1. Planowanie systemu (w tym specyfikacja wymagań) 3. Projekt systemu (model poszczególnych struktur itp.)

Transkrypt

1 Metodyki zarządzania i wytwarzania METODYKI ZARZĄDZANIA PROCESEM I REALIZACJI PROJEKTÓW INFORMATYCZNYCH: RUP, PRINCE2, XP, XPRINCE, SCRUM Tradycyjne RUP (Rational Unified Process) spiralny, rozbudowany PRINCE2 (Projects In Controlled Environments) kaskadowy, rozbudowany Zwinne (agile) Scrum extreme Programming, XP XPrince (połączenie Prince2, XP oraz RUP) Adam Wojciechowski Model kaskadowy Model kaskadowy Planowanie Analiza Projekt Implementacja Testowanie Wdrożenie Pielęgnacja 1. Planowanie systemu (w tym specyfikacja wymagań) 2. Analiza systemu (w tym analiza wymagań i studium wykonalności) 3. Projekt systemu (model poszczególnych struktur itp.) 4. Implementacja (napisanie/wygenerowanie kodu) 5. Testowanie (jednostkowe i funkcjonalne) 6. Wdrożenie i pielęgnacja systemu Wadą jest nieelastyczny podział na kolejne fazy Nie można przejść do następnej fazy przed zakończeniem poprzedniej Iteracje są bardzo kosztowne - powtarzamy wiele czynności Model przyrostowy Model spiralny Planowanie Wymagania Ewaluacja Implementacja Testowanie Wdrożenie Zadania w każdym cyklu Określenie celu Rozpoznanie i mitygacja zagrożeń Budowa i zatwierdzenie Ocena i planowanie Wydanie systemu Źródło rys.: wikipedia 1

2 Model spiralny i przyrostowy Częste kontakty z klientem (w porównaniu do modelu kaskadowego) Faza oceny w każdym cyklu (pozwala uniknąć błędów lub wcześniej je wykryć) Wykorzystanie przez klienta fragmentów systemu (prototypy) Brak konieczności zdefiniowania z góry całości wymagań - cały czas istnieje możliwość rozwijania projektu Częste kontrole jakości w kolejnych cyklach - nastawienie na wykrywanie błędów i działania kontrolne, a nie na zapobieganie Orientacja na zarządzanie, czas i budżet. Trudności z określeniem podzbioru funkcji niezależnych (moduły) Konieczność implementacji szkieletu dodatkowy nakład pracy Wysoki koszt usuwania błędów wykrytych w finalnych etapach projektu Często popełniane błędy i trudności w zarządzaniu i realizacji projektów inf. Zarządzanie wymaganiami ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura oprogramowania nieodporna na obciążenia (ang. Brittle architecture) Zbytnia, niepotrzebna złożoność oprogramowania Niewykryte niespójności w wymaganiach, projekcie oraz implementacji Brak lub niewystarczające testowanie Subiektywna ocena postępu projektu Brak zarządzania ryzykiem Brak automatyzacji prowadzenia projektu Co to jest RUP? Rational Unified Process RUP course_description&coursecode=rp401&country=us&language=en RUP is a knowledge base, containing software engineering practices that represent many of the best practices observed in successful software development Odpowiedź na błędy w zarządzaniu i realizacji projektów informat. Rational Unified Process (RUP) proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę Rational Software Corporation (przedsiębiorstwo zostało przejęte przez IBM) Proces RUP nie jest pojedynczym, ściśle określonym procesem, ale raczej szablonem procesu. Został on zaprojektowany w celu przystosowania do charakteru konkretnej organizacji (przedsiębiorstwa), konkretnego zespołu projektowego lub nawet charakteru konkretnego projektu. Z szablonu RUP można wybrać elementy w zależności od konkretnych potrzeb. Rational Unified Process (RUP) to także nazwa oprogramowania, opracowanego przez Rational Software (obecnie dostępnego w IBM). Produkt ten zawiera hipertekstową bazę wiedzy z przykładowymi artefaktami oraz szczegółowymi opisami wielu typów czynności. Process RUP definiowany jest także w produkcie Rational Method Composer (RMC), który pozwala na tworzenie spersonalizowanych wersji RUP. Metodyka RUP Fazy w RUP RUP bazuje na zbiorze zasad inżynierii programowania oraz najlepszych praktykach, na przykład: iteracyjnym wytwarzaniu oprogramowania (Iterative Development) zarządzaniu wymaganiami (Requirement Management) używaniu architektury bazującej na komponentach (Component-based architecture) graficznym projektowaniu oprogramowania kontroli jakości oprogramowania (Quality Assurance) procesu kontroli zmian w oprogramowaniu (Change Management) Cykl życia w RUP bazuje na modelu spiralnym i układa zadania w fazy i iteracje. Projekt został podzielony na cztery fazy: faza rozpoczęcia (Inception phase) faza opracowywania (Elaboration phase) faza konstrukcji (Construction phase) faza przekazania systemu (Transition phase) 2

3 Fazy w RUP Dyscypliny RUP (Disciplines and workflows) RUP bazuje na zbiorze klocków (building blocks, content elements). Opisują one, co ma zostać stworzone, jakie umiejętności są do tego wymagane oraz, krok po kroku, jak powinien wyglądać proces wytwarzania. Rola (Roles) Kto? Rola definiuje zbiór wymaganych umiejętności, kompetencji i odpowiedzialności. Produkt (Work Products) Co? Produkt reprezentuje wynik zadania oraz wszystkie dokumenty i modele utworzone w czasie procesu. Zadanie (Tasks) Jak? Zadanie opisuje jednostkę pracy przypisaną do roli. W ramach każdej iteracji zadania podzielone są na dziewięć dyscyplin: Dyscypliny inżynierskie: Modelowanie biznesowe (Business modeling) Wymagania (Requirements) Analiza i projekt (Analysis and design) Implementacja (Implementation) Testowanie (Test) Wdrożenie (Deployment) Dyscypliny pomocnicze : Zarządzanie zmianami oraz konfiguracją (Configurationand change management) Zarządzanie projektem (Project management) Środowisko (Environment) PRINCE2: wprowadzenie Metodyka zarządzania przedsięwzięciami Główny aktor: kierownik przedsięwzięcia PRINCE = PRojects IN Controlled Environments CCTA = Central Computer and Telecommunications Agency, UK 199: CCTA wprowadza metodę PRINCE 1996: CCTA ogłasza metodę PRINCE2 Projekt definicja PRINCE2 Środowisko zarządcze stworzone w celu dostarczenia jednego lub większej liczby produktów biznesowych zgodnie z określonym Uzasadnieniem Biznesowym. lub Organizacja powołana na określony czas, w celu wytworzenia unikatowych i wcześniej zdefiniowanych wyników lub rezultatów w ustalonym czasie, przy wykorzystaniu uprzednio określonych zasobów. Cykl życia projektu, okres życia produktu a PRINCE2 PRINCE2 obejmuje cykl życia projektu i część przygotowań przed projektem oraz decyzję zezwalającą na rozpoczęcie zainicjowania projektu Pomysł Badania Decyzja Okres życia produktu Okres od momentu pierwszego pomysłu na produkt aż do jego wycofania z eksploatacji Prawdopodobnie w okresie życia produktu dotyczyć go będzie wiele projektów studium wykonalności, wytworzenie, rozwój i udoskonalenia lub korekty. Specyfikacja Projekt Techniczny Wytworzenie Testowanie Przekazanie Ocena efektów Użytkowanie Likwidacja Okres życia projektu Okres od rozpoczęcia projektu aż do przekazania ukończonego produktu tym, którzy będą go eksploatować i utrzymywać Studium wykonalności cykl życia projektu Jeśli wymagane jest opracowanie studium wykonalności w celu zbadania istniejącej sytuacji i określenia wariantów dalszego postępowania, wtedy optymalnym podejściem jest potraktowanie studium wykonalności jako osobnego i niezależnego projektu. Zdefiniowanie problemu Badania Projekt taki to: jeden Plan Projektu jedno Uzasadnienie Biznesowe jeden zbiór zagrożeń (ryzyko) jeden produkt końcowy - rekomendacje Przygotowanie wariantów Przedstawienie rekomendacji 3

4 Struktura zarządzania wg PRINCE 2 Struktura zarządzania wg PRINCE 2 Komitet Sterujący Komitet Sterujący Reprezentant użytkowników Przewodniczący Reprezentant dostawcy Reprezentant użytkowników Przewodniczący Reprezentant dostawcy Nadzór Przedsięwzięcia Raport Plan Nadzór Przedsięwzięcia Raport Plan Kierownik Przedsięwzięcia Kierownik Przedsięwzięcia Zlecenie Raport Wsparcie Przedsięwzięcia Cykl życia wg PRINCE 2 Pierwsza przymiarka Przyg. zał. Proj Inicj. projektu Etap 1 Etap 2 Etap 3 Etap 4 Zamknięcie Cykl życia wg PRINCE 2 Pierwsza przymiarka Przyg. zał. Proj Przyg. założeń projektu SU Inicj. projektu Etap 1 Etap 2 Etap 3 Etap 4 Zamknięcie Inicjowanie projektu IP Zarządzanie etapem zakresem etapu SB Zamknięcie projektu CP Cykl życia wg PRINCE 2 Pierwsza przymiarka Cykl życia wg PRINCE Przyg. zał. Proj Inicj. projektu Etap 1 Etap 2 Etap 3 Etap 4 Zamknięcie Strategiczne zarządzanie projektem DP Przyg. założeń projektu SU Inicjowanie projektu IP Zarządzanie etapem zakresem etapu SB Zamknięcie projektu CP Przyg. założeń projektu SU Inicjowanie projektu IP Zarządzanie etapem zakresem etapu SB Zamknięcie projektu CP Planowanie PL Planowanie PL 4

5 Cykl życia wg PRINCE 2 Procesy PRINCE2 Przyg. założeń projektu SU Strategiczne zarządzanie projektem DP Inicjowanie projektu IP Planowanie PL Zarządzanie etapem zakresem etapu SB Sterowanie etapem CS Zarządzanie wytwarzaniem produktów Zamknięcie projektu CP Przygotowanie Projektu Inicjowanie Projektu Zarządzanie Strategiczne Projektem Sterowanie Etapem Zarządzanie Wytwarzaniem Produktów Zarządzanie Zakresem Etapu Zamykanie Projektu Planowanie Agile Manifesto extreme Programming Manifest Agile (Agile Manifesto, Manifesto for Agile Software Development) to deklaracja wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania. Została opracowana na spotkaniu jakie miało miejsce w dniach lutego 2001 roku w ośrodku wypoczynkowym Snowbird w USA. Treść Manifestu Agile Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywa się lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkłada się: Ludzie i interakcje ponad procesy i narzędzia Działające oprogramowanie ponad obszerną dokumentację Współpracę z klientem ponad formalne ustalenia Reagowanie na zmiany ponad podążanie za planem Według Manifestu Agile docenia się to, co wymieniono po prawej stronie, jednak bardziej ceni się to, co po lewej. XP to paradygmat i metodyka programowania mające na celu wydajne tworzenie małych i średnich "projektów wysokiego ryzyka", czyli takich, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić. Przyświeca temu koncepcja prowadzenia projektu informatycznego, wywodząca się z obserwacji innych projektów, które odniosły sukces. Praktyki XP XPrince Metafora Małe przyrosty Częsta integracja Współwłasność kodu Gra Planistyczna Standard kodowania Kod Testy Programowanie Refaktoryzacja parami Klient w zespole Brak nadgodzin Prosty projekt Test przed kodem XPrince (Extreme Programming in Controlled Environments) zwinna metodyka wytwarzania oprogramowania, której celem jest wyważenie między zwinnością i dyscypliną. Bazuje ona na: XP, PRINCE2 oraz RUP. Słabe strony XP to wymóg, aby klient pracował razem z zespołem, brak dokumentacji papierowej oraz czasami zbyt krótka perspektywa planowania. Celem, który przyświecał stworzeniu metodyki XPrince, było rozwiązanie problemów związanych ze słabościami XP oraz zachowanie adaptacyjności. W związku z tym metodyka ta integruje metodykę zarządzania projektem (PRINCE2) z metodyką wytwarzania oprogramowania (XP). 5

6 XPrince SCRUM a) PRINCE2 b) RUP c) XP d) XPrince Rozwój produktu podzielony na fazy (tzw. Sprinty) trwające kilka tygodni Funkcjonalności zbierane od klienta (user stories), segregowane na sprinty (sprint planning). 15-minutowe spotkania każdego dnia (daily scrum) opisujące zadania na dany dzień i podsumowujące dzień poprzedni (sprint review). Każdy odpowiada na 3 pytania. Działająca wersja wytwarzana po każdym sprincie (musi być widoczna zmiana z poprzedniej wersji). Zapis zmian w rejestrze (sprint backlog) Właściciel produktu ustala priorytety, ustala cel pierwszego przebiegu. (na podstawie tego tworzony jest backlog) Zespół tworzy produkt. Samodzielnie przypisuje zadania do wykonania Scrum master odpowiada za usuwanie problemów oraz poprawną implementacje procesu. Źródło: slajd 40 Charakterystyka SCRUM Samoorganizujące się zespoły Postęp prac nad produktem następuje w miesięcznych sprintach Wymagania są gromadzone w postaci listy rejestru produktu - product backlog Brak narzuconych praktyk inżynierskich Ustalone reguły w celu stworzenia zwinnego środowiska projektowego Jeden z wielu zwinnych procesów Rozwój sekwencyjny a nakładający się Wymagania Projekt Kodowanie Test Zamiast robić każdą rzecz po kolei Źródło: The New New Product Development Game by Takeuchi and Nonaka. Harvard Business Review, January 196. w scrumie robimy wszystkiego trochę Ramy Scrum Ramy Scrum Role Właściciel produktu Mistrz (ScrumMaster) Zespół Rytuały Role Właściciel produktu Mistrz (ScrumMaster) Zespół Rytuały Planowanie sprintu Przegląd sprintu Retrospektywa Codzienny scrum Artefakty Rejestr produktowy Rejestr sprintu Wykres wypalania Planowanie sprintu Przegląd sprintu Retrospektywa Codzienny scrum Artefakty Rejestr produktowy Rejestr sprintu Wykres wypalania 6

7 Właściciel produktu (Product owner) Definiuje funkcjonalności produktu Decyduje o dacie wydania i zawartości Jest odpowiedzialny za dochodowość/ zwrot z inwestycji (ROI) dla produktu Priorytetyzuje funkcjonalności według ich wartości rynkowej. Dostosowuje priorytety w iteracjach Akceptuje wykonanie pracy Mistrz - The ScrumMaster Reprezentuje management w projekcie Odpowiada za wdrażanie praktyk i wartości Scrum Usuwa przeszkody Czuwa nad produktywnością zespołu Ułatwia współpracę pomiędzy funkcjami Chroni zespół przed zewnętrznymi ingerencjami Zespół - The team Zwykle 5-9 osób Wielofunkcyjny Programisci, testerzy, projektanci user experience itd. Członkowie pracują na cały etat Mogą być wyjątki (np. administrator baz danych) Zespół - The team Samoorganizujacy się Idealnie bez tytułów lecz wyjątkowo są one dopuszczalne Skład zespołu może się zmieniać tylko pomiędzy sprintami Ramy Scrum Role Właściciel produktu Mistrz (ScrumMaster) Zespół Rytuały Planowanie sprintu Przegląd sprintu Retrospektywa Codzienny scrum Artefakty Rejestr produktowy Rejestr sprintu Wykres wypalania Wydajność zespołu Rejestr produktowy Warunki biznesowe Właściwy produkt Technologia Spotkanie planistyczne Ustalenie priorytetów Analiza i szacowanie rejestru produktu Wybranie celu sprintu Planowanie sprintu Plan osiągnięcia celu sprintu Przygotowanie rejestru sprintu (zadań) z rejestru produktu (opowieści użytkownika/ funkcjonalności) Estymacja rejestru produktu (h) Cel sprintu Rejestr sprintu 7

8 Planowanie sprintu Codzienny scrum Zespół wybiera pozycje z rejestru produktu, do których wykonania może się zobowiązać Zostaje utworzony rejestr sprintu Zadania zostają zidentyfikowane i każde z nich zostaje estymowane (1- godzin) Planowanie wykonuje cały zespół a nie ScrumMaster Codziennie 15-minut Na Uwzględniony jest projekt całościowy Jako osoba wybierająca się na wakacje chciałbym zobaczyć zdjęcia hoteli. Nie służy do rozwiazywania problemów cały świat mogą tylko członkowie zespołu, ScrumMaster i właściciel produktu Mówić Pomaga w unikaniu dodatkowych spotkań Każdy odpowiada na 3 pytania 1 Co robiłeś wczoraj? Czy coś utrudnia pracę? Przegląd sprintu 2 Odpowiedzi nie są raportem dla ScrumMastera Są 2 godziny przygotowań Brak slajdów Retrospektywa Uczestniczy cały zespół Zapraszamy cały świat deklaracją przed innymi członkami zespołu Zespół prezentuje co osiągnął w sprincie Zazwyczaj ma postać demo nowych funkcji lub architektury Nieformalny Zasada: 3 stojaco Zapraszamy Warstwa funkcjonalna (h) Interfejs użytkownika (4h) Testy jednostkowe (4h) Wykonanie klasy foo (6h) Testy wydajnościowe (4h) Co będziesz robić dzisiaj? Parametry Okresowo, weryfikacja, co działa, a co nie Zwykle minut Po każdym sprincie Uczestniczy cały zespół ScrumMaster Właściciel produktu Zespół Mogą być klienci oraz inni uczestnicy Start / Stop / Kontynuacja Cały zespół przedstawia i omawia co chciałby: Zacząć robić Przestać robić To tylko jeden ze sposobów przeprowadzenia retrospektywy sprintu Kontynuować

9 Ramy Scrum Rejestr produktu Role Właściciel produktu Mistrz (ScrumMaster) Zespół Rytuały Planowanie sprintu Przegląd sprintu Retrospektywa Codzienny scrum Artefakty Rejestr produktowy Rejestr sprintu Wykres wypalania To jest rejestr produktu Wymagania Lista wszystkich pożądanych prac w projekcie Idealnie-zapisane w taki sposób, aby każda pozycja przedstawiała wartość dla użytkownika lub klienta Priorytety ustala właściciel produktu Korekta priorytetów na początku każdego sprintu Przykładowy rejestr produktu Pozycja Estymata Gość może wykonać rezerwację. 3 Jako gość chcę mieć możliwość anulowania rezerwacji. Jako gość chcę zmienić datę rezerwacji. 3 Jako pracownik hotelu chcę mieć możliwość uruchomienia raportu RevPAR (revenue-peravailable-room) Poprawiona obsługa wyjątków Cel sprintu Krótkie zdanie informujące, na jakiej pracy skupimy się podczas kolejnego sprintu Aplikacja bazodanowa Możliwość uruchamiania aplikacji na bazie SQL Server oprócz Oracle Nauki przyrodnicze Wykonanie podstawowych funkcjonalności do badań DNA Usługi finansowe Wsparcie dla większej liczby finansowych wskaźników technicznych niż ma firma ABC Zarządzanie rejestrem sprintu Członkowie zespołu sami wybierają prace, które chcą wykonać Praca nie jest przydzielana odgórnie Praca pozostała do wykonywania jest aktualizowana codziennie Zarządzanie rejestrem sprintu Każdy członek zespołu może dodawać, usuwać lub zmieniać rejestr sprintu Pojawiają się prace do wykonania Jeżeli praca jest niejasna, zdefiniuj pozycję rejestru z większym planowanym czasem, a następnie podziel go na mniejsze fragmenty Aktualizuj rejestr pozostałej pracy w miarę jak coraz więcej jest wiadome 9

10 Rejestr sprintu Wykres wypalania sprintu Zadanie Interfejs użytkownika Pon. Wt. 4 Śr. Czw. Pt. Środkowa warstwa Test środkowej warstwa 11 Napisanie pomocy online 12 Napisanie klasy foo Dodaj log błędów 4 Godziny Zadanie Interfejs użytkownika Środkowa warstwa Test środkowej warstwa Pon. Wt Śr. 10 Czw Pt. Napisanie pomocy online Godziny 10 0 Mon Tue Wed Thu Fri Skalowalność SCRUM Typowy zespół składa się z 7 ± 2 osób Skalowalność poprzez zespoły zespołów Czynniki podczas skalowania Typ aplikacji Rozmiar zespołu Rozproszenie zespołu Czas trwania projektu Scrum był stosowany w projektach, w których uczestniczyło ponad 500 osób DYSKUSJA 10