Sdílet prostřednictvím


Project management

Pomocí části Řízení projektu MSF pro doprovodné materiály vylepšování procesu CMMI můžete lépe pochopit, jak spravovat, plánovat a koordinovat vývoj a údržbu softwarových produktů. Další informace o knihovnách CMMI naleznete v tématu Background to CMMI.

Seskupení řízení projektových oblastí z oblasti CMMI zahrnuje plánování projektu, sledování a řízení projektu, správu dohody s dodavatelem, integrované řízení projektů, řízení rizik a kvantitativní řízení projektu. Vše kromě kvantitativního řízení projektů je součástí modelu úrovně 2 nebo 3. Kvantitativní řízení projektu je aktivita 4. úrovně modelu, která odráží, jak vysoce vyspělé organizace využívají kvantitativní, statisticky obranné a objektivní data pro rozhodování v rámci řízení a řízení projektů pro zajištění úspěšných a předvídatelných výsledků.

Aktivity správy projektu představují ekonomické náklady na inženýrské činnosti s přidanou hodnotou. Tyto činnosti jsou nezbytné a důležité ke správě rizik, koordinaci úsilí o úspěšné zpracování a odpovídajícím způsobem nastavit očekávání zákazníka. Měli byste však minimalizovat úsilí vynaložené na tyto aktivity. "Málo a často" je dobré heslo. Menší dávky snižují složitost a náklady na koordinaci. Při definování a přizpůsobení definice procesu vezměte v úvahu, že aktivity správy projektu by měly být co nejmenší a současně odpovídaly profilu rizika v projektu.

Iterativní vývoj

Team Foundation spolu s šablonou procesu MSF pro CMMI podporuje iterativní práci. Iterativní vývoj řídí rizika poskytováním prokazatelného a testovaného softwaru v nastavených intervalech během celého projektu.

Successive iterations

Plán projektu je uspořádán do řady iterací, které jsou obvykle dlouhé čtyř až šesti týdnů. Každá iterace končí ukázkou použitelnosti testovaného softwaru. Chcete-li naplánovat sprinty, přejděte sem.

  • Plánu projektu uvádí, jaké požadavky na funkce budou v každé iteraci rozvíjeny. Plán projektu je rozvíjen v iteraci 0 a přezkoumán na začátku každé iterace. Chcete-li vytvořit a zobrazit plán projektu, přečtěte si téma Vytvoření nevyřízených položek.

  • Každý plán iterace uvádí, jaké úkoly budou provedeny během dané iterace. Většina úkolů jsou vývoj a testovací práce, které jsou zapotřebí pro splnění požadavků funkce, která je plánována pro danou iteraci. Plán iterace lze zobrazit pomocí stránky s nevyřízenými položkami sprintu.

Iterační práce neumožňuje automaticky řídit rizika. Pro minimalizaci rizika je nutné uspořádat plán projektu v přírůstcích. Počáteční iterace by měly poskytnout "úplný tenký řez". To znamená minimální verzi nejdůležitějšího chování produktu. Další iterace přidávají více funkcí.

Naopak by bylo mnohem méně užitečné naplánovat všechny prodejní části nákupního webu pro první třetinu projektu, veškerý skladový systém pro druhou třetinu, a veškerý platební systém v poslední třetině. Tento plán by mohl riskovat vytvoření atraktivního a bohatě vybaveného webu, který nemá žádné prostředky pro podnik, jak získávat peníze od svých zákazníků. Je iterativní bez toho, aby byl přírůstkový.

Přírůstkový vývoj má následující výhody:

  • Splňuje požadavky na hodnotu true. Zúčastněné strany mají možnost vyzkoušet produkt, což vždy vede k zlepšení jejich stanovených požadavků.

  • Vyladí architekturu. Umožňuje vývojovému týmu zjišťovat a řešit případné potíže, ke kterým dochází s jejich platformu, nebo potenciálních zlepšení jejich návrhu.

  • Zajišťuje výsledky. Zúčastněné strany ví, že i v případě případného výpadku prostředků projektu nebyly prozatímní výlohy promarněny. Totéž platí, pokud byly odhady vývoje optimistické a je třeba uvolnit méně důležité funkce.

Další informace o tom, jak vyjádřit žádosti přípustnou formou pro přírůstkový vývoj, naleznete v tématu Develop requirements.

Větší a menší cykly

Projekt a iterace nejsou pouze cyklické aspekty vývoje softwaru. Například v iteraci členové týmu zahájí a dokončí úkoly a zkontrolují kód. Systém sestavení vytváří produkt na základě průběžné nebo noční práce. Tým obsahuje stručný denní přehled průběhu úkolů iterace.

Check-in, daily build, iteration, project, program

Ee461565.collapse_all(cs-cz,VS.140).gifVelké projekty

Projekt, ve kterém tým pracuje pomocí několika iterací, může být součástí většího projektu nebo programu. Velký projekt má několik týmů, které pracují paralelně. Každý tým má obvykle 4 až 16 osob.

Otevřete samostatnou verzi větve ovládacího prvku pro každý tým. Každý tým se musí integrovat s hlavní větví na konci každé iterace. Další informace naleznete v tématu Izolace rizik ve správě verzí Team Foundation pomocí větví.

Rezervujte hlavní větev pro integraci a testy. Počítače pro sestavení by měly po integraci provést úplnou sadu testů.

Oblast přiřadíte ke každému týmu, takže jeho pracovní položky lze snadno oddělit od ostatních. Další informace naleznete v tématu Add and modify area and iteration paths.

Týmy mohou sdílet řadu integrací, ale to není vždy nutné. Pokud týmy nesynchronizují integrace, každý tým musí mít vlastní předponu názvů pro své názvy iterací.

V této části

Cyklus projektu: Zahájení projektu, shromáždění požadavků, vytvoření plánu projektu, jeho rozdělení na iterace a doručení verzí. Řízení rizik a řízení změn v plánu.

Project activities

Iterační cyklus: Umožňuje zkontrolovat a aktualizovat požadavky, plánovat úkoly určené k implementaci požadavků a spravovat problémy jakmile nastanou.

Iteration activities

Viz také

Koncepty

Šablona procesů CMMI