Udostępnij za pośrednictwem


Iteracje

W MSF dla poprawy procesu CMMI należy zaplanować projekt jako szereg iteracji.Każda iteracja ma zazwyczaj długość czterech do sześciu tygodni i w tym czasie zespól rozwojowy realizuje określony zestaw wymogów.

Na początku iteracji

Planowanie iteracji odbywa się w czasie rozpoczęcia każdej iteracji lub przed nim.Obejmuje następujące zadania:

  • Przegląd wymagań, które są przypisane do iteracji i zdefiniowane bardziej szczegółowo.

  • Utwórz elementy robocze zadań dla prac, które należy wykonać, aby zaimplementować i przetestować każde wymaganie.Łączy zadania z elementem roboczym wymagań przy użyciu typu łącza nadrzędnego.

  • Ustaw pole Pierwotna wartość szacunkowa każdego zadania.Podziel zadania, których długość oszacowano na więcej niż kilka dni.

  • Porównaj oszacowania z czasem, który jest dostępny dla iteracji.Jeśli całkowite szacowanie jest zbyt długie, uprość niektóre wymagania lub odrocz je do późniejszej iteracji.

Aby uzyskać więcej informacji, zobacz Planowanie iteracji (CMMI).

Podczas iteracji

Wykonanie zadania.

Członkowie zespołu rozpoczynają i kończą zadania, rejestrując te zadania w elementach roboczych.Zakończenie zadania może obejmować sprawdzenie w kodzie programu i innych artefaktach.Każde zadanie powinno trwać nie dłużej niż kilka dni; bardziej złożone zadania są dzielone podczas planowania iteracji.Aby uzyskać więcej informacji, zobacz Zapisać nowy kod dla wątku użytkownika.

Jeśli członek zespołu napotyka jakąś przeszkodę w pracy, której nie można rozwiązać natychmiast, powinien zarejestrować element roboczy problemu.

Testy

Należy opracować ręczne lub automatyczne testy, a przypadki testowe powinny być powiązane z wymaganiami produktu.Zapotrzebowania na produkt nie można uznać za zakończone aż do momentu przyłączenia elementu roboczego do przypadków testowych, które biegną i pokazują, że działają.

Prace rozwojowe dla badań powinny zostać włączone do zadań, które są połączone z wymaganiem produktu.

Kompilacje zwijane i nocne

Kompilacja systemu kompiluje produkt z niedawno zaewidencjonowanych aktualizacji produktu i uruchamia automatyczne testy.Można ustawić podstawowe testów do uruchomienia w sposób ciągły i ustawić pełny pakiet do uruchomienia każdej nocy.Praktyka ta pomaga zapewnić, że wielokrotne skoki nie tworzą nagromadzenia błędów.Aby uzyskać więcej informacji, zobacz Konfigurowanie systemu kompilacji oraz zarządzanie nim.

Spotkanie stand-up

Cały zespół prowadzi codzienne krótki przegląd postępów zadań iteracji.Członkowie zespołu mogą korzystać z tablicy zadań lub projektu Postępu pulpitu nawigacyjnego na ścianie, dzielić go przy użyciu programu Office Live Meeting lub obu.

  • Każdy członek zespołu krótko przestawia ostatnie postępy, pracę w danym dniu i wszelkie problemy związane z blokowaniem.

  • Menedżer projektu lub lider zespołu sprawozdania na temat postępów w rozwiązaniu problemów.Aby uzyskać więcej informacji, zobacz Kwestie związane z zarządzaniem (CMMI).

  • Liczba błędów jest rozpatrywana.Błędy powinny mieć pierwszeństwo nad nowymi wdrożeniami.Staraj się zachować niską liczbę błędów w całym projekcie.Jeśli zwiększa się liczba błędów, należy omówić przyczyny i możliwy wpływ na rozwój.

  • Rozpatrywana jest ocena wydajności.

Zakres korekt

Wykres postępu może wskazywać, że zadania nie zostaną zakończone przed końcem iteracji.W takim przypadku menedżer projektu lub lider zespołu inicjuje dyskusję na temat sposobu uproszczenia wymagań, aby zadania można było obciąć.Aby uzyskać więcej informacji, zobacz Raport dotyczący wypalenia i szybkości spalania.

Zostaną dopasowane wymagania i odpowiednie badania.Nowa funkcja wymagań jest umieszczana na planie projektu dla brakującej funkcji.W przeglądzie planu projektu, które odbywa się pod koniec iteracji, funkcja mogą być przypisane do przyszłych iteracji lub wycięte.

Żądania zmiany i ryzyka nie są uwzględniane podczas iteracji.

Klasyfikacja

Aby przejrzeć błędy, niektórzy członkowie zespołu (zwykle nie cały zespół) spotykają się regularnie.Każdy element członkowski zespołu musi zarejestrować błąd, gdy odkryje wadę.Zarejestrowany błąd zaczyna działać w Stanie zaproponowanym, a celem spotkania dotyczącego alokacji środków zgodnie z potrzebami jest podjęcie decyzji, czy to naprawić, odłożyć do późniejszej iteracji lub czy odrzucić.

Aby uzyskać więcej informacji, zobacz Śledzenie błędów.

Na końcu iteracji

Weryfikacja

Wymagania są uważane za ukończone tylko wtedy, gdy skojarzone testy zostały zakończone pomyślnie.Aby uzyskać więcej informacji, zobacz Weryfikowanie wymagań.

Retrospektywy

Ulepszanie procesów jest ważnym celem CMMI.

Retrospektywna iteracja odzwierciedla to, co poszło dobrze lub źle w iteracji, i rozważa ulepszenia procesów i narzędzi, które są używane przez zespół.Znacząca ilość materiału o retrospektywach jest dostępna w sieci Web.

Członkowie zespołu powinni unikać szukania winnych niepowodzeń.Spróbuj usprawniania procesu, tak aby błędy popełniane przez jednostki miały mniejsze znaczenie.

Po wprowadzeniu zmian w procesie upewnij się, że zespół zgadza się na następujące decyzje:

  • Skąd będzie wiadomo, że nastąpiła poprawa.

  • Kiedy wprowadzisz tę ocenę.

  • Co zrobisz.

Integracja

Jeśli ten projekt jest częścią większego programu, każdy zespół wykonuje swoją pracę w gałęzi systemu kontroli wersji.Oddział główny jest zarezerwowany dla integracji pracy zespołu.Na końcu iteracji zespół może wykonywać integrację z głównej gałęzi.Aby uzyskać więcej informacji, zobacz Używaj odgałęzień, aby izolować ryzyko w kontroli wersji Team Foundation.

Integracja składa się z dwóch kroków:

  • Integracja do przodu w celu połączenia nowszego kodu z głównej gałęzi z gałęzią lokalnego projektu.Po przeprowadzeniu scalania automatyczne i ręczne testy są uruchamiane.Spowoduje to utworzenie pewnej wady.Wady są ustalone na poziomie wysokiego priorytetu.

  • Integracja odwrotna.Kod lokalnego oddziału jest scalony w głównej gałęzi i kompilacja oraz pełen pakiet testu są uruchomione na głównej gałęzi.Zmiany zostały cofnięte, jeśli wystąpią błędy.Wprowadzenie błędów do głównej gałęzi jest źle widziane.Jeśli nie pojawiają się błędy, integracja jest zadeklarowana jako ukończona.

Firma Microsoft zaleca przeprowadzenie integracji na końcu każdej iteracji.Jeśli to opóźnisz, lista błędów do naprawienia po integracji do przodu jest dłuższa.Jeśli naprawienie błędów zajmuje dużo czasu, główna gałąź będzie miała nowy materiał i trzeba będzie wykonać inną integrację do przodu.

Przygotowywanie do następnej iteracji

W kierunku lub na końcu iteracji jest wykonywanych kilka działań związanych z zarządzaniem projektem.Obejmują one recenzowanie ryzyka i dokonanie przeglądu planu w odniesieniu do wniosków o zmianę i oszacowanie zmienionego rozwoju.

Aby uzyskać więcej informacji, zobacz Działania w projekcie.