Řešení problémů s projektem

Transkript

1 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 Karenina 1 Obrázek 9.1 Lev Nikolajevič Tolstoj. 221

2 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

3 ŘEŠENÍ PROBLÉMŮ S PROJEKTEM 223 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.1.

4 224 EFEKTIVNÍ SOFTWAROVÉ PROJEKTY Počet pracovních položek /1/25 6/4/25 6/7/25 6/1/25 6/13/25 6/16/25 6/19/25 6/22/25 6/25/25 6/28/25 6/3/25 Aktivní Vyvřešené Uzavřené Datum 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.

5 ŘEŠENÍ PROBLÉMŮ S PROJEKTEM Počet úkolů den 2-3 dny 4-5 dní 6-1 dní 11-2 dní více než 21 dní Velikost úkolů Počet úkolů Obrázek 9.3 Histogram počtu úkolů podle velikosti ukazuje, že je velikost úkolu velmi variabilní Počet přechodů 6/14/ // /16/25 6/17/25 Vyřešené (za den) Uzavřené (za den) Průměrně vyřešeno 6//25 6/19/ /2/25 6/21/25 6/22/25 Datum 6/23/25 6/24/25 6/25/ /26/25 6/27/25 6/28/25 6 6/29/25 6/3/25 7/1/25 Obrázek 9.4 V souladu s tím ukazuje graf rychlosti projektu (Project Velocity) velký rozptyl v počtu úkolů uzavřených za jeden den.