Utvecklarpraxis för kvalitet i agila projekt
•
0 likes•468 views
Frukostseminarium 4/11 - 2009 Ett vanligt fel många gör när de börjar arbeta agilt är att man låter kvalitén sjunka med tiden. Det kan vara kompromisser mellan bra kod och snabb leverans, slarv med de automatiserade testerna, dokumentation som saknas eller är inaktuell, med mera. Det börjar ta längre och längre tid för projektet att kunna göra en bra leverans. Vad behöver vi för att kunna upprätthålla bra kvalitet och högt tempo på samma gång? Magnus Mickelsson - Citerus
Recommended
Recommended
More Related Content
Featured
Featured (20)
Utvecklarpraxis för kvalitet i agila projekt
- 1. Utvecklarpraxis för kvalité Hur bär vi oss åt för att hålla kvalitén uppe i våra (agila) projekt? Magnus Mickelsson, Citerus AB magnus.mickelsson@citerus.se 1
- 2. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Om Citerus • Citerus är ett konsult- och utbildningsföretag som hjälper sina kunder att lyckas med mjukvaruutveckling. Sedan 1996 har vi utvecklat mjukvara, lett projekt, förbättrat utvecklarpraxis och förfinat ledningsmetoder åt företag från många olika branscher. Vi uppnår resultat genom att höja kvalitetsribban, sätta människor i första rummet och minska på byråkratin. Om Magnus Mickelsson ‣ I branschen sedan 1996 - systemutvecklare och arkitekt QuickTime och en -dekomprimerare krävs för att kunna se bilden. ‣ Certifierad Scrum Master ‣ Utbildar inom TDD, refactoring och övriga Engineering Practices ‣ Fokus på J2EE-plattformen 2
- 3. Vad går fel med vår kod och våra projekt? Hjälper Agile-metoder? 1985-1987 -- Therac-25 medical accelerator. A radiation therapy device malfunctions and delivers lethal radiation doses. Because of a subtle bug called a "race condition” … At least five patients die; others are seriously injured. 3
- 4. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Agile miljö • Självförbättrande • Fokus på ”rätt saker” • Affärsnytta - bra kvalité - snabbt • Kunna lösa problem i teamet • Tydligt och synligt 4
- 5. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Hinder och fällor •Otydliga/oprioriterade krav •Ingen förbättringsprocess •Ingen koll på konsekvenser •”Trasiga fönster” •Teamet kan inte arbeta fokuserat 5
- 6. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Hur handskas vi med detta på teknisk nivå? •KLART-kriterier •Engineering practices •Stop the line 6
- 7. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Stop-the-line! 7
- 8. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Engineering Practices Documentation Visual feedback Refactoring Continuous Integration TDD & Testing Automated build- and release Version control 8
- 9. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Synbar, snabb feedback 9
- 10. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 TDD Think Write test that fails • Ger snabb feedback till utvecklarna Write code to pass test No • Fokusera på domänen (DDD) Do the Yes tests pass? • Hitta ”rytmen” Yes Refactor No Do the tests pass? 10
- 11. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Agil testning - hitta versus undvika buggar Peer programming Developer Customer testing Agile tries to testing use it Quality of code Functionality Acceptance Test automation 11
- 12. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Refactoring •Konsten att städa sin egen röra •Naturlig del av dagliga arbetet •Laga trasiga fönster kontinuerligt •Kräver automatiserade tester 12
- 13. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Kontinuerlig integration och ”One click build” •Enkelt att bygga hela produkten •Automatisera! •Bygg vid varje förändring •Statusrapporter som del av bygget •Larm då bygget kraschar 13
- 14. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Dokumentation i Wiki •Lätt att komma åt och jobba med •Korslänkar •Sökbar •Versionshanterad •Dock: lätt att få ”trasiga fönster” 14
- 15. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 KLART • Kodat •Koden städad •Lyder riktlinjer •Lever upp till kraven •Inga to-dos •Analyserad (Findbugs, PMD etc) 15
- 16. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 KLART • Testat •Automatiserade tester •Manuella tester •Code coverage 16
- 17. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 KLART • Reviewat •Pair programming eller peer review •Design granskad 17
- 18. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 KLART • Administrativt •Dokumentation uppdaterad •Byggscript/verktyg uppdaterade •Inga ofärdiga uppgifter 18
- 19. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 KLART • Levererans •Kod incheckad •Byggt och deployat/paketerat 19
- 20. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Nästa steg? •Fundera över nuläget •Fundera vart ni vill komma •Utbildningar/Litteratur •Hjälp att få team att komma igång •Uppmuntra ”kunskapsföretaget” 20
- 21. Citerus - Magnus Mickelsson, 2009 - magnus.mickelsson@citerus.se - 0708-444183 Frågor? • magnus.mickelsson@citerus.se 21
Editor's Notes
- 2006 Standish Report: 46% av alla projekt misslyckas att leverera ”on-time, within budget or in scope”. "A Standish Group research report shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates” "On the success side, the average is only 16.2% for software projects that are completed on time and on budget. In the larger companies, the news is even worse: only 9% of their projects come in on time and on budget.” http://www.standishgroup.com/sample_research/chaos_1994_1.php
- Korsfunktionella team
- ” Trasiga fönster”: Kommer ”döda buggar” tillbaka till liv? Har ni problem att exakt återskapa en release? Kan jobb gå förlorat om någonting går sönder? Finns det kod i systemet som ingen törs röra? Förstår utvecklare och managers inte varandra?
- Engineering practices för att: Hålla komplexiteten under kontroll Lättare hantera överraskningar Automatisera lättare, vanligt förekommande, uppgifter Snabb feedback till teamet
- Vad är värt att “stoppa linjen” för? Kraschat bygge? Processen funkar inte?
- Engineering practices - några av de viktigare punkterna att ha på plats och se till att de fungerar för att ett projekt ska kunna prestera bra.
- Helikopternivå - större projekt med flera team eller en organistation - karta över pågående projekt/team, hinder som behöver åtgärdas, notiser över saker som behöver synkas med andra team. Lokal nivå - mindre projekt eller enstaka team - lappar med vad som behöver göras i nuvarande sprint, hinderlista, resultat av byggen, kvalitetsrapporter etc.
- Att ha stödet av automatiserade tester ger snabb feedback och ett säkerhetsbälte som gör att man kan fortsätta gå framåt, och inte konstant titta i backspegeln för att se om något gick sönder vid något tillägg eller ändring.
- Michael Feathers WEWLC sid 59: Pay now or pay more later. Either write tests as you make your changes or live with the fact that it is going to get tougher over time.
- Test-Driven development If we estimate 2000 users and lock into that kind of technology, what happens when they suddenly say, ”oh it’s 20000”?
- Flera olika sorters byggen - lokalt för utvecklare, ”continuous integration” med rapporter och status, ”daily build”, release-bygge, t.ex.
- Att använda en Wiki kräver att man ”refactorerar” Wikin, för att förhindra att informationen blir rörig, ologisk och/eller inaktuell.
- Vad för automatiserade tester? Vad för manuella tester?