9 Řešení problémů s projektem Vyšší management Projektový manažer „Všechny šťastné rodiny jsou si podobné; každá nešťastná rodina je nešťastná po svém.“ – L. Tolstoj, Anna Karenina1
Obrázek 9.1
Lev Nikolajevič Tolstoj.
221
222
EFEKTIVNÍ SOFTWAROVÉ PROJEKTY
Aforizmus Lva Nikolajeviče se dá aplikovat i na softwarové projekty. V softwarovém projektu je mnoho vzorů nešťastných situací, které se obvykle projevují nejméně dvěma desítkami symptomů. Kapitola se soustřeďuje na tyto vzory, symptomy, a na to, jak je rozpoznávat. Na tomto místě doufám, že už jste přesvědčenými přívrženci hodnotocentrického přístupu, který prosazuje, abychom používali systémy průběžně hledající způsoby, jako zdokonalit tok hodnoty. V 1. kapitole, „Hodnotocentrický přístup“, jsem ho porovnal se zobrazením „železného trojúhelníku“ úkolocentrického přístupu, kde se předpokládá fixní kapacita a problémy se redukují na čas, zdroje, funkcionalitu a kvalitu.2 Datový sklad metrik, jako je například databáze pracovních položek, umožňuje provozovat projekt na bázi důvěry a transparentnosti. Každý člen týmu vidí stejná data, klade stejné otázky, hledá odpovědi a participuje na nalézání řešení. Možná budete tuto kapitolu kritizovat za to, že je zbytečně kvantitativní. V žádném případě tím ale nemíním doporučovat, že k podchycení problémů vždycky potřebujete nějaká čísla, nebo že řešení a zdokonalování mají být vyjadřovaná v číslech. Jak jsem probral ve 4. kapitole, „Správa projektu“, je třeba, aby byly metriky popisné, nikoli předepisující. Hrdost na profesionalitu, což je jeden z postojů MSF, se předpokládá u každého, a metriky jsou nástroj, který má tuto hrdost posilovat, ne ji vytlačovat. V míčových hrách vyhráváte tím, že hrajete dobře, a sledujete míč, ne světelnou tabuli se skórem. Na tabuli se prostě udržuje aktuální stav skóre, takže se nemusíte rozptylovat hádkami o to, čí čísla jsou správná. Na mnohé symptomy žádný sklad metrik nepotřebujete. Dobře známou ukázkou je inverzní Dilbertův korelační faktor: čím víc Dilbertových kreslených vtipů je nalepených na dveřích kanceláří a na vývěskových tabulích, tím méně zdravá je organizace. (Samozřejmě, nepřítomnost jakýchkoli kreslených vtipů může být také varovným signálem o jistých firemních politikách.) Jiným příkladem je morálka týmu, která se viditelně odráží v úrovni energie a nadšení. Jestliže členové týmu nemohou kvůli problémům v projektu spát, měli by vám být schopni sdělit, co jim dělá starosti. A pokud to nevíte, pak se zbytkem svého týmu netrávíte dost času. Na druhou stranu se může každému z nás stát, že něco přehlédne. Pro odhalení možných rizik a opomenutí jsou skvělé trendy a detailní pohledy, a grafy „zdravotního stavu“ jsou skvělým místem, odkud začít. Dodají vám taková data, abyste mohli začít klást správné otázky, odpovědi však může nalézt jen celý tým. Největší předností grafů metrik je, že dovedou doplnit vaše
ŘEŠENÍ PROBLÉMŮ S PROJEKTEM
pocity a podezření, která získáte z kontaktu se svými týmovými spolupracovníky, když zkoušíte momentální sestavení softwaru, revidujete kód, zkoumáte chyby, plánujete iterace, a tak dále. Grafy poskytují ukazatele všeobecného zdravotním stavu projektu a když máte podezření, že jste narazili na nějaký problém, můžete se podívat na data, abyste si jej potvrdili nebo vyvrátili. Ve zbytku kapitoly uvedu soupis celé řady potenciálních problémů, z nichž mnohé určitě znáte ze svých osobních zkušeností, a předvedu, jak se mohou projevovat na grafech VSTS o zdravotním stavu projektu. Cílem je ukázat, jak může VSTS se svými denními reporty poskytnout včasná varování a pomoci při průběžných korekcích, abyste mohli stále zdokonalovat kvalitu. Používání Excelu s datovým skladem metrik Kromě standardních reportů, které jsou ve VSTS nainstalované s šablonou metodiky, můžete ke všem datům skladu metrik přistupovat z Microsoft Excelu. Podívejte se do tohoto tématu MSDN: Development Tools and Technologies Visual Studio Team System Team Foundation Team Foundation Project Leads Using Reporting and Metrics Team Foundation Server Reporting Using Team Reports Using Microsoft Excel for Team Foundation Server Reporting
Podcenění Jedním z nejčastěji ohlašovaných symptomů problémů je podcenění. Když projekt postupuje vpřed pomaleji, než jak bylo naplánováno, a úsilí je větší, než jaké bylo odhadnuto jako postačující, tak členové týmu podcenili zdroje, obtížnost, čas, nebo jiné faktory (obrázek 9.2). Narazíte-li na tento vzor, samozřejmě budete chtít najít jeho hlavní příčiny. Existuje několik možných příčin podcenění, které jsou znázorněné na obrázcích 9.3 až 9.10.
223
224
EFEKTIVNÍ SOFTWAROVÉ PROJEKTY
Počet pracovních položek
116 144
193
187
179
173
166
106
94
133
156
92 90 86 68
18
38
6/25/2005
6/22/2005
6/19/2005
10
29
67
49
18 6/16/2005
5
6/13/2005
16 6/10/2005
6/7/2005
6/4/2005
6/1/2005
7
15
61
6/30/2005
22
6/28/2005
40
Datum Aktivní Vyvřešené Uzavřené
Obrázek 9.2
Podle sklonu čáry pro uzavřené pracovní položky se dá usoudit, že tato čára bude k datu konce iterace výrazně pod plánovanou úrovní, což znamená, že ne všechny scénáře, které byly pro tuto iteraci naplánované, budou dokončené včas.
Nestejnoměrná dekompozice úkolu Kontrolujte rozmanitost definic úkolů a rozsah jejich podrobnosti. Budete chtít vidět úkoly naplánované na dobu jednoho až tří dnů (obrázky 9.3 a 9.4).
Hluchá místa architektury Někdy tým odhalí, že je zapotřebí změnit něco v architektuře. Třeba je nutné více se soustředit na integraci, přehodnotit požadavky na kvalitu, změnit strukturu komponent, zavést nové společné služby, změnit naplánované prostředí, ve kterém bude produkt nasazen, nebo provést jiné rozsáhlé architektonické změny.
ŘEŠENÍ PROBLÉMŮ S PROJEKTEM
400 350 300
Počet úkolů
250 200 150 100 50 0 1 den
2-3 dny
6-10 dní
4-5 dní
více než 21 dní
11-20 dní
Velikost úkolů Počet úkolů
Obrázek 9.3 Histogram počtu úkolů podle velikosti ukazuje, že je velikost úkolu velmi variabilní.
28 26
21 19
19 18
15
15 13
11.39 12
12
13
12
11
10
12
12 10
10 9
9 6
6 3
3
3 2
2
2
Datum Vyřešené (za den) Uzavřené (za den) Průměrně vyřešeno
7/1/2005
6/30/2005
6/29/2005
6/28/2005
6/27/2005
6/26/2005
6/25/2005
6/24/2005
6/23/2005
6/22/2005
6/21/2005
6/20/2005
6/19/2005
6/18/2005
6/17/2005
6/16/2005
6/15/2005
0 6/14/2005
Počet přechodů
22 20
Obrázek 9.4 V souladu s tím ukazuje graf rychlosti 0 projektu (Project Velocity) velký rozptyl v počtu úkolů uzavřených za jeden den.
225
