Kuka käyttää?

Transkriptio

1 Agile Iteratiivinen ja inkrementaalinen Minimaalinen suunnittelu, pieniä tehtäviä Timeboxing Mahdollisimman paljon tuottavaa työtä Julkaise ajoissa ja usein Aloita pienestä Kehitä iteratiivisesti, muutosmahdollisuudet Käyttötapaukset, user stories Kehitä riittävän hyväksi Ongelmankuvaus Kommunikaatio, takaisinkytkentä, avoimuus, näkyvyys Luottamus 1

2 Kuka käyttää? 2

3 Miksi agile? Jatkuva näkyvyys Mahdollisuus muutoksiin Aiempi bisnesarvo Matalammat riskit 3

4 Agile -manifesti Helmikuu tekijää We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 4

5 Boehmin spiraali 1986 Palautteen tärkeys, vähän kerrallaan, varaudu muutoksiin, inkrementaalisuus, iteratiivisuus, riskiohjautuvuus, prototyypit 5

6 Boehmin riskinhallintasuunnitelma 1. Identify the project s top 10 risk items 2. Present a plan for resolving each risk item 3. Update list of top items, plan and results monthly 4. Highlight risk-item status in monthly project reviews 5. Initiate appropriate corrective actions 6

7 Suunnittelumallit Arkkitehtuurin tärkeys Alexander: ei pohjapiirustuksia, sketsejä Alexander: asukkaiden pitäisi tehdä rakennus Adaptiiviset prosessit Yksilöt ja yhteydet 7

8 Open source Basaari, ei katedraali, Raymond Every good work of software starts by scratching a developer's personal itch. 2. Good programmers know what to write. Great ones know what to rewrite (and reuse). 3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man- Month, Chapter 11) 4. If you have the right attitude, interesting problems will find you. 5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor. 6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. 7. Release early. Release often. And listen to your customers. 8. Given enough eyeballs, all bugs are shallow. 9. Smart data structures and dumb code works a lot better than the other way around. 10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. 8

9 The new new development game Hirotaka Takeuchi, Ikujiro Nonaka 1986 Tuotantovaiheet saatava päällekäin, sashimi-periaate Tuotantomalli rugbystä: tiimi kuljettaa palloa yhteistyössä, ei viestijuoksua Sashimimalli 9

10 The new new development game Sisäänrakennettu epätasapaino Opetetaan uimaan heittämällä järveen Itseorganisoituvat projektitiimit Autonomia Itsensä ylittäminen Ristipölytys Päällekkäiset kehitysvaiheet Monioppiminen Monitasoinen oppiminen Monitoiminnallinen oppiminen Hienovarainen ohjaus 10

11 Rajoitteet Vaatii työntekijöiltä paljon Ei sovi välttämättä vallankumouksellisiin innovointiprojekteihin Isot projektit eivät taivu hyvin tiimityöskentelyyn Jos suunnittelu on neron tekemää ja hyvin määrittelemää 11

12 Toimintojen käyttöprosentit 15 % 16 % 7 % 43 % Never Rarely Sometimes Often Always 19 % Jim Johnson. The Standish Group International Inc

13 Vaikutus Halvemmat toteutuskulut Vaarallista toteuttaa, tekevät järjestelmästä monimutkaisemman Tee nämä ehdottomasti Järjetöntä toteuttaa Ensimmäisenä TODO-listalla Bisnesarvo 13

14 Scrum Ketterän ja iteratiivisen kehityksen prosessikehys Jeff Sutherland, John Scumniotales, and Jeff McKenna OOPSLA 95 14

15 Scrum-roolit Siat Scrum master Product owner Tiimin jäsenet Kanat Sidosryhmät (asiakas, myyjä ) Johtajat 15

16 Työmäärän arviointi Mahdollisimman pieniä tehtäviä Jokin tunnettu vertailupiste, johon verrataan Arvioinnin ei ole pakko olla oikein, mutta sen on oltava kerrasta toiseen samojen periaatteiden mukaista. 16

17 Vastuu Single wrenchable neck Kaikilla selkeästi määritellyt vastuut Vastuullisen tehtävän suorittaminen yleensä voitava demonstroida Kaikki perustuu luottamukseen, jokainen tekee parhaansa 17

18 Timeboxing Projektin osittainen kiinteän mittainen aikasiivu, jolla on omat deadlinensä, vaihetuotteensa ja resurssinsa TB1 TB2 TB3 Riskinhallintametodi Nopea palaute Aika Resurssit Ominaisuudet 18

19 Burndown -kaavio Done -> 100% tehty Velocity -> paljonko tehtävää voidaan yhteen sprinttiin saada mahtumaan Kaaviosta vähennetään tehtävän tunnit, jos tehtävä 100% valmis Jos tehtävä kasvaa, lisätään kaavioon tunteja 19

20 Scrumin soveltaminen Scrum on vain kehys Scrum-but Onko tiimi tekemässä Scrumia: Nokia test Iteratiivisuus Alle neljän viikon iteraatiot Ominaisuudet testattuja ja toimivia iteraation lopuksi Iteraation alettava ennen kuin speksi valmis Scrum Kuka on product owner? Backlog priorisoitu bisnesarvon mukaan Estimaatit ovat tiimin tekemiä Burndown kaaviot on tehty ja velocity tunnettu Ei projektinjohtajia 20

21 Agile ja arkkitehtuuri Arkkitehtuurin tuettava ketteryyttä Miten arkkitehtuuri jaetaan backlogiin? Sprint 0, mitä demotaan? Arkkitehti omistaa arkkitehtuurin Arkkitehti vs. tiimi Arkkitehtuuri riippuu vaatimuksista, vaatimukset voivat muuttua 21

22 Lean Toyota Production System, Taichii Ohno Kaiken pitäisi tuottaa lisäarvoa JIT, Jatkuva parantaminen Suunnitellaan tehtävät etukäteen Muda (hukka), muri (ylikuorma) ja mura (tasapainottomuus) Mura poistuu suunnittelulla, parannetaan prosessia ja muokataan suunnitelmia, muri tasapainottamalla laatua ja määriä, muda reaktiivisesti 22

23 Lean software Seitsemän periaatetta 1. Hukan eliminointi Byrokratia, viiveet, epäselvyydet, turhat ominaisuudet ja koodi, kommunikoinnin hitaus 2. Oppimisen tehostaminen 3. Päätä mahdollisimman myöhään 4. Nopea toimitus 5. Tiimille valta Tiimi tietää miten hoitaa työnsä 6. Integriteetti refaktorointi 7. Kokonaisuuden hallinta 23

24 22 lean -työkalua 1. Seeing Waste 2. Value Stream Mapping 3. Feedback 4. Iterations 5. Synchronization 6. Set-Based Development 7. Options Thinking 8. The Last Responsible Moment 9. Making Decisions 10. Pull Systems 11. Queuing Theory 12. Cost of Delay 13. Self-Determination 14. Motivation 15. Leadership 16. Expertise 17. Perceived Integrity 18. Conceptual Integrity 19. Refactoring 20. Testing 21. Measurement 22. Contracts 24

25 Akronyymejä YAGNI, you ain t gonna need it TAGRI, they ain t gonna read it KISS DRY, Don t repeat yourself MoSCoW, Must, Should, Could, Won t/would 25

26 Lean-käsitteitä Poka-yoke: Virheiden estäminen suunnittelemalla järjestelmät sellaisiksi, ettei virheitä voi tapahtua. Virheen teko voi olla fyysisesti mahdotonta tai järjestelmä varoittaa hyvissä ajoin, että virhe on tapahtumassa Kaizen: jatkuva parantaminen Genchi Genbutsu: mene ja katso itse SMED: nopea vaihto toiseen tuotteeseen Andon: menetelmä huomion kiinnittämiseksi virheeseen 26