Zarządzanie projektem
Możesz użyć sekcji Zarządzanie projektem MSF dla wskazówek dotyczących poprawy procesów CMMI, aby lepiej zrozumieć sposób zarządzania, planowania i koordynacji tworzenia i konserwacji produktów oprogramowania.Aby uzyskać więcej informacji o bibliotece CMMI, zobacz Podstawy CMMI.
Grupowanie Zarządzania projektami dla obszarów procesu w CMMI obejmuje Planowanie projektów, Monitorowanie i kontrolę projektów, Zarządzanie Umowami z dostawcami, Zintegrowane zarządzanie projektem, Zarządzanie ryzykiem oraz Ilościowe zarządzanie projektem.Wszystkie z wyjątkiem ilościowego zarządzania projektami są częścią poziomów 2 lub 3 modelu.Ilościowe zarządzanie projektem jest działaniem poziomu 4 modelu, które odzwierciedla w jaki sposób organizacje o wysokiej dojrzałości używają danych obiektywnych, ilościowych, statystycznie do obronienia, do podejmowania decyzji związanych z zarządzaniem oraz kierowania projektów ku pomyślnemu i przewidywalnemu wynikowi.
Działania związane z zarządzaniem projektem stanowią koszty ekonomiczne dla działań inżynieryjnych stanowiących wartość dodaną.Działania te są konieczne i ważne dla zarządzania ryzykiem, koordynacji pomyślnych działań inżynieryjnych, i odpowiedniego ustawiania oczekiwań klientów.Jednakże należy zminimalizować nakład pracy, który jest wydatkowany na te działania. "Małe i często" to dobra mantra.Kilka mniejszych porcji zmniejsza koszty złożoności i koordynacji.Po zdefiniowaniu i dostosowaniu definicji procesu, powinieneś pamiętać, że działania związane z zarządzaniem projektem powinny być możliwie jak najmniejsze, przy jednoczesnym spełnianiu profilu ryzyka Twojego projektu.
Iteracyjne projektowanie
Team Foundation wraz z szablonem procesu MSF dla CMMI obsługuje prace dla iteracji.Iteracyjne projektowanie zarządza ryzykiem poprzez dostarczanie demonstrowalnego i przetestowanego oprogramowania w ustalonych odstępach czasu przez cały projekt.
Harmonogram projektu jest podzielony na szereg iteracji, które zazwyczaj trwają od czterech do sześciu tygodni.Każda iteracja kończy się pokazem użytecznego, przetestowanego oprogramowania.Aby zaplanować sprinty, przejdź tu.
Plan projektu określa, jakie wymagania będą rozwijane w każdej iteracji.Plan projektu jest opracowany w Iteracji 0 i poddawany przeglądowi na początku każdej iteracji.Aby utworzyć i wyświetlić planu projektu, zobacz Utwórz zaległość.
Każdy plan iteracji wskazuje, jakie zadania będą wykonywane podczas tej iteracji.Większość zadań to prace rozwojowe i testowe, które są potrzebne do spełnienia wymagań dotyczących funkcji, które są planowane dla tej iteracji.Plan iteracji może być oglądany przez stronę zaległości sprintu.
Iteracyjna praca nie zarządza automatycznie ryzykiem.Aby zminimalizować ryzyko, musisz przyrostowo rozmieścić planu projektu.Wczesne iteracje powinny dostarczyć „end-to-end thin slice”, czyli minimalną wersję najważniejszych zachowań produktu.Późniejsze iteracje dodają więcej funkcji.
Z drugiej strony znacznie mniej przydatne byłoby planowanie wszystkich zakupów w witrynie sieci Web w pierwszej z trzech części projektu, wszystkich systemów magazynowych w drugim z trzech, a wszystkich systemów płatności w ostatniej trzeciej fazie.Ten harmonogram ryzykowałby produkcję atrakcyjnej i dobrze się sprzedającej witryny sieci Web, która nie umożliwia firmie pobierania pieniędzy od klientów.Byłby iteracyjny, nie będąc przyrostowym.
Przyrostowe programowanie ma następujące zalety:
Spełnia wymagania dla wartości true.Zainteresowane strony mają możliwość wypróbowania produktu, co zawsze powoduje ulepszenia podanych wymagań.
Dostraja architekturę.Pozwala zespołowi opracowującemu odkryć i rozwiązać wszelkie trudności, które występują w ich platformie lub w związku z potencjalnymi ulepszeniami w zakresie ich konstrukcji.
Zapewnia wyniki.Zainteresowane strony wiedzą, że nawet jeśli zasoby projektu zostaną obcięte w trakcie, wydatków do tej pory poniesione nie zostały zmarnowane.To samo jest prawdą, jeśli oszacowania rozwoju okażą się być optymistyczne i zajdzie konieczność rezygnacji z mniej ważnych funkcji.
Aby uzyskać więcej informacji dotyczących sposobu wyrażania wymagań w formie właściwej dla tworzenia przyrostowego, zobacz Opracowywanie wymagań.
Większe i mniejsze cykle
Projekt i iteracja nie są jedynymi cyklicznymi aspektami opracowywania oprogramowania.Na przykład w iteracji członkowie zespołu uruchamiają i wykonują zadania oraz ewidencjonują kod.System kompilacji tworzy produkt w trybie ciągłym lub w godzinach nocnych.Cały zespół prowadzi codzienny krótki przegląd postępów zadań iteracji.
Duże projekty
Projekt, w którym pracuje zespół w kolejnych seriach iteracji, może być częścią większego projektu lub programu.Duży projekt ma kilka równolegle pracujących zespołów.Każdy zespół ma zwykle 4 do 16 osób.
Otwórz oddzielną gałąź kontroli wersji dla każdego zespołu.Każdy zespół należy zintegrować z główną gałęzią na końcu każdej iteracji.Aby uzyskać więcej informacji, zobacz Używaj odgałęzień, aby izolować ryzyko w kontroli wersji Team Foundation.
Zarezerwuj główną gałąź do integracji i testów.Maszyna kompilacji powinna wykonać cały zestaw testów po integracji.
Do każdego zespołu należy przypisać obszar, dzięki czemu jego elementy robocze mogą być łatwo oddzielone od innych.Aby uzyskać więcej informacji, zobacz Dodawanie i modyfikowanie obszaru i ścieżek iteracji.
Zespoły mogą udostępniać serię integracji, ale nie zawsze jest to konieczne.Jeśli zespoły nie synchronizują integracji, każdy zespół musi mieć swój własny prefiks dla swoich nazw iteracji.
W tej sekcji
Cykl projektu: Rozpocznij projekt, zgromadź wymagania, utwórz planu projektu, podziel go na iteracje i dostarcz wydania.Zarządzanie ryzykiem i zarządzanie zmianami w planie. |
|
Cykl iteracji: Przegląd i aktualizacja wymagań, planowanie zadań w celu implementacji wymagań i zarządzanie problemami, w chwili gdy wystąpią. |