A becslések munkaerőköltség - aytishnye kerékpárok

Ismét felmerült a kérdés, mennyire pontosak a becslések idő szükséges a fejlesztés. Ismét megpróbáltam megfogalmazni választ magának.

Először is, „pontos” értékelést nem létezik elvileg. A munkaerőköltség - ez mindig egy véletlen változó függvényében bizonyos valószínűségi eloszlás. Kifelé, úgy néz ki, mint ez.

Ebben a példában, a valószínűsége feladat teljesítésének 4 napig 0,5, 6 nap - 0,75, 8 nap - 0,9.

Én, mint egy igazi gonosz és ostoba szigorú ügyfél itt összekeveri a munkaerő és a teljesítési határidő a feladat, de ebben az esetben nem számít. Az egyszerűség kedvéért tételezzük fel, hogy a feladatot egy személy, aki ad neki minden alkalommal, amíg a feladat befejezése. (Tudod, hogy az ilyen becslések „az egyszerűség kedvéért” semmiképpen nem egyeznek a tényleges projektek tervezése, ugye?)

Amikor mi becsléséhez szükséges munkaerő-költségek, akkor általában meg magunkat néhány hozzávetőleges valószínűség küszöbértéket. Például, ha azt a küszöbértéket 0,9, a mi értékelést kell végezni, átlagosan kilenc alkalommal tízből.

Ez csak egy hozzávetőleges görbe alakja. Nem valószínű, hogy valaki képes lesz megfogalmazni pontosan eloszlásának paramétereit, hogy értékelje a következő feladat. Akkor, persze, próbálja építeni alapján az összegyűjtött statisztikák a már befejezett feladatokat. De a statisztikák valószínűleg hazudik, mert minden folyamatosan változó feltételekhez, amelyek befolyásolják az eloszlás paramétereit.

És itt mi lassan közeledik az első kérdés a becslések pontossága. Az egyik kedvenc kérdése az ügyfelek (és járnak szerepét feletteseik): „Miért van az értékelés mindig rossz, ha úgy dönt, hogy ilyen sok éve ugyanaz a probléma?”

És jellemző, gyakran egyetértünk vele, és az iroda elhagyása után a megrovás, meggyötört magát „és az igazság, és amikor megáll lépve az azonos rake?” Ezt támasztja alá az a nagyszámú „tudományos”, áltudományos és tudománytalan értékelési módjait, hogy úgy találták fel a szoftverfejlesztésben az évek során a létezéséről. Igyekszünk felmérni az összeg a kódot, több yuzkeysov, funkcionális egységek vagy papagájok. Mi szaporodnak a becslések száma „pi” vagy «e». De ez nem kérdés a lényeg: a pontos becslést lehet „számított”, ha megtaláljuk a mágikus formula.

De lássuk csak: nem igazán oldja meg ugyanazt a problémát?

Képzeljük csak el. A mi feladatunk programozó - például, hogy írjon egy függvényt számítani a négyzetgyök. Programozó költött rá, például három nap, egy nap ment a tesztelés és a hibák kijavításával.

A következő hétfőn, tesszük a programozó egy új feladat: írsz egy függvényt számítani a négyzetgyök. És neki négy napig. A szerzett tapasztalatok alapján. Tapasztalatszerzés, programozó végzi el a munkát két napig, hiba nélkül.

Dicsérjük őt és adjon neki egy harmadik feladat: levelet funkciója a négyzetgyök kivonása.

Miután egy pár hónap programozó termelékenység stabilizálódott, és ő képes lesz arra, hogy a három funkció kiszámolja a négyzetgyök naponta. Ennek alapján a teljesítmény, akkor képes lesz arra, hogy egy nagyon pontos értékelést ... Assessment erőfeszítést, hogy írjon egy függvényt számítani a négyzetgyök.

Az abszurditás nyilvánvaló példa, de jól illusztrálja az alapproblémát rejlő legtöbb szempontból erőfeszítést becslés. Programozók nem oldja meg ugyanezt a problémát. Minden feladat egyedi.

Természetesen igen gyakran programozás általános megközelítés konkrét problémák megoldására - mindenféle minták és keretek. Különböző területein programozás lehetnek többé vagy kevésbé rutin feladatokat. De az igazság az, hogy a rutin gyakran automatizált (vagy adott egy tapasztalatlan, fiatal állatok, amely hozzájárul a részesedése a kiszámíthatatlanság), míg a nagy bizonytalanság éppen abban, hogy a probléma része, ami egyedivé teszi.

A zavarása az ügyfél teljes őszinteséggel: az ő szemszögéből, igazán megoldani ugyanazt az üzleti problémákat. Dolgoztam egy nagyon szűk területen csaknem tíz éve - az alkalmazások számára a terminálok, amelyek elfogadják a bankkártyát. És a szempontból az üzleti ügyfelek számára. Mindezen tíz éve megoldottam számtalanszor feltétlenül ugyanazt a feladatot: a „tanítani” a terminál elvégzésére értékesítése a vásárlói kártya. Egy műszaki szempontból, ezeket a problémákat nem olyan, mint a másik. A paraméterek száma, amelyek különböznek óriási: különböző hardver, a különböző nyelvek, a különböző fordítóprogramok, különböző protokollok, különböző felhasználói felületek üzleti ... De ez mind lényegtelen - terminál, vagy végrehajtja a tranzakciót, vagy sem.

Lehetséges, hogy ennek valami köze? Hogyan kell kezelni a bizonytalanság a tervezési projekt?

A leggyakoribb módszer: feküdt a tervezés, amennyire csak lehetséges, és értékelést ad a kockázatokat, amelyek megfelelnek a legmagasabb valószínűsége. Ez a „maximális lehetőséget” határozza meg, az első helyen. fokú arrogancia menedzser és hajlandósága, hogy alkudni a vásárló, másrészt - a mértéke elhanyagolása a paranoia, ami abban nyilvánul meg, figyelembe véve a kockázatokat.

De még ha tudjuk is, hogy egy üzlet értékelésre annak valószínűsége 0,9, ez nem fogja csökkenteni a feszültséget a projektben. Először. minden tizedik távon továbbra is csalódott (és ez biztos, hogy a legfontosabb és igényes feladat). Második. négy esetben a tízből azt megbecsülni túlzottak legalább kétszer (egyszer nézd meg a táblázatot: értékelés valószínűséggel 0,9 kétszerese az a becsült valószínűsége 0,5). És akkor csökkenni fog a viszontbiztosítási díjak, és a csapat - a shirking a munkából.

Sokkal jobb módja annak, hogy foglalkozik a bizonytalanság a saját fegyvere - az elmélet a valószínűség. Sok valószínűségi becslési módszereket, amelyek közül a legtöbb jól ismert (a referenciák száma tankönyvekben) egy módszer PERT. és a legmegbízhatóbb (az én személyes tapasztalat) - Gyakorlat Planning Poker. Bár Agilis hívei, valószínűleg nem gondol valószínűségi rejlő mechanizmusok ezt a módszert, és egyszerűen csak, és nem.

Planning Poker ad pontos becsléseket meglepetés. Tény, hogy az ő segítségével, úgy véljük, a következő értékelést a közös tapasztalat megoldása az összes korábbi problémák és súlyos kockázatokat. De ez lehet sikeresen használni csak jól szervezett csapat tapasztalt fejlesztők (értsd: Agile-team).

A radikális módon megoldani a problémát kínál elmélete korlátok. kritikus lánc módszer magában foglalja teljes elutasítása az értékelések nagy valószínűséggel. Ehelyett azt javasolják, hogy az értékelés elvégzéséhez az egyes feladatok valószínűséggel körülbelül 0,5, amivel a teljes úszó az egész projekt.

De ez a módja nagyon radikális. Betöltéséhez, meg akarja változtatni az általános kultúra a szervezet design.

Szünet. Olvasd újra, lassan töprengett értelmében: szükség van rá, hogy változtatni a teljes kultúra a szervezet design.

Próbálja megbecsülni, hány ember a cég épít munkájukat a modell körül „becslések”. QA tesztel tervek alapján a befejezés várható időpontját a fejlődés ismétléseket. értékesítési osztály magában foglalja ezeket a becsléseket egyetértésben a kliens, de a szerződés nem az úgynevezett „becslések” és a „szállítási idő”. Marketing Osztály bejelenti megjelenési dátuma a következő verzió „verseny gyilkosok” sajtóközleményében. És alatta minden aláírja a főnök.

Most képzeljük el, hogy beszél, hogy ezek az emberek, „A holnap fogunk adni minden becslést valószínűséggel 0.5.”

Nem, mert nem értik. Azt mondják, hogy ez: „A holnap, csak akkor hajtsa végre a fele az ígéreteiket időzítés.”

Mit fog hallani a válasz és a lényege a design kultúra a szervezet.