De sex viktigaste tekniska arbetsmetoderna som varje produktägare måste känna till
•Download as KEY, PDF•
0 likes•454 views
Som produktägare behöver du känna till värdet av de tekniska arbetsmetoder som ditt utvecklingsteam använder, för att du ska förstå varför tid ska spenderas på att användandet av dem. Att känna till mer om detta ger dig också möjlighet att kräva att teamet börja nyttja de tekniska arbetsmetoder du bedömer ger störst nytta för din produkt. I den här presentationen kommer jag att visa på de viktigaste tekniska arbetsmetoderna för utveckling av mjukvara som du som produktägare borde känna till. Fokus är på vilken nytta de ger, inte på exakt hur de införs. Denna presentation bygger på en artikel som finns publicerad på http://www.scrumalliance.org/articles/139-the-top-six-technical-practices-every-product-owner-must-know-about och den kommer att hållas som blixttal även på XP2010 i Trondheim. Talare är Mikael Boman från Citerus
Recommended
More Related Content
More from Agila Sverige
More from Agila Sverige (20)
De sex viktigaste tekniska arbetsmetoderna som varje produktägare måste känna till
- 1. De sex viktigaste tekniska arbetsmetoderna som varje produktägare måste känna till Mikael Boman, Citerus AB mikael.boman@citerus.se www.citerus.se 1
- 2. 2
- 3. Subversion 2
- 4. Subversion Hudson 2
- 5. Subversion JUnit Hudson 2
- 6. Subversion JUnit Hudson JMock 2
- 7. Subversion ClearCase JUnit Hudson JMock 2
- 8. Subversion ClearCase JUnit Hudson JMock Git 2
- 9. Subversion ClearCase JUnit Hudson JMock Git Selenium 2
- 10. Subversion ClearCase JUnit Hudson JMock TDD Git Selenium 2
- 11. Subversion ClearCase CruiseContr JUnit Hudson JMock TDD Git Selenium 2
- 12. Citerus - Mikael Boman, 2010 - mikael.boman@citerus.se - 0709-43 90 80 Tekniska arbetsmetoder Foto från sxc.hu 3
- 13. Citerus - Mikael Boman, 2010 - mikael.boman@citerus.se - 0709-43 90 80 Versionshantering Foto från sxc.hu 4
- 14. Citerus - Mikael Boman, 2010 - mikael.boman@citerus.se - 0709-43 90 80 Automatiska tester Foto från sxc.hu 5
- 15. Citerus - Mikael Boman, 2010 - mikael.boman@citerus.se - 0709-43 90 80 Kontinuerlig integration Foto från sxc.hu 6
- 16. Citerus - Mikael Boman, 2010 - mikael.boman@citerus.se - 0709-43 90 80 Refaktorering Foto från sxc.hu 7
- 17. Citerus - Mikael Boman, 2010 - mikael.boman@citerus.se - 0709-43 90 80 Gemensamt kodägarskap Foto från sxc.hu 8
- 18. Citerus - Mikael Boman, 2010 - mikael.boman@citerus.se - 0709-43 90 80 Gemensamt kodägarskap Foto från sxc.hu 8
- 19. Citerus - Mikael Boman, 2010 - mikael.boman@citerus.se - 0709-43 90 80 Enkel design Foto från sxc.hu 9
- 20. Citerus - Mikael Boman, 2010 - mikael.boman@citerus.se - 0709-43 90 80 Enkel design Foto från sxc.hu För den som undrar - det är en 9 vägglampa
- 21. Citerus - Mikael Boman, 2010 - mikael.boman@citerus.se - 0709-43 90 80 www.citerus.se 10
Editor's Notes
- Denna presentation är inte tekniskt fokuserad, så ni kommer att slippa höra ord som Subversion, Hudson, JUint, Jmock, ClearCase, Git, Selenium, TDD, CruiseControl
- Denna presentation är inte tekniskt fokuserad, så ni kommer att slippa höra ord som Subversion, Hudson, JUint, Jmock, ClearCase, Git, Selenium, TDD, CruiseControl
- Denna presentation är inte tekniskt fokuserad, så ni kommer att slippa höra ord som Subversion, Hudson, JUint, Jmock, ClearCase, Git, Selenium, TDD, CruiseControl
- Denna presentation är inte tekniskt fokuserad, så ni kommer att slippa höra ord som Subversion, Hudson, JUint, Jmock, ClearCase, Git, Selenium, TDD, CruiseControl
- Denna presentation är inte tekniskt fokuserad, så ni kommer att slippa höra ord som Subversion, Hudson, JUint, Jmock, ClearCase, Git, Selenium, TDD, CruiseControl
- Denna presentation är inte tekniskt fokuserad, så ni kommer att slippa höra ord som Subversion, Hudson, JUint, Jmock, ClearCase, Git, Selenium, TDD, CruiseControl
- Denna presentation är inte tekniskt fokuserad, så ni kommer att slippa höra ord som Subversion, Hudson, JUint, Jmock, ClearCase, Git, Selenium, TDD, CruiseControl
- Denna presentation är inte tekniskt fokuserad, så ni kommer att slippa höra ord som Subversion, Hudson, JUint, Jmock, ClearCase, Git, Selenium, TDD, CruiseControl
- Denna presentation är inte tekniskt fokuserad, så ni kommer att slippa höra ord som Subversion, Hudson, JUint, Jmock, ClearCase, Git, Selenium, TDD, CruiseControl
- Denna presentation ska fokusera på värdet för dig som produktägare av att teamet inför bättre arbetsmetoder. Jag kommer inte att prata om hur det ska gå till. Relaterat till Extreme Programming/ XP
- Gör det att på ett säkert sätt underhålla flera versioner av en applikation. Utan detta är det väldigt riskabelt och kostsamt. Detta är en självklarhet för de flesta projekt idag, men konstigt nog inte överallt.
- Något som tar mycket tid i projekt idag, är all manuell testning som vi måste göra, för att säkerställa att ny funktionalitet inte har förstört gammal funktionalitet. Här kan vi spara tid genom att utvecklarna och testarna gemensamt tar fram automatiska tester. Förutom sparad tid får vi också en ökad säkerhet då vi vet att faktiskt samma tester körs varje gång.
- Se till att det går snabbt, och utan manuella grepp, att bygga en fullständig version av applikationen. Detta ger möjlighet för utvecklarna att fokusera på att bygga funktionalitet, och inte slösa tid på manuellt byggarbete. Om detta görs automatiskt och hela tiden, får vi också snabbt veta om något gått sönder.
- Skriv om koden så att den gör samma sak som tidigare, men på ett annat sätt. Behövs för att kunna få kod som går att förvalta när nya funktioner byggs som ligger nära något som redan finns. Istället för att få två mer eller mindre identiska kopior av koden ska utvecklarna skriva om gammal kod så att den också kan hantera det nya fallet.
- Se till att ingen utvecklare blir omumbärlig. Hanterar Bussfaktorn. Ger automatisk kunskapsspridning om man t.ex. använder parprogrammering.
- Se till att ingen utvecklare blir omumbärlig. Hanterar Bussfaktorn. Ger automatisk kunskapsspridning om man t.ex. använder parprogrammering.
- Lätt att förstå, kräver inte genier. Lätt att förändra när kraven ändras. Lätt att förbättra när vi lär oss mer. Svårt att kontrollera om du inte är insatt i tekniken, men kan vara värt att ställa frågan.