Derrick és Harry Projektmenedzsment Blogja

A becslésről - 2. rész

2012. január 04. - TanacsLajos

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!

 

A bejegyzés trackback címe:

https://derrickesharry.blog.hu/api/trackback/id/tr683519968

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

attilakristo3d · http://www.missingcloud.com 2012.09.10. 02:53:13

Ez is remek post. Érdeklődve várom a harmadik részt :)

TanacsLajos 2012.09.12. 18:59:43

Hű, jogos a megjegyzés, a harmadikkal még tartozom! Hamarosan megszüljük, ígérem, a kedves szavakat köszönjük! :)

JeeDay · http://etelkep.blog.hu 2012.11.06. 21:46:58

A létező legjobb szakkönyv a témában szerintem, mindenkinek ajánlom, sokat segít: www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
süti beállítások módosítása