Tartsa be a határidőket: módszerek, amelyeket a fejlesztők az erőfeszítések becslésére használnak

Üdv mindenkinek! Hatalmas mennyiségű elmélet van, amelyet ismernie kell ahhoz, hogy elkezdhesse a szoftverfejlesztést. Egyes szakemberek (például a Java és más nyelveket használó háttérfejlesztők) többet tudnak róla, míg mások (például a JavaScriptet és a React Native-t használó frontend fejlesztők) valamivel kevesebbet tudnak. Mindazonáltal mindkét csoportnak nemcsak technikai, hanem "szervezési" ismeretekkel is nagy mennyiségben kell rendelkeznie. Ez a "szervezeti" tudás az egyik átfedési terület a frontend és a háttér-fejlesztők számára. Ma ennek a nem technikai, szervezeti tudásnak egy aspektusáról szeretnék beszélni. Ma az erőfeszítés becsléséről fogunk beszélni . Mert csak az Agilis módszertan használatában van tapasztalatom(amelyet a legnépszerűbbnek tartanak), pontosabban a Scrum keretrendszert, a Scrum kontextusában figyelembe veszem az erőfeszítés becslését . Mindjárt az elején meg kell mondanom, hogy az erőfeszítések becslése nehéz. Számomra ez a fejlesztői munkám egyik legnagyobb kihívást/legkellemetlenebb aspektusa. Számos különböző tényezőt kell figyelembe venni, amelyek befolyásolhatják a feladat elvégzéséhez szükséges erőfeszítések becslését. Ezenkívül a jövőbeli fejlesztési tervek az Ön becslésein alapulnak.

Mi van, ha rossz becslést ad?

Ha egy fejlesztő sokkal több órát becsül egy feladat elvégzésére, mint amennyit végül a feladatra fordít, szakértelme megkérdőjelezhető, mivel a becslés annyira pontatlan volt. Más szóval, vad találgatás volt. Ugyanakkor, ha egy fejlesztő nem végzi el a munkát az előre jelzett időn belül, veszélyezteti az ügyfél azon terveit, hogy kiadja a terméket vagy az új funkciót. Ez üzlet, és az üzlet pénz. Kevés vásárló lesz elégedett egy ilyen csúszással. Valójában ezért nem szeretem a becslést – mert néha rendkívül trükkös pontosan meghatározni a feladat elvégzéséhez szükséges időt.

Hogyan készítsünk időbecslést

A becslések általában órákban vagy történetpontokban készülnek. Személyes preferenciám az, hogy a becslési folyamatot történetpontok felhasználásával végezzem el . Nehéz összetéveszteni a konkrét fizikai tárgyakkal, de a történeti pontok kicsit elvontabbak. A szoftverfejlesztő csapatok általában becsléseket adnak időmennyiségben: órák, napok, hetek, hónapok. Ezek az időbecslések elsősorban személyes tapasztalatokon, találgatásokon és/vagy megérzéseken alapulnak. Ebben az esetben a fejlesztők egyszerűen megnézik a feladatot, és kifejezik feltételezésüket, hogy mennyi időt vesz igénybe. Ennek eredményeként ezek a becslések nagyon ritkán pontosak, mert túl sok tényező befolyásolhatja a munka időtartamát. Ezért sok olyan csapat, amely az Agilis módszertant használja, történetpontokat is használ. Merüljünk el!

Mik azok a történetpontok?

A történetpont egy olyan mértékegység, amely egy bizonyos funkció teljes megvalósításához szükséges teljes erőfeszítés becslését fejezi ki. Vagyis relatívról beszélünkbonyolultság. A csapatok a munka összetettsége, a munka mennyisége, valamint a kockázat vagy a bizonytalanság alapján becslést adnak a történetpontokban. Ezeket az értékeket általában a munka hatékonyabb kisebb darabokra osztása érdekében rendelik hozzá, ezáltal kiküszöbölik a kétértelműséget. Idővel ez segít a csapatoknak megérteni, mit tudnak elérni egy adott idő alatt, és segít nekik pontosabban megtervezni a későbbi munkadarabokat. Ez teljesen ellentmondásosnak tűnhet, de ez az absztrakció valóban hasznos: nehéz döntések meghozatalára készteti a csapatot a munka összetettségével kapcsolatban. Nézzünk meg néhány okot a történetpontok használatára a tervezés során:

• Elkerülheti a pontatlan időbecsléseket.
• Ellentétben az időegységben végzett becslésekkel, a történetpontok lehetővé teszik az általános költségek elszámolását: a csapattagok és az ügyfél közötti kommunikáció, a különböző csoportos megbeszélések és tervezési tevékenységek, valamint az előre nem látható helyzetek.
• Minden csapat más-más skálán értékeli a munkáját, ami azt jelenti, hogy kapacitásuk (pontokban mérve) eltérő lesz.
• Az egyes történetpontok hozzárendelésére szolgáló skála meghatározásával gyorsan, különösebb vita nélkül oszthat ki pontokat.

Hogyan NE használjunk történetpontokat

Sajnos a történetpontokkal gyakran visszaélnek. A történeti pontok félrevezetőek lehetnek, ha emberek értékelésére, részletes határidők és erőforrások meghatározására használják őket, és ha összetévesztik őket teljesítménymérővel. Ehelyett a csapatoknak arra kell használniuk őket, hogy megértsék az egyes feladatok hatókörét/bonyolultságát, és meghatározzák a prioritásokat. Talán a nehezebbnek ítélt részekkel kellene először foglalkozni, hogy azokat még a sprint vége előtt meg lehessen tenni , esetleg későbbre tolva a könnyebb feladatokat. Hadd emlékeztesselek arra, hogy mi a sprint a Scrum módszertannal összefüggésben : Ennek az időtartamnak a hosszát a fejlesztés megkezdésekor határozzák meg, és erről a csapat és az ügyfél megállapodik. Ez lehet két hét vagy egy hónap, vagy bármilyen más időszak. Az erőkifejtést általában minden sprint elején készítik el, hogy megtervezzék a sprint végére elvégezhető munkákat, amikor az elkészült munkát átadják a megrendelőnek. A demó segítségével láthatja előrehaladását a termék fejlesztésében, visszajelzést kaphat az ügyféltől, és a projekt pályáját az ügyfél elképzelései szerint állíthatja be. De elkalandozunk egy kicsit. Térjünk vissza a becslésekhez. Túl szubjektív lenne, ha egyetlen fejlesztő becslést adna az összes feladatra. Tehát ez a folyamat általában csapatmunka. A csapatok számos technikát használhatnak becslések generálására. Ma a legnépszerűbb technikát nézzük meg: a scrum pókert . Ehhez a technikához egy menedzserre van szükség, aki moderátorként fog működni a scrum pókerben . Ez lehet valaki, aki scrum mester vagy esetleg PM .

Mi az a Scrum póker?

A Scrum póker vagy a tervezési póker egy olyan becslési technika, amely megállapodás megkötésén alapul. Főleg az előttünk álló munka összetettségének vagy a szoftverfejlesztési feladatok relatív méretének becslésére szolgál. Azonnal mondom, hogy a scrum pókerelterjedt szoftverfejlesztési gyakorlat, és tudnod kell, miről van szó. Ez általában egy alkalmazást vagy webhelyet foglal magában, hogy megkönnyítse a csapat közös becslését egy adott feladatra vonatkozóan. Hogyan történik ez? A csapat átvesz valamit a lemaradásból (új feladat, néhány funkcionalitás), és röviden megvitatja az ezzel kapcsolatos esetleges buktatókat és egyéb árnyalatokat. Ezután minden résztvevő választ egy kártyát egy számmal, amely tükrözi az összetettségi becslésüket. Ó, még egy dolog, amikor ezeket a becsléseket készítjük, a Fibonacci-sorozatban szereplő számokat használjuk közönséges számok helyett. A fibonacci számok népszerűek a scrum pókerben, mert egyre nagyobb rés van közöttük (egy piramis szintjeihez hasonlít). Egyes feladatok nagyon összetettek lesznek, és nem fogjuk tudni megúszni a kis számú történetpontot. Vannak szokatlan kártyák, amelyek a következő jelentéssel bírnak:

Ismeretlen számú végpont

Végtelenül hosszú feladat

Kell egy kis szünet

Ritkábban használt becslési módszerek:

• Pólóméretek - S, M, L, XL
• Kutyafajták - chihuahua, mopsz, tacskó, bulldog és így tovább (személy szerint ez a legfurcsább mértékegység az erőfeszítés becsléséhez =D)

A csapat ezután összehasonlítja a különböző fejlesztők által ugyanarra a feladatra adott becsléseket. Ha egyetértenek, akkor nagyszerű! Ha nem, akkor a különböző becslések okait (érveit) meg kell vitatni. Ezt követően a csapat együtt dolgozik, hogy egységes becslést alkosson, amelyet többé-kevésbé mindenki elfogad. Akkor miért használják a pókert komoly szoftverprojektek tervezésére? El kell ismerni, hogy ez furcsa. Az a tény, hogy ez a fajta gamification önálló gondolkodásra ösztönzi a csapattagokat, és arra kéri őket, hogy csapattársaikkal egy időben fedjék fel becsléseiket. Ezzel viszont elkerülhető, hogy olyan helyzet alakuljon ki, hogy egyes csapattagok mások véleményétől függjenek. Ha nem így történne, akkor a kevésbé tapasztalt fejlesztők a tapasztaltabb csapattagok becsléseit néznék meg és azokra összpontosítanának, és ez kevésbé hasznosítaná saját becsléseiket. De a becslések egyidejű megjelenítése ezt lényegében lehetetlenné teszi. Atlassian ajánlatokegy scrum póker alkalmazás a tervezési folyamatban való használatra.

Példa az erőfeszítés becslésére

Tegyük fel, hogy csapata a következő skálát hozta létre a történetpontok becslésekhez való hozzárendeléséhez: Scrum pókert játszanak minden egyes feladatnál, és Ön a következőképpen becsüli meg:

• Még soha nem valósított meg hasonló funkciót: +3
• A funkcionalitás átlagos méretű: +2
• A megvalósítás rendkívül összetett lesz: +3
• A funkcionalitás tesztjei nagyon összetettek lesznek: +3

Az egyes összetevőket összeadva összesen 11 történetpontot kapsz, de nincs ilyen kártya, ezért 13-at javasolsz. Egy munkatárs a következő becslést adja a feladathoz:

• Korábban is dolgozott hasonló feladattal: +1
• A funkcionalitás átlagos méretű: +2
• A megvalósítás átlagos bonyolultságú lesz: +2
• A működési tesztek írása átlagos bonyolultságú lesz: +2

Köztes eredménye 7 sztoripont, de ez a szám nem létezik a Fibonacci-sorozatban, ezért a legtöbb hozzávetőleges számmal – 8-cal – küldi be a kártyát. A csapat többi tagja is szubjektív nézeteik alapján becsüli meg. Ezután mindenki felmutatja a kártyáit, és azt tapasztalja, hogy szinte az összes munkatársa 13-ra becsült, kivéve azt az egy fejlesztőt, aki 8-ast javasolt. Ebben az esetben megengedi, hogy beszéljen, és megindokolja alacsonyabb becslését. Tegyük fel, hogy ezt az indoklást kínálja: korábban ugyanazon a feladaton dolgozott, és ez nem olyan nehéz, mint amilyennek látszik. Végül meggyőzi a csapat többi tagját, hogy 13-ról 8 sztoripontra gondolják meg véleményüket, mondván, hogy segíteni fog annak, aki végül elvállalja ezt a feladatot. Vagy talán ő maga fogja megtenni. Mindenesetre nem mindegy, hogy a többiek elfogadják-e az érveit vagy sem, mert így vagy úgy, becslést rendelnek a feladathoz, és a csapat áttér a következőre. Kezdetben a becslések pontatlanok lesznek, csakúgy, mint a következő időszakban (sprint) elvégzendő munka mennyiségére vonatkozó becslések. Végül is ezek a becslések becslések felhasználásával készültek. Egy idő után, talán három hónap múlva, a csapat elkezdi pontosabban becsülni a feladatokhoz szükséges időt, és kiderül, hogy a csapat mekkora átlagos munkamennyiséget tud egy sprintben elvégezni. Ez azonban egy általános terv elkészítésének folyamata a munkakörre vonatkozóan. Főleg az időre összpontosít, de ebben az esetben sok különböző releváns tényező lehet. Tegyük fel például, hogy egy fejlesztő két hétre nyaralni ment. Le kell vágnia egy bizonyos mennyiségű tervezett munkát (tervezett funkcionalitást). Vagy tegyük fel, hogy egy új fejlesztő csatlakozott a csapathoz, de még nem járt teljesen a sebességgel, ezért időt kell hagynia neki, hogy megismerje a projektet egybeépítési folyamat. Ez a projekt összetettségétől függően két hétig tarthat, egy hétig is eltarthat. Ez minden mára! Remélem, némileg javítottam tudását az erőfeszítésbecslésről, amely a szoftverfejlesztés szükséges, nem technikai vonatkozása. Ha mélyebben szeretne belemenni ebbe a témába és a scrum részleteibe, erősen ajánlom, hogy olvassa el Jeff Sutherland "SCRUM" című könyvét. A következményekre nem tudok ígéretet tenni, mert miután elolvastad, idegesítő vágy támad majd scrum mesterré lenni =D