Az előző részben a becslés általános természetén merengtünk el kissé, most a gyakorlati megközelítésről fogok írni.  Becslésről szóló sorozatunk harmadik, egyben befejező része a becslés lélektanáról, az ahhoz kapcsolódó, már-már a pszichológia témaköréhez tartozó megfigyeléseimről fog szólni.

A gyakorlati megközelítés alatt egyszerűen azt értem, hogyan érdemes nekiállni egy nagyobb feladat erőforrásigényeinek felmérésének. Alapvetően két technikát szoktam használni, a dekompozíciós módszert és a tapasztalaton alapulót, illetve ezek kombinációját.

Feladat lebontás (dekompozíció)

Dekompozíció alatt egy nagy és komplex feladat minél elemibb lépésekre való bontását értjük. Szokták ezt még Work Breakdown Structure-nek nevezni angolul (ne a decomposition-ra keressünk rá, mert az bomlást, rothadást jelent, és végtelenül gusztustalan képekkel szembesülhetünk a Google-ben). Itt lehet elolvasni a történetét és az elméleti hátterét. Fontos megjegyezni, hogy nem a fejlesztendő szoftvert bontjuk szét, hanem a tevékenységeket, amelyek a létrehozásához szükségesek (ebbe beletartozik a fejlesztői környezet létrehozása például).

A dekompozíció fontossága abban rejlik, hogy komolyan csökkenti becslésünk kockázatát, illetve védhetővé válik a becslés. Ki ne szembesült volna már azzal az (általában főnöki) véleménnyel, hogy "Mii??? Mi az, hogy ez a kis feladat 234 embernap??? A mi időnkben megcsináltuk volna egy hét alatt!!" vagy "Az üzlet szerint ez csak egy apró változtatás, és nagyon gyorsan megvan!" Na ezekből a véleményekből lehet hatékonyan kifogni a szelet egy részletesen lebontott feladatlistával.

Ha ilyen egyszerűen megugorható a becslés, akkor miért szoktak annyira félrecsúszni? Nos, rögtön ott szokott kezdődni a dolog, hogy a projektvezető lendületesen kiosztja a fejlesztőknek: "na srácok, eztmegezt a funkciót becsüljétek meg!"

Ebből egyenesen következik a klasszikus viccből is ismert szituáció:

"Na, mennyi?"
"Harminc!"
"Harminc??? Mi harminc?"
"Öö.. mi mennyi?"

Programozást kell becsülni, vagy a tervezést is beleértjük a feladatba? A tesztelés benne van, vagy nincs? És ha igen, milyen típusú? A fejlesztői teszt (egyszer az életben elindítja a programrészt a fejlesztő, nem csak lefordítja), vagy integrációs teszt is (egyszer az életben a programozók összerakják, amit csináltak, és addig kínlódnak integrálnak, amíg el nem indul)? Ezek a tevékenységek többszörösére növelik a feladatot (nem növelhetik, hanem növelik, ne is áltassuk magunkat).

Egy programozó jellemzően csakis azt az időt becsüli meg, amit a kód beírásával tölt (és azt is alul, de erről majd a becslés pszichológiájában írok). A naiv és optimista menedzser meg azt gondolja, hogy ennyiből meg is lesz a feladat, pedig akkor még nem volt beteg senki, nem mentek szabadságra, nem mondott fel senki, nem derültek ki "előre nem látott technikai problémák amit most bonyolult lenne elmagyarázni". Az elemzők/fejlesztők/tesztelők által mondott számok értelmezése és véglegesítése a projektvezető felelőssége! Azzal senki se takarózzon soha, hogy a fejlesztők rosszul becsültek! A becslés helytelensége egy folyamatosan fennálló kockázat minden projektben, aki ezt nem veszi tudomásul és nem kezeli, kudarcra van ítélve.

Figyeljünk arra, hogy minden projekthez kötődő tevékenységet szerepeltessünk a becslésben. A következők szoktak jellemzően kimaradni:

• Fejlesztési környezet előkészítése
• Dokumentációk megrendelő oldali elfogadása (önámítás azt gondolni, hogy ez egy nap!)
• Kész modulok egymáshoz, vagy a megrendelő rendszereihez történő integrációja
• Release-ek kiadása, telepítése, életre lehellése a különböző környezeteken 
• Szállító oldali funkcionális tesztelés és hibajavítás
• UAT és élesítés támogatás ugyancsak szállítói oldalról
• Projektvezetés

Tapasztalat alapú becslés

A tapasztalati módszer arról szól, hogy keresünk egy feladatot, ami hasonló 

• Komplexitású
• Technológiájú
• Üzleti tartalmú

mint a megoldandó, és ahhoz viszonyítva tippeljük meg, mekkora az előttünk álló feladat. Ezt a módszert nem az alapvető becslések kialakításához, hanem a dekompozíciós módszerrel előállt számok visszaellenőrzéséhez szokás inkább használni. Persze minél több tényező tér el a korábbi és a kivitelezendő projekt között, annál kevésbé használható ez a módszer. Nagy eltéréseknél már olyan ez, mint megválaszolni a klasszikus találós kérdést: ha 12 tyúk 8 nap alatt 65 tojást tojik, akkor hány tyúk hány nap alatt hány tojást tojik?

A tapasztalat alapú becslésnél hasznos, ha nem csak azt nézzük meg mi mennyi ideig tartott, hanem azt is, hogy miért? Ha az előző projektben a tervezett két nap helyet hat hétig tartott a telepítés az integrált tesztkörnyezetbe, akkor most sem lesz ez sokkal kevesebb. Önmagában véve a tapasztalat alapú becslést nagyvonalú, a feladat nagyságrendjét mutató becsléshez használjuk inkább: szinte soha nem fordul elő, hogy kétszer ugyanazt a feladatot kelljen megoldanunk, így szembesülhetünk azzal a problémával, hogy nem találunk olyan projektet, amihez a megoldandót hasonlíthatnánk.

A két módszert természetesen nyugodtan kombinálhatjuk, de sose feledjük: biztosan nem az fog történni, amit becsültünk: csupán a feladatok méretét felmérve felkészülünk legjobb tudásunk szerint az előttünk álló kihívások leküzdésére! Ha a dolgok nem a becsléseknek (és így a terveknek) megfelelően alakulnak, ne pánikoljunk, ne a becslést végzőket hibáztassuk, hanem kezeljük a helyzetet: ez ugyanis a projektvezető feladata!