Ve stavebnictví je vše jasné. Rodinných domů byly postaveny miliony, takže jde o relativně rutinní činnost. Na začátku je časový plán a rozpočet, jejichž nedodržení lze poměrně brzy zjistit a ve výsledku nemají významnější negativní dopad. Rizika špatného návrhu jsou poměrně nízká a náklady na správný návrh jsou relativně malé v porovnání s náklady na vlastní stavbu. Jedná se v podstatě o neustále opakovanou a opakovatelnou činnost. Naproti tomu při softwarovém vývoji je vše přesně naopak. Rizika špatného návrhu jsou poměrně vysoká, přičemž správný návrh je často dražší než vlastní „výroba“. Opakovaný a opakovatelný softwarový projekt se téměř nevyskytuje – lze totiž předpokládat, že takový produkt již někdo nabízí za cenu, které vývoj na zakázku může těžko konkurovat. S trochou nadsázky lze říci, že každý projekt je z velké části nový a první. Objektivnější je tedy srovnávat softwarový vývoj se stavbou velmi netypických objektů, jako například jadernou elektrárnou Temelín, Eiffelovkou anebo vodním dílem Gabčíkovo. U těchto staveb je navíc rozpočet a termín dodržen opravdu pouze výjimečně. Na druhou stranu máte při softwarovém vývoji také výhody, o kterých by se vám při stavbě domu ani nesnilo. Můžete návrh postupně měnit a vylepšovat „za pochodu“, tak jak získáváte zkušenosti a zpětnou vazbu od zákazníka. Zároveň softwarový produkt nabízí užitnou hodnotu již v počátečních fázích vývoje, a lze ho tudíž vyvíjet v iteracích, přizpůsobovat a zpřesňovat jeho kurz apod. Naproti tomu si představte, jakou hodnotu by měl dům bez oken a bez střechy nebo zda by stavební firma začala pracovat na domě, aniž byste jí předem dali kompletní plány. V softwarovém vývoji však bohužel neplatí některé zákonitosti vyjadřované tzv. železným trojúhelníkem projektového řízení, tedy čas–zdroje–výsledek. Ve stavebnictví (alespoň teoreticky) vykonají dva zedníci dvojnásobnou práci za jednotku času, nebo vykonají pevně danou práci za poloviční čas v porovnání s jedním zedníkem. V softwarovém vývoji tyto zákonitosti fungují velmi nespolehlivě – ve srovnání se stavbou domu je to dáno například tím, že procesy jsou mnohem složitější, produktivita zdrojů je velmi nerovnoměrně rozdělena a ve skutečné pracnosti jednotlivých úloh je velký rozptyl. Zkusme se proto zamyslet nad následujícími otázkami:

• Kdo je „zákazníkem“ projektového manažera a kdo jsou další osoby ve hře?
• K čemu potřebujeme projektového manažera?
• Jaké klíčové otázky by měl být schopen odpovědět?
• Jak rozpoznáte blížící se problémy včas?
• Které metriky by měl používat k zodpovězení těchto otázek?
• Jak, kdy, s jakým zpožděním a s jakou přesností získáte tyto metriky?

Obr. 1: Časový vývoj sledované metriky v porovnání se skutečným výkonem

Úskalí předepisujících metrik

K metrikám lze přistupovat dvojím způsobem. První je tzv. popisný (deskriptivní) přístup k metrikám. V tomto případě nám metriky slouží jako kompas, podle kterého se orientujeme a případně měníme kurz. Druhý přístup je tzv. předepisující (preskriptivní), při kterém je metrikami myšleno sledování ukazatelů, nebo i jednoho ukazatele, u kterých je žádoucí dosáhnout nějaké hodnoty. V tomto případě slouží metriky k hodnocení postupu, úspěšnosti nebo pracovní výkonnosti. Ve stavebnictví se řídíme předepisujícími metrikami – utracené peníze vůči rozpočtu, hotová práce vůči časovému plánu apod. Tyto metriky nám jednoznačně řeknou, jak dobře, nebo špatně si náš projekt vede. Ve vývoji softwaru to ale není tak jednoduché. Žádná metrika, která by nám řekla, jaká je dokončenost nebo kvalita vytvářeného produktu, neexistuje. Proto si pomáháme pomocnými metrikami, které nám nahrazují „skutečné“ metriky. A zde je zakopaný pes. Metriky vlastní pak nejsou cílem, jsou pouze aproximací cíle. Kladení přehnaného důrazu vytváří nesprávnou motivaci a deformuje chování lidí – nesnaží se totiž o splnění cíle, ale o splnění pomocné metriky. Jak již bylo popsáno (obr. 1), nastává v delším časovém období výrazné zlepšení sledované metriky, ale jeho pozitivní efekt na skutečný výkon je pouze krátkodobý.

Je tomu tak proto, že lidé mají přirozenou tendenci usilovat o co nejvyšší odměnu s nejmenší vynaloženou námahou. Následující příklady mohou někomu připadat extrémní, ale jsou bohužel zcela reálné a v džungli a nejistotě softwarového vývoje snadno realizovatelné. Uvažte, co mohu dělat, pokud budu hodnocen za:

• počet napsaných řádků kódu – budu psát kód co nejdelší, tím bude navíc hůře čitelný,
• počtu opravených chyb – budu si předem v kódu nechávat chyby, které pak půjdou snadno opravovat,
• počtu objevených chyb – budu hledat formální nedostatky, překlepy apod., důležité chyby zůstanou přehlédnuty.

Multidimenzionální sledování metrik

Výše uvedené příklady by vás neměly dovést k závěru, že metriky nemá smysl sledovat, ale právě naopak. Z naznačené pasti vede cesta přes sledování co největšího množství metrik současně. Tím se ubráníte zploštění pohledu a deformaci chování, která je typická při přehnaném důrazu na některou z metrik. Změnit totiž chování tak, abych ovlivnil žádoucím směrem všechny měřené metriky, je v praxi nemožné. Zároveň budete mít mnohem větší přehled o reálném stavu projektu, budete schopni vidět příčinné souvislosti mezi trendy jednotlivých metrik apod. Vezměme si jednoduchý příklad. Řekněme, že vyvíjíme systém a máme pro něj připravenou řadu testů. Během vývoje dává dobré výsledky osmdesát procent testů a toto číslo se postupně zlepšuje až na sto procent. Při povrchním pohledu ideální stav. V multidimenzionálním přístupu ale můžete sledovat ještě další metriku – procentuální pokrytí funkcí systému testy. A zde například můžete vidět setrvalý pokles – jasný příznak stavu, kdy se vyvíjí nová funkčnost, ale dostatečně se netestuje, například z důvodu termínového stresu. Při plochém pohledu na jedinou metriku (procento úspěšných testů) tedy žijete v nevědomosti a nevíte, že pod vaší židlí tiká časovaná bomba. Při pohledu přes více metrik jste ale schopni ji s dostatečným předstihem odhalit. Při odměňování týmu jej hodnoťte za hodnotu, kterou přinesl zákazníkovi. Tuto hodnotu můžete měřit vyfakturovanou částkou a též spokojeností zákazníka (přímo související s budoucími fakturovanými částkami). Metriky jsou pouhými ukazateli kurzu, nejsou tedy cílem, ale pouze prostředky k němu vedoucími. Další kontraproduktivní aktivitou je snaha o relativní porovnávání jednotlivých členů týmu pomocí metrik. Který vývojář je lepší? Ten, který opravil deset překlepů v dokumentaci, anebo ten, kdo dva dny hledal příčinu jedné chyby, kterou první vývojář nebyl vůbec schopen nalézt?

Obr. 2: Průběžné sledování kvality produktu

Jak metriky získat?

Skutečná otázka zní: jak tyto metriky získat? Jednu možnost můžeme rovnou zavrhnout, a to získávání metrik „vykazováním“ činnosti jednotlivými uživateli, tedy ve své podstatě oddělením nástrojů, které používají, od procesů, kterými je chcete řídit. U této metody bylo mnohokrát prakticky prověřeno, že nefunguje. Je přirozenou lidskou vlastností vytlačovat na okraj všechny činnosti, které jsou vnímány jako zátěž zdržující od zbytečné práce. Vykazováním v nejlepším případě získáte nepříliš přesné metriky s takovým zpožděním, že jejich hodnota bude diskutabilní. V nejhorším případě pak budete čelit partyzánské válce ze strany vykazujících. V každém případě připadne čas strávený vykazováním na vrub „skutečné práce“. Jediným možným způsobem tak zůstává automatický sběr metrik během práce vývojářů a ostatních členů týmu. Zde mluvíme o tzv. instrumentaci denních aktivit. Klíčovým faktorem pro bezproblémovou akceptaci uživateli je vnímání „nezdržuje mne to od práce“. Pak si můžete být jisti hladkou spoluprací vedoucí k přesnému a včasnému sběru informací pro získání důležitých metrik. Pozitivními důsledky budou mimo jiné:

• snížení nákladů,
• automatizovaná podpora procesů,
• auditovatelnost procesů (legislativa, regulace apod.).

Měli byste proto při vývoji softwaru používat takové nástroje, které tyto principy respektují. Investice do nich se vám bohatě vyplatí.

Obr. 3: Sledování postupu práce a míry dokončenosti

Jak metriky využívat?

Využití metrik při procesu vývoje softwaru si ukážeme na příkladech reportů produkovaných produkty Microsoft Visual Studio Team System. První příklad (obr. 2) ukazuje vývoj kvalitativních ukazatelů v čase. Barevné sloupečky označují množství testů, které dopadly dobře, neurčitelně a špatně. V tomto případě je trend jednoznačně pozitivní. Mnohem důležitější je však srovnání s dalšími metrikami. Pokrytí kódu testy stoupá – jsou zaváděny nové testy. Celkové množství známých chyb klesá – chyby jsou svědomitě opravovány. A konečně množství změn v kódu v čase klesá – produkt se stabilizuje. Při porovnání všech těchto metrik si můžeme být prakticky jisti, že kvalita produktu bude velmi dobrá.

Druhý příklad (obr. 3) již tak idylický není. Znázorňuje množství neimplementovaných scénářů (červená), implementovaných, ale nepředaných/neotestovaných scénářů (žlutá) a konečně implementovaných a předaných/otestovaných scénářů (zelená) v čase. Jednoznačně pozitivní je rychlý a trvalý úbytek červených, tedy neimplementovaných scénářů. Dalším pozitivem je dobré plánování projektu – celková výška, tedy objem uvažované práce se v čase nemění. Za negativní lze ale považovat nárůst implementovaných, ale nepředaných/neotestovaných scénářů v čase. Indikuje problém s testováním funkčnosti anebo s jejím předáváním zákazníkovi. Trvale tedy vytváříme novou funkčnost rychleji, než ji stačíme odevzdávat. Je zřejmé, že tento stav je dlouhodobě neudržitelný a povede v budoucnu ke konfliktům a skluzům. Slabým místem je tedy jednoznačně komunikace se zákazníkem a měli bychom se též zamyslet, zda jsme si dostatečně jisti tím, že vyvíjíme to, co zákazník chce.

Odstrašujícím příkladem je obrázek 4. Ten nám ukazuje množství naplánované práce a jeho vývoj v čase s tím, že je práce rozdělena na položky (scénáře) vzniklé před vytvořením plánu (světlejší barva) a po vytvoření plánu (tmavší barva). Jednoznačně zde dochází k tzv. nafukování rozsahu (scope creep). Během vývoje se vynořují nové požadavky a položky, které postupně vytlačují ty původně zamýšlené, jež jsou z termínových důvodů škrtány. Z původních 85 plánovaných požadavků tedy implementujeme pouhou polovinu (43), zato se nám do projektu protlačilo 74 nových požadavků vzniklých až po vytvoření plánu. Projekt se řítí do nevyhnutelného špatného konce a pouhé překročení času a rozpočtu je ještě poměrně optimistický scénář.

Obr. 4: Ilustrace problému „nafouknutí rozsahu“

Shrnutí

Vývoj softwaru se neřídí stejnými pravidly jako stavba domu. Jedná se o náročnou disciplínu srovnatelnou spíše se stavbou velmi atypického díla. Protože jednoznačně platné metriky nejsou k dispozici, musíme si pomáhat pomocnými metrikami. Přílišné spoléhání na jednu metriku nás může zavést do slepé uličky – metrika sama o sobě není cílem, cílem je spokojený zákazník. Proto je důležitý multidimenzionální pohled, ve kterém lze jednotlivé metriky vidět v souvislostech. Data k získání těchto metrik je nutné sbírat automaticky pomocí moderních nástrojů propojených s procesy. V opačném případě ztroskotáme na nedostatku součinnosti uživatelů. Jedině tak budeme mít dostatek dat pro měření postupu, zajištění kvality a včasnou identifikaci případných problémů.

Autor je architektovým specialistou ve společnosti Microsoft Česká republika.