Plánování projektu (CMMI)
Požadovaný výsledek plánování projektu je plán, který obsahuje obor, plán, rozpočet, plánu řízení rizik a závazků a schválení od všech zúčastněných stran.Plán projektu dohodnuté chcete průběh s analýzu, návrh, vývoj, testování a nakonec dodání.
Pomocí metody iterativní vývoj můžete snížit riziko.Počet iterací umožňují prokázat částečně pracovní produktu na konci každé iteraci a zákona o zpětnou vazbu od že demonstrace.Proto plán poskytuje celkový tvar a podléhají přezkoumání a upřesnění před začátkem každé opakování.
V tomto tématu
Získávání a modelování požadavků
Vytvoření dílčích požadavky produktu
Zadávání a úpravy požadavky produktu
Odhad požadavků produktu
Přiřazení požadavky produktu iterací
Plánování testů
Revize požadavky produktu
Získávání a modelování požadavků
Tato činnost je o projednávání systém postupovat, obchodní zúčastněným stranám, potenciální uživatelé a odborníci.Je důležité pochopit souvislosti business.Pokud jste byli požádáni napsat aplikaci pro policisty, pomůže pochopit jejich žargon, postupy a pravidla.
Modely UML jsou užitečným nástrojem pro vyjádření a přemýšlíte o složité vztahy.Můžete kreslit Visual Studio a jejich propojení na jiné dokumenty a na Team Foundation pracovní položky.Další informace získáte v tématu Modelování požadavků uživatelů.
Aktualizace a vylepšení modelu požadavky projektu.Každé iteraci se blíží, přidáte více podrobností aspekty modelu, které jsou relevantní pro dané iterace.Z modelu můžete odvodit ověřovací zkoušky.
Další informace naleznete v tématu Developing Customer Requirements a Vývoj testů z modelu.
Vytvoření dílčích požadavky produktu
Požadavky jako shromážděné z vašich zákazníků nejsou přímo vhodné pro plánování rozvoje přírůstkové.Například vyjasnit postup, když uživatel kupuje něco z webového serveru, může být napsané řadu podrobných kroků: zákazník přejde katalog, přidá položku do vozíku kontroly limitu vozíku, poskytuje adresy a platí; dodání plány skladu; a tak dále.Tyto kroky nebo diagramu činnosti rovnocenné nejsou přírůstkové požadavky.
Místo toho první přírůstek systému může nabídnout k prodeji pouze jednu položku dodat pouze jednu adresu a provádět pouze zkušební transakce s platební služby.Druhý krok může poskytnout katalog, který se skládá z jednoduchého seznamu.Pozdější přírůstky přidat možnost dárkové balení nákupu nebo vyžádání katalogy, které jsou k dispozici od různých dodavatelů.Některé přírůstky pravděpodobně kvality služeb, jako je schopnost zpracovávat 1 000 zákazníků pouze jedno místo.
Jinými slovy by brzy po krocích vykonávat použití hlavních případů konec konec a postupně přidávat funkce v celém.
Pokud pracujete s existující produkt, Princip je stejný, ale spustit z existující funkce.Pokud jste obeznámeni s jeho vnitřní návrhu, může být obtížné odhadnout náklady na aktualizace.Je vhodné jsou přístroje s odhady dřívější změny.
Další informace naleznete v tématu Vývoj požadavků.
Zadávání a úpravy požadavky produktu
Záznam požadavků přírůstkové produktu jako pracovní položky požadavku v Team Foundationa zadejte požadavky na funkci.Můžete vytvořit požadavek pracovních položek v 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 Office Excel zobrazení dotazu požadavky produktu.Další informace naleznete v tématu Práce v aplikaci Microsoft Excel a Microsoft Project připojené k Team Foundation Server a Provedení plánování shora dolů pomocí stromu seznam pracovních položek (V aplikaci Excel).
Odhad požadavků produktu
Vývojový tým by měl odhad práce potřebné k vývoji jednotlivých požadavků produktu.Odhad by zapsány v hodinách, v poli původní odhad pracovní položky.
V rané fázi projektu je hrubý odhad vše potřebné.
Požadavky na velké produkt rozdělte na menší.V ideálním případě každý požadavek produktu bude trvat pouze několik dnů časového vývoje.
Přiřazení požadavky produktu iterací
Zástupci zúčastněných stran obchodní a vývojový tým by měly společně přiřadit požadavky produktu iterací.Obvykle to provést schůzky, kde sdílet nebo projektu Office Excel zobrazení dotazu požadavky produktu.
Dokončení přiřazení pomocí následující druhy údajů:
Priorita požadavek.Viz poznámky v následující podčásti.
Odhad nákladů.Každé opakování uveden počet členů týmu a délka iterace, má pevný počet hodin, které jsou k dispozici pro rozvoj.Kromě toho se použije značný počet těchto hodin pro plánování iterace a další úkoly, které nezahrnují vývoj přímo.
Závislosti mezi požadavky produktu.V přírůstkové řadu požadavků musí se zabývat nejjednodušší požadavky před vylepšení ve stejné oblasti.
Požadavek můžete definovat pracovní položka uvede různé informace, zobrazit následující ilustrace:
.png "Formulář pracovní položky požadavku")
.gif "Ee461521.collapse_all(cs-cz,VS.110).gif")
Některé pokyny pro stanovení priorit
Pro stanovení priorit existovat mnoho podrobných schémat.Jsme v některých případech posoudí při považujeme iterace plánování.Nyní na úrovni projektu můžeme zahrnout některé pokyny, které mohou být užitečné při správě rizika a optimalizaci přidanou hodnotu.
Upřednostnit minimální scénáře-konec.
Cílem je dosáhnout jednoduchý scénář-konec v projektu co nejdříve.Různé části Scénář později přidáte další funkce.Tato praxe zajišťuje základní funkce platformy a hlavní myšlenky v požadavcích se brzy.
Naopak nerozděluje plánu podle architektury.Plán, který dokončí databáze, potom obchodní logiku a uživatelské rozhraní bude pravděpodobně vyžadovat značnou vytvořit integrovat částí na konci.Stejným způsobem vodorovné rozdělení, například {prodejní komponenty; součást skladu; součást platby} není doporučeno.By pravděpodobně vyrábět vynikající systém pro prodej na webu však před prostředkem získávání peněz ze zákazníků má obchodní časový limit.Kompletní součásti lze naplánovat pro vyšší počet iterací, pouze v případě, že jsou skutečně volitelné doplňky.
Upřednostnit technické riziko.
Pokud scénář obsahuje prvek technicky riskantní, rozvíjet v plánu.Riziko trvat o přístupu "brzy selhání".Něco nelze provést, chcete-li to vědět v rané fázi projektu tak, že mohou být zrušena nebo nahrazena alternativní přístup.Tak upřednostnit technicky nebezpečné požadavky do rané iterací.
Prioritu snížení nejistoty.
Zúčastněné strany obchodní nebudou jisti některé požadavky.Je těžké odhadnout chování produktu jsou nejvhodnější v rámci podniku.Stanovit priority práce, která by mohla snížit nejistot.Toho lze dosáhnout často rozvíjením zjednodušená verze scénáře, které mohou uživatelé experimentovat.Odložit úplné scénář, který má vyšší iterace, ve kterém lze považovat za výsledky těchto pokusů.
Upřednostnit vysoce hodnotným požadavky.
Pokud možno pokuste navázat příležitosti náklady o zpoždění funkci pro každý scénář.Použijte k určení požadavků, které mohou potenciálně způsobit další hodnoty zákazníkům dříve.Uspořádání těchto požadavků do dřívější iterací.To může koupit možnost včasné uvolnění částečné produktu
Skupiny scénářů, které jsou společné pro více personas.
Pokud jste nástroj pro dvě nebo více personas scénáře, seskupte tyto společně.Pořadí je číslo personas, které vyžadují scénář.Upřednostnit scénáře, které platí pro větší počet personas do rané iterací.
Pořadí personas.
Personas představují segmenty trhu nebo skupiny uživatelů.Osoby nebo obchodní vlastníci uvádění na trh by měl připomenout priority těchto segmentů nebo skupiny založené na nástroj doručení nebo hodnota segmentu.Segmenty nebo skupiny uživatelů lze hodnocení priority, zobrazte tento seznam personas pro každý segment podle pořadí.Určit scénáře pro nejvyšší pořadový personas a prioritu těchto do dřívější iterací v plánu.
Chceme obecně prioritu snížení rizika vzhledem k možnosti selhání.Chceme běžné funkce prioritu, protože je pravděpodobně vyžadována a není pravděpodobné, že změna.Chceme upřednostňovat hodnotnější požadavky.Chceme Prioritizace všech scénářů, které jsou nutné k uspokojení potřeb všech jeden persona povolit možnost předčasného propuštění výrobku do podmnožiny personas.
Plánování testů
Úsilí, které je nutné ručně nebo pomocí automatického testování test požadavek, musí obsahovat odhad práce pro každý požadavek.
Dříve, než je považován za dokončený, musí být propojen sadu zkušební případ pracovních položek, které společně ukazují, zda je splněn požadavek a zkoušek musí projít každý požadavek produktu.
Při vytváření nebo opravit produkt požadavky odpovídající plán testování musí být aktualizovány.
Revize požadavky produktu
Tato činnost navštěvovat před každé opakování zvážit požadavky revidované a nové revidované priorit a revidované odhady.Bude další revize v prvních několika iterací.
Po prvních několika iteracích budou členové týmu vývoje větší jistotu o odhady.By projít odhady pro další jeden nebo dva iterací a upravte pole původní odhady požadavků, které jsou přiřazeny tyto iterací.