Chvála knihy Software Engineering with Microsoft Visual Studio Team System

Chvála knihy Software Engineering with Microsoft Visual Studio Team System „Fascinující! Tato kniha je nabitá podrobný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 poukazuje na metriky, kterými můžete tuto metodiku ve svých vlastních projektech 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“. Vysvě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 projekty 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 srozumitelnou 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 produktivitu 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 Microsoft 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. Ve světě, kde partyzánské jednotky agilních metodik spojily své síly proti po zuby ozbrojeným legiím CMMI, ukazuje cestu k vzájemnému soužití. Tato kniha je především o softwarovém inženýrství. Klíčové body jako plánování, dokumentaci, vedení, audity a organizaci 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í Team 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 softwarové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 podporu 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 motorem tvorby celkové architektury, která v Team System poskytuje úroveň integrace a transparentnosti, která je pro 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 produktivně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 prostá: 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, proč by to mohla být pravda, a navíc přináší mnoho rad, jak zvýšit produktivitu a efektivitu celého týmu bez ruční režie.“ – Francis T. Delgado, senior program manager, Avanade, Inc.

Efektivní softwarové projekty

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 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 Press ZONER software s.r.o. Nové sady 18, 602 00 Brno tel.: 532 190 883, fax: 543 257 245 e-mail: [email protected] 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


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


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í architekta, 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 roce 2003 pracovat pro Microsoft, měl na starosti 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ástrojů 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 softwarové 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 podařilo vyjádřit je v knize, která se stejnou měrou věnuje praxi i teorii, a která nedopadla jako jedna velká reklama 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 procesu vývoje software řadu problémů a v důsledku způsobil neúspěch velké části projektů. 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ároč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í projektů 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


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č produktu jsem hrál roli 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 teoretický 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 projektu, 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


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 Scrum (jedné z agilních metodik) – jediného místa, kde můžete sledovat průběh všech prací – ale používané nástroje 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 ruč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 pro 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, proč 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í, zruč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 pro 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é projektové 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 provést konzistentní skupinou procesů. 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 realistickou metodiku pro většinu typických IT projektů a týmů. Nemusí být dost formální, aby vyhověla nároků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.

xxiii

xxiv


Jak tuto knihu číst Součástí VSTS je mechanismus řízení procesu nazvaný Microsoft Solutions Framework (MSF), který obsahuje základní ideu modelu týmu, vycházející ze skupiny rovnocenných kolegů. Model týmu umožňuje různou míru specializace. MSF definuje sedm okruhů, 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ároků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 pro 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 netvrdí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é pro různé organizace a projekty. VSTS

xxv

xxvi


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 Microsoft. 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 podrobně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 rozptý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.

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.


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 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 proto 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é redaktorce, 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 pro 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 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, Will Stott, Dan Sullivan, David Trowbridge, Mike Turner, Kumar Vadaparty a Peter Williams. Ve finiši mi velmi pomohli xxix

xxx


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

Chvála knihy Software Engineering with Microsoft Visual Studio Team System

Recommend Documents