Ten artykuł został przetłumaczony przez maszynę. Aby wyświetlić jego treść w języku angielskim, zaznacz pole wyboru Angielski. Możesz też wyświetlić angielski tekst w okienku wyskakującym, przesuwając wskaźnik myszy nad konkretny tekst”.
Tłumaczenie
Angielski
Zalecamy używanie programu Visual Studio 2017

Incepcja projektu

W fazie początkowej, o nazwie powstania projektu można zorganizować podstawowych zasobów projektu.

Na wczesnym etapie projektu należy zwołać kilka zainteresowanych osób i ekspertów merytorycznych do omówienia projektu i przygotowania plan produktu. Należy wybrać zainteresowane strony oparte na rodzaju i złożoności projektu i jego elemencie dostarczanego produktu.

W zależności od wielkości projektu i jego złożoności spotkania mogą trwać kilka dni lub tygodni.

Ważną technikę zarządzania ryzykiem jest planowanie projektu w iteracjach, zazwyczaj od czterech do sześciu tygodni. Plan iteracji jest listą funkcji, którą zespół projektu opracuje i przetestuje. Każda funkcja określa zadanie lub ulepszony wariant zadania, które użytkownik będzie mógł wykonywać przy użyciu produktu. Zaplanowane funkcje są wykazane pod koniec każdej iteracji. Na koniec niektórych iteracji, częściowo ukończony produkt zostaje dopuszczony do badania przez ograniczony zestaw użytkowników.

Informacje zwrotne z tych pokazów i prób są używane do przeglądu planu.

Plan produktu jest ustawiony tak, aby scenariusze głównego użytkownika oraz głównych składników systemu były realizowane na wczesnym etapie, nawet jeśli tylko w sposób uproszczony.

Jednym z najbardziej znaczących ryzyk w większości projektów są złe wymagania. Wymagania mogą być źle zrozumiane nie tylko przez zespół projektowy, ale także przez użytkowników końcowych i zainteresowane strony. Może być im przewidzieć wpływ działalności prowadzonej przez instalację nowego systemu.

Ponadto, kontekst biznesowy może się zmieniać w czasie trwania projektu, co prowadzi do zmiany wymagań produktu.

Proces iteracyjny stanowi gwarancję tego, że wszelkie dostosowania w wymaganiach zidentyfikowane poprzez zademonstrowanie produktu mogą być zamieszczone przed zakończeniem projektu, bez ponoszenia kosztów znacznej przeróbki.

Kolejnym istotnym ryzykiem są źle oszacowane koszty rozwoju. To może być trudne dla deweloperów, którzy pracują w nowym obszarze i być może na nowej platformie, aby rzetelnie oszacować koszt prac rozwojowych przed rozpoczęciem projektu. W niektórych przypadkach może być trudno określić, czy określona strategia implementacji będzie działać wystarczająco dobrze. Ale przez dokonanie przeglądu planu na końcu każdej iteracji, zespół może wziąć pod uwagę doświadczenie poprzednich iteracji. Jest to jeden z powodów dlaczego dobry plan produktu planuje jakąś pracę na każdym głównym składniku na wczesnym etapie.

Niektóre projekty wymagają tego, że wszystkie wymagania muszą działać przed dostawą. Te rodzaje projektów są niezwykłe w kontekście oprogramowania. Przykładem z życia wziętym może być budowa mostu. W połowie ukończony span jest bezużyteczny. Z drugiej strony, w połowie zakończony, ale właściwie zaplanowany projekt musi być możliwy do rozmieszczenia i wykorzystania przez ograniczoną grupę użytkowników. Można go następnie wypełniać stopniowo w ciągu kilku uaktualnień.

Najpierw ustal, czy projekt jest naprawdę oparty na zakresie. Jeśli tak jest, należy poczekać do określenia daty końcowej do momentu otrzymania szczegółowych szacunków i szczegółowego planu. Płacisz za to cenę. Planowanie napowietrzne zostało zwiększone i zaplanowane buforowanie jako plan awaryjny na wypadek niedokładnych szacunków bardziej przesunie datę dostawy co zwiększa koszty. Dlatego przed podjęciem decyzji, że projekt jest oparty na zakresie, należy być absolutnie pewnym. Jest to bardziej prawdopodobne w złożonym środowisku systemów inżynieryjnych niż w klarownej sytuacji dotyczącej oprogramowania lub usług.

Większość projektów oprogramowania jest opartych na dacie, ponieważ mogą one być dostarczane stopniowo. Na przykład, jeśli gra komputerowa ma zostać wydana w okresie świątecznym w Stanach Zjednoczonych, to musi być gotowa w październiku. Niedostarczenie w październiku poważnie wpłynie na sprzedaż między Halloween i Bożym Narodzeniem, a jeśli harmonogram przesunie się o dwa miesiące, okno możliwości może zostać utracone całkowicie.

Projekt należy obsadzić, aby móc go dostarczyć w żądanym terminie. Dane historyczne z ostatnich projektów powinny być wykorzystywane do informowania w trakcie dyskusji o wystarczających środkach.

Po zidentyfikowaniu wymagań pracowników, utwórz strukturę organizacyjną projektu, która jednoznacznie określa strukturę zespołu projektowego, poziomy personalne i rozmieszczenie geograficzne, w razie potrzeby. Zapisz wszystkie informacje kadrowe do portalu twojego projektu.

Opisz każdą rolę projektu i odpowiedzialność, i opublikuj je w planie projektu. Każda osoba, która dołącza do projektu powinna zrozumieć swoją rolę i obowiązki w projekcie.

Ważne jest określenie planu komunikacji dla projektu. Ścieżki komunikacji pomoc, zarządzanie kosztami koordynacji w projekcie. Ważne jest, aby zdefiniować, kto powinien uczestniczyć w spotkaniach, jak często odbywają się spotkania, ścieżki komunikacji oraz sposób eskalacji problemów, które nie mogą być rozwiązane przez zwykłych uczestników dowolnego spotkania.

Celem planu komunikacji jest, aby upewnić się, że koordynacji działań w projekcie działa możliwie bez zakłóceń i uniknąć nieużywanego nakładu poprzez nieporozumienia.

Plan komunikacji powinien być opublikowany na portalu projektu i utrzymany, jak jest to wymagane. Plan komunikacji jest użytecznym narzędziem dla wszystkich pracowników, szczególnie nowych członków. Pomaga im zrozumieć, jak działa większy zespół i jak to zrobić komunikując się odpowiednio na różne sposoby, z różnymi członkami zespołu i do różnych celów.

Określ wszystkie zainteresowane strony projektu. Oprócz podstawowych członków zespołu, wykaz powinien obejmować osoby podróżujące i pracowników technicznych, w których interesie leży udana realizacja projektu lub wpływ jaki produkt może mieć po wejściu w użytkowanie. Te zainteresowane strony mogą być poprzednim lub następnym ogniwem działania inżynierii oprogramowania.

Utwórz wersję szkicu pierwszego planu projektu, który można poddać przeglądowi po uruchomieniu rozwoju. Celem tej wersji jest pomoc w omówieniu zasobów i terminów ze sponsorami projektu. Powinien określać najważniejsze funkcje i szacowane daty dostawy. Aby uzyskać więcej informacji, zobacz Planowanie projektu (CMMI).

Publikowanie zarysu planu projektu na portalu projektu. Chociaż wiele pracy włożono w plan, nadal istnieje plan wysokiego poziomu, który odracza wiele szczegółowych decyzji planowania. Jest to intencjonalne. Zbyt wiele szczegółów teraz wygeneruje odpady później.

W przypadku, gdy wymagania są niepewne, planuj je tylko w konspekcie, a szczegóły powinny zostać odłożone do czasu, gdy dostępne jest więcej informacji. Plan do uzyskania tych informacji.

Zaplanuj spotkanie przeglądowe ze wszystkimi zainteresowanymi stronami. Spotkania twarzą w twarz są zawsze najlepsze dla tego rodzaju działalności. Pamiętaj, aby zaplanować wystarczająco dużo czasu w celu umożliwienia pełnego przeglądu i zezwalaj na wysłuchanie odmiennych opinii.

Teraz, gdy plan projektu został uzgodniony z zainteresowanymi stronami projektu, uzyskaj zobowiązania od każdej z zainteresowanych stron w celu zatwierdzenia planu projektu.

Zbierz zobowiązania i zarchiwizuj szczegóły na portalu projektu.

Aby uzyskać więcej informacji, zobacz następujące zasoby sieci Web:

Pokaż: