Plánování projektu (CMMI)
Požadovaný výsledek plánování projektu je plán, který obsahuje obor, rozvrh, rozpočet, plán řízení rizik a závazek a schválení od všech zúčastněných stran.S odsouhlaseným plánem projektu chcete postoupit k analýze, návrhu, vývoji, testování a nakonec doručení.
Pomocí metody iterativního vývoje můžete snížit riziko.Iterace umožňují ukázat částečně funkční produkt na konci každé iterace a provádět činnost na základě zpětné vazby z této ukázky.Proto tento plán poskytuje celkový obraz a podléhá přezkoumání a upřesnění před začátkem každé iterace.
Shromažďování a modelování požadavků
Tato činnost se týká diskuse o tom, co by měl systém dělat, s obchodními zúčastněnými stranami, potenciálními uživateli a odborníky na danou problematiku.Je důležité pochopit obchodní kontext.Pokud jste byli požádáni o napsání aplikace pro policisty, je užitečné porozumět jejich žargonu, postupům a pravidlům.
Modely UML jsou užitečným nástrojem pro vyjádření a přemýšlení o složitých vztazích.Můžete je nakreslit v aplikaci Visual Studio a poté je propojit do jiných dokumentů a pracovních položek Team Foundation.Další informace naleznete v tématu Modelování uživatelských požadavků.
Aktualizujte a upřesňujte model požadavků v průběhu celého projektu.Při každém blížícím se opakování přidejte další podrobnosti do aspektů modelu, které jsou relevantní pro danou iteraci.Z modelu můžete odvodit testy ověřování.
Další informace naleznete v tématu Vývoj požadavků a Vývoj testů z modelu.
Vytváření dílčích požadavků produktu
Požadavky, jak jste je shromáždili od svých zákazníků, nejsou přímo vhodné pro plánování dílčího vývoje.Chcete-li například vyjasnit postup v případě, že si uživatel koupí něco z webového serveru, pravděpodobně jste napsali řadu podrobných kroků: zákazník projde katalog, přidá zboží do košíku, zkontroluje košík, zadá adresu a zaplatí; sklad naplánuje dodávku; a tak dále.Tyto kroky nebo ekvivalentní diagramy činnosti nejsou dílčí požadavky.
Místo toho první přírůstek systému může nabídnout k prodeji pouze jednu položku, dodat pouze na jednu adresu a provádět pouze testovací transakce s platební službou.Druhý krok může poskytnout katalog, který se skládá z jednoduchého seznamu.Pozdější přírůstky mohou přidat možnost dárkového balení nákupu nebo vyžádání katalogů, které jsou k dispozici od různých dodavatelů.Některé přírůstky se mohou týkat kvality služby, např. schopnost vyřídit 1000 zákazníků místo pouze jednoho.
Jinými slovy, starší přírůstky by měly vykonávat hlavní případy použití konec-konec a postupně přidávat funkce napříč celkem.
Pokud pracujete s existujícím produktem, princip je stejný, ale začnete z existující funkce.Pokud nejste obeznámeni s jeho vnitřní strukturou, může být obtížné odhadnout náklady na aktualizace.Stojí za to být benevolentní v odhadech dřívějších změn.
Další informace naleznete v tématu Vývoj požadavků.
Zadání a úpravy požadavků produktu
Zaznamenejte přírůstkové požadavky produktu jako pracovní položky požadavku v Team Foundationa nastavte typ požadavků na Funkce.Můžete vytvořit nevyřízené položky požadavků pomocí TWA nebo Průzkumník týmových projektů.Pokud máte několik pracovních položek, které chcete vytvořit současně, můžete použít Excel.
Odhad požadavků produktu
Vývojový tým by měl odhadnou práci potřebnou k vývoji jednotlivých požadavků produktu.Odhad se uvádí v hodinách do pole Původní odhad pracovní položky.
V rané fázi projektu je hrubý odhad vše, co je potřeba.
Velké požadavky produktů rozdělte na menší části.V ideálním případě každý požadavek na produkt bude trvat pouze několik dnů z času vývoje.
Přiřazení požadavků produktu k iteracím
Zástupci zúčastněných subjektů podniku a vývojový tým by měli pracovat společně na přidělování požadavků produktu k iteracím.Obvykle to provedete na schůzce, kde sdílíte nebo projektujete zobrazení Office Excel dotazu Požadavky produktu.
Přiřazení je dokončeno pomocích následujících druhů informací:
Priorita požadavku.Viz poznámky v následující podčásti.
Odhadované náklady.Vzhledem k počtu členů týmu a délce iterace má každá iterace pouze pevný počet hodin, které jsou k dispozici pro vývoj.Kromě toho se značný počet těchto hodin použije pro plánování iterace a další úkoly, které nezahrnují vývoj přímo.
Závislosti mezi požadavky produktu.V přírůstkové řadě požadavků musí být nejjednodušší požadavky řešeny před vylepšeními ve stejné oblasti.
Požadavek lze definovat v pracovní položce zadáním různých informací, jak je vidět z následující ilustrace:
.png "Formulář pracovní položka požadavku")
Některé pokyny pro stanovení priority
Mnoho podrobných schémat existuje pro stanovení priority.Prozkoumáme některé z nich, když budeme přemýšlet o plánování iterace.Nyní na úrovni projektu můžeme zahrnout některé pokyny, které mohou být užitečné při správě rizik a optimalizaci přidané hodnoty.
Prioritizujte minimální ucelené scénáře.
Cílem je dosáhnout jednoduchého kompletního scénář v projektu co nejdříve.Později přidáte další funkce do různých částí scénáře.Tento postup zajišťuje, že základní funkce platformy a hlavní myšlenky v požadavcích jsou otestovány v rané fázi.
Naopak nerozdělujte plán podle architektury.Plán, který dokončí databázi, pak obchodní logiku a poté uživatelské rozhraní, bude pravděpodobně vyžadovat značné přepracování, aby bylo na konci možné integrovat části.Stejným způsobem se nedoporučuje vodorovné rozdělení jako {součást prodeje; komponenta skladu; součást platby}.Pravděpodobně by vytvořilo vynikající systém pro prodej na webu, ale došel by mu čas dřív, než by firma měla prostředky k získání peněz od svých zákazníků.Kompletní komponenty lze naplánovat pro vyšší počet iterací, pouze pokud jsou to skutečně volitelné doplňky.
Prioritizujte technická rizika.
Pokud scénář obsahuje technicky rizikový prvek, vyvíjejte ho brzy v plánu.Použijte přístup k riziku „selhat co nejdřív“.Pokud něco nelze provést, chcete to vědět v rané fázi projektu, aby to bylo možné zrušit nebo nahradit alternativním přístupem.Prioritizujte proto technicky nebezpečné požadavky do raných iterací.
Prioritizujte snížení nejistoty.
Zúčastněné obchodní strany se nebudou jisty některými požadavky.Je těžké předpovědět, jaké chování produktu je nejvhodnější v obchodním kontextu.Prioritizujte práci, která pravděpodobně sníží nejistotu.Toho lze často dosáhnout rozvíjením zjednodušených verzí scénáře, se kterými mohou uživatelé experimentovat.Odložit úplný scénář na pozdější iteraci, ve které lze zvážit výsledky těchto pokusů.
Prioritizujte vysoce hodnotné požadavky.
Pokud je to možné, pokuste se vytvořit funkci náklady-z-prodlení-příležitosti pro každý scénář.Použijte je ke stanovení požadavků, které mohou potenciálně přinést větší hodnotu zákazníkům dříve.Prioritizujte tyto požadavky do raných iterací.To vám může poskytnout možnost brzy vydat částečný produkt
Skupinové scénáře, které jsou společné pro více person.
Pokud máte scénáře, které mají nástroje pro dvě nebo více person, seskupte tyto dohromady.Ohodnoťte je podle počtu person, které vyžadují tento scénář.Prioritizujte scénáře, které platí pro větší počet person, do raných iterací.
Ohodnotit persony.
Persony představují segmenty trhu nebo skupiny uživatelů.Marketingoví specialisté nebo majitelé podniků by měli být schopni srozumitelně vysvětlit prioritu těchto segmentů nebo skupin na základě užitečnosti, kterou přinášejí, nebo hodnoty segmentu.Pokud segmenty nebo skupiny uživatelů lze seřadit dle priority, ukažte toto uvedením person pro každý segment podle pořadí.Určit scénáře pro nejvyšší pořadové persony a stanovení jejich priorit do předchozích iterací v plánu.
Obecně chceme upřednostnit snížení rizika z důvodu možnosti selhání.Chceme upřednostnit běžnou funkcionalitu, protože bude pravděpodobně požadována a je nepravděpodobné, že by se změnila.Chceme upřednostnit hodnotnější požadavky.Chceme povolit možnost raného vydání produktu podmnožině osob prioritizací všech scénářů, které jsou nutné k uspokojení potřeb libovolné osoby.
Plánování testů
Odhad práce pro každý požadavek musí obsahovat úsilí, které je nezbytné pro testování požadavku, buď ručně, nebo vytvořením automatického testu.
Předtím, než je považován za dokončený, každý požadavek na produkt musí být spojen se sadou pracovních položek testového případu, které společně ukazují, zda je splněn požadavek, a musí testy projít.
Když vytváříte nebo upravujete požadavky produktu, je nutné aktualizovat odpovídající plán testování.
Kontrola požadavků produktu
Znovu se vraťte k této činnosti před každou iteraci a zvažte opravené a nové požadavky, opravené priority a opravené odhady.Budou další revize v prvních několika iteracích.
Po prvních několika iteracích budou členové týmu vývoje mít větší jistotu při odhadech.Měli by si projít odhady pro další jednu nebo dvě iterace a opravit pole Původní odhady požadavků, které jsou přiřazeny k těmto iteracím.