V IT a businessu se spontánnost nenosí. Plánování je alfou a omegou úspěchu. Všichni chtějí vědět, kdy bude projekt hotový a kolik bude stát. CEO, tým (aby si mohl naplánovat dovolenou) a samozřejmě klienti, kteří si projekt objednávají. 

Pokud jako klient máte občas pocit, že váš dodavatel softwaru tahá ty odhady snad z klobouku, pak právě pro vás jsme připravili tento článek. Poodhalíme vám, co za těmi zdánlivě náhodnými čísly stojí a ukážeme 5 nejčastějších metod, které pro vytváření odhadů využíváme i my v Siestě. Navrch poznáte, jak je odhadování riziková a nepopulární činnost a snad svého projekťáka nebudete příště soudit tak přísně, když se původní odhad trochu protáhne.

Co vše obsahuje odhad

Přesný odhad vám na začátku projektu nedá nikdo. Všechny termíny, které dostanete, jsou přibližné. Čím je projekt komplexnější a experimentálnější, tím je odhadování náročnější a rizikovější disciplína.

Kromě samotného vývoje počítá dobrý odhad i s následujícími položkami:

• kapacity lidí v týmu (často pracují na více projektech zároveň, můžou onemocnět, vzít si volno)
• analýza požadavků
• plánování
• architektura projektu
• projektové řízení (15-20 % z celkového odhadu)
• schůzky (interní týmové a ty s vámi jako klientem, obvykle tvoří 10 % z celkového odhadu)
• bug fixing
• rizika
• subdodavatelé a jejich kapacity a fungování
• nástroje a potřebný software
• ostatní zdroje

A kterákoli z těchto položek se v průběhu vývoje projektu může z různých důvodů navýšit. Teď už asi začínáte rozumět, proč je odhadování tak riziková disciplína. A proč podle studie společnosti McKinsey až 66 % vývojových projektů nedostane svým původním odhadům (budget, deadline nebo rozsah). Těší nás, že v Siestě přes všechny nástrahy dodáváme přes 90 % projektů ve slíbeném čase.

Odhady v agilu vs waterfallu

Způsob odhadování se zásadně liší v projektech řízených agilně nebo waterfallem.

Ve waterfallu máte totiž daný rozsah projektu a potom odhadujete čas a náklady. V agilním řízení (které v Siestě využíváme pro 90 % našich projektů) je tomu přesně naopak. 

Projekty řízené metodou waterfallu jsou kvůli svému rigiditě výrazně náchylnější k opožděnému dodání. Stačí totiž jedna překážka, která tým výrazněji zdrží a zpoždění naberou všechny navazující fáze. A pak už se vezete. Tomu se v agilním řízení snadněji vyhnete, protože jednotliví členové týmu ani inkrementy projektu na sebe obvykle tak úzce nenavazují.

Metody odhadování aneb kde se berou ta čísla

A kde se tedy berou ta čísla, která se k vám jako klientům nakonec dostanou? Představíme vám oblíbené metody vývojových týmů a ukážeme vám, které z nich nejčastěji využíváme v Siestě my. Jinými slovy, kde se berou ta čísla, která vám prezentuje váš projektový manažer.

1. Odborný odhad

Nejvíc přímočará a rychlá metoda, jak získat odhad. Má ale svá rizika.

Zeptáme se vývojáře, jak dlouho on sám odhaduje, že mu daný úkol bude trvat. Jde tedy o odhad úsilí.

Potom připočítáme rezervu. Tu k původním odhadům připočítáváme vždycky. Časová rezerva nebo buffer se může pohybovat v řádu 20 až 200 %.

Obecně závisí na:

• Kvalitě odhadu vývojáře. Pokud ze zkušenosti víme, že daný vývojář podhodnocuje své odhady zhruba o třetinu, jednoduše jeho odhad o třetinu vynásobíme.
• Zkušenostech vývojáře. Seniorní vývojáři jsou ve svém odhadu jistější. Vědí už, na co si dát pozor. Odhady juniorních vývojářů bývají nespolehlivé.
• Rizikovosti projektu. Pokud pracujeme s novými technologiemi, řešíme nový problém nebo spolupracujeme s třetí stranou, se kterou nemáme zkušenosti, rezerva se nutně musí navýšit. Čím větší neznámá, tím větší rezerva.
• Velikosti projektu. Čím větší, tím větší rizika, a tím větší rezerva.
• Sebedůvěře projektového manažera. Pokud si co se týče vlastní práce s odhady věří, stačí mu potom připočíst menší časovou rezervu a naopak. 

Psychologicky je totiž mnohem horší “nalákat” klienta na časnější deadline a ten nesplnit než naopak. Psychologické kotvy na náš mozek fungují spolehlivě.

Odborný odhad je nejpřímější metoda. Je ale vhodná jen

• v týmech, které spolu už v minulosti pracovali a znají své pracovní tempo a zvyky;
• v týmech, kde pracují senioři, kteří mají s vlastními odhady zkušenost a vědí, na co si dát pozor.

3. Analogie

Metoda selského rozumu. Pokud jsme již v minulosti podobný projekt vyvíjeli, odrazíme se od jeho náročnosti a zohledníme odlišnosti a projektová specifika.

Protože každý projekt je z definice jedinečný.

Přinejmenším je třeba zohlednit:

• kdo pracuje na projektu – jejich senioritu, motivaci a kapacity
• spolupráci klienta – často nejdéle trvá čekání na podklady

Analogický odhad dává smysl využít, když je tým dobře

• sehraný
• a zkušený.

3. 3-bodová metoda

Velice pravděpodobně od svého projekťáka dostanete odhady rovnou 3.

• Pesimistický (p)
• Optimistický (o)
• Nejpravděpodobnější (n)

Záchytné číslo pro vlastní odhad si potom váš projekťák spočítá následovně:

(p + o + n)/3

(případně vydělí 6 podle váhy, kterou určí n)

Nebo od něj získáte procentuální pravděpodobnost, pro každý scénář.

“S 50% jistotou vám projekt dodáme za 5 měsíců. Pokud se bavíme o 8 měsících, pak máme 80% jistotu. s 90% jistotou ho budeme schopni dodat za 10 měsíců.”

3-bodovou metodu využívají často týmy, které odhadují v pozdních fázích vývoje a předvídají nejistotu. Anebo ty, které s agilní metodou nemají příliš zkušeností.

4. Planning poker

Abychom vám mohli přiblížit metodu planning pokeru, zmíníme se nejdříve o pojmu story point.

Story point je číslo na Fibonnaciho škále (1, 3, 5, 8, 13, 21, 34, …), které reprezentuje komplexitu včetně rizikovosti a potřebné úsilí k dokončení dané user story. Čím vyšší číslo, tím náročnější na úsilí user story je.

Metoda planning pokeru potom vypadá následovně:

1. Projektový manažer zvolí user story, která se bude odhadovat.
2. Tým user story prodiskutuje.
3. Každý člen týmu následně tajně vybere kartu s daným počtem story pointů a připraví ji číslem dolů.
4. Na znamení všichni členové odhalí svou kartu. 
5. Členové s nejnižším a nejvyšším odhadem vysvětlí svůj odhad.
6. Na základě nových perspektiv všichni členové znovu zvolí kartu se story pointy a na znamení ho odhalí.
7. Postup se opakuje, dokud tým nedosáhne konsensu. Cílem planning pokeru není kompromis, ale konsesus.

Planning poker může být někdy zdlouhavý. Je ale skvělým nástrojem pro tým leadery, který podporuje porozumění v rámci týmu.

Hodí se ho využít

• v menších týmech
• a při menším počtu user stories.

5. Měření trička

Jde o jednoduchou metodu vhodnou především pro projekty řízené v Kanbanu.

Měření trička je vhodnou metodou

• pro méně zkušené týmy
• na začátku projektu
• když je třeba jen hrubý odhad

A jak to probíhá?

• Jednotlivé user stories nebo úkoly se rozdělí mezi 5 kategorií: XS, S, M, L a XL.
• Každá velikost dostane přidělený určitý počet story pointů.

Osvědčená praxe

Na závěr vám ještě poodhalíme pár tipů z naší osvědčené praxe, které nám spolu s přesnějšími odhady umožňují naplánovat a nakonec dodat uživatelsky příjemný produkt.

Prioritizace

Seznam požadavků může být dlouhý. Tak kde začít?

Nejdřív velké úkoly (epicy) rozdělíme do menších. Potom snáze naodhadujeme ty malé.

Spolehlivou metodou pro první selekci priorit je MoSCoW metoda.

Všechny požadavky roztřídíme dle jejich RoI (return on investment) do 4 kvadrantů. Must have a Should have požadavky by měly společně postavit kompetitivní produkt.

MUST HAVE požadavky nutné pro fungování projektu	SHOULD HAVE důležité, ale ne životně důležité požadavky
COULD HAVE nice-to-have	WON’T HAVE požadavky s malou hodnotou a vysokým RoI

Na co při odhadování nezapomenout

Dobrý projektový manažer v odhadech nikdy nezapomíná na dostatek času pro řešení bugů. Ty jsou totiž nedílnou součástí vývoje. Ani nejzkušenější vývojář totiž neprogramuje bezchybně.

A nakonec, odhady je třeba v průběhu vývoje revidovat. Nakonec, pořád jsou to jen odhady a ne čísla vytesaná do kamene. V průběhu vývoje se totiž vždycky objeví nové skutečnosti, které je třeba zohlednit.

Pokud jste dočetli až sem, doufáme, že vám článek odpověděl na všechny otazníky spojené s tématem vytváření odhadů na poli vývoje software. A pokud přece jen nějaké otazníky zbyly, neváhejte nám napsat. Rádi článek doplníme pro vás i další čtenáře.