Agilis becslési technikák

Abstract

A munkaigény becslése agilis projektekben alapvetően különbözik a hagyományos becslési módszerektől. A hagyományos megközelítés szerint a becslést “alulról felfelé” módszerrel végezzük: részletezzük az összes követelményt, és becsüljük meg a követelmények teljesítéséhez szükséges egyes feladatokat órákban/napokban, majd ezeket az adatokat használjuk fel a projekt ütemtervének kidolgozásához. Az agilis projektek ezzel szemben “felülről lefelé” megközelítést alkalmaznak: bruttó szintű becslési technikákat használnak a funkciókészletekre, majd fokozatos kidolgozást és gördülő hullámú tervezési módszereket alkalmaznak a feladatszintre való lefelé haladva, “just-in-time” alapon, iteratív módon egyre több részletet tárva fel minden egyes szintről lefelé. Ez az írás az agilis becslés két gyakori technikáját (tervezési póker és az affinitáscsoportosítás) mutatja be, valamint kitér arra, hogy e gyakorlatok eredményei hogyan járulnak hozzá az ütemterv és a költségvetés előrejelzéséhez.

Top-down vs. Bottom-up

A projektek becslésének hagyományos módszere az, hogy a projekt elején több hetet vagy hónapot fordítanak az építendő termék részletes követelményeinek meghatározására. Miután az összes ismert követelményt összegyűjtötték és dokumentálták, elkészíthető egy Gantt-diagram, amely a követelmények teljesítéséhez szükséges összes feladatot mutatja, az egyes feladatok becslésével együtt. Ezután az erőforrások hozzárendelhetők a feladatokhoz, és az olyan műveletek, mint a terhelés és a kiegyenlítés, segítenek meghatározni a végső szállítási határidőt és költségvetést. Ezt a folyamatot alulról felfelé irányuló módszernek nevezik, mivel a termékkel kapcsolatos minden részletet meg kell határozni, mielőtt a projekt ütemezését és költségeit megbecsülni lehetne.

A szoftveriparban az alulról felfelé irányuló módszer alkalmazása a mai változások sebessége miatt súlyos hátrányokkal jár. A változás sebessége azt jelenti, hogy az új fejlesztési eszközök és az új ismeretekhez való hozzáférés sebessége olyan nagy, hogy bármilyen késedelem a szállításban nyitottá tesz a versenyképes alternatívák előtt, és fennáll a veszélye annak, hogy elavult terméket szállítunk (Sliger, 2010).

A felülről lefelé módszer ezt a kulcsfontosságú problémát úgy kezeli, hogy a jelenleg rendelkezésre álló információk felhasználásával bruttó szintű becsléseket készít. A gördülő-hullámos tervezés ezután az új információk beépítésére szolgál, amint azokról tudomást szereznek, tovább finomítva a becsléseket, és a projekt előrehaladtával iteratív módon egyre részletesebben kidolgozva azokat. Ez a módszer, amelynek során csak annyit tudunk meg, amennyi az induláshoz szükséges, és a munka eredményeinek fejlődésével további ismeretek beépítését tervezzük, lehetővé teszi a projektcsapat számára, hogy gyorsan reagáljon a viszontagságokra és a változó piaci igényekre.

Értékelési technikák

A bruttó szintű becslési technikákat az olyan agilis megközelítéseket alkalmazó csapatok használják, mint a Scrum és az Extreme Programming, és ez az írás a két legnépszerűbb technikával foglalkozik: A tervezési póker és az affinitáscsoportosítás. Az alkalmazott becslési egységeket is megvizsgáljuk, mivel ezeknek az egységeknek olyanoknak kell lenniük, amelyek nem téveszthetők össze az idővel.

Tervezési póker

A bruttó szintű becslés legnépszerűbb technikája a Tervezési póker, vagyis a Fibonacci-sorozat használata egy pontérték hozzárendelésére egy funkcióhoz vagy elemhez (Grenning, 2002). A Fibonacci-sorozat egy matematikai számsorozat, amelyet a 13. században vezettek be, és a természet bizonyos formakincsének, például a fák elágazásának magyarázatára használtak. A sorozat úgy jön létre, hogy a két előző számot összeadjuk, hogy megkapjuk a sorozat következő értékét: 0, 1, 1, 1, 2, 3, 5, 8, 13, 21 és így tovább. Az agilis becslés céljából néhány számot megváltoztattunk, így a következő sorozatot kaptuk: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Ezeket a számokat egy játékkártya-készletben ábrázoljuk (lásd az 1. ábrát). A csapattagok “Tervezési pókert” játszanak (2. melléklet), hogy az egyes tételekre pontérték formájában becslést adjanak. A lépések a következők:

• Minden csapattag kap egy kártyakészletet.
• A vállalkozó (aki NEM kap becslést) bemutatja a becslendő tételt.
• A tételt megvitatják.
• Minden csapattag magányosan kiválaszt egy kártyát, amely a becslését képviseli.
• Ha mindenki készen áll, az összes kiválasztott kártyát egyszerre felfedik.
• Ha minden csapattag ugyanazt a kártyát választotta, akkor ez a pontérték a becslés.
• Ha a kártyák nem azonosak, a csapat megvitatja a becslést, hangsúlyt fektetve a szélső értékekre:
  • A legalacsonyabb értéket választó tag elmagyarázza, miért választotta az értéket.
  • A legmagasabb értéket választó tag elmagyarázza, miért választotta az értéket.
• Válasszon újra, amíg a becslések konvergálnak.
• Hosszadalmas vagy “belemerült” beszélgetések esetén a csapattagok egy kétperces időzítővel időzíthetik a vitát, és minden egyes alkalommal, amikor az időzítő lejár, újra választanak, amíg a konverzió meg nem valósul.
• Mindegyik elemnél megismételjük (Cohn, 2006, 56-57. o.).

A Fibonacci-számok használatának több oka is van, méghozzá ebben a formában. Az első az az elképzelés, hogy amint a csapatok kiküszöbölik az időt mint becslési alapot, kevésbé valószínű, hogy több részletet követelnek és kitömik a becsléseket. Ezek a számok ehelyett a relatív méretet jelölik, nem pedig az időt. Ennek eredményeképpen a becslési feladat meglehetősen gyorsan megy. A csapatok általában nagyjából két percet töltenek minden egyes elemmel, így egy 30 tételből álló hátralévő állományt egy óra alatt lehet megbecsülni. Az a tény, hogy a csapatok csak 9 választási lehetőségre (azaz pontértékekre vagy kártyákra) korlátozódnak, szintén segít felgyorsítani a folyamatot.

A szekvencia a kisebb és jobban megértett funkciók esetében is megfelelő részletezettséget biztosít, miközben a nagyobb becslések esetében elkerüli a pontosság hamis érzetét. Például egy magas becsléssel (20 vagy magasabb) rendelkező elem azt jelenti, hogy az elem nagy és még nem jól érthető. Annak megvitatása, hogy az elem 20-as, 19-es vagy 22-es, időpocsékolás lenne, mivel egyszerűen nem áll rendelkezésre elegendő adat. Amint az elem közelebb kerül ahhoz az iterációhoz, amelyben az elemet meg fogják dolgozni, kisebb darabokra lehet bontani, és szemcsésebb számokkal (1-13) lehet becsülni. Az 1-13-as pontbecslésekkel rendelkező tételek általában egyetlen iteráció (1-4 hét) alatt elvégezhetők.

Fontos megjegyezni, hogy a pontok nem azonos jelentéssel bírnak a csapatok között; például az egyik csapat “ötöse” nem egyenlő a másik csapat “ötösével”. Így a pontokból származtatott csapatsebesség nem használható a csapatok közötti termelékenység összehasonlítására.

Affinitási csoportosítás

A becslés még gyorsabb módja, amelyet akkor használnak, ha a becslendő elemek száma nagy, az affinitási csoportosítás. A csapattagok egyszerűen csoportosítják a hasonló méretű elemeket, ami a 3. ábrán láthatóhoz hasonló konfigurációt eredményez. A módszer egyszerű és gyors:

• Az első elemet felolvassák a csapattagoknak, és a falra helyezik.
• A második elemet felolvassák, és a csapatot megkérdezik, hogy kisebb vagy nagyobb-e, mint az első elem; a falon való elhelyezés a csapat válaszának felel meg (a nagyobb jobbra, a kisebb balra).
• A harmadik elemet felolvassák, és a csapatot megkérdezik, hogy kisebb vagy nagyobb-e, mint az első és/vagy a második elem; az elemet ennek megfelelően helyezik el a falon.
• Az irányítást ezután átadják a csapatnak, hogy befejezzék a többi elem affinitáscsoportosítását.

A csapatok dönthetnek úgy, hogy ugyanígy folytatják, a csoport megbeszélése után egy-egy elemet helyeznek el a falon. Gyorsabb megoldás azonban, ha minden csapattag kiválaszt egy-egy elemet, és azt a saját legjobb felfogása alapján helyezi el. Ez úgy történik, hogy a csapattagok párhuzamosan dolgoznak, amíg az összes elemet ki nem értékelték és fel nem helyezték a falra. Viszonylag rövid idő alatt több száz elemet is meg lehet becsülni. Miután minden elem felkerült a falra, a csapat felülvizsgálja a csoportosításokat. Azokat a tételeket, amelyekről valamelyik csapattag úgy véli, hogy rossz csoportba kerültek, megvitatják, és adott esetben áthelyezik.

Amint az affinitáscsoportosítás befejeződött, a becslési egységértékeket, például a pontokat ki lehet osztani. A 3. ábrán a bal szélső baloldali első csoportot 1 pont értékűként jelölnénk meg, a második csoport 2 pont, a harmadik csoport 3 pont, a negyedik csoport 5 pont, az utolsó csoport pedig 8 pont értékű lenne.

Affinitáscsoportosítás más becslési egységek, például a pólóméretek esetében is elvégezhető. A 4. ábra egy példát mutat a pontok helyett pólóméretekkel jelölt affinitáscsoportosított tételekre.

becslési egységek

A pólóméretek (Extra Small , Small , Small , Medium , Large , Extra Large ) használata egy másik módja annak, hogy a jellemzők relatív méreteire gondoljunk. Ez még nagyobb eltérést jelent a numerikus rendszertől, és mint minden jó bruttó szintű becslési egységet, semmiképpen sem lehet egy adott időtartamhoz kötni.

Az egyéb önkényes mértékegységek közé tartoznak a gumimacik, a NUTS (Nebulous Units of Time) és a lábkilók. A csapatok létrehozhatják saját becslési mértékegységeiket, és mint láthatjuk, gyakran jól szórakoznak ezen.

Ez a dokumentum nem foglalkozik az időalapú mértékegységek, például az ideális fejlesztési napok és/vagy órák használatával. Ezek már elterjedtek és jól ismertek, ezért magyarázatuk nem került bele. Érdemes azonban megjegyezni, hogy a bruttó szintű becslés sikeresebb lehet, ha függetlenítjük az idő fogalmától. Mivel az időbecsléseket a vezetőség és az üzleti élet gyakran kötelezettségvállalásokká alakítja, a csapattagok nagyobb nyomást éreznek arra, hogy a lehető legpontosabbak legyenek. Ennek eredményeképpen egyre több részletet kérnek a becslés tárgyát képező tételről. Ez a bruttó szintű becslést időigényesebb részletszintű becsléssé változtatja, és meghiúsítja az eredeti szándékot és célt.

Az ütemterv és a költségvetés előrejelzése

Mihelyt a bruttó szintű becslések és a csapat sebességének meghatározása megtörtént, az ütemterv és a költségvetés előrejelzése elvégezhető. A csapatok úgy határozzák meg a sebességüket, hogy összeadják az iteráció során elvégzett összes elem összesített pontszámait. Például egy csapat öt elemet választhat ki, amelyek összpontszáma 23 pont (lásd az 5. ábrát). A kéthetes iteráció végére azonban az öt tételből csak négyet tudtak befejezni. A sebességük 15, vagyis az 1-4. tételek pontértékeinek összege. A csapatok nem kapnak “részleges kreditet” a tételek egy részének befejezéséért, így ha el is kezdték volna az 5. tételt, az nem számítana, mivel nem fejezték be.

A menetrend meghatározása

A csapat átlagos sebességét a hosszú távú menetrend előrejelzéséhez használják. Az átlagos sebességet úgy számítják ki, hogy a csapat utolsó három iterációjának sebességméréseit összegzik, és ezt az összeget elosztják hárommal. Ha tehát egy csapat az első iterációban 15 pontot, majd az azt követő két iteráció mindegyikében 20 pontot teljesített, akkor a csapat átlagos sebessége 18 (15+20+20 / 3). Ha egy csapat átlagosan 18 pontot tud elvégezni egy iteráció alatt, és a projektben 144 pont értékű munkát kell elvégezni, akkor a csapatnak nyolc iterációra van szüksége a munka elvégzéséhez (144 / 18). Ha minden egyes iteráció két hét, akkor az előre jelzett befejezés 16 hét. Ez a módszer lehetővé teszi, hogy megválaszoljuk a kérdést: “Mikor leszünk kész ezzel a munkával?”

Ha a csapat rendelkezik sebességadatokkal, akkor meg lehet határozni a legoptimistább befejezési időpontot, a legpesszimistábbat és a legvalószínűbbet. A csapat átlagos sebességszámát a legvalószínűbb forgatókönyv kiszámításához használják, míg a csapat legrosszabbul teljesítő iterációinak sebességszámait a legpesszimistább előre jelzett befejezési dátum kiszámításához. Az olyan iterációk sebességének felhasználásával, ahol a csapat a vártnál többet tudott befejezni, a legoptimistább előrejelzést kapjuk.

Ezeket a számokat arra is használhatjuk, hogy megválaszoljuk a kérdést: “Valamit át kell adnunk erre az időpontra, ezek közül a funkciók közül hányat fogunk addigra befejezni?”. Lásd a 6. ábrán egy példát a legvalószínűbb teljesítésre prognosztizált mennyiségre, a pesszimista előrejelzésre és az optimista előrejelzésre. Ez a példa egy olyan csapatra vonatkozik, amelynek átlagsebessége 20, és amelynek a legrosszabb teljesítési sebessége 12, a legjobb teljesítési sebessége pedig 25. Ebből kiindulva és mindössze hat hét (három iteráció) alatt mennyit lehet befejezni? A pesszimista előrejelzés szerint hat hét alatt csak az 1-8. tételek készülnek el. Az optimista előrejelzés szerint az 1-18. tételek elkészülnek. A legvalószínűbb előrejelzés pedig a csapat 20-as átlagsebessége alapján az, hogy az 1-13. tételek hat hét alatt elkészülnek.

Ha a csapatok nem számszerű becslési egységeket, például pólóméreteket használnának, az előrejelzési algoritmusok összetettebbek lennének. Ajánlott a méreteket numerikus rendszerbe konvertálni, hogy könnyebben lehessen hasonló adatokat generálni. Például a Small-t át lehetne konvertálni NUT 3-asra, a Medium-t NUT 5-ösre, és így tovább. Ezeket át lehet alakítani időtartományokká is (egy Small például 1-3 nap lehetne), de ez eleve kockázatos, a Becslési egységek szakaszban már említett problémák miatt.

A költségvetés meghatározása

Ebben a szakaszban a következő kérdésre keressük a választ: “Csak ennyi pénzünk van – meddig fog tartani, és mennyit fogunk elvégezni, mielőtt elfogy?”. Először is, egy egyszerű képletet használunk az egy pontra jutó költség meghatározására:

Σ (a csapat n időszak terhelt fizetése) / az n időszakban teljesített pontok

Vegyük a csapat fizetésének (terhelt) összegét egy bizonyos időszakra, mondjuk három kéthetes iterációra, és osszuk el a csapat által ugyanezen időszak alatt teljesített pontok számával. Tehát egy olyan csapat, amelynek összes fizetése hat hét alatt 240 000 dollár, és 60 pontnyi munkát végzett a három iteráció alatt, az egy pontra jutó költség 4000 dollár lenne. Most a következő képletet használjuk a költségvetés meghatározásához:

(Pontonkénti költség x az elvégzendő elemek teljes pontértéke) + egyéb költségek = előrejelzett költségvetés

Nagyon gyakran nem minden termékjellemzőt határoznak meg a projekt kezdetén, ami az agilis projektek esetében elvárható. Így a költségvetési becslések azon alapulnak, amit ma tudunk, plusz egy előrejelzési algoritmuson, amely történelmi adatokon vagy szakértői útmutatáson alapul. Tegyük fel például, hogy eddig csak 20 funkció van felsorolva, de az üzlet nem tud további funkcióigényeket vagy finomításokat benyújtani, amíg nem látjuk, hogyan fogadja az ügyfél az első kiadást. A három kiadásra tervezett projekt költségvetése csak az első kiadásra vonatkozóan rendelkezne előrejelzési adatokkal, a teljes projektre vonatkozóan nem. A csapat a fenti algoritmust használhatja az első kiadás költségvetésének előrejelzésére, majd a múltbeli tapasztalatok alapján további 20%-ot feltételezhet a második kiadásra és további 5%-ot az utolsó kiadásra.

A sebességhez hasonlóan a költségvetési előrejelzéseket és az ütemterv-előrejelzéseket is minden iterációban felülvizsgálják. Ez része a gördülő hullámú tervezési folyamatnak, amelyet az agilis projektek alkalmaznak.

Végszavak

Ez az írás nem terjedt ki a strukturált becslési technikák hiányára, amelyeket a lean megközelítésekben, például a kanbanbanban alkalmaznak. Ahelyett, hogy időt töltenének (pazarolnának) az elemek becslésével, az átlagos ciklus- és átfutási időket a csapat tényleges átfutási arányai alapján számítják ki. A Kanban a Little-törvény matematikai tételét használja képletei alapjául. A kumulatív folyamatábrákból származtatott átfutási időszámítások segítségével a csapatok a projekt ütemterveit anélkül prognosztizálják, hogy előzetes becslések készítésére időt fordítanának. Az olvasót arra biztatjuk, hogy végezzen önálló kutatást ebben a témában, ami önmagában is egy különálló dolgozatot alkothatna.

Az agilis projektek célja, hogy egy terméket vagy termékrészleteket korán és gyakran szállítsanak le, hogy az ügyfelek visszajelzéseit és egyéb tanulságokat beépíthessék a következő kiadásba. Azáltal, hogy több időt fordítanak kísérletezésre, kivitelezésre és tanulásra, és kevesebbet a spekulációra, csökken a szállítási ciklusidő. Az agilis csapatok jobban képesek versenyezni a piacon és lépést tartani a változások egyre növekvő sebességével.