načítání...
nákupní košík
Košík

je prázdný
a
b

E-kniha: Odhadování softwarových projektů - Steve McConnell

Odhadování softwarových projektů

Elektronická kniha: Odhadování softwarových projektů
Autor:

Odhadování softwarových projektů, tedy správné stanovení potřebného rozpočtu, termínů, lidských zdrojů a dalších aspektů, se zdá být tolik nepředvídatelná, nejistá a složitá ... (celý popis)
Produkt teď bohužel není dostupný.

»hlídat dostupnost


hodnoceni - 75.7%hodnoceni - 75.7%hodnoceni - 75.7%hodnoceni - 75.7%hodnoceni - 75.7% 100%   celkové hodnocení
1 hodnocení + 0 recenzí

Specifikace
Nakladatelství: Computer press
Dostupné formáty
ke stažení:
PDF
Upozornění: většina e-knih je zabezpečena proti tisku
Médium: e-book
Počet stran: 317
Úprava: ilustrace
Vydání: Vyd. 1.
Název originálu: Software estimation
Spolupracovali: překlad Jiří Fadrný
Jazyk: česky
Téma: náklady, termíny, efektivita týmu, řízení jakosti
ADOBE DRM: bez
ISBN: 978-80-251-1240-3
Ukázka: » zobrazit ukázku
Popis

Odhadování softwarových projektů, tedy správné stanovení potřebného rozpočtu, termínů, lidských zdrojů a dalších aspektů, se zdá být tolik nepředvídatelná, nejistá a složitá činnost, že bývá s nadsázkou přirovnávána k černé magii. Ve skutečnosti tomu tak není: při znalosti několika pravidel a postupů lze podat realistický odhad s poměrně velkou jistotou, vyhnout se tak problémům při realizaci projektu a ušetřit vysoké částky, které zdržený projekt nevyhnutelně spolyká.

Proslulý softwarový inženýr Steve McConell, autor mnoha knižních bestsellerů, vám v této knize předává své zkušenosti, které z něj učinily jednoho z nejvyhledávanějších projektových manažerů. Neočekávejte akademické poučky ani obtížně aplikovatelné vzorce: kniha vychází z reálné praxe a přináší více než 110 tipů, které můžete přímo využít ve vašich projektech a okamžitě tak zvýšit efektivitu vaší firmy.

V knize se dozvíte, jak:
- určit termíny a náklady při dané funkcionalitě nebo určit možnou funkcionalitu při daných termínech a nákladech
- zvýšit efektivitu týmu a ušetřit peníze
- vyhnout se častým chybám odhadů
- definovat jednotlivé aspekty projektu, například analýzu, vývoj, řízení kvality
- použít popisované techniky v praxi na skutečných projektech
- využít tipy pro malé i velké projekty, vyvíjené agilně i tradičně

„Nejen, že se naučíte realisticky odhadovat softwarové projekty, ale díky této knize od základů změníte i svůj celkový pohled na vývoj softwaru. Kniha patří do knihovničky každého opravdového vývojáře.“
Eric Freeman, spoluautor knihy Head First Design Patterns

O autorovi:

Steve McConnell je jedním ze světově nejuznávanějších autorů v komunitě vývojářů a softwarových inženýrů. V roce 1998 jej označili čtenáři časopisu Software Development za jednoho ze tří nejvlivnějších lidí v softwarovém průmyslu, spolu s Billem Gatesem a Linusem Torvaldsem. Do jeho publikační činnosti patří například tituly Dokonalý kód nebo Rapid Development. V současnosti je hlavním softwarovým inženýrem ve společnosti Construx Software, dříve pracoval na softwarových projektech v Microsoftu, Boeingu a v mnoha dalších firmách. (jak správně určit rozpočet, termín a zdroje)

Předmětná hesla
Související tituly dle názvu:
Investiční rozhodování a řízení projektů Investiční rozhodování a řízení projektů
Fotr Jiří, Souček Ivan
Cena: 169 Kč
Architektura softwaru Architektura softwaru
Cripps Peter, Eeles Peter
Cena: 422 Kč
Investiční rozhodování a řízení projektů Investiční rozhodování a řízení projektů
Fotr Jiří, Souček Ivan
Cena: 450 Kč
Softwarové inženýrství Softwarové inženýrství
Sommerville Ian
Cena: 1097 Kč
Softwarové právo Softwarové právo
Jansa Lukáš, Otevřel Petr
Cena: 339 Kč
Recenze a komentáře k titulu
Zatím žádné recenze.


Ukázka / obsah
Přepis ukázky

Steve McConnell

Odhadování softwarových projektů

Jak správně určit rozpočet, termín a zdroje

Computer Press, a.s.

Brno

2006


Odhadování softwarových projektů

Jak správně určit rozpočet, termín a zdroje

Steve McConnell

Copyright © Computer Press, a.s. 2006. Vydání první. Všechna práva vyhrazena.

Vydalo nakladatelství Computer Press, a.s. jako svou 2412. publikaci.

Vydavatelství a nakladatelství Computer Press, a.s.,

nám. 28. dubna 48, 635 00 Brno, knihy.cpress.cz

ISBN 80-251-1240-3

Prodejní kód: K1369

Copyright 2006 by Microsoft Corporation.

Original English language edition Copyright © by Steve McConnell.

All rights published by arrangement with the original publisher, Microsoft Press, a division

of Microsoft Corporation, Redmond, Washington, U.S.A.

Autorizovaný překlad z originálního anglického vydání Software Estimation: Demystifying the Black Art.

Originální copyright: © Microsoft Corporation Inc./Steve McConnell, 2006.

Překlad: © Computer Press, a.s., 2006.

Žádná část této publikace nesmí být publikována a šířena žádným způsobem

a v žádné podobě bez výslovného svolení vydavatele.

Computer Press, a.s., nám. 28. dubna 48, 635 00 Brno

tel.: 546 122 111, fax: 546 122 112

Objednávejte na: knihy.cpress.cz

distribuce@cpress.cz

Bezplatná telefonní linka: 800 555 513

Dotazy k vydavatelské činnosti směřujte na: knihy@cpress.cz

Máte-li zájem o pravidelné zasílání informací o knižních novinkách do Vaší e-mailové schránky,

zašlete nám zprávu, obsahující váš souhlas se zasíláním knižních novinek, na adresu

novinky@cpress.cz.

Novinky k dispozici ve dni vydání, slevy, recenze,

zajímavé programy pro firmy i koncové zákazníky.

Překlad: Jiří Fadrný

Odborná korektura: Marcel Šastný

Jazyková korektura: Petra Láníčková

Vnitřní úprava: Jiří Matoušek

Sazba: Jiří Matoušek, Petr Klíma

Rejstřík: Daniel Štreit

Obálka: Martin Sodomka

Komentář na zadní straně obálky: Václav Kadlec

Technická spolupráce: Zuzana Šindlerová

Odpovědný redaktor: Václav Kadlec

Technický redaktor: Jiří Matoušek

Produkce: Petr Baláš


Stručný obsah

Část 1: Rozhodující koncepce odhadů 23

Kapitola 1 Co je „Odhad“? 25

Kapitola 2 Jak dobré odhady děláte? 37

Kapitola 3 Hodnota přesných odhadů 43

Kapitola 4 Odkud se berou chyby v odhadech? 53

Kapitola 5 Vlivy na odhady 73

Část 2: Základní metody odhadů 93

Kapitola 6 Úvod k metodám odhadů 95

Kapitola 7 Počítání, kalkulace, úsudky 101

Kapitola 8 Kalibrace a historická data 109

Kapitola 9 Individuální úsudky expertů 121

Kapitola 10 Dekompozice a zpětné skládání 129

Kapitola 11 Odhad pomocí analogie 145

Kapitola 12 Odhady pomocí zástupce 153

Kapitola 13 Skupinové úsudky expertů 167

Kapitola 14 Softwarové nástroje na odhady 175

Kapitola 15 Použití více přístupů 183

Kapitola 16 Vývoj odhadů software u dobře odhadnutých projektů 189

Kapitola 17 Standardizované procedury odhadování 199

Část 3: Typické problémy při odhadování 213

Kapitola 18 Problémy v odhadech velikosti 215

Kapitola 19 Problémy v odhadech práce 227

Kapitola 20 Problémy v odhadech rozvrhu 241

Kapitola 21 Odhadování parametrů plánování 253

Kapitola 22 Způsoby prezentace odhadu 269

Kapitola 23 Politika, vyjednávání a řešení problémů 279

Příloha A Prvotní kontrola odhadu 291

Příloha B Odpovědi na kvíz v kapitole 2, „Jak dobré odhady děláte?“ 293

Příloha C Tipy pro odhadování software 295



Obsah

Předmluva 15

Poděkování 21

ČÁST 1

Rozhodující koncepce odhadů

KAPITOLA 1

Co je „Odhad“? 25

Odhady, cíle a závazky 25

Vztah mezi odhady a plány 26

Komunikace ohledně odhadů, cílů a závazků 27

Odhady jako vyjádření pravděpodobnosti 28

Běžná definice „dobrého“ odhadu 32

Odhady a řízení projektu 34

Skutečný cíl odhadů 35

Pracovní definice „dobrého odhadu“ 36

Další prameny 36 KAPITOLA 2 Jak dobré odhady děláte? 37

Jednoduchý kvíz na odhadování 37

Diskuze nad výsledky kvízu 38

Jak jistá je „90% jistota“? 38

Jak široké hranice byste měli zvolit? 40

Odkud se bere tlak na zužování hranic? 40

Kolik tento test vypovídá o skutečném odhadování softwaru? 41

KAPITOLA 3

Hodnota přesných odhadů 43

Je lepší odhad nadsadit nebo podhodnotit? 43

Argumenty proti nadhodnocování 44

Argumenty proti podhodnocení 44

Srovnání argumentů 45


Detaily zaznamenaných odhadů v softwarovém průmyslu 46

O kolik se projekty opožují? 48

Zkušenost z jedné společnosti 48

Systémový problém softwarového průmyslu 49 Výhody přesných odhadů 49 Cena předvídatelnosti ve srovnání s dalšími žádanými atributy projektu 51 Problémy běžných technik odhadování 52 Další prameny 52

KAPITOLA 4

Odkud se berou chyby v odhadech? 53

Zdroje nejistot v odhadech 54

Kužel nejistoty 55

Lze nad kuželem zvítězit? 57

Kužel se sám nezúží 57

Zahrnutí kužele nejistoty do odhadů 58

Vztah mezi kuželem nejistoty a závazkem 59

Kužel nejistoty a opakující se vývoj 60 Chaotické vývojové procesy 61 Měnící se požadavky 61

Odhadování růstu požadavků 62 Opomíjené aktivity 63 Nepodložený optimismus 65 Subjektivita a předsudky 66 Uspěchané odhady 68 Nezaručená přesnost 70 Další zdroje chyb 71 Další prameny 72

KAPITOLA 5

Vlivy na odhady 73

Velikost projektu 73

Proč tato kniha rozebírá velikost v řádcích kódu? 75

Nevýhoda velikosti 75

Kdy můžete nevýhodu velikosti bezpečně ignorovat? 79

Závažnost nevýhody velikosti v odhadech softwaru 80 Druh vyvíjeného softwaru 80 Lidský faktor 81 Programovací jazyk 82

Obsah6


Další vlivy na projekt 83

A opět nevýhoda velikosti 89

Další prameny 91

ČÁST 2

Základní metody odhadů

KAPITOLA 6

Úvod k metodám odhadů 95

Úvahy nad výběrem metody pro odhady 95

Co vlastně odhadujete? 95

Velikost projektu 96

Styl vývoje software 96

Vliv stylu vývoje na výběr metod odhadování 97

Fáze vývoje 97

Dosažitelná přesnost 98 Tabulky použitelnosti metod 98

Použitelnost metod v této kapitole – PŘÍKLAD 98

KAPITOLA 7

Počítání, kalkulace, úsudky 101

Nejprve počítejte 102

Co počítat? 103

Převod počtů na odhady pomocí kalkulací 104

Úsudek je až poslední možnost 106

Další prameny 107

KAPITOLA 8

Kalibrace a historická data 109

Zlepšení přesnosti a další výhody historických dat 110

Započtení vlivů ve firmě 110

Předcházení subjektivitě a nepodloženému optimismu 111

Omezení politikaření v odhadech 111 Data, která lze shromažďovat 113

Problémy s měřením velikosti 113

Problémy s měřením práce 114

Problémy s měřením kalendářního času 114

Problémy s měřením chyb 115

7Obsah


Další problémy při shromažování dat 115 Jak kalibrovat? 116 Použití dat z projektu ke zdokonalení vašich odhadů 117 Kalibrace pomocí průměrných dat z celého odvětví 117 Shrnutí 119 Další prameny 120

KAPITOLA 9

Individuální úsudky expertů 121

Strukturovaný úsudek experta 122

Kdo odhad tvoří? 122

Rozpad na menší celky 122

Použití intervalů 123

Vzorce 125

Soubory otázek 126 Srovnání odhadů a skutečnosti 127 Další prameny 128

KAPITOLA 10

Dekompozice a zpětné skládání 129

Kalkulace přesného celkového očekávaného případu 130

Zákon velkých čísel 131

Jak malé by měly odhadované části být? 132 Dekompozice pomocí struktury práce v aktivitách 133 Rizika sčítání odhadů nejlepších a nejhorších případů 134

Varování: Nejprve matematika! 135

Co bylo špatně? 135 Vytváření smysluplných celkových odhadů nejlepšího

a nejhoršího případu 137

Výpočet nejlepších a nejhorších souhrnných případů pro malá

množství úkolů (jednoduchý vzorec pro standardní odchylku) 137

Výpočet nejlepších a nejhorších souhrnných případů pro velká

množství úkolů (komplexní vzorec pro standardní odchylku) 138

Vytváření souhrnných odhadů nejlepších a nejhorších případů 141

Nástrahy u odhadů s procentuální jistotou 142 Další zdroje 143

Obsah8


KAPITOLA 11

Odhad pomocí analogie 145

Základní přístup k odhadování pomocí analogie 146

Krok 1: Získejte detailní konečné údaje o velikosti, práci a ceně u podobného

projektu v minulosti 147

Krok 2: Srovnejte velikost nového a podobného starého projektu 148

Krok 3: Postavte odhad pro velikost nového projektu jako

procentuální poměr vůči velikosti starého projektu 148

Krok 4: Vytvořte odhad práce postavený na srovnání velikosti

nového a předchozího projektu 149

Krok 5: Kontrolujte soulad předpokladů ve starém a novém projektu 150 Poznámky k nejistotě v odhadu Triadu 150

Nejistota odhadů, plány a závazky 151

KAPITOLA 12

Odhady pomocí zástupce 153

Fuzzy logika 154

Jak získat hodnoty průměrné velikosti 155

Jak klasifikovat novou funkcionalitu 155

Jak fuzzy logiku nepoužívat 156

Rozšíření fuzzy logiky 156 Standardní komponenty 157

Použití standardních komponent s percentily 158

Omezení standardních komponent 159 Větší celky a jejich hodnocení (Story points) 160

Nástrahy škál hodnocení 162 Konfekční velikost (T-Shirt Sizing) 163 Další použití metod se zástupci 165 Další prameny 166

KAPITOLA 13

Skupinové úsudky expertů 167

Skupinová hodnocení 167

Wideband Delphi 169

Účinnost Wideband Delphi 170

„Pravda je venku“ 172

Kdy použít Wideband Delphi 172 Další prameny 173

9Obsah


KAPITOLA 14

Softwarové nástroje na odhady 175

Co lze udělat s nástroji a nikoli ručně 175

Data potřebná pro nastavení nástrojů 180

Jedna věc, kterou byste neměli dělat s nástrojem ani jindy 180

Shrnutí dostupných nástrojů 181

Další prameny 182 KAPITOLA 15 Použití více přístupů 183

Další prameny 187 KAPITOLA 16 Vývoj odhadů software u dobře odhadnutých projektů 189

Vývoj individuálního odhadu na špatně odhadovaném projektu 190

Vývoj individuálního odhadu na dobře odhadovaném projektu 190

Chronologický průběh vývoje odhadu pro celý projekt 192

Vývoj odhadu u velkých projektů 193

Vývoj odhadu u malých projektů 193

Zpřesňování odhadů 193

Jak předložit opravený odhad investorům 194

Kdy předkládat upravené odhady 195

Co když vám management nepovolí odhad přehodnotit? 196

Pohled na dobře odhadnutý projekt 197 KAPITOLA 17 Standardizované procedury odhadování 199

Obvyklé části standardizované procedury 200

Úprava odhadování na proces stádium-brána 200

Příklad standardizované procedury odhadování pro postupné projekty 203

Příklad standardizované procedury odhadování pro opakující se projekty 206

Příklad standardizované procedury odhadovaní z vyspělé organizace 208

Vylepšování vaší standardizované procedury 210

Další prameny 211

Obsah10


ČÁST 3

Typické problémy při odhadování

KAPITOLA 18

Problémy v odhadech velikosti 215

Problémy s odhadováním velikosti 216

Úloha řádků kódu v odhadech velikosti 216 Odhadování pomocí funkčních celků 218

Převod funkčních celků na řádky kódu 220 Zjednodušené metody funkčních celků 221

Nizozemská Metoda 221

GUI elementy 222 Shrnutí metod odhadování velikosti 223 Další prameny 224

KAPITOLA 19

Problémy v odhadech práce 227

Vlivy na práci 227

Výpočet práce z velikosti 229

Výpočet odhadu práce pomocí neformálního srovnání

s předchozími projekty 229

Jaké druhy software jsou v tomto odhadu zahrnuty? 230 Výpočet odhadů práce pomocí vědeckého odhadování 230 Grafy práce z průměru v odvětví 231 Metoda ISBSG 236

Druh projektu: Obecný 237

Druh projektu: Mainframe 237

Druh projektu: Střední 237

Druh projektu: Desktop 237

Druh projektu: Jazyk třetí generace 237

Druh projektu: Jazyk čtvté generace 238

Druh projektu: Rozšíření 238

Druh projektu: Nový vývoj 238 Srovnání odhadů práce 239 Další prameny 240

KAPITOLA 20

Problémy v odhadech rozvrhu 241

Základní rovnice pro rozvrh 242

11Obsah


Výpočet rozvrhu pomocí neformálních srovnání s minulými projekty 243

Jonesova metoda odhadování prvního řádu 244

Výpočet odhadu rozvrhu pomocí vědeckého odhadování 245

Zkracování rozvrhu a nejkratší možný rozvrh 246

Kompromisy mezi rozvrhem a prací 248

Zkracování rozvrhu a velikost týmu 249 Odhady rozvrhu a omezení personálu 250 Srovnání výsledků různých metod 251 Další prameny 252

KAPITOLA 21

Odhadování parametrů plánování 253

Odhad rozložení aktivit na projektu 253

Odhadování přiřazení práce na různé technické aktivity 254

Odhad práce na specifikaci požadavků 254

Odhad práce managementu 255

Odhad celkové aktivity 256

Nastavení podle typu projektu 256

Příklad přiřazení práce na aktivity 257

Poměry vývojáři-testeři 258 Odhad rozvrhu pro různé aktivity 258 Převod odhadované práce (ideální situace) na plán práce 259 Odhady ceny 261

Přesčasy 261

Je cena projektu založená na přímé ceně, plné ceně nebo

nějaké jiné variaci? 261

Další přímé náklady 261 Odhadování produkce chyb a jejich odstraňování 261

Odhad odstraňování chyb 262

Příklad odhadování efektivity při odstraňování chyb 263 Odhadování rezervy pro rizika a výjimečné situace 265 Další hrubá čísla 267 Další prameny 267

KAPITOLA 22

Způsoby prezentace odhadu 269

Komunikace o předpokladech v odhadu 269

Vyjádření nejistoty 271

Znaménka plus a mínus 271

Obsah12


Rozpis rizik 271

Koeficienty pravděpodobnosti 272

Odhady pomocí případů 274

Rozlišení časových údajů a úseků 275

Použití intervalů (libovolných) 276

Užitečnost odhadů pomocí intervalů 276

Intervaly a závazky 277

Další prameny 277

KAPITOLA 23

Politika, vyjednávání a řešení problémů 279

Vlastnosti manažerů 279

Politické vlivy na odhady 280

Externí omezení 281

Rozpočty a termíny 281

Vyjednávání o odhadech versus vyjednávání o závazcích 281

Co dělat, když nebude váš odhad akceptován 282

Odpovědnost technických pracovníků za vzdělávání laických investorů 282

Řešení problémů a principiální vyjednávání 283

Přístup k vyjednávání jako k řešení problému 284

Oddělení lidí a problémů 284

Zaměření na zájmy, ne na pozice 285

Hledání oboustranně výhodných možností 286

Trvání na používání objektivních kritérií 288

Další prameny 289

PŘÍLOHA A

Prvotní kontrola odhadu 291

PŘÍLOHA B

Odpovědi na kvíz v kapitole 2,

„Jak dobré odhady děláte?“ 293

PŘÍLOHA C

Tipy pro odhadování softwaru 295

Rejstřík 313

13Obsah



Předmluva

Tři nejhorší roky studia odhadovatelů cen jsou matematika v páté třídě.

- Norman R. Augustine

Odhadování softwaru není těžké. Odborníci zkoumají a píší o odhadech softwaru užčtyři

cet let a vyvinuli mnoho metod, které podporují přesné odhadování vývoje softwaru.Tvor

ba přesných odhadů je nezáludná – jakmile jednou pochopíte, jak na to. Ale ne všechny

metody v odhadování jsou intuitivní a ani bystří lidé neobjeví všechny dobré postupy sami.

Skutečnost, že někdo je zkušený vývojář, z něj nedělá odborníka na odhady.

Mnoho aspektů odhadování znamená něco jiného, než jak se jeví. Spousta tzv.problé

mů s odhady pochází z nepochopení toho, co je „odhad“, nebo je způsobena tím, že

jsou do odhadování přimíchávány jiné metody, podobné, ale ne stejné. Některémeto

dy tvorby odhadů, které se intuitivně zdají užitečné, nedávají přesné výsledky. Složité

vzorce někdy nadělají víc škody než užitku a některé zdánlivě jednoduché postupypro

dukují překvapivě přesné výstupy.

Tato kniha zhuštěně podává čtyři desetiletí výzkumu, a dokonce ještě více let aktivních

zkušeností s pomocí vývojářům, vedoucím, testerům a manažerům, aby se staliefektiv

ními odhadovateli. Studium odhadování softwaru je všeobecně užitečné, protože vlivy,

které působí na odhady softwaru zároveň působí na vývoj softwaru samotný.

Umění odhadování versus

vědecké odhadování

Výzkum odhadování softwaru se v současné době soustřeuje na zlepšování metod

odhadování tak, aby vynikající softwarové firmy mohly dosahovat výsledků projektů

v rozmezí ±5 % odhadů místo ±10 %. Tyto metody jsou výpočetně náročné. Pochopení

těchto technik vyžaduje velké znalosti matematiky a usilovné studium. Jejich používání

požaduje výpočty, které není možné udělat na kalkulačce. Metody fungují nejlépe, jsou-li

začleněny do komerčních nástrojů pro odhadování. Této oblasti metod říkám vědecké

odhadování.

Ale běžné softwarové firmy zlepšování odhadů z ±10 % na ±5 % netrápí. Typickásoftwa

rová společnost se potýká s problémem, jak předcházet odhadům, které jsou chybné

o 100 % nebo více. (Důvody tohoto stavu jsou různé a rozebereme je v kapitolách 3 a 4.)

Většina z nás si přirozeně myslí, že složité vzorce typu:

nám dají vždy přesnější výsledky než jednoduché vztahy jako tento:

Práce = PočetPožadavků*PrůměrnáPráceNaPožadavek


Ale složité vzorce nemusí být lepší. Softwarové projekty jsou ovlivněny mnoha faktory,

které narušují předpoklady obsažené ve složitých rovnicích pro vědecké odhadování.

Tyto souvislosti si vysvětlíme dále v knize. Navíc většina softwarových praktiků nemá

ani čas, ani chu se zabývat náročnou matematikou, která je pro vědecké metodyodhadování nezbytná.

Proto tato kniha klade důraz na jednoduchá pravidla, procedury a prosté vzorce, které

jsou velmi efektivní a pochopitelné pro softwarové profesionály, kteří dělají svouběžnou práci. Tyto metody nedávají odhady, které jsou přesné v rozmezí ±5 %, ale sníží

chybu na 25 % nebo méně, což je pro většinu projektů dostatečné. Tuto oblast metod

nazývám umění odhadování.

Tato kniha čerpá z umění odhadování i z vědeckých postupů, ale soustřeuje svou

pozornost na metody umění odhadování.

Proč byla napsána tato kniha

a komu je určena

Literatura o odhadování softwaru je nesystematická. Badatelé publikovali stovky článků

a mnoho z nich je užitečných. Ale běžný praktik nemá čas procházet tucty článků

z nesrozumitelných technických magazínů. Je jen pár starších knih, ve kterých bylo

popsáno vědecké odhadování. Tyto knihy mají 800 až 1 000 stran, vyžadují dobrématematické znalosti a jsou určeny především profesionálním odhadovatelům –konzultantům nebo specialistům, kteří často odhadují velké projekty.

Tuto knihu jsem napsal pro vývojáře, vedoucí, testery a manažery, kteří musí odhady

tvořit občas jako jednu z mnoha pracovních činností. Věřím, že většina lidí z praxe chce

přesnost svých odhadů zlepšit, ale nemají čas si udělat doktorát z odhadování softwaru.

Tito praktikové zápasí s běžnými problémy, například jak se vypořádat s politikou, která

se okolo odhadů točí, a jak předcházet tomu, aby někdo jejich odhad svévolně měnil.

Pokud patříte do této kategorie čtenářů, pak je tato kniha určena i vám.

Metody v této knize jsou určeny pro internetový a intranetový vývoj, vložené systémy,

krabicový software, obchodní systémy, nový vývoj, zastaralé zděděné systémy, velké

projekty, malé projekty – v podstatě pro všechny druhy softwaru.

Klíčové přínosy této knihy

Díky soustředěnosti na umění odhadování vám může tato kniha poskytnout novédůležité informace o odhadování:

■ Co vlastně „odhad“ je. (Možná si myslíte, že to víte, ale běžně se tento pojem

používá způsoby, které efektivní odhadování naopak podkopávají.)

■ Faktory, které zapříčinily, že vaše dřívější odhady byly méně přesné, než mohly

být.

Předmluva16


■ Způsoby, jak odlišit dobrý odhad od špatného.

■ Mnoho metod, které vám osobně umožní dělat dobré odhady.

■ Několik metod, které můžete použít při pomoci dalším členům svého týmu, aby

dělali dobré odhady.

■ Způsoby, jak může vaše firma dělat dobré odhady. (Mezi osobními metodami,

skupinovými metodami a firemními metodami jsou důležité rozdíly.)

■ Přístupy k odhadování, které fungují na rychlých projektech, i metody, které se

uplatní na tradičních, postupných projektech (vedených dle plánu).

■ Metody odhadů, které lze použít na malé projekty, a způsoby, které využijete na

projektech velkých.

■ Jak se dostat přes žraloky, kteří mnohdy vody politiky okolo odhadů softwaru

okupují.

Kromě toho, že lépe pochopíte koncepce odhadování, vám metody v této knizepopsané pomohou odhadnout mnoho specifických atributů softwarových projektů, do kterých

patří také:

■ Pracnost nového vývoje včetně rozvrhu, práce a ceny.

■ Rozvrh, práce a cena při údržbě zděděných zastaralých systémů.

■ Množství vlastností, které jste schopni dodat v jedné konkrétní vývojové iteraci.

■ Množství funkcionality, které můžete dodat pro celý projekt, když jsou rozvrh

a velikost týmu dány pevně.

■ Podíly různých nutných aktivit okolo vývoje softwaru, včetně množstvímanažerské práce, práce na specifikaci požadavků, na vývoji, na testování a na opravách

chyb.

■ Parametry plánování, například kompromisy mezi cenou a rozvrhem, ideální

velikost týmu, velikost rizikové rezervy, poměr počtu vývojářů a testerů atd.

■ Parametry kvality, včetně času potřebného na opravy chyb, počtu chyb, které ve

vašem softwaru zůstanou v okamžiku vydání, a dalších faktorů.

■ Téměř všechno ostatní, co chcete odhadnout. V mnoha případech budete moci metody popsané v této knize použít ihned. Většina praktiků nebude potřebovat jít ve studiu dále nad koncepce popsané v této knize. Ale pochopení metod v této publikaci vám dá dostatečný základ, abyste mohli v případě zájmu pokračovat směrem k matematicky náročnějším přístupům. O čem tato kniha není Tato kniha se netýká odhadování těch největších projektů – více než 1 milion řádků kódu nebo více než 100 let práce zaměstnanců. Extrémně velké projekty by měly být odhadovány profesionály, kteří již ony tucty nepochopitelných článků četli, kteřístudovali ony knihy o 800 až 1 000 stranách, kteří dobře znají komerční software naodhadování a kteří jsou zkušení jak v umění odhadování, tak ve vědeckých metodách.

17Předmluva


Kde začít

Místo, odkud začít s četbou, závisí na tom, co od knihy čekáte.

Pokud jste knihu zakoupili proto, že právě te musíte udělat odhad... Začněte

od první kapitoly („Co je „Odhad“?“) a pak přejděte na kapitolu 7 („Počítání, kalkulace,

úsudky“) a kapitolu 8 („Kalibrace a historická data“). Pak prolétněte tipy v kapitolách

10–20 a najděte metodu, která bude pro vás aktuálně nejpoužitelnější. Mimochodem,

tipy z celé knihy jsou v textu zvýrazněny a očíslovány, a navíc jsou všechny – 118cel

kem – shromážděny v příloze C, „Tipy pro odhadování softwaru“.

Jestliže chcete zlepšit své osobní dovednosti v odhadování, jestliže chcetezlep

šit výkon vaší firmy při tvorbě odhadů či pokud prostě jen hledáte lepšípocho

pení odhadů softwaru obecně... Přečtěte knihu celou. Chcete-li napřed pochopit

obecné principy a pak se ponořit do detailů, čtěte ji postupně od začátku. Pakližechce

te napřed znát detaily a pak z nich učinit obecné závěry, začněte kapitolou 1, přečtěte

kapitoly 7 až 23 a následně se vrate ke kapitolám, které jste přeskočili.

Bellevue, Washington

psáno na Nový rok 2006

Předmluva18


Zpětná podpora

Učinili jsme vše, co bylo v našich silách, aby kniha byla co nejlepší. Na následujícíinter

netové adrese můžete posílat připomínky ke všem knihám vydavatelství Microsoft Press:

http://www.microsoft.com/learning/support/books/

Přímé napojení na Microsoft Press Knowledge Base, kde můžete zadávat své dotazy

nebo problémy, najdete na:

http://www.microsoft.com/mspress/support/search.asp

Poznámky, dotazy či nápady ohledně této knihy můžete posílat přímo na vydavatelství

Microsoft Press, bu poštou, nebo e-mailem:

Microsfot Press

Attn: Software Estimation Editor

One Microsoft Way

Redmond, WA 98052-6399

e-mail:

msinput@microsoft.com

Poznámka redakce českého vydání: I nakladatelství Computer Press, které pro vás

tuto knihu přeložilo, stojí o zpětnou vazbu a bude na vaše podněty a dotazy reagovat.

Můžete se obrátit na následující adresy:

Computer Press

redakce počítačové literatury

náměstí 28. dubna 48

635 00 Brno-Bystrc

nebo

knihy@cpress.cz.

Další informace a případné opravy českého vydání knihy najdete na internetové adrese

http://knihy.cpress.cz/k1369. Prostřednictvím uvedené adresy můžete též naší redakci

zaslat komentář nebo dotaz týkající se knihy. Na vaše reakce se srdečně těšíme.

19Předmluva



Poděkování

Neustále nevycházím z údivu nad tím, kolika způsoby Internet zlepšuje práci. Rukopis

mé první knihy četli v podstatě pouze lidé, kteří bydleli do 50 mil ode mě. Knihu,kte

rou držíte, revidovali recenzenti z Argentiny, Austrálie, Kanady, Dánska, Anglie,Němec

ka, Islandu, Nizozemí, Severního Irska, Japonska, Skotska, Španělska a Spojených států.

Kniha těmito recenzemi neuvěřitelně získala.

Poděkování v první řadě zasluhují ti, kdo přispěli kritickými komentáři k velkým částem

knihy: Fernando Berzal, Steven Black, David E. Burgess, Stella M. Burns, Gavin Burrows,

Dale Campbell, Robert A. Clinkenbeard, Bob Corrick, Brian Donaldson, Jason Hills,Wil

liam Horn, Carl J Krzystofczyk, Jeffrey D. Moser, Thomas Oswald, Alan M. Pinder, Jon

Price, Kathy Rhode, Simon Robbie, Edmund Schweppe, Gerald Simon, Creig R. Smith,

Linda Taylor a Bernd Viefhues.

Dále si moji vděčnost zaslouží všichni, kteří recenzovali vybrané části knihy: Lisa M.

Adams, Hákon Ágústsson, Bryon Baker, Tina Coleman, Chris Crawford, DominicCro

nin, Jerry Deville, Conrado Estol, Eric Freeman, Hideo Fukumori, C. Dale Hildebrandt,

Barbara Hitchings, Jim Holmes, Rick Hower, Kevin Hutchison, Finnur Hrafn Jonsson,

Aaron Kiander, Mehmet Kerem Kiziltunç, Selimir Kustudic, Molly J. Mahai, SteveMat

tingly, Joe Nicholas, Al Noel, David O’Donoghue, Sheldon Porcina, David J. Preston,

Daniel Read, David Spokane, Janco Tanis, Ben Tilly a Wendy Wilhelm.

Obzvláště bych chtěl vyzdvihnout instruktory seminářů Construx estimation. Po létech

povzbuzujících diskuzí je často nemožné říci, které nápady pocházejí ode mě a které od

nich. Díky patří Earlu Beedeovi, Greggovi Boerovi, Mattu Peloquinovi, PamelePerrot

tové a Steve Tockeyovi.

Tato kniha se soustřeuje na umění odhadování a zjednodušení v této knize umožnili

výzkumníci, kteří strávili desítky let objasňováním vědeckého odhadování. Mé srdečné

díky míří ke třem gigantům vědeckých metod odhadů: Barry Boehmovi, CapersoviJone

sovi a Lawrence Putnamovi.

Spolupráce s Devonem Musgravem, redaktorem této knihy, byla opět vynikající. Díky

Devone! Pomocná redaktorka Becka McKay rovněž zlepšila můj původní rukopisneví

daným způsobem. Poděkování si také zaslouží zbytek pracovníků vydavatelstvíMicro

soft Press, tedy Patricia Bradbury, Carl Diltz, Tracey Freel, Jessie Good, Patricia

Masserman, Joel Panchot a Sandi Resnick. Díky také náleží tvůrci rejstříku SethoviMais

linovi.

A na závěr děkuji své ženě Ashlie, která je – podle mého soudu – nejlepší životnípart

nerkou, jakou jsem si kdy mohl přát.

21Poděkování



ČÁST 1

Rozhodující

koncepce odhadů



KAPITOLA 1

Co je „Odhad“?

Je velmi obtížné hodnověrně, energicky a riskantně obhajovat odhad,

který je vypracován bez jakékoli kvantitativní metody, postaven na malém

vzorku dat a podpořen z velké části pouze mlhavými představamimanažerů.

- Fred Brooks

Možná si myslíte, že již víte, co odhad je. Cílem této kapitoly je přesvědčit vás,

že odhad je něco jiného, než si většina lidí myslí. Dobrý odhad je dokonce něco

ještě více vzdáleného od zažité představy.

Slovníková definice odhadu je: 1. Prozatímní vyhodnocení nebo hrubákalkulace. 2. Předběžná kalkulace ceny projektu. 3. Úsudek postavený na dojmech

a názorech jednotlivce. (Zdroj: The American Heritage Dictionary, SecondCollege Edition, 1985.)

Zní to podobně jako to, oč jste žádáni v okamžiku, kdy máte vypracovat odhad?

Jste žádáni o prozatímní nebo předběžnou kalkulaci – což znamená, že se váš

názor může později změnit?

Pravděpodobně ne. Když manažeři žádají „odhad“, často žádají závazek nebo

plán, jak dosáhnout cíle. Rozlišování mezi odhady, cíli a závazky je při procesu

porozumění tomu, co odhad je, co odhad není a jak odhady zlepšit, kritické.

Odhady, cíle a závazky

Přesnou řečí vyslovena má vlastně slovníková definice odhadu pravdu: odhad

je předpově, jak dlouho bude projekt trvat nebo kolik bude stát. Aleodhadování softwarových projektů se navzájem ovlivňuje s obchodními cíli, závazky

a řízením.


Cíl je výrazem žádoucího obchodního plánu. Příklady jsou například takovéto:

■ „Verzi 2.1 potřebujeme mít hotovou pro demonstraci na veletrhu v květnu.“

■ „Potřebujeme včas stabilizovat toto vydání (release) pro prázdninový prodejní

cyklus.“

■ „Tyto funkce je potřeba dokončit do 1. července, abychom dostáli nařízením

vlády.“

■ „Další vydání nesmí stát více než 2 miliony dolarů, protože to je maximálnírozočet, který na toto vydání máme.“

Obchodníci mají závažné důvody pro to, aby stanovovali cíle bez ohledu na odhady

softwaru. Ale skutečnost, že cíl je žádoucí nebo dokonce nutný, ještě neznamená, že je

dosažitelný.

Zatímco cíl je popis žádoucího obchodního plánu, závazek je slib dodávky definované

funkčnosti na dané úrovni kvality k určitému datu. Závazek může být stejný jako odhad

nebo může být oproti odhadu agresivnější či konzervativnější. Jinými slovy,nepředpokládejte, že závazek musí být totéž co odhad. Nemusí.

Tip 1:

Rozlišujte mezi odhady, cíli a závazky.

Vztah mezi odhady a plány

Odhadování a plánování spolu souvisí, ale odhadování není plánování a plánování není

odhadování. Odhadování by měl být nezaujatý, analytický proces, zatímco plánování již

zaujaté být má, jde o proces hledání cíle. U odhadu je snaha o jakýkoliv konkrétní výstup

hazardem. Smyslem odhadu je přesnost, a nikoli konkrétní výsledek. Ale cílem plánování

je nalezení konkrétního výsledku. Vědomě (a vhodně) svoje plány upravujeme, abychom

došli k daným výstupům. Plánujeme konkrétní způsoby, jak kýženého cíle dosáhnout.

Odhady formují základ plánu, ale plány se nemusí s odhadem shodovat. Pokud jsou

odhady a cíle dramaticky odlišné, musí plány projektu tento rozpor odhalit a vyššíriziko zakalkulovat. Pokud se odhady a cíle příliš neliší, mohou pak plány uvažovat srizikem nižším.

Jak odhadování, tak plánování je důležité, ale fundamentální odlišnosti mezi nimiznamenají, že jejich míchání má tendenci vést ke špatným odhadům i špatným plánům.

Důležitý cíl v plánování může vést k nahrazení analyticky vypočteného odhadu tímto

cílem; členové projektu mohou dokonce na tento cíl odkazovat jako na odhad, což mu

dodává nechtěnou svatozář objektivity.

Zde jsou příklady úvah v plánování, které částečně závisí na přesných odhadech:

■ Vytváření detailního rozvrhu.

■ Nalezení kritické cesty projektu.

■ Vytvoření kompletní struktury prací.

Část 1 – Rozhodující koncepce odhadů26


■ Zjištění priorit v dodávkách funkcionality.

■ Rozpad projektu na jednotlivé iterace. Přesné odhady znamenají lepší postup prací v každé z těchto oblastí (kapitola 21, „Odhadování parametrů plánování“, se těmito tématy zabývá detailněji). Komunikace ohledně odhadů, cílů a závazků Jedním z důsledků blízkého a někdy matoucího vztahu mezi odhadováním aplánováním je, že investoři někdy o těchto aktivitách hovoří nesprávně. Typický příklad špatné komunikace vypadá takto:

MANAŽER: Jak dlouho myslíte, že bude tento projekt trvat? Potřebujeme mít tento

program připravený na veletrh za 3 měsíce. Nemohu vám přidat žádné lidi, takže

to musíte zvládnout s těmi, co máte. Zde je seznam potřebných vlastností.

VEDOUCÍ PROJEKTU: OK, projdu si ta čísla a ozvu se. Později...

VEDOUCÍ PROJEKTU: Odhadli jsme projekt na 5 měsíců.

MANAŽER: Pět měsíců?! Neslyšel jste mě? Řekl jsem, že musíme mít ten program

hotový za 3 měsíce, na veletrh! Z této komunikace si vedoucí projektu patrně odnese pocit, že manažer uvažujeiracionálně, protože chce od týmu, aby zvládl pětiměsíční práci za tři měsíce. Manažerpatrně bude o vedoucím projektu smýšlet naopak v tom smyslu, že vedoucí „nebere“ realitu podnikání, protože nechápe, jak důležité je, aby program byl na veletrh za tři měsíce připraven. Všimněte si, že v tomto příkladě manažer vlastně nežádal odhad. Žádal od vedoucího projektu, aby vypracoval plán, jak cíle dosáhnout. Většina manažerů nemá technické znalosti potřebné k jemným finesám rozlišování mezi odhady, cíli, závazky a plány. Z čehož vyplývá, že odpovědnost za překlad požadavku manažera do konkrétnějšítechnické mluvy přebírá technický vedoucí. Zde je produktivnější způsob možné interakce:

MANAŽER: Jak dlouho myslíte, že bude projekt trvat? Potřebujeme, aby byl program hotový za tři měsíce na veletrh. Nemohu vám přidat žádné lidi, takže to

musíte zvládnout s těmi, co máte. Zde je seznam potřebných vlastností.

VEDOUCÍ PROJEKTU: Ujasněme si jednu věc. Je pro nás důležitější 100%funkcionalita, nebo aby bylo do veletrhu hotovo aspoň něco?

MANAŽER: Musíme mít na veletrh aspoň něco. Ale rádi bychom měli 100%funkčnost, je-li to možné.

27Kapitola 1 – Co je „Odhad“?


VEDOUCÍ PROJEKTU: Chtěl bych si ještě přesněji ujasnit vaše priority. Pokud se

ukáže, že 100% funkčnosti nejsme do veletrhu schopni dosáhnout, máme býtpřiraveni vydat alespoň to, co budeme mít v tu dobu hotovo, nebo mámenaplánovat posun vydání až za veletrh?

MANAŽER: Pro veletrh musíme mít aspoň něco, takže pokud bude tlak na posun,

musíme vydat aspoň to něco, i kdyby to nebylo 100% to, co chceme.

VEDOUCÍ PROJEKTU: OK, navrhnu plán, jak dodat co nejvíce funkčnosti ve třech

měsících.

Tip 2:

Pokud jste požádáni o odhad, ujasněte si, zda máte dělat opravdu odhad

nebo najít způsob, jak dosáhnout cíle.

Odhady jako vyjádření

pravděpodobnosti

Jestliže tři čtvrtiny softwarových projektů překračují odhady, jsou šance jakéhokolivsoftwarového projektu na dokončení včas menší než 100%. Jakmile jednou víme, že šance

na včasné dokončení nejsou rovny 100 %, nabízí se okamžitě otázka: „Jestliže šance

nejsou 100%, jaké tedy jsou?“ Toto je jedna z hlavních otázek odhadování softwaru.

Odhady softwaru jsou běžně prezentovány jako jednočíselná informace, například:

„Tento projekt bude trvat 14 týdnů.“ Tyto zjednodušující jednočíselné odhady jsou

nesmyslné, protože neobsahují údaj o pravděpodobnosti spojené s tímto číslem.Předokládají pravděpodobnost, jak je vidět na obrázku 1.1, která dává jedinou možnost

dokončení.

Obrázek 1.1 Jednočíselný odhad se 100% pravděpodobností předpokládá,

že skutečné dokončení se rovná plánovanému dokončení. To je nereálné.

Část 1 – Rozhodující koncepce odhadů28

Jediné možné dokončení

(100% pravděpodobnost)

Pravděpodobnost

Rozvrh (nebo cena nebo práce)


Jednočíselný odhad je obyčejně cíl maskovaný jako odhad. Někdy naznačujesofistikovanější odhad, který byl zbaven významné informace o pravděpodobnosti někde vprůběhu.

Tip 3:

Když vidíte jednočíselný „odhad“, zeptejte se, zda je číslo odhad, nebo zda

jde skutečně o cíl. Přesné odhady softwaru uznávají, že na softwarové projekty útočí nejistota ze všech stran. Souhrnně tyto různé zdroje nejistot znamenají, že dokončení projektu se chová jako rozdělení pravděpodobnosti – některá dokončení jsou pravděpodobnější, některá méně pravděpodobná a skupina dokončení ve středu rozdělení jenejpravděpodobnější. Lze očekávat, že rozdělení dokončení projektu bude vypadat jako běžná zvonová křivka, jak je vidět na obrázku 1.2.

Obrázek 1.2 Běžný předpoklad je, že dokončení softwarového projektu tvoří

zvonovou křivku. Tento předpoklad je nesprávný, protože existují limity, jak

efektivně může projektový tým dokončit jakékoli zadané množství práce.

Každý bod na křivce reprezentuje šanci, že projekt bude dokončen přesně v tento den

(nebo bude stát přesně tolik). Plocha pod křivkou tvoří 100 %. Tento druhpravděpodobnosti bere v úvahu možnost velkého rozptylu dokončení. Ale předpoklad, žedokončení jsou symetricky rozdělena okolo průměru, není správný. Existuje omezení v tom,

jak dobře lze projekt vést, což znamená, že konec levé části rozdělení je useknutý

a nesahá tak daleko doleva jako u zvonové křivky. A zatímco omezení na to, jak dobře

projekt může probíhat, existuje, omezení v tom, jak špatně projekt může jít, neexistuje,

takže rozdělení pravděpodobnosti má velmi dlouhý konec v pravé části.

Obrázek 1.3 podává přesnou reprezentaci rozdělení pravděpodobnosti dokončenísoftwarového projektu.

29Kapitola 1 – Co je „Odhad“?

Pravděpodobnost

Nominální dokončení

Rozvrh (nebo cena nebo práce)


Obrázek 1.3 Přesné vyobrazení možných dokončení softwarového projektu. Je zde limit

v tom, jak dobře projekt může probíhat, ale není omezen počet možných problémů.

Svislá čárkovaná úsečka ukazuje „nominální“ dokončení, které je také možno nazvat

dokončení „50/50“ – je zde 50% šance, že projekt skončí lépe, a 50% šance, že projekt

skončí hůře. Statisticky se tato hodnota nazývá „mediánem“ dokončení.

Obrázek 1.4 ukazuje jiný způsob vyjádření tohoto rozdělení pravděpodobnosti.Zatím

co obrázek 1.3 ukazoval pravděpodobnosti dodávky k určitým termínům, obrázek 1.4

ukazuje pravděpodobnosti dodávky k danému datu nebo dříve.

Obrázek 1.4 Pravděpodobnost dodávky softwarového projektu k danému datu

nebo dříve (nebo za danou či nižší cenu nebo v dané či nižší pracnosti).

Obrázek 1.5 předkládá ideu pravděpodobností dokončení projektu jiným způsobem. Jak

je z obrázku vidět, prostý odhad typu „18 týdnů“ opomíjí zajímavou informaci, že

18 týdnů je pravděpodobných jen z 10 %. Odhad typu „18 až 24 týdnů“ jeinformativ

nější a poskytuje důležitou informaci o pravděpodobnostním intervalu dokončení

projektu.

Část 1 – Rozhodující koncepce odhadů30

Pravděpodobnost

Rozvrh (nebo cena nebo práce)

Nominální dokončení

(odhad 50/50)

Pravděpodobnost

dodávky kdané

mu nebodřívější

mu datu (nebo za

danou či nižší cenu

či pracnost)

Nominální dokončení

(odhad 50/50)

Rozvrh (nebo cena nebo práce)


Obrázek 1.5 Všechny jednočíselné odhady jsou explicitně či implicitně

spojeny s pravděpodobností.

Tip 4:

Když vidíte jednočíselný odhad, tak jeho pravděpodobnost není 100%.Zeptejte se, jakou pravděpodobnost tento odhad má. Pravděpodobnosti související s odhady lze vyjádřit mnoha způsoby. Můžete použít„procentuální jistotu“ přidanou k jednočíselnému odhadu: „Jsme si na 90 % jistí, že tozvládneme za 24 týdnů.“ Můžete popsat odhady jako nejlepší a nejhorší scénář, což naznačuje pravděpodobnost: „V nejlepším případě to zvládneme za 18 týdnů, v nejhorším za 24 týdnů.“ Nebo můžete odhad místo jednoho čísla postavit jednoduše jako interval: „Odhadujeme to na 18 až 24 týdnů.“ Klíčové je, že všechny odhady obsahujípravděpodobnost, a už je vyjádřena přímo nebo obsažena implicitně. Explicitní vyjádřenípravděpodobnosti je příznakem dobrého odhadu. Závazek můžete dát k optimistické hranici odhadu, k pesimistické nebo kamkoli mezi ně. Důležité je znát, kam do intervalu váš závazek spadá, abyste mohli příslušně plánovat.

31Kapitola 1 – Co je „Odhad“?

Pravděpodobnost

úspěchu

Odhadovaný čas

dokončení


Běžná definice „dobrého“ odhadu

Odpově na otázku, co je „odhad“, nám stále nedává odpověd na otázku, co je dobrý

odhad. Experti na odhady navrhli mnoho definicí dobrého odhadu. Capers Jonespro

hlásil, že přesnost ±10 % je možná, ale jen u dobře řízených projektů (Jones 1998).Cha

otické projekty mají příliš velkou variabilitu, aby takové přesnosti bylo možné

dosáhnout.

V roce 1986 navrhli profesoři S. D. Conte, H. E. Dunsmore a Y. D. Shen, že dobrýpří

stup k odhadování by měl dávat odhady, které jsou v rozmezí 25 % okolo skutečných

výsledků v 75 % času (Conte, Dunsmore a Shen, 1986). Tento standard odhadování je

nejběžnějším standardem používaným pro vyjadřování přesnosti odhadů (Stutzke 2005).

Mnoho společností ohlásilo výsledky odhadů, které jsou blízko k přesnosti, kterou

Conte, Dunsmore, Shen a Jones navrhli. Obrázek 1.6 ukazuje skutečné výsledky isrov

nání s odhady u souboru projektů U.S. Air Force.

Obrázek 1.6 Zlepšení v odhadování v sadě projektů U.S. Air Force.

Předpovědi se dramaticky zlepšily, když organizace přešly na vyšší úrovně CMM.

1

Obrázek 1.7 ukazuje výsledky podobného programu zlepšení ve společnosti Boeing.

Část 1 – Rozhodující koncepce odhadů32

Skutečné výsledky

jako procento

odhadu

Úroveň CMM organizace, která projekt vede

Zdroj: „A Correlation Study of the CMM and Software Development Performance“ (Lawlis, Flowe a Thordahl 1995).

1

CMM (Capability Maturity Model – Model Schopnosti a Vyspělosti) je systém definovanýInstitu

tem softwarového inženýrství pro určení efektivnosti softwarových organizací.


Obrázek 1.7 Zlepšení odhadů ve společnosti Boeing. Stejně jako u projektů

U.S. Air Force se předpovědi dramaticky zlepšily na vyšších úrovních CMM.

Závěrečný podobný příklad na obrázku 1.8 vychází ze zlepšených výsledků odhadů ve

společnosti Schlumberger.

Obrázek 1.8 Ve firmě Schlumberger byla zlepšena přesnost odhadů z průměrného

překročení o 35 týdnů na průměrné dokončení o 1 týden dříve

Jedna ze společností, která je mým klientem, dodává 97 % svých projektů včas a zasmlu

venou cenu. Telcordia ohlásila, že dodává včas a ve smluvené ceně dokonce 98 % svých

projektů (Pitterman 2000). Mnoho dalších firem publikovalo tytéž výsledky (Putnam

a Myers 2003). Organizace vytvářejí dobré odhady na základě Jonesovy definice idefi

nice Conteho, Dunsmorea a Shena. Ovšem v obou těchto definicích chybí důležitýkon

cept – řečeno konkrétně, přesných výsledků odhadů nelze dosáhnout pouze samotným

praktikováním odhadů. Musí být také podepřeny efektivním řízením projektu.

33Kapitola 1 – Co je „Odhad“?

Chyba

odhadu

Historická data použitá pro

odhady ve všech projektech

Úroveň CMM

Průměrné

překročení

(týdny)

Začátek v půlrocích

(počet projektů)


Odhady a řízení projektu

Někdy, když lidé diskutují o odhadech vývoje softwaru, chápou odhadování čistě jako

proces předvídání. Chovají se, jako kdyby byl odhad vytvářen nestranným odhadcem,

sedícím kdesi bokem, mimo veškeré plánování projektu a priorit.

Ve skutečnosti je při odhadování u softwaru jen máloco nestranné. Pokud jste kdychtě

li příklad aplikace Heisenbergova principu neurčitosti na software, tak odhad vyhoví

dokonale. (Heisenbergův princip neurčitosti je založen na faktu, že pouhé pozorování

objektu jej ovlivňuje a tudíž není možné s jistotou určit, jak by se objekt choval bez vlivu

pozorovatele.) Jakmile jednou učiníme odhad a na jeho základě se zavážeme kdodáv

ce funkcionality a kvality k určitému datu, pak projekt řídíme, abychom cíle dosáhli.

Typické řízení projektu obnáší odstraňování nedůležitých požadavků, redefinování

požadavků, náhradu méně zkušených pracovníků zkušenějšími atd. Obrázek 1.9 tuto

dynamiku ilustruje.

Obrázek 1.9 Projekty se od počátku až do dodávky mění. Změny jsou obvykle dost

významné, takže výsledný projekt není stejný jako projekt, pro který byl dělán odhad.

Nicméně pokud dokončení odpovídá odhadu, říkáme, že projekt s odhadem souhlasil.

Kromě událostí v průběhu řízení projektu jsou projekty často ovlivněnynepředvídaný

mi vnějšími událostmi. Projektový tým může například dostat úkol vytvořit prozatímní

vydání (release) na podporu klíčového zákazníka. Zaměstnanci mohou být rozděleni

kvůli podpoře starého projektu atd.

Události, které se v průběhu projektu stanou, téměř vždy zneplatní předpoklady, které

byly použity pro odhad projektu zpočátku. Mění se předpoklady ohledně funkcionality,

mění se předpoklady týkající se personálu, mění se priority. Je pak v podstatěnemož

né provést čistě analytický rozbor toho, zda byl projekt odhadnut přesně – protožepro

jekt, který byl výsledně dodán, není projektem, na který byl původní odhad dělán.

Část 1 – Rozhodující koncepce odhadů34

Zaměstnanci

nejsou připraveni

v plánovaný

okamžik

Odstranění

požadavků

Rozdělení

zaměstnanců

kvůli podpoře

veletrhu

Odstranění

nestabilní

funkcionality

„Odhad“ = 20

zaměstnaneckých

měsíců

PPrroojjeekktt

Dokončení = 20

zaměstnaneckých

měsíců

Přidání

požadavků

Méně zkušení

pracovníci oproti

očekávání

Rozdělení

zaměstnanců

kvůli podpoře

starých projektů

Přidány další

požadavky


V praxi to znamená, že pokud jsme dodali projekt o zhruba požadované funkcionalitě,

s použitím přibližně naplánovaného množství zdrojů a zhruba v termínu, říkámeoby

čejně, že projekt „se vešel do odhadu“, i přes všechny analytické nepřesnosti, které toto

vyjádření implicitně obnáší.

To znamená, že kritéria „dobrého“ odhadu nemohou být postavena na jeho schopnosti

předvídat, což je nedosažitelné, ale na schopnosti odhadu podpořit úspěch projektu, což

nás vede k dalšímu tématu: Správná role odhadů.

Skutečný cíl odhadů

Předpokládejme, že se připravujete na cesty a rozhodujete se, který kufr si máte vzít.

Máte malý kufřík, který se těší vaší oblibě, protože je lehký a vejde se do skříňky nad

hlavou v letadle. Máte také velký kufr, který už tak rádi nemáte, protože jej musíte na

letišti registrovat a pak na něj čekat u výdeje zavazadel, což pochopitelně zdržuje.Polo

žíte své oblečení vedle malého kufříku a zdá se vám, že se do něj téměř vejde. Coudě

láte? Zkusíte oblečení do kufříku pečlivě naskládat, abyste neplýtvali místem, a budete

doufat, že se tam vše naskládá. Pokud se to nezdaří, můžete nacpat oblečení dokufří

ku hrubou silou, a to tak, že si na kufřík sednete a pokusíte se zacvaknout zámky.Jest

liže se ani tento pokus nezdaří, stojíte před volbou: nechat nějaké oblečení doma, nebo

vzít velký kufr.

Softwarové projekty stojí před podobným dilematem. Plánovači projektů často vidípro

past mezi obchodními cíli projektu a odhadovaným časovým rozvrhem a cenou. Pokud

je propast malá, může plánovač uřídit projekt ke zdárnému konci obzvláště pečlivoupří

pravou nebo zmenšením časového rozvrhu projektu, rozpočtu či vlastností. Pokud je

propast velká, musí dojít k přehodnocení cílů projektu.

Primárním cílem odhadování vývoje softwaru není předpově jeho dokončení; cílem je

zjištění, zda jsou cíle projektu natolik realistické, aby byl projekt při směřování kdosa

žení těchto cílů zvládnutelný. Vejde se vaše oblečení, které si na cestu berete, domalé

ho kufříku nebo si budete muset vzít kufr velký? Bude možné vzít si po malých

úpravách malý kufřík? Manažeři chtějí stejné typy odpovědí. Nechtějí často přesný

odhad, který jim říká, že se požadované oblečení do kufříku nevejde; chtějí plán, jak do

kufříku dostat oblečení co nejvíce.

Problémy nastávají v situaci, kdy se vzdálenost mezi obchodními cíli a rozvrhem prací

a snahou potřebnou k dosažení těchto cílů příliš zvětší. Zjistil jsem, že pokud sepočá

teční cíl a odhad od sebe neliší o více než asi o 20 %, má projektový manažerdosta

tečný manévrovací prostor pro řízení funkčnosti, rozvrhu prací, velikosti týmu a dalších

parametrů, aby byly obchodní cíle projektu dosaženy; další experti s tím souhlasí

(Boehm 1981, Stutzke 2005). Pokud je rozdíl mezi cílem a tím, co je doopravdyzapo

třebí, příliš velký, nebude manažer schopen projekt řídit směrem k úspěšnému cílimalý

mi změnami parametrů projektu. Sebepečlivější balení vašeho oblečení nebo jakékoliv

sezení na víku od kufříku do něj všechny vaše oděvy nedostane a budete muset vzít

kufr větší, i když to není vaše počáteční volba, nebo budete muset nějaký kus oblečení

nechat doma. Cíle projektu budou muset lépe akceptovat realitu, má-li manažer projekt

zvládnout tak, aby bylo dosaženo cíle.

35Kapitola 1 – Co je „Odhad“?


Odhady nemusí být ani tak dokonale přesné, jako spíše užitečné. Když mámekombinaci přesných odhadů, dobrého nastavení cíle a dobrého plánování a řízení, můžeme

dosáhnout výsledků projektu, které se blíží k „odhadům.“ (Jak jste asi uhádli, slovo

„odhad“ je v uvozovkách, protože projekt, pro který byl odhad udělán, není totožný

s výsledným dodaným projektem.)

Tato dynamika změn předpokladů v projektu je hlavním důvodem, proč se tato kniha

více soustředí na umění odhadování než na vědu. Přesnost ± 5 % vám moc k ničemu

nebude, když se zásadní předpoklady projektu změní o 100 %.

Pracovní definice

„dobrého odhadu“

Ve světle několika předchozích kapitol jsme již nyní schopni odpovědět na otázku, co

dělá dobrý odhad dobrým odhadem.

Dobrý odhad je odhad, který poskytuje dostatečně jasný pohled na realituprojektu, aby vedení projektu mohlo dělat dobrá rozhodnutí, jak projekt vést, aby bylo

dosaženo cíle. Tato definice je základem diskuze o odhadech ve zbytku této knihy. Další prameny Conte, S. D., H. E. Dunsmore a V. Y. Shen. Software Engineering Metrics and Models. Menlo Park, CA: Benjamin/Cummings, 1986. Kniha Conteho, Dunsmorea a Shenaobsahuje zásadní diskusi o hodnocení modelů odhadů. Diskutuje kritéria „v 25% vzdálenosti od skutečnosti po 75 % času“ i mnoho dalších hodnotících kritérií. DeMarco, Tom. Controlling Software Projects. New York, NY: Yourdon Press, 1982. DeMarco rozebírá pravděpodobností chování softwarových projektů. Stutzke, Richard D. Estimating Software-Intensive Systems. Upper Saddle River, NJ:Addison-Wesley, 2005. Příloha C Stutzkeho knihy obsahuje souhrn měření přesnosti odhadů.

Část 1 – Rozhodující koncepce odhadů36


KAPITOLA 2

Jak dobré odhady

děláte?

Tento proces se nazývá odhadováním, nikoli hledáním naprostépřesnosti.

- Phillip Armour

Nyní, když víte, co je to dobrý odhad, zamyslete se nad otázkou: Jak dobré

odhady dělám? Následující text vám tuto otázku pomůže zodpovědět.

Jednoduchý kvíz

na odhadování

Tabulka 2.1 (na další straně) obsahuje kvíz, který otestuje vaše odhadovací

schopnosti. Pečlivě si přečtěte a promyslete následující pokyny:

U každé otázky vyplňte horní a dolní hranice, ve kterých dle vašeho názoru

s 90% pravděpodobností leží správná hodnota. Nedávejte své intervaly ani

příliš velké, ani příliš malé. Postavte je tak, aby byly dost vzdálené a dlevašeho nejlepšího úsudku dávaly 90% šanci, že hledaná odpově bude mezi nimi.

Nehledejte prosím žádnou z těchto odpovědí – kvíz má zhodnotit vašeschopnosti odhadu, ne schopnosti vyhledávat. Pro každou položku musíte vepsat

odpově, vynechání položky bude hodnoceno jako chyba. Omezte častohoto cvičení na 10 minut.

(Můžete kvíz před vyplněním okopírovat, aby si jej mohli vyplnit i dalšíčtenáři vašeho výtisku knihy.)

Správné odpovědi na otázky (například zeměpisná šířka Šanghaje) najdete vpříloze B v závěru této knihy. Za každou správnou odpově si připočtěte bod.


Dolní odhad Horní odhad Otázka

[ ____________ ] – [ ____________ ] Povrchová teplota Slunce

[ ____________ ] – [ ____________ ] Zeměpisná šířka Šanghaje

[ ____________ ] – [ ____________ ] Plocha asijského kontinentu

[ ____________ ] – [ ____________ ] Rok narození Alexandra Velikého

[ ____________ ] – [ ____________ ] Celkový objem měny USA v oběhu roku 2004

[ ____________ ] – [ ____________ ] Celkový objem Velkých jezer

[ ____________ ] – [ ____________ ] Celosvětové příjmy z filmu Titanic

[ ____________ ] – [ ____________ ] Celková délka pobřeží Tichého oceánu

[ ____________ ] – [ ____________ ] Počet knih vydaných v USA od roku 1776

[ ____________ ] – [ ____________ ] Nejtěžší zaznamenaná modrá velryba

Tabulka 2.1 Jak dobré odhady děláte?

Zdroj: Inspirováno podobným kvízem v knize Programming Pearls, Second Edition (Bentley 2000).

Tento kvíz je z knihy Software Estimation od Steve McConnella (Microsoft Press, 2006) a je autorskychrá

něn – © 2006 Steve McConnell. Všechna práva vyhrazena. Tento kvíz je možno kopírovat za předpokladu, že

je obsažena tato značka copyrightu.

Jak jste si vedli? (Nemějte špatný pocit. Většina lidí tento kvíz udělá špatně!) Napište své

skóre sem: ___________

Diskuze nad výsledky kvízu

Účelem tohoto kvízu není zjistit, zda víte, kdy se narodil Alexandr Veliký nebo na které

rovnoběžce leží Šanghaj. Jeho cílem je určit, jak dobře znáte své vlastní schopnosti

odhadů.

Jak jistá je „90% jistota“?

Pokyny nad kvízem jsou specifické v tom,



       
Knihkupectví Knihy.ABZ.cz - online prodej | ABZ Knihy, a.s.
ABZ knihy, a.s.
 
 
 

Knihy.ABZ.cz - knihkupectví online -  © 2004-2018 - ABZ ABZ knihy, a.s. TOPlist