Efektivní softwarové projekty

Efek

tivní

sof

twar

ové

proj

ekty

E N C Y K L O P E D I E Z O N E R P R E S S

ENCYKLOPEDIE WEBDESIGNERASam 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 soft-warové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 pre-zentace 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 zodpo-ví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 úkolocentric-ké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 usnad-nění odhadů;

• tvorba požadavků pomocí postav a scénářů;

• vedení projektu s it eracemi, důvěryhodnou transparentností a bezkon-fliktními metrikami;

• architektonický návrh z hodnot ocentrického pohledu využí vající archi-tekturu 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ů...

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.

E N C Y K L O P E D I E Z O N E R P R E S S

www.zonerpress.cz

Sam GuckenheimerJuan J. Perez

Sam

Guc

kenh

eim

erJu

an J

. Per

ez

9 7 8 8 0 8 6 8 1 5 6 2 6

ISBN 978-80-86815-62-6KATALOGOVÉ ČÍSLO: ZR703DOPORUČENÁ CENA: 300 KČ

Efektivní softwarové projekty

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 do-mácích odborníků najdete celu řadu titulů světově uznávaných autorů, se informujte na adrese vydavatelství.

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

Efektivní softwarové projekty

Zoner Press tel.: 532 190 883 fax: 543 257 245e-mail: [email protected]://www.zonerpress.cz

ZONER software, s.r.o., Nové sady 18, 602 00 Brno

Chvála knihySoftware 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é. Tato 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 po-ukazuje 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 Micro-soft 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 Sys-tem. 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 im-plementovat s nástroji z Team System. Na rozdíl od předcházejících knih o softwa-rový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 Software 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 Sys-tem 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á transparent-nost projektu, kterou Team System poskytuje, zlepšuje součinnost v týmu a př ed-ví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 hodnotocen-trické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é jed-notky 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 gani-zaci 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 me-tody 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ěř neviditel-ná, 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ži-telné 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é architektury, 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ře-dí povzbuzujícím důvěru a osobní bezpečí, může vytvořit pr oduktivnější vývo-jář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 GuckenheimerJuan 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 storageretrieval 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 žádnouformou 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é projektyAutor: Sam Guckenheimer, Juan J. Perez

Copyright © ZONER software, s.r.o. Vydání první v roce 2007. Všechna práva vyhrazena.

Zoner PressKatalogové čí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ánDTP: 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 prostř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 PressZONER software s.r.o.Nové sady 18, 602 00 Brno

tel.: 532 190 883, fax: 543 257 245e-mail: [email protected]://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

xi

O autorovi xvii Úvodem xix Předmluva xxi Poděkování xxix

Kapitola 1 Hodnotocentrický přístup 1Změna přístupu 2

Tři síly, se kterými se musíme smířit 2Jaký software má cenu budovat? 3

Protikladné přístupy 4Význam toku 7

Rozdíl oproti úkolocentrismu 10Transparentnost 11

Jedna databáze pracovních položek 13Sledování každodenní činnosti 17

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

Kapitola 2 Hodnotocentrické metodiky 27Microsoft Solutions Framework 28Iterativní vývoj 30

Proč vyvíjet iterativně 30Délka 32Různé výhledy, různá míra podrobnosti 33Volba priorit 33Přizpůsobení metodiky 35

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

Obsah

xii EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

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

Shrnutí 46Poznámky 47

Kapitola 3 Požadavky 49Jakou máte vizi? 50

Strategické projekty 51Adaptivní projekty 51

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

Postavy a scénáře 55Začněte s postavami 55Scénáře 56Techniky průzkumu 57Brzy konkretizujte 59Storyboardy 60Záběr scénářů 61Prověření zákazníkem 62Rozvíjení scénářů 64

Postavy a scénáře a jejich alternativy 65Aktéři (actors) a případy užití (use cases) 65Uživatelské příběhy (user stories) 66

Scénáře potěšující, uspokojující a „nepříjemnosti“ 66Požadavky na kvalitu 67

Bezpečnost a soukromí 68Výkon 69Uživatelský zážitek 69Kontrolovatelnost 70

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

xiiiOBSAH


Kapitola 4 Vedení projektu 79Pochopení odchylek 81Používání popisných metrik místo předpisujících 83Mnoho rozměrů zdraví projektu 86Odpovědi na každodenní dotazy 86

Zbývající práce 88Rychlost projektu 90Neplánovaná práce 91Ukazatele kvality 92Počty chyb 93Znovuotevírání 95Chyby podle priority 95Skutečná kvalita a plánovaná rychlost 97

Odhad iterace 98Odhad shora dolů 99Odhad zdola nahoru 100Dolaďování 100Odhady kvality 102Retrospektivy 104

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

Uspokojení auditora 110Shrnutí 113Poznámky 113

Kapitola 5 Návrh architektury 115Hodnotocentrický pohled na architekturu 116Architektura zaměřená na služby 116

Webové služby a SOA 118Návrh podle kontraktu 118

Omezení se stupni volnosti 119

xiv EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

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

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

Bezpečnost 127Výkon 127

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

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

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

Okamžitá zpětná vazba s testy programových jednotek a pokrytím kódu 141

Co dřív – testy nebo kód? 142Pokrytí kódu 143

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

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

xvOBSAH

Aby byla práce transparentní 161Shrnutí 162Poznámky 163

Kapitola 7 Testování 165Hodnotocentrický pohled na testování 166

Co dělá dobrého testera? 167Základní otázky 169Dodáváme zákaznickou hodnotu? 169

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

Jsou požadavky na kvalitu dostatečné pro použití? 177Zátěžové testy 177Testování bezpečnosti 182Testy použitelnosti 183

Otestovali jsme změny? 183Co jsme neotestovali? 184

Požadavky 184Kód 186Rizika 187

Funguje to v rutinním provozu stejně dobře jako v laboratoři ? 189Testujeme dostatečně? 192

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

Kdy máme testovat? 196Cyklus zanesení změn 196Cyklus denního sestavení 197Cyklus schválení sestavení 198Cyklus iterace 199Cyklus projektu 200

Které testy mají být automatizované? 201Jak efektivní je náš tým, nebo náš outsourcovaný tým? 201Shrnutí 202Poznámky 203

xvi EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

Kapitola 8 Ohlašování chyb 205Varovná příhoda 207Životní cyklus softwarové chyby 208

Ohlašování chyb je jako žurnalistika 210Subjektivní data 213Objektivní data 214Údaje o vyhodnocení 216Plán 218


Kapitola 9 Řešení problémů s projektem 221Podcenění 223

Nestejnoměrná dekompozice úkolu 224Hluchá místa architektury 224Nafukování rozsahu 227Neadekvátní příděl chyb 229Únik zdrojů 229

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

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

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


Kapitola 10 Závěr 243Očekávaná kritika 244Ještě jednou o hodnotocentrismu 245Poznámky 247

Rejstřík 249

xvii

O autorovi

Sam Guckenheimer za sebou má 25 let zkušeností ar chitekta, vývojáře, teste-ra, 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ža-davky zákazníků a zodpovídá za celkový návrh dalších vydání těchto produk-tů. Než začal v r oce 2003 pracovat pr o Microsoft, měl na star osti produkto-vou 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 soft-ware 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.

xix

Ú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 produkt, který je na nich založen. Jsem rád, že se mu po-dař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šlen-ky v nich přímo ožívají.

Mezi klíčové myšlenky knihy patří „hodnotocentrické“ procesy. Sam se do-mní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ři-tom 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, sledo-vá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 hodnotocent-rické metodiky.

Téměř deset let se v různých oblastech softwarového inženýrství – v progra-mová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

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

xxi

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 pro-gramech 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 postupu-jete 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 nedove-dou pochytit charakteristiky, které jsou pro vývojáře, testery a fungování soft-ware nejdůležitější.

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 pro-duktu“ 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ís-to 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 profesi-oná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. Koli-krá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 indivi-duá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řed-poklady. 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-

xxiiiPŘ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 nepochy-buji 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 pou-ká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 pro letectví; nemusí být dost volná, aby vyhovovala tříčlenému týmu, který pracuje v garáži.

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:

Vývoj

Testování

Vedeníproduktu

Uživatelská zkušenost

Nasazení

Projektovéřízení

Architektura

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.

xxvPŘ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 pa-sáž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 neodrazo-val. (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é kole-gy 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

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í procesu“. 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 programy 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.

xxviiPŘEDMLUVA

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

Seznámení s Visual Studio 2005 Team System

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.

Prů

vod

ce p

rod

ukte

m a

arc

hite

ktur

ou O

bo

roví partněři p

ro V

isual Stud

ioVisual Studio Team Foundation

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

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

xxviii EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

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 Microsoft. 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).

xxix

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ápo-mocný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 for Agile Software Develop-ment 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á, Ke-vin P. Davis, Cristof Falk, Linda Fernandezová, Ken Garove, Bill Gibson, Mar-tin Heller, Bijan Javidi, Yulin Jin, Cem Kaner , Chris Kinsman, Aaron Kowall, Clementino Mendonca, Thomas Murphy, Gary Pollice, Tomas Restrepo, Johan-na Rothmanová, Joel Semeniuk, W ill Stott, Dan Sullivan, David T rowbridge, Mike Turner, Kumar Vadaparty a Peter Williams. Ve finiši mi velmi pomohli

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 GuckenheimerRedmond, Washington, USA

1

„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.)

Hodnotocentrický přístup1

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ž ne-dovedou 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 vel-ké čá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ý ob-raz 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šo-val, vypracoval alternativu, která ovšem zapadla. 2 Proč se dnes v každé učeb-nici 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 jedno-dušší.“

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 za-lož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

3HODNOTOCENTRICKÝ 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řeno-sový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é poraden-ské společnosti na druhou stranu potřebují prokázat svým americkým a evrop-ským zákazníkům požadovanou úr oveň kvality. Mnohé se chytily metodiky Capability Maturity Model Integration (CMMI) navržené v Softwar e Engine-ering 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 nemu-sely 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é metodi-ce, 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 podob-ný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


k němu mohli zakoupit licenci (nebo jej dokonce získat bezplatně). Žádná r o-zumná 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 bezri-zikové, 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žď o-vá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íz-ký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


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 hodnoto-centrický (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).

Úkol 1Plán

Úkol 3Úkol 4

Úkol 2

...

...

...

Úkolocentrický Hodnocentrický

Hod

nota

Zbýv

ajíc

í prá

ce

Obrázek 1.2 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í Decla-ration of Interdependence.9 Formuluje šest prinicpů, kter é tento přístup cha-rakterizují:

• 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 vlast-nictví 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.


• 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í, meto-dik a postupů, které odpovídají situaci.

Za těmito principy se skrývá od základu jiný úhel pohledu, kterým se hod-notocentrické 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 pocho-pili 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 celko-vého naplánovaného času.

Počítaji se jen výsledky, které jsou pro zákazníka hodnotné (fungující software, hotová do-kumentace atd.). Tok pracovních proudů musíte měřit frontami produkujícími hodnotu pro zákazníka a všech-ny 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 prav-dě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 pone-chejte otevřené, přizpůsobte se neustálému dodávání a specifi-kaci nekonkretizujte předčasně.


Výchozí předpoklad Úkolocentrický přístup Hodnotocentrický přístup

Přijatelnost odchy-lek

Ú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řed-ví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é doku-menty, 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 odchyl-ky tak, aby se zlepšil tok výstu-pů. Cokoliv navíc je zbytečné.

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

Omezení času, zdrojů, funkcio-nality 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 po-tom 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 porov-ná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í od-mě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ěru 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 Csikszent-mihalyi:

27

„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. Jed-notlivci 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 cha-rakteristiku takovýchto metodik, na konkr étní podmínky, které je nutné vzít v úvahu, a příklady, které můžete využít.

Hodnotocentrické metodiky2

Vyšší managementProjektový manažer


Softwarové metodiky dostupné ve VSTS

Spolu s VSTS se dodávají dvě metodiky, které jsou obě variantou Micro-soft 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ší alterna-tivu – 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é pestrosti 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

29HODNOTOCENTRICKÉ 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í fun-gují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 Insti-tute.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 me-todiku 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 po-uží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.


Iterativní vývoj

MSF je iterativní a inkrementální metodika. Význam iterativního vývoje komu-nita softwarových vývojářů chápe již déle než dvacet let. Obvykle se tím myslí „způsob vývoje software, při kterém definice požadavků, návr h, implemen-tace 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 Bro-oks, 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 snad-no 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.

31HODNOTOCENTRICKÉ 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ší rozbo-ry 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řes-nost, 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ě neza-vedly. 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ánova-cím prvkem je „iterace“. Ta představuje pevný počet týdnů, někdy označova-ný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 hod-noty, 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


Program

Iterace

ProjektDenní sestavení

Zanesení změnSchválené sestavení

Obrázek 2.2 V softwarových projektech probíhá mnoho provázaných cyklů, počínaje cyklem kódování-úprava-testová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. Lid-ská 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

79

„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ějiv 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“

Vedení projektu4



„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 da-tovém skladu metrik s cílem poskytnout vám praktický základ pr o hodno-tocentrické 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í pro-jektu využívají metriky a dotazy, které VSTS umožňuje.

81VEDENÍ 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 od-chylky 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 ji-né 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 od-chylek.

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 mi-kromanagementu, 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.

221

„Všechny šťastné rodiny jsou si podobné; každá nešťastná rodina je nešťastná po svém.“– L. Tolstoj, Anna Karenina1

Řešení problémů s projektem9


Obrázek 9.1 Lev Nikolajevič Tolstoj.


Aforizmus Lva Nikolajeviče se dá aplikovat i na softwarové projekty. V softwa-rové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 hodnotocentric-ké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“ úkolocent-rické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 vy-jadř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ětel-nou 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 na-lézt jen celý tým. Největší př edností grafů metrik je, že dovedou doplnit vaše

223ŘEŠENÍ PROBLÉMŮ S PROJEKTEM

pocity a podezření, která získáte z kontaktu se svými týmovými spolupracov-ní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 projektu. 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 ša-blonou 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É PROJEKTYP

oče

t pra

covn

ích

po

lože

k

5 10 1829

3849

61 67

715

1618

22

4068

86

9092

6/1/

2005

6/4/

2005

6/7/

2005

6/10

/200

5

6/13

/200

5

6/16

/200

5

6/19

/200

5

6/22

/200

5

6/25

/200

5

6/28

/200

5

6/30

/200

5

DatumAktivníVyvřešenéUzavřené

193 187179 173 166

156144

133116

10694

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 struk-turu 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.

225ŘEŠENÍ PROBLÉMŮ S PROJEKTEM

400

350

300

250

200

150

100

50

0

1 den 2-3 dny 4-5 dní 6-10 dní 11-20 dní více než 21 dní

Po

čet ú

kolů

Velikost úkolů

Počet úkolů

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

20

11.3912

11

3 3 3

15

28

26

22

12 12 12 12

2 2 2

6

10 10

13 13

21

19 19

15

18

109 9

6

00

6/14

/200

5

6/15

/200

5

6/16

/200

5

6/17

/200

5

6/18

/200

5

6/19

/200

5

6/20

/200

5

6/21

/200

5

6/22

/200

5

6/23

/200

5

6/24

/200

5

6/25

/200

5

6/26

/200

5

6/27

/200

5

6/28

/200

5

6/29

/200

5

6/30

/200

5

7/1/

2005

Datum

Po

čet p

řech

od

ů

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

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

243

„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.

Závěr10


V této knize jsem popisoval, jak tým rovnocenných pracovníků může s hodno-tocentrický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 Fra-mework), 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 otlou-ká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 in-terakcí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 mno-hem širší komunitě, než tomu bylo kdy dříve.

2. Kniha nijak přesně nepředepisuje, jak máte pracovat. Principem hod-notocentrismu 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ři-způsobených situaci.

3. Žádná z disciplin není probrána v dostatečné hloubce. To, co jsem na-psal, 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

245ZÁVĚR

si, že jsem zanedbal některá klíčová témata, jako jsou uživatelská zkuše-nost, 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 ne-vyskytuje 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é, od-liš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é paradig-ma, 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.


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 hodno-ty. 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.

Postoje

Důvěra a transparentnost

Hrdost na profesionalitu

Průběžně studujte

Kvalitaje každodennístarost všech

Soustřeďte sena obchodní

hodnotu

Opětovnévyužívání

a rozšiřování

Týmrovnocenných

spolupracovníků

Celé řešení

Inkrementálnídoručování

hodnoty

Partnerse zákazníky

Buďte agilní,očekávejtea adaptujte

změny

Pracujtena sdílené

vizi

Poučte seze všech

zkušeností

Brzy přecházejte

od abstraktníhoke konkrétnímu

Principy Zplnomocňujtečlenytýmu Investujte

do kvality

Včasná a častánasazení

do provozu

Pěstujteotevřené

komunikace

Zřizujte jasnézodpovědnosti

a sdílenápověření

Návrhpro kvality

služeb (QoS)

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

247ZÁVĚR

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 prv-ní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 rozšiřitelným způsobem. K dispozici jsou bezplatné, časově omezené verze produktu, takže si můžete vyzkoušet, zda se pr o vás hodí. Samozřejmě, že VSTS je nový pr o-dukt, 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 trans-parentnost. 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

Date post:	27-Mar-2016
Category:	Documents
Upload:	zoner-software-as
View:	224 times
Download:	2 times

Efektivní softwarové projekty

Documents