Hogyan becsülheti meg projektje történetpontjait?

Amikor egy Agilis projekten dolgozik, a csapat történetek létrehozásával megtervezi a munkát a következő sprintekre. A történet egyetlen funkcionalitásba zárt tevékenységet határoz meg leírási és elfogadási feltételekkel.

A sprintek általában két-négy hétig tartanak. Ennyi időn belül a csapatnak meg kell értenie, mennyi tartalmat tud bevinni egy sprintbe, hogy az adott sprintidőn belül még meg tudja tenni.

Egy nem agilis projektnél a munkát általában embernapokban becsülné meg. Ez azt jelenti, hogy hány teljes munkaidős alkalmazottra van szüksége ennek a tevékenységnek a elvégzéséhez? Ebben az esetben a becslések készítésekor mindig gondoljon a napokra és az emberek számára.

Egy agilis projektnél a dolgok másként működnek. A végső becslés kiszámításához már nem kell számolnia a napokat vagy az embereket. Valójában még azt is megtiltjuk, hogy az erőfeszítést embernapokhoz hasonlítsuk. Ehelyett hagyja, hogy a csapat egy általánosan elfogadott értékre konvertálja a történethez, amely az általános becslést fogja képviselni.

Most, hogy pontosan mi az érték, ez nem igazán számít. Igaz, a történetbecslések leggyakoribb képviselői a történetpontok. Ezek alapvetően Fibonacci-számok, amelyek 0, 1, 2, 3, 5, 8, 13, 21 stb.-től kezdődnek. A következő érték az előző két szám összege. Ez segít megkülönböztetni a történet összetettségét, mivel minden következő magasabb szám jelentősen magasabb, mint az előző.

De nem kell ragaszkodnia a történethez. Ez lehet becsült pólóméret (XXS, XS, S, M, L, XL, XXL). Ha igazán kreatív szeretne lenni, bemutathatja az állatkerti állatokat, és felhasználhatja őket méretbecsléshez.

Akárhogy is, most sokkal inkább az egész csapat érzéséről van szó, hogy melyik szám (vagy állat) reprezentálja legjobban ennek a történetnek az összetettségét. Ez határozottan nem az időreprezentációról szól. Végül a csapatnak a sprintben szereplő összes történetet teljesítenie kell. Tehát az idő már az elején adott, és állandó szám.

A történetpontok becslésének összetevői

A történetpont-becslés egyáltalán nem csak arra vonatkozik, hogy egy adott történet mennyire bonyolult/nehéz. A történet becslésekor a csapatnak több szempontot is figyelembe kell vennie, és ezeket tükröznie kell a végső becslési értékben.

A végső becslés ekkor egy olyan érték, amely az összes szempont egyetlen számmá formált kombinációját reprezentálja. Íme, mit kell tartalmaznia egy ilyen becslésnek.

#1. Technikai nehézség

Feltételezve, hogy a történeteket egy fejlesztőcsapat számára becsüljük meg, a történet technikai nehézsége lesz az egyik első olyan terület, amelyre a csapat alapértelmezés szerint koncentrálni fog.

És mindenképpen ez a helyes megközelítés. A műszaki szakértőkkel teli csapatnak kell a legjobban tudnia, hogyan kell értékelni egy történet ilyen területét. Itt a csapat különféle megközelítéseket vagy tippeket mérlegelhet, például:

  • Hogyan hasonlítható össze ez a történet a technikai összetettség szempontjából már bemutatott történetekkel?
  • Hány kódfájlt kell a csapatnak létrehoznia/frissítenie a történet befejezéséhez?
  • Hány további kódmódosítást fog generálni ez a történet a környező rendszerfolyamatokon?
  • Mennyire lesz bonyolult az algoritmus vagy a folyamatlogika megvalósítása?
  A letöltési sebesség korlátozása a Chrome-ban

#2. Külső függőségek és kockázatok

Meglepődnénk, de leggyakrabban a csapat sprintjében a történetek sikere más csapatok vagy a csapaton kívüli személyek hozzájárulásán múlik.

A legkönnyebben megbecsülhetőek azok a történetek, amelyekben minden, amit a csapat képes egyedül megvalósítani. A dolgok bonyolulttá válnak, ha a csapatnak külső segítségre van szüksége a történeteihez. A csapaton kívüli emberek számára ez a tevékenység természetesen nem lesz prioritás. A csapatnak csak számolnia kell ezzel a tényezővel, és figyelembe kell vennie a becslésen belül.

Az, hogy ez a tényező mennyivel növeli a teljes becslést, leginkább a csapat korábbi tapasztalataitól és az „externália szintjétől” függ. Általában egyes sprinteken a csapatban kialakul valami természetes egységes érzés, hogy ez a külső emberektől való függés mennyire megnehezítheti a történet sikeres befejezését.

#3. Újrafelhasználhatósági tényező

A következő megfontolandó terület az, hogy a csapat a meglévő tartalomból mennyit tud újra felhasználni a történet befejezéséhez. Nyilvánvaló, hogy ha néhány alkatrész már így vagy úgy megvan, akkor nem szükséges a nulláról építeni. Ehelyett a csapat újra felhasználhatja a már egyszer elkészített megoldást, hogy sokkal gyorsabban építsen egy újat.

Ily módon ez a tudás csökkentheti a teljes becslést, még akkor is, ha normál esetben (ez az újrafelhasználhatóság nélkül) a történet bonyolultabb lenne a meghatározott tartalom alapján.

#4. A saját csapat megértése

Az egyik figyelemre méltó tényező, amelyet egyetlen embernap alapú becslés sem tud figyelembe venni, az a csapat szolgálati idejének és képességeinek önismerete.

Ahogy a csapat együtt dolgozik és több sprintet teljesít, a bent lévők megismerik egymást. Kezdik megérteni, hogy ki mit tud, és mennyire jó ebben. És ha már mindenki ismeri a csapat többi tagját, akkor ezt együtt, mint csapatot figyelembe vehetik a becslés során.

Ha a történet valamilyen konkrét technikai készségen van, és ez a képesség nagyon erősen jelen van a csapaton belül, akkor a történet egyértelmű megvalósítása nem lesz akkora gond. Vagy fordítva, ha a szükséges képesség hiányzik az egész csapaton belül, akkor a csapatnak lényegesen több időre lesz szüksége, hogy rátérjen a témára, és ezt tükröznie kell a becslésben.

A történet becslése

Minden történetbecslésnek csapatmunka kell, hogy legyen. Egyetlen hang sem határozhatja meg előre a történet összetettségét. A végső cél az kell legyen, hogy a csapat megvitassa a becslést, amíg minden tag meg nem egyezik egyetlen értékben, amely a végső becslést képviseli.

A csapat elvégezheti a becslést közvetlenül a sprint finomítási megbeszélésen (egy olyan találkozón, ahol a történeteket megvitatják és tisztázzák a csapatok), vagy külön időt is szánhatnak erre.

Példa a becslési folyamatra

  • Válasszon egy becslési eszközt a csapat számára, például Planning Pokert, Miro táblát vagy hasonlót.
  • Helyezzen egy történetet a táblára. Hagyja, hogy a csapat megbeszélje a történettel kapcsolatos utolsó gondolatait vagy kérdéseit. Győződjön meg arról, hogy az egész csapat tisztában van a történettel, és készen áll a becslésre.
  • Indítsa el a becslést. Minden csapattagnak választania kell egy számot a Fibonacci skáláról.
  • Miután mindent megbecsült, nézze meg együtt az eredményeket. Indítsa el a vitát. Általában a csapat két-három szám között különül el. Hadd indokolják meg az alsóbb rétegből érkezők, hogy miért kell ilyen alacsonynak lennie a becslésnek. Aztán hadd fejtsék ki a másik végről érkezők, hogy miért legyen ilyen magas a végső becslés. A cél az, hogy minden érvet, megfontolást és tényt lerakjunk az asztalra, hogy az egész csapat egy lapon legyen a történetben foglaltak megértésében.
  • A megbeszélés befejezése után hagyja, hogy a csapat újra becsüljön. A legtöbb esetben a csapat most egy vagy két különböző számra konvertál. Ismételje meg újra a vitát. A konkrét esettől függően vagy a csapat megállapodik a két alternatíva közül a végső számban, vagy Ön dönt egy másik becslési körről.
  • A becslés csak akkor ér véget, ha a csapat minden tagja teljesen rendben van a végső becsléssel. Ennek az egész csapatnak kell megegyeznie, nem csak néhány emberrel. Lehetséges, hogy később minden történetet bárkihez hozzárendelhet a csapatból. Ezért fontos, hogy mindenki egyetértsen abban, hogy mennyire összetett a történet.
  •   14 legjobb megvásárolható Google Stadia-kontroller

    Sprint terv kötelezettségvállalás

    A csapatnak most lemaradása van olyan történetekkel, amelyek már átmentek a becslési munkameneteken. Ideális esetben a történetekhez (a végső becsült értéktől eltekintve) prioritást is rendeltek, hogy a csapat tudja, melyik történet következik a következő sprintben.

    Jön a tervezési munkamenet, ahol a csapat kiválaszt néhány történetet a következő sprinthez. A következő szempontok alapján kell dönteni, hogy mely történeteket válasszuk:

    ✅ A legmagasabb prioritást élvező történetek, amelyeket a csapat elsőként mérlegel.

    ✅ A csapat tapasztalata, hogy egy sprinten belül hány történetpontot tudnak elérni. Ez a tudás csak a csapat idejével és tapasztalatával jön létre. Ennek a képességnek a finomhangolásához és megfelelő megértéséhez több sprintre van szüksége.

    ✅ Nem csak a teljes történetpontszámot és prioritást kell figyelembe vennie. Egy másik szempont az, hogy a csapaton belüli készségek hogyan terjednek el a kiválasztott történetekben. Például, ha a csapatnak csak két előtér-fejlesztője van, előfordulhat, hogy nem csak olyan történeteket választ, amelyek csak előtér-fejlesztést tartalmaznak. Ez a két srác túlzott kihasználásához vezetne, míg a csapat többi tagja nem annyira. A csapat tudása tehát kéz a kézben jár a sprint tartalomkészítés hatékonyságával.

    Sebességfaktor

    Mindenekelőtt a csapat sebessége ül (a közelgő sprintre). Ez a szám semmilyen módon nem kapcsolódik a történetpontok teljes számához. Azt azonban jelzi, hogy a csapat mennyi munkára áll majd rendelkezésre a közelgő sprintre.

    Annak érdekében, hogy pontosan meg tudjuk tervezni a sprint tartalmát, a két szempontot egyesítjük:

  • Csapatsebesség – Napokban mérve. A csapat egy tagja egy teljes napra rendelkezésre áll, a csapat sebességében eggyel egyenlő. Például egy 10 fős csapat, aki teljesen rendelkezésre áll egy 2 hétig tartó sprintre, 100 fős csapatkapacitásnak felel meg.
  • Egy sprint alatt teljesített történetpontok szokásos mennyisége – történetpontokban mérve. Ez a szám korábbi tapasztalatból származik, és szorosan összefügg a csapat sebességével.
  • Időre és gyakorlásra van szükség, hogy megtaláld az édes helyet.

    Előnyök és gyakori hibák

    Meglepő, hogy a csapatok mennyire hajlandóak maguknak bonyolítani az agilis csapattá alakulás folyamatát. Szó szerint úgy érzi, hogy „meg kell szereznie”, mielőtt elkezdhet dolgozni ebben a módban.

      Google Meet vs Zoom: Melyik a jobb

    Sajnos ez az első lépés a legnehezebb is. Bizonyos esetekben ez akár évekbe is telhet, különösen szigorúan konzervatív vállalati környezetben, ahol az idő önmagában elakad az időben.

    Mindenesetre ez fog történni, ha a csapat „megkapja”:

    • Nem kell többé embereket vagy napokat számolnia ahhoz, hogy tudja, mikor lehet valamit befejezni.
    • A csapat megtanulja, hogy csak annyira összetett történeteket alkosson, hogy azok beleférjenek egy sprintbe. Ha egy történet összetettebb, akkor automatikusan több történetre oszlik.
    • A csapat jó becslésekkel rendelkezik minden egyes munkáról, és miután megtervezték a sprintet, pontosan tudja, mikor esedékes.
    • Ez növeli a csapat megbízhatóságát és kiszámíthatóságát.
    • A csapaton belül minden ember „ugyanazon a frekvencián” lesz. Megnéznek egy történetet, és hasonló dolgokat fognak megérteni. Talán egy idő után már nem is veszik a fáradságot, hogy megbecsüljék. A számot a fejükben látják, és mivel mindannyian ugyanazt a számot látják, e kifejezett becslés nélkül is elkötelezhetik magukat a történetek mellett.

    És általában ez történik, ha a csapat még mindig nem tudja megérteni a folyamatot vagy a munkamódszert:

    • Valahogy még mindig ragaszkodnak a régi divatos embernapi becslésekhez. Mindent napokra vagy érintett személyekre konvertálnak. A történetpontok vagy Fibonacci-számok a napok számát jelentik, akár közvetlenül, akár közvetve, különféle átalakításokon keresztül.
    • A vezetés összehasonlítja a csapatokat az egyes sprintekben elért történetpontok száma alapján. Ez akkora baj, amennyire csak lehet. Ekkor egy lényeges tényt nem értünk: minden csapat másképp értékeli a történet pontjait. Egyáltalán semmi ok arra, hogy két csapat szinkronizálására törekedjünk, hogy „ugyanúgy” becsüljék meg történeteiket.
      • Míg az egyik csapat történeti pontja kör rajzolását jelenti, egy másik csapat számára egy lapos tetős, négy ablakos és két ajtós ház megrajzolását jelentheti. És teljesen rendben van.
    • Néha a csapatok hajlamosak szinte mindent 2-4 különböző számra becsülni. Talán mert attól tartanak, hogy egy történetnek 123-as a száma, valaki azt hiszi, hogy ennek köze van a napok számához. De tény, hogy a Fibonacci skála végtelen számú számot tartalmaz. Nem kell csupán 3-as, 5-ös vagy 8-as becslésekre korlátoznunk magunkat. Biztosan megtehetjük (és talán már azzal a céllal hozzuk létre a történeteket, hogy olyan összetettek legyenek, ebben az esetben ez rendben van), de biztosan nem kell.
    • A becslést idősebb emberek hajtják végre, akik előre meghatározzák az egész csoport elvárásait. Soha nem szabad megengednünk, hogy egy csapattag befolyásolja a becslést. Mindenkinek egyenlő joga van véleményt nyilvánítani és meghallgatni.

    Végső szavak

    Az agilis becslésre való átállás a hagyományosabb megközelítésekről nem mindig könnyű, és ehhez igazodni kell – mind a csapatok, mind a fenti vezetés számára. Ahhoz, hogy ez működjön, mindkét félnek meg kell értenie a folyamatot. Ha egyikük nem érti, az átmeneti időszak nehéz út, tele egymásnak ellentmondó elvárásokkal.

    De amint minden átalakul, néhány varázslatos dolog megtörténik. A csapatok jobban meg tudják becsülni és megtervezni munkájukat, a vezetésnek pedig kiszámíthatóbb kiadásai és ütemtervei lesznek, amelyekre támaszkodhatnak.

    Ezután nézze meg az egészségtelen folyamatokat, amelyek tönkretehetik a sprintet.