ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI

Prezentacja na temat: "ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI"— Zapis prezentacji:

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, technik i 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: Extreme Programming, Crystal, Dynamic Systems Development, Rapid Application 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,

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 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 oprogramowanie ponad 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 samym jedną 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 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.

14 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 

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

22 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

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 Crystal Methodologies - 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
„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

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 Rapid Application 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 klasyczna RAD Rys. 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 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

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
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 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)

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
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

44 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.

45 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)

46 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

47 Odpowiada za sukces projektu:
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

48 Interpretacja Scrum przez pryzmat dotychczasowych doświadczeń
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

49 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

50 Lessons learned 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

51 Firma 3. Niekompetentny ScrumMaster
Pominął Przejście: szef – trener (coach) Przejście: kontrola – ułatwienia Lekceważenie roli samoorganizacji  demotywacja członków zespołu Firma 3. Niekompetentny ScrumMaster Działalność: sprzedaż oprogramowania do planowania Stosowane podejście: klasyczne (sekwencyjne) Efekt – wydłużające się terminy Błąd: niezrozumienie roli „owczarka”

52 Lessons learned ScrumMaster 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

53 Firma 4. Nadgorliwy ScrumMaster
Działalność: sprzedaż oprogramowania dla służby zdrowia Problem: konkurencja firm internetowych, pośrednicy klient-służba zdrowia Rozwią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)

54 Błędy Nieuwzględnienie kultury firmy Nieuwzględnienie priorytetów
Narzucanie metody Scrum wbrew woli kierownictwa firmy Nietrzymanie nerwów na wodzy Lessons learned Nieudana ocena wartości pracy zespołowej w firmie „Scrum dotyczy rzeczy możliwych. Martwy owczarek jest niepotrzebny”

55 Firma 5. Wilki Działalność: zarządzanie funduszami Problem: przegapienie rewolucji technologicznej (internet, komórki, mobilne technologie  samodzielność klientów) Koło ratunkowe CMM (Capability Maturity Model – pomyłka) Rozwiązanie skuteczne - Scrum

56 Atak wilków Ingerencja „z boku” – naruszenie zasad Scrum Efekt1: raportowanie prac nie związanych ze Sprintem ani z zaległościami produktowymi Efekt2: pogwałcenie podstawowej reguły Scrum – autonomii zespołu Efekt 3: zrozumienie i ekspiacja osoby odpowiedzialnej za zamieszanie

57 Lessons learned Znaczenie uwidoczniania wszystkiego na bieżąco Zaległości produktowe + priorytety powszechnie dostępne Rola codziennego Scrum w tym uwidocznianiu – ScrumMaster może stosować reguły, a zespół pozostać na właściwej ścieżce

58 Podsumowanie roli ScrumMaster
Kto 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

59 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.

60 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)

61 Firma 6. Sytuacja początkowa Właściciel rurociągów (gaz, paliwa, ropa) – wynajem (Ameryka Płn.) Bardzo duża firma Tantiemy dla prywatnych właścicieli gruntów Problem: częste zmiany właścicielskie; archaiczna („ręczna”) metoda ustalania adresów aktualnych właścicieli (czaso- i kosztochłonna)

62 Inny problem: różne prawo/procedury właścicielskie w różnych stanach
Decyzja: Scrum Właściciel produktu w akcji: Ustalił priorytety: proces automatyzacji przed przeniesieniem danych między serwerami Pierwsze sprinty – mniej biznesowej funkcjonalności (rozruch trwa i kosztuje) Aktualizacja bazy o niezbędne dane

63 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%

64 Wartość roli właściciela produktu
Odpowiada 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

65 Rola właściciela produktu
Ciągła współpraca z zespołem Cią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

66 Firma 7. Przywracanie zarządu do działania
Działalność: średniej wielkości sprzedawca oprogramowania; wielu małych klientów Sytuacja: powierzenie stworzenia kolejnej wersji oprogramowania (poprzednia nie była gotowa) Metoda: CPM i Gantt, potem decyzja: Scrum Rozwiązanie skuteczne – Scrum Spotkanie przeglądu sprintu (7 zespołów); udział „top management” firmy

67 Lessons learned Zastąpienie formalnego raportowania – współpracą Kilkugodzinne spotkania z zarządem firmy Spotkania „top management” podsumowująco/oceniające współpracę  SUPER!

68 Firma 5. Naprawa problemu XFlow
Ukryty 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

69 Rozwiązanie Spotkanie obu grup Komunikacja bezpośrednia – argumentacja Wyjś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ń

70 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ą

71 Lessons learned X nie był typowym dla Scrum właścicielem produktu – „utajnianie” tego podejścia X stosował zasadę „Scrum sztuką rzeczy możliwych” Spotkania obu grup „face to face” pokazały zbieżność potrzeb i problemów obu Te grupy wcześniej się nie spotykały – a to jest warunkiem koniecznym postępu w pracach nad projektem

72 Firma 8. Cele firmy Działalność: początkująca firma telekomunikacyjna Charakterystyka: 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)

73 Użyteczność Scrum Korzystne zestawienie zaległości produktowych Przeciążenie X – poprzednio całodniowe przeglądy, dotyczące nielicznych  marnotrawstwo czasu większości Rozwiązanie – codzienne Scrum Problem – zakupy deficytowych komponentów

74 Rozwiązanie – dwóch młodszych inżynierów
Lessons learned Zaangaż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

75 Firma 9. Cele systemu transferu funduszy
Działalność: instytucja finansowa (w czołówce w USA – wpływ na rynki walutowe) Rozmowy z ludźmi biznesu – wymagania językowe System przelewów – FTS (Found Transfer System) Fakt1: zamiar opracowania nowszej wersji systemu Fakt2: zmiana na kluczowych stanowiskach

76 Użyteczność Scrum Prezentacja Scrum dla trzech kluczowych osób Tworzenie listy zadań do wykonania w cyklu 30-dniowym, uwzględniająca priorytety Przegląd funkcjonalności, kolejnych zadań do wykonania i wybór zadań na następny Sprint Pozytywne podejście zespołu – tylko jedno spotkanie miesięcznie Efekt: w ciągu godziny zespół wybrał istotne zaległości produktowe, też zaległości sprintu

77 Lessons learned Bagatelizowanie metodyki Scrum w oczach zespołu FTS Zespół nie potrzebował języka Scrum – mieli swój Stosowali Scrum, nie używając jego terminologii Bagatelizowanie Scrum uprościło współpracę zespołu FTS z innymi zespołami

78 Podsumowanie Cztery 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

79 Zespół i właściciel uczą się nawzajem rozumieć
przedtem rozmawiali w różnych językach Właściciel nie nauczy się technologii – raczej zespół podejścia biznesowego Wspólny mianownik obu stron – zaległości produktowe Wspólny język jest krytycznym czynnikiem sukcesu projektu 14.05.

80 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

81 Firma 10. Sytuacja początkowa Działalność- sprzedaż oprogramowania (wielu małych klientów) Dobre opinie o produktach Grupa programistów – prace nad nowym wydaniem oprogramowania Decyzja o zastąpieniu podejścia klasycznego metodyką Scrum

82 Zespół w działaniu Szkolenie – przygotowanie do pierwszego sprintu Koncentracja na aktywności i zaangażowaniu zespołu Wniosek – 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

83 Wartość zespołu Zaangażowanie zespołu w realizację, identyfikacja z celem sprintu Wymyślenie sposobu na osiągnięcie celu Tworzenie zespołu w firmie 10. Wydajność metodyki – realizacja zadań w kolejności (priorytety) Jej realizacja przez zespół – samoorganizacja i samozarządzanie

84 Istota – sprint – zespół pracuje na max – prezentacja właścicielowi produktu (działająca funkcjonalność) Ważne dla zespołu – poczucie autonomii Trudność: przejście od zespołu zarządzanego do samozarządzającego. Efekty – wydajność i zadowolenie z pracy odpowiedzialny za powyższe – ScrumMaster Stwierdzenie: ScrumMaster nie jest kierownikiem zespołu ani projektu

85 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

86 Integracja programistów i testerów
Podział na podzespoły  optymalizacja przydziału osób do podzespołów (do niezbyt wielu) Scrum – sztuka rzeczy możliwych zalety – 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

87 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 - Scrum Głó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)

88 Eliminacja zbędnych artefaktów- dokumentów wspierających metodykę kaskadową
Promowanie osoby ScrumMastera Sytuacja: izolacja członków zespołu: biura, boksy, brak komunikowania się Dodatkowe źródło izolacji – podejście kaskadowe Komunikacja pisemna, zamiast „face to face” Sprinty zmieniły radykalnie tę sytuację

89 Lessons learned Dominuje 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

90 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

91 Boksy usunięto Przestrzeń typu „hol” służy spotkaniom, wymianom Firma 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

92 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ę.

93 Wykonał zadanie, przetestował rozwiązanie, uspokoił zespół
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ągalny Rozwiązanie – prywatny detektyw odnalazł Thomasa, on wspomógł zespół, cel sprintu osiągnięty

94 Lessons learned Ogromne pretensje Thomasa do ScrumMastera (naruszenie prywatności) Obie strony konfliktu mają mieszane uczucia; sytuacje takich trudnych wyborów nie są rzadkością

95 Podsumowanie Firma 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

96 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.

97 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

98 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)

99 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

100 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

101 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

102 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 ź

103 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 jest w 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 ź

104 Rys. 2. Sprint 

105 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

106 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 ź

107 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) ź

108 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 ź

109 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 ź

110 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ń ź

111 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 ź

112 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

113 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ę

114 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

115 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)

116 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

117 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

118 Firma 12. Porządkowanie chaosu Sytuacja 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?

119 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

120 Decyzja: Scrum; kierownictwo 12
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)

121 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ę

122 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 chaosu Sytuacja 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 )

123 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

124 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

125 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

126 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.

127 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

128 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

129 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

130 Efekt – trafne oszacowania
Analiza – 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

131 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ń

132 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 wykonanie Dla zarządu okazja do rozwinięcia/złagodzenia oczekiwań

133 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

134 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ą

135 Zaległości sprintu Definiują pracę dotyczącą zaległości produktu Jedynie zespół może zmienić zaległości sprintu Przyrost funkcjonalności produktu Wymóg: zespół tworzy przyrost funkcjonalności produktu, możliwy do wydania

136 DZIĘKUJĘ ZA WSPÓŁPRACĘ
i/and HAPPY PROJECTS!!! Projekt współfinansowany przez Unię Europejską w ramach środków Europejskiego Funduszu Społecznego