Planowanie projektu (CMMI)
Oczekiwanym wynikiem planowania projektu jest plan, który zawiera zakres, harmonogram, budżet, planu zarządzania ryzykiem i zobowiązania i zatwierdzenie od wszystkich zainteresowanych stron.Z planu projektu uzgodnionego chcesz przejść do analizy, projektowania, rozwoju, badania i ostatecznej dostawy.
Można zmniejszyć ryzyko przy użyciu metody iteracyjne projektowania.Iteracje umożliwiają przedstawienie częściowo działającego produkt na koniec każdej iteracji i działanie na informacji zwrotnej każdej demonstracji.Dlatego plan zawiera ogólny kształt i jest przedmiotem przeglądu i uszczegółowienie przed rozpoczęciem każdej iteracji.
Zbieranie i modelowania wymagań
Ta działalność dotyczy dyskusji na temat tego, co system powinien zrobić, z potencjalnymi użytkownikami biznesowymi oraz ekspertami merytorycznymi.Ważne jest, aby zrozumieć kontekst biznesowy.Jeśli zostałeś poproszony o napisanie aplikacji dla funkcjonariuszy policji, pomaga to zrozumieć żargon, procedury i reguły.
Modele UML są użytecznym narzędziem do wyrażania i planowania złożonych relacji.Można rysować je w Visual Studio i połączyć je do innych dokumentów i do Team Foundation elementów roboczych.Aby uzyskać więcej informacji, zobacz Modelowanie — Wymagania dla użytkownika.
Aktualizowanie i poprawianie modelu wymagań w czasie trwania całego projektu.Gdy zbliża się iteracja, dodaj więcej szczegółów do aspektów modelu, które są istotne dla tej iteracji.Z modelu można czerpać testy weryfikacyjne.
Aby uzyskać więcej informacji, zobacz Opracowywanie wymagań i Tworzenie testów z modelu.
Tworzenie przyrostowych wymagań produktu
Wymagania jakie zostały zebrane od klientów nie są bezpośrednio właściwe do celów planowania rozwoju przyrostowego.Na przykład, aby wyjaśnić procedurę, gdy użytkownik kupi coś z witryny sieci Web, można napisać szczegółową serię kroków: klient przegląda katalog, dodaje element do koszyka, potwierdza zawartość koszyka, dostarcza adres i płaci; magazyn planuje dostawę; i tak dalej.Następujące kroki lub diagram aktywności równoważnej nie są wymagania przyrostowo.
Zamiast tego, pierwszy przyrost systemu może oferować tylko jeden przedmiot do sprzedaży, dostarczyć tylko jeden adres i wykonywać tylko transakcję testową z usługą płatności.Druga wartość przyrostu może stanowić wykaz, który składa się z prostej listy.Późniejsze przyrosty mogą dodać opcję pakowania ozdobnego zakupu lub opcję prośby o katalogi, które są dostarczane przez różnych dostawców.Niektóre skoki mogą dotyczyć jakości usług, takich jak zdolność do obsługi 1000 klientów, zamiast tylko jednego.
Innymi słowy, wczesne przyrosty powinny wykonywać główne przypadki użycia „od końca do końca” i stopniowo dodawać funkcje.
Jeśli pracujesz z istniejącym produktem, zasada jest taka sama, ale zaczynasz od istniejącej funkcji.Jeśli nie jesteś zaznajomiony z jego wewnętrzną konstrukcją, koszt aktualizacji może być trudny do oszacowania.Warto liberalnie podchodzić do prognoz dla wcześniejszych zmian.
Aby uzyskać więcej informacji, zobacz Opracowywanie wymagań.
Wprowadzanie i edytowanie wymagań produktu
Zarejestruj wymogi dotyczące produktów pierwotnych jako wymagania elementów roboczych w Team Foundation i wpisz typ wymagania jako Funkcja.Można utworzyć zaległości wymagania za pomocą TWA lub Team Explorer.Jeśli posiadasz kilka elementów roboczych, które chcesz utworzyć w tym samym czasie, można użyć programu Excel.
Szacowanie wymagań produktów
Zespół opracowujący powinien oszacować czynności, które są wymagane do rozwoju każdego zapotrzebowania na produkt.Szacowanie stosuje się w godzinach, w polu Oryginalnego Oszacowania elementu roboczego.
Na początku projektu, przybliżone oszacowanie jest wszystkim, co potrzeba.
Złam duże wymagania produktu na mniejsze.Najlepiej, jeśli każde zapotrzebowanie na produkt zajmie tylko kilka dni czasu projektowania.
Przypisywanie wymagań produktu do iteracji
Przedstawiciele zainteresowanych stron biznesowych i deweloperów powinni współpracować przy przypisaniu wymogów produktu do iteracji.Zazwyczaj można to zrobić w spotkaniu, gdzie dzielisz lub tworzysz projekt Office Excel widoku zapytania wymagań produktu.
Przypisanie jest wykonywane przy użyciu następujących rodzajów informacji:
Priorytet wymagania.Zobacz uwagi w następującej podsekcji.
Szacowany koszt.Biorąc pod uwagę liczbę członków zespołu i długość iteracji, każda iteracja ma tylko określoną liczbę godzin, które są dostępne dla rozwoju.Ponadto znaczna liczba tych godzin zostanie wykorzystana do planowania iteracji i innych zadań, które nie dotyczą bezpośrednio rozwoju.
Zależności między wymaganiami produktu.W przypadku przyrostowych serii wymagań, najprostsze wymagania muszą być rozwiązane przed ulepszeniami w tym samym obszarze.
Można zdefiniować wymaganie w elemencie roboczym, określając różne informacje, tak jak pokazują następujące ilustracje:
.png "Formularza elementu pracy wymagań")
Niektóre wytyczne dotyczące priorytetów
Istnieje wiele schematów szczegółowych dla priorytetyzacji.Będziemy sprawdzać niektóre z nich podczas rozważania planowania iteracji.Teraz na poziomie projektu zamieszczamy pewne wskazówki, które mogą być przydatne do zarządzania ryzykiem i optymalizowania wartości dodanej.
Ustaw priorytety minimalne scenariuszy end-to-end.
Staraj się osiągnąć prosty scenariusz „od końca do końca” tak wcześnie w projekcie, jak to możliwe.Później można dodać więcej funkcji do różnych części tego scenariusza.Daje to gwarancję, że podstawowe funkcje platformy i główne pomysły w wymaganiach są sprawdzane przed terminem.
Z drugiej strony, nie dziel harmonogramu według architektury.Harmonogram, który kończy bazę danych, następnie logika biznesowa, a następnie interfejs użytkownika prawdopodobnie będą wymagać dużo przeróbek, aby zintegrować części na końcu.W ten sam sposób, nie jest zalecany podział poziomy {składnik sprzedaży; składnik magazynu; składnik płatności}.Prawdopodobnie stworzyłby wspaniały system sprzedaży w sieci Web, ale zabrakło czasu na pozyskanie środków pieniężnych od swoich klientów.Pełne składniki mogą być planowane do późniejszych iteracji tylko wtedy, gdy są one naprawdę opcjonalnymi dodatkami.
Ustaw priorytet ryzyka technicznego.
Jeśli scenariusz zawiera technicznie ryzykowny element, opracuj go wcześnie w harmonogramie.Przyjmij podejście "wczesna porażka" do ryzyka.Jeśli czegoś nie da się osiągnąć, chcesz o tym wiedzieć na początku projektu, tak, aby móc to odwołać lub zastąpić alternatywnym podejściem.Tak więc priorytety technicznie ryzykownych wymagań na początku iteracji.
Ustaw priorytet zmniejszenia niepewności.
Zainteresowane strony biznesowe nie będą pewne niektórych wymagań.Trudno jest przewidzieć, które zachowanie produktu będzie najlepiej działać w kontekście działalności.Ustaw priorytet pracy, który może zmniejszyć niepewność.Często można to osiągnąć poprzez rozwój prostszej wersji scenariusza, z którym użytkownicy mogą eksperymentować.Wstrzymaj pełny scenariusz do późniejszej iteracji, w której należy uwzględnić wyniki tych doświadczeń.
Ustaw priorytet wartościowych wymagań.
Jeśli to możliwe spróbuj ustalić funkcję szansy opóźnienia kosztów dla każdego scenariusza.Te kształty służą do celów określenia wymogów, które mogą potencjalnie przynieść więcej korzyści dla klientów wcześniej.Ustaw priorytet tych wymagań do wcześniejszych iteracji.To może kupić opcję zwalnianie częściowego produktu wcześnie
Scenariusze grupy, które są wspólne dla wielu osób.
Jeśli posiadasz scenariusze, które mają narzędzie dla dwóch lub więcej osób, pogrupuj je razem.Ustaw ich pozycję według liczby motywów, które wymagają tego scenariusza.Ustaw priorytet scenariuszy, które dotyczą większej liczby motywów do początku iteracji.
Motywy rangi.
Motywy stanowią segmenty rynku lub grupy użytkowników.Osoby zajmujące się marketingiem lub właściciele firm powinny mieć możliwość sformułowania priorytetu takich segmentów lub grup w oparciu o narzędzie do dostarczenia lub wartość segmentu.Jeżeli segmenty lub grupy użytkowników można sklasyfikować według priorytetu, pokaż to poprzez listę osób dla każdego segmentu według stopnia.Określ scenariusze dla najwyższej rangi osób i określ ich priorytety we wcześniejszych iteracjach w harmonogramie.
Ogólnie rzecz biorąc chcemy określić priorytet redukcji ryzyka ze względu na możliwość uszkodzenia.Chcemy określić priorytet typowej funkcje, bo to może być wymagane i raczej nie ulegnie zmianie.Chcemy określić priorytet bardziej wartościowych wymagań.Chcemy włączyć opcję dla wcześniejszego zwolnienia produktu do podzbioru autorstwa przez klasyfikowanie wszystkich scenariuszy, które są wymagane do zaspokojenia potrzeb jakiegokolwiek autora.
Planowanie testów
Szacowany czas pracy dla każdego wymogu musi zawierać nakład, który jest wymagany do testowania wymogu, ręcznie lub przez tworzenie automatycznych testów.
Zanim zostanie uznany za zakończony, wymagania każdego produkt muszą być połączone z zestawem elementów roboczych przypadków testowych, które razem pokazują, czy zostały spełnione wymagania i badanie musi przejść.
Podczas tworzenia lub zmiany wymagań produktu, odpowiedni plan badań musi zostać zaktualizowany.
Zmiana wymogów dotyczących produktów
Przeglądanie tej aktywności przed każdą iteracją w celu przejrzenia nowych i poprawionych wymagań, skorygowania priorytetów i poprawienie oszacowań.Będzie kilka korekt w pierwszej iteracji.
Po kilku pierwszych iteracjach członkowie zespołu rozwoju będą bardziej pewni swoich oszacowań.Powinny przejść przez szacunki dla jednej lub dwóch iteracji i poprawić pola Oryginalnych Szacunków wymagań, które są przypisane do tych iteracji.