Typy pracovních položek a pracovní postup šablony procesu CMMI

Týmy pomocí typů pracovních položek (WIT) poskytovaných s šablonou procesu MSF pro CMMI Process Improvement 2013 (CMMI) plánují a sledují pokrok softwarových projektů.Týmy definovat podmínky pro správu nevyřízených položek práce a pak pomocí na kanbanové tabuli, sledování průběhu aktualizací stav požadavky.

Můžete získat podrobné informace o portfolio požadavky, můžete vlastníci produktů namapovat požadavky na funkce.Týmy pracovat v iterací, definují úlohy, které automaticky propojit s požadavky.

Pomocí Microsoft Test Manager a Team Web Access (TWA), testeři k vytváření a spouštění testovacích případů a definovat chyby ke sledování vady kódu.

Pro podporu dalších procesů CMMI, týmům, které můžete sledovat žádosti o změnu, rizika, problémy a poznámky zaznamenat v zkontrolujte schůzek.

Plánování projektu definováním požadavků a odhadem míry úsilí

Vytvořte požadavky z panelu pro snadné přidání na stránce nevyřízených položek produktu.Případně lze požadavky přidat hromadně pomocí aplikací Excel nebo Project.

Později můžete otevřít každý požadavek a mít tak k dispozici další podrobnosti a odhad rozsahu.

Požadavky určují funkce a prvky produktu, které týmy musí vytvořit.Vlastníci produktu obvykle definují a stohují pořadí požadavků na stránce nevyřízených položek produktu.Tým pak změří úsilí a práci potřebné k doručení položek s nejvyšší prioritou.

Definováním položky Velikost pro požadavky mohou týmy používat funkci prognózy a grafy rychlosti pro odhad budoucích iterací nebo pracovního úsilí.Pomocí následujících polí a karet zachyťte důležité informace.Další informace naleznete v tématu Plánování projektu.

Pole/karta	Použití
Velikost (viz poznámka 1)	Odhad množství práce potřebného k dokončení požadavku pomocí libovolné jednotky měření, které dává váš tým přednost, například velikost trička, body scénáře nebo čas. Agilní grafy rychlosti a nástroje prognózy odkazují na hodnoty v tomto poli.Toto pole je povinné pro generování grafu rychlosti.
Priorita [povinné] (2)	Subjektivní hodnocení požadavku ve vztahu k podniku.Povolené hodnoty jsou následující: 1: Produkt nelze odeslat bez položky. 2: (výchozí) Produkt nelze odeslat bez položky, ale není třeba ji řešit okamžitě. 3: Implementace položky je volitelná na základě zdrojů, času a rizika.
Třídění [povinné] (2)	Označuje typ rozhodnutí ke třídění, která čekají na vyřízení u pracovní položky.Použijte toto pole, když je pracovní položka ve stavu Navrhované, a zadejte jednu z následujících hodnot: Čekající (výchozí), Další informace, Informace přijaty a Roztříděno.
Blokováno (2)	Označuje, zda je členovi týmu zabráněno v pokroku v implementaci požadavku nebo úkolu nebo řešení chyby, žádosti o změnu nebo rizika.Pokud byl problém otevřen za účelem sledování blokujícího problému, můžete vytvořit odkaz na problém.Můžete zadat Ano, nebo Ne.
Potvrzeno [povinné] (2)	Označuje, zda je požadavek v projektu potvrzen.Můžete zadat Ano, nebo Ne (výchozí).
Řazení zásobníku (1)	Lze sledovat relativní pořadí požadavků.Pořadí položek na stránce nevyřízených položek produktu se stanoví podle toho, kam jste položky na stránce přidali nebo přesunuli.Při přetahování položek aktualizuje proces na pozadí toto pole, které je přiřazeno k typu type="Order" v souboru ProcessConfiguration.
(Požadavek) Typ [povinné] (2)	Typ požadavku, který chcete implementovat.Můžete určit jednu z následujících hodnot: Obchodní záměr Funkce (výchozí) Funkční Rozhraní Provozní QoS (Quality of Service) Bezpečnost Scénář Zabezpečení
Popis	Poskytuje dostatek podrobných informací pro odhad, kolik práce je třeba k implementaci požadavku.Zaměřte se na to, pro koho je požadavek určen, čeho chtějí uživatelé docílit a proč.Nepopisujte, jak by měl být požadavek vytvořen.Poskytněte dostatečně podrobné údaje, aby mohl tým zapisovat úkoly a testovací případy pro potřebu implementace položky. V polích HTML můžete přidat formátovaný text a obrázky.
Analýza (Hodnocení dopadu)	Dopad pro zákazníka v případě, že není neimplementován tento požadavek.Můžete zahrnout informace z modelu Kano o tom, zda je tento požadavek v kategorii překvapení, vyžadováno nebo zjevné.Tyto informace můžete zaznamenat do pole formátovaného textu HTML, které odpovídá odhadu dopadu.
Jiné	Následující pole jsou umístěna na kartě Jiné a nejsou požadována. Integrováno v: Číslo sestavení produktu, které zahrnuje požadavek, žádost o změnu nebo opravuje chybu. Test přijetí uživateli [povinné] (2): Stav testu přijetí uživateli. Úspěšný Selhání Není připraven (výchozí) Připraven Vynecháno Informace přijaty Zadejte možnost Není připraven, pokud je požadavek Aktivní, a možnost Připraven, pokud je požadavek ve stavu Vyřešeno. Původní odhad (3): Počet hodin nebo dnů potřebných k dokončení úkolu. Odborníci na danou problematiku: Jména členů týmu, kteří znají oblast zákazníka, jíž představuje tento požadavek. Datum zahájení, Datum dokončení (3): Cílová data pro zahájení nebo dokončení práce.Tato pole jsou vyplněna aplikací Microsoft Project, když ji použijete k plánování.

Poznámky:

1. Další informace o změně přiřazení pole naleznete v tématu Konfigurace a přizpůsobení nástrojů pro agilní plánování pro týmový projekt.

2. Chcete-li změnit výběr nabídky, naleznete v části seznam výběr přizpůsobit.

3. Můžete určit práci v hodinách nebo ve dnech.Neexistují žádné vlastní časové jednotky spojené s tímto polem.

   Použijete-li aplikaci Microsoft Project pro přiřazení prostředků a sledování plánu, můžete aktualizovat pole pomocí aplikace Project.

Sledování průběhu

Týmy mohou pomocí panelu Kanban sledovat průběh plnění požadavků a pomocí panelu úkolů sprintu sledovat průběh plnění úkolů.Přetažení položek do sloupce nového stavu aktualizuje pole Stav a Důvod pracovního postupu.

Můžete přizpůsobit panel Kanban pro podporu dalších drah procesu nebo sloupců.Nebo můžete přizpůsobit pracovní postup pro požadavky a WIT úkolu, což změní výchozí záhlaví sloupců.

Typický průběh pracovního postupu při požadavku:

• Vlastník produktu vytvoří požadavek ve stavu Navrhované s výchozím důvodem Nový požadavek.

• Vlastník produktu aktualizuje stav na Aktivní, když začnou práce na jeho implementaci.

• Tým aktualizuje stav na Vyřešeno při dokončení vývoj kódu a systém testy úspěšně dokončeny.

• Nakonec vlastník týmu nebo produktu přesune požadavek do stavu Uzavřeno, když vlastník produktu souhlasí, že byl implementován v souladu se všemi akceptačními kritérii a prošel všemi ověřovacími testy.

Mapování požadavků na funkce

Při správě sady produktů nebo zkušeností uživatele můžete chtít zobrazit rozsah a průběh práce v celém portfoliu produktů.To lze provést definováním funkcí a mapováním požadavků na funkce.

Na stránce Nevyřízené položky funkce můžete rychle přidat funkce stejně, jako jste přidali požadavky.

Pracovní položka funkce obsahuje podobná pole, jaká jsou poskytována pro požadavky, a zahrnuje další pole popsaná v následující tabulce.

Karta Požadavky obsahuje odkazy na mapované požadavky.

Pole	Použití
Obchodní hodnota	Zadejte číslo, které zachycuje relativní hodnotu funkce ve srovnání s jinými funkcemi.Čím vyšší číslo, čím větší obchodní hodnotu.
Cílové datum	Zadejte datum, kdy by měla být funkce zavedena.

Ze stránky nevyřízených položek se zapnutou funkcí Mapování můžete přetáhnout požadavky na funkci, kterou implementují.

Toto mapování vytvoří nadřízené a podřízené odkazy z funkce na požadavky, které jsou zachyceny na kartě Požadavky.

Pomocí nevyřízených položek portfolia můžete přecházet z jedné nevyřízené položky na jinou a zobrazit požadovanou úroveň podrobností.Když nastavíte hierarchii týmů, můžete nevyřízené položky portfolia použít také k zobrazení souhrnu probíhající práce v několika týmech.

Definování úkolů potřebných k implementaci požadavků a sledování kapacity týmu a pracovního tempa

Pokud váš tým spravuje svou práci v řadě iterací, může použít stránku nevyřízených položek sprintu k rozpisu práce, která musí být splněna, do různých úkolů.

Pojmenujte úkol a odhadněte práci, kterou potřebuje.

Když týmy odhadují práci, znamená to, že definují úkoly a odhadnou hodiny nebo dny potřebné pro jejich dokončení.Týmy předvídají práci a definují úkoly na začátku každé iterace a každý člen týmu provádí dílčí úkoly.Úkoly mohou zahrnovat vývoj, testování a jiné druhy práce.Například vývojář může definovat úkol pro implementaci požadavků a tester může definovat úkoly pro zápis a spouštění testovacích případů.Propojením úkolů s požadavky a chybami lze vidět pokrok dosažený u těchto položek.Další informace naleznete v tématu Aktivity iterací.

Pole	Použití
Typ úkolu (viz poznámka 1)	Z povolených hodnot vyberte typ úkolu, který chcete implementovat: Nápravné opatření Zmírňující opatření Plánováno
Disciplína (1)	Vyberte disciplínu, kterou tento úkol představuje, když tým odhaduje kapacitu sprintu podle aktivity. Analýza Vývoj Test Vzdělávání uživatelů Zkušenosti uživatele Toto pole se používá také k výpočtu kapacity podle disciplíny.Je přiřazeno k parametru type="Activity" v souboru ProcessConfiguration.(2) Další informace naleznete v tématu Implementace úkolů vývoje.
Původní odhad (3)	Odhadované množství práce potřebné k dokončení úkolu.Toto pole se obvykle po přiřazení nezmění.
Zbývající práce (3)	Určete, kolik hodin nebo dnů práce zůstává k dokončení úkolu.Jak práce postupuje, aktualizujte toto pole.Používá se k výpočtu grafů kapacity, grafu úbytku práce sprintu a sestavy Sestava Úbytek práce a pracovní tempo. Pokud rozdělíte úkol na dílčí úkoly, zadejte hodiny pouze pro dílčí úkoly.Práci můžete určit v libovolné jednotce měření, kterou váš tým zvolí.
Dokončená práce (3)	Množství práce, které bylo vynaloženo na implementaci úkolu.

Poznámky:

1. Chcete-li změnit výběr nabídky, naleznete v části seznam výběr přizpůsobit.

2. Další informace o změně přiřazení pole naleznete v tématu Konfigurace a přizpůsobení nástrojů pro agilní plánování pro týmový projekt.

3. Můžete určit práci v hodinách nebo ve dnech.Neexistují žádné vlastní časové jednotky spojené s tímto polem.

   Použijete-li aplikaci Microsoft Project pro přiřazení prostředků a sledování plánu, můžete aktualizovat pole pomocí aplikace Project.

Sledování průběhu testu v uživatelských scénářích a zachycení vad kódu

Požadavky na test

Z nástroje Test Manager nebo TWA můžete vytvořit testovací případy, které se automaticky propojí s požadavkem nebo chybou.

Testovací případ obsahuje několik polí, z nichž mnohá jsou automatizovaná a integrovaná s nástrojem Test Manager a procesem sestavení.Popis každého pole naleznete v části Referenční dokumentace polí pro integraci sestavení a testů.

Na kartě Testované požadavky se zobrazují všechny požadavky a chyby v testovacím případu.Pomocí propojení může tým sledovat pokrok dosažený při testování každé položky a podporovat informace, které se zobrazí v sestavě Sestava Přehled požadavků (CMMI).

Sledování vad kódu

Můžete vytvořit chyby z aplikace TWA, Visual Studio nebo při testování pomocí nástroje Test Manager.Další informace naleznete v tématu Sledování chyb.

Pole/karta	Použití
Hlavní příčinu	Vyberte příčinu chyby z povolených hodnot: Chyba kódování Chyba návrhu Chyba specifikace Chyba komunikace Neznámé Chcete-li změnit výběr nabídky, naleznete v části seznam výběr přizpůsobit.
Kroky pro reprodukci	Zaznamenejte dostatek informací, aby ostatní členové týmu pochopili celkový dopad problému, a rovněž zaznamenejte, zda došlo k nápravě chyby.Jedná se o opatření přijatá k vyhledání nebo reprodukci chyby a očekávaného chování. Popis kritérií, která by měl tým použít k ověření, zda je závadný kód opraven.
Závažnost	Vyberte jednu z povolených hodnot, které představují subjektivní hodnocení vlivu chyby na projekt: 1 – Kritická 2 – Vysoká 3 – Střední 4 – Nízká Chcete-li změnit výběr nabídky, naleznete v části seznam výběr přizpůsobit.
Systémové informace Nalezeno v sestavení Integrovaná v sestavení	Když nástroj Test Manager vytvoří chyby, automaticky zaplní pole Systémové informace a Nalezeno v sestavení informacemi o softwarovém prostředí a sestavení, kde došlo chybě.Další informace o definování softwarová prostředí, naleznete v části Nastavení testovacích počítačů pro zpracování testů nebo shromažďování dat. Jakmile vyřešíte chybu, použijte možnost Integrováno v sestavení k zadání názvu sestavení, jež zahrnuje kód, který chybu opraví. Chcete-li získat přístup k rozevírací nabídky všechny sestavení, která byla provedena, můžete aktualizovat FIELD definice pro nalezené v sestavení a integrované v sestavení odkazuje na globální seznam.Globální seznam je automaticky aktualizováno každé sestavení, která se spouští.Další informace naleznete v tématu Pole na podporu integrace s testováním, sestavováním a správou verzí. Informace o tom, jak definovat názvy sestavení naleznete v tématu Zadávání smysluplných názvů pro dokončená sestavení s použitím čísel sestavení.

Sledování žádostí o změnu, rizik, problémů a poznámek, které jsou zaznamenány na revizních zasedáních

S následujícími WIT mohou týmy sledovat informace doporučené procesem CMMI.

• Vytvořte žádost o změnu vždy, když se navrhuje změna pracovního produktu, který je součástí řízení změn.Další informace o používání naleznete v tématech Řízení změn a Referenční dokumentace polí žádosti o změnu.

  

  Na kartě Analýza zadejte podrobnosti dopadu, který bude mít žádost o změnu na architekturu, zkušenosti uživatele, test, návrh/vývoj nebo technické publikace.

• Vytvořte problém pro sledování události nebo situace, která může blokovat práci nebo blokuje práci na produktu.Problémy se liší od rizik tím, že týmy identifikují problémy samovolně, obvykle během každodenních schůzek týmu.

  

  Další informace naleznete v tématech Řízení problémů a Referenční dokumentace polí chyb, problémů a rizik (CMMI).

• Vytvořte riziko pro sledování události nebo situace, která může blokovat práci nebo blokuje práci na produktu.Problémy se liší od rizik tím, že týmy identifikují problémy samovolně, obvykle během každodenních schůzek týmu.

  

  Další informace naleznete v tématech Řízení rizik a Referenční dokumentace polí chyb, problémů a rizik (CMMI).

• Vytvořte revizi pro dokumentaci výsledků návrhu nebo přezkoumání kódu.Členové týmu mohou zachytit podrobnosti toho, jak návrh nebo kód splňuje standardy v oblasti správnosti názvu, relevance kódu, rozšiřitelnosti, složitosti kódu, složitosti algoritmu a zabezpečení kódu.

  

  Další informace naleznete v tématech Implementace úkolů vývoje a Referenční dokumentace polí revizního zasedání (CMMI).

Definování společných polí a karet pracovní položky

Ve většině formulářů pracovních položek se zobrazí následující pole a karty.Každá karta se používá ke sledování určité informace, jako např. Historie, Odkazy nebo Přílohy.Tato tři pole obsahují historii změn, zobrazení propojených pracovních položek a možnost zobrazení a připojení souborů.

Jediné povinné pole je Název.Při uložení pracovní položky jí systém přiřadí jedinečné ID.

Pole/karta	Použití
Název (povinné)	Zadejte popis obsahující nejvýše 255 znaků.Název lze vždy později upravit.
Přiřazeno	Přiřaďte pracovní položku členovi týmu, který je odpovědný za provedení práce.V závislosti na kontextu, ve kterém pracujete, zobrazuje rozevírací nabídka pouze členy týmu nebo přispěvatele do týmového projektu.
Stav	Použijte nejprve výchozí hodnotu.Jak práce postupuje, aktualizujte ji, aby odrážela aktuální stav. Postup změny rozevíracího seznamu stavů naleznete v tématu Změna pracovního postupu pro typ pracovní položky.
Důvod	Použijte nejprve výchozí.Aktualizujte při změně stavu.Každému stavu je přiřazen výchozí důvod. Postup změny rozevíracího seznamu důvodů naleznete v tématu Změna pracovního postupu pro typ pracovní položky.
Oblast	Zvolte cestu oblasti přidruženou k produktu nebo týmu, nebo pole ponechte prázdné, dokud nebude přiřazeno během plánování schůzky. Postup změny rozevíracího seznamu oblastí naleznete v tématu Přidání a změna cest oblastí a iterací.
Iterace	Zvolte sprint nebo iteraci, ve které má být práce dokončena, nebo pole ponechte prázdné a přiřaďte je později během plánovací schůzky. Postup změny rozevíracího seznamu iterací naleznete v tématu Přidání a změna cest oblastí a iterací.
Všechny odkazy	Přidejte všechny typy vazeb, jako jsou hypertextové odkazy, sady změn, zdrojové soubory a další. Tato karta obsahuje také všechny odkazy, které jsou definovány pro pracovní položku, i ty definované na jiných kartách ovládacích prvků odkazů.
Přílohy	Sdílejte podrobnější informace přidáním souborů k pracovní položce, jako jsou vlákna e-mailů, dokumenty, obrázky, soubory protokolu nebo jiné typy souborů.
Historie	Zkontrolujte záznam pro audit, který systém ukládá, a shromážděte další informace. Pokaždé, když je pracovní položka aktualizována, informace se zapíší do historie.Historie obsahuje datum změny, autora změny a seznam polí, která byla změněna.Do pole historie lze přidat také formátovaný text.

Vyhledání informací o jiných polích, viz téma Index polí pracovních položek.

Spustit sledování práce

Před zahájením sledování práce, musí mít týmový projekt.Přejít zde ji vytvořit.

Chcete-li spustit sledování práce, proveďte jednu nebo více z následujících možností:

• Seznamte se s běžné úkoly pracovní položka, podívejte se na téma Začínáme používat pracovní položky.

• Chcete-li vytvořit nevyřízené položky, použijte TWA.Další informace naleznete v tématu Vytvoření backlogu.

• Chcete-li vytvořit struktury rozdělení práce, použijte projektu nebo aplikace Excel.

• Další informace o jaké klienta k použití naleznete v tématu Výběr klienta Team Foundation pro podporu vašich úkolů.

Dotazy a odpovědi

O: jaký pracovního postupu je uvedeno, nemá CMMI podpory?

O: tyto diagramy zobrazit hlavní průběh a regresní stavů funkce, požadavku, chyb a úkolů.Chcete-li přizpůsobit pracovního postupu, přejděte zde.

Funkce

Požadavek

Chyba

Úloha

D: jak vyřešte chybu jako duplicitní?

O: nastavení stavu odebrané a zadejte důvod jako duplicitní.

O: jak propojit existující chyby z Test Runner?

O: naleznete v části aktualizovat existující chybu při použití Test Runner.