PROJEKT ZESPOŁOWY WYDZIAŁ MATEMATYKI I INFORMATYKI UŁ

Transkrypt

1 PROJEKT ZESPOŁOWY WYDZIAŁ MATEMATYKI I INFORMATYKI UŁ

2 Uniwersalne metodyki zarządzania projektami PMBoK: Project Management Body of Knowledge - metodyka zarządzania projektami opracowana przez PMI (Project Management Institut) PRINCE2: Project in Controlled Environments - metodyka zarządzania projektami opracowana przez APMG (The Association for Project Management Group) PCM: Project Cycle Management / GOPP: Goal Oriented Project Planning - metodyka zarządzania projektami opracowana dla projektów rozwojowych i europejskich P2M: Project & Program Management System for Enterprise Innovation - metodyka zarządzania projektami opracowana przez japońskie stowarzyszenie EAAJ (Enggineering Advancement of Japan) APM: Agile Project Management - rodzina adaptacyjnych (zwinnych) metodyk zarządzania projektami

3

4 Agile Project Management Problemy definiowania projektu Klienci i użytkownicy nie są pewni czego chcą Klienci mają trudności ze sformułowaniem tego co chcą Wiele szczegółów z tego co klienci na prawdę chcą ujawni się dopiero podczas realizacji projektu Szczegóły wdrożenia na samym początku realizacji są nie do ogarnięcia Wraz z tym jak widzą powstający produkt zmienia się sposób myślenia Siły zewnętrzne (takie jak produkty konkurencji lub usługi) prowadzą do zmian lub rozbudowy wymagań

5 Agile Project Management MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT Odkrywamy lepsze sposoby rozwijania oprogramowania Sami tak działamy i pomagamy innym tak działać. Dzięki tej pracy zauważyliśmy, że bardziej wartościowe są: Osoby i relacje ponad procesy i narzędzia Działające oprogramowanie ponad wyczerpującą dokumentację Współpraca klienta ponad wynegocjowany kontrakt Reagowanie na zmiany ponad realizację planu. Tak to po prawej mamy rzeczy cenne, Jednak te po lewej cenimy bardziej.

6 Agile Project Management PORÓWNANIE PODEJŚCIA TRADYCYJNEGO I ADAPTACYJNEGO Adaptacyjne Tradycyjne Zorientowane na dostarczenie funkcjonalności Zorientowane na podział zadań Plany są hipotezą, a nie przewidywaniem Plany są przewidywaniem odnośnie przyszłości Sukces rozumiany jako zdolność adaptacji do zmieniających się warunków w projekcie Sukces rozumiany jako zgodność z wcześniej założonym planem Duża precyzja planu dla wczesnych iteracji, bardzo zgrubny charakter planu w dalszej fazie projektu Szczegółowy plan opracowany dla całego projektu

7 Agile Project Management PORÓWNANIE PODEJŚCIA TRADYCYJNEGO I ADAPTACYJNEGO Adaptacyjne Tradycyjne Przyczyny odchyleń od planu są analizowane i dostarczają informacji do zmiany planu kolejnych faz projektu (adaptive action) Odchylenia od planu są traktowane jako błędy zarządzania i wymagają bezkrytycznej poprawy (corrective action) Zarządzanie zmianą jest motorem dla procesów innowacyjnych Zarządzanie zmianą często degeneruje się do biurokratycznych procedur blokujących zmianę Zorientowane na stworzenie samoorganizującego się i samodyscyplinującego się zespołu projektowego Zorientowane na procedury i techniki kontroli oraz mikrozarządzanie zadaniami projektowymi

8 Agile Project Management WARTOŚĆ UZYSKANA DZIĘKI ZWINNEMU ZARZĄDZANIU PROJEKTAMI Poprawa Znaczna poprawa Skumulowane Wzrost zdolności do zarządzania zmieniającymi się priorytetami 52% 40% 92% Wzrost produktywności 58% 17% 75% Polepszenie morale zespołów 54% 20% 74% Polepszenie jakości produktów 50% 24% 74% Przyspieszenie czasu wdrożenia na rynek 51% 20% 71% Redukcja ryzyk projektowych 55% 17% 72% Silniejsze relacje IT z celami biznesowymi 44% 22% 66%

9 Agile Project Management RODZINA METODYK ZWINNYCH

10 Agile Project Management XP - EXTREME PROGRAMMING Testowanie Projektowanie Kodowanie Testowanie Kodowanie Wdrożenie Testowanie Projektowanie Projektowanie Wdrożenie Utrzymanie systemu, rozbudowa o nowe funkcjonalności i uaktualnienia już istniejących Kodowanie Wdrożenie

11 Agile Project Management SCRUM - KRYTYKA PODEJŚCIA KASKADOWEGO Trudności w wykorzystaniu modelu kaskadowego: brak możliwości pełnego zrozumienia wymagań przed rozpoczęciem projektu, możliwość rzeczywistego określenia oczekiwań klientów dopiero w momencie otrzymania przez nich wstępnej wersji oprogramowania, częste zmiany wymagań w trakcie Wymagania systemowe Wymagania oprogramowania Analiza Projektowanie Kodowanie procesu tworzenia oprogramowania, zastosowanie nowych narzędzi i technologii utrudniających przewidzenie skutecznej strategii implementacji. Testowanie Działanie

12 Agile Project Management ETAPY DOCHODZENIA DO SCRUM A H. Takeuchi i I. Nonaka, New Product Development Game, Harvard Business Review, 1986 Obserwacja liderów: Fuji-Xerox, Canon, Honda, Epson, Brother, 3M, Xerox, HP Własna holistyczna koncepcja silnie zachodzących na siebie faz realizacji projektu toczących się nie w sposób liniowy, lecz wyłaniających się w postaci iteracyjnych eksperymentów z ciągłych, wzajemnych interakcji międzyfunkcjonalnego zespołu odpowiedzialnego za projekt od początku do zakończenia Podstawowe założenia nowego podejścia: inherentna (nieodłączna) niestabilność, samoorganizujące się zespoły, zachodzące na siebie fazy rozwoju produktu, grupowe uczenie się, subtelna kontrola, organizacyjny transfer wiedzy.

13 Agile Project Management PIERWSZY SCRUM Jeﬀ Sutherland Główny Inżynier, Easel Corporation Ken Schwaber Dyrektor Zarządzający, Advanced Development Methods Sutherland po raz pierwszy zdefiniował role, zatrudnił pierwszego Właściciela Produktu i Szefa SCRUM a, opracował pierwszy wykaz prac produktu, wykaz prac sprintu i zbudował pierwszy portfel produktów stworzonych z wykorzystaniem metodyki SCRUM Prezentacja metody szerokiej publiczności: Sutherland J., Agile Development: Lessons Learned from the First SCRUM, Cutter Agile Project Management Advisory Service, Executive Update, Vol. 5, No. 20, 1993 Wspólny występ na konferencji Object-Oriented Programming, Systems, Languages & Applications, USA, 1995 Schwaber K., Agile Software Development with SCRUM, Microsoft Press, 2004

14 Agile Project Management METODYKA SCRUM

15 Agile Project Management FILARY METODYKI SCRUM Role: właściciel produktu (product owner) szef SCRUM a (scrum master) zespół (scrum team) Ceremonie: spotkanie planowania sprintu (sprint planning meeting) spotkanie przeglądu sprintu (sprint review meeting) codzienne zebrania (daily scrum meetings) Artefakty: wykaz prac produktu (product backlog) wykaz prac sprintu (sprint backlog) Wykres malejący (burndown chart)

16 Role w metodyce SCRUM Właściciel produktu (ang. product owner) Właściciel produktu jest rolą, w której odpowiedzialności znajduje się produkt finalny oraz wszystkie funkcjonalności, które będą dostarczały wartość klientom i użytkownikom. Rola ta zarządza także priorytetami ich implementacji. Głównym zadaniem właściciela produktu jest zapewnienie, że zespół robi właściwe rzeczy, z biznesowego punktu widzenia. Właściciel produktu odpowiada za: dostarczenie przez produkt wartości klientom, identyfikację i definiowanie funkcjonalności produktu, nadanie priorytetów funkcjonalności zgodnie z ich wartością dla klientów, podejmowanie decyzji o datach i zawartości kolejnych wydań produktu, aktualizowanie zestawu funkcjonalności i ich priorytetów w kolejnych sprintach, akceptację lub odrzucenie wykonanej pracy.

17 Role w metodyce SCRUM Zespół (ang. scrum team) Zadaniem zespołu jest wykonanie pracy potrzebnej do dostarczenia działających funkcjonalności produktu wskazanych przez właściciela produktu. W skład zespołu wchodzi zazwyczaj 5 do 9 osób posiadających umiejętności specjalistyczne konieczne do pracy w projekcie i osiągnięcia celów sprintu. W skład zespołu wchodzą zazwyczaj: analitycy, projektanci, programiści, testerzy, administratorzy i inni. Cechy charakterystyczne zespołu SCRUM: Płaska struktura. Samoorganizujący się charakter. Multidyscyplinarny. W całości zaangażowani w pracę. Rezygnacja z wielozadaniowości.

18 Role w metodyce SCRUM Szef scruma (ang. scrum master) Nie pełni roli kierownika, a tym bardziej roli kierownika projektu. Szef scruma jest rolą wspierającą zespół i właściciela produktu w realizacji projektu z sukcesem, odpowiada za zrozumienie i stosowanie zasad metodyki w zespole, wspiera procesy uczenia się. Szef scruma działa na rzecz zespołu i jednym z jego kluczowych zadań jest bycie "buforem" między zespołem a jego bliższym i dalszym otoczeniem, osobą odsuwającą przeciwności, blokującą interwencje z zewnątrz, rozwiązującą problemy mogące utrudnić zespołowi realizację zadeklarowanych celów Szef scruma: zapewnia, że zespół jest gotowy do pracy i produktywny, umożliwia bliską współpracę pomiędzy wszystkimi rolami i funkcjami, usuwa bariery, ochrania zespół przed ingerencjami z zewnątrz, zapewnia, że zespół prowadzony jest zgodnie z metodyką SCRUM.

19 Iteracyjny proces SCRUM

20 Iteracyjny proces SCRUM Proces rozpoczyna Właściciel Produktu. Jego zadaniem jest stworzenie wizji produktu, która następnie przybiera formę listy, składającej się z uporządkowanych zgodnie z priorytetami elementów funkcjonalności tworzonego oprogramowania (ang. product backlog). Metodyka nie specyfikuje sposobu, ani argumentów priorytetyzacji funkcjonalności. Wykaz prac produktu jest jednym dokumentem przedstawiającym jeden, definitywny opis wszystkiego co może być kiedykolwiek zrobione przez zespół, w kolejności ważności. Przykładowe pozycje wykazu prac produktów: Nowe funkcjonalności oprogramowania, Cele związane z poprawą wydajności systemu, Prace rozwojowe i pomysły na innowacje, Prace nad rozwiązaniem znanych usterek.

21 Wykaz prac produktu (product backlog) Wykaz prac produktu (product backlog) Specyfikacja (link wiki) Priorytet Szacowana wartość Wstępny szacunek pracochłonności Jako kupujący chcę móc umieścić książkę w koszyku zakupów Jako kupujący chcę móc usunąć książkę z koszyka zakupów Podnieść wskaźniki wydajności przetwarzania transakcji Rozpoznać możliwości przyspieszenia walidacji kart płatniczych Zaktualizować wszystkie serwery do Apache Zdiagnozować i naprawić błędy skryptu realizacji zamówienia Jako kupujący chcę stworzyć i zapisać listę zakupów Pozycja wykazu Jako kupujący chcę móc dodawać i odejmować pozycje z listy zakupów Paweł Wyrozębski Aktualne szacunki pracy pozostałej do wykonania

22 Wykaz prac produktu w trakcie realizacji projektu Wysoki priorytet Każda iteracja realizuje pozycje o najwyższych priorytetach Modelowanie szczegółowe Każda nowa pozycja jest priorytetyzowana i dodawana do listy Pozycje wykazu mogą w każdym momencie zmienić priorytet Modelowanie ogólne Pozycje wykazu mogą w każdym momencie zostać usunięte Niski priorytet Pozycje wykazu prac produktu

23 Iteracyjny proces SCRUM Spotkanie planowania sprintu (sprint planning meeting) Cel: opracowanie szczegółowego planu dla bieżącej iteracji. Czas: jeden pełny dzień, dwie części po 4 godziny każda. Treść spotkania: Przegląd wizji, mapy drogowej, planu wydań, oraz wykazu prac produktu przez wszystkie trzy role. Zapoznanie się zespołu z opisami pozycji wykazu o najwyższym priorytecie oraz weryfikacja szacunków pracochłonności. Wybór pozycji wykazu przez zespół do realizacji w najbliższej iteracji; Zespół zdejmuje elementy z góry listy priorytetów i podejmuje się ich realizacji w trakcie trwania jednej iteracji (czyli zazwyczaj czterech tygodni roboczych). Po podjęciu decyzji o elementach wchodzących w skład sprintu rozpoczyna się druga część spotkania polegająca na szczegółowym zaplanowaniu zadań i czasochłonności pracy do wykonania.

24 kaz prac printu Wykaz prac sprintu (ang. sprint backlog) Wykaz prac sprintu Pozycja wykazu prac produktu Zadanie sprintu Wstępny Aktualne szacunki pracy szacunek pozostałej do wykonania Ochotnik pracochło nności Zmodyfikować bazę danych 5 Opracować stronę (UI) 8 Jako kupujący chcę Opracować stronę (Javascript) móc usunąć Przygotować automatyczne książkę z koszyka testy akceptacji zakupów Zaktualizować stronę pomocy dla kupującego Zintegrować kod DCP i Podnieść wskaźniki przeprowadzić testy wydajności Zmienić kod DCP i czytnik do przetwarzania wykorzystania prank http API transakcji Paweł Wyrozębski

25 Wykaz prac sprintu (ang. sprint backlog) Wykaz prac sprintu az prac printu Paweł Wyrozębski 358

26 Iteracyjny proces SCRUM SCRUM SPRINT Realizacja SPRINTU: Zakończenie spotkania planowania sprintu rozpoczyna z kolejnym dniem początek pierwszej (i kolejnej) iteracji - SPRINTU. Celem sprintu jest wykonanie zaplanowanej pracy i dostarczenie kompletu funkcjonalności, do których zobowiązał się zespół podczas spotkania. Czas sprintu zależy od decyzji zespołu ale powinien wynosić nie dłużej niż miesiąc (1-4 tyg. robocze). RAZ PRZYJĘTY CZAS TRWANIA SPRINTU JEST NIEZMIENNY PODCZAS REALIZACJI CAŁEGO PROJEKTU! W przypadku niezakończenia pracy w danej iteracji, sprint musi zakończyć się zgodnie z terminem.

27 Iteracyjny proces SCRUM SCRUM powszedni (daily SCRUM) W trakcie sprintu odbywają się dodatkowo CODZIENNE ZEBRANIA (ang. daily scrum meetings), inaczej: spotkania na dzień dobry, scrum powszedni, stand-up meetings. Codziennie o tej samej porze, przed rozpoczęciem pracy, nie dłuższe niż kwadrans. Prowadzone są przez szefa scruma i mają charakter synchronizacji bieżącej wymiany informacji na temat codziennej pracy, wykonanych postępów oraz zauważonych trudności: Co udało się wykonać od ostatniego spotkania (czyli od wczoraj)? Co zamierzam zrobić do kolejnego spotkania (czyli do jutra)? Czy pojawiły się jakieś trudności, przeszkody w mojej pracy? Wśród członków zespołu (Prosiaki - Pigs), którzy jako jedyni mogą zabierać głos obecność jest obowiązkowa. Inni zainteresowani (Kurczaki - Chickens) mogą być obecni, ale bez możliwości wypowiadania się.

28 Iteracyjny proces SCRUM Wykres spalania (sprint burndown chart) Stosowany w celu monitorowania postępów pracy w trakcie sprintu. Postęp mierzony jest względem czasu Wykres spalania pozostałego do zakończenia zadania i opiera (ang. burndown chart) się nasprint jednostkach naturalnych (godziny/dni). Wykres spalania (ang. sprint burndown chart) Informacje o pracy zbierane sąwpodczas Stosowany w celu monitorowania postępów pracy trakcie sprintu spotkań codziennych. Postęp mierzony jest wzgledem czasu pozostałego do zakończenia zadania i opiera się na jednostkach naturalnych (godziny/dni) Informacje o pracy zbierane są podczas spotkań codziennych Pozycja wykazu prac produktu Jako kupujący chcę móc usunąć książkę z koszyka zakupów Zadanie sprintu Wstępny Ochotnik szacunek pracochłonności Aktualne szacunki pracy pozostałej do wykonania Zmodyfikować bazę danych Adam Opracować stronę (UI) Tomasz Opracować stronę (Javascript) Beata Przygotować automatyczne testy akceptacji Zaktualizować stronę pomocy dla kupującego Piotr i Ewa Beata w sumie roboczogodzin: Paweł Wyrozębski Paweł Wyrozębski Źródło: Milewski J., Projektowy młyn, Compu

29 Iteracyjny proces SCRUM Wykres spalania Wykres spalania (sprint burndown chart) (ang. sprint burndown chart) 362 Paweł Wyrozębski Źródło: Milewski J., Projektowy młyn, Computerworld, nr 29/2005

30 Iteracyjny proces SCRUM Zakończenie sprintu Sprint kończy się ZAWSZE zgodnie z przyjętą datą - nawet jeśli zespół przeszacuje lub niedoszacuje ilość pracy w danej iteracji. Zakończenie sprintu związane jest z organizacją dwóch czterogodzinnych spotkań, które odbywają się najczęściej jednego dnia, są to: spotkanie przeglądu sprintu (ang. sprint review meeting) oraz spotkanie retrospektywne (ang. sprint retrospective meeting).

31 Iteracyjny proces SCRUM Zakończenie sprintu Spotkanie przeglądu sprintu Zespół wraz z właścicielem produktu oraz przy wsparciu szefa scruma dokonują przeglądu wszystkiego tego co wydarzyło się w trakcie ostatniej iteracji i dotyczyło opracowywanego produktu: zespół przedstawia wyniki swojej pracy i demonstruje działające funkcjonalności produktu, właściciel produktu ma za zadanie zapoznać się z rozwiniętym produktem i przekazać zespołowi aktualne informacje na temat wizji produktu i stanu rynku. Pozycje z wykazu prac produktu, które zostały wykonane i odebrane w całości zostają wykreślone. Pozycje, które wymagają dalszej pracy nie mogą być prezentowane na spotkaniu i wracają do zestawienia, gdzie będą oczekiwać na zaktualizowane priorytety od właściciela produktu. W spotkaniu mogą brać udział także inne osoby zainteresowane projektem i swobodnie dzielić się swoimi wątpliwościami i propozycjami. Spotkanie trwa nie dłużej niż 4 godziny.

32 Iteracyjny proces SCRUM Zakończenie sprintu Spotkanie retrospektywne sprintu Spotkanie retrospektywne sprintu odbywa się zaraz po zakończeniu przeglądu sprintu i trwa również nie dłużej niż 4 godziny. Jego celem jest zapewnienie ciągłego doskonalenia procesu i uczenia się wszystkich uczestników scruma, tak aby kolejne iteracje toczyły się lepiej i sprawniej od poprzednich. Jest to bardzo ważny element metodyki i nie powinien być pomijany lub marginalizowany. W trakcie spotkania retrospektywnego każdy z uczestników wypowiada się na temat przebiegu ostatniego sprintu odnosząc się do tego co robione było dobrze, do tego co robione było źle oraz jakie zmiany należałoby wprowadzić od kolejnego sprintu. Spotkanie takie może poprowadzić szef scruma, ale dla zachowania neutralności sugeruje się zaproszenie zewnętrznego prowadzącego. Właściciel produktu może w nim uczestniczyć, lecz jego obecność nie jest obowiązkowa.

33 Iteracyjny proces SCRUM Rozpoczęcie nowej iteracji Rozpoczęcie nowego sprintu

34 Rytm SCRUMA RYTM SCRUM a listopad 10 poniedziałek wtorek środa czwartek piątek listopada Spotkanie Planowania Sprintu Scrum codzienny Scrum codzienny Scrum codzienny Scrum codzienny spotkanie przeglądu sprintu + retrospektywa 19 Scrum codzienny Scrum codzienny Scrum codzienny Scrum codzienny Scrum codzienny Scrum codzienny Scrum codzienny Scrum codzienny 29 Spotkanie Planowania Sprintu niedziela Scrum codzienny Scrum codzienny Scrum codzienny Scrum codzienny 8 Spotkanie Planowania Sprintu sobota 30 grudnia spotkanie przeglądu sprintu + retrospektywa 3 Scrum codzienny Scrum codzienny Scrum codzienny Scrum codzienny 367 Paweł Wyrozębski