Efektivní softwarové projekty

E N C Y K L O P E D I E

Sam Guckenheimer je vedoucím plánovačem pro VSTS. Než začal v roce 2003 pracovat pro Microsoft, st aral se o produkt ovou strategii v Rational Software Corporation (nyní součást IBM). Sam je Phi Bet a Kappa absolvent Harvardu a nyní žije se svojí ženou a dětmi v Puget Sound.

P R E S S

ZONER software, s.r.o. významný producent software v oblasti digitální fotografie, počítačové grafiky a multimédií, poskytovatel internetových služeb, souvisejících s prezentací na internetu a e-komercí, a nakladatelství odborné literatury.

www.zoner.cz

Pod tímto logem vycházejí publik ace určené pro k aždého vážného zájemce o práci s počítačem. Od r yze praktických příruček a průvodců až po komplexní publikace o všem, co potřebuje gr afik, webdesignér, vývojář či programátor při každodenní práci.

Na slevy, které můžete získat, a vydavatelský plán, v němž vedle knih domácích odborníků najdete celu řadu titulů světově uznávaných autorů, se informujte na adrese vydavatelství.

DOPORUČENÁ CENA: 300 KČ KATALOGOVÉ ČÍSLO: ZR703

ISBN

Sam Guckenheimer Juan J. Perez

Efektivní softwarové projekty

Sam Guckenheimer Juan J. Perez

Kniha Efektivní softwarové projekty je určena všem softwaro vým týmům, které chtějí používat moderní způsoby vývoje software. Je to kniha především o softwarovém inženýrství a její obsah je v elmi univerzální, i když uk azuje možnosti využití VSTS (Visual Studio Team System). Seznamuje s hodnotovým přístupem, z něhož vychází základ VSTS, uvádí jeho základní principy a způsob jejich prezentace na praktických příkladech řízení reálného průběhu IT projektů.

Sam Guckenheimer v projektu VSTS zastupoval požadavky zákazníka a zodpovídal za uživatelské rozhraní VSTS. Knihu koncipoval jako rámec, který vám při realizaci projektu pomůže přímo využít možností VSTS. Čtenáři se seznámí např. s tématy: • úloha hodnotocentrického přístupu (v kontrastu k přístupu úkolocentrickému) v životním cyklu software a význam a důležitost „toku“; • použití MSF for Agile Software De velopment a MSF f or CMMI Process Improvement; • pracovní položky pro plánování a vedení úkolníku ve VSTS; • mnohorozměrné denní metriky určené k udržení t oku projektu a usnadnění odhadů; • tvorba požadavků pomocí postav a scénářů; • vedení projektu s it eracemi, důvěryhodnou transparentností a bezkonfliktními metrikami; • architektonický návrh z hodnot ocentrického pohledu využí vající architekturu zaměřenou na služby, omezení a požadavky na kvalitu; • vývoj s testy programových jednotek, pokrytím kódu testy, profilováním a automatizovaným sestavením; • testování hodnoty pro zákazníka pomocí scénářů, požadavků na kvalitu, konfigurací, dat, průzkumů a metrik; • efektivní oznamování chyb a jejich řešení; • řešení problémů projektu: rozpoznávání a napr avování běžných rizik a antivzorů...

Efektivní softwarové projekty

Efektivní softwarové projekty

Z O N E R

P R E S S

ENCYKLOPEDIE WEBDESIGNERA

Sam Guckenheimer, Juan J. Perez

E N C Y K L O P E D I E

Z O N E R

978-80-86815-62-6

Zoner Press tel.: 532 190 883 fax: 543 257 245 e-mail: knihy@zoner.cz http://www.zonerpress.cz ZONER software, s.r.o., Nové sady 18, 602 00 Brno

9 7 8 8 0 8 6

8 1 5 6 2 6

www.zonerpress.cz

Chvála knihy Software Engineering with Microsoft Visual Studio Team System „Fascinující! Tato kniha je nabitá podr obnými informacemi o schopnostech VSTS a důvody, proč byly do VSTS zahrnuty – což jsou věci, kter é se můžete dozvědět jen od člena týmu, který na něm pracoval. Snad ještě důležitější je to, že všechny technické vlastnosti nebo návodné instrukce jsou doplněny o vysvětlení, proč jsou pro vás důležité. T ato kniha neopakuje chyby starších metodik, ale přitom zdůrazňuje to, co je na nich dobré. Současně udává směr budoucím metodikám a poukazuje na metriky, kterými můžete tuto metodiku ve svých vlastních pr ojektech vyladit a přizpůsobit.“ – Mark Michaelis, autor knihy Essential C# 2.0 „Tuto knihu si musí př ečíst každý, kdo chce Visual Studio Team System a Microsoft Solutions Framework 4.0 ovládnout tak, jak jejich tvůrci zamýšleli. Mezi jejich klíčové rysy patří „zodpovědná agilnost“. V ysvětluje posun k hodnotocentrickému přístupu k projektům a popisuje, jak Team System tento posun umožňuje. Její obsah je díky četným příkladům toho, jak byl tento přístup používán při vývoji VSTS, snadno pochopitelný.“ – Aaron Kowall, EDS Applications Portfolio Development, Innovation Engineering „Sam Guckenheimer je poslem nové éry důvěryhodné transparentnosti, která způsobí revoluční změnu ve způsobu, jakým řídíme pr ojekty zabývající se vývojem software. Nespokojte se s tím, že si koupíte Visual Studio Team System; naučte se, jak s jeho pomocí ovládnout změnu a sklidit odměnu. Sam vám ukáže, jak na to.“ – David J. Anderson, autor knihy Agile Management for Software

Engineering

„Samovi se podařilo na 250 stranách zachytit jádro balíku Visual Studio Team System. Podílíte-li se na tvorbě software nebo na vedení softwarových projektů – jako vývojář, tester, projektový manažer, architekt nebo IT manažer – budete chtít, aby ji měl každý člen vašeho týmu. Kniha sr ozumitelnou formou přibližuje moderní metody softwarového inženýrství a výklad doplňuje jasnými příklady , jak je implementovat s nástroji z Team System. Na rozdíl od předcházejících knih o softwarových metodikách se tato nebojí použít principy v praxi. Bez ohledu na to, zda VSTS již máte, zvažujete jej, nebo jen chcete zvýšit svoji pr oduktivitu a obchodní pozici, bude pro vás velkým přínosem. Kniha je zábavná, přístupná a snadno ji přečtete během víkendu.“ – Rick LaPlante, generální ředitel, Visual Studio Team System, Microsoft

„Sam Guckenheimer je již roky jedním z intelektových vůdců a učitelů komunity testování software. Je potěšující, že konečně vydal knihu, zvláště když vysvětluje jeho pohled tak, jako tato.“ – Cem Kaner, J.D., Ph.D., profesor softwarového inženýrství, Florida Institute of Technology; vedoucí autor knih Lessons Learned in Software

Testing a Testing Computer Software

„V knize Softwar e Engineering with Micr osoft Visual Studio Team System Sam Guckenheimer zachycuje ducha balíku Team System a rodící se hodnotocentrický přístup v softwarových metodikách. Základem návrhu a implementace Team System je měření dodané hodnoty, které nahrazuje dlouho praktikovaný přístup, při kterém se měřila hotová práce. Díky tomu zjistíte, že dosud nevídaná transparentnost projektu, kterou Team System poskytuje, zlepšuje součinnost v týmu a př edvídatelnost projektu. Navíc přitom členy týmu nezatěžuje časově nákladnou režií.

Jestliže chcete plně ocenit vizi, skrývající se za Team System, a přínos hodnotocentrického softwarového vývoje, který umožňuje, musíte si tuto knihu přečíst.“ – Rob Caron, obsahový architekt, Microsoft; autor knihy Team System

Nexus

„Sam Guckenheimer je technickým diplomatem. V e světě, kde partyzánské jednotky agilních metodik spojily své síly pr oti po zuby ozbr ojeným legiím CMMI, ukazuje cestu k vzájemnému soužití. T ato kniha je př edevším o softwarovém inženýrství. Klíčové body jako plánování, dokumentaci, vedení, audity a or ganizaci Sam probírá z agilního i formálnějšího pohledu, a také popisuje ideální stav v obou případech. Ačkoliv materiál předkládá v kontextu VSTS, jeho rady jsou univerzální. Sam oslovuje všechny role, které se projektu účastní, a poskytuje jim spolehlivé rady, nezávislé na „mohutnosti“ zvolených metodik. Obsah je aktuální a příhodný a zahrnuje architektury orientované na služby, vývoj řízený testy a metody návrhu, vyvinuté v komunitě uživatelských rozhraní. Samova kniha je Velmi Skvělým Textem o Software.“ – Dr. Bill Curtis, chief process officier, Borland Software Corporation; hlavní autor People Capability Maturity Model „Sam Guckenheimer je skutečným obhájcem uživatele. S pomocí T eam System, platformy, která metodiku zprostředkovává takovým způsobem, že ji lze pomocí nástrojů automatizovat, spravovat metrikami a že je pro uživatele téměř neviditelná, předkládá praktický a dostupný přístup k softwar ovému inženýrství, aniž by přitom opomíjel skutečnost, že musíme řešit těžké problémy.“ – James Behling, hlavní architekt Accenture Delivery Methods, Accenture

„Sam Guckenheimer i já jsme se vždy snažili zlepšit podpor u mezi vývojovými a provozními týmy. Samova kniha přináší dobře srozumitelný, z metodiky vycházející pohled na nejlepší techniky softwarového vývoje ztělesněné v MSF a použitelné v balíku Visual Studio Team System. „Vodopád“ zklamal, ale Samova kniha vám může ukázat, jak Visual Studio Team System používat při rychlém vývoji jen s tak rozsáhlou metodikou, jakou k tomu skutečně potřebujete.“ – Brian White, senior director of product management, iConclude, Inc., autor Software Configuration Management Strategies and Rational

ClearCase: A Practical Information

„V současném agilním prostředí představuje transparentnost zásadní prvek. Sam byl a stále je hnacím motor em tvorby celkové ar chitektury, která v Team System poskytuje úroveň integrace a transpar entnosti, která je pr o aplikaci agilního přístupu ve větších týmech potřebná. Když je tato transparentnost použita v prostředí povzbuzujícím důvěru a osobní bezpečí, může vytvořit pr oduktivnější vývojářské týmy a přitom do nich vnést postupy agilních metod. Nyní se do agilního procesu může zapojit celý vývojový tým, včetně obchodních analytiků, architektů a testerů.“ – Granville „Randy“ Miller, spoluautor A Practical Guide to eXtreme

Programming and Advanced Use Case Modeling

„Dovedete si představit, že máte k dispozici nástroj pro reinženýring obchodních procesů, použitelný pro softwarové inženýrství? Nástroj, který by dovedl zeštíhlit IT průmysl? Přesně o tom je tato kniha! Otevř e vám oči – je branou do nové éry softwarového inženýrství. Základní otázka této knihy je pr ostá: Dokázalo by MSFT VSTS, aby náš IT pr ůmysl přestal být takovým uměním, jakým zatím je, a stal se více vědou? Sam Guckeheimer vysvětluje, pr oč by to mohla být pravda, a navíc přináší mnoho rad, jak zvýšit pr oduktivitu a efektivitu celého týmu bez ruční režie.“ – Francis T. Delgado, senior program manager, Avanade, Inc.

Efektivní softwarové projekty

Sam Guckenheimer Juan J. Perez

Software Engineering With Microsoft Visual Studio Team System Authorized translation from the English language edition, entitled SOFTWARE ENGINEERING WITH MICROSOFT VISUAL STUDIO TEAM SYSTEM, 1st Edition, 0321278720 by GUCKENHEIMER, SAM; PEREZ, JUAN J., published by Pearson Education, Inc, publishing as Addison Wesley Professional, Copyright © 2006

by Sam Guckenheimer.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. CZECH language edition published by ZONER SOFTWARE, S.R.O. Copyright © 2007 by ZONER software, s.r.o.

Autorizovaný překlad anglického vydání nazvaného SOFTWARE ENGINEERING WITH MICROSOFT VISUAL STUDIO TEAM, první vydání, 0321278720, autor GUCKENHEIMER, SAM; PEREZ, JUAN J., vydal Pearson Education, Inc. ve vydavatelství Addison Wesley Professional; Copyright © 2006 Sam Guckenheimer.

Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována nebo předávána žádnou formou nebo způsobem, elektronicky ani mechanicky, včetně fotokopií, natáčení ani žádnými jinými systémy pro ukládání bez výslovného svolení Pearson Education, Inc. České vydání ZONER SOFTWARE, S.R.O. Copyright © 2007 ZONER software, s.r.o.

Efektivní softwarové projekty Autor: Sam Guckenheimer, Juan J. Perez Copyright © ZONER software, s.r.o. Vydání první v roce 2007. Všechna práva vyhrazena.

Zoner Press Katalogové číslo: ZR703 ZONER software, s.r.o.

Nové sady 18, 602 00 Brno Překlad: Jan Kuklínek, RNDr. Jan Pokorný Redakce: Jan Kuklínek Šéfredaktor: Ing. Pavel Kristián DTP: Lenka Křížová Informace, které jsou v této knize zveřejněny, mohou byt chráněny jako patent. Jména produktů byla uvedena bez záruky jejich volného použití. Při tvorbě textů a vyobrazení bylo sice postupováno s maximální péčí, ale př esto nelze zcela vyloučit možnost výskytu chyb. Vydavatelé a autoři nepřebírají právní odpovědnost ani žádnou jinou záruku za použití chybných údajů a z toho vyplývajících důsledků. Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována ani distribuována žádným způsobem ani pr ostředkem, ani reprodukována v databázi či na jiném záznamovém prostředku či v jiném systému bez výslovného svolení vydavatele, s výjimkou zveřejnění krátkých částí textu pro potřeby recenzí.

Veškeré dotazy týkající se distribuce směřujte na: Zoner Press ZONER software s.r.o.

Nové sady 18, 602 00 Brno tel.: 532 190 883, fax: 543 257 245 e-mail: knihy@zoner.cz http://www.zonerpress.cz

ISBN 978-80-86815-62-6

Mé ženě Monice, díky jejíž podpoře mohla tato kniha vzniknout.

Stručný obsah Kapitola 1

Hodnotocentrický přístup

1

Kapitola 2

Hodnotocentrické metodiky

27

Kapitola 3

Požadavky

49

Kapitola 4

Vedení projektu

79

Kapitola 5

Návrh architektury

115

Kapitola 6

Vývoj

133

Kapitola 7

Testování

165

Kapitola 8

Ohlašování chyb

205

Kapitola 9

Řešení problémů s projektem

221

Kapitola 10

Závěr

243

Obsah O autorovi Úvodem Předmluva Poděkování Kapitola 1 Hodnotocentrický přístup Změna přístupu Tři síly, se kterými se musíme smířit Jaký software má cenu budovat?

Protikladné přístupy Význam toku Rozdíl oproti úkolocentrismu Transparentnost

xvii xix xxi xxix 1 2 2 3

4 7 10 11

Jedna databáze pracovních položek

13

Sledování každodenní činnosti

17

Přizpůsobte metodiku projektu na míru Shrnutí Poznámky

Kapitola 2 Hodnotocentrické metodiky Microsoft Solutions Framework Iterativní vývoj Proč vyvíjet iterativně Délka Různé výhledy, různá míra podrobnosti Volba priorit Přizpůsobení metodiky

Správa rizik Přizpůsobte metodiku projektu na míru

21 23 24

27 28 30 30 32 33 33 35

36 37 xi

xii

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Adaptivní vs. plánovaná Tiché vědomosti vs. vyžadovaná dokumentace Implicitní vs. explicitní podpisové brány a model vedení Auditovatelnost a legislativní požadavky Předepsaná organizace vs. samoorganizace Jediný projekt vs. mnoho souběžných projektů Zeměpisné a organizační hranice

Shrnutí Poznámky

Kapitola 3 Požadavky Jakou máte vizi?

Strategické projekty Adaptivní projekty

Kdy požadavky upřesňovat Požadavky nejsou věčné Koho zajímají požadavky

Postavy a scénáře

38 39 40 41 43 43 45

46 47

49 50 51 51

52 52 53

55

Začněte s postavami Scénáře Techniky průzkumu Brzy konkretizujte Storyboardy Záběr scénářů Prověření zákazníkem Rozvíjení scénářů

55 56 57 59 60 61 62 64

Postavy a scénáře a jejich alternativy

65

Aktéři (actors) a případy užití (use cases) Uživatelské příběhy (user stories)

Scénáře potěšující, uspokojující a „nepříjemnosti“ Požadavky na kvalitu Bezpečnost a soukromí Výkon Uživatelský zážitek Kontrolovatelnost

Kanova analýza Průběh šíření technologie Sběr dat

65 66

66 67 68 69 69 70

71 73 74

OBSAH

Shrnutí Poznámky

Kapitola 4 Vedení projektu Pochopení odchylek Používání popisných metrik místo předpisujících Mnoho rozměrů zdraví projektu Odpovědi na každodenní dotazy Zbývající práce Rychlost projektu Neplánovaná práce Ukazatele kvality Počty chyb Znovuotevírání Chyby podle priority Skutečná kvalita a plánovaná rychlost

Odhad iterace Odhad shora dolů Odhad zdola nahoru Dolaďování Odhady kvality Retrospektivy

Stanovování priorit (triage) Cvičení ke stanovování priorit Díky čemu je stanovování priorit efektivní: červená čára Co se děje při stanovování priorit Eskalace a řešení problémů Iterace a stanovování priorit

Uspokojení auditora Shrnutí Poznámky

Kapitola 5 Návrh architektury Hodnotocentrický pohled na architekturu Architektura zaměřená na služby Webové služby a SOA Návrh podle kontraktu

Omezení se stupni volnosti

75 77

79 81 83 86 86 88 90 91 92 93 95 95 97

98 99 100 100 102 104

104 105 107 109 109 109

110 113 113

115 116 116 118 118

119

xiii

xiv

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Základní architektura Ověřte architektonická rozhodnutí Zpřesnění základu Referenční architektury

VSTS a architektura zaměřená na služby Postoj k požadavkům na kvalitu

119 120 121 122

124 126

Bezpečnost Výkon

127 127

Občanský postoj Návrh s ohledem na provoz Shrnutí Poznámky

128 128 131 131

Kapitola 6 Vývoj Hodnotocentrický pohled na vývoj Kvalita z hlediska vývojáře Vývoj řízený testy zajišťuje jednoznačnost požadavků Řešení programátorských chyb automatizovanými i ručními revizemi kódu

133 134 134

Automatizovaná analýza kódu Ruční revize kódu

139 140

Okamžitá zpětná vazba s testy programových jednotek a pokrytím kódu Co dřív – testy nebo kód?

Pokrytí kódu

Zdokonalování testů programových jednotek Rozmanitá data Různé konfigurace Testy integrace komponent Kontrolní testy sestavení Vylaďování výkonu

Jak předcházet odchylkám ve verzích Zanášení změn (checking-in) Používání šuplíků (shelving) Větvení Pro co používat správu verzí Automatizace sestavení

136 138

141 142 143

145 146 146 147 148 149

152 153 155 156 156 156

OBSAH

Aby byla práce transparentní Shrnutí Poznámky

Kapitola 7 Testování Hodnotocentrický pohled na testování Co dělá dobrého testera?

Základní otázky Dodáváme zákaznickou hodnotu?

161 162 163

165 166 167

169 169

Automatizované testy scénářů Odstínění testů od změn uživatelského rozhraní

172 176

Jsou požadavky na kvalitu dostatečné pro použití?

177

Zátěžové testy Testování bezpečnosti Testy použitelnosti

Otestovali jsme změny?

Co jsme neotestovali?

Požadavky Kód Rizika

Funguje to v rutinním provozu stejně dobře jako v laboratoři?

Testujeme dostatečně?

Co je „dostatečně dobré“ Průzkumné testování Testování jako objevování Falešná jistota

Kdy máme testovat?

Cyklus zanesení změn Cyklus denního sestavení Cyklus schválení sestavení Cyklus iterace Cyklus projektu

Které testy mají být automatizované?

Jak efektivní je náš tým, nebo náš outsourcovaný tým?

Shrnutí Poznámky

177 182 183

183 184 184 186 187

189 192 192 194 194 195

196 196 197 198 199 200

201 201 202 203

xv

xvi

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Kapitola 8 Ohlašování chyb Varovná příhoda Životní cyklus softwarové chyby Ohlašování chyb je jako žurnalistika Subjektivní data Objektivní data Údaje o vyhodnocení Plán

Shrnutí Poznámky

Kapitola 9 Řešení problémů s projektem Podcenění Nestejnoměrná dekompozice úkolu Hluchá místa architektury Nafukování rozsahu Neadekvátní příděl chyb Únik zdrojů

Příliš uvolněné vývojářské praktiky Selhání sestavení Nedostatečné testy programových jednotek Znovuotevírání Švindlování

Testy procházejí; řešení nefunguje Vysoká rychlost odhalování chyb Testy jsou zastaralé

Hromadění položek pro testování Testy jsou neúspěšné Testuje se příliš málo

Shrnutí Poznámky

Kapitola 10 Závěr Očekávaná kritika Ještě jednou o hodnotocentrismu Poznámky Rejstřík

249

205 207 208 210 213 214 216 218

218 219

221 223 224 224 227 229 229

229 229 231 232 233

233 233 236

236 237 238

240 241

243 244 245 247

O autorovi Sam Guckenheimer za sebou má 25 let zkušeností ar chitekta, vývojáře, testera, produktového manažera, projektového manažera a generálního manažera v softwarových společnostech v USA a v Evropě. V současné době působí jako vedoucí plánovač pro Microsoft Visual Studio Team System. Zastupuje požadavky zákazníků a zodpovídá za celkový návrh dalších vydání těchto produktů. Než začal v r oce 2003 pracovat pr o Microsoft, měl na star osti produktovou strategii v Rational Software Corporation (nyní součást IBM pod názvem Rational Division). Vlastní pět patentů týkajících se nástr ojů pro údržbu software během jeho životního cyklu. Často přednáší na oborovných konferencích.

Vystudoval Harvardskou univerzitu a je členem bratrstva Phi Beta Kappa.

Sam žije se svojí ženou a třemi ze čtyř dětí v oblasti Puget Sound.

xvii

Úvodem Téměř deset let jsem se snažil Sama Guckenheimera př esvědčit, aby napsal knihu o softwarovém inženýrství. On ale stále jen opakoval, „Ale ne, nejsem na to připraven.“ S vydáním nástroje Visual Studio Team System přišel o svoji výmluvu: teď už své názory na softwar ové inženýrství zkrátka musel vysvětlit, aby lidem pomohl pochopit pr odukt, který je na nich založen. Jsem rád, že se mu podařilo vyjádřit je v knize, která se stejnou měr ou věnuje praxi i teorii, a která nedopadla jako jedna velká r eklama nebo akademická diskuze nad filozofií softwarového inženýrství. Líbí se mi jeho konkrétní příklady: výchozí myšlenky v nich přímo ožívají.

Mezi klíčové myšlenky knihy patří „hodnotocentrické“ procesy. Sam se domnívá, že stojíme před mohutnou změnou našeho přístupu k software, a s tím lze jen souhlasit. „Úkolocentrický“ přístup zanesl do pr ocesu vývoje software řadu problémů a v důsledku způsobil neúspěch velké části pr ojektů. Zda se „hodnotocentrickému“ přístupu podaří stávající problémy vyřešit, aniž by přitom vznikly problémy nové, je samozřejmě zatím ve hvězdách.

Softwarové metriky zatím nebyly , zejména vzhledem k nár očnému sběru podkladových dat, využívány plně. Jak Sam ve své knize vysvětluje, sledování denních činností umožňující bezbolestný sběr dat otevírá metrikám nové možnosti. Sam tím ale nekončí; z metody agilního vedení pr ojektů si vypůjčil některé zajímavé techniky, na kterých ukazuje, jak každodenně řešit problémy softwarového projektu. To také umožňuje spolehlivě aplikovat hodnotocentrické metodiky.

Téměř deset let se v různých oblastech softwarového inženýrství – v programování, uživatelském zážitku, testování i architektuře – objevuje řada nápadů.

Sam z nich vybral ty nejlepší a dohromady je zapojil do celého životního cyklu xix

xx

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

softwarového díla.

Věřím, že se vám budou líbit stejně, jako se líbily mně.

Ivar Jacobson, Ph.D. Ivar Jacobson Consulting LLC

Předmluva

Proč jsem tuto knihu napsal Do společnosti Microsoft jsem přišel v roce 2003 se záměrem pracovat na nové řadě produktů Visual Studio Team System (VSTS), která byla vydána na konci roku 2005. Jako vedoucí plánovač pr oduktu jsem hrál r oli hlavního zástupce zákazníka, což byla role, ke které jsem měl vždy velmi kladný vztah. V té době jsem za sebou měl 27 let zkušeností v oboru IT, z nichž většinu jsem strávil jako tester, projektový manažer, analytik a vývojář.

Jako tester jsem vždy chápal teor etický význam pokročilých vývojářských praktik, zejména testů programových jednotek, pokrytí kódu, statické analýzy a profilování výkonu a správy paměti. Přitom mi ale nebylo dost dobř e jasné, jak může mít někdo trpělivost potř ebnou ke zvládnutí všech těch tajuplných nástrojů, které člověk potřeboval, aby mohl ty správné praktiky uplatnit.

Jako vedoucímu projektu mi vždy vadilo, že jediná pořádná data, která jsme mohli získat, se týkala chyb. Řídit projekt jen na základě údajů o chybách v programech je jako řídit auto se zavázanýma očima a točit volantem teprve tehdy, když do nečeho narazíte. Ve skutečnosti chcete z něčeho poznat, že postupujete tím správným směrem – nejen, že jste z něj sešli. I zde jsem vždy oceňoval různé metriky, například pokrytí kódu nebo rychlost pr ojektu, ale nikdy jsem nechápal, jak by bylo možné pro ně získat podkladová data.

Jako analytik jsem si zamiloval modelování. Uvažuji vizuálně a grafické modely považuji za šikovný způsob dokumentace a komunikace. Ale jakmile přijde na implementaci, modely ztrácejí kontakt s realitou projektu. A nedovedou pochytit charakteristiky, které jsou pro vývojáře, testery a fungování software nejdůležitější. xxi

xxii

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

A ve všech těchto případech mě velmi trápilo, jak obtížné bylo sdělit úplný obrázek všem členům týmu. Líbila se mi myšlenka „jednotného úkolníku produktu“ pocházející z metodiky Scr um (jedné z agilních metodik) – jediného místa, kde můžete sledovat pr ůběh všech prací – ale používané nástr oje se takovému jednotnému přístupu zuby nehty bránily . Co mají tyto požadavky společného s těmito úkoly, tamtěmi prvky modelu a tady těmito testy?A jak do toho zapadá zdrojový kód?

Když se podívám zpět do historie, mám dojem, že mezi klíčové okamžiky IT patří ten, kdy se obor př estal snažit o automatizaci r učních procesů a místo toho se zeptal: „Jak můžeme s využitím automatizace př epracovat naše základní podnikatelské procesy?“ Tehdy obor začal přinášet skutečné obchodní hodnoty. Říká se, že kovářova kobyla chodí bosa. Stejně tak to platí i pr o IT. Zatímco jsme se ze všech sil snažili automatizovat ostatní podnikatelské procesy, na ten svůj jsme z větší části zapomněli. Téměř všechny nástroje určené pro IT profesionály a týmy, zdá se, stále automatizují staré ruční procesy. Před automatizací trpěly tyto procesy velkou režijí, které se nezbavily ani po automatizaci. Kolikrát jste byli na hodinové poradě, na kter é první hodinu a půl zabrala hádka o tom, čí čísla jsou ta správná?

S příchodem Visual Studio Team System se tedy zcela vážně ptáme: „Jak můžeme s využitím automatizace př epracovat naše základní podnikatelské procesy? Jak můžeme dobr é procesy zbavit režie? Jak můžeme zvýšit individuální produktivitu všech těchto různých rolí a přitom je spojit do výkonného týmu?“

Kdo by si měl tuto knihu přečíst Tuto knihu jsem napsal pro softwarový tým, který zvažuje používat pro práci na svém projektu prostředí VSTS. Zabývá se odpovědmi na otázky proč, ne jak.1 Co patří mezi nosné myšlenky VSTS? Proč jsou určité myšlenky prezentovány určitým způsobem? Například, pr oč je tolik věcí označováno jako pracovní položky (work items)? Co měří datový sklad metrik (metric warehouse)? Proč budete používat tyto druhy reportů?

V minulosti jsem se znovu a znovu př esvědčil o tom, že vzdělaní, zr uční a zkušení lidé přistupují k softwarovým projektům s různými výchozími předpoklady. To, co je pro jednoho samozřejmá pravda, je pro druhého jen pověra, a to, co jeden považuje za součást běžného povědomí je pr o druhého převrat-

PŘEDMLUVA

nou novinkou. Přirozený důraz na funkční role, které bývají často zabudovány do profesních odvětví, tento problém ještě zhoršuje. Samozřejmě, že nepochybuji o tom, že mohu narazit na špičkové vývojář e, špičkové testery, špičkové architekty, špičkové obchodní analytiky a špičkové pr ojektové manažery, ale získat něco, co bude hodnotné pro zákazníka, vyžaduje spolupráci mezi všemi disciplínami. Snaha optimalizovat jednu konkr étní roli bez ohledu na ostatní, nemusí kvalitu výsledku v očích zákazníka nijak zlepšit.

Jednou z možností, jak se s rozdíly vypořádat, představuje přítomnost kouče, který dovede tým pr ovést konzistentní skupinou pr ocesů. Koučové jsou výborní, ale ne každý si může dovolit s nimi pracovat. A protože vám nemohu poslat kouče, který by vám byl v případě potřeby k dispozici, napsal jsem tuto knihu.

Tato kniha není podrobným návodem v tom smyslu, že byste se v ní dozvěděli, kam a v jakém pořadí klepnout. K tomuto tématu najdete spousty dobr é dokumentace přímo ve VSTS, a já se na ni budu na odpovídajících místech odkazovat. Tato kniha naopak poskytuje základní rámec, ve kter ém můžete o softwarových projektech přemýšlet takovým způsobem, jenž můžete přímo přenést do VSTS. Ve skutečnosti jsme právě tak VSTS navrhnuli.

Tato kniha také nemá být přehledem literatury věnované softwarovému inženýrství. V posledních čtyřiceti letech byly o tomto tématu napsány desítky , ne-li stovky, knih. Nesnažím se o jejich shrnutí, ani nepokrývám vše co ony .

Nijak mě nepřekvapí, když mi odborníci budou vytýkat, že někter é z mých argumentů se v současné době považují za samozř ejmé. Ale bohužel jak poukázal Sigmund Freud, samozřejmé věci bývají často př ehlíženy. Díky tomu se může stát, že rozdíly mezi myšlenkovými světy členů týmu vyplují na povrch teprve tehdy, když se o nečem pohádají. Takže jestliže mi máte za zlé, že říkám příliš mnoho jasných věcí, přiznávám, že tomu tak opravdu je.

Prezentuji zde dostatek teorie a praktických příkladů, aby s nimi bylo možné popsat r ealistickou metodiku pr o většinu typických IT pr ojektů a týmů.

Nemusí být dost formální, aby vyhověla nár okům na software pro avioniku, vyžadující schválení Federální úřadu pr o letectví; nemusí být dost volná, aby vyhovovala tříčlenému týmu, který pracuje v garáži.

xxiii

xxiv

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Jak tuto knihu číst Součástí VSTS je mechanismus řízení pr ocesu nazvaný Micr osoft Solutions Framework (MSF), který obsahuje základní ideu modelu týmu, vycházející ze skupiny r ovnocenných kolegů. Model týmu umožňuje r ůznou míru specializace. MSF definuje sedm okr uhů, nebo také úhlů pohledu, kter é musejí být v úspěšném procesu zastoupeny, a obsahuje i rady, jak tento model přizpůsobit požadovaným nár okům. Tyto úhly pohledu v knize označuji takovýmito symboly:

Projektové řízení

Architektura

Vedení produktu

Vývoj

Uživatelská zkušenost

Testování

Nasazení

Aspekt

Obrázek 0.1 Microsoft Solutions Framework zavádí model týmu rovnocenných kolegů, rozdělených na sedm úhlů pohledu, které musejí být v úspěšném projektu zastoupeny. MSF for CMMI Process Improvement těchto sedm oblastí specializuje na osmnáct, zatímco MSF for Agile Software Development vystačí se šesti (slučuje Vedení produktu a Uživatelský zážitek) a je připraveno snížit jejich počet na tři.

PŘEDMLUVA

Kniha je napsána pro celý tým. Informace prezentuje tak, aby si každý člen týmu mohl udělat obrázek o tom, jak celou situaci vidí ostatní. Části týkající se konkrétních rolí jsou přitom označeny, takže se můžete zaměřit pouze na ty pasáže, které sami potřebujete. Snažil jsem se jednotlivá témata pokrýt takovým způsobem, který by byl zajímavý pro všechny členy týmu a nikoho neodrazoval. (Pro někoho může být toto rozhodnutí dalším důvodem, proč ji kritizovat pro její jednoduchost.) Já osobně si i př es specializaci, která je pr o tuto dobu typická, myslím, že je důležité mít – alespoň na této úrovni – vazbu na své kolegy a představu o tom, co by měli dělat. Nemáte-li času nazbyt, můžete si podle symbolů okruhů vybrat jen témata pro ty role, které vás zajímají nejvíce.

Odkazy na dokumentaci Jak jsem již řekl, tato kniha není soubor návodů. Když bude na místě upozornit na některé detaily VSTS nebo na jeho dokumentaci, uvidíte takovýto odkaz: Microsoft Developer Network (MSDN) Součástí každého VSTS je i přístup do Microsoft Developer Network.

Začněte na http://msdn.microsoft.com/teamsystem a následujte odkazy Reference Product Documentation. Můžete se setkat s řadou termínů, jejichž význam si možná budete chtít upřesnit.

Najdete je v tématu: Development Tools and Technologies Visual Studio Team System Visual Studio Team System Glossary

Udělal jsem to takto, protože předpokládám, že tuto knihu většinou nebudete číst u počítače, ale někdy se k němu budete chtít vrátit a zkusit něco prakticky.

Při obyčejném čtení tak můžete tyto odkazy prostě přeskočit.

Myšlenky ostatních V této knize chci uvést myšlenky stojící za VSTS, ale přitom netvr dím, že jsou původní. VSTS bylo od základů navrženo tak, aby umožnilo postupovat podle různých metodik a bylo tak použitelné pr o různé organizace a projekty. VSTS

xxv

xxvi

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

a tedy i tato kniha se nebojí využívat osvědčené postupy,které se ve vývojářské komunitě objevily. Všude, kde to bylo možné, jsem se snažil uvést odkazy na odpovídající zdroje v poznámkách na konci kapitol. Jestliže vás tyto odkazy nezajímají, není nutné poznámky číst.

Hrubý přehled VSTS Recenzenti prvních verzí této knihy mi vytýkali, že jsem nikde dostatečně jasně nevysvětlil, z čeho se vlastně VSTS skládá, a tak to napravuji poznámkou na další straně, která pochází přímo z webových stránek společnosti Micr osoft.

V současné době jsou k dispozici čtyři klienti VSTS a v budoucnu se mohou objevit další, ale já mezi nimi nerozlišuji, protože tím hodnotným je Team Suite.

Microsoft vám umožňuje vybrat si požadovanou funkcionalitu př esně, ale já věci nechci dělat složitějšími, než je bezpodmínečně nutné.

Takže když budu psát o „VSTS“ nebo o „Team System,“ předpokládejte, že píši o Team Suite.

Jednou ze součástí VSTS je metodika Microsoft Solutions Framework (MSF), který je na obrázku 0.2 znázorněn rámečkem „Řízení pr ocesu“. Standardně se dodává ve dvou variantách, které lze upravit na nespočet vlastních: • MSF for Agile Software Development • MSF for CMMI Process Improvement Později se budu oběma věnovat podr obněji, ale v podstatě se dá říci, že když se softwarovými metodikami začínáte, měli byste použít MSF for Agile Software Development, a když máte r ozptýlený tým, zavádíte pr ogramy pro optimalizaci procesů, procházíte audity nebo toužíte po certifikaci CMMI, měli byste popřemýšlet o MSF for CMMI Process Improvement.

Dále budu mluvit př evážně o myšlenkách společných oběma variantám, a když se daná věc bude týkat jen jedné z nich, upozorním na to.

PŘEDMLUVA

xxvii

Seznámení s Visual Studio 2005 Team System

Visual Studio 2005 Team Suite Visual Studio 2005 Team Edition for Developers

Visual Studio 2005 Team Edition for Architects

Visual Studio 2005 Team Edition for Testers

Visual Studio 2005 Team Edition for Database Professionals

Visual Studio Team Foundation

Oboroví partněři pro Visual Studio

Průvodce produktem a architekturou

Z reklamního oddělení společnosti Microsoft

Visual Studio 2005 Team Edition for Software Developers nabízí pokročilé vývojářské nástroje, se kterými mohou týmy připravovat spolehlivé služby a aplikace, použitelné i v těch nejnáročnějších podmínkách.

Visual Studio 2005 Team Edition for Software Architects přináší vizuální návrháře, se kterými mohou architekti, správci infrastruktury a vývojáři navrhovat řešení poskytující služby, která lze validovat proti svému operačnímu prostředí.

Visual Studio 2005 Team Edition for Software Testers poskytuje pokročilé nástroje pro testování zátěže, které týmům umožňují ověřit výkon aplikace ještě před jejím praktickým nasazením.

Visual Studio 2005 Team Suite spojuje všechny tyto produkty do všezahrnujícího nástroje pro správu životního cyklu softwarového díla, který bere v úvahu potřeby víceúčelových rolí v rámci organizace.

Všechny tyto produkty využívají služeb rozšiřitelného serveru zajišťujícího týmovou spolupráci, Visual Studio 2005 Team Foundation Server který všem členům rozšířeného IT týmu umožňuje snadno řídit a sledovat průběh a zdraví svých projektů.

Visual Studio 2005 Team Edition for Database Professionals přináší zajímavé možnosti pro změnové řízení, testování a nasazení databázových projektů. Každý, kdo vytváří aplikace pro SQL 2000 nebo 2005 v něm určitě najde řadu užitečných funkcí pro svoji každodenní práci.

Obrázek 0.2 Visual Studio 2005 Team System sestává ze čtyř klientských produktů a jednoho serverového.

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

xxviii

Prohlášení Nakonec musím ještě výslovně upozornit na to, že vešker é názory prezentované v této knize jsou mé vlastní a nemusejí se nutně shodovat s těmi, kterými se prezentuje společnost Micr osoft. Ačkoliv jsem v této společnosti zaměstnán, píši sám za sebe a ne za společnost. Mé názory a chyby pr oto nepřisuzujete Microsoftu (snad jen kdybyste jim chtěli říci, že si nevybrali dobr ého zaměstnance), ale jen a jen mě. Když budete chtít, můžete se se mnou pohádat přímo na mém blogu na http://blogs.microsoft.com/sam/.

Poznámky 1.

Jestliže se s VSTS chcete naučit pracovat, poslouží vám kniha Willa Scotta a Jamese Newkirka Visual Studio Team System – Better Software Development for Agile Teams (Boston, MA: Addison-Wesley, 2006).

Poděkování S psaním této knihy velmi pomohly podněty řady lidí. Rád bych nejprve poděkoval své r edaktorce, Karen Gettmanové, která byla ochotná zabývat se začínajícím autorem, majícím vizi a něco, co může nabídnout. Důležitými učiteli pro mě byli Ivar Jacobson a Cem Kaner , kteří mě mnoho let pobízeli k tomu, abych něco napsal.

Dalším je Rick LaPlante, který je v mém zaměstnání pořád mým šéfem.

Když hledal produktového plánovače pro skupinu Visual Studio Team System, nebál se na mě vsadit, a po celou tu dobu byl šéfem velmi vstřícným a nápomocným. Vedle Ricka samozřejmě chci zmínit i pár set kolegů, díky kterým je VSTS tím, čím je. Každý kontakt s nimi pr o mne byl a stále je po intelektuální stránce velmi přínosný.

Jak uvidíte, z velké části vycházím z práce Granvilla („Randyho“) Millera a Davida J. Andersona, kteří mají na svědomí MSF forAgile Software Development a MSF for CMMI Process Improvement. Při práci na MSF v4 jsme si užili nesčetných debat a objevů, a tato zkušenost měla na to, co zde čtete, zásadní vliv.

Juan J. Perez, můj spoluator, a Kim Tapia St. Amant ze společnosti Personify Design se postarali o bohaté příklady a ilustrace v knize. Pracoval jsem s nimi velmi rád.

A nakonec musím poděvat mnoha recenzentům, mezi které patří Jeff Beehler, James Behling, Charlie Bess, Rossen Blagoev, Rob Caron, Wendy Chunová, Kevin P. Davis, Cristof Falk, Linda Fernandezová, Ken Garove, Bill Gibson, Martin Heller, Bijan Javidi, Yulin Jin, Cem Kaner , Chris Kinsman, Aaron Kowall, Clementino Mendonca, Thomas Murphy, Gary Pollice, Tomas Restrepo, Johanna Rothmanová, Joel Semeniuk, W ill Stott, Dan Sullivan, David T rowbridge, Mike Turner, Kumar Vadaparty a Peter W illiams. Ve finiši mi velmi pomohli xxix

xxx

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Kim Boedigheimerová, Ben Lawson a Michael Thurston z Addison-Wesley.

Bez jejich rad a návrhů by tato kniha byla jen stínem toho, čím teď je.

Sam Guckenheimer Redmond, Washington, USA

1

Hodnotocentrický přístup „Každá teorie by měla být tak jednoduchá, jak je to jen možné, ale ne jednodušší.“ – Albert Einstein

Obrázek 1.1

Einsteinova speciální teorie relativity způsobila změnu našeho přístupu k chápání fyziky.

Završila čtyřicet let trvající dohady týkající se nejpalčivější technické otázky té doby – jak synchronizovat hodiny a jak přesně kreslit mapy rozsáhlých území.

(Fotografie zveřejněna se souhlasem Hebrew University of Jerusalem, Izrael.)

1

2

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Změna přístupu Ke změnám v přístupu dochází náhle a nepravidelně, když star é teorie již nedovedou vysvětlit svět, jak jej vnímáme. 1 Ukázkovým příkladem z věděckého světa je speciální teorie r elativity Alberta Einsteina, publikovaná r oku 1905.

Einstein popsal newtonovskou mechaniku jako zvláštní případ obecnějších principů, čímž ukončil čtyřicet let diskuzí o podstatě času a souběžnosti a z velké části udal směr vědy, technologií a světových událostí ve dvacátem století.

Podle posmrtné legendy, kterou mnozí z nás znají ze školy , byl Einstein osamoceným teoretikem, pro kterého byla jeho práce úředníka na patentovém úřadě jen rozptýlením od jeho skutečné vášně, fyziky. Přitom je tento zažitý obraz zcestný. Ve skutečnosti se většina přihlášek, které posuzoval, týkala přesně těch fyzikálních problémů, které jej fascinovaly – synchronizace času na velké vzdálenosti k různému účelu, například pro tvorbu železničních jízdních řádů, námořních tabulek a přesných územních map, o které byl v době koloniálních výbojů velký zájem. Speciální teorie r elativity přinesla matematické ř ešení všech těchto problémů a uzavřela desítky let trvající věděcké spory.

Einstein nebyl jediným, kdo tento matematický pr oblém roku 1905 vyřešil – Henri Poincaré, který svou proslulostí v té době Einsteina výrazně př evyšoval, vypracoval alternativu, která ovšem zapadla. 2 Proč se dnes v každé učebnici fyziky setkáme s ř ešením Einsteinovým? Poincarého výpočty vycházely z existence „éteru“, předpokládané výplně prostoru, která prostupovala celou fyzikou 19. století. Na dr uhou stranu teorie Einsteinova využívala mnohem jednodušší výpočty, které se bez éter u obešly. Jednalo se o první významný příklad principu, který je – také posmrtně – připisován právě Einsteinovi: „Každá teorie by měla být tak jednoduchá, jak je to jen možné, ale ne jednodušší.“

Tři síly, se kterými se musíme smířit Ve vývoji softwaru nyní dochází k podobnému posuvu, k jakému došlo ve fyzice před sto lety. Jednoho víkendu roku 2001 se sešlo 17 předních osobností tohoto oboru s cílem pr obrat „metody s nízkou r ežií“. Setkání zakončili založením organizace Agile Alliance, vycházející z pr ohlášení Agile Manifesto.3 Původně se jednalo o heslo lidí, kteří v tehdejších softwar ových metodikách viděli obdobu „éteru“ fyziky 19. století – zbytečnou komplikaci a překážku pro výkonnost. O pět let později se „agilita“ stala hlavním proudem. Propaguje ji

HODNOTOCENTRICKÝ PŘÍSTUP

každý oborový analytik, každý řídicí pracovník ji bere za svoji a každý se snaží z ní získat ještě více.

V tutéž dobu do hry vstupují dva další vnější ekonomické vlivy . Jedním je celosvětová konkurence. Spojení ekonomické liberalizace, nár ůstu přenosových kapacit komunikačních kanálů a dostupnost vzdělaných pracovních sil na rodících se trzích způsobilo, že se př esun softwarového vývoje do zemí s nižšími platy (zejména do Indie) stal finančně výhodným. 4 Indické poradenské společnosti na druhou stranu potřebují prokázat svým americkým a evropským zákazníkům požadovanou úr oveň kvality. Mnohé se chytily metodiky Capability Maturity Model Integration (CMMI) navržené v Softwar e Engineering Institute na Carnegie Mellon University .5 CMMI představuje typického zástupce těžkopádných metodik, pr oti kterým se „agilisté“ vzbouřili, a byla považována za příliš drahou pr o nasazení v jiných oblastech, než je válečný průmysl. Společnosti v jiných zemích si díky svým cenovým výhodám nemusely dělat těžkou hlavu z dodatečných nákladů a mohly důvěryhodnost CMMI auditu využít jako konkurenční výhodu.

Druhým ekonomickým faktor em je větší důraz na dodržování př edpisů, způsobený nedbalými obchodními praktikami z 90. let. V USA ztělesňuje tuto tendenci Sorbanesův-Oxleyho zákon (SOX) z roku 2002, podle kterého jsou za klamavé účetní výkazy trestně zodpovědní řídící pracovníci společností. V důsledku toho se software a systémy zpracovávající finanční informace octily pod daleko větším dohledem a kontrolami, než tomu bylo kdykoliv dříve.

Tyto síly – agilita, přesun vývoje do jiných států a shoda s př edpisy – nelze vyřešit, aniž by došlo ke změně v našem přístupu k životnímu cyklu softwaru.

Dnešní ekonomická situace vyžaduje pr užnost spojenou se zodpovědností.

Kombinace těchto dvou extrémů vyžaduje nový přístup jak k samotné metodice, tak k jejím nástrojům.

Jaký software má cenu budovat?

Abyste mohli tyto dva požadavky spojit, musíte si uvědomit, že softwar ové inženýrství se od všech ostatních inženýrských disciplín odlišuje. Když stavíte třeba most, silnici nebo dům, můžete bez problémů nastudovat stovky podobných příkladů. A ekonomická realita vás většinou nabádá provést nový projekt podobně, jako ten poslední, abyste se vyhnuli možným rizikům.

U software je to naopak, takže když někdo již systém víceméně odpovídající vašim potřebám postavil, existuje dost vysoká pravděpodobnost, že byste si

3

4

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

k němu mohli zakoupit licenci (nebo jej dokonce získat bezplatně). Žádná r ozumná firma nebude vydávat peníze na vývoj softwar e, který může zakoupit levněji. Protože pod komerčními licencemi jsou dostupné tisíce softwar ových produktů, téměř vždy se vám vyplatí si je zakoupit. Pr otože rozhodnutí o vývoji software musí být založeno na spolehlivé návratnosti investic a r ozboru rizik, pracuje se téměř bez výjimky na takových softwarových projektech, které nejsou komerčně dostupné.

Toto obchodní prostředí má na charakter softwar ových projektů velmi významný vliv. Znamená totiž, že softwarové projekty, které jsou snadné a bezrizikové, protože již byly v minulosti realizovány, nezískají finanční prostředky.

Jediný software, který bude vyvíjen, je ten, který se objevuje poprvé nebo jehož předchůdci nejsou veř ejně dostupní. Tato podnikatelská r ealita představuje hlavní příčinu toho, proč je vývoj software tak náročný a riskantní a proč je tak důležité řídit se správnou metodikou.6

Protikladné přístupy Nejistota, která tvoří nedílnou součást softwarových projektů, ztěžuje správný odhad úkolů, což má za následek velký r ozptyl přesnosti odhadů. Typickou mylnou představou je, že to nevadí, pr otože se kladné i záporné odchylky zprůměrují. Ale softwarové projekty se skládají z dlouhých ř etězců navzájem závislých událostí, tak se tyto odchylky kumulují a mají za následek opožď ování pozdějších fází projektu.7 Naneštěstí pochází většina obecně přijímaných znalostí o vedení pr ojektů ze světa silnic a mostů. V tomto světě je návr h spojen s malými riziky , jeho cena je v porovnání s budováním nízká a jen zřídkakdy lze hodnotu dodávat inkrementálně. (Přes zpola hotový most přece přejet nemůžete!) Při takovémto způsobu plánování nejprve rozhodnete inženýrský návrh, pečlivě jej rozdělíte na implementační úkoly, které naplánujete a vybavíte podle jejich závislostí a dostupnosti zdrojů, a průběh projektu sledujete tak, že si odškrtáváte hotové úkoly (nebo sledujete, kolik procent celku je již hotovo). Pro jednoduchost budu tomuto způsobu vedení projektu říkat úkolocentrický (work-down), protože jeho centrálním motivem je posloupnost konkrétních úkolů. Úkolocentrický přístup nachází uplatnění u inženýrských pr ojektů s nízkými riziky, malým rozptylem a dobře známým návrhem. Například mnohé IT projekty spočívají v přizpůsobení běžně dostupného komer čního software, například podnikového systému pr o plánování zdr ojů. Vývoj často vedle

HODNOTOCENTRICKÝ PŘÍSTUP

obchodního rozboru, vedení projektu a testování představuje jen malý zlomek celého projektu. Tyto projekty vykazují obvykle menší odlišnosti než vývoj něčeho zcela nového, takže znalosti ze světa silnic a mostů zde fungují lépe než u nového vývoje.

Od roku 1992 8 je úkolocentrické nahlížení na softwar ové metodiky stále silněji konfrontováno s jiným pohledem. Rodící se přístup zatím nezastř ešuje žádný jednotný termín, ale já mu pro jednoduchost budu říkat přístup hodnotocentrický (value-up). A jak už to s novými přístupy bývá, ani tento se neobjevil najednou a rovnou ve své finální podobě (viz obrázek 1.2).

Obrázek 1.2

Hodnocentrický

Hodnota

Zbývající práce

Úkolocentrický Plán Úkol 1 Úkol 2 Úkol 3 Úkol 4 ... ... ...

Základní rozdíl mezi úkolocentrickým a hodnotocentrickým přístupem spočívá ve výchozím měřítku. Úkolocentrický přístup považuje projekt za pevný seznam úkolů jisté ceny, které je třeba dokončit, a výdaje měří podle těchto úkolů. Hodnotocentrický přístup měří hodnotu, která je v jednotlivých okamžicích dodávána, a na vstupy nenahlíží jako na pevnou zásobu, ale jako na proměnlivé toky.

Jako příklad hodnotocentrického uvažování si vypůjčím pr ohlášení Declaration of Interdependence.9 Formuluje šest prinicpů, kter é tento přístup charakterizují: • Zaměříme se na průběžné vytváření hodnoty, čímž zvýšíme návratnost investic.

• Zákazníka zapojíme do častých konzultací a sdílíme s ním vlastnictví projektu, a tak dodáme spolehlivé výsledky.

• Očekáváme nejistotu a jsme na ni díky iterativnímu vývoji, předvídání a přizpůsobení připraveni.

• Chápeme, že nejzákladnějším zdrojem hodnoty jsou jednotlivci, a vytvoříme jim takové prostředí, kde mohou něco znamenat, čímž povzbudíme tvořivost a vynalézavost.

5

6

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

• Výkon povzbuzujeme skupinovou zodpovědností za výsledky a sdílením zodpovědnosti za efektivitu týmu.

• Efektivnost a spolehlivost zvyšujeme nasazováním strategií, metodik a postupů, které odpovídají situaci.

Za těmito principy se skrývá od základu jiný úhel pohledu, kterým se hodnotocentrické uvažování liší od úkolocentrického. Rozdíly mezi nimi shrnuje tabulka 1.1.

Tabulka 1.1 Základní rozdíly mezi úkolocentrickým a hodnotocentrickým přístupem Výchozí předpoklad

Úkolocentrický přístup

Hodnotocentrický přístup

Plánování a změny

Plánování a návrh jsou činnosti, které musejí být bezpodmínečně bezchybné. Musíte je provést nejdříve, rozdělit zodpovědnost za plán, sledovat plnění plánu a pečlivě bránit tomu, aby se do něj nedostaly nějaké změny.

Změna je přirozená; smiřte se s tím. Plánování a návrh probíhá během celého projektu. Úvodnímu plánování a návrhu by proto mělo být věnováno jen tolik prostředků, abyste pochopili rizika a mohli provést další malý inkrement.

Primární měřítko

Dokončování úkolů. Protože známe kroky vedoucí ke konečnému cíli, můžeme měřit všechny průběžné výsledky a již získanou hodnotu vypočítat jako poměr spotřebovaného a celkového naplánovaného času.

Počítaji se jen výsledky, které jsou pro zákazníka hodnotné (fungující software, hotová dokumentace atd.).

Tok pracovních proudů musíte měřit frontami produkujícími hodnotu pro zákazníka a všechny průběžné míry musíte brát s odstupem.

Definice kvality

Splnění specifikace. Proto musí být správná hned na začátku.

Hodnota pro zákazníka. Její vnímání se může změnit (a pravděpodobně k tomu dojde).

Zákazník může být schopen kvalitu formulovat teprve tehdy, když poprvé dostane fungující software. Možnosti proto ponechejte otevřené, přizpůsobte se neustálému dodávání a specifikaci nekonkretizujte předčasně.

HODNOTOCENTRICKÝ PŘÍSTUP

Výchozí předpoklad

Úkolocentrický přístup

Hodnotocentrický přístup

Přijatelnost odchylek

Úkoly lze rozpoznat a odhadnout dopředu. Odchylkami se nemusíte zabývat.

Odchylky tvoří součást všech procesních toků, přirozených i umělých. Abyste dosáhli předvídatelnosti, musíte odchylky pochopit a snížit jej.

Průběžné výstupy

K rozdělení návrhu a naplánování úkolů jsou nezbytné dokumenty, modely a jiné průběžné artefakty, které vedle toho umožňují měřit stávající pokrok.

Průběžná dokumentace by měla minimalizovat nejistotu a odchylky tak, aby se zlepšil tok výstupů. Cokoliv navíc je zbytečné.

Přístup k řešení problémů

Omezení času, zdrojů, funkcionality a kvality určují, co můžete dosáhnout. Když změníte jedno, musíte tomu ostatní přizpůsobit.

Pečlivě hlídejte změny, aby se do plánu nedostaly takové, se kterými se nepočítá.

Omezení se mohou a nemusejí týkat času, zdrojů, funkcionality nebo kvality. Místo toho najděte hlavní slabé místo omezující tok hodnoty, pracujte na něm aby přestal být nejdůležitější, a potom přejděte k dalšímu. Hladší tok zajistíte dalším snižováním odchylek.

Přístup k důvěře

Lidi je nutné sledovat a porovnávat se standardy. Vedení by mělo jednotlivce za jejich výkon při plnění plánu odměňovat.

Radost z dobře odvedené práce a týmové spolupráce je lepší motivací než individuální odměny. Důvěryhodné průhledné prostředí, kde všichni členové týmu mohou vidět celkovou výkonnost, funguje lépe než nařízení shora.

Význam toku Jádro hodnotocentrického přístupu spočívá v důrazu na tok (flow). Slovo tok má v tomto směr u dva významy a oba dva jsou pr o plánování softwarových projektů důležité.

První je tok zážitkový, což je stav doprovázející perfektní výkon, jak ve své knize Flow: The Psychology of Optimal Experience vysvětluje Mihaly Csikszentmihalyi:

7

2

Hodnotocentrické metodiky Vyšší management Projektový manažer „Jedna metodika těžko bude tou jedinou „správnou“, ... pro každý projekt a realizační tým existuje jiný „správný“ způsob práce.“1 – Alistair Cockburn

Obrázek 2.1

Rytmus posádky veslujcí jako jeden muž představuje perfektní příklad obou významů toku. Jednotlivci pociťují euforii z ideálního výkonu a díky sladěné týmové práci může svého ideálního výkonu dosáhnout i celý systém (v tomto případě veslice).

V předcházející kapitole jsem vysvětloval význam hodnotocentrického přístupu. V této kapitole se mu budu věnovat podr obněji, a podívám se na charakteristiku takovýchto metodik, na konkr étní podmínky, které je nutné vzít v úvahu, a příklady, které můžete využít.

27

28

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Softwarové metodiky dostupné ve VSTS Spolu s VSTS se dodávají dvě metodiky, které jsou obě variantou Microsoft Solutions Framework (MSF): • MSF for Agile Software Development • MSF for CMMI Process Improvement Můžete si je stáhnout z http://msdn.microsoft.com/msf/ a podívat se na ně. Tato webová stránka také obsahuje odkazy na mnoho metodik dodávaných partnerskými společnostmi, včetně SCRUM, FDD a EUP. Metodiky MSF si také můžete přizpůsobit na svou vlastní šablonu procesu.

Microsoft Solutions Framework Existují desítky zdokumentovaných softwar ových metodik.2 Mnoho z těch, které se v posledních 30 letech objevily, vycházejí z úkolocentrického přístupu a k popsání všech svých myslitelných očekávaných i neočekávatelných situací vyžadují ohromné množství dokumentace. 3 Manažeři chtěli mít jistotu, aniž by si uvědomili, jaké to bude mít důsledky na produktivitu práce. Myšlenka se tak obrátila proti nim. Když týmy nevědí, bez čeho se mohou bez obav obejít, zahrnou do svého plánování a výkonu vše. Tento problém dobře vystihli Barry Boehm a Richard Turner: Budujte svoji metodiku zdola nahoru, nepřizpůsobujte ji shora dolů Metodiky založené na plánu mívaly ve zvyku vést na všezahrnující metody, které lze přizpůsobit na míru konkrétní situaci. To dovedou odborníci; ostatní ale pro jistotu raději používají vše, což má často za následek zbytečně vysoké náklady. Agilní přistup nabízí lepší alternativu – začít s poměrně malou skupinou postupů a další přidávat teprve tehdy, když lze jednoznačně prokázat jejich výhodnost.4 Podobně většina metodik a nástr ojů brání dostatečné pestr osti projektů a své týmy nutí k „univerzálnímu“ přístupu. VSTS je opr oti tomu pr ostředí pro spolupráci a vývoj, kter é dovoluje mít pr o každý pr ojekt vlastní metodiku.

Také předpokládá, že tým si metodiku „natáhne na míru“ – tzn. vezme několik

HODNOTOCENTRICKÉ METODIKY

základních hodnot a postupů a podle potřeby přidá další. Jak uvádí předchozí citát, byl tento přístup mnohem úspěšnější.

V Team System existují dvě plnohodnotné metodiky , obě vycházející ze společného základu nazvaného Microsoft Solutions Framework (MSF): • MSF for Agile Software Development. Prostá metodika, držící se principů Agile Alliance.5 Metodiku MSF Agile používejte u projektů s krátkou životností a u týmů, pro které je důležitý výsledek a které mohou pracovat bez hory průběžné dokumentace. Je to pružný rámec, který vám pomůže vytvořit přizpůsobivý systém pro vývoj software.

Předpokládá nutnost reagovat na změny, zdůrazňuje dodávání fungujícího software a jako hlavní měřítko úspěchu propaguje prověření zákazníkem.

• MSF for CMMI Process Improvement. Metodika navržená tak, aby vyhovovala CMMI 3. úrovně podle definice Software Engineering Institute.6 Rozšiřuje MSF Agile o formálnější plánování, více dokumentace a pracovních výsledků, více podpisových bran a podrobnější sledování času. MSF for CMMI své činnosti jasně ukazuje v Oblastech činnosti (Practice Areas) a Cílech (Goals), čímž vychází vstříc organizacím, které CMMI používají jako základ pro vylepšení svých procesů, nebo které usilují o hodnocení CMMI. Ale narozdíl od předchozích pokusů o metodiku CMMI používá MSF hodnotocentrický přístup, který umožňuje celý rámec CMMI aplikovat agilně a bez zbytečné režie.7 Obě instance MSF jsou hodnotocentrické. V obou případech MSF využívá ověřené postupy společnosti Microsoft a jejích zákazníků a oborových zkušeností.

Hlavní rozdíl mezi nimi spočívá v úrovni formality schvalování, míře sledování vynaloženého výkonu a hloubce použitých metrik. Například MSF for CMMI Process Improvement považuje hodnotitele nebo auditora za samostatnou roli a poskytuje činnosti a reporty, které může auditor při hodnocení metodiky použít. V jeho agilním příbuzném se shoda se vzorovou metodikou neuvažuje.

Hladká integrace obou variant MSF do T eam System podpor uje rychlý iterativní vývoj s neustálým učením se a zdokonalováním. Společná databáze pracovních položek a datový sklad metrik přinášejí odpovědi na otázky ohledně zdraví projektu téměř okamžitě, a díky spojení pr ůvodce metodikou s nástroji můžete vidět postupy metodiky přímo v nástr ojích a podle potřeby se jimi řídit.

29

30

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Iterativní vývoj MSF je iterativní a inkrementální metodika. Význam iterativního vývoje komunita softwarových vývojářů chápe již déle než dvacet let. Obvykle se tím myslí „způsob vývoje softwar e, při kter ém definice požadavků, návr h, implementace a testování pr obíhají částečně souběžně a cyklicky (místo aby pr obíhaly lineárně), takže výsledný softwarový produkt je dokončován postupně“. 8 Cyklický vývoj vznikl jako lék na lineární „vodopádový“ vývoj. Fred Brooks, jehož kniha Mythical Man Month stále patří mezi nejvíce ceněné knihy o softwarovém inženýrství, shrnuje princip vodopádu takto: Základní chybou vodopádového modelu je předpoklad, že projekt projde celým procesem jen jednou, že architektura je vynikající a snadno použitelná, návrh implementace je bezproblémový, realizace je po otestování neměnná. Jinak řečeno – předpokládá, že chyby se budou týkat pouze realizace a jejich oprava tedy může být snadno zahrnuta do testování komponent a systému.9

Proč vyvíjet iterativně Pro iterativní vývoj mluví řada velmi příjemných důvodů: 1. Řízení rizik. Požadovaný výsledek není dopředu znám. Abyste mohli mít rizika pod kontrolou, musíte své požadavky a předpoklady v návrhu obhájit nebo vyvrátit tak, že budete prvky cílového systému implementovat postupně, těmi nejriskantnějšími počínaje.

2. Hospodárnost. V nejistém obchodním prostředí je důležité, abyste své priority často promýšleli a investice považovali za finanční opce. Čím více pružnosti získáte díky brzkým platbám a častým kontrolám, tím hodnotnější tyto opce budou.

3. Soustředění. Lidé dovedou v jednom okamžiku myslet jen na omezené množství věcí. Když práci seskupíte do krátkých iterací, všichni členové týmu se na zadanou práci mohou lépe soustředit – obchodní analytici lépe odhadnou požadavky, architekti přijdou s lepším návrhem, vývojáři s lepším kódem atd.

HODNOTOCENTRICKÉ METODIKY

4. Motivace. Softwarový tým nic nepovzbudí lépe, než když může vidět fungující, byť předběžnou, verzi programu. Ani sebepodrobnější rozbory specifikací se tomu nemohou vyrovnat.

5. Teorie řízení. Krátké iterace snižují míru chyby ve vašich odhadech a rychle z nich zjistíte, jak přesné vaše plány projektu jsou.

6. Zapojení zadavatelů. Zadavatelé (zákazníci, uživatelé, vedení) rychle vidí výsledky a více se do projektu zapojí a nabídnou více svého času, rad a financí.

7. Neustálé vzdělávání. Celý tým se z každé iterace poučí, takže se přesnost, kvalita a vhodnost hotového projektu neustále zlepšují.

To vše lze shrnout slovy: „Iterativnost je vhodná pr o všechny projekty... a pro ty s vysokými riziky je nevyhnutelná“.11 Přesto se stále najde mnoho IT or ganizací, které iterativní vývoj ještě nezavedly. Iterativní vývoj v praxi vyžaduje, aby tým i jeho manažer měli př esný přehled o veškeré práci, kterou je nutné udělat, a aby ji mohli mezi jednotlivými krátkými iteracemi často sledovat a měnit priority . Tyto časté aktualizace vyžadují přehledný úkolník, nejlépe doplněný automatickým sběr em dat, například takovým, který nabízí databáze pracovních úkolů ve VSTS. Při hodnotocentrickém přístupu k iterativnímu vývoji se pracuje v mnoha cyklech, při nichž se jednotlivé činnosti časově překrývají. Výchozím plánovacím prvkem je „iterace“. Ta představuje pevný počet týdnů, někdy označovaných jako „časový rámec“, do kterých je r ozvržen stanovený úkol. Iterace se používají jako interval pro plánování zamýšlených scénářů, měření toku hodnoty, ohodnocení stávající metodiky, hledání slabých míst a pr ovádění úprav (obrázek 2.2). V kapitolách věnovaných vývoji a testování se budu zabývat podrobněji cykly zanášení změn a denních sestavení, kterým se obvykle říká „inkrementy“ a které přirozeným způsobem iteraci vedou.12

31

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

32

Program Iterace Denní sestavení

Zanesení změn

Obrázek 2.2

Projekt

Schválené sestavení

V softwarových projektech probíhá mnoho provázaných cyklů, počínaje cyklem kódování-úpravatestování-odladění-zanesení, měřeným na minuty, přes iteraci trvající několik týdnů, až po projekt, který může běžet roky. Když se tyto cykly propojí, je možné pochopit celý proces.

Délka Ve skutečnosti se délka iterací liší pr ojekt od projektu; průchody ale obvykle trvají dva až šest týdnů. Iterace opět určuje velikost dávky, kterou budete používat pro měření hodnoty předávané zákazníkovi, kterou mohou být například scénáře nebo požadavky na kvalitu. V elikost dávky musí být tak malá, jak je to jen při zachování tohoto cíle možné, jak vysvětluje David Anderson v Agile Management for Software Engineering: Malé dávky jsou zásadní pro tok! Jsou také nezbytné pro kvalitu. Lidská přirozenost vede při vývoji software k tomu, že při zpracovávání větších dávek nejsou inženýři tak nároční a věnují méně pozornosti detailům. Například, když se korektury kódu provádějí v malých dávkách, jejich příprava je rychlá a jejich provedení také. Protože kódu

4

Vedení projektu Vyšší management Projektový manažer „Nedostatky v teoriích projektů a řízení se navzájem posilují a jejich nepříznivé následky prostupují celým životním cyklem projektu. Obvykle to začíná nedostatečně zjištěnými požadavky zákazníka, a jejich vyjasnění a změna narušují další pokrok projektu. Skutečný postup se začne opožďovat oproti plánu, jehož aktualizace je příliš těžkopádná na to, aby mohla být prováděna pravidelně. Bez aktuálního plánu se systém autorizace práce změní na informační management. Úkoly jsou stále častěji zahajovány bez všech potřebných vstupů a předpokladů, což vede k nízké efektivitě nebo přerušování úkolů a nárůstu odchylek později v projektu. Přitom se řízení podle referenčního výkonu, který nevychází z momentálního stavu, stává neefektivním nebo zkrátka kontraproduktivním.

Systematické vedení projektu se nakonec přemění v pozlátko, pod kterým je úkol sice nakonec dokončen, ale ne tak efektivně a se sníženou hodnotou pro zákazníka.“1 – L. Koskela a G. Howell, „The Underlying Theory of Project Management Is Obsolete“

79

80

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

„Přítel v nouzi“, C.M. Coolidge, c. 1870

Obrázek 4.1

Bez průhledných dat se z vedení projektu může stát sázka, založená na neúplných informacích a rozcházejících se úhlech pohledu zadavatelů. Můžete to bez nadsázky přirovnat k pokeru.

Předcházející kapitola se zabývala zjišť ováním požadavků. Tato se zaměř uje na vedení běžícího pr ojektu, který tyto požadavky implementuje. Nejprve se budu zabývat třemi principy, které jsou pro hodnotocentrický přístup klíčové: • Odchylky, které je třeba rozpoznat ve zvládnutých projektech i těch, které se vymkly kontrole.

• Popisné metriky místo předepisujících.

• Posuzování zdraví projektu z více pohledů.

Ve VSTS jsou tyto principy realizovány v databázi pracovních položek a v datovém skladu metrik s cílem poskytnout vám praktický základ pr o hodnotocentrické vedení projektu. Pro dokreslení této stránky VSTS v této kapitole používám mnoho příkladů s reporty z datového skladu metrik. Tyto příklady budou „příjemné“ na r ozdíl od „neradostných“, kter é se objeví v 9. kapitole, „Řešení problémů s projektem“.

Nakonec se v této kapitole budu zabývat odhady a stanovováním priorit (triage) z hodnotocentrického pohledu. Tyto dvě důležité techniky vedení projektu využívají metriky a dotazy, které VSTS umožňuje.

VEDENÍ PROJEKTU

Pochopení odchylek Základem hodnotocentrického přístupu je myšlenka přir ozenosti odchylek.

Odchylky a jejich dopad na kvalitu byly původně studovány ve výr obním inženýrství a velmi dobře o nich učil W. Edwards Deming: Běžné a zvláštní příčiny. [Dr. Walter A. Shewhart z Bell Labs] viděl dva druhy odchylek – odchylky způsobené běžnými příčinami a odchylky způsobené příčinami zvláštními. ... Běžné příčiny odchylek zůstávají vždy a všude stejné. Zvláštní příčiny odchylek jsou prostě zvláštní, a nepatří do systému běžných příčin. ... Dr. Shewhart také viděl dva druhy chyb: Chyba 1. druhu: reakce na výsledek, jakoby byl způsoben zvláštní příčinou, ačkoliv byl způsoben běžnou příčinou odchylky.

Chyba 2. druhu: přistupovat k výsledku, jakoby byl způsoben běžnou příčinou odchylky, ačkoliv byl způsoben příčinou zvláštní.2 Stejné rozlišení běžných a zvláštních příčin odchylek platí i pr o softwarové projekty. Procesy, ve kterých se objevují přir ozeně způsobené odchylky jsou pod kontrolou, ty, ve kterých dochází k odchylkám ze zvláštních příčin, ne.

V softwarových projektech trvají některé věci déle, než se předpokládalo, a jiné jsou hotovy dříve. Některý softwar e lze integrovat bez problémů, jindy se objeví chyby, které je třeba opravovat. Některé scénáře zákazníky potěší přesně podle očekávání, jiné je třeba doladit na testech použitelnosti a se zkušenostmi získávanými během několika iterací. T o obvykle bývají přir ozené příčiny odchylek.

Chybou 1. dr uhu je dělat něco s pr ocesem, který je pod kontr olou a jen vykazuje tyto přirozené odchylky. Tím odchylky jen zvýšíte a pr oces se vám rychle vymkne z rukou. A vše – což je pravděpodobně důležitější – vede k mikromanagementu, který tým demoralizuje.

Deming předvádí účinky takovýchto zásahů na nádherně prostém příkladu.3 Vezmete si trychtýř, kuličku a stůl, trychtýř zamíříte na vybraný cíl, necháte skrz něj mnohokrát skutálet kuličku (ř ekněme 50×) a budete si značit místa, kam kulička dopadla. Po každém pokusu trychtýř posunete, abyste vyr ovnali chybu. Deming navrhuje tři korekční pravidla, která sama o sobě zní rozumně.

První průchod ukazuje přirozené odchylky, zatímco ty ostatní vykazují větší rozptyl odchylek.

81

9

Řešení problémů s projektem Vyšší management Projektový manažer „Všechny šťastné rodiny jsou si podobné; každá nešťastná rodina je nešťastná po svém.“ – L. Tolstoj, Anna Karenina1

Obrázek 9.1

Lev Nikolajevič Tolstoj.

221

222

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Aforizmus Lva Nikolajeviče se dá aplikovat i na softwarové projekty. V softwarovém projektu je mnoho vzorů nešťastných situací, které se obvykle projevují nejméně dvěma desítkami symptomů.

Kapitola se soustřeďuje na tyto vzory, symptomy, a na to, jak je rozpoznávat.

Na tomto místě doufám, že už jste př esvědčenými přívrženci hodnotocentrického přístupu, který prosazuje, abychom používali systémy průběžně hledající způsoby, jako zdokonalit tok hodnoty . V 1. kapitole, „Hodnotocentrický přístup“, jsem ho por ovnal se zobrazením „železného trojúhelníku“ úkolocentrického přístupu, kde se předpokládá fixní kapacita a problémy se redukují na čas, zdroje, funkcionalitu a kvalitu.2 Datový sklad metrik, jako je například databáze pracovních položek, umožňuje provozovat projekt na bázi důvěry a transpar entnosti. Každý člen týmu vidí stejná data, klade stejné otázky, hledá odpovědi a participuje na nalézání řešení. Možná budete tuto kapitolu kritizovat za to, že je zbytečně kvantitativní.

V žádném případě tím ale nemíním dopor učovat, že k podchycení pr oblémů vždycky potřebujete nějaká čísla, nebo že řešení a zdokonalování mají být vyjadřovaná v číslech. Jak jsem probral ve 4. kapitole, „Správa projektu“, je třeba, aby byly metriky popisné, nikoli předepisující.

Hrdost na profesionalitu, což je jeden z postojů MSF, se předpokládá u každého, a metriky jsou nástr oj, který má tuto hr dost posilovat, ne ji vytlačovat.

V míčových hrách vyhráváte tím, že hrajete dobř e, a sledujete míč, ne světelnou tabuli se skórem. Na tabuli se prostě udržuje aktuální stav skóre, takže se nemusíte rozptylovat hádkami o to, čí čísla jsou správná.

Na mnohé symptomy žádný sklad metrik nepotř ebujete. Dobře známou ukázkou je inverzní Dilbertův korelační faktor: čím víc Dilbertových kreslených vtipů je nalepených na dveřích kanceláří a na vývěskových tabulích, tím méně zdravá je organizace. (Samozřejmě, nepřítomnost jakýchkoli kreslených vtipů může být také var ovným signálem o jistých fir emních politikách.) Jiným příkladem je morálka týmu, která se viditelně odráží v úr ovni energie a nadšení.

Jestliže členové týmu nemohou kvůli problémům v projektu spát, měli by vám být schopni sdělit, co jim dělá starosti. A pokud to nevíte, pak se zbytkem svého týmu netrávíte dost času.

Na druhou stranu se může každému z nás stát, že něco př ehlédne. Pro odhalení možných rizik a opomenutí jsou skvělé tr endy a detailní pohledy , a grafy „zdravotního stavu“ jsou skvělým místem, odkud začít. Dodají vám taková data, abyste mohli začít klást správné otázky, odpovědi však může nalézt jen celý tým. Největší př edností grafů metrik je, že dovedou doplnit vaše

ŘEŠENÍ PROBLÉMŮ S PROJEKTEM

223

pocity a podezření, která získáte z kontaktu se svými týmovými spolupracovníky, když zkoušíte momentální sestavení softwaru, revidujete kód, zkoumáte chyby, plánujete iterace, a tak dále. Grafy poskytují ukazatele všeobecného zdravotním stavu projektu a když máte podezř ení, že jste narazili na nějaký problém, můžete se podívat na data, abyste si jej potvrdili nebo vyvrátili.

Ve zbytku kapitoly uvedu soupis celé řady potenciálních problémů, z nichž mnohé určitě znáte ze svých osobních zkušeností, a př edvedu, jak se mohou projevovat na grafech VSTS o zdravotním stavu pr ojektu. Cílem je ukázat, jak může VSTS se svými denními r eporty poskytnout včasná var ování a pomoci při průběžných korekcích, abyste mohli stále zdokonalovat kvalitu.

Používání Excelu s datovým skladem metrik Kromě standardních reportů, které jsou ve VSTS nainstalované s šablonou metodiky, můžete ke všem datům skladu metrik přistupovat z Microsoft Excelu. Podívejte se do tohoto tématu MSDN: Development Tools and Technologies Visual Studio Team System Team Foundation Team Foundation Project Leads Using Reporting and Metrics Team Foundation Server Reporting Using Team Reports Using Microsoft Excel for Team Foundation Server Reporting

Podcenění Jedním z nejčastěji ohlašovaných symptomů pr oblémů je podcenění. Když projekt postupuje vpřed pomaleji, než jak bylo naplánováno, a úsilí je větší, než jaké bylo odhadnuto jako postačující, tak členové týmu podcenili zdr oje, obtížnost, čas, nebo jiné faktory (obrázek 9.2).

Narazíte-li na tento vzor, samozřejmě budete chtít najít jeho hlavní příčiny.

Existuje několik možných příčin podcenění, které jsou znázorněné na obrázcích 9.3 až 9.10.

224

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Počet pracovních položek

116 144

193

187

179

173

166

106

94

133

156

92 90 86 68

18

38

6/25/2005

6/22/2005

6/19/2005

10

29

67

49

18 6/16/2005

5

6/13/2005

16 6/10/2005

6/7/2005

6/4/2005

6/1/2005

7

15

61

6/30/2005

22

6/28/2005

40

Datum Aktivní Vyvřešené Uzavřené

Obrázek 9.2

Podle sklonu čáry pro uzavřené pracovní položky se dá usoudit, že tato čára bude k datu konce iterace výrazně pod plánovanou úrovní, což znamená, že ne všechny scénáře, které byly pro tuto iteraci naplánované, budou dokončené včas.

Nestejnoměrná dekompozice úkolu Kontrolujte rozmanitost definic úkolů a rozsah jejich podrobnosti. Budete chtít vidět úkoly naplánované na dobu jednoho až tří dnů (obrázky 9.3 a 9.4).

Hluchá místa architektury Někdy tým odhalí, že je zapotř ebí změnit něco v ar chitektuře. Třeba je nutné více se soustředit na integraci, přehodnotit požadavky na kvalitu, změnit strukturu komponent, zavést nové společné služby, změnit naplánované prostředí, ve kterém bude produkt nasazen, nebo pr ovést jiné rozsáhlé architektonické změny.

ŘEŠENÍ PROBLÉMŮ S PROJEKTEM

400 350 300

Počet úkolů

250 200 150 100 50 0 1 den

2-3 dny

6-10 dní

4-5 dní

více než 21 dní

11-20 dní

Velikost úkolů Počet úkolů

Obrázek 9.3 Histogram počtu úkolů podle velikosti ukazuje, že je velikost úkolu velmi variabilní.

28 26

21 19

19 18

15

15 13

11.39 12

12

13

12

11

10

12

12 10

10 9

9

6 3

3

6

3 2

2

2

Datum Vyřešené (za den) Uzavřené (za den) Průměrně vyřešeno

7/1/2005

6/30/2005

6/29/2005

6/28/2005

6/27/2005

6/26/2005

6/25/2005

6/24/2005

6/23/2005

6/22/2005

6/21/2005

6/20/2005

6/19/2005

6/18/2005

6/17/2005

6/16/2005

6/15/2005

0 6/14/2005

Počet přechodů

22 20

Obrázek 9.4 V souladu s tím ukazuje graf rychlosti 0 projektu (Project Velocity) velký rozptyl v počtu úkolů uzavřených za jeden den.

225

10

Závěr

„Je pravda, že skutečně máme ve své zemi, zvané Rovina, třetí nepoznanou dimenzi, které se říká „výška“, a zrovna tak je pravda, že vy skutečně máte ve své zemi, zvané Prostor, čtvrtou nepoznanou dimenzi, která prozatím žádné jméno nemá, a které já budu říkat „druhá výška“. My si neumíme uvědomit svoji „výšku“ o nic lépe, než vy svoji „druhou výšku“. Ani já – který jsem byl v Prostoru a měl to privilegium „výšku“ na dvacet čtyři hodin prohlédnout – ji teď neumím pochopit, nebo si ji nějak uvědomit svým zrakem nebo jakýmkoliv myšlenkovým pochodem. Nezbývá mi než věřit, že existuje.“ – Edwin Abbott, Flatland: A Romance of Many Dimensions 1

Obrázek 10.1

Oba obrázky jsou dvourozměrné projekce téhož osmistěnu. Zakryjete-li však obrázek vpravo, budete patrně obrázek vlevo považovat za čtverec se dvěma úhlopříčkami. Jen když vidíte oba dva najednou, vypadají úhlopříčky jako hrany trojrozměrného obrazce.

243

244

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

V této knize jsem popisoval, jak tým rovnocenných pracovníků může s hodnotocentrickým přístupem a s balíkem Visual Studio Team System (VSTS) zvýšit svoji produktivitu při tvorbě zákaznické hodnoty. Používal jsem k tomu různé neměřitelné stránky pracovních postupů i měřitelné metriky, které jsou přitom zachycovány. Obojí představuje mnohorozměrný přístup. Často jsem se odkazoval na dvě instance MSF (Micr osoft Solution Framework), protože jsou to metodiky dodávané s VSTS, a pr otože jsou, pokud vím, hodnotocentrickému myšlení nejblíže. Všude tam, kde to bylo možné, jsem se snažil uvádět intelektuální zdroje použitých myšlenek.

Očekávaná kritika V době, kdy jsem knihu psal, byl Team System právě vydán. Učinil jsem řadu prohlášení a očekávám za ně dost značné množství kritiky , takže mi dovolte, abych se hned k pěti hlavním obviněním přiznal: 1. Kniha není dostatečně agilní. Konkrétně očekávám, že mi bude otloukáno o hlavu, že nedodržuji dost důkladně principy Agile Manifesto.2 Například píši více o metodikách a nástrojích než o jednotlivcích a interakcích, a také více o změnách v souvislosti s plánem, než o reakci na změny bez jakéhokoliv plánu. Vlastně si myslím, že obrovitá síla agilní komunity spočívá v převratných nástrojích, které se vynořily pro testy programových jednotek a pro řízení změn. A metodiky jako extrémní programování demonstrovaly skvělou hodnotu disciplíny. S VSTS se snažíme nástroje a techniky tohoto druhu usnadnit a zpřístupnit mnohem širší komunitě, než tomu bylo kdy dříve.

2. Kniha nijak přesně nepředepisuje, jak máte pracovat. Principem hodnotocentrismu je důležitost strategií přizpůsobených situaci. Snažil jsem se soustředit se na rozpoznávání a pochopení situace, a doufal jsem, že pokud celý tým může vidět stejná data, přesné postupy si už vypracuje.

Rozhodně by stálo za to napsat knihu o manažerských postupech přizpůsobených situaci.

3. Žádná z disciplin není probrána v dostatečné hloubce. To, co jsem napsal, má být úvodní kniha řady. Brzy po jejím vydání bude k dispozici kniha zaměřená výhradně na vývojářské techniky s VSTS. Doufám, že se ke mně v průběhu několika let připojí mnozí další autoři. Uvědomuji

ZÁVĚR

245

si, že jsem zanedbal některá klíčová témata, jako jsou uživatelská zkušenost, dokončení či předání produktu a provoz.

4. Nemám pro podporu svých tvrzení dostatečná data. Zatím ne. Společnost Microsoft se určitě chystá nashromáždit případové studie týkající se VSTS, ke kterým se budete moci dostat na adrese http://msdn. microsoft.com/teamsystem. Doufám, že vám umožní dostatečný vhled do používaných metodik i dostatek dat k ilustraci hodnot, které jsem zde probíral.

5. Zdroje jsou příliš náhodné. Softwarové inženýrství není nové a nevyskytuje se nezávisle na svém obchodním kontextu. Usilovně jsem se snažil zpřístupnit hodnotnou práci komunity i prostředí byznysu dvacátého prvního století. Často zjišťuji, že softwarové debaty jsou příliš černo-bílé, ale myslím si, že celá situace má mnohem víc barevných odstínů. Doufám že i vy dáváte přednost barvám a odstínům před čistě černo-bílým pohledem.

Možná budu také obviněn, že dělám pr oduktu příliš velkou r eklamu. Snažil jsem se probrat myšlenky návrhu, které vedly k vytvoř ení VSTS, s tolika příklady, kolik se mi do knihy vešlo. Pokoušel jsem se, kdykoli to bylo možné, odlišit myšlenky od implementace, ale k jejich dokreslení jsem používal produkt.

Doufám, že jste jejich podání považovali za vyvážené.

Ještě jednou o hodnotocentrismu Klíčovou myšlenkou této knihy je, že se ve vývoji software rodí nové paradigma, kterému já říkám hodnotocentrický přístup. Počáteční intelektuální kořeny hodnotocentrismu se nacházejí v práci autor ů Deming, Weinberg a Goldratt a komunit Agile, Lean Manufacturing a Theory of Constraints. Ústř edním principem hodnotocentrismu je maximalizovat tok zákaznické hodnoty.

V souladu s těmito kořeny zastává hodnotocentrismus tyto myšlenky: 1. Počítejte se změnami. Investujte do plánování a navrhování jen tolik, kolik je nezbytné k pochopení rizik a ke zvládnutí příštího malého inkrementu.

2. Měřte jen ty výstupy které představují zákaznickou hodnotu. Dívejte se na všechny pomocné míry skepticky.

246

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

3. Kvalitu chápejte jako hodnotu pro zákazníka. Představy zákazníka se mohou změnit, takže udržujte možnosti otevřené a plánujte časté dodávky.

4. Přijměte skutečnost, že odchylka je součástí všech procesů. Rozlišujte zvláštní příčiny odchylek od běžných. Zacházejte s nimi odlišně.

5. Používejte pomocné výstupy vaší práce jen tehdy, zdokonalují-li tok hodnoty. Používejte je pro redukci neurčitosti a rozptylu, ne pro měření pokroku práce.

6. Zvyšujte kapacitu tím, že se pustíte do úzkých hrdel v toku hodnoty. Zdroje a čas vylaďujte až poté, co odstraníte úzká hrdla.

7. Buďte transparentní a důvěřujte. Předpokládejte, že je tým hrdý na svou profesionalitu a že chce, aby byla vidět.

Důvěra a transparentnost Inkrementální doručování hodnoty

Postoje

Principy

Buďte agilní, očekávejte a adaptujte změny

Kvalita je každodenní starost všech

Hrdost na profesionalitu

Pracujte na sdílené vizi

Průběžně studujte

Zplnomocňujte členy týmu

Včasná a častá nasazení do provozu

Návrh pro kvality služeb (QoS)

Poučte se ze všech zkušeností

Soustřeďte se na obchodní hodnotu

Brzy přecházejte od abstraktního ke konkrétnímu

Tým rovnocenných spolupracovníků Investujte do kvality

Opětovné využívání a rozšiřování Pěstujte otevřené komunikace

Obrázek 10.2 Principy a postoje MSF odrážejí hodnotocentrické paradigma.

Partner se zákazníky

Celé řešení Zřizujte jasné zodpovědnosti a sdílená pověření

ZÁVĚR

247

Považujete-li tento seznam za základ , pak jsem polovinu svého záměr u už splnil.

Druhou polovinou mého záměru je ubezpečit vás, že dobré nástroje mohou znamenat velký pozitivní posun. VSTS není první pr odukt, který se zabývá životním cyklem softwaru, a nebude ani posledním. Já však věřím, že je prvním produktem, který se pokouší nabídnout vyčerpávající hodnotocentrický přístup pro celý tým pr ostým, produktivním, integrovaným a r ozšiřitelným způsobem. K dispozici jsou bezplatné, časově omezené verze pr oduktu, takže si můžete vyzkoušet, zda se pr o vás hodí. Samozř ejmě, že VSTS je nový pr odukt, a proto bude jistě hodně požadavků, co by měl umět, aby se dostal ještě dál. Vítám dialog.

Tím, že VSTS kontr oluje softwarový proces, zavádí důvěryhodnou transparentnost. Datový sklad metrik poskytuje celému týmu společný pohled na fakta a společnou základnu historické výkonnosti. Tento společný pohled mění diskusi z „Čí čísla jsou správná?“ na „Co bychom měli udělat teď?“.

Doufám, že se VSTS stane zár odkem podobných inovací v celém odvětví.

Zdokonalování kapacity IT a softwar ového průmyslu je jednou z největších ekonomických výzev a příležitostí nadcházejících dekád. Věřím, že se neobejde bez hodnotocentrického přístupu a nástrojů, které ho budou podporovat.

Poznámky 1. Edwin Abbott, Flatland: A Romance of Many Dimensions, napsal A Square (Boston, Roberts Brothers, 1885), předmluva k druhému vydání.

2. www.agilemanifesto.org