Ohjelmistotekniikka - Luento 3

Transkriptio

1 Ohjelmistotekniikka - Luento 3 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 Muutoskustannukset, kun käytetään perinteistä (waterfall) kehitysprosessia Todelliset muutoskustannukset, kun käytetään ketterää kehitysprosessia Tavoite, kun käytetään ketterää kehitysprosessia Projekti edistyy 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) 1. 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) Yksinkertainen suunnittelu - CRC kortit Kokeilut (spike solutions) - prototyypit Design Planning Refaktorointi Coding julkaisu ohjelmiston lisäys (inkrementti) - lasketaan projektin nopeus (montako kertomusta julkaisussa toteutettiin) Test Hyväksymistestaus Yksikkötesti Jatkuva integrointi Pariohjelmointi 15

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

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

18 XP kehityssykli Iteration plan Tasks Unfinished Tasks Too much to do Share Learn and Communicate Pair Programming Refactor Mercilessly Move People Around CRC cards New Functionality 100% Unit Tests Passed Day by Day Failed Acceptance Tests Stand up Meeting Next Task or Failed Acceptance Test Collective Code Ownership Acceptance Test Passed 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 sprintin katselmointi julkistuksen kehityksen lopetus näistä tarkemmin seuraavilla sivuilla 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) Kehitä, paketoi, katselmoi, sovita (ei vaadita peräkkäisyyttä) Sprintin työlista: - ominaisuudet yhteen Sprint -kierrokseen Päivittäin 30 päivää minuutin päivittäinen Scrum tapaaminen ( tilannekatsaus) Ei projektipäällikköä, Scrum master valvoo prosessin noudattamista Uusi toteutettu ominaisuus Tuotteen työlista (backlog): - asiakkaan haluamat ominaisuudet 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 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ä ohjelmisto- kehityksessä tulisi käyttää molempia kehittämistapoja? Cockburn A., Using both incremental and iterative development, Crosstalk, May, 2008, pp

28 Tuoretta tietoa Teemu Karvonen: Jatkuva ohjelmistotuotanto ohjelmistopainotteisessa tuotekehityksessä (väitöskirja) Continuous software engineering in the development of software-intensive products Web-kehityksessä yleisesti hyödynnettyä jatkuvaa ohjelmistojulkaisua (continuous deployment) ja asiakaskokeiluja (customer experimentation) hyödynnetään vain harvoin tuotepainotteisessa ohjelmistotuotannossa. Teknisten haasteiden lisäksi perinteiset jäykät liiketoimintamallit ja hitaat, pitkäkestoiset projektikäytännöt ovat usein esteenä nopeille asiakaskokeiluille ja ohjelmistojulkaisuille ohjelmistoyritykset ovatkin panostaneet voimakkaasti tuotekehityskäytäntöjen uudistamiseen ja tekniseen kyvykkyyteen, kuten jatkuvaan integrointiin (continuous integration) ja automatisoitujen testijärjestelmien kehittämiseen tuoteohjelmissa ja kehitystiimeissä. Yritystasolla ja liiketoimintamalleissa kyvykkyyttä jatkuvaan toimittamiseen ja asiakaskokeiluihin kuitenkin hyödynnetään hajanaisesti vain joissakin tuote- ja asiakasprojekteissa. 28

29 Yhteenveto Tärkeää on olla yhteinen visio, tavoite Tärkeää on kommunikoida Tärkeää on tietää miten aiomme toimia yhdessä Valitaan joku kehitysparadigma joka sopii ongelmaan ja joka osataan enemmän tai vähemmän hyvin, ja joka sopii asiakasyhteistyöhön ja varmistetaan että kaikki tietävät miten toimitaan, mitä toimitetaan ja milloin 29