Hodnotocentrické metodiky

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

Obrázek 2.1

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

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

27

28

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

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

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

HODNOTOCENTRICKÉ METODIKY

základních hodnot a postupů a podle potřeby přidá další. Jak uvádí předchozí citát, byl tento přístup mnohem úspěšnější. V Team System existují dvě plnohodnotné metodiky, obě vycházející ze společného základu nazvaného Microsoft Solutions Framework (MSF): • MSF for Agile Software Development. Prostá metodika, držící se principů Agile Alliance.5 Metodiku MSF Agile používejte u projektů s krátkou životností a u týmů, pro které je důležitý výsledek a které mohou pracovat bez hory průběžné dokumentace. Je to pružný rámec, který vám pomůže vytvořit přizpůsobivý systém pro vývoj software. Předpokládá nutnost reagovat na změny, zdůrazňuje dodávání fungujícího software a jako hlavní měřítko úspěchu propaguje prověření zákazníkem. • MSF for CMMI Process Improvement. Metodika navržená tak, aby vyhovovala CMMI 3. úrovně podle definice Software Engineering Institute.6 Rozšiřuje MSF Agile o formálnější plánování, více dokumentace a pracovních výsledků, více podpisových bran a podrobnější sledování času. MSF for CMMI své činnosti jasně ukazuje v Oblastech činnosti (Practice Areas) a Cílech (Goals), čímž vychází vstříc organizacím, které CMMI používají jako základ pro vylepšení svých procesů, nebo které usilují o hodnocení CMMI. Ale narozdíl od předchozích pokusů o metodiku CMMI používá MSF hodnotocentrický přístup, který umožňuje celý rámec CMMI aplikovat agilně a bez zbytečné režie.7 Obě instance MSF jsou hodnotocentrické. V obou případech MSF využívá ověřené postupy společnosti Microsoft a jejích zákazníků a oborových zkušeností. Hlavní rozdíl mezi nimi spočívá v úrovni formality schvalování, míře sledování vynaloženého výkonu a hloubce použitých metrik. Například MSF for CMMI Process Improvement považuje hodnotitele nebo auditora za samostatnou roli a poskytuje činnosti a reporty, které může auditor při hodnocení metodiky použít. V jeho agilním příbuzném se shoda se vzorovou metodikou neuvažuje. Hladká integrace obou variant MSF do Team System podporuje 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ástrojích a podle potřeby se jimi řídit.

29

30

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

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

Proč vyvíjet iterativně Pro iterativní vývoj mluví řada velmi příjemných důvodů: 1. Řízení rizik. Požadovaný výsledek není dopředu znám. Abyste mohli mít rizika pod kontrolou, musíte své požadavky a předpoklady v návrhu obhájit nebo vyvrátit tak, že budete prvky cílového systému implementovat postupně, těmi nejriskantnějšími počínaje. 2. Hospodárnost. V nejistém obchodním prostředí je důležité, abyste své priority často promýšleli a investice považovali za finanční opce. Čím více pružnosti získáte díky brzkým platbám a častým kontrolám, tím hodnotnější tyto opce budou. 3. Soustředění. Lidé dovedou v jednom okamžiku myslet jen na omezené množství věcí. Když práci seskupíte do krátkých iterací, všichni členové týmu se na zadanou práci mohou lépe soustředit – obchodní analytici lépe odhadnou požadavky, architekti přijdou s lepším návrhem, vývojáři s lepším kódem atd.

HODNOTOCENTRICKÉ METODIKY

4. Motivace. Softwarový tým nic nepovzbudí lépe, než když může vidět fungující, byť předběžnou, verzi programu. Ani sebepodrobnější rozbory specifikací se tomu nemohou vyrovnat. 5. Teorie řízení. Krátké iterace snižují míru chyby ve vašich odhadech a rychle z nich zjistíte, jak přesné vaše plány projektu jsou. 6. Zapojení zadavatelů. Zadavatelé (zákazníci, uživatelé, vedení) rychle vidí výsledky a více se do projektu zapojí a nabídnou více svého času, rad a financí. 7. Neustálé vzdělávání. Celý tým se z každé iterace poučí, takže se přesnost, kvalita a vhodnost hotového projektu neustále zlepšují. To vše lze shrnout slovy: „Iterativnost je vhodná pro všechny projekty... a pro ty s vysokými riziky je nevyhnutelná“.11 Přesto se stále najde mnoho IT organizací, které iterativní vývoj ještě nezavedly. Iterativní vývoj v praxi vyžaduje, aby tým i jeho manažer měli přesný přehled o veškeré práci, kterou je nutné udělat, a aby ji mohli mezi jednotlivými krátkými iteracemi často sledovat a měnit priority. Tyto časté aktualizace vyžadují přehledný úkolník, nejlépe doplněný automatickým sběrem dat, například takovým, který nabízí databáze pracovních úkolů ve VSTS. Při hodnotocentrickém přístupu k iterativnímu vývoji se pracuje v mnoha cyklech, při nichž se jednotlivé činnosti časově překrývají. Výchozím plánovacím prvkem je „iterace“. Ta představuje pevný počet týdnů, někdy označovaných jako „časový rámec“, do kterých je rozvržen stanovený úkol. Iterace se používají jako interval pro plánování zamýšlených scénářů, měření toku hodnoty, ohodnocení stávající metodiky, hledání slabých míst a provádění úprav (obrázek 2.2). V kapitolách věnovaných vývoji a testování se budu zabývat podrobněji cykly zanášení změn a denních sestavení, kterým se obvykle říká „inkrementy“ a které přirozeným způsobem iteraci vedou.12

31

EFEKTIVNÍ SOFTWAROVÉ PROJEKTY

32

Program

Iterace Projekt Denní sestavení

Zanesení změn Schválené sestavení

Obrázek 2.2

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

Délka Ve skutečnosti se délka iterací liší projekt 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. Velikost dávky musí být tak malá, jak je to jen při zachování tohoto cíle možné, jak vysvětluje David Anderson v Agile Management for Software Engineering: Malé dávky jsou zásadní pro tok! Jsou také nezbytné pro kvalitu. Lidská přirozenost vede při vývoji software k tomu, že při zpracovávání větších dávek nejsou inženýři tak nároční a věnují méně pozornosti detailům. Například, když se korektury kódu provádějí v malých dávkách, jejich příprava je rychlá a jejich provedení také. Protože kódu