Ohjelmistotekniikka - Luento 13 Jouni Lappalainen & Henrik Hedberg

Transkriptio

1 Ohjelmistotekniikka - Luento 13 Jouni Lappalainen & Henrik Hedberg Hajautettu versionhallinta Git työkalulla - Henrik Hedberg Luku 27: Projektin aikataulun kiinnittäminen - työnositus (WBS) - aikataulutustekniikat ja ansaitun arvon arvio - Scrum projektin hallinnassa

2 Soveltuvat lait ja pohdiskelun aiheita 1. Henkilöiden lisääminen myöhässä olevaan projektiin aiheuttaa vain lisää myöhästymistä / no 36, Brooks 1975 Milloin tuo edellä esitetty Brooksin laki ei välttämättä pidä paikkaansa? Van Genuchten ja Hatton esittelevät paperissaan uuden mittarin, ohjelmiston hyöty (software mileage). Mitä sillä tarkoitetaan ja mihin sitä voidaan käyttää?? Mitä yhteistä näet ansaitun arvon arviossa ja Scrumin Burndown arviossa?

3 27. Projektin aikataulun kiinnittäminen työn osittaminen - WBS WBS (work breakdown structure) on puurakenne, joka kuvaa esim. projektin tai sopimuksen vaatiman työpanoksen. Tällöin kuvataan lopputulos ja sen jakaminen hallittaviin komponentteihin (järjestelmät, osajärjestelmät, komponentit, tehtävät, osatehtävät, työpakkaukset) Tehtävät (tai osatehtävät) ovat yhdelle henkilölle ositettavissa oleva rajattu työkokonaisuus, josta henkilö selviää 2-3 viikossa

4

5 Projektin vastuiden määrittely Responsibility Assignment Matrix (RAM) Projektin vastuiden määrittelyn pohjana ovat projektin tehtävien määritys WBS (work breakdown structure) siihen liittyvät työmääräarviot käytettävissä olevat resurssit osaaminen työpanos vastuu Lopputuloksena on Responsibility Assignment Matrix (RAM) 5

6 Projektin aikataulutus Tietty tehtävä toteutetaan aktiviteetilla Aktiviteettiin liittyy alkamisajankohta, päättymisajankohta tekijät, käytettävä työpanos vaihetuotteet (deliverables) Aktiviteettien päättymisajankohtia sanotaan etapeiksi (milestones) Etappi on saavutettu, kun aktiviteetin vaihetuotteet on hyväksytty projektisuunnitelman määrittämällä tavalla (esim. projektikatselmuksessa) Aktiviteetti 1 Aktiviteetti 2 Aktiviteetti 3 Aktiviteetti 4...

7 Esimerkki aikataulutuksesta (Gantt-kaavio) Aktiviteetti" viikko 30" viikko 31" viikko 32" viikko 33" viikko 34" viikko 35" Aktiviteetti 1 Aktiviteetti 2 Aktiviteetti 3 Aktiviteetti 4 Aktiviteetti 5 Aktiviteetti 6 Aktiviteetti 7 Tarkasteluajankohta

8 Työmääräarvion tarkentuminen 4*x esitutkimus 2*x määrittely 1.5*x moduulisuunnittelu toteutus 0.67*x 0.5*x 0.25*x Boehm 1984

9 Työpanos ja tuotteen toimitus asiakkaalle Effort Cost E d Impossible region E a = m (t 4 d /ta 4 ) E a = effort in person-months t d = nominal delivery time for schedule t o = optimal development time (in terms of cost) t a = actual delivery time desired E o T min = 0.75T d t d t o development time Ohjelmiston arvioitu koko on LOC ja projektin vaatima työpanos 12 henkilötyövuotta. Jos tiimin koko on 8 henkilöä, projekti valmistuu noin 1.3 vuodessa Jos toimitusaikaa jatketaan 1.75 vuoteen, tarvittava työpanos laskee niin, että tiimin koko voidaan pienentää 4 henkilöön Pressman

10 Earned Value Management (EVM) (Earned Value Analysis, EVA) Projektin hallinta ansaitun arvon perusteella Ansaittu arvo (Earned value) mittaa kehitystä arvioidaan projektin valmiusastetta suorittamalla määrämuotoista analyysiä aikataulutettujen tehtävien suoritusasteesta Pressman

11 Miten ansaittu arvo lasketaan... Työn budjetoitu kustannus (budgeted cost of work scheduled, BCWS) on määritelty jokaiselle aikataulun tehtävälle BCWS i on suunniteltu työpanos tehtävälle i. tietyllä ajan hetkellä voidaan laskea arvo BCWS, joka on niiden tehtävien BCWS i arvojen summa, joiden pitäisi olla suunnitelmien (aikataulun) mukaan olla valmiina käytetään myös termiä PV (planned value) Valmiiden tehtävien budjetti (budget at completion, BAC) määritellään kaikkien tehtävien BCWS i arvojen summana. BAC = (BCWS k ) kaikille tehtäville k Pressman

12 Ansaitun arvon laskenta CPI = EV / AC SPI = EV / PV PV BAC kustannukset AC SV CV EV aika Lipke & Henderson 2006

13 Miten ansaittu arvo lasketaan... Seuraavaksi lasketaan suoritetun työn budjetoidut kustannukset (budgeted cost of work performed, BCWP). BCWP on kaikkien valmiiden tehtävien BCWS arvojen summa tietyllä ajan hetkellä. käytetään myös termiä EV (earned value) the distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were planned to be completed and the latter represents the budget of the activities that actually were completed. [WIL99] BCWS, BAC ja BCWP arvojen perusteella voidaan laskea : Aikataulupohjainen suorituskyky (Schedule performance index, SPI) = BCWP/BCWS tai EV/PV (hyvä, jos > 1) Aikataulupoikkeama (Schedule variance, SV) = BCWP BCWS SPI kuvaa resurssien käytön tehokkuutta. Pressman

14 Miten ansaittu arvo lasketaan... Arvioitu valmiusaste (Percent scheduled for completion) = BCWS/BAC = (PV /BAC) mikä prosenttiosuus tulisi olla valmiina hetkellä t. Todellinen valmiusaste (Percent complete) = BCWP/ BAC = (EV/BAC) mikä osuus todella on valmiina hetkellä t. Todellinen työkustannus (Actual cost of work performed, ACWP = AC), todellinen työkustannus tehtävistä, jotka ovat valmiina tietyllä hetkellä. Sen jälkeen voidaan laskea kustannuspohjainen suorituskyky (Cost performance index, CPI) = BCWP/ACWP = EV/AC Kustannuspoikkeama (Cost variance, CV) = BCWP ACWP Pressman

15 Scrum projektin hallinnassa ja työmäärän arvioinnissa, ongelmakohdat,... Sprintin suunnittelu - tavoite - tiimin jäsenet ja sitoutuminen - työlista ja sen tarkentaminen tehtäviksi - aika ja paikka päivittäiselle scrumille - sprintin demopäivä Missä järjestyksessä työlistan tehtävät suoritetaan? Miten sprintin vauhti (velocity) arvioidaan (story points)? Montako sprinttiä? Päivittäin 30 päivää Listalla Tehtävänä Tehty Seinätaulun käyttö työpanoksen arviointi sprintin työlistalle Montako tiimiä? Onko sprinttien välillä välipäiviä? Miten hyväksymistestaus järjestetään? Entä retrospective review? Uusi toteutettu ominaisuus Tuotteen työlista (backlog): - asiakkaan haluamat ominaisuudet Sprintin demo (katselmointi) sidosryhmä (asiakas, scrum master tuotteen omistaja, tiimi) osallistuu

16 Työmäärän arviointi ketterissä menetelmissä Tuotteen työlistan vaatimusten tarkentuminen Tuotteen työlistassa aluksi karkea työmääräarvio kullekin vaatimukselle. Vaatimuksen siirtyessä lähemmäksi listan kärkeä, sitä tarkennetaan ja samalla työmääräarvio tarkentuu. Vaatimuksen tai sen osan siirtyessä sprintin työlistaan se ositetaan tehtäviksi (tehtävän koko 4-16 tuntia) Vaatimuksen työmäärä voidaan arvioida suunnittelupokerin avulla jokaisella osallistujalla on korttipakka, jossa jokaisella kortilla on mahdollinen työmääräarvio (esim. 0,1,2,3,5,8,... (Fibonaccin sarjan mukaan) ja lisäksi 1 2,?, kahvikuppi) arvioitava vaatimus esitellään osallistujille jokainen valitsee kortin, joka vastaa hänen näkemystään työmäärästä, ja kortit näytetään yhtä aikaa yleisestä linjasta poikkeavien arvioiden esittäjät saavat puolustaa näkemystään arviointiprosessia toistetaan, kunnes päästään yhteisymmärrykseen Haikala & Mikkonen,

17 Missä järjestyksessä työlistan tehtävät suoritetaan? Miten sprintin vauhti (velocity) arvioidaan (story points)? Montako sprinttiä? Tuotteelta halutut ominaisuudet (perustuvat käyttäjäkertomuksiin (user stories)) järjestetään tärkeysjärjestykseen ja tehdään suunnitelma, missä tuoteversiossa ne toteutetaan tärkeys >= 100: ominaisuudet aina versioon 1.0 tärkeys 50-99: ominaisuudet mielellään versioon 1.0 tärkeys 25-49: ominaisuudet tarvitaan, mutta riittää toteuttaa ne versiossa 1.1 tärkeys < 25: ei tarvitse toteuttaa Ominaisuuksien vaatima työmäärä on arvioitu Fibonacci sarjan mukaisesti. Sprintille tarvitaan myös mittari, jossa on otettu mukaan henkilöiden sitoutumisaste (lomat, toisten tiimien auttaminen, tietokoneongelmat jne.). Tätä sanotaan sprintin vauhdiksi (velocity). Se saadaan kertomalla ns. focus factor arvolla (tavallisesti noin 70%) työpäiväarvio. Näin saadaan uusi mittari story point. Jos sprintin pituus on kiinnitetty 3 viikkoon eli 15 työpäivään ja tiimiin kuuluu 6 henkilöä. Silloin sprintin pituus on 90 työpäivää. Jos kuitenkin focus factor on vain 50%, saadaan sprintin vauhdiksi 45 story pointtia (= paljonko yhdessä sprintissä voidaan tehdä). Tärkeys Nimi banaani kiivi papaija meloni sitruuna omena appelsiini rusina sipuli mustikka puolukka Tärkeys Nimi banaani kiivi papaija meloni sitruuna omena appelsiini rusina sipuli mustikka puolukka Arvio Sprintti 1 Sprintti 2 Sprintti 3 Sprintti 4 Kniberg H., 2006 /

18 Optimaalinen tiimin koko on 5-9 henkilöä. Montako tiimiä? Onko sprinttien välillä välipäiviä? Miten hyväksymistestaus järjestetään? Entä retrospective review? Jos eri tiimit tekevät työtä yhteisen tuotteen eteen, tiimien työn yhteensovittamista voidaan edistää Scrum-of-Scrums kokouksilla. Eri tiimien scrum masterit pitävät kerran viikossa noin puolen tunnin palaverin. Maanantai 9-10 Sprint 1 demo Sprint 1 retrospective Sprint 2 suunnittelu huono parempi Maanantai 9-10 Sprint 1 demo Sprint 1 retrospective Tiistai 9-13 Sprint 2 suunnittelu paras Perjantai 9-10 Sprint 1 demo Sprint 1 retrospective Lauantai Sunnuntai Maanantai 9-13 Sprint 2 suunnittelu Kniberg H., 2006 /

19 Miten hyväksymistestaus järjestetään? loppukäyttäjät Vaihtoehto Hyväksymistestaus 1.1 Hyväksymistestaus virheitä Sprint 1 Sprint 2 Vaihtoehto 2 Sprint 1 Julkistus Sprint 2 Julkistus Vaihtoehto virheitä Sprint 1 Sprint 2 Kniberg H.,

20 Listalla Tehtävänä Tehty Burndown-arvio Suunnittelemattomat Seuraava sprintti Seinätaulun käyttö Kniberg H., 2006 /

21 Listalla Tehtävänä Tehty 70 Burndown-arvio Liikaa suunnittelemattomia töitä Työtä jäljellä (story points) Tammi Helmikuu 2006 Sprintille varatut työt saadaan tehtyä etuajassa. Otetaan lisää seuraavan sprintin työlistasta. Suunnittelemattomat Seuraava sprintti Seinätaulun käyttö Kniberg H., 2006 /

22 Soveltuvat lait ja pohdiskelun aiheita Henkilöiden lisääminen myöhässä olevaan projektiin aiheuttaa vain lisää myöhästymistä / no 36, Brooks 1975 laki perustuu OS/360 käyttöjärjestelmäprojektissa saatuihin kokemuksiin lakia voidaan soveltaa suuriin projekteihin, jossa osallistujilta vaaditaan sovellusalueen tietämystä miksi näin on? uusien henkilöiden koulutus projektin töiden jakaminen uudelleen (re-partitioning) vaikuttaa rikkovasti projektiin kommunikointikustannukset kasvavat (n 2 )

23 Soveltuvat lait ja pohdiskelun aiheita Milloin tuo edellä esitetty Brooksin laki ei välttämättä pidä paikkaansa? Van Genuchten ja Hatton esittelevät paperissaan uuden mittarin, ohjelmiston hyöty (software mileage). Mitä sillä tarkoitetaan ja mihin sitä voidaan käyttää?? Mitä yhteistä näet ansaitun arvon arviossa ja Scrumin Burndown arviossa? Van Genuchten M. and Hatton L., Software Mileage, IEEE Software, vol 28, no 5, 2011, pp