Ohjelmistotekniikka - Luento 3 Jouni Lappalainen

Transkriptio

1 Ohjelmistotekniikka - Luento 3 Jouni Lappalainen Luku 3: Ketterä kehitys - ketterien menetelmien 12 periaatetta - XP (extreme programming) - Scrum menetelmä - Lean menetelmä 1

2 Luku 3: Ketterä kehittäminen Ketterä (agile) termi ohjelmistojen kehittämisen yhteydessä tarkoittaa (agile manifest) Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 2

3 Ketteryyden vaikutus muutoskustannuksiin Muutoskustannukset, kun käytetään perinteistä kehitysprosessia Muutoskustannukset Projekti edistyy Todelliset muutoskustannukset, kun käytetään ketterää kehitysprosessia Tavoite, kun käytetään ketterää kehitysprosessia 3

4 Ketterien menetelmien 12 periaatetta (Agile Alliance, 2003) 1. Tärkeimpänä periaatteena on toteuttaa asiakkaan toiveet ensimmäisestä toimituksesta alkaen ja jatkaa tätä ohjelmiston valmistumiseen 2. Muuttuvia vaatimuksia otetaan vastaan jopa kehityksen loppuvaiheessa. Ketterien menetelmien tarkoituksena on edistää asiakkaan kilpailuetua. 3. Toimivia ohjelmaversioita toimitetaan jatkuvasti. Toimitusvälit vaihtelevat muutamasta viikosta muutamaan kuukauteen. 4

5 Ketterien menetelmien 12 periaatetta Liiketoiminnan edustajat ja ohjelmistokehittäjät työskentelevät yhdessä päivittäin ja läpi projektin. 5. Rakenna projekti motivoituneiden henkilöiden varaan. Anna heidän käyttöön tarvittava toimintaympäristö, tue heidän tarpeita ja luota heihin. 6. Kasvokkain käytävä keskustelu on tehokkain tapa välittää informaatiota. 7. Toimiva ohjelmisto on tärkein kehityksen mittari. 8. Ketterät prosessit tukevat kestävää kehitystä. Hankkeen omistajien, kehittäjien ja käyttäjien tulisi pystyä kehittämään toimintaansa jatkuvasti. 5

6 Ketterien menetelmien 12 periaatetta Jatkuva huomion kohdistaminen tekniseen laatuun ja hyvään suunnitteluun edistää ketteryyttä. 10. Yksinkertaisuus tekemättä jätettävän työn maksimointi (ei tehdä turhaa työtä) on oleellista. 11. Itseorganisoituvat tiimit tuottavat parhaita arkkitehtuuriratkaisuja, vaatimusmäärittelyjä ja suunnitelmia. 12. Tiimi tarkastelee omaa toimintaansa säännöllisin väliajoin ja miettii tehokkaampia toimintatapoja. 6

7 Mitä ominaisuuksia vaaditaan tiimiltä ja sen jäseniltä Kompetenssi Yhteinen tavoite Kyky yhteistyöhön Kyky päätöksentekoon Kyky ratkaista sumeita ongelmia Jäsentenvälinen luottamus ja kunnioitus Kyky järjestää tiimin asiat (itseorganisoitua) 7

8 Ketteriä menetelmiä ovat esim. extreme Programming (XP) Scrum Lean Feature Driven Development Crystal Agile Modeling 8

9 extreme Programming (XP) Olettamus ohjelmiston vaatimukset ovat muuttuvia ja muutosten määrä sekä ominaisuudet ovat ennalta arvaamattomia. turhaa suunnitella arkkitehtuuria tulevaisuutta varten, koska tulevaisuudessa suunnittelulähtökohdat saattavat kuitenkin olla täysin erilaiset. 9

10 XP käytännöt (12 kpl, Beck 2000) 1. suunnittelupeli (planning game) 2. pienet julkaisut (small releases) 3. metafora (metaphor) 4. yksinkertainen suunnittelu (simple design) 5. testaus (testing), 6. refaktorointi (refactoring) 7. pariohjelmointi (pair programming) 8. kollektiivinen koodin omistaminen (collective ownership) 9. jatkuva integrointi (continuous integration) tuntinen viikko (40-hour week) 11. on-site asiakas (on-site customer) 12. ohjelmointistandardit (coding standards). 10

11 Uusi XP (2005) Vaatimusten analysointi ja suunnittelu 1. Kertomukset (stories), kuvaavat järjestelmän toiminnan 2. Viikkosykli (weekly cycle), viikon alussa valitaan toteutettavat kertomukset 3. Kvartaalisykli (quarterly cycle), suunnitellaan toimintaa pidemmällä tähtäimellä 4. Löysä aikataulu (slack), pidä aikataulu sopivan löysänä, jotta ennakoimattomat ongelmat ehditään ratkaista 11

12 Uusi XP (2005) Tiimi- ja ihmistekijät 5. Yhdessä tilassa (sit together), tiimin tulisi toimia yhdessä tilassa, jotta kommunikointi olisi tehokasta 6. Koko tiimi (whole team), tiimissä tuli olla monenlaista osaamista ja yhteishenki 7. Informatiivinen työtila (informative workspace), työtilassa tulisi olla esim. postereita, jotka kertovat projektin tilasta 8. Innostava työ (energized work), ylitöitä tulisi minimoida, jotta suunnittelijat pysyvät virkeinä 9. Pariohjelmointi (pair programming), koodaamiseen osallistuu aina kaksi ohjelmoijaa 12

13 Uusi XP (2005) Suunnittelu 10. Paloittain suunnittelu (incremental design), suunnitelma koodataan heti kuin mahdollista, näin saadaan nopeasti palautetta ja järjestelmää voidaan parantaa jatkuvasti 11. Testit ensin ohjelmointi (test-first programming), testit kirjoitetaan ennen koodin päivitystä ja lisäystä Koodaus ja julkaisu 12. Kymmenen minuutin kooste (ten-minute build), järjestelmän koostaminen ja testien suoritus tulisi tehdä 10 minuutissa 13. Jatkuva integrointi (continuous integration), kehittäjien tulisi integroida muutokset kahden tunnin välein 13

14 Uusi XP (2005) Lisäkäytänteet Real customer involvement Incremental Deployment Negotiated scope contract Pay-per-use Team continuity Shrinking team Root-cause analysis Code and test Shared code Single code base Daily deployment 14

15 XP prosessi Käyttäjäkertomukset - arvot (priorisointi) - hyväksymistestauskriteeerit Iteraatioiden suunnittelu (mitä toteutetaan seuraavassa julkaisussa) julkaisu ohjelmiston lisäys (inkrementti) - lasketaan projektin nopeus (montako kertomusta julkaisussa toteutettiin) Planning Yksinkertainen suunnittelu - CRC kortit Test Hyväksymistestaus Refaktorointi Yksikkötesti Design Coding Jatkuva integrointi Kokeilut (spike solutions) - prototyypit Pariohjelmointi 15

16 XP projekti User Stories Test scenarios Requirements New user story project velocity Bugs Architectural Spike System metaphor Uncertain estimates Release Planning Spike Release plan Confident estimates Iteration Latest version Next iteration Acceptance Test Customer approval Exploration phase Planning phase Iterations to Release phase Productionizing phase Maintenance phase Small Releases 16

17 XP iteraatiosykli New user stories, Project velocity Release plan Next iteration Bugs User stories Project Velocity Failed Acceptance Tests Iteration Planning Unfinished Tasks Iteration Plan Learn and Communicate Development New Functionality Bug Fixes Day by Day Latest version 17

18 XP kehityssykli Day by Day Iteration plan Tasks Failed Acceptance Tests Unfinished Tasks Too much to do Stand up Meeting Share Next Task or Failed Acceptance Test Learn and Communicate Pair Programming Refactor Mercilessly Move People Around CRC cards Collective Code Ownership 100% Unit Tests Passed Acceptance Test Passed New Functionality Bug Fixes 18

19 Scrum Nimi tulee rugbyn pelitaktiikkapalavereista reagoidaan nopeasti ympäristön tarpeisiin Menetelmä ei ota kantaa tekniikoihin, kuten XP, vaan painottaa iteratiivista suunnittelua ja edistymisen seurantaa Ei projektipäällikköä vaan itsenäistä työtä yhteisin tavoittein Scrum master ohjaa prosessia Työlistat (backlog) tuotteelle, julkistukselle ja sprintille Scrum kehitys on jaettu viiteen vaiheeseen julkistussuunnitelman katselmointi tuotestandardien jakelu, katselmointi ja sovitus sprintti näistä tarkemmin seuraavilla sivuilla sprintin katselmointi julkistuksen kehityksen lopetus 19

20 Scrum Kehitystyö ositetaan sprintteihin, pyrähdyksiin aktiviteetit: kehitä, paketoi, katselmoi, sovita aktiviteettien ei tarvitse noudattaa peräkkäistä järjestystä Sprintin pituus on max 4 viikoa / 30 päivää, mutta päivittäin pidetään minuutin päiväpalaveri (daily scrum), jossa käydään läpi tehty työ ja seuraava työ Scrum master kysyy mitä kukin on tehnyt onko ongelmia mitä seuraavaksi 20

21 Scrum prosessi (sprintti ja sen katselmointi) Sprintin tehtävälista: - ominaisuudet yhteen Sprint kierrokseen Kehitä, paketoi, katselmoi, sovita (ei vaadita peräkkäisyyttä) Päivittäin 30 päivää Tuotteen kehitysjono(backlog): - asiakkaan haluamat ominaisuudet minuutin päivittäinen Scrum tapaaminen ( tilannekatsaus) Ei projektipäällikköä, Scrum master valvoo prosessin noudattamista Uusi toteutettu ominaisuus Sprintin katselmointi: sidosryhmä osallistuu 21

22 Lean (hoikka, kevyt) software development Eliminoi hukka (Eliminate Waste) vältä virheitä, turhia piirteitä, töiden ketjutusta, odottelua, osittain tehtyjä töitä, tarpeettomia prosesseja Rakenna laatua (Build Quality in) luo testitapaukset, testaa mahdollisimman aikaisessa vaiheessa ja jatkuvasti, automatisoi testaus Tehosta oppimista, Luo tietämystä (Amplify Learning, Create Knowledge) Ohjelmistokehityksessä tehdään tuotetta, jollaista ei olla aiemmin tehty => se vaatii uuden asian oppimista Talleta tiimin tietämys niin että sen löytää helposti, esim. kommentteina koodiin 22

23 Lean (hoikka, kevyt) software development Päätä mahdollisimman myöhään (Defer Commitment) parhaat päätökset tehdään, kun tietoa on riittävästi Toimita nopeasti (Deliver Fast) kehitä piirteitä paloittain ja lyhyissä iteraatioissa Arvosta ihmisiä (Respect People) luota ihmisten kykyyn suorittaa tehtävät ja parantaa prosessia Optimoi kokonaisuus (Optimize the Whole) paikallisen prosessin optimointi ei riitä, pyri optimoimaan mahdollisimman suuri osa arvoketjusta 23

24 Feature Driven Development (FDD) Suositellut käytännöt (best practices) Sovellusalueen mallintaminen (domain object modeling) Piirreperustainen kehittäminen (developing by feature) Luokan omistajuus (Individual class ownership) Piirrekohtaiset ryhmät (feature teams) Tarkastukset (inspections) Säännölliset julkistukset (regular builds) Versionhallinta (configuration management) Tulosten raportointi (reporting of results) 24

25 Feature Driven Development (FDD) Kehitä kokonaismalli Muodosta lista halutuista ominaisuuksista Ominaispiirrekohtainen toteutuksen suunnittelu Ominaispiirrekohtainen ohjelmiston suunnittelu Ominaispiirrekohtainen ohjelmiston rakentaminen 25

26 Luento 3: lait ja pohdiskeluaiheet 1. Ketterät ohjelmointimenetelmät vähentävät muuttuvien vaatimusten vaikutusta / hyp_no 6, Fowler 2001 asiakkaat eivät ymmärrä alussa kaikkia tarpeitaan -> vaatimukset muuttuvat läsnäolevat asiakkaat nopea kehityssykli mahdollistaa osittain valmiiden järjestelmien esittelyn 26

27 Luento 3: lait ja pohdiskeluaiheet Millaisille projekteille protoilumalli ja vesiputousmalli soveltuvat parhaiten? Cockburn esittelee oheisessa paperissa inkrementaalisen ja iteratiivisen kehittämisen ominaisuuksia. Miksi myös ketterässä ohjelmistokehityksessä tulisi käyttää molempia kehittämistapoja? Cockburn A., Using both incremental and iterative development, Crosstalk, May, 2008, pp

28 Luento 3: lait ja pohdiskeluaiheet Voivatko Agile manifestin neljä periaatetta aiheuttaa joskus myös ongelmia? Millaisia? Tarkastele Turnerin (oheinen paperi) listaa ketterille ominaispiirteille. Mitkä ovat näiden ominaispiirteiden yhteydet ketterien menetelmien 12 periaatteeseen? Turner R., Towards Agile systems engineering process, Crosstalk, April, 2007, pp

29 Harjoitustehtävät: 1 kerta 1. Lue paperit McConnell S., and Tripp L., Professional Software Engineering: Fact or Fiction, IEEE Software, Nov/Dec, 1999, pp Davis M., Will Software Engineering Ever Be Engineering?, Communications of the ACM, vol 54, no 11, 2011, pp ja kirjoita noin 700 sanan paperi aiheesta; Voiko ohjelmistotekniikka koskaan tulla insinööritaidoksi (engineering)? Voit tarkastella myös kysymyksiä: Mitä elementtejä kypsään ammattikuvaan tarvitaan? Mitä puutteita ohjelmistotekniikassa kypsän ammattikuvan kannalta tunnetaan? 2. Lean Software Development menetelmässä on seitsemän periaatetta. Valitse niistä yksi (ei kuitenkaan eliminate waste ) ja kuvaa, miten se sovitetaan ohjelmistokehitykseen ketterässä ohjelmistoprojektissa. 3. Toimit projektipäällikkönä ohjelmistoyrityksessä. Tehtävänäsi on hallita laajassa käytössä olevan tekstinkäsittelysovelluksen seuraavan sukupolven version kehittämistä. Työlle on suunniteltu ja hyväksytty tiukka aikataulu. Millaisen prosessimallin valitset ja miksi? 29