Zwinne

Report
ZAAWANSOWANE
ZARZĄDZANIE PROJEKTAMI
Wrocław, 2013/2014
Opracował i prowadzi
dr inż. Jan BETTA
(Zwinne.pptx)
CELE ZAJĘĆ
C1 Uzyskanie przez Słuchaczy wiedzy na temat
klasycznych i adaptacyjnych metodyk
zarządzania projektami
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
PLAN ZAJĘĆ
I. Metodyki klasyczne (przypomnienie)
1. Podstawowe pojęcia PM – przypomnienie
2. PM – stan wiedzy (świat, Polska)
2.1 Metodyka PMI
2.2 Metodyka Prince 2
2.3 Wytyczne kompetencji IPMA (ICB/NCB)
II. Metodyki zwinne (adaptacyjne)
1. Przegląd: Extreme Programming, Crystal, Dynamic
Systems Development, Rapid Application Development,
Scrum
2. ScrumMaster
3. Właściciel produktu
4. Zespół Scrum
5. Zdarzenia w Scrum - sprint, planowanie sprintu
6. Zdarzenia w Scrum - monitorowanie sprintu, sprint expost (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, 2005
2. 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 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
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ów
Mał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 - 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ę
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
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 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
 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
Inicjowanie
Planowanie
Analiza
Projekt
Tworzenie
Testy
Produkt
RAD
Analiza
Projekt
Tworzenie
Inicjowanie
Planowanie
Testy
Przywództwo
Zespół
Produkt
Przegląd
klienta
Rys. 1. Metodologia klasyczna vs. RAD
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. 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.
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)
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
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
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
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
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
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”
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
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)
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”
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
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
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
Podsumowanie
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
 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ą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 (czasoi kosztochłonna)
 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
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 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
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
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
Lessons learned
Zastąpienie formalnego raportowania –
współpracą
Kilkugodzinne spotkania z zarządem firmy
Spotkania „top management”
podsumowująco/oceniające współpracę 
SUPER!
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
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ń
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 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
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)
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
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
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
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
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
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
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.
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ą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
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
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
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
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ó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
 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)
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ę
Lessons learned
Dominuje tradycja relacji „przełożonypodwł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ę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
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ągalny
Rozwiązanie – prywatny detektyw odnalazł
Thomasa, on wspomógł zespół, cel sprintu
osiągnięty
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ą
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
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 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
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 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?
 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 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 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 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
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 wykonanie
Dla 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
sprintu
Przyrost funkcjonalności produktu
 Wymóg: zespół tworzy przyrost
funkcjonalności produktu, możliwy do
wydania
DZIĘKUJĘ ZA
WSPÓŁPRACĘ
i/and
HAPPY PROJECTS!!!
Projekt współfinansowany przez Unię Europejską w ramach środków Europejskiego Funduszu Społecznego

similar documents