1 / 136

ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI

ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI. Wrocław, 2013/2014 Opracował i prowadzi dr inż. Jan BETTA ( Zwinne.pptx ) . CELE ZAJĘĆ. C1 Uzyskanie przez Słuchaczy wiedzy na temat klasycznych i adaptacyjnych metodyk zarządzania projektami

dino
Download Presentation

ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI Wrocław, 2013/2014 Opracował i prowadzi dr inż. Jan BETTA (Zwinne.pptx)

  2. CELE ZAJĘĆ C1 Uzyskanie przez Słuchaczy wiedzy na temat klasycznych i adaptacyjnych metodyk zarządzania projektami C2 Nabycie przez Nich wiedzy o funkcjonowaniu i stosowaniu właściwych metod, techniki narzędzi PM C3 Opanowanie umiejętności praktycznego stosowania w/w metod, technik i narzędzi zarządzania rzeczywistym projektem

  3. PLAN ZAJĘĆ I. Metodyki klasyczne (przypomnienie) • Podstawowe pojęcia PM – przypomnienie • PM – stan wiedzy (świat, Polska) 2.1 Metodyka PMI 2.2 Metodyka Prince 2 2.3 Wytyczne kompetencji IPMA (ICB/NCB)

  4. II. Metodyki zwinne (adaptacyjne) • Przegląd:ExtremeProgramming, Crystal, Dynamic Systems Development, RapidApplication Development, Scrum • ScrumMaster • Właściciel produktu • Zespół Scrum • Zdarzenia w Scrum - sprint, planowanie sprintu • Zdarzenia w Scrum - monitorowanie sprintu, sprint ex-post (retrospektywa sprintu) • Artefakty Scrum – rejestr produktu, rejestr sprintu, przyrost funkcjonalności produktu • Podsumowanie wykładu

  5. ŹRÓDŁA (tylko cz. II. - zwinne) • Highsmith J., Agile Project Management, Wydawnictwo MIKOM, Warszawa, 2005 • Schwaber K., Sprawne zarządzanie projektami metodą Scrum, Microsoft Press, Warszawa, 2005 • Charvat J., Project Management Methodologies, John Wiley & Sons, New Jersey, 2003 • Manifesto for Agile Software Development, http://agilemanifesto.org/

  6. Metodyki zwinne - przegląd Adaptacyjne zarządzanie projektami (ang. Agile Project Management, APM) to zbiór różnych metodyk, określanych jako zwinne bądź lekkie, i narzędzi stosowanych w zarządzaniu złożonymi i innowacyjnymi projektami - głównie informatycznymi (m.in. w zakresie inżynierii oprogramowania). Obecnie – projekty badawcze?

  7. Dynamiczny rozwój adaptacyjnego zarządzania projektami rozpoczął się w 2001 roku, - dokument Manifesto for Agile Software Development, który zainicjował głębokie przemiany w środowiskach programistycznych, a następnie przeniknął w niektóre obszary zarządzania projektami. Powstanie APM było w dużej mierze reakcją na mało elastyczne metody zarządzania projektami informatycznymi.

  8. Manifest Agile(Manifest Zwinnego Wytwarzania Oprogramowania)  Jest to deklaracja wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania. Została opracowana na spotkaniu jakie miało miejsce w dniach 11-13 lutego 2001 roku w ośrodku wypoczynkowym Snowbird w USA (stan Utah). Uczestniczyli w nim reprezentanci nowych metodyk tworzenia oprogramowania będących alternatywą dla tradycyjnego podejścia opartego na modelu kaskadowym (sekwencyjnym).

  9. Deklaracja programowa twórców tych metod jest nazwana Manifestem Agile (Manifesto for Agile Software Development, 2001).Manifest ten jest skrótowym opisem celu, dla którego zostały one stworzone. „Odkrywamy coraz to lepsze sposoby tworzenia oprogramowania, robiąc to i pomagając innym to robić. W tej pracy zaczęliśmy szczególnie cenić:

  10. Ludzi i wzajemne interakcje ponad procedury i narzędzia • Działające oprogramowanieponad wyczerpującą dokumentację • Współpracę z klientem ponad negocjowanie kontraktów • Reagowanie na zmiany ponad trzymanie się planu”

  11. Zespoły prowadzące projekty o zmiennym zakresie muszą charakteryzować się zdolnościądo adaptacji (agility). Sprowadza się to do posiadania umiejętnosci wytwarzania posiadanego produktu i jednoczesnego reagowania na zmiany i oczekiwania biznesowe. Tym samymjedną z podstawowych różnic w stosunku do tradycyjnych technik jest podejście do odchyleń w pierwotnym planie.

  12. Metodyka Agile zakłada, że plan projektu jest przewodnikiem do przyszłości, a nie “samą przyszłością”. A zatem odchylenia od planu nie są traktowane jako błędy,ale –przeanalizowane- są podstawą do zmian w planie dalszych faz projektu. Tym samym strony wdrożenia przedkładają wzajemną kooperację, rozumianą jako dostosowywanie się do zmian, nad sztywne trzymanie się kontraktu. To z kolei wymaga odpowiedniego podejścia do kwestii kosztów, które rosną wraz z poszerzeniem zakresu wdrożenia.

  13. Z punktu widzenia techniki Agile definiowanie sztywnych ram projektowych w zakresie umowy nie ma sensu. Istnieje bowiem ryzyko, że takie zapisy będą interpretowane w niekorzystny dla sukcesu projektu sposób. Klienci mają bowiem skłonności do niekontrolowanego poszerzania zakresu funkcjonalnonalności często “na zapas”, co z kolei przez dostawcęjest interpretowane jako niekorzystna próba reinterpretacji umowy. Dyskusja o zakresie zostaje więc przeniesionana ścieżkę wojenną- klient chce jak najwięcej,nawet jeśli nie potrzebuje; dostawca stara się ograniczyć swoje zaangażowanie. Efektem są zakłócenia w przebiegu projektu.

  14. Podejście Agilezakłada, że •  lista procesów i funkcjonalności systemu może zmieniać się z czasem i potrzebami biznesowymi klienta i rekomendacjami firmy wdrożeniowej • klienci mogą nie znać na początku projektu wszystkich możliwości systemu a co za tym idzie, mogą dopiero po pewnym czasie wyrazić potrzebę przemodelowaniaswoich procesów, poprzez taką modyfikację funkcjonalności lub zmianę sposobudziałnia firmy, które pozwolą na ograniczenie kosztów wewnętrznych • zmiany w zakresie, terminach i kosztach traktowane są przez obie strony jako naturalny element projektu 

  15. Cechy charakterystyczne Agile Proces wdrożenia metodą adaptacyjną jest   • iteracyjny i ewolucyjny - umożliwiający przystosowanie do zmian wewnętrznych i zewnętrznych  • modułowy i wyszczuplający, umożliwiajcąy usuwanie albo dodawanie poszczególnych elementów procesu w zależności od potrzeb interesariuszy • koncentrujący się na istotnych funkcjonalnościach, •  oparty na cyklach zawierających informację zwrotną i wskazówki do wykorzystania w następnym cyklu

  16. Członkowie zespołu winni podzielać następujące wartości • prostota - dla istotnych czynników sukcesu staramy się znaleźć najprostsze możliwe rozwiązanie • komunikacja - dbamy o stały i wysoki poziom komunikacji w zespole, • informacja zwrotna (feedback) • odwaga - istotna do podejmowania ważnych decyzji • pokora - nie jesteśmy wszechwiedzący i trzeba czasem uzupełnić swoją wiedzę

  17. Agile Project Management, czyli zarządzanie adaptacyjne, wymaga od obu stron dużej dozy zaufania. Jeżeli partnerzy projektowi chcą pracować w oparciu o jej założenia, można się spodziewać sukcesu. Jednak w przypadku, gdy jedna ze stron ma zastrzeżenia co do sposobu prowadzenia projektu, bezpieczniej jest poprowadzić projekt metodą tradycyjną.

  18. Agile Project Management zdecydowanie różni się od podejścia tradycyjnego, inne są również rola i zakres odpowiedzialności kierownika projektu. Dotychczasowe praktyki zarządzania projektem polegające na jednoosobowej odpowiedzialności za projekt, szczegółowym planowaniu, rozdzielaniu zadań i rozliczaniu z postępów prac, ustępują miejsca szerokiej i aktywnej współpracy z klientem, kolektywnej odpowiedzialności za sukces projektu oraz planowaniu i realizacji projektu pod kątem osiąganej wartości oraz adaptacji do zmian.

  19. System sześciu zasad APM Wartość dla klienta poprzez innowacyjne produkty • Dostarczaj wartość klientowi • Zastosuj wytwarzanie iteracyjne oparte na dostarczaniu elementów funkcjonalnych • Promuj doskonałość techniczną Przywódczo-partycypacyjny styl zarządzania • Zachęcaj do badań • Buduj adaptacyjne zespoły • Upraszczaj

  20. Pozostałe zasady i cele stosowania zwinnych metodyk w ramach zarządzania projektami • elastyczność i adaptacyjność projektowania względem dynamicznie zmieniających się potrzeb i oczekiwań klienta (stąd termin zwinne - ang. agile) • tworzenie wartościowych i innowacyjnych rozwiązań zarówno dla firmy jak i klientów na każdym etapie projektowania • minimalizacja kosztów m.in. dzięki skróceniu harmonogramu procesu wytwarzania

  21. koncentracja na członkach zespołu projektowego, wzrost motywacji pracowników i bezstresowa realizacja projektów • ścisła współpraca z klientem - preferowany jest kontakt bezpośredni • prostota i samoorganizujące się zespoły • satysfakcja klienta dzięki szybkiemu i regularnemu dostarczaniu wartościowego produktu • minimalizacja ryzyka 16.04.

  22. ExtremeProgramming (XP) Methodology- główny nacisk kładziony jest na sposób prowadzenia prac projektowych związanych z programowaniem: • Bazuje na iteracjach, obejmujących proste projektowanie, testowanie i ciągłą integrację • Proponuje skuteczne (proste) techniki przyjmowania założeń, działań i ról w projekcie

  23. Opiera się na czterech podstawowych zasadach: komunikacja, feedback, prostota i … odwaga • Koncentracja na zaspokojeniu potrzeby biznesowej • Fazy procesu XP służą planowaniu celów • Koncentracja na tworzeniu kodów • Mało uwagi na dokumentację • Duża przestrzeń dla swobody i kreatywności twórców

  24. Skupienie na redukcji kosztów • Nie nadaje się dla dużych projektów • Główne praktyki XP: • Testowanie • Programowanie w parach • Używanie kart CRC (Class, Responsibility, Collaboration) • Możliwość stosowania XP łącznie z innymi metodologiami

  25. CrystalMethodologies- rodzina • Podział: białe (jasne), żółte, pomarańczowe, brązowe, niebieskie, fioletowe • Koncentracja na wartości: „komunikacja, ludzie, produkty i samoadaptacja” • Główne elementy metodologii dotyczą: działania oprogramowania i komunikacji interpersonalnej • Koncentracja na czynnikach sukcesu projektu oraz zapewnieniu zespołowi warunków pozwalających na kreatywną i ciekawą pracę

  26. Zastosowanie do małych projektów • Redukcja dokumentacji • „lessonslearned” (w tym nieformalne doświadczenia) • Tworzenie oprogramowania grą zespołową – stałe współdziałanie dla osiągnięcia celu – dostarczenie oprogramowania • Dwie zasady Crystal: • Wspólne pomieszczenia robocze • Komunikacja face-to-face

  27. Dynamic Systems Development Methodology • Wielka Brytania • Używa wielokrotnego prototypowania, aby dostarczyć produkt projektu • Czas i zasoby są ustalone • Zmienna jest funkcjonalność rezultatów • Zazwyczaj jest odwrotnie • Nacisk na szybkie znajdowanie rozwiązań • Czas jest nadrzędnym celem, przy zachowaniu wymogów jakościowych • Prostota, praktyczność i elastyczność rozwiązań dla interesariuszy

  28. RapidApplication Development Methodology Tradycyjne metodologie tworzenia oprogramowania: • Identyfikacja potrzeb klienta/użytkownika • Sformułowanie specyfikacji i wymogów (funkcjonalnych oraz technicznych) • Tworzenie oprogramowania • Testowanie To wszystko trwa – RAD skraca postępowanie Problem: zmiany w technologii wytwarzania produktu. Konsekwencja: wymagana dynamika/elastyczność podejścia PM

  29. RAD dokonuje scalenia/kompresji czterech faz w dynamiczne serie krótkich, iteracyjnych cykli • RAD używa krótkich faz w projekcie – wyniki są osiągane szybciej • Niemal natychmiastowe wyniki – konkretny produkt (do dopracowania) • Tworzenie rozwiązania/produktu, doskonalonego, aż do satysfakcji klienta

  30. Cechy metodologii RAD • Tworzenie zespołów mniejszych niż przeciętnie • Zintegrowany (mieszany) skład zespołów projektowych • Analiza, projektowanie, wytwarzanie i testowanie są skompresowane w dynamiczną serię krótkich, iteracyjnych cykli • Zadania są wykonywane raczej współbieżnie aniżeli sekwencyjnie • Fazy projektu są krótkie, cykliczne i nadzwyczaj dynamiczne • Krótsze fazy dają szybsze osiąganie korzyści

  31. Kolejne wersje produktu uwzględniają potrzeby klienta - każdy cykl dostarcza funkcjonalną wersję rozwiązania • Wersje produktu nie są pełnym prototypem, raczej roboczą wersją • RAD bierze pod uwagę zmiany technologiczne i podejmuje szybkie decyzje • Metodologia polega na zmianach inkrementalnych, prowadzących do końcowego produktu • Zespół projektowy rozumie nieuchronność zmian

  32. Metodologia klasycznaRADRys. 1. Metodologia klasyczna vs. RAD Inicjowanie Planowanie Analiza Projekt Tworzenie Testy Produkt Analiza Projekt Tworzenie Przywództwo Inicjowanie Planowanie Produkt Testy Przegląd klienta Zespół

  33. ScrumMethodology Scrum: Zwinna metodyka zarządzania złożonymi projektami Elementy: role, zdarzenia, artefakty, zbiory reguł Autorzy: Ken Schwaber, Jef Sutherland Cechy: lekka, łatwa do zrozumienia, trudna do opanowania

  34. Scrum: • jest ramowym zestawem sposobów postępowania, umożliwiających stosowanie różnych technik i procesów • umożliwia doskonalenie praktyk zarządczych i inżynierskich

  35. Teoria Scruma bazuje na empiryzmie. Podejście iteracyjne i przyrostowe  lepsza przewidywalność i kontrola ryzyk Zasady kontroli empirycznej procesu: przejrzystość, inspekcja, adaptacja

  36. Przejrzystość: wszystkie aspekty procesu są opisane powszechnie znanymi standardami Inspekcja: rozsądnie częsta, dotyczy artefaktów i postępów na ścieżce prowadzącej do celu Adaptacja: aspekt procesu przekroczył ustalone limity  jak najszybsza korekta procesu/materiału Cztery punkty inspekcji i adaptacji

  37. Planowanie sprintu (Sprint PlanningMeeting) • Codzienny Scrum (DailyScrum) • Przegląd sprintu (Sprint Review) • Retrospektywa sprintu (Sprint Retrospective) Role: Zespół Scrumowy (Scrum Team) • Scrum Master • Właściciel Produktu (ProductOwner) • Zespół Deweloperski (Development Team)

  38. Scrum Master: odpowiada za rozumienie i stosowanie teorii Scruma przez Zespół Scrumowy; wspiera Właściciela Produktu, Zespół Deweloperski i całą organizację Właściciel Produktu: maksymalizacja wartości dodanej produktu i pracy Zespołu Deweloperskiego Zespół Deweloperski (projektowy): profesjonaliści, dostarczający na koniec każdego sprintu produktu, gotowego do wydania przyrostu

  39. Zdarzenia w Scrumie: służą regularności i ograniczania potrzeby dodatkowych spotkań. Każde zdarzenie to okazja do inspekcji i adaptacji. Sprint: esencja Scruma;  1 miesiąc; wytwarzany przyrost potencjalnie gotowej funkcjonalności; stała długość. Sprint: planowanie sprintu, codzienne Scrumy, okres wytwarzania, przegląd sprintu, retrospektywa sprintu.

  40. Planowanie sprintu: spotkanie max. 8 h, cały Zespół Scrumowy; co ma być dostarczone, jaką pracę trzeba wykonać. Codzienny Scrum: codzienne, 15 min. spotkanie, tylko Zespół Deweloperski Przegląd sprintu: spotkanie na koniec Sprintu, inspekcja, ew. dostosowanie Rejestru Produktu Retrospektywa sprintu: Zespół Scrumowy robi inspekcję swych działań, plan usprawnień dla kolejnego sprintu. Po przeglądzie.

  41. Artefakty Scruma: wyniki pracy lub jej wartości, aby możliwe były inspekcja i adaptacja: • Rejestr Produktu: uporządkowany zestaw wszystkich elementów produktu; jedyne źródło wymaganych zmian. • Rejestr sprintu: zbiór elementów Rejestru Produktu wybranych do sprintu plus plan dostarczenia Przyrostu i realizacji celu sprintu.

  42. Przyrost funkcjonalności: łączne elementu Rejestru Produktu zakończone podczas sprintu i sprintów poprzednich. Definicja Ukończenia (elementu Rejestru Produktu albo Przyrostu): jednoznaczność rozumienia. Reguły wiążą ze sobą i definiują relacje między rolami, zdarzeniami i artefaktami. Scrum istnieje tylko w swej pełnej postaci – wszystkie role, zdarzenia, artefakty i reguły.

  43. ScrumMaster • Odpowiednik Kierownika Projektu • Odpowiedzialność: proces SCRUM • Proces: definiuje zasady, warunki zaspokojenia potrzeb, artefakty i terminologię • Rola pasterza – utrzymać stado w całości, a wilki przegonić 23.04.

  44. Firma 1. Sytuacja początkowa • Firma tworzy oprogramowanie do generowania kodu • Zła sytuacja finansowa (wysokie koszty) ScrumMaster w akcji: • Propagowanie SCRUM • Zwalczanie postaw szkodzących („ciągotki” ku staremu)

  45. Zachęcanie właściciela produktu do stosowania SCRUM – konflikt interesów – przekonanie go Wartość roli ScrumMaster • Godzenie różnych oczekiwań poprzez sprinty • Blokowanie wpływów zewnętrznych podczas sprintu • Zmiana priorytetów prac zespołu • Szybkie reagowanie na rosnące potrzeby klienta

  46. Rola ScrumMaster • Różna od roli PM • Odpowiada za sukces projektu: • Pomoc właścicielowi produktu w wyborze najbardziej wartościowych zaległości; pomoc zespołowi w przetworzeniu ich w funkcjonalności • Władza pośrednia, oparta na wiedzy SCRUM • Zasady pracy – łatwe, wdrożenie - trudne

  47. Trudności • Interpretacja Scrum przez pryzmat dotychczasowych doświadczeń • Niezrozumienie zasad samoorganizacji, krytycznych sytuacji, widoczności i cyklów inspekcji z adaptacją • Niezrozumienie zmiany paradygmatów: • Kontrola – przekazywanie uprawnień • Kontrakty – współpraca • Dokumentacja - kodowanie

  48. Firma 2. Niekompetentny ScrumMaster • Działalność: pozyskiwanie kultur tkanek ze służby zdrowia – przekazywanie firmom farmaceutycznym • Wartość dodana: spis, demografia, rodzaje chorób i ich zaawansowanie • Błąd: „jego Scrum”, on zlecał zadania członkom zespołu

  49. Lessonslearned Teoria codziennego spotkania SCRUM • Co zrobiłem od ostatniego Scrum? • Co zamierzam zrobić przed następnym Scrum? • Co mi przeszkadza w pracy? Zła interpretacja • Sprawdzanie, czy członkowie zespołu „to” zrobili • Narzucenie im, co mają zrobić przed kolejnym Scrum • Sprawdzenie, co może zrobić, aby usunąć przeszkody

More Related