ZAAWANSOWANE ZARZĄDZANIE PROJEKTAMI

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