ZARZĄDZANIE PROJEKTAMI

Podejście tradycyjne:
Projekt jest określonym w czasie predsięwzięciem podejmowanym w celu wytworzenia unikalnego
produktu lub usługi.
 Projekt to ciąg działań i zadań wymagający zaangażowania zasobów
 Można wskazać czas rozpoczęcia i zakończenia zarówno całego projektu, jak i jego
poszczególnych części (faz, etapów, zadań)
 Nie jest przedsięwzięciem rutynowym !!!
Inne cechy projektów:
 Odpowiedź na konkretną potrzebę
 Popyt na rynku, zlecenie klienta
 Postęp technologiczny, wymogi prawne
 Potrzeby biznesowe (finansowe)
 Charakteryzuje się znaczną złożonością
 Ma określony budżet
 Jest niepowtarzalny
 Jest realizowany w konkretnej obudowie organizacyjno-prawnej
Kategorie projektów:
- inwestycyjne (gdy firma wprowadza nowe inwestycje)
- informatyczne ((zinformatyzowanie systemu w firmie)
- badawczo-rozwojowe (związane z pracami badawczymi, rozwojowymi lub przy wprowadzeniu nowego
produktu na rynek)
- reorganizacyjne (reorganizacja struktur orfanizacyjnych – nowe działy, wydziały, emisje giełdowe itp)
Zarządzanie projektami – oznacza zastosowanie wiedzy, umiejętności, metod, narzędzi i technik w
trakcie realizacji projektu w taki sposób, zy osiągnąć postawione przed projektem cele:
 Kontekst procesowy – procesy i działania do wykonania
 Kontekst interpersonalny – budowanie i funkcjonowanie zespołu projektowego (w jaki sposób
zebrać zespół projektowy?)
 Kontekst organizacyjny – relacje między projektem a organizacją, która go realizuje (układanie
relacji)
Organizacje upowszechniające wiadomości, opracowań o projektach pozwalających rozwiajać wiedzę,
nadają certyfikaty (prowadzą certyfikację), otwierają i prowadzą konkursy międzynarodowe dotyczące
doskonałości w zarządzaniu projektami: IPMA, PMI (wiedza, nagroda, doświadczenie) Kraków 2007
Największe projekty: CHINY

Tradycyjne podejście (cechy) – określone wymagania do projektów

 Fazowość
 Sekwencyjność (pewne fazy będą po sobie następować)
 Hierarchia
Adaptacyjne podeście – określone i doprycyzowane wymagania
 Cykliczność
 Przyrost
 Partnerstwo
Ekstremalne podejście – klient wie czego chce, nie wie jak zrobić lub odwrotnie
 Testowanie hipotez

Metodyki dotyczące podejścia tradycyjnego – KASKADOWE

 ICB (International Content Baseline) wydane przez IPMA (International Project Management
Association)
 PMBOK PMI
Metodyki dotyczące podejścia adaptycyjnego – ZWINNA
 SCRUM (scrum.org)
Metodyki dotyczące podejścia ekstremalnego
 DAD
Tradycyjne zarządzanie projektami (Traditional Project Management) – w podejściu tym realizacja
projektu przebiega zgodnie z pryjętą metodyką przy wykorzystaniu tradycyjnych technik i narzędzi
zarządzania projektami
Adaptacyjne zarządzanie projektami (Adaptive Project Framework) – w tym podejściu stosowana
metodyka zarządzania projektami jest modyfikowana i adaptowana w miarę konkretyzowania się
oczekiwań i wymagań klienta projektu.
Może zmieniać się układ etapów oraz działań w ramach etapów, a także dobór narzędzi potrzebnych dor
realizacji
Ekstremalne zarządzanie projektami (Extreme Project Management) – w tym podeściu nie stosuje się
żadnej konkretnej metodyki. Zarządzanie projektami s tym podejściu polega na selektywnym stosowaniu
elementów dostępnych metodych zarządzania projektami. Jednym kryterium przydatności wybranych
elementów jest zrealizowanie czynności i wymagań klienta projektu.

TRADYCYJNE PODEJŚCIE
 1. Środowisko projektu
Projekt jest definiowany, rozpoczynany i realizowany w specyficznym środowisku pozostając pod
jego bezpośrednim lub pośredim wpływem.
Każdy z czynników działających w środowisku projektu tj. obowiązujące standardy, trendy, szanse
i zagrożenia działające wewnątrz przedsiębiorstwa ma wpływ na inicjowanie i realizację projektu.
Warunki brzegowe – określają przestrzeń jaką ma kierownik projektu realizując projekt (fizyczne,
organizacyjne, infrastrukturalne)
Główni uczestnicy projektu

SPONSOR (ten, kto

ponosi loszty projektu)

KIEROWNIK PROJEKTU
(ten, kto będzie
zarządzać projektem)

KLIENT (ten, kto będzie

korzystać z wyników ZESPÓŁ (ten, kto
projektu) realizuje projekt)

[Identyfikacja wymagań użytkownika projektu]

Na projekt działają siły u trendy zlokalizowane w otoczeniu dalszym. Zaliczamy do nich tendencje i
zmiany ujawniające się w otoczeniu naukowym, technologicznym, społecznym i politycznym.
Projekt realizowany w przedsiębiorstwie (zwanym organizacją macierzystą) pozostaje również pod
wpływem otoczenia bliższego tj. sił i zmian zachodzących wewnątrz organizacji.
Interesariusze (udziałowcy) projektu to osoby lub grupy osób, które uczestniczą w projekcie, są
zainteresowane wynikiem projektu lub są w jakiś sposób ograniczane przez projekt (klient, wykonawca,
kierownik projektu, zespół projektowy, użytkownik końcowy, zarząd, presa, lokalne grupy interesów,
banki finansujące projekty)
Analiza:
1) Identyfikowanie
2) Klasyfikowanie
- nastawienie do projektu
- władza
3) Wyizolowanie
4) Przygotowanie planu

2. Cele projektu

czas budżet

zakres
Zmiana jednego z trzech kluczowych parametrów projektu (budżetu, czasu, zakresu) pociąga za sobą
konieczność zmiany przynajmniej jeszcze jednego parametru. Jeżeli jednak pozostałe dwa parametry
pozostaną niezmienione, będzie to miało negatywny wpływ na obciążenie zasobów i jakość projektu.

Zakres produktu lub usługi – cechy i funkcje, jakie mają być realizowane przez produkt lub usługę.
Zakres projektu – czynności, których wykonanie prowadzi do doastarczenia produktu lub usługi o
pożądanych cechach i funkcjach.
Identyfikacja potrzeby – wiem, jaki jest mój problem
Sformułowanie wymagań – wiem co chce osiągnąć
Określenie celów – dróg rozwiązania problemu jest wiele, decyduje się na jedną z nich
Te 3 parametry są po to żeby wiedzieć do czego dążymy
Cele projektu muszą być spójne z celami organizacji
Projekt powinien wpisywać się w ogólną strategię organizacji
Podsumowanie:
 Związek między trzema czynnikami
 Wychodzimy od zakresu
 Sponsor projektu może zmienić reguły gry, ale szacowanie projektu pozostaje bez zmian
 Cele, które są postawione przed projektem muszą wspierać cele strategiczne
 Powinien istnieć wyższy cel, nie może być sytuacji gdy projekty są realizowane, lecz nie ma
żadnego celu strategicznego

Główni uczestnicy projektów:

 Sponsor (ten kto ponosi koszty projektu)
 Kierownik projektu (ten kto będzie zarządzał projektem)
 Wykonawca (ten kto realizuje projekt)
  Klient (ten kto będzie korzystał z wyników projektu)

Organizowanie projektu:
 Trzy struktury (komitet sterujący – sponsor, klient, interesariusz (umieszczenie ich może źle
się skończyć, mogą opóźniać wykonanie projektu), kierownik projektu, zespół projektu
 Komitet sterujący nadzoruje prawidłową realizację projektu (nie zarządza projektem!!!)
 Biuro projektu – odciążają kierownika z „pracy papierkowej” (księgowość)
 Kierownik projektu zarządza zespołem projektowym
 Zespół komponujemy zgodnie z zakresem danego projektu, kompetentni członkowie

3. Ryzyko w projekcie
Ryzyka są definiowane jako możliwe wydarzenia lub sytuacje, które mają nikorzystny wpływ na projekt
w odniesieniu do planowanych rezultatów.
Analiza i ocena ryzyka zaczynają sie na wstępnym etapie projektu. Musi być powtarzane okresowo
[przez cały czas życia proejktu, przez czas jego realizacji]. Etapy:
 Identyfikacja ryzyka (rozpoznawanie ryzyka)
 Klasyfikacja ryzyka (szacowanie ryzyka)
 Dokumentowanie ryzyka (opisanie ryzyka) [zarządzanie ryzykiem]
[Ad.1 w oparciu o listę kontrolną przeglądam i sprawdzam wszystkie założenie proejktu – check-lista]
[Ad.2 prawdopodobieństwo wystąpienia i potencjalną szkodę zazwyczaj w walucie budżetu państwa np.
zł]
[Ad.3 Udokumentowanie, zby każdy wiedział o co chodzi, np. wysokie kary, ryzyko kursów trzeba szerzej
opisać]
[prawdopodobieństwo wystąpienia (100% - pewność)
- potencjalna szkoda – w walucie]
[Ryzyko szacowane można ilustrować na macierzach szacowanie ryzyka)
Jedynym efektywnym i powszechnie stosowanym narzędziem oceny i kwantyfikacji ryzyka są listy
kontrolne ryzyka.
[nie ma uniwersalnej check-listy ryzyka; każda organizacja ma inną; są przykłądowe dla konkretnych
organizacji]
Listy kontrolne ryzyka zawierają pytania z następujących obszarów:
 Rezultaty projektu i technologia
  Aspekt handlowy
 Aspekt personalny
 Aspekt środowiskowy
 Dostawy i dostawcy
 Umowy

4. Organizacja projektu

sponsor klient interesariusz komitet sterujący

związki
kierownik projektu biuro projektu
zewnętrzne

kierownik kierownik kerownik

zespołu 1 zespołu 2 zespołu n

zespół kontroli zespół 1a zespół 2a zespół na

jakości zespół 1b zespół 2b zespół nb

Kierownik projektu zarządza projektem, a komitet sterujący nadzoruje.

Biuro projektu – typowe administracyjne funkcje, które są zdejmowane z kierownika projektu; prodte
prawy
Biuro programu
Biuro zarządzania projektami – kreuje standardy metodyczne; jest na samej górze struktury
Zespół projektowy – zwykle zorganizowany hierarchicznie, członkowie raportują kierownikowi zespołu
lub bezpośrednio kierownikowi projektu z postępu realizacji proejktu; członkowie raportują o
problemach i problemy te są priorytetowe
Kierownik projektu – jego zadaniem jest operacyjne zarządzanie projektem; mając do dyspozycji zespół
proejktowy, swoją wiedzę i odpowiednie narzędzie musi planowo wykonać projekt; może go wspierać
biuro projektu. Musi motywować zespół, zmusać go do raportowania (monitoruje wszystkie bieżące
sprawy)
Komitet Sterujący
(sponosr + klient – zawsze!!!)
Analizuje cząstkowe produkty i wydaje pewne decyzje; zbiera się w kluczowych momentach; jeżeli z
punktu widzenia komitetu produkt zadowolający „przechodzi dalej”.
Kierownik nie przyjmuje bezkrytycznej decyzji komitetu, ale informuje komitet o tym jakie skutki będzie
miało np. powtórzenie któregoś etapu (koszty itd.). Kierownik również raportuje do komitetu.
Struktury organizacji macierzystej
Relajce między projektem a organizacją macierzystą równie ważne co 3 główne struktury
Projekty w strukturze liniowej
Umieszczenie kierownictwa projektu w strukturze liniowej występuje w takich przypadkach, kiedy
projekt nie jest zbyr kompleksowy i złożony oraz angażuje jeden z obszarów przedsiębiorstwa w dużo
większym stopniu niż inne:

 Krótka droga służbowa dla wydawanych poleceń

 Polecenia są jednoznacznie wydawane i mogą być łatwo zmienione
 Minimalne nakłady na koordynację projektu (nie wchodzą osoby inne niż w dziale)
 Zapewnione przekazanie nabytego doświadczenia na kolejne projekty [wiedza zostaje w ramach
zespołu, który realizując następne projekty ta wiedza wykorzysta]
 Nakłady na personel zarządzający projektem są minimalne
 Dobrze wykorzystany zespół specjalistów [zespół tworzony jest spośród fachowców danej
dziedziny]
 Jasny rozdział zadań, odpowiedzialności i uprawnień [rozdział zadań wg struktury organizacyjnej
zaprojektowanej już wcześniej]
Kierownikiem projektu w strukturze liniowej zostaje kierownik działu, taki projekt nie jest zbyt
rozbudowany, dotyczy jednego działu, kierownik taki spełnia dwie fukcje: jest kierownikiem działu
rpojektu, musi umieć pogodzić te dwie sfery]

Projekty w strukturze macierzowej

Projekt w strukturze macierzowej realizowany jest przez jednostki organizacyjne przedsiębiorstwa,
odpowiednio do ich funkcji, jako usługa dla projektu

 Kierownik projektu działa, jako koordynator oraz jak osoba odpowiedzialna całościowo za
planowanie, serowanie, kontrolę projektu, wyniki, terminy i zasoby
 Kierownik projektu odpowiada za ugodnienia, przeglądy przeprowadzanie zmian i decyzję
 Wielu kierowników projektów sięga po te same zasoby (zasób idzie do tego, gdzie jest większy
priorytet) – najpierw kierownik projektu, potem przełożony, jeżeli o niższym priorytecie –
najpierw przełożony potem kierownik
 Kierownik nie zna wszystkich ludzi w organizacji, ci ludzie są tylko „wyposażeni” siup
 Wybór odpowiedniego kierownika
Rozdzielenie kompetencji w projektowej organizacji macierzowej
Kierownictwo firmy
Kierownik projektu – kierownik wydziału a – kierownik wydziału b
Co? Jaka praca? Kiedy?Do kiedy ma zostać wykonana? Kto?Przyporządkowanie personalne
JAK? Sposoby rozwiązywania fachowe GDZIE? Miejsce wykonania pracy
Kierownik projektu określa i decyduje o tym co ma btć zrobione i do kiedy ma być zrobione
Kierownik wydziału określa kto ma wykonać, jak ma wykonać, gdzie ma wykonać
Wielu kierowników projektów sięga po te zame zasoby. [praca operacyjna miesza się z projektową,
może dojść do konfliktów]
[największe wykorzystanie zasobów spośród innych struktur]
W strukturze projektowej są złożone i komplekwose projekty w długim horyzoncie czasowym
angażujące zasoby organizacji:

 Koncentracja zaangażowanych zasobów na celach projektu

 Jednoznacznie określone uprawnienia do wydawania poleceń
 Przejrzyście określony podział przcy, kompetencji i odpowiedzialnośi
 Wyraźne oddzielne od organizacji macierzystej (zebrani pracownicy)
 Problemy: nieoptymalne wykorzystanie zasobów, problem zabrania praconików z organizacji
macierzystej, osłabienie organizacji macierzystej (zabranie głównychm kluczowych pracowników)
[kierownik ma pełnie władzy w wydzielaniu ludzi i środków, jest w pełni skocentrowany jak i reszta
struktury w cele projektu, nie są rozliczani z czego innego tylko z projektu, kierownik ma pełnie władzy w
rozdzieleniu obowiązków, wyraźny podział pracy, zasoby wykorzystywane a mało optymalny sposób nie
wyciska się z nich pełni możliwości (zasobów)
Kierownik decyduje jaką strukturę obrać w wykonaniu projektu, wytłumaczyć sponsorowi, określić
zasoby

5. Fazy projektu
Cykl życia projektu (charakter kaskadowy – po zakończeniu jednej rozpoczyna się następna faza)
- faza początkowa: potrzeba biznesowa, kontrola zmian, karta projektu, deklaracja zakresu projektu,
plan zarządzania projektem
- faza realizacji: akcje zapobiegawcze i naprawcze, raporty o postępach, podprodukt – produkt końcowy
- faza końcowa: protokoły odbioru, zebrane doświadczenie, archiwum dokumentów, produkt finalny
Fazą proejktu nazywać będziemy skończony predział czasowy w cyklu proejktu, który w swej treści różni
się od pozostałych faz. W ramach faz mogą być wyodrębnione etapy projektu.
Fazy i etapy projektu mają określone ograniczenia czasowe oraz zdefiniowane cele cząstkowe.
Faza początkowa ma wygenerować plan zarządzania projektem:
- karta projektu
- zakres
- cele
- analiza ryzyka
W fazie realizacji są raporty o postępach, czyli wymóg że kierownik projektu iest informowany o
postępach przez zespół projektowy i sam informuje o postępach komitet sterujący. Opracowania
zmieniają się w półprodukty. Produkt powstanie najpierw w 1 szt. Półproduktu, później powstnie kolejny
aby produkować w skali masowej. Produkt finanlny w skali przemysłowej.
W Fazie końcowej zamykamy projekt. Jestzamykany od strony jego zarządzania tym projektem i od
strony produktu finalnego. Projekt jest rozliczany od strony finansowej.
Zamykany od strony zarządzania: kierownik projektu przygotowuje raport z tego projektu, końcowy
Lessons Learned co w projekcie było realizowane, jak był realizowany co się udało a co się nie udało, jak
działał zespół, co się udało zrobić inaczej, jakie problemy były w tym projekcie. Ten raport jest później na
forum organizacji przekazywany, czyl w fazie końcowe jest spotkanie: zespołu projektowego, kierownika
projektu i menadżerów (dyrektorów pionu załej organizacji macierzystej) i dyskutują o Lessons Learned.
Potem ten raport jest zamykany w tak zwsnej organizacyjnej fazie wiedzy.
Archiwizacja dokumentacji projektowej – załość dokumentacji któ®a powstała wokół realizacji projektu
jest zbierana w jednym miejscu, skanowana, kserowana, przechowywana np. w folderach, aby w razie
potrzeby gdy produkt tego projektu po latach będzie sprawiał kłopoty to wraca się do tej dokumentacji i
bada, analizuje.
Ostatnim elementem jest rozwiązanie zespołu projektowego i ta tymczasowa struktura projektu w tym
momencie przestaje istnieć jako odrębny byt, poza organizacją macierzystą przestaje istnieć.
Zasoby wracają do organizacji macierzystej.
Faza końcowa dotyczy uporządkowania kwestii związanych z projektem i produktem, uporządkowanie
związane z tym produktem to usunięci usterek, czyli jeżeli jest produkt dostarczany na koniec fazy
realizacji i komitet sterujący zgłasza usterki względem tego produktu. Potwierdzeniem zamknięcia tych
spraw i porwierdzeniem tych spraw związanych z produktem jest podpisanie odbioru tego produktu.
Komitet sterujący zgłasza problemy z produktem – pojawia się lista usterek – eliminacja isterek i
informuje o tym komitet sterujący – komitet sterujący analizuje działanie produktu, nie zauważa
żadnych usterek a te które zauważtł zostają usunięte – podpisuje protokół odbioru kiedy produkt spełnia
wszystkie wymagania (na tym kończy się zamknięcie projektu w sferze produktowej)
Cykl życia projektu dotyczy metodych kaskadowych,
Rozróżnienie:
W tych projektach gdzie następstwo jest sekwencyjne powinno być realizowane za pomocą metodyki
kaskadowej
W tych proejktach gdzie następstwo faz jest płynne (2 faza będzie się rozpoczynać zanim skończy się 1),
to realizowane jest za pomocą metodyki zwinnej

Realizacja projektu odbywa się zgodnie z terminami, celami, unikaniem określonego wcześniej ryzyka
INICJATYWA w czasie zmienia się w PROJEKT
Faza>etap
Przejścia między fazami (etapami) na ogół definiowane są jako kamienie milowe tj. kluczowe
wydarzenia o szczególnym znaczeniu dla projektu
Podjęcie decyzji odnośnie kamieni milowych to: udzielenie zgody na przejście do kolejnego etapu,
powtórzenie etapu lub etapów, zaniechanie projektu
W metodykach kaskadowych fazy są od siebie oddzielone kamieniami milowymi i następują
sekwencyjnie. W metodykach kaskadowych kamienie milowe są bardzo istotne. Są realizowane tylko w
projektach kaskadowych. Kierownik proejktu dokładnie określa koniec fazy, stawia kamień milowy i jest
w stanie precyzyjnie określić moment rozpoczęcia kolejnej fazy. Jeśli stałość ulegnie zaburzeniu to rola
kierownika projektu polega na tym aby tak żonglować pracami aby logika tych zastępstw jeżeli jest to
możliwe żeby te prace które następują po pracach opóźnionych przesunąć żeby zamknięcie fazy odbyło
się w tym terminie którym kierownik peirwotnie ustalił. Musi pójść wszystko zgodnie z planem albo
kierownik musi być przygotowany na przekształcenia, zamiany następstwa prac. W momencie kiedy jest
kamień milowy jest spotkanie komitetu sterującego który dokonuje ewaluacji rezultatu produktu
cząstkowego, który jest efektem danej fazy. W komitecie sterującym są 2 osoby: sponsor, klient bądź
jego reprezentant. Sponsor i klient patrzą z różnych perspektyw na rezultaty projektu, sponsor ocenia
pod kontem korzyści finansowym, klient: czy projekt jest zgodny z wymaganizmi, które wcześniej zostały
ustalone. Muszą razem dojść do kompromisu, musi być 1 decyzja.
Jak jest komitet sterujący, czyli jak jest kamień milowy i komitet sterujący ewaluuje rezultaty projektów,
dokonuje 3 decyzje:
 Komitet sterujący ocenia rezultaty fazy jako satysfakcjonujące i pozwala kierownikowi projektu
rozpocząć kolejną fazę, nie ma zastrzeżeń
 Komitet sterujący ocenia część funkcji które ma produkt, czyli ocenia fazy półprodukt bądź
produkt jako nie w pełniksatysfakcjonujący, zgodny z tym co chciał, zażyczył sobie komitet
sterujący i nakazuje jego przekonfigurowanie, część prac w danej fazie trzeba powtórzyć
 Produkt powstały w danej fazie jest tak różny, w duży sposób nie odpowiada oczekiwaniom
komitetu sterującego, że jest zdyskwalifikowany, tzn. że albo wracamy do początku fazy i
powtarzamy albo kasujemy ten projekt
Komitet sterujący nie będzie skłonny do skasowania projektu, ponieważ zostały wyłożone już koszty,
może wrócić gdy zmienią się warunki brzegowe albo realia w których funkcjonuje organizacja.
W metodykach kaskadowych fazy są od siebie oddzielone kamieniami milowymi i następują
sekwencyjnie. W metodykach kaskadowych kamienie milowe są bardzo istotne. Są realizowane tylko w
projektach kaskadowych. Kierownik projektu dokładnie określa koniec fazy, stawia kamień milowy i jest
w stanie precyzyjnie określić moment rozpoczęcia kolejnej fazy.
W metodykach zwinnych, podejście adaptacyjne, nie ma kamieni milowych.
W metodykach zwinnym, adaptacyjnym też są fazy, fakt że nie jesteśmy w stanie określić końca fazy jest
pochodną sposobu prowadzenia prac prowadzonych w zwinnych na początku fazy zespół proejktowy
zanalizując wspólnie z właściciel może wprowadzić zmiany, zmienić że wzrośnie z 5 do 7 i to powoduje
opóźnienie fazy. Ilośc interacji jesteśmy w stanie oszacować.
W crumie interacje nazywają się sprintami, mają swoją wewnętrzną strukturę, jest planowanie sprintu,
realizowanie
Zwinne metodyki to iteracje, a w metodyce scrum konkretnie to interacje określane są mianem sprintu,
sprint trwa 1-2 tygodnie, sprinty to okrążenia.
Podejście adaptacyjne to programowanie dla której iteracje dopisuje się nowe funkcje, koduje, jak
trzeba to pewne elementy kodu się kasuje, czyli funkcje się eliminuje
2 dokymenty:
 Plan zarządzania projektem – rezultat 1 fazy
 Specyfika produktu – cechy, wymagania produktu; jeżli zachodzą zmiany produktu (np jeśli klient
zachciał czegoś innego)

3 fazy – poglądowo się wyodrębnia (w projektach będą inne nazwy faz, mogą się nazywać etapami,
może być ich więcej)
1 faza – długa (bo będzie łatwiej później wytworzyć produkt, jeśli wiemy czego chcemy; by być gotowym
do ewentualnych sytuacji, mieć wszystko pod kontrolą) konceptualna praca, dużo wysiłku wymaga.
Przykłady: plany, koncepcje. Tylko w tej fazie mogą zachodzić gruntowne zmiany produktu (np pod
wpływem klientów). Najtrudniejsza, najwięszej pracy wymaga od kierownika
2 faza – powstają produkty cząstkowe półprodukty, prototyp (na początku fazy realizacji, ale nie
zawsze); produkt końcowy pojawia się w fazie realizacji; on jeszcze ma usterki, wady – ich się poprawia
(określa się ich przyczyny, wpływ – podjąć działania, by to naprawić); system raportowania
3 faza - główne aspekty:
 rozliczanie projektu od strony finansowej
 przygotowanie „lessons learnt”
 archiwizacja dokumentacji (musi pozwolić otworzyć proces powstania produktu i zarządzania)
 zawiązanie zespołu projektowego (członkowie zespołu wracają do codziennej pracy)
Produkt zaczyna się być sprzedawany, wykorzystywany przez klienta.
Metoda sześciu kapeluszy: informacje (biały), emocje i intuicja (czerwony), kreatywność (zielony),
zagrożenia (czarny), korzyści i wartość (żółty), organizacja
Ryzyka są definiowanie, jako możliwe wydarzenia lub sytuacje, które mają niekorzystny wpływ na
projekt w odniesieniu do planowanych rezultatów.
Analiza i ocena ryzyka zaczyna się na wstępnym etapie projektu. Musi byż powtarzane okresowo [przez
cały czas życia projektu, przez czas jego realizacji]
Fazy definiowania projektu (medoda 6 myślowych kapeluszy: biały – informacje; zielony – kreatywność;
czerwony – emocje i intuicja; czarny – zagrożenie; żółty – korzyści i wartość; niebieski – organizacja)
(mond maping) (metoda skrzynki morfologicznej)
1. Inicjowanie projektu
 Analiza potrzeb
 Formułowanie inicjatyw proejktu
 Zgałaszanie inicjatyw projektóe kierownictwu
 Analiza i ocena inicjatyw projektów
 Przyjęcie inicjatywy projektu przez kierownictwo do dlszego lub opracowania bądź jej
odrzucenie
2. Określanie projektu (listy kontrolne)
 Sprecyzowanie projektu
 Analiza i ocena ryzyka projektu
 Ocena nakładów i korzyści realizacji projektu
 Podjęcie przez kierownictwo decyzji o realizacji projektu
 Wyznaczanie założeń (celów) realizacji projektu
3. Organizowanie projektu
 Wybór formy instytucjonalnej realizacji projektu
 Powołanie kierownictwa projektu
 Powołanie innych organów kierowniczych projektu
 Organizowanie pracy zespołu proejktowego
 Pozyskanie pracowników zespołu projektowego
 Opracowanie planu pracy zespołu projektowego
 Zatwierdzenie organizacji planu pracy zespołu projektowego przez kierownictwo
4. Określenie struktury projektu (WBS, paliety robocze)
 Sprecyzowanie celów projektu
 Zebranie dodatkowych informacji dotyczących projektu
 Ustalanie kryteriów podziału projektu
 Określenie struktury hierarchicznej proejktu
 Określenie struktury kooperacyjnej proejektu
 Zatwierdzenie struktury projektu przez kierownictwo
5. Planowanie przebiegu projektu

 Określenie czasu realizacji czynności projektu

 Planowanie terminów realizacji czynności projektu
 Obliczenia rezerw czasu
 Określenie krytycznych elementów projektu
 Weryfikacja przebiegu proejktu
 Zatwierdzenie planu przebiegu projektu prze kierownictwo
6. Planowanie zasobów projektu
 Określenie zapotrzebowanie zasobów przez poszczególne czynności projektu
 Planowanie zasobów ludzkich
 Planowanie kosztów projektu
 Planowanie finansowanie projektu
 Budżetowanie proejktu
 Zatwierdzenie planu zasobów projektu przez kierownictwo
 Podjęcie dezyzji o przystąpieniu do wykonawstwa projektu
7. Organizacja wykonawstwa projektu
 Pozyskiwanie środków finanswoych na realizację proejktu
 Planowanie podziału zadań z zakresu wykonawstwa proejktu
 Poszukiwanie dostawców i podwykonawców projektu
 Kontraktowanie dostaw i usług
 Opracowanie sustemów motywacyjnych motywacyjnych wykonawstwa projektu
 Opracowanie systemu zapewnienia jakości projektu
 Zatwierdzenie przez kierownictwo organizacji wykonawstwa proejktu
 8. Kontrola projektu
 kontrola terminów projektu
 kontrola zużycia zasobów projektu
 kontrola kosztów projektu
 kontrola dostaw i podwykonawstwa
 kontrola innych działań
 kontrola pracy zespołu proejktowego
9. Koordynacja proejktu
 Koordynacja terminów proejktu
 Koordynacja zużycia zasobów ludzkich
 Koordynacja kosztów projektu
 Koordynacja dostaw i podwykonawcó
 Koordynacja innych działań (ograniczenie ryzyka, działania pozajościowe itp)
 Koordynacja pracy zespołu projektowego
10. Zamknięcie projektu
 Odbiór projektu przez zamawiającego
 Rozliczenie proejktu
 Opracowanie dokumentacji eksploatacyjnej (chodzi o niejako „instrukcję obsługi” np.
wdrożonych systemó informatycznych)
 Szkolenie użytkowników
 Inne działania wspomagające użytkowników
 Opracowanie raportu z realizacji proejktu [opracowanie 30-40 stronicowe dot. tego jak
przebiegła realizacja, jakie pojawiły się probelemy, w jaki sposób zostały rozwiązane]
 Lessons learned
 Podjęcie decyzji o zakończeniu projektu
 Rozwiązanie zespołu proejktowego

6. Podział prac w projekcie

WBS (work breakdown structure)
 podział pracu odnosi się do rozbicia projektu, jako całości systemu na pojedncze elementy
składowe ze względu na cele, działania lub rezultaty, a następnie zdefiniowanie najważniejszych
zależności między nimi (struktura)
 kluczowy instrument porządkowania i komunikacji w ramach projektu
 ma charakter hierarchiczny
 projekt

podprojekt podprojekt

pakiety pakiety pakiety

prac prac prac

czynności
czynności czynności

Pakiety robocze – są ro zespoły czynności nadające się do wykonania przez jednego –

wewnętrznego lun zewnętrznego wykonawc
Stanowią one połączenie struktury projektu z strukturą organizacyjną
Pakiety robocze = pakiety prac
Struktura podziału prac jest przygotowywana w metodykach kaskadowych, jeśli chodzi o
metodyki kaskadowe to jest narzędzie którym jest struktura podziału prac i przygotowując tę
strukturę podziału prac jednocześnie kierownik projektu dzieli projekt przez takie elementy,
którymi są jednym słowem pakiety prac czy przygotowując strukturę podziału prac kierownik
projektu na samym końcu wyodrębnia pakiety prac które to pakiety prac są takimi najbardziej
detalicznym ujęciem prac w projekcie, czy jeżeli mówimy o tym że są jakieś prace przekazywane
do wykonania członkom zespołu proejktowego albo że kieorwnik proejktu planuje jakieś prace
do wykonania na konkretny termin to w tym momencie operuje on elementami które są to
pakiety prac (zbioru zestawu działań do wykonania)
Problem z podziałem prac jest taki że ma on charakter hierarchiczny, czyli kierownik proejktu
dzieląc zakres prac w projekcie musi przejść przez elementy pośrednie, czyli najpierw dzieli ten
zakres np. na elementy, potem te elementy na ich części skłądowe z tych elementóe dopiero
wyodrębnia pakiety prac, logika wyodrębniania pakietu prac jest na zasadzie od ogółu do
szczegółu.
W zależności od sposobu w jakim kierownik projektu zaczyna wyodręniać te elementy niższego
rzędu możemy rozróżnić 3 rodzaje struktury podziału prac:
 struktury podziału prac w ujęciu funkcjonalnym, struktura podziału prac w której kierownik
proejktu rozpoczyna wyodrębnianie elementów niższego rzędów w tej strukturze, mając na
uwadze fazy i etapy projektów
 struktury podziału prac w ujęciu obiektowym, logika postępowania jest taka sama, czyli że
kierownik proejktu od całości zakresu idzie niżej wyodrębniając poziomy niższego rzędu,
natomiast nie wyodręnia och poprzez pryzmat faz proejktu ale poprzez pryzmat obiektów które
w tym projekcie są możliwe do zdefiniowania, czyli jeżeli celem proejktu jest zbudowanie odiedla
 mieszkaniowego skłądającego się z 4 budynków, to kierownik proejktu potraktuje każdy z tych 4
budynków jako osobny obiekt
 struktury podziału prac w ujęciu mieszanym, są elementy struktury podziału prac w ujęciu
funkcjonalnym i obiektowym, np. 1 część zakresu jest wyodrębniona przez pryzmat faz projektu,
np. faza początkowa i w tej fazie początkowej dla wszystkich budynków są wyodrębnione pakiety
prac a potem kierownik projektu przestaje posługiwać się spojrzeniem fazowym na obiekt i
pozostałe części elementy struktury podziału prac wyodrębnia obiektowo, czyli konkretne
obiekty są rozumiane jako budynki i wyodrębniamy prace z tym związane.
Struktura podziału prac jest punktem wyjścia do wielu różnych analiz, które kierownik projektu
wykonuje planując, organizując proejkt, więc struktura podziału prac jest bardzo ważna, kierownik
projektu musi mieć pakiety prac bo 1 narzędziem, analaiza gdzie wykorzysta pakiety prac będzie macierz
odpowiedzialności zadaniowej, to jest narzędzie, ta macierz ona pozwala kierownikowi projektu nałożyć
pakiety prac które wyodrębnił, a właściwe ostatni element struktury prac na strukturę organizacyją
proejktu, rozrzuca pakiety prac na członków zespołu projektowego np. jak ma 100 pakietów prac i 5
członków ro przyporządkowuje tym osobom w zależności od kompetencji 1 osoba może dostać więcej
od 2.
Jak kierownik projektu rozdzieli te pakiety prac pomiędzy zespół projektowego to mogą zaistnieć 2
sytuacje:
1) Okazuje się że część pakietów prac została nieprzyporządkowana
2) 1 bądź kilku członków zespołu proejktowego nie ma w ogóle pakietów prac do wykonania
Z punktu kierownika projektu sytuacja w której zostają członkowie zespołu projektowego, którzy nie
mają przyporządkowanych żadnych pakietów prac do wykonania jest dużo bardziej korzystna, ponieważ
kierownik zawsze może zmienić zakres proejktu.
( to wszystko w odniesieniu do metodyki kaskadowej )
( to do metodyki zwinne )
Metodyki zwinne, scrum – w nich jest właściciel produktu to co chce klient, jakie ma wymagania
właściciel produktu, umieszcza w dokumencie który nazywa się rejestr produktu, ten rejestr produktu
zwiera następujące elementy: epiki, elementem pośrednim są historyjki)
Epiki to funkcje, historyjki to elementy tych funkcji, epik jest to większa część produktu, opisuje funkcje
produktu, a historyjki opisują w jako sposób klient chciałby że te wszystkie elementy funkcji działały.

Projekty za pomocą scruma – są zorientowane produktowo, w scrumie każdy epik, ta funkcja bądź
funkconalność jest dostarczana, wytwarzana i to jest etap gdzie epik jest zamieniany z historyjek ma
rzeczywiście działająca funkcje nazywa się wydaniem, czyli zespół projektowy scrumowy planując swoje
prace rozumując w kategoriach epików czyli funkcji które produkt powinien zawierać nyśli o kolejnych
wydaniach w których te funkcje będą dostarczone, czyli np. że funkcja zostanie dostarczona w wydaniu 1
to będzie 1 epik i 2 epik to wydanie nr2
Wydanie to nie jest faza projektu, w wydaniu nie ma kamieni milowych
W ramach wydań są sprinty, wydanie zwykle obejmuje horyzont 3 miesięczny, czyli planując wydanie,
myśli się o 3 miesięcach, natomiast myśląc o sprincie myśli się o 2 tygodniach. Dzielenie powoduje że
możemy sobie obliczyć że w 1 wydaniu jest średnio 6 sprintów (2 tyg/3mies). Moment zakończenia
wydania nie planuje się w oparciu o szacowany czas trwania tego wydania, tylko w oparciu o szybkość
prac zespołu.
Ocena i interpretacja hstoryjek – każda osoba kładzie kartę z oceną i potem sprawadzają i sumują – to
się dzieje na eta[ie planowania działania (oceniana jest pracochłonność, dobto tych historyjek)
Płynne następstwo faz, czyli możliwość wydłużania lub skrócenia wydań, bierze się z tego względu że
średnia prędkość zespołu jest średnia czyli są historyjki które zostaną zrealizowane szybciej, bo zespół
pracuje szybciej albo wydłużą kiedy zespół pracuje wolniej, jest 1 zasada zmian: sprintów się nie
wydłuża, sprint trwa 2 tygodnie i koniec (określony czas może być i 3 tygodnie)
Wykres spalania punktów polega on na tym z 1 strony mamy ogólną sumę punktów w wydaniu, którym
powinniśmy zrealizować, a z 2 strony mamy kolejne sprinty, tygodnie w ramach sprintu, wykres ten
pokazuje w jaki sposób prace przebiegają szybciej wolniej niż zakładają

Macierz odpowiedzialności (znana również jako macierz RAM – Responsobility Assignmment

Matrix)
NPV = FV*1(1+k)^n; NPV – zdyskontowane przepływy pieniężne z proejktu, FV – wartość
przepływów rocznych z proejktu, k – ztopa procentowa, n – liczba okresów (lat)
1. faza początkowa 2. faza realizacji 3. faza zakończenia

1.1 etap 1 1.2 etap 2

1.1.1.moduł 1 1.1.2 moduł 2

Dlaczego kodujemy pakiety prac (a nie tylko nazwa) – bo to ułatwia komunikację między
pracownikami i archiwizowanie dokumentów)
Struktura podziału prac:
 punktem wyjścia jest pełny zakres projektu
 zakres ten jest stopniowo dzielony na mniejsze elementy (z reguły osiąga 3-4 poziomy)
 ma każdym poziomie poszczególne elementy są wzajemnie rozłączone i sumują się do zakresu
projektu
 najniższym poziomem podziału w SPP są tzw. Pakiety robocze. Składają się z działań o podobnym
charaktezrze, które można przypisać do konkretnej komórki organizacyjnej lub pracownika
 zakres kosztów i czasu realizacji pakietów powienien być stosunkowo mały
  warto pomyśleć o stworzeniu odrębnego pakietu roboczego pod nazwą „Zarządzanie
projektem”
Faza rozwoju projektu:
 przedstawienie przedmiotu projektu, jako całości
 ustalenie wszystkich uszczegółowionych, a dzięki temu weryfikowanych, jednostek
roboczych (podprojektów, modułów, pakietów prac)
 zestawienie wszystkich powiązanych ze sobą pakietów prac
 nadanie projektowi waszej większej przejrzystości
 ułatwienie osiągnięcia wspólnej wizji produktu projektu
 uporządkowanie pracy
 komunikacja w zakresie zarządzania zmianą
 przydzielenie pakietów prac podwykonawcom

Planujemy – przypisujemy pakiety prac do pracowników, ale to tylko planowanie. Jeżeli nie zostają
pakiety prac, a już nie ma osób – kierownik musi dodać osób do zespołu projektowego. Kierownik musi
mniej więcej rozdzielić obowiązki między członkami zespołu projektowego.
Kierownik określa logikę, następstw między palietami prac, kolejność wykonania pakietów prac, podział
prac itd
Większość pakietów prac lepiej realizować równolegle (a nie sekwencyjnie bo długo to zajmuje)
Bufory – przerwy między wykonaniem zadań (bez przerw, jeżeli będą opóźnienia – przesunięcia)
TB (total buffer – zapas całkowity) – okres czasu pomiędzy najwcześniejszym i najpóźniejszym
położeniem działania na osi czasu. Bufor ten pokazuje nam o ile można wydłużyć czas trwania prac w
ramach jednego pakietu prac bez zmiany terminu następnego. TB=LS-ES=LF-EF
FB (free buffer – zapas swobodny) – okres czasu o który działania może zostać odroczone od swego
położenia najwcześniejszego, zanim osiągnie limit najwcześniejszego rozpoczęcia swego następnika
FB=ESB-EFA
Ścieżka krytyczna – muszą być zgodnie z terminami, bez opóźnień. Bo jeżeli coś pójdzie niesprawnie, to
będzie jak domino – wszystko się spóźni – trzeba będzie skracać czas innego zadania/ w inny sposób to
naprawiać, zminimalizować negatywne skutki)
Nie na ścieżce krytycznej – nie ma znaczenia, czy terminy się pzesuną czy nie
Harmonogram – określony tu moment rozpoczęcia i zakończenia, czas trwania, kamienie milowe (jako
pakiety prac o zerowym czasu trwania). Harmonogram, który kierownik stwarza na początku –
harmonogram wstępny (bazowy), a później będą się pojawiały kolejne (bieżące) wersje harmonogramu
(widzi jak się różni planowanie: rzeczywiste, jaka jest różnica)

Elementy w SCRUM są ze sobą ściśle powiązane. Trudno jest rozdzielić jedno od drugiego.
4 wydarzenia:
1) wydarzenie – planowanie sprintu
2) budujemy SCRUM

3 Artefakty:
- rejestr produktu – org. Product Backlag
- rejestr printu – org. Spint Backlag
- inkrement – okreśkenie

3 roli:
1) właściciel produktu
2) SCRUM master
3) Developerzy
Za Product Backlag jest odpowiedzialny właściciel produktu (product owner)
Product Owner – konatakt z klientem, zapisuje tematy (to, co może być zrealizowane) do Rejestru
Produktu; życzenia: oczekiwania klienta. On jest pomostem między klientem a developerami
(organizacją). Robi to, by developerzy wiedzieli, co się dzieje u klienta i co może być zrobione w
przyszłości. Temat może być zrealizowany, ale nie musi.
Product Backlag: szczegółowe elemnty (tematy, historyjki) -> mają charakter ewergentny (każdy
zamienia się w inny: temt->epiki->historyjki użytkownika) -> realizują zadania zamierzone na przyszłość.
Temat zamienia się w epiki – bardziej szczegółowe elemnty. Epik – opisuje zazwycaj rodzaj
funkcjonalności, opisuje moduły. Historyjka – opis fukcji, mają określony format najbardziej
szczegółowe.
Forma, w jakiej jest opisywana historyjka jest określona [jako <nazwa użytkownika> chciałb ym określić
móc <akcja> dzięki czemu <powód]
HARMONOGROWANIE I PLANOWANIE ZASOBÓW
Rozumiane całościowi ustalanie kolejności działań i zarządzanie harmonogramem wymaga
przeprowadzania następujących działań:
 Szczegółowego opisu pakietów zadań, określenie ich kolejności
 Stworzenie planu porządkowania i harmonogramowania działań
 Optymalizacja i publikacja planowanych harmonogramów oraz ich uaktalnianie

Planowanie
Główne poziomy planowania zwinnego
Poziom planowania Częstliwość Kto Centrum wagi
Produkt 1-2 razy w roku ProductOwnerZarząd Rozwój produktu na
 przestrzeni czasu
Wydanie 3-4 razy w roku ProductOwner Zespół Kompromisy między
funkcjonalnością i datą
dostarczenia
Sprint Co 1-4 tygodnie ProductOwner Zespół Jakie funkcjonalności
mogą być dostarczone
w Sprincie
DailyScrum Każdy dzień Zespół Jak zrealizować
funkcjonalność
Wydanie dotyczy kluczowych finkcjonalności produktu (w ramach 1 produktu może być kilka wydań)
W ramach wydań są sprinty
Sprint zaczyna się w środku tygodnia
Zawsza dokłądnie, precyzyjnie na ile możliwe
->Plany muszą być dokładne ->ale zyskuj precyzje z czasem:
[ukończymy między wrześniem a październikiem]
[skończymy w październiku]
[będzie gotowe na 5 października]
->jak dokłądnie możesz określić sprzedaż w przyszłym roku?
Podejście adaptacyjne
TibeBox toograniczenie czasowe przypisywan różnym wtdarzeniom. Jest to maksymalny dopuszczalny
czas trwania.

Adaptacyjne zarządzanie projektami (Agile Project Management) to podejście wykorzystujące zbiór

różnych metodyk, określanych jako zwinne, lekkie lub elastyczne (ang. Agile Methodologies) oraz
narzędzi stosowanych w zarządzaniu złożonymi i innowacyjnemi projektami. Charakteryzuje się stałą
współpracą z klientem, dlatego też ramy prjketu nie ściśle określone, a sam projekt podzielony jest na
mniejsze części tzw. funkcjonalności (iteracje). Zespoły Agile dodatkowo często dokonują zmian i korekt
w nawiązaniu do wymogów i oceny klienta, uwagę skupiając głównie na pracy nad powierzonym
zadaniem.
Indywidualizm to kolejny aspekt wyróżniający się w metodach zwinnych. Odchodzi się w tym przypadku
od stadaryzacji. Cechą charakterystyczną adaptacyjnego zarządzania projektami jest stanowcze
zmniejszenie ilości dokumentów. Metody Agile zapewniają gamę technik, dzięki którym możliwe jest
zaczęcie realizacji projektu bez pewności wykonania założonych celów. Proponują również metody
uporządkowania zadań w projekciem aby zagwarantować, że zespół będzie realizował odpowiednie
czynności, bez znajomości człego zakresu projektu.
Medoty oderowane w ramach adaptacyjnego zarządzania projektami nie są adekwatne do wszystkich
rodzajów proejktów, szczególnie takich które są bardzo duże i rozbudowane oraz niezbędne są spore
wydatki technologiczne. Metody Agile nie nadają się również w zagmatwanych projektach, gdzie ciężko
klientowi jest zrozumieć jak będzie wyglądał efekt końcowy.
Manifest Agile, a dokładniej Manifest Zwinnego Tworzenia Oprogramowania (ang. Manifesto for Agile
Software Development) to dokument, który ukazał się w 2001r. w ośrodku wypoczynkowym Snowbird w
USA i zapoczątkował dynamiczny rowój adaptacyjnego zarządzania projektami. Manifest Agile
spowodował głębokie przemiany w środowiskach programistycznych, a następnie przeniknął w niektóre
obszary zarządzania projektami. Powstanie Agile Project Management było w dużej mierze reakcją na
mało elastyczne metody zarządzania projektami informatycznymi, które uważano wówczas za zbyt
sformalizowane i mało efektywne.
Główne cele i zasady stosowania zwinnych metodych w ramach zarządzania projektami:
 Elastyczność i adaptacyjność projektowania względem dynamicznie zmieniających się potzreb i
oczekiwań klienta (stąd termin zwinne – ang. Agile)
 Tworzenie wartościowych i innowacyjnych rozwiązań zarówno dla firmy jak i konsumentów na
każdym etapie projektowania
 Minimalizacja kosztów m.in. dzięki skróceniu harmonogramów procesu wytwarzania
 Koncentracja na członkach zespołu proejktowego, wzrost motywacji wśród 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
 Satysgakcja klientów dzięki szybkiemu i regularnemu dostarczaniu wartościowego produktu
 Minimalizacja ryzyka (Manifesto for Agile Software Development)
Rola zespołu w projektowaniu zwinnym
 Członkowie zepsołu projektowego realizują wiele funkcji; nie jest zachowana żadna struktura
organizacyjna, zespół sam sobą zarządza
 Członkowie zespołu są odpowiedzialni za problemy, które są do rozwiązania we wszystkich
funkcjonalnościach
 Każdy członek zespołu podejmuje decyzję w jaki sposób zrealizuje wyznaczone przed nim zadania
 Kluczowym wyzwaniem jest ograniczenie do minimum tworzenie dokumentacji i rozwijanie
bezpośredniej wymiany informacji między uczestnikami zespołu. Gdy członkowie projektu
pracują z innych lokalizacji, wykorzystuje się regularne formy komunikacji wykorzystujące
przestępne różne formy komunikatorów, głównie narzędzi internetowych
Metody zaliczane do nurtu Agile
 Metodyka SCRUM (K.Schwaber i J.Sutherland)
 Metodyka Crystal (A.Cockburn)
 Metodyka Extreme Programming (K.Beck, W.Cunningham I M.Fowler)
 Adaptive Software Development (J.Highsmith)
 Dynamic Systems Development Method
 Feature Driven Development
 Behavior Driven Development/Acceptance Driven Development
 Lean Software Development (E.Ries)
 Kanban (D.Anderson)
Założenia metodyki SCRUM
Założenia metodyki SCRUM są bardzo proste. Całóść pracy dzielona jest na mniejsze kawałki, zwane
„sprintami”. Przyjmuje się, że sprinty nie powinny trwać dłużej niż 30 dni kalendarzowych. W praktyce,
czas ten może być zróżnicowany i zależy od indywidualnych preferencji każdego zespołu.
Metodyka SCRUM to jedna z najpopularniejszych metodyk zwinnych w zarządzaniu projektami IT,
oparta na zasadach Agile. To metodyka, która daje możliwość rozwiązywania złożonych problemów,
adaptacji produktu, do wymagań klienta. Scrum umożliwia wydajne i innowacyjne kreowanie produktu,
o możliwe jak najwyższej jakości dla klienta, ze względu na iteracyjny (przyrostowy) proces kontroli.
Metodyka SCRUM przez twórców metody definiowana jest jako ramy procesu (z ang. Famework), w
którym można wdrożyć różnorodne podprocesy oraz techniki w celu zarządzania złożonym rozwojem
produktu. Dzięki metodyce Scrum rozpoczęcie pracy wymaga określenia „wizji” produktu, bez
konieczności dokładnego wyznaczenia szczegółowych cech formy, w jakiej ma zostać dostarczony
klientowi.
Teoria SCRUM opiera się na empirycznej teorii sterowania procesem. Empiryzm zakłada, że wiedza
pochodzi z doświadczenia i podejmowania decyzji opartych na tym, co jest już znane. Scrum stosuje
podejście iteracyjne (przyrostowe) w celu optymalizacji przewidywalności i kontroli ryzyka.
Zdefiniowano trzy filary, które podtrzymują każdą implementację kontroli procesu: przejrzystości (ang.
Transparency), adapracji (ang. Adaptation) oraz inspekcji (ang. Inspection)
 filar przejrzystości – istotne aspekty procesu muszą być zaprezentowane oraz zrozumiałe dla
osób odpowiedzialnych za wyniki, ponadto muszą być określone wspólnym standardem oceny.
Dzięki temu cały proces, jego kontrola oraz cel końcowy są „przejrzyste”
 filar adaptacji – w przypadku zarejstrowania podczas rutynowych kontroli, jakiegokolwiek
czynnika, który zaburza proces, filar adaptacji pozwala zespołowi na zmianę podejścia do
sposobu pracy z dnia na dzień
 filar inspekcji – zakłada, że kontrole postępu prac, powinny być częste na tyle, by wykryć
możliwość ulepszenia lub też zapobiec błędom jak najwcześniej. Aczkolwiek nie mogą być na tyle
częste, by przeszkadzać w pracy zespołowi. Filar inspekcji zakłada również, że kontrola powinna
być przeprowadzana przez wysoko wykwalifirowanego inspekora.
Zespóły SCRUM są autonomiczne i wielofunkcyjne, jednostki zepsołu pracując razem, mają wszystkie
kompetencje niezbędne do wykonania danego zakresu pracy. Ma to na celu optymakizację wydajności,
elastyczności i kreatywności. J.Wewerka, M.Turek, T.Włodarek, Systematyczny opis metodyki Scrum dla
zespołów projektowych, „Studia Informatica”, 2012 nr 1
 Właściciel produktu odpowiada za maksymalizację wartości produktu. Jego zadaniem jest
konsultacja z klientem oraz opracowanie wizji produktu. W trakcie procesu tworzenia Właściciel
odpowiada za kontrolę każdego etapu jego powstawania, tak by spełnić wszystkie oczekiwania
postawione przez klienta. Właściciel produktu koordynuje również pracę Zespołu
odpowiedzialnego za rozwój oraz ściśle z nim współpracuje.
 Zespołu odpowiedzialnego za rozwój (Development Team) – odpowiedzialny za rozwój składa
się z profesjonalistów, specjalizujących się w konkretnych dziedzinach, których zakres wiedzy
pokrywa wszystkie aspekty tworzenia produktu. Zespół ten upoważniony jest przez pracodawcę
do organizacji i zarządzania czasem oraz wyznaczonymi zadaniami , oczywiście pod warunkiem,
że dane etapy zostaną ukończone w odpowiednim czasie
 Mistrz Scrum odpowiada za wyjaśnienie w jasny sposób zastosowania metodyki Scrum w
konkretnym projekcie. Kontroluje proces tworzenia produktu oraz tryb pracy Zespołu
odpowiedzialnego za rozwój. Mistrz Scrum odpowiada za tom bt wyznaczona metodyka była
kontynuowana w trakcie procesu.
Definicja SCRUM
Scrum to uproszczone ramy postępowania, które pomagają poszczególnym osobom, zespołom i
organizacjim wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów.
Najprościej rzecz ujmując, SCRUM wymaga, aby Scrum Master przyczyniał się do tworzenia
środowiska, w którym:
 1. Product Owner porządkuje pracę potrzebną do rozwiązania złożonego problemu, tworząc
Product Backlog
2. Scrum Team przekształca wybraną część tej pracy w wartościowy Increment w trakcie Sprintu
3. Scrum team oraz jego interesariusze sprawdają efekty i dostosowują swoje działania na potrzeby
kolejnego Psrintu
4. Powtórz
Scrum jest prosty. Wypróbuj go w postaci, w jakiej został tu opisany i sprawdź, czy jego filozofia,
teoria oraz struktura pomogą ci w osiągnięciu celów i tworzeniu wartości. Scrum rozumiany jako
ramy postępowania jest celowo niekomplenty, definiuje jedynie elementy wymagane do
wdrożenia teorii Scruma. Scrum opiera się na inteligencji zbiorowej jego użytkowników. Zamiast
dawać ludziom szczegółowe instrukcje, reguły Sruma pozwalają kształtować wzajemne relacje i
interakcje. W Scrumie można stosować różnorodne procesy, techniki i metody. Scrum obejmuje
istniejące praktyki lub sprawia, że stają się zbędne. Scrum unaocznia względną skuteczność
dotychczasowego zarządzania, środowiska, technik pracy, zby umożliwiać wprowadzenie
usprawnień.
Scrum Team
Podstawowym elementem Scruma jest nieiwielki zespół, czyli Scrum Team. W skład Scrum Teamu
wchodzi jeden Scrum Master, jeden Product Owner oraz Developerzy. Scrum Team nie dzieli się na
podzespoły, nie obowiązuje w nim hierarchia. To spójna grupa profesjonalistów skupionych na
pojedynczym celu określanym jako Cel Produktu.
Scrum Teamy są interdyscyplinarne, co oznacza, że ich członkowie mają wszystkie umiejętności
potrzebne do wytwarzania wartości co Sprint. Są także zespołami samozarządzającymi, co oznacza, że
samodzielnie podejmują decyzję o tym, kto będzie wykonywał określone zadania, kiedy i jak.
Scrum Team jest wystarcająco niewielki, aby pozostawać zwinnym, a jednocześnie wystarczająco liczny,
aby móc ukończyć znaczącą część pracy w Sprincie, zwykle skłąda się z 10 osób lub mniej. Jak wynika z
naszego doświadczenia, mniejsze zespoły na ogół lepiej się komunikują i są bardziej produktywne. Jeśli
Scrum Teamy stają się zbyt liczne, powinny rozważyć przeorganizowanie si,ę w kilka spójnych Scrum
Teamów skupionych ma tym samym produkcie. Dlatego powinny mieć wspólny Cel Produktu, Product
Backlog oraz tego samego Product Ownera.
Scrum Team ponosi odpowiedzialność za wszystkie działania związane z produktem obejmujące
współpracę z interesariuszami, weryfikację, utrzymanie, obsługę, eksperymentowanie, badania i rozwój
oraz wszelkie inne działania, które mogą okazać się konieczne. Zespół ma odpowiednią strukturę oraz
uprawniwnia nadane mu przez organizację, by móc zarządzać własną pracą. Równimierna tempo pracy
w Sprintach korzystnie wpływa na skupienie i przewidywalność zespołu.
Cały Scrum Team ponosi odpowiedzialność za wytworzenie wartościowego, użytecznego Incrementu co
Sprint. Scrum określa trzy konkretne zakresy odpowiedzilności w ramach Scrum Teamu: Developerów,
Product Ownera oraz Scrum Mastera.

Developerzy to osoby w Scrum Teamie zobowiązane do wytworzenia każdego aspektu użytecznego

Incrementu w każdym czasie. Zakres konkretnych umiejętności niezbędnych Developerom często bywa
szeroki i różni się w zależności od dziedziny. Tym niemniej Developerzy zawsze ponoszą
odpowiedzialność za:
 Stworzenie planu Sprintu, czyli Sprint Backlogu
 Ciągłe zapewnianie jakości poprzez postępowanie zgodnie z Definicją Ukończenia
  Codzienne dostosowywanie planu tak, aby osiągnąć Cel Sprintu
 Wzajemne egzekwowanie odpowiedzialnności zawodowej
Product Owner ponosi odpowiedzialność za maksymalizowanie wartości produktu będącego efektem
pracy Scrum Teamu. Sposób, w jaki to robi, może znacznie się różnić w zależności od organizacji, Scrum
Team bądź poszczególnych osób. Product Owner ponosi również odpowiedzialność za skuteczne
zarządzanie Product Backlogiem, co obejmuej:
 Opracowywanie i jasne artykułowanie Celu Produktu
 Tworzenie i jasne artykułowanie elmentów Product Backlogu
 Porządkowanie elementów Product Backlogu
 Zapewnienie przejrzystości, dostępności i zrozumienia Product Backlogu
Jest jedyną osobą zarządzającą Rejestrem Produktu
Określa kolejność elementów Rejestru Produktów
Zapewnia, że jest on dostępny, przejrzysty i jasny
Zapewnia, że zespół deweloperski rozumie elementy Rejestru Produktu
Product Owner może wykonywać powyższe zadania samodzielne lub zlecać je innym osobom. Niemniej
to Product Owner pozostaje za nie odpowiedzialny
Aby praca Product Ownera mogła przynosić pożadane efekty, jego decyzje muszą być respektowane
przez całą organizację. Decyzje te uwidoczniają się w treści oraz kolejności elementów Product Backlogu
oraz w Incremencie, który może zostać poddany ocenie podaczas Sprint Review
Product Owner to jedna osoba, nie komitet. Product Owner może w Product Backlogu uwzględniać
potrzeby licznych interesariuszy. Ci, którzy chcą dokonać zmian w Product Backlogu mogą to zrobić,
próbując przekonać do tego Product Owner

Scrum Master ponosi odpowiedzialność za to, aby Scrum był stosowany zgodnie z tym, co zostało
opisane w tym Przewodniku. Realizuje to zadanie, pomagając wszystkim w zrozumieniu teorii i praktyki
Scruma, zarówno w samym Scrum Teamie, jak i w organizacji.
Scrum Master ponosi odpowiedzialność za efektywność Scrum Teamu. Czyni to poprzez stwarzanie mu
odpowiednich warunków do poprawy stosowanych przez niego praktyk, zgodnie z regułami Scruma.
Scrum Masterzy to prawdziwi liderzy działający na rzecz Scrum Teamu, jak i szerzej rozumianej
organizacji.
Scrum Master wspiera Scrum Team na kilka sposobów, m.in.:
 Insruuje członków zespołu, na czym polega zamozarządzanie i interdyscyplinarność
 Pomaga Scrum Teamowi skupić się na wytwarzaniu wartościowych Incrementów zgodnych z
Definicją Ukończenia
 Sprawia, że przyczyny organizacje postępy Scrum Teamu zostają usunięte
 Dba o to, aby wszystkie wydarzenia scrumowe się odbywały, były konstruktywne i produktywne
oraz by mieściły się w wyznaczonych ramach czasowych
Scrum Master wspiera Product Ownera na kilka sposobów:
 Pomaga znajdować techniki pozwalające na skuteczne określenie Celu Produktu oraz zarządzanie
Product Backlogiem
 Pomaga Scrum Teamwi zrozumieć potrzebę jasnego i zwięzłego formułowania elementów
Product Backlogu
 Pomaga wprowadzać empiryczne podejście do planowania pracy nad produktem w złożonym
środowisku
  Wspomaga współpraće z interesariuszami, kiedy zostanie o to poproszony lub kiedy zachodzi
taka potrzeba
Scrum Master wspiera organizację na różne sposoby, m.in.:
 Przewodzi organizacji, szkoli i instruuje ją w procesie wdrażania Scruma
 Planuje i doradza w wykorzystywaniu Scruma w organizacji
 Pomaga praconikom i interesariuszom w zrozumieniu oraz stosowaniu empirycznego podejścia
do złożonych problemów
 Usuwa bariery pomiędzy interesariuszami w Scrum Teami
Sprint

W sprincie 2 tugodniowym odbywają się codzienne spotkania, codzienny scrumtu historyjki wchdzą z
rejestru ptoduktu do sprintu ściśle określone historyjki które zespół ma zaimplementować, zbudować, w
momencie gdy jest planowanie sprintu określane są priotytety i cel sprintu. W momencie planowania
sprintu historyjki dzielone są na zadania.

To wykresy spalania są robione na każdym codzienym scrumie, spotkanie zespół projektowy w którym
uczestniczy tylko ten zespół projektowy, potykają się codziennie na określony czas, zawsze ten sam i
zadają sobie pytania co zrobiłem wczoraj, co zrobię dziś i co będę robił jutro, oceniaj swoją pracę dzień
po dniu, ustalaj postęp prac.
Zawalidrogi to elementy które przeszkadzają zespołowi proejktowemu w sprincie, czyli np. że jednemu
padł komputer i nie ma na czym pracować, 2 ma sprawy rodzinne i go nie będzie. Lista zawalidróg
nazywana jest rejestrem zawalidróg, scrum master ma je usunąć.
Tablica korkowa – opisuje historyjki do zrobienia, na karteczkach obrazują sobie hisotryjki i zadania do
zrobienia. Obok wisi wykres spalania, rejestr zawalidróg.

Planowanie Sprintu
Sprinty są pulsem Scruma. W Sprintach pomysły są przekształcane w wartość.
Są to wydarzenia o ustalonej długości, trwają maksymalnie miesiąc dla uzyskania regularności. Nowy
Sprint rozpoczyna się natychmiast po zakończeniu poprzedniego.
Cała praca niezbędna do osiągnięcia Celu Produktu, z uwzględnienie, zdarzeń: Sprint Planning Daily
Scrum, Sprint Review oraz Sprint Retrospective, odbywa się w Sprintach.
W czasie trwania Sprintu:
 Nie dokonuje się żadnych zmian, które zagrażałyby osiągnięciu Celu Sorintu
 Jakość nie spada
 Product Backlog jest w razie potrzeby uszczegóławiany
 Zakres pracy może być doprecyzowany lub renegocjowany z Producy Ownerem wraz z rosnącym
zrozumieniem
Sprint Planning rozpoczyna Sprint poprzez rozplanowanie pracy do wykonania w Sprincie. Powstały plan
jest efektem wspólnej pracy całego Scrum Teamu.
Product Owner gwarantuje, że uczestnicy są przygotowani do omówienia najważniejszych elementów
Product Backlogu oraz tego, jak powinien zostać sformułowany Cel Produktu. Scrum Team może
zaprosić na Sprint Planning także osoby w charakterze doradców.

Celem Daily Scrum jest sprawdzenie postępów w dążeniu do osiągnięcia Celu Sprintu oraz w razie
konieczności zadaptacja Sprint Backlogu, czyli dostosowanie zaplanowanej pracy.
Daily Scrum to 15-minutowe wydarzenie dla Developerów danego Scrum Teamu. Aby ograniczyć
złożoność, odbywa się ono w tej samej porze i w tym samym miejscu w każdy dzień roboczy w trakcie
trwania Sprintu. Jeśli Product Owner lub Scrim Master wykonują praće związaną z elementami Sprint
Backlogu, uczestniczą w spotkaniu jako Developerzy.
ScrumMaster jest na planowaniu Sprintu, organizuje to spotkanie, ale głos nie zabiera. On jest neutralny,
zorientowany na pomoc zespołowi. Odpowiada za porządek na tym spotkaniu.
Tablica – wykresy, wykres spalania sprintu, lista przeszkód (przygotowuje Scrum Master)
Backlog – histroyjki
To Do – zadania do wykonania
Dev – pracujemy nad zadaniami
Test – testowanie
Done – zrobione
Co zrobiłem wczoraj? Co zrobię dzisiaj? Co zronię jutro? Czy jest coś co utrudnia mi-nam osiągnięcie
Celu Sprintu?
Wykrest spalania:
2 rodzaje:
- wydania: łączna złożoność historyjek np. 120, w ramach wydania 3 miesięcznego, 6x2tygodniowe
sprinty. Po każdym sprincie uzupełniany, dorysowana czerwona linia wyznacza wczorcową prędkość
zespołu; zielona linia rzeczywisty stan prędkości – powyżej czerwonej (w tyle), powyżej (do przodu)
- sprintu: oś Y-produktywność zespołu w godzinach (do 8h dziennie); oś X-dni
Godziny/dni=optymalna liczba roboczogodzin (160/10=16h)

Product Backlog to ewoluująca, uporządkowana lista tego, co jest konieczne dla ulepszenia produktu. To
jedyne źródło pracy podejmowanej przez Scrum Team. Elementy Product Backlogu, które mogą zostać
Ukończnone przez Scrum Team w trakcie jednego Sprintu, zostają uznane za gotowe do wybrania
podczas Sprint Planningu. Zwykle osiągają ten stopień przejrzystości w procesie ich doskonalenia.
Doskonalenie (ang.refirement) Product Backlogu to działanie polegające na dzieleniu elementów
Product Backlogu na mniejsze, bardziej precyzyjnie zdefiniowanie jednostki oraz na ich dookreślaniu. To
ciągły proces, którego celem jest dodawanie szczegółów, takich jak opis, kolejność czy rozmiar.
Właściwości te często są różne w zależności od specyfiki pracy.
Developerzy, którzy będą wykonywać pracę, są odpowiedzialni za określenie wielkości elementó Product
Backlogu. Product Owner może wpływać na Developerów, pomagając im w zrozumieniu oraz w
dokonywaniu wyborów.
Zobowiązanie: Cel Produktu
Cel Produktu opisuje przyszły stan produktu, który może posłużyć Scrum Teamowi jako punkt
odniesienia w procesie planowania. Cel Produktu jest odzwierciedlony w Product Backlogu. Pozostała
część Product Backlogu ewoluuje, aby określić „co” przyczyni się do odsiągnięcia Celu Produktu.
Produkt to sposób na dostarczenie wartości. Ma jasno określone granice, znanych interesariuszy, dobrze
zdefiniowanych użytkowników lub klientów. Produkt może być usługą, fizycznym produktem bądź czymś
bardziej abstrakcyjnym.
Cel Produktu to długoterminowe zamierzenie Scrum Teamu. Zespół musi zrealizować jeden cel (lub z
niego zrezygnować), zanim przystąpi dom realizacji kolejnego.

Sprint Backlog
Na Sprint Backlog składają się: Cel Sptintu (po co), elementy Product Backlogu wybrane do realizacji w
Sprincie (co) oraz wykonalny plan dostarczenia Incrementu (jak)
Sprint Backlog to plna przygotowany przez Developerów dla nich samych. Jest dobrze widoczną, na
bieżąco aktualizowaną reprezentacją pracy, którą Developerzy planją wykonać w trakcie Sprintu, zby
zrealizować Cel Sprintu. Dlatego Sprint Backlog jest uaktalniany przez cały Sprint wraz z rosnącym
zrozumieniem. Powinien być dostatecznie szczegółowy, aby Developerzy mogli na jego podstawie
sprawdzić swoje postępy podczas Daily Scrum.
Zobowiązanie: Cel Sprintu
Cel Sprintu jest jednym celem w Sprincie. Choć Cel Sprintu jest zobowiązaniem Developerów,
pozostawia swobodę pod względem tego, co dokładnie należy zrobić, aby osiągnąć. Ce; Sprintu
zapewnia także spójność i skupienie, zachęcając Scrum Team do wspólnego wykonywania pracy, a nie
podejmowania odrębnych przesięwzięć.
Cel Sprintu formułuje się podczas Cprint Planningu, a następnie uwzględnia go w Sprint Backlogu.
Pracując w Sprincir Developerzy mają na uwadze to, jaki jest Cel Sprintu. Jeśli okazuje się, że praca do
wykonania nie pokrywa się z ich przewidywaniami, współpracują z Product Ownerem, aby
wynegocjować zakres Sprint Backlogu w trakcie Sprintu, nie zmieniając przy tym Celu Sprintu.

Increment to konkretny krok w kierunku osiągnięcia Celu Produktu. Każdy kolejny Increment
rozbodowuje wszystkie wcześniejsze, jest też skruptulatnie weryfikowano po to, aby zapewnić, że
wszystkie Incrementy są do siebie dopasowane. Aby dostarczyć wartość, Increment musi bć użyteczny.
W trakcie Sprintu może zostać wytworzonych wiele Incrementów. Przedstawienie sumy Incrementów
podczas Sprint Review wspiera podejście empiryczne. Jednakże Increment może zostać dostarczony
interesariuszom przed zakończeniem Sprintu. Nigdy nie należy traktować Sprint Rewiew jako jedynego
punktu decyzyjnego dopuszczającego dostarczenie wartości.
Praca nie może zostać uznana za część Incrementu, jeśli nie jest zgodna z Definicją Ukończenia.

Backlog Refinement – pielęgnacja backlogu

- dodanie elementu, usunięcie elementu, zmiana priorytetów, dodanie szczegółów, aktualizacja
- odpowiedni wybrany czas, brak określenia odgórnego, indywidulany wybóę czasu
Zmiany ze względu na potrzeby klienta, zmianę wymagań
Dodanie kryteriów akceptacji
Porządkowanie elementów Rejestru Produktu
Do % pojemności zespołu seweloperskiego

DEEP
Detailed appropriately Estimated Emergent Prioritized
User Story (historyjka) – czyli historia użytkownika, odpowiada o kliencie lub użytkowniku korzystającym
z produktu. Zawiera imię, krótki opis oraz kryteria akceptacji

Wydarzenia w Sprincie:
1) Planowanie Sprintu
2) Daily Scrum
3) Przegląd Sprintu (Sprint Review)
4) Retrospektywa

Vebsity (prędkość zespołu) – rednia liczba punktów użytkownika, które zespół jest w stanie
zaimplementować.
 1. Planowanie Sprintu
Skupione wokół:
->co zostanie zrealizowane
->jak zostanie zrealizowane
8h dla 4tygodniowego Sprintu
4h dla 2tygodniowego Sprintu

Sprint zaczynać w środku tygodnia np. w środę planowanie

Zespół planuje co chce osiągnąć, kieruntk, na czym się koncentruje, ustala cel Sprintu
Na wejściu: Backlog, Przyrost Produktu (nie ma jakichś funkcji a za jakoś czas to będzie to co chcemy
osiągnąć, przyrost wartości), Prędkość zespołu na bazie kilku ostatnich sprintów, Dostępność Zespołu w
nadchodzącym sprincie
Na wyjściu: Cel Sprintu, Sprint Backlog (pełne wypełnienie Sprintu prawdopodobnie się nie spawdzi)
Wydanie – większa pula Sprintów, klient dostaje coś dużego (np. działająca funkcja złożona)
Przyrost
Planowanie wydania – wybieramy 2/3 epiki (w każdym jakieś fukcje działające), składają się na jedną
funkcjonalność
Planning Poker – karty, każdy rzuca kartę z odpowiednią złożonością historyjki, określenie za pomocą
kart stopień złożoności jaki dana historyjka wg nich ma
 Moderator (zwykle Product Owner) czyta opis zadania i odpowiada na pytania. Postarajcie się nie
przedłużać dyskusji w nieskończoność. Skutecznie działa ustawienie limiru czasowego.
 Na sygnał szyscy jednocześnie wyciągają kartę z wartością mówiącą na ile Story Pints ich zdaniem
wyceniają to zadanie.
 Jeżeli estymaty się nie różnią, to prawdobodobnie dobrze rozumiecie zadanie i macie wspólnie
ustaloną wartość Story Points dla niego
 Różnice między dwiema kolejnymi wartościami w ciągu stanowią błąd statystyczny. Dlatego jeżeli
estymaty różnią się nieznacznie to zespół może przedyskutować wybór lub przyjąć własną regułę
(np. większość głosów)
 Jeżeli estymaty znacznie się różnią to osoby, które pokazały najniższą i najwyższą liczbę
odpowiadają, dlaczego zaproponowali taką estymatę. Nie chodzi tu o bronienie swojego zdania
tylko o odkrycie założeń, z których rozbieżności wynikają. Następnie głosowanie jest powtarzane.
Zwykle po dwóch, trzech głosowaniach udaje się dojść do porozumienia i można przejść do
estymowania kolejnego zadania. Dlatego jeżeli po kilku rundach dalej utrzymuje się rozbieżność
to najprawdopodobniej w zadaniu jest zbyt dużo niewiadomych i wymaga ono lepszego
zrozumienia przez zespół. W przeciwnym przypadku, wzięcie go do Sprintu będzie się wiązało z
dodatkowym ryzykiem.
Dojście do kompromisu dot. złożoności
Epiki – poziom ogólności, którym zajmujemy się na poziomie wydania
WYDARZENIE – iteracja w krótszym okresie, plan wydania, wydanie, retrospektywa wydania
Historyjka – dzielona na zadania – zadanie nie dłuższe niż 8h
Planowanie Sprintu – spotkanie, określony timebox, ograniczona liczba osób; Właściciel Produktu
wyświetla backlog, mówi, co chciałby, by było zaimplementowane, kryteria akceptacji każdej z historyjek
(parametry, które musi spełniać działająca funkcja)
Każdy Sprint dodaje wartość. Product Owner
Sformułowanie Celu Sprintu, dlaczego jest on wartościowy, Cel Sprintu określony przed zakończeniem
Sprint Planningu

Developerzy wyznaczają które historyjki zostają, a które oni wywalją

Wybór elmentów Product Backlogu, nad którym będą pracować
W jaki sposób zostanie wykonana praca? Developerzy
Praca niezbędna do wytworzenia Incrementu, realizowanie zadań, kryteria akceptacji
Sprint Poker – developerzy dostają karty, rzucają wartości, opisujące właściwą pracochłonność zadania
LEAD TIME – czas, który upłynął od momentu założenia przez klienta u sprzedawcy, do chwili
dostarczenia towaru do kupującego
CYCLE TIME – proces usuwania błędu, przeanalizowanie problemy, development, testy, wdrożenie
CAPACITY – zdolność
THROUGHPUT - pzepustowość
Historyki są dzielone na zadania. Dla każdego zadania jest określona pracochłonność. Zadanie nie może
trwać dłużej niż 8 godzin (jeżeli jest więcej – trzeba rozbić na mniejsze zadania)

Po tym, jak zespół wybierze historyjki – ponownie ich oszacywuje (ich złożonność)”
- po to, by nie popełnił błędów
- jeżeli jest mniejsza – dorzuca historyjki, jeżeli mniejsza – wyrzuca historyjki.

Podział zadań: dla każdej historyjki są zdeklarowane zadania, są wyświetlane: każdy developer zgłasza
się do zadania, które chce robić. Jeżeli nikt się ni zgłasza do zadania ->Serum Master musi doprowadzić
do tego, by była to załatwione. ALE Scrum Master nie może nazwać konkretnego developera.
Właściciel produktu nie może później dodać historyjki zespółowi.

Codzienny Scrum

TimeBox – 15 min (odbywa się codziennie)

Układ Sprintu:
 Co zrobiłem wczoraj, co pomogło Zespołowi Developerskiemu osiągnięciu celu Sprintu
 Co zrobię dziś, zby pomóc Zespołowi Developerskiemu osiągnąć Cel Sprintu
 Czy jest coś co utrudnia mi lub Zespołowi Developerskiemu osiągnięcie Cel SprintU
Nie ma stałego schematu wypowiadania się (albo jest wcześniej ustalony
ScrumMaster ma atrybut mówcy (ro przekazuje DeveloperzowiP
Idea codziennego SCRUM – ustalić te zadania, powiedzieć, że coś np. nie udało się zrobić, poprosić o
pomoc, by zminimalizować ryzyko)
Rola SCRUM –mastera – analizowanie tych odpowiedzi i zapisywanie problemów.
W codziennym SCRUMie często posługuje się
Tablica Canban
Sories Not started In progress Dane
(+restowanie)
Story#1 TaskA, TaskB, TaskC
Story#2 TaskA TaskC TaskB
 Story#3 TaskB, TaskD TaskA, TaskC

Wykres spalania SPRINTu (Sprint Burn-Down Chart) – może być w punktach użytkownika, ale częściej w
roboczogodzinach

Ideał effort Hours

Effort remaining
Gdzie -- jest prawie pozioma -- - zespół prawdopodobnie nie realizuje zadań (nie spalają roboczogodzin)
Sprint dwutygodniowy ma 14 dni, ale roboczych 10.
Podsumowanie Codzienny Scrum
- tworzy plan na dzień
- organizowanie i przeprowadzanie przez i dla zespołu Developerskiego

 Możliwość do inspekcji i adaptacji

 SCRUM Master zapewnia, że się odbywa
 Nie jest to spotkanie raportujące dla SM, PO
Niektóry Zespoły pod czas Daily Scrum aktuakizują Sprint Backlog, Burndown – to raczej jest praktyką
(bo 15 min to mało) zazwyczaj to później robi SCRUM Master.
Cały zespół prowadzi rekrutację członków do zespołu
Przegląd Sprintu (Sprint Reciew)
PRZEGLĄD SPRINTU 2-4H. TYLKO TO CO SPEŁNIŁO KRYTERIA DEFINICJI UKOŃCZENIA
 SCCRUM Master uczestniczy w spotkaniu
 SCRUM Master organizuje spotkanie
 Product Owner akceptuje lub odrzuca elementy Backlogu
 Product Owner nie powinien być niczym zaskoczony
 Nie powinien to być pierwszy raz kiedy Product Owner widzi funkcjonalność
 Okazja dostarczyć informację zwrotną Zespołowi
 Przedstawienie nowej wersji zainteresowanym stronom
Zespół prezentuje , konfrontuje z użytkownikiem, klientem, właścicielem produktu ->ktoś z nich bada,
klika, spawdza jak to działa.
Rola developerów – zbierają informacje zwrotne
Inkrement w momencie Przeglądu Sprintu jest inspektywny
To wszystko ładuje w Rejestrze Sprintu; później w Rejestrze Produktu.
Dług techniczny – sytuacja, w której bardzo dużo funkcji w każdym Sprincie działa nieprawidłowo (nie
powinno być za dużo tych błędów)
Retrospektywa
Cel retrospektywy – analiza prazy zespołu, poprawienie działań członków.
 Zorganizowana przez Scrum Mastera
 Uczestniczy cały zespół SCRUM
 Zespół podsumowuje jak poszedłostatni Sprint
 Zespół wybiera rzeczy do zrealizowania/usprawnienia na najbliższy Sprint
 Co można zmienić, aby w przyszłości było lepiej, doskonalenie
Dlaczego warto sięgnąć po Szablon Retrospektywy:
1) Przygotujcie scenę (Set the stage) – po pierwsze, ustalcie na czym skupicie się na tej
Retrospektywie. Upewnijcie się, że macie właściwe osoby i wszystko, co jest potrzebne do
przeprowadzenia spotkania
2) Zbierzcie dane (Gather data) – zanim przejdziecie do wniosków, przyglądnijcie się temu, co się
wydarzyło. Oczywiście dane, które was interesują zależą od celu ustalonego krok wcześniej.
Możecie na przykłąd popatrzeć na poprzedni Sprint, albo ostatnie Wydanie, zebrać metryki o
ilości błędólub stabilności waszych środowisk; narysować obecny proces; ustalić kto i w jaki
sposób podejmuje decyzje
3) Wygenerujcie spostrzeżenia (Generate insight) – jeżeli macie już dane z poprzedniego punktu to
na ich podstawie wygenerujcie spostrzeżenia. Jakie akcje możemy podjąć? Co chcemy zmienić?
Co chcemy zostawić? Co zacząć, co przestać, a co kontynuować?
4) Zdecydujcie co robić (Decide what to do) – trzeci krok powinniście zakończyć z dużą ilością
pomysłów. Przed wami krótki Sprint, między tydzień a miesiąc pracy. Dlatego stwórzcie
realistyczny plan i nie próbujcie naprawiać wszystkiego na raz. Wybierzcie 1-2 zmiany, które
chcecie wprowadzić.
5) Zamknijcie spotkanie (Close) – to krótkie podsumowanie spotkania, w trakcie którego możecie
ocenić jak przebiegło i jak możecie je zrobić lepiej następnym razem.
METODY SZACOWANIA:
 Planning Poker – złożoność historyjek w punktach użytkownika, planowanie wydanie
 Sprint Poker – planowanie sprintu, pracochłonność
 T-Shirt sizing – złożoność historyjek (np.2x większa, mniejsza) S, M, L itp.
  Three point method – trzy wartości dla każdej historyki (optimistic 3, pessimistic 7, most likely 6)
 Relative mass evaluation – oś z przedziałami punktów użytkownika, przyporządkowanie
złożoności historyjek

Odpowiedzialność SCRUM Masters:

 Zapewnienie, że CRUM jest rozumiany i stosowany
 Pomoc w spotkaniach Scrumowych jeśli jest potrzebna lub wymagana
 Przybliżanie teorii SCRUM, praktyk i zasad
 Wspierający lider zespołu
 Powodowanie zmian, które poprawia jakość i produktywność
 Wcielanie agility do organizacji
Właściciel produktu – członek zespołu developerskiego, może przerwać (jeżli uzna że cel Sprintu nie
zostanie zorganizowany) Sprint, jest pomostem pomiędzy klientem a zespołem
Developerzy – członkowie zespołu, decydują, co jak kiedy będzie zrobione, realizują badania

Artefakt 3: Inkrement (Przyrost) DONE

 Posiadanie gotowej definicji ukończenia (Definition of Done DoD) informuje kiedy jest gotowe do
wdrożenie
 DoD optymalizuje utrzymanie, równe tempo prac
  Wracaj do DoD co każdy Sprint
 „Ukończone” jest dla całego produktu nie tylko dla Przyrostu Zespołu Scrumowego
Każdy przyrost produktu musi być:
 Ukończony (Done) bez żadnej pozostałej pracy
 Potencjalnie gotowy do użycia przez klienta
 Transparentny – każda osoba widząca Przyrost ma takie samo rozumienie tego co jest
zrealizowane
Definicja „Ukończenia”:
 Pozytywne testy wydajnościowe, unit testy, zasięg testów powyżej 85%
 Spełnia standarsy kodowania
 Refactoring
 User Acceptance testing
 Testy integracyjne
 Niezbędną dokumentację (just enough)
 Regression testung
 Code Review