% Ohjelmistotuotanto % Matti Luukkainen ja ohjaajat Antti, Pooki, Riku, Sini, Taneli % syksy 2024

Luento 4

8.11.2024

Kurssipalaute

Kurssipalaute
- Kurssilla lopussa kerättävän palautteen lisäksi ns. jatkuva palaute https://norppa.helsinki.fi

Luennot
- huomenna klo 12-14 B123
- ensi viikosta alkaen ma ja ti 12-14 B123
Pajaa salissa BK107
- ma 14-16
- to 13-15
- pe 12-14 (huomenna poikkeuksellisesti klo 14-16)

Miniprojektit

Käynnistyvät 11.11 alkavalla viikolla
Ilmoittautumisen deadline su 10.11. klo 23.59
Aloitustilaisuudet
- ti 14-16
- ke 14-16
- ke 16-18
- to 10-12
- to 14-16
Seuraavat viikot: sprinttien katselmus ja suunnittelu samassa aikaikkunassa
Loppudemot
- ke 11.12. klo 12-14 B123
- to 12.12. klo 12-14 CK112

Nopea kertaus eiliseltä

User story
- description
- conversations
- acceptance criteria
. . .
Hyvä user story: INVEST

. . .
Estimointi
- Miksi? Kuka? Miten?

. . .

Product Backlog
- Kuka vastuussa?
- Miten saadaan projektin alussa muodostettua?

Hyvä product backlog on DEEP

Mike Cohn lanseerasi lyhenteen DEEP kuvaamaan hyvän backlogin ominaisuuksia
- Detailed appropriatly
- Estimated
- Emergent
- Prioritized

Estimated, Prioritized

. . .

Detailed appropriately eli sopivan detaljoitu
- ylempänä tarkkoja
- alempana suurpiirteisempiä

{ width=350 }

Emergent kuvaa backlogin muuttuvaa luonnetta:
- uusia storyja tulee
- vanhoja poistetaan, uudelleenpriorisoidaan ja uudelleenestimoidaan, muokataan ja pilkotaan

. . .

Muuttuvan luonteen takia backlogia tulee hoitaa projektin edetessä (engl. backlog refinement/grooming)
- Pääasiallinen vastuu on product ownerilla
- Backlogin hoitamiseen osallistuu koko kehitystiimi
- Scrum suosittelee että noin 10% sprintin työajasta käytetään backlog refinementiin

"Ready" story ja epiikki

Hyvä story on siis INVEST (independent, negotiable, valuable, estimable, small, testable)
DEEP taas taas sanoo, että backlogin pitää olla sopivan detaljoitu

. . .

INVEST päteekin vain backlogin korkeamman prioriteetin storyihin
- Joskus sanotaan että story on ready, kun se on valmiina toteutettavaksi (hyvin tunnettu ja INVEST)

. . .

Alemman prioriteetin storyt voivat olla epiikkejä (epic)
- scope ei tiedossa, ei mielekästä estimoida

Velositeetti

Estimoinnin yksi tarkoitus on mahdollistaa koko projektin viemän aikamäärän summittainen arviointi

. . .

Estimoinnin yksikkönä on abstrakti käsite story point, miten sen avulla voidaan arvioida projektin kestoa?

. . .

Kehitystiimin velositeetti (engl velocity) tarjoaa osittaisen ratkaisun tähän
Velositeetilla tarkoitetaan tiimin keskimäärin yhdessä sprintissä toteuttamien story pointtien määrää

. . .

Jos velositeetti selvillä ja toteutettavaksi tarkoitetut storyt estimoitu, projektin keston arvio on helppo laskea

(storyjen estimaattien summa) / velositeetti * sprintin pituus

Projektin alkaessa velositeetti ei ole selvillä, ellei kyseessä ole jo yhdessä työskennellyt tiimi

. . .

Velositeetti vaihtelee alussa melko paljon
- Estimointi aluksi vaikeampaa varsinkin jos sovellusalue ja käytetyt teknologiat eivät ole täysin tuttuja

{ width=300 }

. . .

Velositeetti ja siihen perustuva projektin keston arvio alkaakin tarkentumaan pikkuhiljaa

Ketterissä menetelmissä on oleellista kuvata mahdollisimman realistisesti projektin etenemistä

. . .

Velositeettiin lasketaan mukaan ainoastaan definition of donen mukaisesti toteutetut storyt
- "lähes valmiiksi" tehtyä työtä ei katsota ollenkaan tehdyksi

{ width=350 }

Burndown

Projektin etenemistä kuvataan joskus release burndown -kaavion avulla

. . .

{ width=350 }

Burndown

Projektin etenemistä kuvataan yleensä release burndown -kaavion avulla

{ width=350 }

Burndown

Projektin etenemistä kuvataan yleensä release burndown -kaavion avulla

{ width=350 }

Burndown

Projektin etenemistä kuvataan yleensä release burndown -kaavion avulla

{ width=350 }

Burndown

Projektin etenemistä kuvataan yleensä release burndown -kaavion avulla

{ width=350 }

Burndown

Projektin etenemistä kuvataan yleensä release burndown -kaavion avulla

{ width=350 }

Burndown

Projektin etenemistä kuvataan yleensä release burndown -kaavion avulla

{ width=350 }

Kannattaako estimointi? #NoEstimates

Storyjen viemän työmäärän arvioimiseen kaksi motivaatiota
- auttaa asiakasta priorisoinnissa
- mahdollistaa koko projektin tai kokonaisuuden viemän ajan ja kustannuksen arvioinnin

. . .

Story point -pohjainen suhteellinen estimointi on saavuttanut vankan aseman
- Scrum guide mainitsee että backlogin vaatimukset estimoituja
- Samoin kuten monet parhaat käytänteet kuten DEEP

. . .

#NoEstimates-liike ruvennut kyseenalaistamaan story point -perustaista estimointitapaa
- pitää siitä saavutettuja hyötyjä liian vähäisinä verrattuna käytettyyn aikaan ja vaivaan

. . .

Yksinkertainen vaihtoehto: arvioidaan velositeetti laskemalla kussakin sprintissä valmistuneiden storyjen lukumäärä

. . .

Toimii jos storyt riittävän tasakokoisia?

Tauko 10 min

Sprintti

Sprintin suunnittelu

Kertauksena alkuviikolta: Scrum määrittelee pidettäväksi ennen jokaista sprinttiä suunnittelupalaverin

. . .

Palaverin ensimmäinen tavoite on selvittää mitä sprintin aikana tehdään
- Lähtökohtana DEEP product backlog

. . .

Product owner esittelee backlogin kärjessä olevat vaatimukset
- Tiimin on tarkoitus olla riittävällä tasolla selvillä mitä vaatimuksilla tarkoitetaan

. . .

Tiimi valitsee niin monta storyä kuin se arvioi kykenevänsä sprintin aikana toteuttamaan definition of donen laadulla

Sprintin tavoite

Suunnittelun yhteydessä määritellään sprintin tavoite (goal)
- Lyhyt, yhden tai kahden lauseen kuvausta siitä, mitä tiimi on aikeissa sprintin aikana tehdä

. . .

K. Schwaber, ensimmäisen sprintin tavoite: demonstrate a key piece of user functionality on the selected technology

. . .

Verkkokaupan sprinttien tavoitteita voisivat olla:
- Ostoskorin perustoiminnallisuus: tuotteiden lisäys ja poisto
- Ostosten maksaminen ja toimitustavan valinta

. . .

Lyhyt kuvaus parempi niille sidosryhmäläisille, joita ei kiinnosta seurata tapahtumia yksittäisten storyjen tarkkuudella

Sprintiin valittavat storyt

Sprintin tavoitteen asettamisen lisäksi tulee valita backlogista sprintin aikana toteutettavat storyt
- Kehitystiimi päättää kuinka monta storya sprinttiin otetaan

. . .

Jos velositeetti on selvillä, on valinta periaatteessa helppo

{ width=230 }

Jos velositettia ei tiedossa, käytetään harkintaa

Product owner voi vaikuttaa sprinttiin mukaan otettaviin storyihin tekemällä uudelleenpriorisointia

{ width=230 }

Entä jos myös D halutaan sprinttiin?

Uudelleenpriorisoidaan

{ width=250 }

. . .

Entä jos myös C halutaan mukaan?

Pienennetään A:n kuvaamaa toiminnallisuutta

{ width=280 }

. . .

Entä jos A ei saa pienentyä

Jaetaan A kahteen osaan

{ width=280 }

Tärkeämpi osa toiminnallisuutta eli A1 mahtuu mukaan sprinttiin, vähemmän tärkeät osat eli A2 jää myöhempiin sprintteihin

User storyjen jakaminen useampaan osaan

Haastava aihe, palataan siihen tänään jos aikaa jää
Kurssinmateriaalissa jonkin verran ohjeistusta asiaan
Pääperiaate: jakamisessa syntyvien storyjen edelleen noudatettava INVEST-kriteerejä

Miten sprintin tavoitteeseen päästään?

Sprintin suunnittelun yhteydessä sprinttiin valituille user storyille tehdään karkean tason suunnittelu

. . .

Mietitään mitä teknisen tason tehtäviä (task) on toteutettava, jotta user story saadaan valmiiksi

. . .

Suunnitellaan komponentteja ja rajapintoja karkealla tasolla

. . .

Huomioidaan uusien storyjen aiheuttamat muutokset olemassa olevaan osaan sovelluksesta

Storyn jako taskeihin, esimerkki

Esimerkiksi tuotteen lisääminen ostoskoriin, voitaisiin jakaa seuraaviin teknisiin taskeihin:
- sessio, joka muistaa asiakkaan tila
- oliot ja tietorakenteet ostoskorin ja ostoksen esittämiseen
- laajennus tietokantaskeemaan
- html-näkymää päivitettävä tarvittavilla painikkeilla
- kontrolleri painikkeiden käsittelyyn
- yksikkötestit kontrollerille ja ostoskorin logiikalle
- hyväksymätestien automatisointi

. . .

Kaikkia storyyn liittyviä taskeja ei sprintin suunnittelun aikana löydetä
- Uusia taskeja generoidaan tarvittaessa sprintin edetessä

Sprint backlog

Sprint backlog koostuu sprintiin valituista storyista ja niihin liittyvistä tehtävistä eli taskeista

. . .

Sprint backlog usein organisoitu taskboardiksi

{ width=250 }

Taskit niiden valmistumisastetta kuvaavassa sarakkeessa

Sprint backlogin työmääräarviot

Sprintissä arvioidaan päivittäin kunkin taskin jäljellä olevaksi arvioitua työmäärää
- Usein tapana tehdä arviot tunteina

. . .

{ width=400 }

Sprintin burndown etenemisen seurantaan

{ width=450 }

Kannattaako taskeille tehdä työmääräarviot?

A Scrum book 2019 ei suosittele taskien tasolla tehtävää työmääräarviointia
- Kehottaa seuraamaan sprinttien aikana ainoastaan sitä kuinka monen story pointin verran storyja saatu valmiiksi

. . .

On mahdollista, että tiimi saa sprintissä valmiiksi lähes kaikki taskit, saamatta valmiiksi yhtäkään storya
- Burn down voi näyttää pitkään melko hyvältä, mutta asiakkaan saama arvo on lopulta nolla

. . .

Yksinkertainen tapa sprintin etenemisen seurantaan
- laske, tai katsoa taskboardilta, mikä on jo valmiiden ja vielä valmistumattomien sprinttiin kuuluvien taskien lukumäärä

Joskus Sprinteissä ...

{ width=350 }

Joskus Sprinteissä käy näin

{ width=350 }

Puolivalmis työ kasautuu ja asiat eivät valmistu

{ width=350 }

WIP-rajoitteet

Yhtä aikaa työn alla olevien taskien suuri määrä voi koitua ongelmaksi
- Riski sille, että sprintin päätyttyä paljon osittain valmiita storyja kasvaa

. . .

Ratkaisu: work in progress eli WIP -rajoitteet

{ width=300 }

Kanban ja Lean

WIP-rajoitusten idea on peräisin Kanban-menetelmästä, joka on eräs keskeisimmistä Lean-ajattelun työkaluista
- Lean-ajattelu on peräisin jo kymmeniä vuosia vanhasta Toyota Production Systemistä

. . .

Lean-ajattelun taustalla on idea hukan eli asiakkaalle arvoa tuottamattomien asioiden eliminoimisessa

. . .

Toiminnallisuudet tuovat arvoa vasta käytössä, sitä ennen ne sitovat turhaan kustannuksia ja tuovat riskejä

. . .

Hukkaa muun muassa: osittain tehty työ, välivarastointi ja turha odottaminen

WIP-rajoitteiden soveltaminen

WIP-rajoitteita voidaan soveltaa Scrumin yhteydessä monella tavalla

. . .

Aika tavallista on rajoittaa eri työvaiheessa, esim. toteutuksen olevien taskien määrää

. . .

tai yksittäisellä sovelluskehittäjän kerrallaan työn alla olevien töiden määrää

. . .

Järkevintä lienee rajoittaa sprintin aikana yhtäaikaa työn alla olevien storyjen määrää mahdollisimman pieneksi

. . .

WIP-rajoitteita säädetään usein retrospektiivien yhteydessä jos kehitystyössä havaitaan ongelmia

Storyjen jakaminen

Haastava aihe aloittelijalle ja joskus myös kokeneille ohjelmistokehittäjille
Pääperiaate: jakamisessa syntyvien storyjen edelleen noudatettava INVEST-kriteerejä
Richard Lawrencen ohjeita

Pattern 1: business rule variations

As a user, I can search for flights with flexible dates.

. . .

kannattaa jakaa siten että jokainen näistä ehdoista eritellään omaksi storykseen

... as "between dates x and y"
... as "a weekend in December"
... as "± n days of dates x and y"

Pattern 2: simple/complex

As a user, I can search for flights between two destinations

. . .

voidaan jakaa seuraavasti

... when only direct flights used
... specifying a max number of stops
... including nearby airports
... using flexible dates

Pattern 3: major effort

As a user, I can pay for my flight with VISA, MasterCard, Diners Club, or American Expres.

. . .

voitaisiin jakaa kahtia, missä ensimmäisessä storyssa vasta hoidettaisiin yksi luottokorttityyppi, ja seuraava story yleistäisi toiminnan kaikkiin kortteihin:

... I can pay with VISA
... I can pay with all four credit card types (VISA, MC, DC, AMEX) (given one card type already implemented)

Pattern 4: data entry methods

As a user, I can search for flights between two destinations

. . .

jakaantuukin helposti kahteen esim. seuraavasti

... using simple date input
... with a fancy calendar UI

Pattern 5: Defer Performance

As a user, I can search for flights between two destinations

. . .

jakaantuu kahtia seuraavasti:

... slow—just get it done, show a "searching" animation
... in under 5 seconds

Pattern 6: Operations

As a user, I can manage my account

. . .

jakaantuu moneen osaan

... I can sign up for an account
... I can edit my account settings
... I can cancel my account

Pattern 7: Break Out a Spike

Jos tiimi ei ole toteuttanut koskaan luottokorttimaksuun liittyvää toiminnallisuutta, user storysta

As a user, I can pay by credit card

kannattaa eriyttää aikarajattu eksperimentti joka suoritetaan aiemmassa sprintissä.

Tämän jälkeen toivon mukaan varsinaisen toiminnallisuuden toteuttava story osataan estimoida paremmin:

Investigate credit card processing
Implement credit card processing

Files

4.md

Latest commit

History

4.md

File metadata and controls

Kurssipalaute

Miniprojektit

Nopea kertaus eiliseltä

Hyvä product backlog on DEEP

"Ready" story ja epiikki

Velositeetti

Burndown

Burndown

Burndown

Burndown

Burndown

Burndown

Burndown

Kannattaako estimointi? #NoEstimates

Tauko 10 min

Sprintti

Sprintin suunnittelu

Sprintin tavoite

Sprintiin valittavat storyt

User storyjen jakaminen useampaan osaan

Miten sprintin tavoitteeseen päästään?

Storyn jako taskeihin, esimerkki

Sprint backlog

Sprint backlogin työmääräarviot

Sprintin burndown etenemisen seurantaan

Kannattaako taskeille tehdä työmääräarviot?

Joskus Sprinteissä ...

Joskus Sprinteissä käy näin

Puolivalmis työ kasautuu ja asiat eivät valmistu

WIP-rajoitteet

Kanban ja Lean

WIP-rajoitteiden soveltaminen

Storyjen jakaminen

Pattern 1: business rule variations

Pattern 2: simple/complex

Pattern 3: major effort

Pattern 4: data entry methods

Pattern 5: Defer Performance

Pattern 6: Operations

Pattern 7: Break Out a Spike