Webtown blog

Gondolataink cikkekbe rendszerezve

null A forecast a szoftverfejlesztésben

Vrana Zoltán

A forecast a szoftverfejlesztésben

Gondolatok és tapasztalatok a szoftverfejlesztési projektek forecast-folyamatai kapcsán.

Mi a forecast?

A forecast a szoftverfejlesztésben olyan, mint az időjárás jelentés, időjárás előrejelzés.
Amikor azt mondja az időjós, hogy másnap 10 fok lesz, akkor ezen információ alapján el tudjuk dönteni, hogy milyen ruházatot fogunk felvenni. Ha még az is elhangzik, hogy az eső valószínűsége 50%, akkor lehet, hogy még az esernyőnket is betesszük a táskánkba.

Másnap, amikor kilépünk az ajtón kiderül, hogy csak 8 fok van és az eső nem esik. 
Olyan is előfordulhat, hogy feleslegesen cipeltük egész nap az esernyőnket, mert egyáltalán nem esett. Sőt, van, hogy egyáltalán nem jön be az előrejelzés.

A tévedés mértéke a hőmérséklet esetén 20%, de mégsem gondoljuk azt, hogy előző nap becsaptak volna bennünket, mert tudjuk, hogy az időjárást pontosan előre jelezni nem egyszerű dolog. Inkább hálás vagyunk, mert a kapott információ segített bennünket a döntéshozatalban. 
A szoftverfejlesztésben a forecast pont ilyen.

Természetesen feltehető az a kérdés, hogy miként hoztunk volna döntést, ha nincs az előrejelzés? Ugyanis minden nap hozunk döntést anélkül, hogy folyton néznénk az időjárás jelentést. Ilyenkor tapasztalati alapon döntünk, de ehhez szükségünk van valamilyen szintű ismeretre, tapasztalatra. Jellemzően ilyen esetben az adott évszak általános időjárási viszonyai, illetve az előző néhány nap időjárása alapján döntünk. Ismeret és tapasztalat!
Ugyanakkor tudjuk, hogy így sem döntünk mindig jól, mint ahogy a forecast sem helyes minden esetben. Az előrejelzés extrém módon változó környezetben, kevés rendelkezésre álló adat mellett az esetek nagy részében pontatlan lesz, nincs olyan, hogy pontos előrejelzés.
A szoftverfejlesztésben a forecast pont ilyen.

Milyen szituációk szoktak előfordulni a szoftverfejlesztés során, amelyek kapcsolatba hozhatók egy feladat méretével?

  • sales fázisban ajánlatot szeretnénk adni és az ajánlatkérő pontos összeget és határidőt vár az ajánlatban
  • szeretnénk tudni, hogy egy adott követelmény halmaz mekkora fejlesztést jelent
  • nem tudjuk, hogy egy adott idő alatt egy adott méretű követelmény halmaz befutható-e
  • elég kicsi-e egy adott backlog elem ahhoz, hogy sprintbe tudjon kerülni, azaz bontani kell-e vagy sem

Mire jó a forecast?

Ahhoz, hogy a forecast jó legyen valamire, fontos, hogy értsük a kimenetét. Értsük azt, hogy mire tudjuk felhasználni, de mindenek előtt meg kell, hogy értsük, hogy mire nem jó a forecast.

Arra nem jó, hogy pontosan megmondjuk egy adott követelményről, hogy hány óra és hány perc szükséges a lefejlesztéséhez. Nem jó arra sem, hogy megmondjuk mikorra tudunk egy adott követelmény halmazt leszállítani.

Amire jó az az, hogy visszajelzést kapjunk egy szakértő csapattól, hogy a különböző szintű, típusú és méretű követelmények egymáshoz képest mekkorák, vagyis relatív méretezést kapunk. Megtudhatjuk, hogy a bemeneti infók alapján melyik a legkisebb követelmény, és melyik a legnagyobb. Megtudhatjuk, hogy mely követelmények hordozzák a legnagyobb kockázatot.
A forecast kimenet alapján lehet egy nagyságrendi érzésünk, hogy az összes forecast-olt követelmény körülbelül mekkora.


Mit csinálunk a forecast során?

Product Owner-ként rá kell érezzünk arra, hogy egy fejlesztő csapat számára milyen típusú és részletezettségű információkra van szükség ahhoz, hogy forecast-olni tudjon. Azaz melyek azok a kulcsmondatok, amelyek segítik a megértést és a forecast-olást.
Ez nem szól másról, mint a forecast várható eredményének minőségéhez, ha úgy tetszik, akkor a kimenet pontosságához optimalizáljuk a befektetett energiát. Ha így teszünk, akkor minimalizálni tudjuk a veszteségünket (készletezés elkerülése) és kontrollálni tudjuk a kapacitásaink felhasználását. Ez igaz a felkészülésre és igaz magára forecast eseményre is!

Development team tagjaként pedig el kell fogadjuk, hogy a forecast során nem kapunk minden részletre kiterjedő információt, és ezen nagyon kevés információ alapján kell egy relatív méretet meghatározni.

Scrum Master-ként mind a PO-t, mind pedig a DEV team tagjait segítenünk kell, hogy számukra a lehető legkomfortosabb legyen a forecast esemény. Segíthetjük a PO-t a felkészülésben is. A moderálás szintje attól függ, hogy a résztvevők milyen tapasztalatokkal rendelkeznek.

Mi kell ahhoz, hogy a forecast hatékony legyen?

Az egyik legnagyobb kihívás az, hogy a várható kimenethez képest arányos energiát fektessünk a forecast-ba, mind a felkészülésbe, mind magába az eseménybe.

A saját tapasztalataink szerint a recept az alábbi:

  • végy egy felkészült Product Owner-t, aki hozza az epic-eket és tudja azt a 2-5 kulcsmondatot, amely jellemzi az adott epic-et
  • végy egy fejlesztő csapatot, akik képesek arra, hogy egy skálán relatív elhelyezzék az epic-eket; képesek arra, hogy olyan kérdéseket tegyenek fel, amelyek a forecast szintjén tartják a beszélgetést
  • végy egy moderátort, aki képes a forecast eseményt moderációjával mederben tartani, mondjuk egy Scrum Master-t
  • kell egy, az epic-ekhez passzoló forecast méretskála (a Product Owner és a Scrum Master akár előzetesen egyeztethetik, meghatározhatják)
  • célszerű az alábbi információkat is biztosítani a forecast bemeneteként, mivel ezek hordozhatnak olyan elvárásokat, amelyek befolyásolják a forecast kimenetét
    • feltételezett Definition of Done: ha ez nem áll rendelkezésre, akkor értenünk kell, hogy mit jelent, ha később állnak elő ezek az információk
    • feltételezett szállítási folyamat: ha ez nem áll rendelkezésre, akkor értenünk kell, hogy mit jelent, ha később állnak elő ezek az információk

 

Milyen hibákat követhetünk el a forecast során?

  • ha a Product Owner nem készül fel a forecast-ra: a rendelkezésére álló követelmények, információk emészthetetlen formában állnak rendelkezésre, és így kerülnek a fejlesztő csapat elé
    • túl sok/túl részletes információ átadása
    • eltérő részletezettségű epic-ek
    • az epic-eknek logikátlan sorrendben való forecast-olása
  • ha a forecast során a résztvevők fel akarják tárni az adott epic részleteit, már-már sprintready backlog elemek létrehozása felé megy a forecast - saját tapasztalatok alapján egy-egy epic-re nagyjából 1-3 percet érdemes fordítani
  • hibázunk, ha valaki nem érti, és/vagy nem tudja kezelni a forecast kimenetét és olyan célokra használja, amelyre nem alkalmas a forecast
  • PO konkrét kerettel érkezik és befolyásolni akarja a forecast kimenetét vagy a legrosszabb, szeretné beszorítani a DEV team forecast-ját egy adott keretbe

 

A fentebb leírtakból könnyen kiolvasható, hogy a forecast legkevésbé sem egyszerű.

Odafigyeléssel azonban lehet jól csinálni.

A kimenete pedig egyaránt hasznos a Scrum team, a Product Owner és a stakeholderek mellett az egész Scrum projekt és a megrendelői, vállalkozói oldal minden képviselője számára.