Metriky pro řízení agilních vývojových týmů

Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod

Metriky pro řízení agilních vývojových týmů Bakalářská práce

Autor:

Jana Holbová, DiS. Informační technologie, Manažer projektů IS

Vedoucí práce:

Praha

Mgr. Miroslav Široký, DiS.

Duben 2014

Prohlášení: Prohlašuji, že jsem bakalářskou práci zpracovala samostatně a v seznamu uvedla veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámena se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Českém Krumlově, dne 25. dubna 2014

Jana Holbová, DiS.

Poděkování Ráda bych poděkovala Mgr. Miroslavu Širokému, DiS., za cenné rady, věcné připomínky a vstřícnost při konzultacích k vypracování této bakalářské práce.

Anotace Práce se zabývá problematikou používání metrik za účelem řízení týmu vývojářů softwarového startupu používajícího agilní vývojový proces. Teoretická část práce poskytuje přehled terminologie a obecné zásady pro práci s metrikami. Praktická část práce pak uvádí přehled metrik vhodných pro sledování vývojových týmů a jejich jednotlivých členů a navrhuje praktiky a postupy (metodiku) práce s těmito metrikami za účelem stabilizace a rozvoje vývojového týmu v prvních fázích startupu (před uvedením výsledného produktu na trh a bezprostředně po něm). Práce je užitečná pro manažery, kteří chtějí, aby jejich rozhodování v oblasti řízení lidských zdrojů vývojových týmů bylo podložené reálnými daty a tím byla omezena možnost nesprávného (subjektivního) vyhodnocení posuzovaných situací. Klíčová slova: metrika, startup, vývojář, vývojový tým

Annotation This thesis deals with applying metrics to management of software startup development teams using an agile development process. The theoretical part provides terminology and basic rules for effective use of metrics. The practical part then introduces an overview of metrics suitable for monitoring development teams and their individual members and proposes practices and methods of working with these metrics in order to stabilize and growth of the development team in the first stages (before and immediately after the product is introduced to the market). The thesis may be useful for managers that want their human-resources-related decisions to be based on real data and thus the risk of incorrect (subjective) assessment of real world situations be minimized. Key words: metrics, software developer, software development team, startup

Obsah Úvod .................................................................................................................................................. 7 1.

Zvolené metody zpracování........................................................................................................ 9

2.

Metriky obecně ......................................................................................................................... 10 2.1. Definice metriky ................................................................................................................... 10 2.2. Klasifikace metrik ................................................................................................................ 13 2.3. Použití metrik ....................................................................................................................... 14 2.3.1.

Hledání metrik .................................................................................................... 14

2.3.2.

Vlastnosti dobrých metrik .................................................................................. 15

2.3.3.

Vyhodnocování metrik ....................................................................................... 16

3.

Zákonitosti skladby vývojových týmů ..................................................................................... 21

4.

Metriky vývojových týmů ........................................................................................................ 23 4.1. Metriky množství odvedené práce........................................................................................ 23 4.1.1.

Objem dokončené práce (ODP) .......................................................................... 23

4.1.2.

Počet dokončených úkolů (PDU) ....................................................................... 24

4.1.3.

Průměrná složitost dokončeného úkolu (SDU) .................................................. 25

4.1.4.

Soustava metrik ODP + PDU + SDU ................................................................. 25

4.1.5.

Trend objemu dokončené práce (TODP)............................................................ 26

4.1.6.

Počet účastí na řešení nepřidělených úkolů (UNU)............................................ 27

4.1.7.

Počet odstraněných defektů (POD) .................................................................... 28

4.2. Metriky kvality odvedené práce ........................................................................................... 28 4.2.1.

Dopad vyprodukovaných defektů (DVD) .......................................................... 28

4.2.2.

Počet nedokončených úkolů (PNU) ................................................................... 29

4.2.3.

Pokrytí řešených oblastí (PRO) .......................................................................... 29

4.3. Metriky dosaženého výsledku .............................................................................................. 31 4.3.1.

Počet aktivací (AKT) .......................................................................................... 31

4.3.2.

Střední doba mezi aktivacemi (SAKT) .............................................................. 31

4.3.3.

Počet deaktivací (DEA) ...................................................................................... 32

4.3.4.

Střední doba mezi deaktivacemi (SDEA) ........................................................... 32

4.3.5.

Úspěšnost aktivací (UAKT) ............................................................................... 32

4.3.6.

Růst aktivací (RAKT)......................................................................................... 33

4.3.7.

Střední doba růstu aktivací (SRAKT) ................................................................ 33

4.3.8.

Trendy metrik dosaženého výsledku .................................................................. 34

4.4. Metriky příspěvku k dosaženému výsledku ......................................................................... 34

5.

4.4.1.

Přínos odvedené práce (POP) ............................................................................. 34

4.4.2.

Pracovní záběr (ZAB)......................................................................................... 35

4.4.3.

Chybovost (CHYB) ............................................................................................ 35

4.4.4.

Relativní metriky k metrikám POP, ZAB a CHYB............................................ 36

4.4.5.

Přínos k aktivacím (PAKT) ................................................................................ 36

4.4.6.

Přínos k deaktivacím (PDEA) ............................................................................ 37

Práce s metrikami vývojových týmů ........................................................................................ 39 5.1. Zavedení metrik do praxe ..................................................................................................... 39 5.2. Sběr dat ................................................................................................................................. 40 5.3. Vyhodnocování sebraných dat.............................................................................................. 40 5.4. Použití metrik pro hodnocení ............................................................................................... 45 5.5. Použití metrik pro optimalizaci ............................................................................................ 45

Závěr ................................................................................................................................................ 47 Seznam použité literatury ................................................................................................................ 49

Úvod Metriky jsou důležitým nástrojem managementu. Podstatou managementu je řízení zdrojů (např. peněz nebo lidské práce) tak, aby jejich použití směřovalo ke splnění stanoveného cíle. Aby bylo možné určit, zda a jakým způsobem se splnění tohoto cíle přibližuje či vzdaluje, je potřeba existence zpětné vazby, která tyto informace poskytne. Právě tuto zpětnou vazbu poskytují metriky. Na základě takto získaných informací je pak možné přijímat rozhodnutí, která povedou ke krátkodobým (např. změna priority úkolu) či dlouhodobým (např. optimalizace pracovního postupu) zlepšením. Naopak bez zpětné vazby je řízení založeno na intuici, nikoli na doložitelných skutečnostech, což je z pohledu managementu nežádoucí stav. To potvrzuje i známý citát Toma DeMarca „You can not control, what you can not measure“ [11, str. 11] neboli „Nemůžete řídit to, co nemůžete (z)měřit“. Metriky poskytují dva různé pohledy na sledovaný proces. Z pohledu operativního řízení přehled o tom, co se děje v okamžiku, kdy jsou metriky sbírány. Z pohledu strategického řízení pak nezkreslený historický přehled o průběhu celého procesu, který je důležitý hlavně proto, že lidská paměť funguje nedokonale a člověk má přirozenou tendenci potlačovat vzpomínky na negativní skutečnosti [22]. Příkladem může být neúspěšná část celkově úspěšného projektu, která může být tímto vlivem zapomenuta, přitom poznatky získané z tohoto dílčího neúspěchu by v budoucnu mohly pomoci. U startupů jsou metriky ještě o to důležitější, že efektivita často rozhoduje o jejich úspěchu či neúspěchu. Typický startup se vyznačuje tím, že na jeho počátku jsou myšlenka a omezené zdroje. Cílem startupu je přetvořit myšlenku (skrze za tím účelem vytvořený projekt) v konkurenceschopný produkt. To se ale musí povést v čase, který má startup pokrytý svými omezenými zdroji. Efektivní čerpání těchto zdrojů se u startupů typicky zajišťuje kombinací dvou nástrojů: používáním agilních a zejména pak „štíhlých“ (angl. „lean“) metodik a skladbou a efektivním fungováním projektového týmu. Tyto nástroje do značné míry odpovídají i oblastem aktuálního výzkumu v softwarovém inženýrství.

7

Softwarové inženýrství se po dlouhou dobu zaměřovalo na kvalitu zdrojového kódu. Později, na základě zjištění, že kvalita zdrojového kódu do značné míry odráží kvalitu vývojového procesu, se středem zájmu staly vývojové metodiky. Někteří přední softwaroví inženýři (např. Fred Brooks nebo Tim Lister) ovšem již nějaký čas upozorňují na to, že kvalitní vývojový proces sám o sobě nestačí a že je potřeba se zaměřovat i na výběr a rozvoj lidských zdrojů a jejich skladbu do projektových týmů. To se v poslední době stalo skutečností a potvrzuje to mj. vznik hnutí „software craftsmanship“ [18]. Na trhu existuje řada publikací zabývajících se metrikami pro řízení týmů. Problémem je, že většina z nich (za všechny jmenujme např. [24]) se problematice věnuje pouze v obecné (psychologické) rovině a nezohledňuje tak specifika oblasti vývoje softwaru. Určitou výjimkou je kniha Codermetrics [2]. Nejen, že je zaměřena na vývoj softwaru, ale dokonce předpokládá použití agilních metodik a popisuje odlišnosti používání metrik podle fáze projektu (fáze před prvním vydáním výsledného produktu, fáze bezprostředně po vydání výsledného produktu, fáze údržby a rozvoje stabilního produktu) a podle typu výsledného produktu (např. desktopový software, vnitropodnikové serverové systémy, cloudové služby). Její nevýhodou je ale skutečnost, že se věnuje výhradně činnostem bezprostředně souvisejícím se samotným vývojem softwaru a nepostihuje tedy činnosti jako jsou průzkum či reverzní inženýrství, které jsou pro startupy neméně důležité. Cílem této práce je navržení množiny praktik a postupů (metodiky) práce s metrikami pro manažery začínajících firem (startupů), zejména se zaměřením na úvodní fázi projektu, tedy skladbu vývojového týmu a jeho stabilizaci. Metriky optimalizující fungování již stabilního vývojového týmu nejsou vzhledem k rozsahu práce řešeny.

8

1. Zvolené metody zpracování Práce vychází z rešerše odborné literatury, s ohledem na rychlý vývoj zpracovávané oblasti pak zejména literatury vydané v posledních letech. Teoretická část uvádí definice pojmů a shrnuje obecné zásady práce s metrikami. V praktické části práce je popsán soubor metrik vhodných pro použití v prvních fázích startupu. Tyto metriky vychází z metrik uvedených v literatuře, jsou ale přeuspořádané, vhodně pojmenované a doplněné. Dále jsou uvedeny metody práce s těmito metrikami, zejména během jejich vyhodnocování. Pro ilustrativní příklady v praktické části jsou použita skutečná data v anonymizované podobě.

9

2. Metriky obecně 2.1. Definice metriky Aby nedocházelo k nedorozuměním, je potřeba pojem „metrika“ nějak definovat. Pro tento účel se dobře hodí poměrně nedávno vydaná norma ISO/IEC/IEEE 24765 [15], jejímž cílem je poskytnout přehled stávající (poněkud roztříštěné) terminologie v oblasti systémového a softwarového inženýrství a přispět tím k její postupné standardizaci. Tato norma uvádí seznam definic pro každý obsažený pojem, přičemž každá definice je opatřena odkazem na zdroj (nejčastěji jiná stávající norma z dané oblasti). Následující odstavce obsahují seznam definic pojmu „metrika“ a souvisejících pojmů „měření“, „indikátor“, „entita“ a „atribut“: metrika [15, str. 216] 1. „kombinace dvou nebo více měr nebo atributů“ [ISO/IEC 20926:2003 Software Engineering – IFPUG 4.1 Unadjusted Functional Size Measurement Method – Counting Practices Manual] 2. „kvantitativní vyjádření míry, do jaké má nějaký systém, komponenta nebo proces daný atribut“ 3. „definovaná metoda měření a měřítko“ [ISO/IEC 14598-1:1999 Information Technology – Software Product Evaluation – Part 1: General Overview] měření [15, str. 211] 1. „proces přiřazení čísla nebo kategorie entitě za účelem popisu atributu této entity“ [IEEE 1061-1998 (R2004) IEEE Standard for Software Quality Metrics Methodology] 2. „přiřazení čísel objektům systematickým způsobem za účelem reprezentace vlastností těchto objektů“ [ISO/IEC TR 19759:2005 Software Engineering – Guide to the Software Engineering Body of Knowledge (SWEBOK)] 3. „použití metriky pro přiřazení hodnoty (čísla nebo kategorie) atributu entity na základě stupnice“ [ISO/IEC 14598-1:1999 Information technology – Software Product Evaluation – Part 1: General Overview]

10

4. „množina operací, jejichž cílem je určení hodnoty míry“ [ISO/IEC 25000:2005 Software Engineering – Software Product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE] 5. „přiřazení hodnot aspektům softwarového inženýrství (produktům, procesům nebo zdrojům) a modelům od nich odvozeným na základě statistiky a odborných znalostí nebo jinými technikami“ [ISO/IEC TR 19759:2005 Software Engineering – Guide to the Software Engineering Body of Knowledge (SWEBOK)] 6. „přiřazení relativní hodnoty“ [ISO/IEC 20926:2003 Software Engineering – IFPUG 4.1 Unadjusted Functional Size Measurement Method – Counting Practices Manual] 7. „číselný údaj, rozsah nebo množství získané měřením“ [IEEE 1061-1998 (R2004) IEEE Standard for Software Quality Metrics Methodology] indikátor [15, str. 172] 1. „míra poskytující odhad nebo hodnocení určených atributů odvozených od modelu s ohledem na vytyčené informační potřeby“ [ISO/IEC 15939:2007 Systems and Software Engineering – Measurement Process a ISO/IEC 25000:2005 Software Engineering – Software Product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE] 2. „míra použitelná k odhadu nebo předpovědi jiné míry“ [ISO/IEC 14598-1:1999 Information Technology – Software Product Evaluation – Part 1: General Overview] 3. „zařízení nebo proměnná nastavitelná do předem definovaného stavu na základě výsledku procesu nebo výskytu určené podmínky“ entita [15, str. 126] 1. „věc významná pro uživatele, o níž se uchovávají informace“ [ISO/IEC 20968:2002 Software Engineering – Mk II Function Point Analysis – Counting Practices Manual] 2. „v oblasti programování počítačů každá položka, která může být pojmenována nebo zaznamenána v (počítačovém) programu“ 3. „objekt (věc, událost nebo jiný pojem) vyskytující se v modelu“ [ISO/IEC 154741:2002 Information Technology – CDIF Framework – Part 1: Overview]

11

4. „objekt, který má být charakterizován měřením jeho atributů“ [ISO/IEC 15939:2007 Systems and Software Engineering – Measurement Process a ISO/IEC 25000:2005 Software Engineering – Software Product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE] 5. „reprezentace množiny skutečných nebo abstraktních věcí, které jsou považovány za věci stejného typu, a to z toho důvodu, že mají stejné vlastnosti a mohou se účastnit stejných vztahů“ [IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject)] 6. „základní věc významná pro uživatele, o níž je uchováván soubor skutečností“ [ISO/IEC 20926:2003 Software Engineering – IFPUG 4.1 Unadjusted Functional Size Measurement Method – Counting Practices Manual] 7. „modelovaný objekt“ [ISO/IEC 15476-4:2005 Information Technology – CDIF Semantic Metamodel – Part 4: Data Models] 8. „logická komponenta datového úložiště reprezentující základní věc významnou pro uživatele, o níž je uchovávána informace“ [ISO/IEC 29881:2008 Information Technology – Software and Systems Engineering – FiSMA 1.1 Functional Size Measurement Method] atribut [15, str. 27] 1. „vlastnost spojená s množinou reálných nebo abstraktních věcí, která charakterizuje určitý zájmový prvek“ [IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject)] 2. „nedílná vlastnost nebo charakteristika entity kvantitativně nebo kvalitativně rozeznatelná lidskými nebo automatickými prostředky“ [ISO/IEC 15939:2007 Systems and Software Engineering – Measurement Process a ISO/IEC 25000:2005 Software Engineering – Software Product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE] 3. „měřitelná fyzická nebo abstraktní vlastnost entity“ [IEEE 1061-1998 (R2004) IEEE Standard for Software Quality Metrics Methodology]

12

4. „určitelný vztah mezi objektem a hodnotou“ [ISO/IEC 19500-2:2003 Information Technology – Open Distributed Processing – Part 2: General Inter-ORB Protocol (GIOP)/Internet Inter-ORB Protocol (IIOP)] 5. „funkce z oboru instancí nějaké třídy do oboru instancí tříd hodnot určitého atributu“ [IEEE 1320.2-1998 (R2004) IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject)] 6. „jedinečná informace o entitě“ [ISO/IEC 20968:2002 Software Engineering – Mk II Function Point Analysis – Counting Practices Manual] 7. „jednohodnotová charakteristika entity nebo vztahu“ [ISO/IEC 15474-1:2002 Information Technology – CDIF framework – Part 1: Overview] Jak je patrné, výše uvedené definice jsou velmi neurčité a vzájemně provázané, v některých případech

dokonce

nejednoznačné.

Příkladem

takové

nejednoznačnosti

může

být

jednohodnotovost v sedmé (poslední) definici pojmu „atribut“, která může (a nemusí) být chápána jako jednorozměrnost1. Pro účely této práce byly tedy zvoleny následující definice, které by měly lépe vystihovat podstatu výše uvedených pojmů: metrika je kvantitativní vyjádření atributu entity entita je sledovaný (abstraktní či konkrétní) objekt atribut je vlastnost entity

2.2. Klasifikace metrik Podobně jako fyzikální veličiny můžeme dělit na přímo a nepřímo měřitelné, jsou přímo a nepřímo měřitelné i metriky2. Z této skutečnosti, kterou připomíná i slavný citát připisovaný italskému hvězdáři Galileu Galilei „What is not measurable make measurable“ [11, str. 6]

1

Z matematického hlediska hodnota může (ale nemusí) být skalární (jednočíselná), jednočíselná hodnota pak dále může (ale nemusí) být vyjádřitelná reálným číslem. Komplexní a hyperkomplexní čísla ani vektory a tenzory (obecně) za jednorozměrné považovat nelze. 2

Příkladem nepřímo měřitelné fyzikální veličiny je „rychlost“, kterou lze získat podílem přímo měřitelných veličin „délka“ a „čas“. Příkladem nepřímo měřitelné (obecné) metriky je „cena rodinného domu“, kterou lze získat kombinací jiných přímo či nepřímo měřitelných metrik, jakými jsou „zastavěná plocha“, „obestavěný prostor“, „dostupnost inženýrských sítí“ apod.

13

neboli „Učiňte měřitelným to, co měřitelné není“, vyplývá, že hodnotu metriky lze získat buď měřením (přímou kvantifikací) nebo výpočtem z jiných metrik (nepřímou kvantifikací). Metriky lze rovněž dělit na absolutní a relativní. Hodnota absolutní metriky je vždy výsledkem měření a je samostatně použitelná. Naopak hodnota relativní metriky je vždy výsledkem výpočtu a vztahuje se k jiné (referenční) hodnotě. Bez této referenční hodnoty je pak její vypovídací schopnost omezená. Podobných klasifikací metrik bychom našli celou řadu. Výše uvedené klasifikace však mají, na rozdíl od mnoha jiných, zásadní dopad na správné zacházení s nimi, zejména pak při jejich hledání a vyhodnocování.

2.3. Použití metrik Aby bylo používání metrik smysluplné, musí být metriky vhodné pro požadovaný účel. Aby bylo jejich používání efektivní, je potřeba sbírat a vyhodnocovat pravidelně, nejlépe v rozumně dlouhých (či spíše krátkých) pevně stanovených intervalech. Za tímto účelem je vhodné vybudovat určitou infrastrukturu (nejlépe z části automatizovanou), která tyto činnosti usnadní.

2.3.1. Hledání metrik Jak již bylo zmíněno v úvodu této práce, účelem metrik je poskytovat zpětnou vazbu v podobě informací o postupu ke stanovenému cíli. Hledání konkrétních metrik tedy musí nutně vycházet z cíle samotného. Úkol nalezení vhodných metrik přitom není nijak snadný. Situaci dobře vystihuje Jonathan Alexander, který uvádí, že hledání metrik je „trochu věda, trochu umění a spousta pokusů a omylů“ [2, str. 30]. Hledání metrik přesto není žádná alchymie. Obecnou strukturu tohoto myšlenkového procesu popisuje metodika GQM (Goal – Question – Metric) [5], která poskytuje návod v podobě posloupnosti tří kroků: 1. stanovení konkrétního cíle 2. zformulování otázek týkajících se plnění stanoveného cíle 3. nalezení metrik, které se stanou zdrojem odpovědí na tyto otázky.

14

Konkrétní postup pro tyto kroky již metodika GQM neposkytuje. Zejména pro druhý a třetí krok to není ani dost dobře možné, protože postup se může výrazně lišit v závislosti na stanoveném cíli. Je však možné určit obecné vlastnosti, které tento cíl musí mít, aby šlo druhý a třetí krok vůbec provést. Cíl musí v zásadě splňovat tzv. SMART kritéria [9]. Musí tedy být přesně vymezený, měřitelný, dosažitelný, zdrojově naplánovatelný a termínovaný. Pro účely hledání metrik jsou klíčové především přesné vymezení a dosažitelnost, protože zdrojová naplánovatelnost a termínovanost se týkají spíše projektu, který má daného cíle dosáhnout, a měřitelnost lze v zásadě zajistit vždy (viz výše uvedený citát Galilea Galilei), byť v některých případech jen za cenu vysoké (neúměrné) složitosti. Účelem formulování otázek ve druhém kroku je ujasnit si, jaká cesta (popř. jaké cesty) ke stanovenému cíli vede (vedou). Díky tomu, že se otázky mají týkat přímo plnění tohoto cíle, by mělo být možné na jejich základě určit klíčové parametry tohoto plnění, které se ve třetím kroku stanou podkladem pro stanovování konkrétních metrik. Za určitých okolností (zejména u složitějších cílů) může být výsledkem formulování otázek zjištění, že je potřeba zabývat se ještě cíli dílčími. V takovém případě je nutné tento krok opakovat pro každý takový dílčí cíl. Výstupem třetího kroku by měly být metriky měřící klíčové parametry plnění cíle. Často zde dochází k situaci, že některý klíčový parametr lze měřit více způsoby a na odpovídající metriku tak existuje více různých kandidátů. Podobně jako pro cíle je možné i v tomto případě určit obecné vlastnosti dobrých metrik, které mohou s jejich výběrem pomoci.

2.3.2. Vlastnosti dobrých metrik Dobrá metrika musí zohledňovat oblast činnosti, pro kterou je určena. Někdy přitom může docházet k překvapivým zjištěním. Příkladem mohou být metriky produktivity v oblasti vývoje softwaru. Na první pohled se dobrou metrikou zdá být množství vyprodukovaného zdrojového kódu za jednotku času, tedy obdoba metriky běžně používané ve výrobních procesech (norma kusů na čas, popř. norma času na jeden kus). Je třeba si ale uvědomit dvě věci. Za prvé, cílem vývoje softwaru není vyprodukovat co největší množství zdrojového kódu. Zcela naopak, poznatky z oblasti softwarového inženýrství říkají, že cílem je co nejmenší množství zdrojového kódu, které splňuje požadavky na vyvíjený software, a to z důvodu minimalizace nákladů při jeho údržbě. Za druhé, zdrojový kód je zde až vyjádřením

15

výsledku procesu vývoje softwaru, nikoli procesu samotného. Podstatou procesu vývoje softwaru je nalezení řešení problému (algoritmu), a to řešení takového, které splňuje zadáním určené omezující podmínky. Určujícím faktorem produktivity vývoje softwaru jsou tedy znalosti a zkušenosti. Dobrá metrika produktivity proto musí být vztažena k množství znalostí a zkušeností a ke schopnosti nové znalosti a zkušenosti získávat [3, str. 27]. Cesta k vyšší produktivitě týmu tak vede jednak přes výběr členů (skladbu) týmu, jednak přes průběžnou podporu jejich dalšího vzdělávání, tedy paradoxně přes z pohledu některých vedoucích pracovníků nežádoucí „neproduktivní“ čas. Originální příklad špatně zvolené metriky je uveden v [11, str. 30]. Zde se uvádí, že inteligenci psa nelze určovat na základě výsledku dotazníkového IQ testu běžně používaného u lidí. Dobrá metrika musí sledovat požadovaný cíl (být v přímé či ještě lépe příčinné souvislosti s jeho plněním) a zároveň musí být odolná proti možné manipulaci s její hodnotou. Jako odstrašující příklad uvažujme následující situaci: Za účelem zvýšení nákladové efektivity vývoje softwaru se jako metrika produktivity práce vývojáře stanoví počet řádků vyprodukovaného kódu (obdoba situace v předchozím odstavci). Pro zajištění motivace vývojářů dosahovat vyšší produktivity práce se tato metrika zároveň použije jako podklad pro stanovování výše jejich odměn. Vývojáři se této situaci přizpůsobí tím nejjednodušším způsobem, tedy začnou hledat cesty, jak při řešení přiděleného úkolu produkovat co největší množství kódu (např. volbou štábní kultury produkující vyšší počet řádků kódu a nepoužíváním frameworků a knihoven). Tato opatření nevyhnutelně povedou k tomu, že kód bude nepřehledný a plný chyb, které navíc nebude snadné nalézt a opravit. V konečném důsledku bude každý zásah do kódu znamenat vyšší pracnost a tedy vyšší náklady a nákladová efektivita naopak (pravděpodobně velmi výrazně) klesne. Odolnost proti manipulaci se nejčastěji zajišťuje soustavou více metrik, které jsou navzájem provázány tak, že manipulace s hodnotou jedné z nich se projeví zhoršením hodnot ostatních. Příklad takové soustavy je uveden u metrik množství práce na str. 23.

2.3.3. Vyhodnocování metrik Účelem používání metrik je získávání takových informací, které mohou sloužit jako indikátor průběhu či stavu sledovaného procesu a mohou být podkladem pro strategické, taktické

16

a operativní změny v tomto procesu prováděné. Aby metriky mohly plnit svůj účel, je nutné je vyhodnocovat, tedy získávat požadované informace z jejich hodnot. Aby případná rozhodnutí učiněná na základě těchto informací mohla být správná, je dále potřeba, aby i tyto informace byly správné, tedy aby vyhodnocování metrik bylo správně provedeno. Metriky nelze vyhodnocovat „od stolu“ pohledem na jejich číselné hodnoty, vždy je potřeba chápat, co se za těmito hodnotami skrývá. Nezbytným základem správného vyhodnocení každé metriky je tak porozumění jejímu smyslu. Pokud se (na základě tohoto porozumění) hodnota metriky zdá neuspokojivá, je vždy potřeba pátrat po příčině tohoto stavu. Je ovšem nutné hledat skutečnou příčinu a nespokojit se s nejjednodušším vysvětlením, které se v danou chvíli nabízí. Přitom je potřeba mít na paměti, že těchto příčin může být více. Případné závěry je nutné činit na základě správných metrik. Pro některé závěry se hodí absolutní metriky, pro některé naopak metriky relativní. Například na základě samotné informace, že za uplynulý měsíc bylo pro určitý produkt obdrženo sto chybových hlášení (absolutní metrika), nelze odpovědně rozhodnout, jak kvalitní tento produkt je. Danou hodnotu je potřeba vyhodnocovat v kontextu jiné absolutní metriky, např. počtu uživatelů tohoto produktu. Situace se pak jeví zcela odlišně, pokud má produkt uživatelů deset nebo sto tisíc. Správnou metrikou pro daný závěr je tedy například počet chybových hlášení na jednoho uživatele (relativní metrika). Jak bylo uvedeno výše, možných příčin hodnoty metriky může být více, navíc se na výsledném stavu mohou podílet různou měrou. Příkladem může být metrika „system spoilage“ [1, str. 1-93]. Jedná se o podíl objemu práce strávené opravováním chyb na celkovém objemu práce (relativní metrika). Příčinou neuspokojivých hodnot této metriky může být špatná práce (nekompetentnost, nezkušenost, ležérní přístup) vývojářů. Příčinou ovšem může být i špatná organizace práce. Taková situace běžně vzniká v případech, kdy termíny odevzdání nebo ceny zakázek neodpovídají jejich pracnostem. Vývojáři jsou pak z důvodu dodržování termínů a rozpočtů nuceni k nedbalé práci s tím, že vzniklé chyby a nedodělky budou řešeny v rámci údržby (s novými termíny, popř. s novým rozpočtem), resp. k odpracování velkého množství přesčasů, které se negativně projeví na jejich pracovních výsledcích.

3

Nejedná se o rozsah, kniha používá číslování stran s pomlčkou.

17

Svět není černobílý. Proto ani objektivně prokázané skutečnosti nelze vždy kategoricky hodnotit jako pozitivní nebo negativní. Jako příklad takové situace může posloužit defekt. Pokud se vyloučí „nižší“ příčiny (lenost, lajdáctví apod.), je defekt identifikací znalosti nebo zkušenosti, která chyběla [3, str. 28]. Za předpokladu, že tým (člen týmu) dokáže danou znalost nebo zkušenost využít (poučit se) a stejnou chybu neopakovat, je defekt zároveň indikátorem procesu získávání znalostí nebo zkušeností [3, str. 28]. Přestože je tedy defekt obvykle vnímán negativně (v ideálním případě by k defektům nemělo docházet), je na něm za určitých okolností paradoxně i něco pozitivního. Stejná skutečnost se navíc může v průběhu času jevit různě. Jako příklad je možné uvažovat následující situaci: Dva vývojáři byli pověřeni implementací stejné funkčnosti. Prvnímu vývojáři splnění úkolu zabralo 10 hodin, druhému 12 hodin. Na základě těchto hodnot je možné dospět k závěru, že první vývojář byl produktivnější (z pohledu vedoucích pracovníků lepší) než druhý. Po určitém čase bylo potřeba tuto funkčnost rozšířit. Implementace tohoto rozšíření do kódu prvního vývojáře zabrala 7 hodin, zatímco do kódu druhého vývojáře zabrala 1 hodinu. Důvodem bylo to, že kód prvního vývojáře byl napsán nepřehledně a nestandardně (bylo těžší se v něm vyznat) a nebyl ani příliš promyšlený (část bylo nutné přepracovat), zatímco kód druhého vývojáře byl napsán čistě a používal vhodné návrhové a implementační vzory, které jeho úpravu usnadnily. Implementace funkčnosti včetně její rozšířené verze tedy v kódu prvního vývojáře zabrala 17 hodin, zatímco v kódu druhého vývojáře jen 13 hodin. Za těchto okolností se produktivita obou vývojářů zdá být opačná. Situace se navíc může dále vyvíjet, přičemž není jasné, kterým směrem. V takových případech je relevantní závěry možné učinit až za relativně dlouhou dobu. Není tedy vhodné na základě (některých) metrik sestavovat žebříčky (a pořádat soutěže), zejména pokud se pro daný účel používají okamžité hodnoty a nikoli jejich vývoje v čase (trendy). Hlavním použitím metrik by mělo být sledování (dlouhodobých) trendů a (krátkodobých) odchylek od nich. V těchto trendech a odchylkách je totiž možné rozpoznávat různé vzorce chování a na jejich základě usuzovat, co se uvnitř sledovaného procesu odehrává. Tímto způsobem je možné vypozorovat např. dispozice pracovníků (některé úkoly jim vyhovují více), jejich profesní rozvoj (stejné úkoly plní čím dál tím lépe, jsou schopni plnit stále složitější úkoly) nebo nalezení vhodně složeného týmu (v určitém složení dosahuje tým lepších výsledků).

18

Obrázek 1: Závislost výše nákladů C na míře kvality Q.. Celkové náklady Ct jsou dány součtem nákladů způsobených nekvalitou Cd a nákladů vynaložených vynaložených na dos dosažení ažení kvality Cq. V bodě, kde Cd=Cq, dosahují Ct globálního minima Co. Průběhy (křivky) veličin jsou idealizované. V některých případech je sledování trendů jediným nástrojem, jak zjistit požadované informace. Příkladem je Feigenbaumův model nákladů a kvality [16,, str. 419].. Podle tohoto modelu jsou náklady pro každou úroveň kvality dány součtem nákladů způsobených nekvalitou a nákladů vynaložených na dosažení kvality. kvality. Oboje náklady mají exponenciální charakter, přičemž náklady způsobené nekvalitou s rostoucí kvalitou exponenciálně klesají, zatímco náklady vynaložené na dosažení kvality se zvyšující se kvalitou exponenciálně rostou. V bodě, kde jsou si oboje náklady náklady rovny, má jejich součet (celkové náklady) globální minimum (viz Obrázek 1). ). Náklady vynaložené na dosažení kvality jsou, na rozdíl od nákladů způsobených nekvalitou, nekvalitou, řiditelné. Aby bylo možné určit, zda je pro dosažení globálního minima potřeba náklady vynaložené na dosažení kvality zvýšit či naopak snížit, je nejprve nutné vědět, v jakém bodě na pomyslné křivce celkových nákladů se nachází současný stav. V zásadě jediný jediný způsob, jak tohoto poznání dosáhnout, je sledovat trend odezvy celkových nákladů na změny nákladů vynaložených na dosažení kvality. Podle charakteru této odezvy (zda je s provedenou změnou shodná či je k ní opačná) pak lze stanovit, zda se nacházíme od globálního minima napravo či nalevo. Metriky mohou občas vykazovat trendy, které jsou v rozporu s obecně platnými (uznávanými) zákonitostmi. Nejčastějším důvodem takové situace bývá nějaký skrytý (dosud neodhalený)

19

vnitřní či vnější faktor. Příklad lze najít v oblasti psychologie práce. U většiny lidí se nadměrné pracovní zatížení (a z něho pramenící stres) projeví poklesem pracovní výkonnosti a zvýšeným počtem chyb. Existují ovšem lidé, kteří reagují opačně a nejlepších pracovních výsledků dosahují právě pod zvýšeným tlakem. Dalším, již méně častým, důvodem bývá chyba při práci s metrikami. Pokud jsou dodržovány zásady správného výběru a vyhodnocování metrik, bývá tato chyba nejčastěji ve fázi sběru dat. Příklady mohou být záměrná manipulace s hodnotami nebo defekt nástroje pro automatizovaný sběr dat. Zdaleka nejméně častým důvodem je pak možnost, že ona obecně platná (uznávaná) zákonitost, se kterou je trend porovnáván, zcela obecně platná není. Je třeba si uvědomit, že poznatky v oboru softwarového inženýrství jsou (podobně jako v případě ekonomie nebo sociologie) založeny na empirických pozorováních. Empiricky prokázané zákonitosti mají vždy nějaké předpoklady a jejich obecná platnost je dána obecnou platností těchto předpokladů. Je tedy možné (přinejmenším teoreticky) narazit na situaci, kdy některý z nich splněn není4. Na metriky se nelze slepě spoléhat. Metriky (stejně jako vše ostatní) mají svá omezení. Některé věci zachytit jednoduše nedokáží, to ale neznamená, že jsou špatné. Metriky jsou pomůckou pro odhalování problémů, nikoli nástrojem jejich řešení.

4

Obdobné situace se mohou koneckonců vyskytnout i v případě přírodních (exaktních) věd. Příkladem je třeba klasická mechanika, která také byla dlouho považována za obecně platnou.

20

3. Zákonitosti skladby vývojových týmů Vývoj softwaru je v dnešní době týmová záležitost. Důvodem je jednak rozsah a složitost softwarových řešení, jednak potřeba na cestě k cíli vykonávat různé činnosti. Není dost dobře možné, aby všechny potřebné znalosti a zkušenosti obsáhl jeden člověk. Pomineme-li sociální dovednosti (tzv. „soft skills“), je možné zbylé (odborné) znalosti a zkušenosti (tzv. „hard skills“) rozdělit do dvou oblastí. První oblastí jsou znalosti a zkušenosti technické. Týkají se zejména druhu vyvíjeného softwaru a popř. jeho části, požadované funkčnosti, dále pak cílové platformy, programovacích (popř. jiných) jazyků, frameworků a knihoven. Druhou oblastí jsou znalosti a zkušenosti procesní. Ty vycházejí především z jednotlivých fází životního cyklu vyvíjeného softwaru a blíže určují dispozice jednotlivce pro týmové role (např. analytik, kodér, tester). Některé role (a potažmo pak odpovídající procesní znalosti a zkušenosti) pak vyplývají ze samotných vývojových metodik (např. v případě metodiky Scrum jde o roli Scrum Master [21, str. 185]). Aby mohl vývojový tým efektivně fungovat, musí být vhodně složen. K tomu je zapotřebí brát v úvahu několik různých hledisek. Za prvé, znalosti a zkušenosti jeho jednotlivých členů se musí navzájem doplňovat tak, aby společnými silami pokryli znalosti a zkušenosti potřebné k úspěšnému dokončení projektu. Za druhé, potenciál všech členů týmu by měl být využit v maximální možné míře. Každý člověk má určitý talent, a pokud je tento talent objeven, je možné jej následně využít ve prospěch týmu jako celku. Za třetí, členové týmu měli mít určité charakterové vlastnosti, které jsou předpokladem úspěšného konce projektu. Jedná se zejména o nadšení pro práci, obětavost a oddanost společnému cíli [23]. Každý softwarový projekt vyžaduje technické vedení. Je potřeba držet o projektu celkový (ucelený) obrázek a mít jasnou dlouhodobou vizi a na základě těchto informací rozhodovat o použitých technologiích a postupech a určovat směr dalšího postupu k vytyčenému cíli. Tradičně má tento úkol na starosti role architekta. Ten musí pro plnění tohoto úkolu disponovat dostatečným rozhledem a zkušenostmi v oboru. Zároveň ale musí mít aktuální praktické zkušenosti se zvolenými technologiemi a postupy a být kdykoli schopen týmu aktivně pomoci při vývoji. Z tohoto důvodu se na tuto pozici nehodí architekti a techničtí vedoucí pracovníci z velkých společností [17].

21

Kromě architekta se v týmu musí vyskytovat i další procesní role. Jsou jimi zejména analytik, kodér a tester, v závislosti na druhu vyvíjeného produktu pak dalšími rolemi mohou být např. grafik nebo návrhář uživatelského rozhraní (tato role bývá často součástí týmů vyvíjejících mobilní aplikace [6]). Jednotlivé role často nemají jasně vymezené hranice, naopak je možné nalézt mezi některými rolemi značné překryvy (analytik a architekt, kodér a tester). V praxi je tedy zcela obvyklé, že každý člen týmu zastává souběžně více rolí. Pro startupy to, s ohledem na minimalizaci nákladů, platí o to více. Složit kvalitní vývojový tým není jednoduchý úkol. Požadavků na jednotlivé členy je poměrně mnoho, ve skutečnosti je tedy skladba týmu vždy určitým kompromisem. Tým je potřeba skládat nejen s ohledem na aktuální potřeby, ale i s výhledem do budoucnosti. Je tedy nutné hledat takové jedince, kteří mají zájem na sobě dále pracovat a neustále se zlepšovat. Zároveň není možné s požadavky klesnout pod určitou hranici, protože právě kvalita týmu může znamenat rozdíl mezi úspěchem a neúspěchem celého startupu. Proto je na místě si s hledáním těch „správných“ členů týmu dát práci a snažit se sestavit silný, dynamický a synergický tým. Z toho důvodu může nastat i situace, kdy bude potřeba se některého stávajícího člena týmu zbavit (tato potřeba přitom nemusí nutně znamenat, že se jedná o špatného pracovníka). Je tedy třeba se nebát takový krok učinit bez ohledu na případné osobní vazby [17].

22

4. Metriky vývojových týmů Metriky

uvedené

v této

kapitole

v zásadě

vycházejí

z metrik

popsaných

v knize

Codermetrics [2]. Zde uvedené metriky jsou ale přizpůsobené (přeuspořádané, vhodně pojmenované, doplněné) zaměření této práce.

4.1. Metriky množství odvedené práce Množství odvedené práce je základním ukazatelem fungování celého týmu i jeho jednotlivých členů. Na množství odvedené práce se totiž projeví každá neefektivita, od nekompetentnosti a neodbornosti přes špatnou organizaci práce až po nízké pracovní nasazení. Tento ukazatel ale nijak nepostihuje kvalitu odvedené práce ani její přínos k dosaženému výsledku. Jedná se tedy o indikátor případných problémů, na jehož základě lze začít pátrat po jejich příčinách.

4.1.1. Objem dokončené práce (ODP) Sledování objemu dokončené práce je v zásadě podobné úkolu plánování objemu práce, které je u agilního vývoje prováděno na počátku každé iterace. Při něm je každý úkol, podle své složitosti, ohodnocen číslem z předem definované stupnice. Toto ohodnocení je možné použít pro výpočet této metriky, kterou lze definovat jako součet ohodnocení su všech dokončených úkolů u: ODP
  

Důležitým předpokladem je, aby ohodnocování úkolů bylo konzistentní, a to jak v rámci jedné iterace, tak napříč různými iteracemi. Z tohoto důvodu je ohodnocování v agilních metodikách dílem celého týmu (viz např. „planning poker“ [7, str. 56]). Konzistentní musí pochopitelně být i použitá stupnice. Výběr vhodné číselné řady blíže popisují např. [8, str. 113] a [7, str. 52 – 53]. Opravy defektů se do objemu dokončené práce nezapočítávají. Důvodem je, aby záměrným vytvářením defektů nedocházelo k umělému navyšování objemu dokončené práce. Agilní metodiky obecně vycházejí z předpokladu, že defekty opravuje ten, kdo je způsobil. V takovém případě se jedná o odstranění nedodělku úkolu, za jehož splnění byl již dotyčný

23

vývojář metrikou (kladně) ohodnocen a další (kladné) ohodnocení tedy nepřichází v úvahu. Naopak, práce na odstraňování defektu se negativně projeví na objemu ostatní dokončené práce, což je v zásadě požadovaný jev. Pokud přesto opravu defektu provedl někdo jiný (např. z důvodu, že se nejednalo o přímé zavinění nebo viník již není součástí týmu), postihuje tuto situaci samostatná metrika (viz oddíl 4.1.7). Podílí-li se na řešení úkolu více vývojářů, je nutné kvůli spravedlivému rozdělení objemu dokončené práce zohlednit konkrétní situaci. Pokud první (původní) vývojář úkol rozpracuje a nedokončí a jeho dokončení provede druhý (jiný) vývojář, rozdělí se objem dokončené práce tak, že prvnímu vývojáři se započítá taková část, kterou bylo možné při dokončení úkolu využít, a zbytek připadne druhému vývojáři. Nedokončené úkoly přitom postihuje ještě samostatná (negativní) metrika (viz oddíl 4.2.2). Specifickým případem spolupráce více vývojářů je párové programování. Zde je nutné rozlišovat, za jakým účelem k němu bylo přistoupeno. Pokud je párové programování používáno rutinně nebo je použito pro řešení úkolu s vysokou složitostí, rozdělí se objem dokončené práce mezi oba vývojáře rovnoměrně. Pokud je jeho účelem zaškolování nového člena týmu, přidělí se celý objem dokončené práce školiteli. Před vyhodnocováním objemu dokončené práce je potřeba jeho hodnotu normalizovat. Důvodem jsou jednak odchylky v délce iterací (mohou vzniknout např. předčasným ukončením iterace), jednak různé pracovní úvazky jednotlivých vývojářů. Samotné vyhodnocení je pak potřeba dělat vždy v kontextu dalších metrik a okolností. Nízká hodnota této metriky totiž může znamenat třeba také to, že vývojář neměl pro dokončení většího objemu práce dostatečný prostor (např. z důvodu pracovních cest).

4.1.2. Počet dokončených úkolů (PDU) První doplňkovou metrikou k množství odvedené práce je počet dokončených úkolů, který lze matematicky definovat jako součet fiktivních ohodnocení 1 všech dokončených úkolů u: PDU
 1 

Ohodnocení se započítá jen tomu vývojáři, který příslušný úkol skutečně dokončil. Výjimkou je situace, kdy je úkol řešen pomocí párového programování, které je použito buď rutinně

24

nebo kvůli vysoké složitosti úkolu. V takovém případě se ohodnocení započítá oběma zúčastněným vývojářům. Podobně jako u objemu dokončené práce je potřeba i zde hodnotu metriky před vyhodnocováním normalizovat a vyhodnocení dělat vždy v kontextu dalších metrik a okolností.

4.1.3. Průměrná složitost dokončeného úkolu (SDU) Druhou doplňkovou metrikou k množství odvedené práce je průměrná složitost dokončeného úkolu. Jedná se o relativní metriku, která je definována jako aritmetický průměr ohodnocení su všech dokončených úkolů u. Hodnota této metriky je tedy zároveň rovna podílu objemu dokončené práce a počtu dokončených úkolů: SDU


∑  ODP
∑ 1 PDU

Na rozdíl od předchozích metrik není (díky podílu) potřeba hodnotu metriky před vyhodnocováním normalizovat, a to ani v případě použití nenormalizovaných hodnot (první zlomek). Vyšší hodnota vždy znamená, že vývojář plnil z větší míry složitější úkoly.

4.1.4. Soustava metrik ODP + PDU + SDU Objem dokončené práce, počet dokončených úkolů a průměrná složitost dokončeného úkolu společně tvoří soustavu metrik, která je poměrně odolná vůči manipulacím s hodnotami každé jednotlivé metriky. Případné manipulace s hodnotou lze primárně očekávat u objemu dokončené práce. Umělé (zdánlivé) navyšování objemu však lze docílit pouze nadhodnocováním složitosti jednotlivých úkolů. Vzhledem k tomu, že ohodnocování úkolů je dílem celého týmu (opět viz „planning poker“ [7, str. 56]), musel by nutně „podvádět“ celý tým. Tato situace je poměrně nepravděpodobná, navíc by se projevila tím, že by mezi úkoly nebyly téměř žádné s nejnižším ohodnocením. To příliš neodpovídá normálnímu stavu, kdy jednoduché úkoly by se měly vyskytovat ve větší míře než úkoly složité. Druhým možným vysvětlením takové situace je nedostatečný rozpad práce na jednotlivé úkoly. To však lze poměrně snadno ověřit (např. podle struktury očekávaného výsledku každého úkolu).

25

Manipulace s počtem dokončených úkolů spočívá v plnění jen nejjednodušších úkolů. Výsledek se ovšem projeví nízkou hodnotou průměrné složitosti dokončeného úkolu. Naopak podstatou manipulace s průměrnou složitostí dokončeného úkolu je plnění jen nejtěžších úkolů. To se projeví na nízkém počtu dokončených úkolů. Hodnoty počtu a průměrné složitosti dokončených úkolů by měly odrážet roli (zkušenost) každého člena týmu. Začínající vývojář bude mít pravděpodobně vyšší počet dokončených úkolů s nižší průměrnou složitostí. Oproti tomu zkušený vývojář bude plnit převážně složitější úkoly a jejich počet tak bude nižší.

4.1.5. Trend objemu dokončené práce (TODP) Kromě absolutní hodnoty objemu dokončené práce je důležité sledovat i její trend, z něhož jsou patrné případné výkyvy výkonnosti vývojáře. Hodnotu tohoto trendu lze získat jako poměr objemů dokončené práce v současné (i) a předchozí (i – 1) iteraci vynásobený hodnotou trendu v předchozí iteraci: TODP


ODP ∙ TODP ODP

Protože uvedený vzorec je rekurentní, je možné hodnotu metriky sledovat až od druhé iterace. Kromě toho je potřeba zvolit ještě počáteční hodnotu trendu: TODP
100 Hodnota 100 má tu výhodu, že aktuální hodnota trendu má v takovém případě význam procentuálního zlepšení (zhoršení) oproti počátečnímu objemu odvedené práce ODP0. Použít ale lze i libovolnou jinou hodnotu. Vyšší hodnota trendu objemu dokončené práce je dána větší mírou zlepšení proti předchozím iteracím, nikoli větším množstvím dokončené práce. Metrika proto neslouží ke vzájemnému porovnávání členů týmu, ale ke sledování vývoje konkrétního jednotlivce (popř. týmu jako celku) v čase. Zároveň je potřeba mít na paměti, že zlepšovat se nelze do nekonečna, protože výkonnostní kapacita každého jednotlivce je shora omezena. Situace je tak analogická s případem zvyšování hrubého domácího produktu nerostoucí populace v ekonomii. Na hodnotě trendu se rovněž projeví jakékoli výkyvy objemu dokončené práce (viz oddíl 4.1.1).

26

4.1.6. Počet účastí na řešení nepřidělených úkolů (UNU) Vývojáři potřebují v rámci své každodenní práce činit desítky různých rozhodnutí (zejména návrhových a implementačních), která přímo či nepřímo ovlivňují kvalitu výsledku. V závislosti na složitosti dané situace mohou mít potřebu některá rozhodnutí konzultovat se zkušenějšími kolegy. To je na jednu stranu žádoucí stav, nevyhnutelně ale vede k tomu, že dotazovaný do určité míry spolupracuje na plnění jemu nepřiděleného úkolu. Za tuto spolupráci není nijak kladně hodnocen, naopak může vést (a často také vede) ke snížení objemu jím dokončené práce. Je tedy vhodné zavést metriku, která by pomáhala tyto „rušivé vlivy“ sledovat. Takovou metrikou může být počet účastí na řešení nepřidělených úkolů, který lze matematicky definovat jako součet fiktivních hodnot 1 všech poskytnutých konzultací k: UNU
 1

Do poskytnutých konzultací je nutné počítat jen takové, které mají požadovaný efekt, tedy jsou skutečnou pomocí při řešení problému. Nemusí to tedy být jen přímá odpověď, ale může jít např. o vyhledání informací v dostupné literatuře. Oproti tomu odpověď „nevím“ pomocí zcela jistě není. Je tedy vhodné, aby poskytnutou konzultaci hlásil jak dotazovaný, tak dotazující. Případné manipulace s hodnotou metriky spočívající v (oboustranném) hlášení fiktivních konzultací lze vyřešit sledováním počtu vyžádaných konzultací. Zavedení takové podpůrné metriky by ale v žádném případě nemělo mít za následek potlačení motivace vývojářů konzultovat svá rozhodnutí, metrika by tedy neměla mít automaticky negativní dopad na hodnocení dotazujících. Podobně jako v případě počtu a průměrné složitosti dokončených úkolů by i hodnoty této metriky měly odrážet roli (zkušenost) každého člena týmu. Vysoká hodnota poukazuje na nerovnováhu znalostí a zkušeností v týmu, zatímco za nízkou hodnotou se může (především u zkušeného vývojáře) skrývat nekomunikativnost nebo neochota spolupracovat.

27

4.1.7. Počet odstraněných defektů (POD) Počet odstraněných defektů je metrika postihující situace, kdy některý vývojář opravuje defekt, který nezavinil. Hodnotu lze matematicky definovat jako součet fiktivních hodnot 1 všech odstraněných defektů d: UOD
 1

Ohodnocení se započítá všem vývojářům, kteří se aktivně (nikoli např. jen konzultací, kterou postihuje počet účastí na řešení nepřidělených úkolů) podíleli na opravě příslušného defektu.

4.2. Metriky kvality odvedené práce 4.2.1. Dopad vyprodukovaných defektů (DVD) Dopad vyprodukovaných defektů je negativní metrika ekvivalentní k objemu odvedené práce. Hodnotou je součet součinů závažností zd a relativního rozšíření rd všech vyprodukovaných defektů d: DVD
  ∙ 

Závažnost defektu je obdoba složitosti úkolu, ohodnocování defektů tedy musí být konzistentní (viz oddíl 4.1.1). Z pohledu používání dopadu vyprodukovaných defektů pro výpočet dalších metrik je vhodné, aby číselná řada použitá pro stupnici závažnosti byla ekvivalentní s číselnou řadou použitou pro ohodnocování složitosti úkolů. Relativní rozšíření je pak procentuální vyjádření přibližného počtu uživatelů zasažených daným defektem. Tuto hodnotu je možné odhadnout na základě chybových hlášení a její přesnost by (z důvodu praktičnosti) neměla přesáhnout zhruba 10 %. Problémem dopadu vyprodukovaných defektů je, že defekty jsou často objeveny s poměrně značným zpožděním. Sledování této metriky po jednotlivých iteracích je tedy nepraktické a může být velmi zavádějící. Pro nezkreslené informace by bylo nutné hodnotu započítávat do iterace, ve které byl defekt vytvořen. Takový postup by znamenal neustálé přehodnocování již ukončených iterací, což by bylo administrativně velmi náročné. V tomto případě je vhodnější

28

sledování hodnoty (kumulativní, průměrné) za delší časové období (například čtvrtletí) a jejího trendu. Volba delšího časového období zároveň řeší případnou potřebu hodnotu normalizovat. Hodnota dopadu vyprodukovaných defektů by v zásadě měla odrážet roli (zkušenost) každého člena týmu. Příčin defektů ale může být mnoho. Mohou být způsobeny jak samotným vývojářem (např. zkušenost s řešením podobných úkolů a s použitými technologiemi a postupy, schopnost abstraktního myšlení a soustředění se, pečlivost), tak pracovními podmínkami (např. organizace práce, požadavky a pokyny odporující požadovanému výsledku, klid na pracovišti). Tyto skutečnosti je potřeba při vyhodnocování metriky brát v úvahu.

4.2.2. Počet nedokončených úkolů (PNU) Počet nedokončených úkolů postihuje situace, kdy některý vývojář úkol rozpracuje a nedokončí. Hodnotu lze matematicky definovat jako součet fiktivních ohodnocení 1 všech nedokončených úkolů u: PNU
 1 

Ohodnocení je vývojáři započítáno jen tehdy, pokud jsou důvodem nedokončení úkolu jeho nedostatečné schopnosti úkol vyřešit (samostatně či za pomoci konzultací s kolegy). Takovým důvodem ale není přerozdělení práce z organizačních důvodů (např. nahrazení chybějícího člena týmu). Při vyhodnocování je i zde potřeba nezapomenout na normalizaci hodnoty metriky a zohlednění kontextu dalších metrik a okolností.

4.2.3. Pokrytí řešených oblastí (PRO) Vyvíjený produkt je typicky souborem menších logických částí, přičemž každá taková část poskytuje určitou funkčnost. Příkladem hrubého členění počítačové aplikace mohou být databáze (uchovávání dat), výpočetní logika (zpracování dat) a uživatelské rozhraní (zobrazování dat). Pokrytí řešených oblastí udává, na kterých částech který vývojář pracoval.

29

Matematicky lze hodnotu definovat jako matici fiktivních ohodnocení {0,1} oblastí o a vývojářů v: PRO,


1, 0,

pokud vývojář v pracoval na oblasti o v opačném případě

Seznam oblastí produktu v podstatě vychází z vysokoúrovňového návrhu (architektury) produktu, jeho sestavením by tedy měl být pověřen člověk (tým), který je za architekturu produktu zodpovědný. Nalezené oblasti je možné (a vhodné) rovněž používat pro následnou kategorizaci defektů. Podobně jako dopad vyprodukovaných defektů by i pokrytí řešených oblastí mělo být sledováno po delší (ale shora omezené) časové období. Důvodem je, že vývojář, který na dané části pracoval, si poznatky nabyté při této práci pamatuje delší dobu. Pokud ale s danou oblastí nepřichází delší dobu do styku, začíná tyto poznatky naopak zapomínat (viz např. Ebbinghausův model zapomínání [10]). Celkovou hodnotu je tedy vhodné počítat za několik posledních měsíců (rozumně dlouhým obdobím může být např. půlrok), a to z dílčích hodnot získaných během jednotlivých iterací i: 0, PRO,
 1,

pokud  PRO,
0 

v opačném případě



Ze stejného důvodu je vhodné po provedení zásadních změn v určité oblasti (např. její přepracování nebo změna použité technologie) vynulovat (zpětně za celé sledované období) hodnotu u všech vývojářů, kteří se na takové změně nepodíleli. Z výsledné matice lze získat dvě důležité informace. Za prvé, zda a jak dobře jsou jednotlivé oblasti pokryty stávajícími členy týmu. Tímto způsobem je možné snadno identifikovat, kde může případným výpadkem (odchodem, nemocí) nastat problém nebo kde k takovému problému již došlo. Na základě této informace pak lze přistoupit k opatřením vedoucím ke zlepšení zastupitelnosti mezi členy týmu v dané oblasti. Za druhé, jak pokrytí oblastí konkrétním vývojářem odpovídá jeho roli v týmu. U začátečníka lze očekávat, že se bude zabývat převážně jednou oblastí, naopak zkušenější vývojáři by měli být schopni pracovat na podstatně širším spektru oblastí. Zároveň je důležité, aby vývojář, který plní roli architekta, měl přehled o produktu jako celku, tedy všech jeho částech.

30

4.3. Metriky dosaženého výsledku Metriky dosaženého výsledku odrážejí úspěšnost vyvíjeného produktu u uživatelů, tedy jakousi „tržní hodnotu“ práce odvedené týmem. Úspěšnost vyvíjeného produktu je přitom dána zejména jeho aktivacemi (a deaktivacemi). Aktivací (a deaktivací) mohou být myšleny různé události, v závislosti na typu produktu. Např. u desktopové aplikace se může jednat o instalaci (a odinstalaci), u cloudové služby pak o založení (a zrušení či opuštění) uživatelského účtu.

4.3.1. Počet aktivací (AKT) Metrika vyjadřuje počet nově získaných aktivací produktu. Hodnotu lze matematicky definovat jako součet fiktivních hodnot 1 všech aktivací a: AKT
 1 

Sběr dat pro tuto metriku je vhodné řešit automatizovaně, například pomocí odpovídající funkce v samotném produktu (obdoba služby Google Analytics [12]). Počet aktivací se nijak nevztahuje k vývojovým iteracím, je tedy vhodné metriku vyhodnocovat za kalendářní období (týden, měsíc, rok). Vzhledem k tomu, že v rámci obchodní strategie jsou obvykle stanovovány určité cíle (např. výhled prodeje), lze sledovat nejen absolutní hodnotu počtu aktivací, ale i relativní hodnotu vztaženou k těmto cílům.

4.3.2. Střední doba mezi aktivacemi (SAKT) Alternativou k počtu aktivací za určité období je střední doba mezi aktivacemi. Její hodnotu lze získat jako podíl délky sledovaného období do a počtu aktivací v tomto období: SAKT


 AKT

Tato metrika nemá sama o sobě nijak velkou vypovídací hodnotu (jedná se jen o jiný pohled na stejná data), ale je snáze porovnatelná (např. s historií, cíli, konkurencí), protože nevyžaduje normalizaci s ohledem na případné různé délky sledovaných období.

31

4.3.3. Počet deaktivací (DEA) Počet deaktivací vyjadřuje úbytek aktivací produktu, je tedy opačnou metrikou k počtu aktivací. Hodnotu lze tedy matematicky definovat jako součet fiktivních hodnot 1 všech deaktivací d: DEA
 1

Pro práci s touto metrikou platí stejná pravidla jako pro počet aktivací (viz oddíl 4.3.1).

4.3.4. Střední doba mezi deaktivacemi (SDEA) Střední doba mezi deaktivacemi je alternativou k počtu deaktivací za určité období. Její hodnotu lze získat jako podíl délky sledovaného období do a počtu deaktivací v tomto období: SDEA


 DEA

Pro práci s touto metrikou platí stejná pravidla jako pro střední dobu mezi aktivacemi (viz oddíl 4.3.2).

4.3.5. Úspěšnost aktivací (UAKT) Pokud je vyvíjený produkt nabízen formou zkušebních verzí (zkušebních účtů v případě cloudových služeb), je možné sledovat, do jaké míry se uživatelé zkušební verze stanou stálými uživateli produktu. Tuto hodnotu, nazývanou úspěšnost aktivací, lze matematicky definovat jako podíl počtu aktivací a součtu fiktivních hodnot 1 všech zkušebních verzí z: UAKT


AKT ∑ 1

Pro názornost je možné hodnotu vynásobit stem a získat tak hodnotu v procentech. Nízká hodnota znamená, že uživatelé jeví o produkt zájem, ale po jeho vyzkoušení tento zájem ztrácejí. Důvodem může být nekvalitní produkt s kvalitní marketingovou kampaní nebo naopak špatně zaměřená propagace kvalitního produktu (oslovuje převážně nevhodnou

32

skupinu uživatelů, podává zkreslené informace o produktu). Jiným důvodem může být, že funkce zařazené do zkušební verze uživatele dostatečně nezaujmou.

4.3.6. Růst aktivací (RAKT) Pro aktivace a deaktivace je možné definovat souhrnnou metriku vyjadřující růst (popř. pokles) počtu aktivací. Její hodnotu je možné definovat jako rozdíl počtu aktivací ponížený o počet nezískaných aktivací (počet aktivací odečtený od součtu fiktivních hodnot 1 všech zkušebních verzí z) a o počet deaktivací: RAKT
AKT   1  AKT  DEA 

Pokud produkt není nabízen formou zkušebních verzí, zjednodušuje se výpočet na: RAKT
AKT  DEA Pro práci s touto metrikou platí stejná pravidla jako pro metriky počtu aktivací a deaktivací (viz oddíly 4.3.1, resp. 4.3.3). Rozdílem oproti těmto metrikám ale je, že růst aktivací může nabývat i záporných hodnot. Kladné hodnoty v tomto případě znamenají nárůst počtu aktivací, záporné hodnoty pak naopak pokles počtu aktivací.

4.3.7. Střední doba růstu aktivací (SRAKT) Střední doba růstu aktivací je obdobou středních dob mezi aktivacemi a deaktivacemi pro růst aktivací. Její hodnotu lze získat jako podíl délky sledovaného období do a růstu aktivací v tomto období: SRAKT


 RAKT

Pro práci s touto metrikou platí stejná pravidla jako pro střední doby mezi aktivacemi a deaktivacemi (viz oddíly 4.3.2, resp. 4.3.4). Podobně jako v případě růstu aktivací i zde může metrika nabývat záporných hodnot značících pokles počtu aktivací.

33

4.3.8. Trendy metrik dosaženého výsledku Metriky dosaženého výsledku jsou důležité i z obchodního pohledu. Díky nim je totiž možné vysledovat určité sezónní trendy. Příkladem mohou být Vánoce (chytré mobilní telefony a tablety patří v poslední době mezi časté vánoční dárky a bezprostředně po Vánocích tak zpravidla dochází k nárůstu prodejů mobilních aplikací) nebo období před letními dovolenými (v souvislosti s rodinnými cestami k moři dochází k nárůstu prodejů elektronických navigací). Tyto trendy, pokud se podaří je vysledovat a případně vysvětlit, se dají použít při další podpoře prodeje.

4.4. Metriky příspěvku k dosaženému výsledku Množství a kvalita odvedené práce hodnotí práci jednotlivců (popř. týmu jako celku), nijak ale neodráží dosažený výsledek. Tento výsledek je přitom na odvedené práci přímo závislý, propojení obou oblastí je tedy potřebné. Takové propojení poskytují metriky příspěvku k dosaženému výsledku. Na jejich základě je následně možné sledovat přínos jednotlivců k výsledku celého týmu. Dosažený výsledek odráží i jiné faktory než je práce odvedená vývojovým týmem. Jedná se zejména o kvalitu počáteční myšlenky (obchodního záměru) a následné marketingové kampaně. Tyto faktory jsou metrikami příspěvku k dosaženému výsledku do značné míry zanedbány. Takové zjednodušení ale u startupů nepředstavuje zásadní problém, protože životaschopnou myšlenku je vždy možné dotáhnout do úspěšného konce (pokud by myšlenka životaschopná nebyla, povede k brzkému neúspěchu celého startupu) a marketing v dnešní době značně usnadňují sociální sítě (tzv. „virální marketing“ [20]).

4.4.1. Přínos odvedené práce (POP) Přínos odvedené práce hodnotí množství práce, které projekt skutečně posunulo vpřed. Ve své podstatě jde o množství kvalitně odvedené práce. Hodnotu lze definovat jako rozdíl objemu dokončené práce a dopadu vyprodukovaných defektů: POP
ODP  DVD

34

S ohledem na skutečnost, že defekty bývají objeveny se zpožděním (viz 4.2.1), je vhodné namísto okamžité hodnoty dopadu vyprodukovaných defektů použít průměr (či jinou statistickou míru polohy) za delší časové období (např. 6 iterací). Důvodem je zajištění určité setrvačnosti hodnoty dopadu vyprodukovaných defektů a tím omezení okamžitých výkyvů přínosu odvedené práce způsobených nalezením každého jednotlivého defektu. Před uplynutím zvoleného časového období je pak možné jako hodnotu dopadu vyprodukovaných defektů použít buď hodnotu 0 nebo hodnotu vypočtenou za již uplynulou část zvoleného období.

4.4.2. Pracovní záběr (ZAB) Pracovní záběr je metrikou znázorňující užitečnost vývojáře v rámci týmu. Jedná se o dvourozměrnou veličinu (hloubka × šířka). Hloubka pracovního záběru je dána počtem vývojářových aktivit (řešení úkolů, poskytování konzultací, odstraňování defektů) a šířka pracovního záběru počtem jím pokrytých oblastí produktu. Hodnotu pracovního záběru vývojáře v lze tedy vypočítat jako součet počtu jím dokončených úkolů, počtu jeho účastí na nepřidělených úkolech a počtu jím odstraněných defektů vynásobený relativní hodnotou (vztaženou k celku) počtu jím pokrytých oblastí o: ZAB
PDU  UNU  POD  ∙

∑ PRO, ∑ 1

Podobně jako v případě přínosu odvedené práce i tato metrika počítá s hodnotou vypočítávanou za delší časové období. Zde je touto hodnotou pokrytí řešených oblastí. Před uplynutím zvoleného časového období je ovšem, vzhledem k součinu, potřeba používat hodnotu vypočtenou za již uplynulou část zvoleného období.

4.4.3. Chybovost (CHYB) Chybovost je relativní metrika odrážející přesnost práce při plnění úkolů. Matematicky lze chybovost definovat jako podíl dopadu vyprodukovaných defektů a součtu dopadu vyprodukovaných defektů s objemem dokončené práce: CHYB


DVD ODP  DVD

35

Výsledkem výše uvedeného výpočtu je reálné číslo z intervalu 〈0,1〉. Taková hodnota se hodí

při výpočtu hodnot jiných metrik, pro vyhodnocování a porovnávání je ale vhodné tuto hodnotu převést na procenta.

4.4.4. Relativní metriky k metrikám POP, ZAB a CHYB Přínos odvedené práce, pracovní záběr a chybovost mají dvojí účel. Jednak slouží jako pomocné metriky pro výpočet dalších metrik příspěvku k dosaženému výsledku, jednak se dají převést na odpovídající relativní metriky a přímo tak použít pro vyjádření přínosu jednotlivce k výsledku dosaženému týmem. Převod metriky M na odpovídající relativní metriku m lze matematicky vyjádřit jako podíl hodnoty metriky M a součtu hodnot metriky M všech vývojářů v: #


$ ∑ $

I zde je pro vyhodnocování a porovnávání vhodné takto vypočtenou hodnotu převést na procenta. Metriky přínosu odvedené práce, pracovního záběru a chybovosti se dají dále použít pro srovnání jednotlivce s průměrem (nebo jinou statistickou míru polohy) celého týmu. Za tímto účelem je možné definovat relativní metriku m na základě hodnoty metriky jednotlivce M a průměru celého týmu M: #


$$ $

Po vynásobení vypočtené hodnoty stem je následně z výsledku zřejmé, o kolik procent je v dané (absolutní) metrice sledovaný vývojář nad (v případě kladné hodnoty) nebo pod (v případě záporné hodnoty) celotýmovým průměrem.

4.4.5. Přínos k aktivacím (PAKT) Přínos k aktivacím, na rozdíl od předchozích metrik příspěvku k dosaženému výsledku, vztahuje metriky objemu a kvality práce přímo k dosaženému výsledku. Hodnota vyjadřuje přínos účelně vynaloženého úsilí k počtu nově získaných aktivací a lze ji matematicky

36

Obrázek 2: Závislost doplňku chybovosti (1 - CHYB) na rostoucím dopadu vyprodukovaných chyb DVD při stejném objemu dokončené práce ODP = 1 vyjádřit jako součin počtu aktivací, relativní hodnoty přínosu odvedené práce (vztažené k celkové hodnotě přínosu odvedené práce za celý tým) a doplňku chybovosti do hodnoty 1: PAKT
AKT ∙ ∑

POP

% POP

∙ 1  CHYB

Výsledná hodnota není (ač by se tak mohlo na první pohled zdát) podílem jednotlivých vývojářů na celkovém počtu aktivací. Díky kombinaci přínosu odvedené práce a chybovosti, tedy dvou metrik, které obě odrážejí kvalitu práce, a zejména pak nelinearitě chybovosti je průběh přínosu k aktivacím nelineární a znevýhodňuje nekvalitně odvedenou práci. Toto znevýhodnění a jeho nelinearita je znázorněno na modelové situaci, viz Obrázek 2. Při vyhodnocování této metriky není důležitá absolutní hodnota (nemá žádný zvláštní význam), ale porovnání absolutních hodnot mezi jednotlivými členy týmu.

4.4.6. Přínos k deaktivacím (PDEA) Přínos k deaktivacím je obdobou přínosu k aktivacím. Hodnota vyjadřuje „přínos“ úsilí vynaloženého (byť neúmyslně) na vytváření chyb k úbytku počtu aktivací a lze ji matematicky vyjádřit jako součin počtu deaktivací a chybovosti: PDEA
DEA ∙ CHYB

37

Obrázek 3: Závislost chybovosti CHYB na rostoucím dopadu vyprodukovaných chyb DVD při stejném objemu dokončené práce ODP = 1. Výsledná hodnota opět není podílem jednotlivých vývojářů na úbytku celkového počtu aktivací. Díky nelinearitě chybovosti je i průběh přínosu k deaktivacím nelineární a znevýhodňuje nekvalitně odvedenou práci. Znevýhodnění a jeho nelinearitu znázorňuje modelová situace, viz Obrázek 3. Podobně jako v případě přínosu k aktivacím není ani u přínosu k deaktivacím důležitá absolutní hodnota, ale porovnání absolutních hodnot mezi jednotlivými členy týmu.

38

5. Práce s metrikami vývojových týmů Metriky jsou nástrojem projektového řízení, který přináší řadu výhod v podobě objektivních podkladů pro manažerská rozhodování. Tyto výhody přináší ale jen tehdy, pokud jsou používány v souladu se zásadami popsanými v oddílu 2.3. Následující oddíly na tyto zásady navazují a doplňují je o metodické pokyny pro jednotlivé oblasti práce s metrikami.

5.1. Zavedení metrik do praxe Metriky nelze používat způsobem, kdy je sběr a vyhodnocování dat prováděno jen tehdy, pokud je čas a „nálada“. Používání metrik musí být dlouhodobé a systematické. Předtím je ovšem potřeba udělat první krok a s používáním metrik začít, tedy zavést je do běžné praxe. Toto zavedení by mělo být provedeno formou projektu. Především proto, že by mělo být časově ohraničené a mít vyhrazené zdroje. V opačném případě lze téměř s jistotou tvrdit, že k systematickému používání metrik nikdy nedojde. Na počátku používání metrik se jejich hodnoty po určité časové období jen sledují. Cílem této fáze je zjistit informace o fungování sledovaného procesu, zejména pak o jeho efektivitě a její stabilitě v čase. Toto období by mělo trvat do doby, než je sledovaný proces dostatečně zmapován, tedy do okamžiku, kdy je možné si o něm udělat ucelený obrázek. S ohledem na potřebu zjištění stability efektivity tohoto procesu by toto období nemělo být kratší než 6 iterací. Získané poznatky lze používat ihned pro provádění operativních změn v procesu a dále v následující fázi ke stanovování konkrétních cílů vedoucích k optimalizaci procesu. Zavedení metrik má obvykle pozitivní dopad hned od samého počátku. Důvodem je psychologický efekt. Lidé totiž svou pozornost zaměřují více na to, co se měří a sleduje. Zavedení metrik sledujících nějaký cíl (např. kvalitu produktu nebo služby) tak může mít samo o sobě určitý efekt zlepšení (posunu k tomuto cíli). Nevýhodou naopak může být, že pozornost zaměřená jedním směrem může jinde chybět. Zlepšení v jedné oblasti tak může být na úkor oblasti jiné, což by ale mělo být odhalitelné dalšími metrikami.

39

5.2. Sběr dat Proces sběru dat je vhodné co nejvíce automatizovat. Nejen, že práce strojů je ve srovnání s lidskou prací levnější, ale především není tolik náchylná k chybám. Data mohou být sbírána jak vyvíjeným produktem (např. počet aktivací a deaktivací, viz oddíly. 4.3.1 a 4.3.3), tak nástroji pro podporu vývoje (např. systémy pro řízení uživatelských požadavků a defektů, nástroje pro testování a průběžnou integraci, systémy pro správu verzí). Takto se hodí využít všechny již zavedené systémy, naopak zavádění systémů jen za tímto účelem je zbytečné. Startupy často využívají nástroje od společnosti Atlassian [4], která svou licenční politikou umožňuje malým a středním podnikatelům využívat své nástroje bez vysokých počátečních investic. Tam, kde není možné sběr dat automatizovat, by se tento proces měl stát týmovou aktivitou. Je tedy potřeba jednotlivé členy týmu k této činnosti motivovat a zajistit, aby poskytovali nezkreslená data. Nejlepším způsobem, jak toho dosáhnout, je nastavit proces práce s metrikami tak, aby výsledky byly užitečné pro každého. Zároveň je nutné rozptýlit obavy, že případná data o negativních či nepříjemných skutečnostech nepovedou nutně k (mnohdy neopodstatněným či neúměrným) sankcím a že poskytnutá součinnost jim nezpůsobí nespravedlivou újmu. Sebraná data je potřeba uchovávat, zpracovávat a zpřístupňovat všem zainteresovaným stranám. Pro účely uchovávání a zpřístupňování postačí libovolné sdílené úložiště (např. sdílený disk nebo webová stránka. Je ale výhodou, pokud zvolené úložiště poskytuje zároveň podporu pro zpracování dat. Příkladem takových úložišť mohou být služby Google Docs [13] nebo Microsoft Office 365 [19], které umožňují provádět s daty libovolné výpočty a zobrazovat je ve formě tabulek a grafů.

5.3. Vyhodnocování sebraných dat Vyhodnocování sebraných dat by se mělo provádět v pravidelných intervalech. U agilního vývojového procesu se pro tento účel hodí retrospektiva na konci každé iterace [21, str. 375]. Z důvodu efektivity je potřeba, aby sebraná data již byla statisticky zpracovaná a vhodnou formou (tabulky, grafy) znázorněná. Přípravou dat by měl být pověřen vhodný člen týmu (např. u metodiky Scrum je ideální volbou Scrum Master [21, str. 185]). Na samotném

40

Obrázek 4: Podíl vývojářů V1 až V3 na celkovém dopadu vyprodukovaných chyb DVD za jednotlivé iterace I1 až I4 a za období odpovídající těmto čtyřem iteracím jako celku. vyhodnocování by se pak měl podílet celý tým. Tímto způsobem je zajištěno, že každý člen týmu se může k hodnotám metrik vyjádřit a vyslovit svůj názor na jejich příčinu (popř. příčiny). Zároveň je omezeno riziko, že skutečná příčina zůstane přehlédnuta, protože na ni nebylo upozorněno. Pro znázornění podílů hodnot jednotlivých členů týmu na hodnotě celého týmu se velmi dobře hodí řádkové (popř. sloupcové) skládané grafy. Příkladem může být graf podílu vývojářů na celkovém dopadu vyprodukovaných chyb za několik posledních iterací (viz Obrázek 4). Z grafu lze na první pohled vyčíst hned několik skutečností. Za prvé, vývojář V2 má výrazně nižší dopad vyprodukovaných chyb než zbylí dva vývojáři. Bez dalších informací je možné vyslovit domněnku, že se jedná o zkušeného vývojáře (resp. vývojáře, který má zkušenosti s plněním úkolů obdobných těm, které jsou mu přidělovány). Naopak chybovost vývojáře V3 je po celé sledované období poměrně vysoká. Zřejmě tedy půjde buď o nezkušeného vývojáře (popř. vývojáře, pro něhož jsou jemu přidělené úkoly nezvyklé) nebo o vývojáře, který své úkoly neplní s dostatečnou pečlivostí. Za druhé, tým měl neobvykle zvýšený dopad vyprodukovaných defektů ve druhé iteraci. Příčina tohoto jevu již zřejmá není, mohou jí ale být např. charakter úkolů plněných v této iteraci nebo nějaké dočasné (jedná se o jednorázový výkyv) vnější vlivy narušující soustředění na práci. Při bližším zkoumání pak lze objevit další zajímavé informace. Např. zmíněná (problematická) druhá iterace se nijak neprojevila na dopadu vyprodukovaných chyb vývojáře V2. Tato skutečnost tak jen nahrává výše vyslovené domněnce, že se jedná o zkušeného vývojáře.

41

Obrázek 5: Podíl počtu dokončených úkolů PDU, počtu účastí na nepřidělených úkolech UNU a počtu odstraněných defektů POD na pracovních výsledcích vývojářů V1 až V3 za jednu iteraci. Specifickým případem skládaného grafu je souhrnné zobrazení několika podobných metrik. Příklad (viz Obrázek 5) zobrazuje ve stejném grafu počet dokončených úkolů, počet účastí na nepřidělených úkolech a počet odstraněných defektů vývojářů za jednu iteraci. Součet těchto metrik pak odpovídá prvnímu činiteli pracovního záběru (viz oddíl 4.4.2). Z grafu je vidět, že ač vývojář V1 dokončil nejmenší počet úkolů, jeho role v rámci iterace byla důležitá, protože se podílel na dokončení několika dalších (jemu nepřidělených) úkolů. Trendy hodnot jsou lépe vidět ze zobrazení časových řad formou čárových grafů. Na následujícím obrázku (viz Obrázek 6) je jako příklad uveden vývoj objemu dokončené práce vývojáře za delší časové období. Z grafu lze vypozorovat jasně rostoucí trend objemu dokončené práce. Počáteční fáze stagnace na nízkých hodnotách (iterace I1 až I3) může být způsobena např. používáním nové technologie nebo plněním nového typu úkolů. Může se ale jednat i o zcela jiné příčiny (např. ošetřování nemocného dítěte). Pozornost si v tomto případě zasluhuje výkyvové zhoršení v iteraci I6. Zde by bylo vhodné zjistit, zda se podobný výkyv vyskytuje i u jiných vývojářů. Pokud ano, bude pravděpodobnou příčinou nějaký vliv týkající se celého týmu. Pokud ne, bude se zřejmě jednat o výkyv způsobený nějakou událostí v osobním životě vývojáře (například mu mohl pojít domácí mazlíček či mohla na několikadenní návštěvu dorazit tchýně). Obecně lze říci, že výkyvy (na jednu či druhou stranu) si zasluhují pozornost, pokud jsou větší než cca 10 %. Menší výkyvy jsou u většiny lidí poměrně běžné a obvykle nejsou

42

Obrázek 6: Vývoj objemu dokončené práce ODP jednoho vývojáře za období odpovídající deseti iteracím I1 až I10. z pohledu projektu příliš podstatné. Zvýšenou pozornost si potom zasluhují především výkyvy, které se vyskytují opakovaně. V takovém případě se často jedná o příznak jiného (hlubšího) problému. Časové řady v podobě čárových grafů je možné použít i pro porovnávání jednotlivých členů týmu. V tomto případě je vhodné do grafu zakreslit i průměrnou hodnotu (popř. jinou statistickou míru polohy). Příklad takového grafu je na obrázku 7. Graf znázorňuje vývoj přínosu dokončené práce za delší časové období. Z grafu je na první pohled vidět pokrok vývojáře V1, který se pozitivně projevil i na výsledku celého týmu (zde znázorněného průměrnou hodnotou). Zvláštním případem metriky je pokrytí řešených oblastí (viz oddíl 4.2.3). Jedná se o dvourozměrnou metriku, i její zobrazení tedy musí být dvourozměrné. Vhodná je tabulka znázorňující matici oblastí (řádky) a vývojářů (sloupce), kde na průsečíku oblasti a vývojáře je buňka vyplněna právě tehdy, když daný vývojář v danou oblast o pokrývá (PROo,v = 1). Pro příklad mobilní aplikace, která svá data synchronizuje se serverem, je odpovídající tabulka zobrazena na obrázku 8. Z tabulky je na první pohled zřejmé, že každá oblast je pokryta alespoň dvěma vývojáři a že každý vývojář pokrývá alespoň dvě oblasti. Projekt tedy netrpí problémy se zastupitelností mezi vývojáři (výpadek kteréhokoli z nich lze nahradit). Pokud by byla potřeba zachytit i míru znalostí a zkušeností vývojářů s řešenými oblastmi, bylo by možné metriku upravit tak, aby hodnotou bylo reálné číslo z intervalu 〈0,1〉 odrážející počet

iterací ze sledovaného období, ve kterých vývojář plnil úkoly z dané oblasti. Výplní buněk by pak mohl být odstín šedi odpovídající takto vypočtené hodnotě.

43

Obrázek 7: Vývoj přínosu dokončené práce POP vývojářů V1 až V3 za období odpovídající deseti iteracím I1 až I10. Pro porovnání je zakreslena i průměrná hodnota. Tabulka do značné míry zachycuje i role jednotlivých vývojářů v týmu. Je zřejmé, že V2 a V3 se zaměřují na uživatelské rozhraní klienta, V4 na serverovou část, V5 řeší webové rozhraní pro správu serveru a V1 s největší pravděpodobností plní na projektu roli architekta.

klient

V1

V2

V3

V4

V5

uživatelské rozhraní databáze

server

synchronizace dat webová služba databáze rozhraní pro správu

Obrázek 8: Pokrytí řešených oblastí PRO vývojáři V1 až V5 V oddíle 4.3.8 bylo zmíněno použití trendů metrik dosaženého výsledku pro podporu dalšího prodeje. Jejich identifikace vyžaduje dostupnost dat za delší časové období (nejméně 3 roky), proto se netýká počátečních fází startupů. Pro tento účel se ale hodí čárový graf zvolené metriky po kalendářních měsících. Příklad pro počet nových aktivací produktu v prvních třech letech po jeho uvedení na trh je zachycen na obrázku 9. Z grafu je patrný výrazný nárůst počtu nových aktivací v letních měsících (květen až srpen) a o něco menší nárůst v období kolem Vánoc (listopad až leden). V prvním roce jsou počty nových aktivací celkově malé, což je typické pro nově uvedený produkt bez masivní marketingové kampaně. Z hodnot třetího roku pak lze usoudit, že produkt se na trhu uchytil. 44

Obrázek 9: Vývoj počtu nových aktivací AKT produktu v prvních třech letech po jeho uvedení na trh.

5.4. Použití metrik pro hodnocení Metriky nejsou jen nástrojem pro rozhodování, ale mohou i úspěšně sloužit jako motivace týmu k neustálému sebezlepšování. Díky své číselné hodnotě umožňují snadné porovnání jednotlivých členů týmu a je tedy vhodné, aby se odrážely na jejich hodnocení (nejen nutně finančním). Tam, kde to charakter metriky dovoluje, je možné zveřejňovat výsledky formou žebříčků. Tyto žebříčky by měly sloužit jednak k ocenění těch, kteří podávají kvalitní výkony (horní příčky žebříčku), jednak k motivaci zbytku týmu (zbylé příčky žebříčku) se v žebříčku posunout výše. Je ale potřeba zabránit tendencím „vítězení“ jen v jedné disciplíně (zejména pak na úkor jiných oblastí). Kladně ohodnocená by tedy měla být celková zlepšení (byť pozvolná), nikoli dílčí „raketové vzestupy“ (po kterých stejně obvykle následují „raketové pády“).

5.5. Použití metrik pro optimalizaci Po zavedení metrik do praxe je příhodné jejich využití pro optimalizaci řízeného procesu. K tomu je potřeba pro vhodné metriky stanovit jejich výsledné hodnoty odpovídající požadovanému cíli (zlepšení). Tato výsledná hodnota se získá kvalifikovaným odhadem (odhadem na základě zkušeností s podobnými situacemi) z dosavadních hodnot.

45

V souvislosti s tím může nastat situace, kdy je stanovená výsledná hodnota příliš vysoká (kvalifikovaný odhad byl příliš optimistický). Ta se projeví tím, že po určité době zlepšování nastává delší stagnace. V takovém případě je nutné vyloučit jiné příčiny (např. neochota týmu se dále zlepšovat) a smířit se „pouze“ s dosaženým stavem. Obecně platí, že důležité není dosáhnout nějaké konkrétní hodnoty, ale posunout se vpřed, resp. nastolit zlepšující se trend.

46

Závěr Cílem práce bylo navržení množiny praktik a postupů (metodiky) práce s metrikami pro manažery začínajících firem (startupů), zejména se zaměřením na úvodní fázi projektu, tedy skladbu vývojového týmu a jeho stabilizaci. V teoretické části práce byly nejprve uvedeny definice metrik a pojmů s metrikami souvisejících a základní klasifikace metrik, které mají zásadní dopad na správné zacházení s nimi. Dále byly popsány obecné zásady pro práci s metrikami s důrazem na jejich hledání a vyhodnocování a obecné zákonitosti skladby vývojových týmů. V praktické části práce byl sestaven přehled metrik vhodných pro sledování vývojových týmů a jejich jednotlivých členů. Nejprve byly uvedeny metriky množství odvedené práce (produktivity) a metriky kvality odvedené práce. Poté následovaly metriky výsledku dosaženého týmem jako celkem a metriky příspěvku jednotlivých členů týmů k tomuto výsledku. Důraz byl kladen na volbu takové soustavy metrik, která ztěžuje záměrné manipulace s jejich hodnotami tím, že napomáhá jejich včasnému odhalení. Dále byly uvedeny metodické pokyny pro zavádění těchto metrik do praxe, sběr dat potřebných pro určování jejich hodnot, a jejich vyhodnocování. Na závěr byly uvedeny zásady pro používání metrik jako podkladů pro hodnocení jednotlivých členů týmu a optimalizaci fungování týmu jako celku. Součástí obou částí práce (teoretické i praktické) jsou ilustrativní příklady. Zdroji příkladů v teoretické části práce byly jednak odborná literatura, jednak vlastní pozorování a zkušenosti autorky práce. Jako podklady pro příklady v praktické části práce pak byla použita skutečná data, která byla s ohledem na oprávněné zájmy jejich poskytovatelů anonymizována. Práce v zásadě splnila cíl, který si vytyčila. Užitečná může být především pro manažery začínajících firem (startupů), pro které se může stát vodítkem při tvorbě podkladů pro řízení týmu vývojářů používajícího některou z agilních metodik vývoje. Na základě takto vytvořených podkladů je následně možné do značné míry zlepšit rozhodování v oblasti řízení lidských zdrojů vývojových týmů, zejména omezit možnost nesprávného (subjektivního)

47

vyhodnocení posuzovaných situací. Nedostatkem práce je, že se (s ohledem na svůj rozsah) omezuje jen na první fáze startupu (před uvedením produktu na trh a bezprostředně po něm). Nejsou tak zahrnuty metriky specifické pro optimalizující fungování již stabilního vývojového týmu a metriky týkající se podpory vyvinutého produktu. Práci lze v tomto směru chápat jako podnět pro zpracování těchto chybějících oblastí v samostatné bakalářské či diplomové práci.

48

Seznam použité literatury 1

AINAPURE, Bharati S. Software Testing and Quality Assurance. Second Revised Edition. Pune: Technical Publications, 2009. ISBN 978-81-8431-566-0.

2

ALEXANDER, Jonathan. Codermetrics: Analytics for Improving Software Teams. Sebastopol: O'Reilly Media, 2011. ISBN 978-1-4493-0515-4.

3

ARMOUR, Phillip G. A Measure of Control: Some Limitations on Measurements in Software. Communications of the ACM. Philadelphia: ACM, 2012, 55(6), 26 – 28. ISSN 0001-0782.

4

Atlassian Corporate Website [online]. Sydney: Atlassian, 2014 [cit. 20. 4. 2014]. Dostupné z: http://www.atlassian.com/

5

BASILI, Victor R., CALDIERA, Gianluigi a ROMBACH, H. Dieter. The Goal Question Metric Approach. Encyclopedia of Software Engineering. Hoboken: Wiley, 1994, Vol. 1, s. 528 – 532.

6

CAUBLE, Brian. Mobile App UX and UI Design 101 [online]. Birmingham: Appsolute Genius, 2014 [cit. 24. 4. 2014]. Dostupné z: http://appsolutegenius.com/blog/mobile-appux-and-ui-design-101/

7

COHN, Mike. Agile Estimating and Planning. Upper Saddle River: Prentice Hall, 2006. ISBN 978-0-13-147941-8.

8

COLLIER, Ken. Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Boston: Addison-Wesley, 2012. ISBN 978-0-321-50481-4.

9

DORAN, George T. There's a S.M.A.R.T. Way to Write Management Goals and Objectives. Management Review. New York: American Management Association, 1981 70(11), 35 – 36. ISSN 0025-1895.

10 EBBINGHAUS, Hermann. Memory: A Contribution to Experimental Psychology. Bristol: Thoemmes Press, 1998. ISBN 978-1-8550-6672-4. 11 FENTON, Norman E. a PFLEEGER, Shari L. Software Metrics: A Rigorous and Practical Approach. Stamford: Course Technology, 1998. ISBN 978-0-534-95425-3.

49

12 Google Analytics Official Website [online]. Mountain View: Google Inc., 2014 [cit. 14. 4. 2014]. Dostupné z: http://analytics.google.com/ 13 Google Docs Official Website [online]. Mountain View: Google Inc., 2014 [cit. 20. 4. 2014]. Dostupné z: http://docs.google.com/ 14 HAUSER, John R. a KATZ, Gerald M. Metrics: You Are What You Measure. European Management Journal. Amsterdam: Elsevier, 1998, 16(5), 517 – 528. ISSN 0263-2373. 15 International Organisation for Standardization. ISO/IEC/IEEE 24765:2010(E) – Software and Systems Engineering – Vocabulary. Geneva: ISO/IEC Press, 2010. ISBN 978-07381-6206-5. 16 JURAN, Joseph M., a Gryna, Frank M., ed. Juran's Quality Control Handbook. Fourth Edition. New York: McGraw-Hill, 1988. ISBN 978-0-070-33176-1. 17 LESONSKY, Rieva. 6 Skills Every Startup Team Needs [online]. New York: SAY Media Inc., 2012 [cit. 19. 2. 2014]. Dostupné z: http://readwrite.com/2012/06/14/6-skills-everystartup-team-needs/ 18 Manifesto for Software Craftsmanship [online]. 2009 [cit. 30. 3. 2014]. Dostupné z: http://manifesto.softwarecraftsmanship.org/ 19 Microsoft Office Official Website [online]. Redmond: Microsoft Corp., 2014 [cit. 20. 4. 2014]. Dostupné z: http://office.microsoft.com/ 20 RAYPORT, Jeffrey. The Virus of Marketing. Fast Company. Harlan: Fast Company, 1996. 1(6), 68 – 72. ISSN 1085-9241. 21 RUBIN, Kenneth S. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston: Addison-Wesley, 2013. ISBN 978-0-13-704329-3. 22 SCHACTER, D. L. The Seven Sins of Memory: Insights From Psychology and Cognitive Neuroscience. American Psychologist. Washington D.C.: American Psychological Association, 1999, 54(3), 182 – 203. ISSN 0003-066X. 23 STRAUSS, Samantha. How to Build a Startup Team [online]. Chicago: Tech Cocktail, 2010 [cit. 19. 2. 2014]. Dostupné z: http://tech.co/how-to-build-a-startup-team-2010-08 24 WOODCOCK, Mike a FRANCIS, Dave. Team Metrics: Resources for Measuring and Improving Team Performance. Amherst: HRD Press, 2008. ISBN 978-1-59996-129-3.

50