Evidence-based scheduling, aneb jak vylepšit odhady dokončení projektů

Na ACM Queue vyšel rozhovor s Joelem Spolskym. Těm, kteří trochu čtou Joelovy články, nepřinese asi nic opravdu nového, až na jeden bod: myšlenku evidence-based scheduling.

Jde o to, jak odhadovat časy dokončení projektů. "Klasický" systém je jednoduchý – rozdělit projekt na jednotlivé úkoly (malé, v řádu hodin), těm přiřadit odhadovanou délku práce, časy sečíst a výsledek "napasovat" do kalendáře. Výsledkem je datum dokončení, které můžete jít oznámit šéfovi či klientovi.

Problém je, že čas přiřazený úkolům je jen odhad. A odhad může být špatný, obvykle podceněný. Ve skutečnosti totiž nejste schopni říct "funkci X naprogramuju za 8 hodin", ale spíš něco jako "je 50% pravděpodobnost, že funkci X naprogramuju za 8 hodin". Při sčítání je pak třeba s pravděpodobnostmi korektně zacházet. Rozhodně totiž neplatí, že dvě osmihodinové funkce s pravděpodobností 50 % zvládnete na 50 % za 16 hodin – pravděpodobnost u součtu bude nižší.

Idea evidence-based schedulingu je v tom, sledovat, jak vám jednotlivé odhady průběžně vycházejí, a získávat tak rozložení pravděpodobnosti plnění úkolů v odhadnutém čase. (Rozložení bude pravděpodobně jiné pro každého člena týmu a pro každou délku odhadu – delší odhady budou mít "placatější" křivku.) Při tvorbě výsledného součtu je pak jen otázka trochy matematiky spočítat pravděpodobnostní rozložení data dokončení celého projektu. Ve výsledku je pak možné říct něco jako: "Projekt dokončíme na 75 % na konci ledna, na 99 % pak v polovině března."

Zdá se vám tato myšlenka zajímavá? Mě docela ano. V rozhovoru je naznačeno, že je implementována v Joelově bug-tracking systému FogBugz, ale v principu není vůbec složité ji vestavět do jakéhokoliv podobného systému, kde je možné sledovat časy úkolů. Nechtěl by si nějaký matfyzák pohrát a doimplementovat podporu této funkce třeba do Bugzilly nebo Tracu? Myslím, že je to dobrý námět na ročníkový projekt nebo zápočťák, který by nebyl "do šuplíku", ale opravdu k něčemu.