Post on 22-Feb-2016
description
ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI
Wrocław, 2013/2014
Opracował i prowadzidr inż. Jan BETTA
(Zwinne.pptx)
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
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)
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
Ź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/
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?
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.
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).
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ć:
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”
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.
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.
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.
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
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
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ę
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ą.
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.
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
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
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.
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
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
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
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ę
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
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
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
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
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
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
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
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
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
Teoria Scruma bazuje na empiryzmie.
Podejście iteracyjne i przyrostowe lepsza przewidywalność i kontrola ryzyk
Zasady kontroli empirycznej procesu: przejrzystość, inspekcja, adaptacja
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
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)
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
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.
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.
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.
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.
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.
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)
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
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
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
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
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
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”
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
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)
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”
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
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
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
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
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.
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)
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)
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
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%
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
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
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
Lessons learnedZastąpienie formalnego raportowania –
współpracąKilkugodzinne spotkania z zarządem firmySpotkania „top management”
podsumowująco/oceniające współpracę SUPER!
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
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ń
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ą
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
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)
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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)
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ę
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
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
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
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ę.
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
Lessons learnedOgromne pretensje Thomasa do
ScrumMastera (naruszenie prywatności)Obie strony konfliktu mają mieszane uczucia;
sytuacje takich trudnych wyborów nie są rzadkością
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
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.
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
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)
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
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
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
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
ź
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
ź
Rys. 2. Sprint
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
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
ź
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)
ź
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
ź
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
ź
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ń
ź
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
ź
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
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ę
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
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)
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
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.
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?
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
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)
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ę
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.)
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
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
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
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.
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
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
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
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
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ń
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ń
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
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ą
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
Projekt współfinansowany przez Unię Europejską w ramach środków Europejskiego Funduszu Społecznego
DZIĘKUJĘ ZA WSPÓŁPRACĘ
i/andHAPPY PROJECTS!!!