Wykład 7 Przepływ prac: Zarządzanie projektem

Wykład 7 Przepływ prac: Zarządzanie projektem
Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 7 Przepływ prac: Zarządzanie projektem Wykładowca: dr inż. Ewa Stemposz

Zagadnienia Zagadnienia Zagadnienia
Zarządzanie projektem: cele Planowanie z uwzględnieniem iteracji Zarządzanie ryzykiem Pojęcie pomiaru Czym jest metryka ? Pracownicy i artefakty Przepływ prac Zarządzanie projektem Przepływ prac: detale Więcej o aspektach niektórych aktywności Budowanie planu iteracji Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The Rational Unified Process An Introduction, Addison-Wesley, 1999.

Zarządzanie projektem: cele (1)
Zarządzanie projektem w inżynierii oprogramowania wymaga umiejętności lawirowania pomiędzy konkurującymi często wymaganiami, ograniczeniami i ryzykami, po to by zaspokoić potrzeby klienta i użytkowników końcowych. Fakt, że niewiele projektów jest kończonych w zaplanowanym czasie - bez przekraczania budżetu i okrajania funkcjonalności - jest dobrym wskaźnikiem trudności tego zadania. RUP wspomaga zarządzanie projektem przez dostarczenie odpowiednich wytycznych, które choć nie stanowią recepty na sukces, to specyfikują podejście, ułatwiające realizację tego zadania. Trzy główne cele przepływu prac Zarządzanie projektem to: Dostarczenie praktycznych wskazówek wspomagających planowanie prac, organizowanie zespołu (przydział zadań do grup osób i ustalanie odpowiedzialności), kontrolę realizacji projektu i monitorowanie postępów. Dostarczenie szablonów dla zarządzania ryzykiem.

Zarządzanie projektem: cele (2)
Dostarczenie szablonów dla zarządzania procesem budowy złożonego oprogramowania. W RUP, nie podjęto prób przykrycia wszystkich aspektów procesu zarządzania. Nacisk położono głównie na: Planowanie zgrubne dla całości projektu (z uwzględnieniem cykli, faz i iteracji) oraz planowanie szczegółowe dla poszczególnych iteracji. Zarządzanie ryzykiem (wykrywanie potencjalnych problemów). Pomiary (metryki) i monitorowanie postępów (odpowiednio do założonych planów). RUP nie zajmuje się: zarządzaniem ludźmi w aspektach takich, jak zatrudnienia czy szkolenia, zarządzaniem budżetem, zarządzaniem kontraktami zawieranymi z dostawcami i klientami.

Planowanie z uwzględnieniem iteracji (1)
Planowanie projektu z uwzględnieniem iteracji wymaga rozstrzygnięcia kwestii, które nie istniały przy zastosowaniu podejścia tradycyjnego, jak np.: Jak wiele iteracji będzie potrzebne? Jak długo powinna trwać każda z nich? W jaki sposób należy ustalić cele i „zawartość” każdej iteracji? Jak należy śledzić postęp prac w trakcie realizacji iteracji? Planowanie dużych, złożonych projektów Ambitne próby planowania realizacji dużych, złożonych projektów z dokładnością „co do minuty”, wyróżniania aktywności i przypisywania osób do zadań na kilka miesięcy czy kilka lat do przodu, jak wykazała praktyka - są z góry skazane na niepowodzenie. Tworzono diagramy Gantt’a (czy semantyczne sieci aktywności), które pokrywały całe ściany, a mimo to projekty kończyły się niepowodzeniem. Skuteczna realizacja szczegółowych planów wymaga posiadania zarówno dobrego zrozumienia problemu, jak i stabilnych wymagań, stabilnej architektury oraz ukończony choć jeden podobny projekt, tak by w oparciu o niego można było ustalić szczegółowy WBS.

Innymi słowy, jak można planować zbudowanie przez osobę X w tygodniu n modułu Y skoro w momencie planowania, w żaden sposób nie da się w ogóle wydedukować potrzeby posiadania modułu Y? Planowanie szczegółowe jest możliwe w tych dziedzinach inżynieryjnych, gdzie WBS jest mniej lub bardziej zestandaryzowane i stabilne - kolejność zadań jest dostatecznie uporządkowana. Np. budując budynek nie można wznosić jednocześnie piętra pierwszego i czwartego. Po pierwszym musi powstać drugie, potem trzecie, aby można było zająć się czwartym. RUP rekomenduje, by realizacja projektu była opierana na dwóch rodzajach planów, różniących się stopniem szczegółowości: plan faz (zgrubny - nie więcej niż jedna, dwie strony opisu) i seria planów dla iteracji (szczegółowych). Plan faz Tworzony jest jeden plan faz, jeden na potrzeby całego projektu. Plan faz obejmuje z reguły jeden cykl - czasami, stosownie do potrzeb, kilka kolejnych cykli. Tworzony jest bardzo wcześnie, w fazie początkowej. W każdej momencie, może być poddany modyfikacji.

Plan faz definiuje zakres i założenia projektu odwołując się do dokumentu Wizji. Plan faz zawiera poniższe elementy: Daty głównych kamieni milowych: LCO - określenie celów danego cyklu rozwijania projektu (koniec fazy początkowej; projekt ma dobrze określony zakres i zapewnione środki na realizację). LCA - specyfikacja architektury (koniec fazy opracowywania; stabilizacja architektury). IOC - osiągnięta początkowa zdolność operacyjna (koniec fazy konstrukcji; pierwsze beta). Wypuszczenie produktu (koniec fazy wdrożenia i koniec danego cyklu). Profile zespołowe --> jakie zasoby ludzkie są wymagane na poszczególnych etapach cyklu. Specyfikację mniej ważnych kamieni milowych --> data zakończenia każdej iteracji wraz ze specyfikacją jej celów (o ile można je zidentyfikować).

Plan iteracji Tworzony jest jeden plan dla każdej iteracji (plan szczegółowy). Projekt z reguły posiada dwa plany iteracji aktywne w danym momencie: Plan dla bieżącej iteracji: jest wykorzystywany do śledzenia postępów prac w trakcie realizacji. Plan dla następnej iteracji: jest tworzony począwszy od połowy bieżącej iteracji i jest prawie (?) gotowy przy jej końcu. Plan iteracji tworzony jest za pomocą tradycyjnych technik (diagramy Gantt’a, itp.) i narzędzi do planowania (Microsoft Project, itp.). Cel - definiowanie zadań, przypisanie zadań do osób i zespołów. Plan zawiera ważne daty, takie jak np.: zakończenie budowy „czegoś”, dostarczenie komponentów z innej organizacji czy terminy głównych przeglądów. RUP - przyjmując za podstawę proces iteracyjny i niekończącą się akomodację zmian celów i taktyki - zakłada tym samym, że nie istnieją racjonalne powody, by marnować czas na przygotowywanie szczegółowych planów dla dłuższych horyzontów czasowych: takie plany są trudne do zarządzania, szybko stają się nieaktualne oraz z reguły są ignorowane przez organizacje wykonawcze).

Plan faz (zgrubny) Zgoda na projekt Przegląd architektury Beta1 Beta2 Wypuszczenie produktu Iter. #1 Iter. #2 Iter. #3 Iter. #4 Iter. #5 Start 1/98 LCO 3/98 4/98 LCA 5/98 IOC 12/98 2/99 Plan iteracji (szczegółowy) 4/98 5/98 Przegląd projektu Budowa #1 Budowa #2

Zarządzanie ryzykiem (1)
Tim Lister, Software Risk Management Is Software Project Management, Seminar at Software Productivity Center, Vancouver, B. C., Canada, May 1966: „All the risk-free projects have been done” Tylko to, co do czego ma się pełną świadomość, że jest do zrobienia, można precyzyjnie opisać, sporządzić harmonogram, podzielić na zadania, przypisać do osób czy poddać przeglądom. Zarządzanie ryzykiem obejmuje te aspekty projektu, co do których brakuje pełnej świadomości. Wiele organizacji wytwarzających oprogramowanie wykonuje swoją pracę zaprzeczając istnieniu ryzyka w ogóle: szacowanie i planowanie jest przeprowadzane w sposób, który sugeruje, że wszystkie aspekty procesy są doskonale znane, praca jest w całości mechaniczna a personel nie podlega żadnym fluktuacjom.

Czym jest ryzyko? Ryzyko jest tym wszystkim, co może przeszkodzić w osiągnięciu sukcesu a aktualnie nie jest znane w ogóle, lub znane mało lub mało prawdopodobne. Dla projektu software’owego „osiągnięciem sukcesu” możemy nazwać zbudowanie systemu w zaplanowanym czasie, bez przekraczania budżetu, okrajania funkcjonalności i z wypełnieniem wszystkich wyspecyfikowanych ograniczeń. Decyzje, podejmowane w trakcie realizacji projektu, muszą być opartych o analizę ryzyka! Aby decyzje były efektywne, analiza musi być dobra! Trzeba nie tylko rozumieć istotę ryzyka, ale też posiadać jasno sprecyzowane strategie dla mitygowania ryzyka - innymi słowy trzeba umieć z nim postępować. Ryzyka możemy podzielić na: Ryzyka bezpośrednie: takie, które w dużym stopniu pozostają pod kontrolą projektu. Ryzyka pośrednie: projekt posiada małą albo w ogóle żadną kontrolę nad nimi.

W opisie ryzyka możemy wyróżnić dwa podstawowe atrybuty: prawdopodobieństwo wystąpienia, wpływ na projekt (stopień zagrożenia, „waga” ryzyka). Oba powyższe atrybuty są często łączone w jeden pojedynczy, nazywany wskaźnikiem ważności ryzyka, który może przyjmować jedną z pięciu wartości określających istotę ryzyka: duże (high), znaczące (significant), umiarkowane (moderate), pomniejsze (minor), małe (low). Uważa się, że tyle wartości wystarcza, aby określić stopień zagrożenia projektu przez określone ryzyko. Jak postępować z ryzykiem? Główna idea: nie chować głowy w piasek, nie zachowywać się pasywnie, nie czekać aż ryzyko zamieni się w problem, który może „zabić” projekt, zanim zostaną podjęte jakiekolwiek decyzje. Dla każdego postrzeganego ryzyka trzeba zawczasu wiedzieć, jak z nim postępować.

Wg Barry Boehm’a (Software Risk Management: Principles and Practice, IEEE Software, Jan. 1991) możliwe są trzy główne sposoby zarządzania ryzykiem: Unikanie ryzyka: Reorganizacja projektu tak, by nie podlegał oddziaływaniu ryzyk. Przeniesienie ryzyka: Reorganizacja projektu tak, by ryzyko ponosił ktoś inny, np.: klient, sprzedawca, bank czy jakiś inny podmiot. Zaakceptowanie ryzyka: Praca ze świadomością ewentualności wystąpienia niekorzystnych wydarzeń, monitorowanie symptomów oraz określenie sposobów postępowania dla zmniejszenia zagrożenia. W tym ostatnim przypadku, można zrobić dwie rzeczy: Mitygować ryzyko: Oznacza to podjęcie kroków zapobiegawczych w celu zredukowania zarówno prawdopodobieństwa wystąpienia ryzyka, jak i jego wpływu na projekt. Zdefiniować plan postępowania, jeśli ryzyko wystąpi: innymi słowy „utworzyć plan B”.

Pojęcie „pomiaru” (1) Dlaczego dokonujemy pomiarów?
Dokonujemy pomiarów głównie po to, by zyskać kontrolę nad przebiegiem projektu, by nim efektywnie zarządzać. Mierzymy, by szacować - w terminach ukończonych zadań, jakości artefaktów i zgodności z wymaganiami - jak daleko lub blisko jesteśmy w porównaniu do poczynionych uprzednio planów. Mierzymy, by doświadczenia nabyte w trakcie realizacji jednego projektu wykorzystać do ulepszania następnych (odnośnie nakładów pracy, pieniędzy i uzyskiwanej jakości produktów). Innymi słowy chcemy mieć możliwość oceniania rezultatów wprowadzanych zmian (na przestrzeni pewnego okresu czasu) - co w efekcie posłuży do ulepszanie procesu wytwarzania oprogramowania. Dokonywanie pomiarów zwiększa koszty projektu o niemałe sumy i dlatego warto jest precyzyjnie określać co i po co ma być mierzone, tak by gromadzić jedynie pomiary użyteczne dla wypełniania założonych celów. Cele można z grubsza podzielić na dwa rodzaje:

Pojęcie pomiaru (2) Cele związane z posiadaniem wiedzy: Cele opisywane z pomocą czasowników takich jak np. oszacuj, prognozuj, monitoruj. Wyrażają pragnienie posiadania lepszego zrozumienia przeprowadzanego procesu. Na przykład, można chcieć oszacować jakość produktu czy posiadać dane, które pozwoliłyby na prognozę niezbędnych nakładów potrzebnych na testowanie, monitorowanie pokrycia testów czy zmianę wymagań. Cele związane ze zmianami lub osiągnięciami: Cele wyrażane za pośrednictwem czasowników takich jak np. zwiększ, zredukuj, ulepsz, osiągnij. Mówią o potrzebie śledzenia zmian (ulepszeń) na przestrzeni pewnego okresu czasu, np. od iteracji do iteracji czy też od jednego projektu do drugiego. Przykłady celów: Monitoruj postęp w stosunku do poczynionych planów. Zwiększ satysfakcję klienta. Popraw produktywność. Popraw przewidywalność. Zwiększ ponowne użycie.

Pojęcie pomiaru (3) Nie jest możliwa bezpośrednia zamiana celów na rodzaje pomiarów - cele specyfikuje się poprzez określenie pod-celów, czyli akcji, które uczestnicy projektu muszą wykonać, by osiągnąć cel. Ponadto, należy mieć pewność, że uczestnicy projektu dobrze rozumieją korzyści, jakie mogą z faktu osiągnięcia celu wyniknąć. Na przykład dla celu „Zwiększ satysfakcję klienta” można wyróżnić następującą listę pod-celów: Zdefiniuj, co oznacza „satysfakcja klienta”. Dokonuj pomiaru satysfakcji klienta w trakcie wypuszczania kolejnych produktów. Weryfikuj fakt wzrostu satysfakcji. Niektóre z pod-celów (nie wszystkie) mogą wymagać dokonywania pomiarów. Na przykład, dane świadczące o stopniu satysfakcji klienta mogą być pobierane z przeglądów dokonywanych przez klientów, ankiet czy liczby wezwań do „ciężkich przypadków” w trakcie użytkowania produktu.

Czym jest metryka ? Można wyróżnić dwa rodzaje metryk:
Metryka będąca mierzalnym atrybutem pewnego bytu. Na przykład nakłady pracy niezbędne dla realizacji projektu mogą stanowić miarę jego złożoności - poprzez zsumowanie okresów czasu zaplanowanych dla realizacji wszystkich niezbędnych aktywności. Miara elementarna stanowiąca element składowy metryki zdefiniowanej w punkcie 1. Pojedyncza rezerwacja czasu jest tu przykładem elementarnej miary. Z reguły, miara elementarna jest tym rodzajem metryki, który może być przechowywany w bazie danych i nigdy nie jest interpretowany samodzielnie, w izolacji od innych elementów. Definiowanie metryk wymaga zarówno precyzyjnego określenia opisujących je miar elementarnych, jak i określenia reguł tworzenia kolekcji tych miar. Metryki - o które oparte są cele związane ze śledzeniem zmian (czy osiągnięć na przestrzeni czasu) - z reguły bazują na wyliczaniu pierwszych pochodnych (dla pojedynczej iteracji lub całości projektu).

Pracownicy i artefakty (1)
Główni pracownicy przepływu prac Zarządzanie projektem to: Kierownik projektu i Recenzenci projektu. Inni pracownicy – to ci, odpowiedzialni za plany, którymi nie zajmuje się Kierownik projektu, a które stanowią element składowy Planu rozwoju oprogramowania (SDP Software Development Plan), Kierownik konfiguracji - odpowiedzialny za Plan zarządzania konfiguracjami, Inżynier procesu - odpowiedzialny za Plan produkcji (Development case)

Pracownicy i artefakty (2)
Kierownik projektu odpowiedzialny za Szacowanie iteracji Plan iteracji Przypadek biznesowy Plan rozwoju oprogramowania Porządek prac Szacowanie statusu Pomiary projektu Plan akceptacji produktu Plan zarządzania ryzykiem Lista ryzyk Plan rozwiązywania problemów Plan pomiarów

Przepływ prac Zarządzanie projektem (1)
[Tylko dla pierwszej iteracji] [Wszystkie kolejne iteracje] Twórz wyobrażenie nowego projektu [Plany projektu zatwierdzone] Określ zakres Szacuj ryzyka Planuj następną iterację Nadzoruj i monitoruj projekt Buduj Plan rozwoju oprogramowania Projekt unieważniony Zarządzaj bieżącą iteracją Projekt unieważniony [Iteracja zakończona sukcesem] { Kontynuacja przepływu prac Zarządzanie projektem znajduje się na następnej folii }

Przepływ prac Zarządzanie projektem (2)
[Koniec iteracji] [Koniec projektu] [Koniec fazy] Zakończ projekt Zakończ fazę [Projekt unieważniony] Projekt unieważniony Koniec projektu [Brak akceptacji] [Faza kompletna] Określ zakres Szacuj ryzka Koniec iteracji

Zarządzanie projektem: detale (1)
Twórz wyobrażenie nowego projektu Celem jest tu umożliwienie podjęcia decyzji dotyczących rozwijania lub unieważnienia projektu w ogóle. Aktywności poświęcone są identyfikowaniu i szacowaniu ryzyk, rozwijaniu przypadku biznesowego, inicjalizowaniu projektu (Kierownik projektu) oraz przeglądom dotyczącym akceptacji projektu (Recenzenci projektu). Określ zakres, szacuj ryzyka Celem jest tu ponowna ocena zamierzonych własności systemu i powiązanych z ich osiąganiem ryzyk. Ocena jest dokonywana dwukrotnie: Pierwszy raz, gdy zostało wybrane preferowane podejście, projekt został zainicjalizowany - wtedy ma za zadanie dostarczenie solidnej bazy dla dalszego szczegółowego planowania. Drugi raz, na zakończenie każdej iteracji, by podsumować wyniki, ocenić doświadczenia i upewnić się, które ryzyka „odesłano na emeryturę”.

Buduj Plan rozwoju oprogramowania Celem jest tu opracowywanie elementów składowych i załączników dla Planu rozwoju oprogramowania (Kierownik projektu). Plan rozwoju oprogramowania musi zostać zrecenzowany w aspekcie szans na zrealizowanie i akceptacji przez uczestników projektu (Recenzenci projektu). Planuj następną iterację Ta aktywność polega na utworzeniu szczegółowego planu dla iteracji, następnej po bieżącej. Plan tworzy Kierownik projektu, a Recenzent poddaje go przeglądowi. Plan następnej iteracji może być przyczyną zmiany Planu rozwoju oprogramowania, np.: gdy zmienia się allokacja funkcjonalności lub przypadek biznesowy (ulegają zmianie koszty lub ROI na skutek zmian dat uzyskiwania ważnych własności systemu). Nadzoruj i monitoruj projekt Obsługa żądań zmian, w tym ustalanie planu realizacji zmian usankcjonowanych przez Kierownika zmian, w tej i następnych iteracjach. Ciągłe monitorowanie projektu w kontekście aktywnych ryzyk, pomiarów postępów oraz jakości.

Regularne raportowanie statusu projektu przed osobami spoza projektu w ramach organizacji. Rozwiązywanie napotykanych problemów zgodnie z utworzonym Planem rozwiązywania problemów. Zarządzaj bieżącą iteracją Zadania: zgromadzenie zasobów niezbędnych do przeprowadzenia iteracji, wykonanie zaplanowanych prac a następnie szacowanie ich rezultatów (Kierownik projektu). Czy cele iteracji zostały osiągnięte bada się w oparciu o wytworzone artefakty (Recenzenci projektu). Przeglądy związane są z recenzowaniem zarówno kryteriów oceny iteracji jako takiej, jak i kryteriów akceptacji wyprodukowanych artefaktów. Zakończ fazę Faza może być zakończona, gdy: Wszystkie ważne kwestie zostały rozwiązane. Stan głównych artefaktów jest znany. Problemy związane z rozmieszczeniem (np. instalacja, przeniesienie, szkolenie) zostały zaadresowane.

Dalsze finansowanie projektu jest zapewnione, w przypadku gdy kończy się aktualny kontrakt. Powyższe aktywności przypisane są do obowiązków Kierownika projektu. Recenzent projektu odpowiada za przegląd artefaktów zgodnie z regułami określonymi przy definiowaniu odpowiedniego kamienia milowego. Jeśli stan projektu jest satysfakcjonujący zostaje uzyskana zgoda na przejście do następnej fazy. Zakończ projekt Kierownik projektu ma za zadanie przygotowanie projektu do zakończenia. Jeśli projekt zostanie zaakceptowany przez Recenzenta projektu, klient formalnie przejmuje produkt na własność. Więcej o aspektach niektórych aktywności 1. Tworzenie planu dla faz wymaga udzielenia odpowiedzi na pytania: Jak duże nakłady będą potrzebne do realizacji? Kiedy będziemy w stanie uzyskać produkt gotowy do wypuszczenia?

Więcej o aspektach niektórych aktywności (1)
Planowanie kolejnych kamieni milowych (zgrubne) odbywa się do tyłu, począwszy od planowanej daty wypuszczenia produktu. 2. Wielkość zespołu a plan prac Praktyka wskazuje, że zwiększenie liczebności zespołu nie pociąga za sobą proporcjonalnego wzrostu produktywności. Niektórzy uważają nawet (Fred Brooks), że „dodanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej”. RPU zaleca, by wykorzystując różne techniki szacowania złożoności oprogramowania (COCOMO, FPA, ...), wybierać rozsądny kompromis między wymaganymi nakładami, czasem potrzebnym na realizację a wielkością zespołu. Produktywność można zwiększać zwiększając ponowne użycie, niekoniecznie zespół. 3. Ustalanie profilu nakładów prac Ustaliwszy kompromis między nakładami, czasem i wielkością zespołu należy określić profil nakładów prac i sprecyzować daty dla kamieni milowych, modyfikując tzw. profil podstawowy (typowy) w zależności od różnych aspektów danego projektu. Modyfikację przeprowadza się bazując na różnych heurystykach.

zasoby Typowy profil można wykorzystać, gdy: projekt nie jest duży, nie wymaga dużych nakładów, cykl jest początkowy, nie ma konieczności adaptacji do istniejącej architektury, liczba ryzyk jest mała. P O K W czas P – faza początkowa O – faza opracowywania K – faza konstrukcji W – faza wdrożenia Faza Czas Wysiłek początkowa opracowywania konstrukcji wdrożenia 10% 30% 50% 5% 20% 65% 10%

Jeśli potrzeba czasu, by ustalić zakres odpowiedzialności dla systemu, znaleźć potrzebne fundusze, przeprowadzić badania rynku czy też zbudować prototyp weryfikujący poprawność wstępnych rozwiązań, należy wydłużyć fazę początkową. Jeśli: (1) architektura ma być zbudowana od podstaw, (2) planuje się wykorzystanie nowych, nieznanych technologii, (3) system musi wypełniać surowe wymagania dotyczące wydajności, (4) istnieją różne ryzyka techniczne, (5) w zespole projektowym jest dużo nowych osób – w takim wypadku należy wydłużyć fazę opracowywania. Jeśli aktualnie ma być wytwarzana druga generacja istniejącego produktu (cykl ewolucji) i nie są planowane żadne poważne zmiany w architekturze, z powodzeniem można skrócić fazę początkową i fazę opracowywania. Jeśli istnieje konieczność szybkiego wypuszczenia produktu na rynek – bo jesteśmy opóźnieni lub dlatego, że to my kreujemy rynek – i ponadto mamy w planach stopniowy rozwój produktu, należy skrócić fazę konstrukcji i wydłużyć fazę wdrożenia.

Jeśli wdrożenie systemu nie jest sprawą trywialną, np. trzeba zamienić stary system utrzymując ciągłość prac, itp. należy wydłużyć fazę wdrożenia. 4. Czas trwania iteracji Każda iteracja - rozpoczynając się planowaniem prac i kończąc wypuszczeniem produktu (wewnętrznym lub zewnętrznym) - stanowi prawie kompletny mini-projekt. Wytworzony produkt, w większości przypadków ma postać kodu wykonalnego, niekompletnego w danym momencie. W idealnym przypadku każda iteracja powinna trwać od dwóch do sześciu tygodni, w praktyce długość iteracji zmienia się od projektu do projektu. W dużym stopniu zależy to od rozmiaru i rodzaju organizacji. Np. grupa złożona z pięciu osób może zaplanować pracę w poniedziałek, spotykać się codziennie na lunchu, by omawiać postępy, w czwartek rozpocząć budowę i zakończyć prace związane z daną iteracją w piątek wieczorem. Z kolei, grupy większe (np. kilkadziesiąt osób) będą wymagały bardziej formalnego podziału prac, formalnych sposobów wymiany informacji, synchronizowania podzespołów, scalania wyników i monitorowania przebiegu. Iteracja może trwać nawet i kilka miesięcy.

Liczba linii kodu Liczba osób Czas trwania iteracji 5,000 20,000 100,000 1,000,000 4 10 40 150 2 tygodnie 1 miesiąc 3 miesiące 8 miesięcy Inne aspekty, które należy rozważać ustalając czas trwania iteracji, to: stopień znajomości podejścia iteracyjnego w organizacji, stabilność i dojrzałość organizacji oraz stopień automatyzacji w zarządzaniu artefaktami. 5. Liczba iteracji jest z założenia różna dla różnych faz. W fazie początkowej często uważa się, że iteracji nie ma, tzn. nie ma czegoś, co można by nazwać „prawdziwą iteracją” (mini-projektem): żaden kod nie jest produkowany, wykonywane są głównie aktywności związane z planowaniem i marketingiem.

Czasami jednak iteracja jest potrzebna, po to by: Zbudować prototyp, by przekonać siebie czy sponsora, że proponowane rozwiązanie (lepiej: pomysł na rozwiązanie) jest dobre. Zbudować prototyp, w celu mitygowania ryzyk technicznych (np. eksploracja nowych technologii czy nowych algorytmów) czy udowodnienia, że cele wydajnościowe są osiągalne. Przyspieszyć wdrażanie narzędzi i procesów w organizacji. Faza początkowa: 0 lub 1 iteracja W fazie opracowywania należy zaplanować przynajmniej jedną iterację. Jeśli nie istnieje architektura, od której można by rozpocząć prace, lub trzeba rozwiązywać problemy związane z nowymi ludźmi, nowymi technologiami, nowymi platformami software’owo-hardwer’owymi - wtedy trzeba planować dwie lub trzy iteracje. Założenie, że wszystkie problemy mogą być rozwiązywane na raz, jest nierealne.

Ponadto, być może trzeba zademonstrować prototyp klientowi czy użytkownikowi końcowemu, aby uściślić wymagania. Jedna iteracja może być też potrzebna do korekty błędów w architekturze - błędów wynikłych z wcześniej podjętych decyzji. Faza opracowywania: od 1 do 3 iteracji W fazie konstrukcji, podobnie jak w fazie opracowywania należy zaplanować przynajmniej jedną iterację. Dwie iteracje są bardziej rozsądnym rozwiązaniem, szczególnie gdy planuje się poświęcić więcej wysiłków na testowanie i integrację. Dla bardziej ambitnych projektów można planować co najmniej trzy iteracje. Warunek – organizacja jest wystarczająco zautomatyzowana i dojrzała na tyle, by znieść stres związany z dłuższym okresem realizacji. Faza konstrukcji: od 1 do 3 iteracji

W fazie wdrożenia, podobnie, jak w dwóch poprzednich fazach, należy zaplanować przynajmniej jedną iterację, np. finalne wypuszczenie produktu po beta. W praktyce, zbyt często, na skutek sytuacji występującej w danym momencie na rynku czy niskiej jakości wypuszczonego produktu, liczbę iteracji trzeba zwiększać. Faza wdrażania: 1 lub 2 iteracje Dla tzw. „typowych” projektów możliwe są następujące warianty: Projekt z małą liczbą iteracji: 3 iteracje [0, 1, 1, 1] Projekt z typową liczbą iteracji: 6 iteracji [[1, 2, 2, 1] Projekt z dużą liczbą iteracji: 9 iteracji [1, 3, 3, 2] Iteracje zostały podane dla jednego cyklu, zgodnie z kolejnością faz: początkowa, opracowywania, konstrukcji i wdrażania. Podsumowywując, „typowy” projekt jest realizowany w trakcie iteracji. + -

Budowanie planu iteracji (1)
Natura szczegółowego planu dla iteracji zmienia się od fazy do fazy. Objaśnienie sposobu budowania planu iteracji zostało podane poniżej w oparciu o iterację dla fazy opracowywania, a dalej omówiono różnice występujące dla iteracji z pozostałych faz. Pewne kryteria ulegają zmianie wraz ze zmianą fazy, ale „szczegółowy przepis” pozostaje taki sam. W pierwszym kroku należy sobie dobrze uświadomić ograniczenia: (1) czas zaplanowany (wcześniej) na realizację danej iteracji i (2) dostępne zasoby. W kroku drugim należy przygotować szczegółowy plan bazujący na powyższych ograniczeniach. Planowanie polega na przypisaniu aktywności do pracowników i pracowników do konkretnych osób. Bardzo użyteczne jest na tym etapie narzędzie do planowania, takie jak np. Microsoft Project. Ważne! Nie należy specyfikować zbyt ambitnych celów i planować ich osiągnięcie - innymi słowy, należy planować w oparciu o czas, a nie o cel (scheduling by time not by volume), co oznacza że planuje się maksymalną (wystarczającą) ilość pracy możliwą do wykonania w trakcie realizacji danej iteracji.

Zbudowanie szczegółowego planu iteracji może być realizowane w oparciu o cztery poniższe kroki: Należy zdefiniować obiektywne kryteria sukcesu iteracji. Kryteria zostaną wykorzystane przy końcu iteracji, w trakcie przeglądu. Na ich podstawie będzie podejmowana decyzja, czy iteracja zakończyła się sukcesem czy porażką. Trzeba zidentyfikować konkretne, dające się mierzyć artefakty, które mają być budowane od początku czy też modyfikowane w trakcie iteracji. Trzeba znaleźć aktywności, które umożliwią zrealizowanie tego zadania. Opierając się na typowym WBS (Work Breakdown Structure), trzeba go tak zmodyfikować, by zostały uwzględnione aktywności zidentyfikowane w poprzednim kroku. Należy oszacować czas i nakłady niezbędne do realizacji każdej planowanej aktywności, dbając o to, by utrzymywać się w ramach zaplanowanego wcześniej budżetu.

Iteracje w fazie opracowywania Plany dla iteracji w fazie opracowywania muszą być budowane w oparciu o trzy, najważniejsze w tej fazie elementy: ryzyka, własności krytyczne dla osiągnięcia sukcesu i pokrycie : Plany powinny być budowane tak, by większość ryzyk została zmitygowana lub „wysłana na emeryturę” właśnie w fazie opracowywania. Ryzyka są bardzo ważne, ale to nie mitygacja ryzyk jest celem ostatecznym. Ostatecznym celem jest uzyskanie produktu, posiadającego własności uznane za krytyczne dla osiągnięcia sukcesu. Ponieważ podstawowym celem fazy opracowywania jest budowa stabilnej architektury, plany muszą być konstruowane tak, by architektura adresowała wszystkie aspekty oprogramowania (pokrycie). Jest to ważne, bo architektura stanowi bazę dla dalszego planowania.

Ryzyka Dla każdego z ryzyk o największej wadze należy zidentyfikować taki scenariusz w jednym z przypadków użycia, który „wymusi” na zespole projektowym konfrontację z ryzykiem. Np. (1) Jeśli występuje ryzyko integracyjne: „baza danych D może pracować niepoprawnie z systemem operacyjnym S” – należy dołączyć scenariusz, który wymusi choćby najbardziej „skromną” współpracę między nimi. (2) Z kolei, jeśli występuje ryzyko związane z nieodpowiednią wydajnością systemu, np.: „może wystąpić zbyt duży czas obliczania trajektorii lotu samolotu”, należy dołączyć scenariusz, który wymusi obliczanie trajektorii, co najmniej dla najbardziej oczywistych i najczęściej występujących sytuacji. Własności krytyczne Należy wybrać z przypadków użycia te scenariusze, które dotyczą podstawowych, najczęściej używanych funkcji i serwisów.

Pokrycie Przy końcu fazy opracowywania, należy dołączać te scenariusze, które choć nie są ani ważne z perspektywy ryzyk, ani z perspektywy własności krytycznych, to dotyczą tych obszarów projektu, które i tak kiedyś trzeba rozwijać. Często opłaca się konstruowanie złożonych scenariuszy adresujących jednocześnie wiele elementów ze wspomnianej powyżej listy (np. kilka ryzyk + własności krytycznych) - nie mniej jednak, właśnie ze względu na ich złożoność, należy wykorzystywać je rozważnie. Przykłady złożonych celów iteracji: 1. Utwórz rekord użytkownika ze stacji klienckiej; rekord ma być przechowywany w bazie danych na serwerze, łącznie z dialogiem użytkownika (niekoniecznie wszystkie pola); operacja powinna przebiegać bezbłędnie. Powyższy scenariusz łączy własności krytyczne z ryzykiem dotyczącym integracji (baza danych i software komunikacyjny) oraz z działaniem na dwóch różnych platformach.

W takim przypadku, członkowie zespołu projektowego są zmuszeni do zapoznania się z nowymi narzędziami, wspomagającymi proces tworzenia GUI. W efekcie, realizacja scenariusza doprowadzi do uzyskania prototypu, który można zaprezentować użytkownikom (w celu uzyskania informacji zwrotnych). 2. Upewnij się, że jeśli zostanie utworzonych 20,000 rekordów użytkowników, czas dostępu nie przekroczy 20 milisekund. Ten scenariusz adresuje czynniki służące określaniu wydajności systemu: objętość danych i czas odpowiedzi. Jeśli nie zostaną one właściwie potraktowane w tym kroku, mogą drastycznie wpłynąć na zmianę architektury później. 3. Unieważnij zmianę adresu użytkownika. Ten scenariusz z kolei, adresuje problemy związane z unieważnianiem wykonanych wcześniej operacji. Na podstawie jednej prostej własności, zmusza się zespół projektowy do przemyślenia wszelkich funkcji undo, co często też wyzwala potrzebę skonsultowania z użytkownikiem końcowym rozsądnych kosztów przeprowadzania operacji unieważniających.

4. Doprowadź do skompletowania wszystkich przypadków użycia powiązanych z zarządzaniem łańcuchem dostaw (pokrycie). Ten scenariusz ma na celu sprawdzenie, czy pozyskano całość wymagań, niezbędnych dla realizacji pewnej funkcjonalności systemu: tu „zarządzanie łańcuchem dostaw”. Iteracje w fazie konstrukcji W fazie konstrukcji ryzyka nadal pozostają motorem napędowym, szczególnie że mogą się pojawiać nowe. Ale, w tej fazie istnieje też inny, bardziej znaczący motor napędowy: kompletność przypadków użycia. Iteracje fazy konstrukcji powinny być planowane tak, by w pierwszej kolejności zrealizować własności najbardziej krytyczne (by poddać je testowaniu w więcej niż jednej iteracji). Główny cel fazy konstrukcji, to realizacja wszystkich przypadków użycia (pełne pokrycie). Przykłady iteracji w fazie konstrukcji: 1. Skompletuj własności opisujące operatora telefonicznego, z wyłączeniem usług dotyczących serwisu nocnego.

Ten scenariusz dotyczy zbioru powiązanych własności. Część z nich może być zrealizowana jeszcze w fazie opracowywania, a następnie może posłużyć jako prototyp do rozwijania innych własności. 2. Przeprowadź integrację, aby otrzymać nową wersję systemu. Ten scenariusz może wymagać wprowadzenia drobnych zmian do architektury, być może na skutek błędów wykrytych we wcześniejszych iteracjach. Iteracje w fazie wdrożenia W fazie wdrożenia cel główny to ukończenie aktualnej generacji produktu. Zadania dla iteracji w tej fazie są formowane w terminach błędów, jakie mają być usunięte i w terminach jakości (np. poprawa używalności, wydajności). Jeśli - w fazie konstrukcji - nie wszystkie własności zostały zrealizowane, to można próbować zrobić to w fazie wdrożenia pod warunkiem, że dołączane własności nie zburzą tego, co osiągnięto do tej pory.

Przykłady iteracji w fazie wdrożenia: 1. Rozwiąż wszelkie problemy o największej wadze, u wszystkich klientów posiadających wersję beta. Cel: nie tylko poprawa jakości produktu, ale też i poprawa wiarygodności organizacji na rynku. 2. Osiągnij wydajność 2000 transakcji na minutę. Cel: ulepszenie jakości systemu. Takie zadanie wymaga zajęcia się optymalizacją, np.: zmianą struktur danych, wykorzystaniem pamięci cache i/lub wykorzystaniem bardziej efektywnych algorytmów. 3. Zredukuj liczbę różnych okien dialogowych o 30%. Cel: poprawa czytelności przez zmniejszenie bałaganu spowodowanego nadmiarem rozwiązań. 4. Utwórz wersje produktu w językach niemieckim i japońskim. Cel: Wersja beta została skonstruowana wyłącznie na rynki anglojęzyczne. W fazie wdrożenia można zrealizować inne wersje.

Uszczegóławianie prac niezbędnych do wykonania w trakcie realizacji iteracji - dotyczy to wszystkich iteracji niezależnie od fazy. Mając zdefiniowane cele iteracji, wybrane przypadki użycia (które mają być rozwijane) i listę defektów (które należy usuwać) w kolejnym kroku trzeba określić, jakich artefaktów będą dotyczyć działania niezbędne do osiągnięcia założonych celów, np.: Jakie klasy powinny być ponownie przejrzane? Jakie podsystemy będą zmieniane, a jakie tworzone od początku? Jakie interfejsy prawdopodobnie ulegną zmianom? Która dokumentacja będzie musiała być zaktualizowana? Kolejny krok to zidentyfikowanie (w RUP) potrzebnych aktywności i umieszczenie ich w planie iteracji. Niektóre aktywności są wykonywane tylko raz w trakcie przebiegu iteracji (np. tworzenie planu iteracji), podczas gdy inne raz na klasę, raz na przypadek użycia czy raz na podsystem (np. projektowanie klasy).

Następnie, wybrane z RUP aktywności należy powiązać wzajemnie (na zasadzie kolejności wytwarzania artefaktów) i oszacować dla każdej z nich nakłady pracy. Większość aktywności wymaga przypisania jednej osoby (lub małej grupy osób); praca nie powinna wymagać poświęcenia więcej niż kilku dni. W trakcie tworzenia planu iteracji może się okazać, że zabraknie czasu na realizację założonych celów. Zamiast rozszerzać iterację (np. poprzez zwiększenie czasu jej trwania, co może wpłynąć albo na późniejsze wypuszczenie produktu finalnego, albo na zmniejszenie liczby iteracji) lepiej jest zredukować ambitne plany. W zależności od tego, w której fazie znajduje się dana iteracja można uprościć scenariusze czy też zredukować zbiór realizowanych własności.

Wykład 7 Przepływ prac: Zarządzanie projektem

Podobne prezentacje

Prezentacja na temat: "Wykład 7 Przepływ prac: Zarządzanie projektem"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres

Wejść

Zaloguj się poprzez sieć społeczną:

Wykład 7 Przepływ prac: Zarządzanie projektem

Podobne prezentacje

Prezentacja na temat: "Wykład 7 Przepływ prac: Zarządzanie projektem"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres