zaawansowane zarzĄdzanie projektami
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/1.jpg)
ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI
Wrocław, 2013/2014
Opracował i prowadzidr inż. Jan BETTA
(Zwinne.pptx)
![Page 2: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/2.jpg)
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
![Page 3: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/3.jpg)
PLAN ZAJĘĆ
I. Metodyki klasyczne (przypomnienie)1. Podstawowe pojęcia PM – przypomnienie2. PM – stan wiedzy (świat, Polska)2.1 Metodyka PMI2.2 Metodyka Prince 22.3 Wytyczne kompetencji IPMA (ICB/NCB)
![Page 4: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/4.jpg)
II. Metodyki zwinne (adaptacyjne)1. Przegląd: Extreme Programming, Crystal, Dynamic
Systems Development, Rapid Application Development, Scrum
2. ScrumMaster3. Właściciel produktu4. Zespół Scrum 5. Zdarzenia w Scrum - sprint, planowanie sprintu6. Zdarzenia w Scrum - monitorowanie sprintu, sprint ex-
post (retrospektywa sprintu)7. Artefakty Scrum – rejestr produktu, rejestr sprintu,
przyrost funkcjonalności produktu 8. Podsumowanie wykładu
![Page 5: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/5.jpg)
ŹRÓDŁA (tylko cz. II. - zwinne)1. Highsmith J., Agile Project Management,
Wydawnictwo MIKOM, Warszawa, 20052. Schwaber K., Sprawne zarządzanie
projektami metodą Scrum, Microsoft Press, Warszawa, 2005
3. Charvat J., Project Management Methodologies, John Wiley & Sons, New Jersey, 2003
4. Manifesto for Agile Software Development, http://agilemanifesto.org/
![Page 6: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/6.jpg)
1. 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?
![Page 7: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/7.jpg)
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.
![Page 8: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/8.jpg)
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).
![Page 9: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/9.jpg)
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ć:
![Page 10: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/10.jpg)
Ludzi i wzajemne interakcje ponad procedury i narzędzia
Działające oprogramowanie ponad wyczerpującą dokumentację
Współpracę z klientem ponad negocjowanie kontraktów
Reagowanie na zmiany ponad trzymanie się planu”
![Page 11: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/11.jpg)
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 samym jedną z podstawowych różnic w stosunku do tradycyjnych technik jest podejście do odchyleń w pierwotnym planie.
![Page 12: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/12.jpg)
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.
![Page 13: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/13.jpg)
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 przeniesiona na ś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.
![Page 14: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/14.jpg)
Podejście Agile zakł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ę przemodelowania swoich procesów, poprzez taką modyfikację funkcjonalności lub zmianę sposobu dział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
![Page 15: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/15.jpg)
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
![Page 16: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/16.jpg)
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ę
![Page 17: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/17.jpg)
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ą.
![Page 18: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/18.jpg)
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.
![Page 19: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/19.jpg)
System sześciu zasad APMWartość dla klienta poprzez innowacyjne produktyDostarczaj wartość klientowiZastosuj wytwarzanie iteracyjne oparte na
dostarczaniu elementów funkcjonalnychPromuj doskonałość technicznąPrzywódczo-partycypacyjny styl zarządzaniaZachęcaj do badańBuduj adaptacyjne zespołyUpraszczaj
![Page 20: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/20.jpg)
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
![Page 21: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/21.jpg)
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.
![Page 22: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/22.jpg)
Extreme Programming (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
![Page 23: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/23.jpg)
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ówMało uwagi na dokumentacjęDuża przestrzeń dla swobody i kreatywności
twórców
![Page 24: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/24.jpg)
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
![Page 25: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/25.jpg)
Crystal Methodologies - rodzinaPodział: białe (jasne), żółte, pomarańczowe,
brązowe, niebieskie, fioletoweKoncentracja na wartości: „komunikacja, ludzie,
produkty i samoadaptacja”Główne elementy metodologii dotyczą: działania
oprogramowania i komunikacji interpersonalnejKoncentracja na czynnikach sukcesu projektu oraz
zapewnieniu zespołowi warunków pozwalających na kreatywną i ciekawą pracę
![Page 26: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/26.jpg)
Zastosowanie do małych projektówRedukcja dokumentacji„lessons learned” (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
![Page 27: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/27.jpg)
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
![Page 28: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/28.jpg)
Rapid Application Development MethodologyTradycyjne metodologie tworzenia oprogramowania: Identyfikacja potrzeb klienta/użytkownika Sformułowanie specyfikacji i wymogów
(funkcjonalnych oraz technicznych) Tworzenie oprogramowania TestowanieTo wszystko trwa – RAD skraca postępowanie Problem: zmiany w technologii wytwarzania produktu.Konsekwencja: wymagana dynamika/elastyczność
podejścia PM
![Page 29: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/29.jpg)
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
![Page 30: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/30.jpg)
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
![Page 31: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/31.jpg)
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
![Page 32: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/32.jpg)
Metodologia klasyczna
RAD
Rys. 1. Metodologia klasyczna vs. RAD
Inicjowanie Planowanie Analiza Projekt Tworzenie Testy Produkt
Inicjowanie Planowanie Produkt
Analiza Projekt
TworzenieTesty
Przegląd klienta
Zespół
Przywództwo
![Page 33: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/33.jpg)
Scrum Methodology
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
![Page 34: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/34.jpg)
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
![Page 35: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/35.jpg)
Teoria Scruma bazuje na empiryzmie.
Podejście iteracyjne i przyrostowe lepsza przewidywalność i kontrola ryzyk
Zasady kontroli empirycznej procesu: przejrzystość, inspekcja, adaptacja
![Page 36: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/36.jpg)
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
![Page 37: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/37.jpg)
Planowanie sprintu (Sprint Planning Meeting)
Codzienny Scrum (Daily Scrum)
Przegląd sprintu (Sprint Review)
Retrospektywa sprintu (Sprint Retrospective)
Role: Zespół Scrumowy (Scrum Team)
Scrum Master
Właściciel Produktu (Product Owner)
Zespół Deweloperski (Development Team)
![Page 38: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/38.jpg)
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
![Page 39: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/39.jpg)
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.
![Page 40: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/40.jpg)
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.
![Page 41: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/41.jpg)
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.
![Page 42: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/42.jpg)
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.
![Page 43: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/43.jpg)
![Page 44: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/44.jpg)
2. ScrumMasterOdpowiednik Kierownika ProjektuOdpowiedzialność: proces SCRUMProces: definiuje zasady, warunki zaspokojenia
potrzeb, artefakty i terminologięRola pasterza – utrzymać stado w całości,
a wilki przegonić23.04.
![Page 45: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/45.jpg)
Firma 1.Sytuacja początkowaFirma tworzy oprogramowanie do
generowania koduZła sytuacja finansowa (wysokie koszty)ScrumMaster w akcji:Propagowanie SCRUMZwalczanie postaw szkodzących („ciągotki” ku
staremu)
![Page 46: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/46.jpg)
Zachęcanie właściciela produktu do stosowania SCRUM – konflikt interesów – przekonanie go
Wartość roli ScrumMasterGodzenie różnych oczekiwań poprzez sprintyBlokowanie wpływów zewnętrznych podczas
sprintuZmiana priorytetów prac zespołuSzybkie reagowanie na rosnące potrzeby
klienta
![Page 47: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/47.jpg)
Rola ScrumMasterRóżna od roli PMOdpowiada 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 SCRUMZasady pracy – łatwe, wdrożenie - trudne
![Page 48: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/48.jpg)
TrudnościInterpretacja 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
![Page 49: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/49.jpg)
Firma 2. Niekompetentny ScrumMasterDział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
![Page 50: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/50.jpg)
Lessons learnedTeoria codziennego spotkania SCRUMCo zrobiłem od ostatniego Scrum?Co zamierzam zrobić przed następnym Scrum?Co mi przeszkadza w pracy?Zła interpretacjaSprawdzanie, czy członkowie zespołu „to” zrobiliNarzucenie im, co mają zrobić przed kolejnym ScrumSprawdzenie, co może zrobić, aby usunąć przeszkody
![Page 51: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/51.jpg)
PominąłPrzejście: szef – trener (coach)Przejście: kontrola – ułatwienia Lekceważenie roli samoorganizacji demotywacja
członków zespołuFirma 3. Niekompetentny ScrumMasterDziałalność: sprzedaż oprogramowania do
planowaniaStosowane podejście: klasyczne (sekwencyjne)Efekt – wydłużające się terminyBłąd: niezrozumienie roli „owczarka”
![Page 52: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/52.jpg)
Lessons learnedScrumMaster nie zrozumiał swej roli
„ułatwiacza” zamiast menedżera, roli „owczarka” zamiast „rozkazodawcy”
Przejście „władza” – „ułatwiacz” stanowi problem dla wielu
Zespół potrzebuje ochrony, pomocy, a nie nakazów i rozliczeń
ScrumMaster liderem, a nie kierownikiem
![Page 53: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/53.jpg)
Firma 4. Nadgorliwy ScrumMasterDziałalność: sprzedaż oprogramowania dla
służby zdrowiaProblem: konkurencja firm internetowych,
pośrednicy klient-służba zdrowiaRozwiązanie – Firma 4.com; internet; portal
połączony z istniejącymi w Firmie 4 systemami kilka dużych projektów (m.in. dot. stosunków społecznych)
![Page 54: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/54.jpg)
BłędyNieuwzględnienie kultury firmyNieuwzględnienie priorytetówNarzucanie metody Scrum wbrew woli kierownictwa
firmyNietrzymanie nerwów na wodzyLessons learnedNieudana ocena wartości pracy zespołowej w firmie „Scrum dotyczy rzeczy możliwych. Martwy owczarek
jest niepotrzebny”
![Page 55: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/55.jpg)
Firma 5. WilkiDziałalność: zarządzanie funduszamiProblem: przegapienie rewolucji
technologicznej (internet, komórki, mobilne technologie samodzielność klientów)
Koło ratunkowe CMM (Capability Maturity Model – pomyłka)
Rozwiązanie skuteczne - Scrum
![Page 56: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/56.jpg)
Atak wilkówIngerencja „z boku” – naruszenie zasad ScrumEfekt1: raportowanie prac nie związanych ze
Sprintem ani z zaległościami produktowymiEfekt2: pogwałcenie podstawowej reguły
Scrum – autonomii zespołuEfekt 3: zrozumienie i ekspiacja osoby
odpowiedzialnej za zamieszanie
![Page 57: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/57.jpg)
Lessons learnedZnaczenie uwidoczniania wszystkiego na
bieżącoZaległości produktowe + priorytety
powszechnie dostępneRola codziennego Scrum w tym uwidocznianiu
– ScrumMaster może stosować reguły, a zespół pozostać na właściwej ścieżce
![Page 58: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/58.jpg)
PodsumowanieKto walczy, kto jest kibicem? Świnią
czy kurczakiem? Zobowiązania a zaangażowanie? Szynka czy jajka?
Podsumowanie roli ScrumMaster Usuwa bariery między
projektantami/wykonawcami, a właścicielem produktu
Uczy właściciela produktu maksymalizacji zwrotu kosztów i osiągania swych celów przy pomocy Scrum
![Page 59: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/59.jpg)
Poprawa życia zespołu poprzez ułatwianie pracy twórczej
Poprawa wydajności zespołu – wszelkie akceptowalne sposoby
Poprawa inżynierii – aby każdy przyrost funkcjonalności był możliwy do wydania
Udostępnianie aktualnych informacji o postępach zespołu wszystkim interesariuszom
Zakaz bycia klasycznym kierownikiem Korzystanie z kilku pierwszych Sprintów, aby
wdrożyć się w rolę07.05.
![Page 60: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/60.jpg)
3. Właściciel produktu Realizacja zwrotu wartości zainwestowanej Zaległości produktowe – główne narzędzie
kierowania projektem sprint po sprincie, aby maksymalizować zysk
Zaległości produktowe – możliwość nadania priorytetów wymaganiom o najwyższej wartości biznesowe; adaptacja produktu do zmian (klient, biznes, konkurencja)
![Page 61: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/61.jpg)
Firma 6.Sytuacja początkowaWłaściciel rurociągów (gaz, paliwa, ropa) –
wynajem (Ameryka Płn.)Bardzo duża firmaTantiemy dla prywatnych właścicieli gruntówProblem: częste zmiany właścicielskie;
archaiczna („ręczna”) metoda ustalania adresów aktualnych właścicieli (czaso- i kosztochłonna)
![Page 62: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/62.jpg)
Inny problem: różne prawo/procedury właścicielskie w różnych stanach
Decyzja: ScrumWłaściciel produktu w akcji:Ustalił priorytety: proces automatyzacji przed
przeniesieniem danych między serweramiPierwsze sprinty – mniej biznesowej funkcjonalności
(rozruch trwa i kosztuje)Aktualizacja bazy o niezbędne dane
![Page 63: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/63.jpg)
Automatyzacja zasilania bazy danych, scenariusze rozstrzygania konfliktów redukcja i automatyzacja pracy
Satysfakcjonujący przyrost produktu po pierwszym sprincie
Dwutygodniowy sprint implementujący ten przyrost zmniejszenie obciążenia pracą członków oddziału ds. własności gruntów o 40%
![Page 64: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/64.jpg)
Wartość roli właściciela produktuOdpowiada za zwrot kosztów inwestycji
wybór funkcjonalności, rozwiązującej zasadnicze problemy biznesowe
Wzywa do wydania innych funkcjonalności, w miarę potrzeb i możliwości
Zwrot kosztów inwestycji w krótkim czasie
![Page 65: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/65.jpg)
Rola właściciela produktuCiągła współpraca z zespołemCiągła współpraca ze ScrumMaster, który jest
buforem między nim a zespołem programistów i klientami („ułatwiaczem”)
Zwrot kosztów inwestycji w krótkim czasie
![Page 66: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/66.jpg)
Firma 7. Przywracanie zarządu do działania Działalność: średniej wielkości sprzedawca
oprogramowania; wielu małych klientówSytuacja: powierzenie stworzenia kolejnej
wersji oprogramowania (poprzednia nie była gotowa)
Metoda: CPM i Gantt, potem decyzja: ScrumRozwiązanie skuteczne – ScrumSpotkanie przeglądu sprintu (7 zespołów);
udział „top management” firmy
![Page 67: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/67.jpg)
Lessons learnedZastąpienie formalnego raportowania –
współpracąKilkugodzinne spotkania z zarządem firmySpotkania „top management”
podsumowująco/oceniające współpracę SUPER!
![Page 68: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/68.jpg)
Firma 5. Naprawa problemu XFlowUkryty w cieniu „X” - właściciel produktu
Dlaczego to zrobił? Jak to zrobił?
Konflikt inżynierowie (rentowność)-wewnętrzni klienci (problemy operacyjne)
Czy pomocne byłyby spotkania obu grup? – problem: żadna z nich nie dawała X prawa nadawania priorytetów
![Page 69: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/69.jpg)
RozwiązanieSpotkanie obu grupKomunikacja bezpośrednia – argumentacjaWyjście naprzeciw oczekiwaniom drugiej
strony – szukanie kompromisów – zrozumienie podejścia przez obie grupy
Skupienie się X na kluczowym podejściu Scrum: najpilniejsze potrzeby, najbliższa przyszłość, krótkoterminowy plan działań
![Page 70: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/70.jpg)
Wybór 7 elementów i 3 błędów do naprawy – 30 dni – akceptacja przez wszystkich
Po tym sprincie prezentacja wyników klientom wewnętrznym przez inżynierów – niemal zachwyt
X proponuję listę priorytetów funkcjonalności na następny sprint - obie grupy ją aktualizują
![Page 71: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/71.jpg)
Lessons learnedX nie był typowym dla Scrum właścicielem
produktu – „utajnianie” tego podejściaX stosował zasadę „Scrum sztuką rzeczy
możliwych”Spotkania obu grup „face to face” pokazały
zbieżność potrzeb i problemów obuTe grupy wcześniej się nie spotykały – a to jest
warunkiem koniecznym postępu w pracach nad projektem
![Page 72: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/72.jpg)
Firma 8. Cele firmyDziałalność: początkująca firma
telekomunikacyjnaCharakterystyka: pościg za szerokim pasmem,
większą przepustowością – technologicznie, możliwość o 4000%
Patenty młodych naukowców z MIT w tej firmie
Problemy: konkurenci chcą wykupić, sprzeciw właściciela X (zbyt tania oferta)
![Page 73: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/73.jpg)
Użyteczność ScrumKorzystne zestawienie zaległości
produktowychPrzeciążenie X – poprzednio całodniowe
przeglądy, dotyczące nielicznych marnotrawstwo czasu większości
Rozwiązanie – codzienne ScrumProblem – zakupy deficytowych komponentów
![Page 74: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/74.jpg)
Rozwiązanie – dwóch młodszych inżynierówLessons learnedZaangażowanie właściciela w rozwoju
produktu – rozwiązanie krytycznych problemów
Zatrudnienie młodszych inżynierów odciążyło starszych w rozwiązywaniu trudnych problemów
Efekt – 3-krotny wzrost wartości firmy po 1 miesiącu od prezentacji wyników
![Page 75: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/75.jpg)
Firma 9. Cele systemu transferu funduszyDziałalność: instytucja finansowa (w czołówce
w USA – wpływ na rynki walutowe)Rozmowy z ludźmi biznesu – wymagania
językoweSystem przelewów – FTS (Found Transfer
System)Fakt1: zamiar opracowania nowszej wersji
systemuFakt2: zmiana na kluczowych stanowiskach
![Page 76: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/76.jpg)
Użyteczność ScrumPrezentacja Scrum dla trzech kluczowych osóbTworzenie listy zadań do wykonania w cyklu
30-dniowym, uwzględniająca priorytetyPrzegląd funkcjonalności, kolejnych zadań do
wykonania i wybór zadań na następny SprintPozytywne podejście zespołu – tylko jedno
spotkanie miesięcznieEfekt: w ciągu godziny zespół wybrał istotne
zaległości produktowe, też zaległości sprintu
![Page 77: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/77.jpg)
Lessons learnedBagatelizowanie metodyki Scrum w oczach
zespołu FTSZespół nie potrzebował języka Scrum – mieli
swójStosowali Scrum, nie używając jego
terminologiiBagatelizowanie Scrum uprościło współpracę
zespołu FTS z innymi zespołami
![Page 78: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/78.jpg)
PodsumowanieCztery sytuacje – w każdej znalazł się
właściciel produktu (świadomie bądź nieświadomie)
W każdym przypadku ScrumMaster doprowadzał do i organizował spotkania właściciela produktu z zespołem
Powyższa współpraca – świadoma bądź utajniona; zawsze pożyteczna
![Page 79: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/79.jpg)
Zespół i właściciel uczą się nawzajem rozumieć- przedtem rozmawiali w różnych językachWłaściciel nie nauczy się technologii – raczej
zespół podejścia biznesowegoWspólny mianownik obu stron – zaległości
produktoweWspólny język jest krytycznym czynnikiem
sukcesu projektu14.05.
![Page 80: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/80.jpg)
4. Zespół Scrum Odpowiedzialność za zarządzanie rozwojem Zespół wybiera prace do wykonania i kieruje
nimi podczas kolejnych sprintów Zmiana wymagań (decyduje zespół) – chodzi
o wydanie przyrostu funkcjonalności produktu
Narzucanie kierowania z zewnątrz prowadzi do niepowodzenia
![Page 81: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/81.jpg)
Firma 10.Sytuacja początkowaDziałalność- sprzedaż oprogramowania (wielu
małych klientów)Dobre opinie o produktachGrupa programistów – prace nad nowym
wydaniem oprogramowaniaDecyzja o zastąpieniu podejścia klasycznego
metodyką Scrum
![Page 82: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/82.jpg)
Zespół w działaniuSzkolenie – przygotowanie do pierwszego
sprintuKoncentracja na aktywności i zaangażowaniu
zespołuWniosek – zbyt duży zespół (powinno być
kilku, a nie kilkunastu członków)Decyzja zespołu – podział na kilka
podzespołów (efektywność prac)Zapewnienie spójności, min. powtarzalności
![Page 83: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/83.jpg)
Wartość zespołuZaangażowanie zespołu w realizację,
identyfikacja z celem sprintuWymyślenie sposobu na osiągnięcie celuTworzenie zespołu w firmie 10.Wydajność metodyki – realizacja zadań
w kolejności (priorytety)Jej realizacja przez zespół – samoorganizacja
i samozarządzanie
![Page 84: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/84.jpg)
Istota – sprint – zespół pracuje na max – prezentacja właścicielowi produktu (działająca funkcjonalność)
Ważne dla zespołu – poczucie autonomiiTrudność: przejście od zespołu zarządzanego
do samozarządzającego. Efekty – wydajność i zadowolenie z pracy
odpowiedzialny za powyższe – ScrumMasterStwierdzenie: ScrumMaster nie jest
kierownikiem zespołu ani projektu
![Page 85: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/85.jpg)
Przejrzystość wiodącą zasadą – wszyscy muszą wiedzieć, gdzie każdy z nich się znajduje
Nauka organizacji kolejnych sprintów: uszczegółowianie zadań, realistyczne planowanie transformacji zaległości produktowych w funkcjonalności
Wynik: odkrycie i wykorzystanie nadwyżek czasu i energii
Wynik: zadowolenie ze współpracy i pomocy
![Page 86: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/86.jpg)
Integracja programistów i testerówPodział na podzespoły optymalizacja
przydziału osób do podzespołów (do niezbyt wielu)
Scrum – sztuka rzeczy możliwychzalety – częste i regularne dostarczanie
funkcjonalności, motywacja zespołu, poprawa warunków pracy, doskonalenie jakości
Implementacja empirycznego podejścia przez Scrum na zasadzie inspekcji i adaptacji
![Page 87: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/87.jpg)
Porównanie szacunków z wartościami rzeczywistymi – różne sposoby ukrywania prawdy
Kłopoty i problemy zespołu: samodzielność, presja czasu (Sprint), model kaskadowy nie spełnia oczekiwań
Decyzja Zarządu - ScrumGłówne zadania – wdrożenie metodyki określenia
zaległości produktowych do najbliższego wydania, wyznaczenie zespołów projektowych, dobór ich członków
Wspólne przestrzenie robocze dla zespołów (komunikacja)
![Page 88: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/88.jpg)
Eliminacja zbędnych artefaktów- dokumentów wspierających metodykę kaskadową
Promowanie osoby ScrumMasteraSytuacja: izolacja członków zespołu: biura,
boksy, brak komunikowania sięDodatkowe źródło izolacji – podejście
kaskadoweKomunikacja pisemna, zamiast „face to face”Sprinty zmieniły radykalnie tę sytuację
![Page 89: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/89.jpg)
Lessons learnedDominuje tradycja relacji „przełożony-
podwładny”Wiodąca rola – ScrumMaster (pracuje nad
zespołem, ale i nad samym sobą)Zespół musi nauczyć się zarządzania samym
sobąScrumMaster jest odpowiedzialny za proces
i usuwanie przeszkód, lecz nie za zarządzanie funkcjonalnością tworzonego produktu
![Page 90: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/90.jpg)
Ważna jest współpraca ScrumMaster i zespołu aby osiągnąć najlepsze wyniki
Ulepszenia winny dotyczyć całego systemu, a nie podsystemów
Inspekcja i adaptacja – niezbędna wiedza, co podlega inspekcji
Scrum jest trudny w stosowaniu – wymaga częstych inspekcji i adaptacji. Doświadczenie – zarząd firmy w końcu akceptuje Scrum
![Page 91: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/91.jpg)
Boksy usuniętoPrzestrzeń typu „hol” służy spotkaniom,
wymianomFirma 11.Komentarz: Scrum zwiększa wydajność zespołu
o rząd wielkości. Decydująca rola – rosnące zaangażowanie zespołu, wzajemna pomoc
Sytuacja początkowa
![Page 92: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/92.jpg)
Jeden z pierwszych wydawców wiadomości w internecie
Przewaga konkurencyjna – silnik analizy leksykalnej błyskawiczny dostęp do informacji według dowolnego kryterium
Kolejny atut – zwiększenie stopnia elastyczności silnika, umożliwiająca analizę źródeł wiadomości
Powyższe wymagało, by Thomas Sun (odludek) został częścią zespołu (zaprzyjaźnioną „świnią”). Zgodził się.
![Page 93: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/93.jpg)
Wykonał zadanie, przetestował rozwiązanie, uspokoił zespół. Wyjechał na 2 tygodnie, bez możliwości kontaktu.
W tym czasie problemy, potem awaria silnika analizy leksykalnej wściekłość i rozpacz zespołu – funkcjonalność była już ogłoszona publicznie
Sprint był porażką – cel nieosiągalnyRozwiązanie – prywatny detektyw odnalazł
Thomasa, on wspomógł zespół, cel sprintu osiągnięty
![Page 94: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/94.jpg)
Lessons learnedOgromne pretensje Thomasa do
ScrumMastera (naruszenie prywatności)Obie strony konfliktu mają mieszane uczucia;
sytuacje takich trudnych wyborów nie są rzadkością
![Page 95: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/95.jpg)
PodsumowanieFirma 10. – przed wdrożeniem Scrum grupa
osób pracowała indywidualnie, w izolowanych miejscach. Analogia – karanie niegrzecznego dziecka „kątem”
Prosimy ludzi o zrobienie czegoś możliwego – przeważnie próbują
Prosimy ludzi o zrobienie czegoś nieco powyżej ich możliwości – próbują, o ile nie będą karani za niewykonanie wszystkiego
![Page 96: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/96.jpg)
Gdy ludziom oferuje się pomoc, zachęca i docenia – przeważnie dają z siebie wszystko
Praca w zespole – efekt synergii (do granicy 7 +/- 2)
Zaległości produktowe napędzają mechanizm osiągania najlepszych wyników
Sytuacja w firmie 10. ex post zmieniła się na korzyść – ludzie chcą usprawnić, organizację, zespoły, samych siebie i realizację swych zadań.
21.05.
![Page 97: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/97.jpg)
5. Zdarzenia w Scrum - sprint, planowanie sprintu
Sprint: esencja Scruma; 1 miesiąc; 30-dniowa iteracja
Spotkanie planujące sprint 8 godz., dwie równe czasowo części. Pierwsza
– określenie zaległości produktowych, druga – przygotowanie zaległości sprintu
Uczestnicy – właściciel produktu i zespół; każdy z nich może zaprosić dodatkową stronę – obserwatora – za wyjątkiem kurczaka
![Page 98: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/98.jpg)
Właściciel produktu przygotowuje zaległości produktowe przed spotkaniem. W razie jego nieobecności lub braku przygotowania, zastępuje go w pełni ScrumMaster
Cel pierwszej części spotkania – zespół selekcjonuje te części zaległości produktowych, które jest w stanie zamienić w możliwy do wydania przyrost funkcjonalności. Będą one przedstawione właścicielowi produktu podczas przeglądu sprintu (jego zakończenie)
![Page 99: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/99.jpg)
Zespół proponuje, ostateczna decyzja co do zaległości produktowych sprintu należy do właściciela produktu
Zespół określa, jaka część zaległości produktowych zamierzonych przez właściciela produktu będzie realizowana w trakcie sprintu
Ograniczenie 1. części do 4 godzin jest nieprzekraczalne. W razie niewykonania analizy zaległości produktowych, jest ona dokończona podczas sprintu
![Page 100: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/100.jpg)
Druga część spotkania planującego ma miejsce zaraz po pierwszej, czas też 4 godz.
Obecność właściciela produktu obowiązkowa – mogą być pytania
Zespół, całkowicie autonomicznie, opracowuje w 2. części strategię realizacji zamiany zaległości produktowych w przyrost możliwej do wydania funkcjonalności produktu. Inni uczestnicy mogą tylko obserwować lub odpowiadać na pytania członków zespołu
![Page 101: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/101.jpg)
Wynik drugiej części spotkania planującego sprint to: Lista zadań (zaległości sprintu) Ocena zadań wraz z przydziałem do nich osób –
początek realizacji funkcjonalności Lista może być niekompletna, ale na tyle
obszerna, by pokazać wspólnotę zobowiązań zespołu i zapewnić mu pracę przez pierwszą część sprintu. Podczas tego okresu zespół określi pozostałe zadania i doda je do zaległości sprintu
![Page 102: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/102.jpg)
Sprint 30 dni – kompromis: można coś zrobić, co
zainteresuje właściciela i co jest możliwe do wydania
Zespół może w czasie sprintu współpracować z otoczeniem
Zespól jest całkowicie samozarządząjący sobą Zespół zobowiązuje się do wykonania
zaległości produktowych – zamrożonych na czas sprintu
ź
![Page 103: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/103.jpg)
W razie niewykonalności sprintu, ScrumMaster może awaryjnie sprint zakończyć; nowe spotkanie planujące sprint; nowy sprint
Zespół może, po konsultacji z właścicielem, usunąć te elementy zaległości, których nie jestw stanie wykonać
Zespół może, po konsultacji z właścicielem, dodać inne elementy zaległości produktowych
Dwie odpowiedzialności członka zespołu: uczestnictwo w codziennym sprincie, publikowanie wszystkim aktualnych zaległości sprintu
ź
![Page 104: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/104.jpg)
Rys. 2. Sprint
![Page 105: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/105.jpg)
6. Zdarzenia w Scrum - monitorowanie sprintu, sprint ex-post (retrospektywa sprintu)
Codzienne spotkanie SCRUM Czas – 15 min. Codziennie, ta sama pora, to samo miejsce –
najlepiej na początku dnia Obecni wszyscy członkowie zespołu,
ewentualne substytuty Punktualność; kara – 1 dolar
![Page 106: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/106.jpg)
Każdy zdaje raport – 3 pytania: Co zrobiłeś od wczoraj? Co zrobisz do jutra? Co utrudnia ci efektywne wykonywanie pracy?
Jedynie raportowanie Mówi TYLKO JEDNA OSOBA W razie potrzeby, spotkanie
zainteresowanych po codziennym SCRUM
ź
![Page 107: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/107.jpg)
Kurczaki tylko słuchają Kurczakom nie wolno rozmawiać z członkami
zespołu po spotkaniu Świnie i kurczaki naruszające zasady mogą
być usunięte z zespołu (świnie), bądź ze spotkania (kurczaki)
ź
![Page 108: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/108.jpg)
Spotkanie przeglądu sprintu Ograniczenie – 4 h Cel – zaprezentowanie właścicielowi
i udziałowcom wykonanej funkcjonalności – tylko tej zrealizowanej
Rozpoczyna prezentacja (jeden z członków): cel sprintu, zobowiązania wykonania zaległości produktowych, tychże ukończonych. Inni członkowie mogą omawiać dobre i złe strony wykonania
ź
![Page 109: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/109.jpg)
Odpowiedzi na pytania udziałowców, notowania wymaganych zmian
Pytania do udziałowców: ich opinie, zmiany, priorytety zmian
Dyskusja właściciel-udziałowcy-zespół dot. przedefiniowania zaległości produktowych
Przestrzeń na kreatywność - np. nowe funkcjonalności , priorytety
ScrumMaster uzgadnia miejsce i datę następnego przeglądu sprintu i ogłasza je
ź
![Page 110: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/110.jpg)
Retrospektywne spotkanie sprintu Limit: 3 h. Członkowie zespołu, ScrumMaster
(obowiązkowo), właściciel produktu (opcjonalnie)
Początek: co poszło dobrze, co mogłoby być ulepszone (wszyscy)
ScrumMaster zapisuje Zespół ustala kolejność rozmów dotyczących
ulepszeń
ź
![Page 111: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/111.jpg)
ScrumMaster jest „ułatwiaczem” w poszukiwaniu lepszych metod wykorzystania procesu Scrum
Elementy zaskarżalne, które mogą być przeniesione do kolejnego sprintu, będące niefunkcjonalnymi zaległościami produktowymi, powinny być zakwalifikowane jako te o wysokim priorytecie
ź
![Page 112: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/112.jpg)
Firma 10. Porządkowanie chaosu Planowanie i zarządzanie skomplikowanymi
projektami: PERT, Gantt Komplikacja - podział na role: analiza,
projektowanie, kodowanie, testowanie, tworzenie dokumentacji
Efekt1: wzajemna izolacja osób pracujących nad poszczególnymi funkcjonalnościami
Efekt 2: kaskadowe podejście do pracy, brak możliwości współpracy
![Page 113: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/113.jpg)
Efekt3: bałagan, błędy w oprogramowaniu (produkcie)
Efekt 4: syndrom studenta Efekt 5: wyczerpanie i zniechęcenie członków
zespołu Decyzja: Scrum, czas wdrożenia – 2 tygodnie Spotkanie z zespołem – ujawnienie
problemów (praca nad dwoma produktami) – jedni nie skończyli zadań, inni czekali na wyniki, obijając się
![Page 114: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/114.jpg)
Wniosek – zespół nie był właścicielem swych prac, wykonując odgórne polecenia
Propozycja rozwiązania – spotkanie planujące sprint
Członkowie zespołu ustalili priorytety Ustalono listę wymagań funkcjonalnych
i niefunkcjonalnych
![Page 115: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/115.jpg)
Metoda – śledząca kula. Czy zespół mógł utworzyć moduły obsługi kredytów spełniających wszystkie niefunkcjonalne wymagania w zaległościach produktowych?
Czy zespół był w stanie to wykonać w ciągu 30 dni?
Wymaganie od zespołu – niewielki kawałek funkcjonalności, obsługujący oba produkty (zadowolenie klienta, że to ten sam produkt)
![Page 116: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/116.jpg)
Efekty: poczucie sukcesu zespołu, zadowolony klient, wiedza kierownictwa
Lessons learned Wymyślanie wszystkiego od razu we wczesnej
fazie złożonego projektu jest bardzo trudne Zadania przestają być aktualne wkrótce po
ich przydzieleniu Praca sekwencyjna podzieliła zespół
trudności w komunikacji i współdziałaniu
![Page 117: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/117.jpg)
Szalone tempo w ostatnich 2-3 miesiącach „wypalony” zespół
Skupienie się na przyrostach funkcjonalności zapewnia postępy w kierunku ukończenia wydania
Iteracyjne i przyrostowe praktyki Scrum dają zespołowi poczucie spełnienia
Scrum jest empiryczny; stosuje częstą inspekcję i adaptację
Zespoły same znajdują swe własne rozwiązania 28.05.
![Page 118: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/118.jpg)
Firma 12. Porządkowanie chaosuSytuacja początkowa Publikacja profesjonalnych czasopism
z różnych dziedzin, również w sieci Problem – opóźnienia (tylko 1 tytuł w
terminie); przyczyna – różnice w technologii Pytania do wydawcy:
Zapewnienie estetyki w trybie online? Modyfikacja procesów redakcyjnych
i produkcyjnych umożliwiających online? Najlepszy mechanizm umieszczania w sieci?
![Page 119: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/119.jpg)
Chaos w poszukiwaniach rozwiązania – kontakt z WebPub (firma internetowa) – wykupienie jej – ukierunkowanie jej prac na swe publikacje
Kłopoty – istniejąca platforma WebPub wymagała modyfikacji dla wydawania czasopism firmy 12.
Podjęte decyzje poprawek w platformie WebPub, nowych formatów niewykonalne terminy publikacji
![Page 120: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/120.jpg)
Decyzja: Scrum; kierownictwo 12. ceniło przyrostowe dostarczanie funkcjonalności, konkretnie pokazujące postęp
Spotkanie planujące sprint dla zespołu każdego czasopisma (każdy – 9 osób)
Sporządzenie zaległości produktowych funkcjonalności
Nadanie priorytetów – najwyższe niefunkcjonalne (struktura danych, możliwości wydawnicze WebPub)
![Page 121: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/121.jpg)
Lessons learned Zbyt złożone relacje miedzy zespołami
wymagają modyfikacji Scrum Złożoność częstotliwość inspekcji ilość
okazji do adaptacji Zespoły tworzyły zależne oprogramowania,
ich przyrosty funkcjonalności powstające podczas sprintów przeplatały się
![Page 122: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/122.jpg)
Rozwiązanie – zmiana składu zespołów – każdy miał jedną osobę zaznajomioną z każdym elementem skomplikowanej sytuacji i posiadającą autorytet
Firma 13. Porządkowanie chaosuSytuacja początkowa Pozyskiwanie informacji z masy danych –
łączenie danych (data fusion) Złożoność, różne umiejętności, wytrwałość
(projekt rządu USA, po 11.09.2011.)
![Page 123: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/123.jpg)
Dane z agencji, nie znających słowa „współpraca”
Konieczność utworzenia nowych technologii Dostosowanie algorytmów łączenia danych –
wyszukiwanie „igły w stogu siana” Konieczność „dowodu działania” –
odpowiadali eksperci od algorytmów, baz danych, technologii łączenia i programiści; efekt – niepowodzenie
![Page 124: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/124.jpg)
Decyzja: Scrum; 2-dniowe uczenie metodyki i planowanie sprintu
Pierwszy dzień – porażka, nie zrozumieli sprintu, nie stali się samoorganizującym się zespołem; przyczyna – tajne dane agencji rządowych; odmienne dane z różnych źródeł
Rozwiązanie – spotkanie: koncepcja (hipotetycznych) zaległości produktowych, lista zaległości, analiza i wybranie prac podczas pierwszego sprintu
![Page 125: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/125.jpg)
Zespół uświadomił sobie, że ograniczony czas wymusza ograniczenie się do reprezentatywnych elementów produktu, by uzyskać funkcjonalność
2 godz. – zespół opisał, co może wykonać - samoorganizacja zespołu osiągnięta! Scrum zrozumiany
Zamiana hipotetycznych zaległości produktowych w rzeczywiste
Nowe spotkanie, planujące sprint dla rzeczywistych zaległości produktowych
![Page 126: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/126.jpg)
Lessons Learned Wymagana elastyczność i skuteczność
ScrumMaster w różnych okolicznościach; firma 13. – związane ręce brakiem informacji
Samoorganizacja i współpraca najlepiej rozumiane na prawdziwych przykładach/problemach. W firmie 13. trzeba było przejść od hipotez do rzeczywistości.
![Page 127: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/127.jpg)
Firma 14. Zarządzanie gotówkąSytuacja początkowa „14” to jedna z największych instytucji
finansowych na świecie 2 lata: 20% projektów programistycznych
wykorzystuje Scrum Kolejny projekt: „Aplikacja gotówkowa” –
zapisywanie i raportowanie transferów
![Page 128: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/128.jpg)
Dwudniowe (wstępne) spotkanie planujące sprint: Pięciu programistów, właściciel produktu,
ScrumMaster, kierownik wdrażania systemów Podstawy Scrum Brak listy zaległości produktowych, aby rozpocząć
spotkanie planujące sprint Niezrozumienie przez zespół takiej procedury –
chcieli „iść do przodu” Konsultant przekonał zespół do wartości listy
zaległości produktowych – wyznaczenie linii bazowej
![Page 129: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/129.jpg)
Szacowanie zaległości produktowych Wątpliwości zespołu co do sensowności
i rzetelności oceny Rozmowy, negocjacje dotyczące tematu Problem – mała dokładność szacunków Podpowiedź: Scrum jest empiryczny – „sztuka
rzeczy możliwych” Śledzenie zaległości produktowych każdego
sprintu Zakończenie każdego sprintu – uaktualnianie
oczekiwań zarządu; podstawa - śledzenie
![Page 130: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/130.jpg)
Efekt – trafne oszacowaniaAnaliza – co znaczy „zrobione”? Niezrozumienie znaczenia „szacowanie” Znaczenie testowania funkcjonalności Uaktualnianie szacunków Część pracy przekazana do Działu Jakości Efekt: priorytety zaległości elementów
produktowych
![Page 131: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/131.jpg)
Zmiany są trudne Rozbieżności w rozumieniu „zrobione” Efekt: czas realizacji z 5 do 7 miesięcy Problem1: dotychczasowe sztywne trzymanie
się terminów w „14.” Aktualizacja terminu: w wyniku pierwszego
(i dalszych) sprintów Problem2: w „14” wierzono, że można
dokładnie przewidzieć przyszłość i że nie trzeba będzie modyfikować przewidywań
![Page 132: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/132.jpg)
Lessons Learned Firma winna się przeorganizować, aby skorzystać
z metodyki Scrum Kultura zarządzania „14” postrzegała wstępne
szacowania czasu/pracochłonności jako umowę Scrum – każde spotkanie podsumowujące sprint
pokazuje różnice: Szacunki – rzeczywistość Możliwości zespołu – rzeczywiste wykonanieDla zarządu okazja do rozwinięcia/złagodzenia
oczekiwań
![Page 133: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/133.jpg)
Niewiele projektów umożliwia przeprowadzenie obiektywnej analizy ilościowej w celu podejmowania optymalnych decyzji
Po każdym sprincie właściciel odpowiada za pokazanie zespołowi zadań o największej wartości dla organizacji
Chodzi nie tylko o zamianę zaległości w funkcjonalność, ale i stosowanie się do praktyk inżynierskich/standardów
![Page 134: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/134.jpg)
7. Artefakty Scrum – rejestr produktu, rejestr sprintu, przyrost funkcjonalności produktu
Zaległości produktowe Lista zaległości produktowych. Odpowiada
właściciel produktu Zaległości nigdy nie są kompletne –
dynamicznie się rozwijają
![Page 135: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/135.jpg)
Zaległości sprintu Definiują pracę dotyczącą zaległości produktu Jedynie zespół może zmienić zaległości
sprintuPrzyrost funkcjonalności produktu Wymóg: zespół tworzy przyrost
funkcjonalności produktu, możliwy do wydania
![Page 136: ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI](https://reader038.vdocuments.mx/reader038/viewer/2022103102/5681620e550346895dd23a61/html5/thumbnails/136.jpg)
Projekt współfinansowany przez Unię Europejską w ramach środków Europejskiego Funduszu Społecznego
DZIĘKUJĘ ZA WSPÓŁPRACĘ
i/andHAPPY PROJECTS!!!