Zarządzanie Projektami IT

Kompetencje Cyfrowe

marzec 2021
„…wewnątrz organizacji tylko trzy zjawiska występują
naturalnie: spory, chaos i nieefektywność
…cała reszta wymaga zarządzania”

Peter F. Drucker
Cechy dobrego zarządzania projektami
z siedmiu cech dobrego zarządzania wg Petera F. Druckera

• Dotyczy przede wszystkim ludzi

• Wymaga prostych i zrozumiałych celów
• Wymaga komunikowania się
• Musi być zorientowane na najważniejszy rezultat, jakim jest zadowolony klient
Definicja Projektu
Jednorazowe przedsięwzięcie podejmowane
w celu wytworzenia unikalnego produktu
lub dostarczenia unikalnej usługi (wg PMI)
 Cechy projektu
• Ustalony z góry początek i koniec
• Zorganizowany, złożony ciąg działań
• Niepowtarzalny charakter
• Zde niowane zasoby
• Etapowa realizacja
fi
Przykłady projektów, terminologia
• Projekt budowy autostrady
• Projekt wdrożenia nowego systemu informatycznego w przedsiębiorstwie
• Projekt stworzenia aplikacji mobilnej do wypożyczania hulajnóg elektrycznych
• Czy wyjazd na wakacje to projekt?
• Uwaga - “Piszemy projekt unijny” -> skrót myślowy, mamy na myśli “piszemy
wniosek o do nansowanie przedsięwzięcia/projektu”
• Na marginesie:
• Słowo “projekt” jest dosyć nieszczęśliwą kalką z jęz. angielskiego
• Polskie słowo “projekt” oznacza zarówno projekt w sensie “dokument” (ang. “design”), np.
projekt domu od architekta, jak i projekt w sensie “przedsięwzięcie” (ang. “project”), np.
projekt przeprowadzenia budowy tego domu.
fi
Proces
Nie wszystko jest projektem

Proces - zbiór działań, które przetwarzają dany wkład w wynik, stanowiący

wartość dla Klienta
PROCES

DOSTAWCA WKŁAD WYNIK KLIENT

DOSTAWCA: zapewnia wkład do procesu

8

WKŁAD: materiały i zasoby potrzebne do realizacji procesu

WYNIK: produkty lub usługi, będące rezultatem procesu
KLIENT: odbiorca wyników procesu
Projekt a proces
Cechy projektu Cechy procesu
ukierunkowanie na zmiany stabilność
niepowtarzalność (unikatowość) rutynowość, powtarzalność
wysokie ryzyko niskie ryzyko

wykonywane na zlecenie wykonywane stale

kierownictwo zaangażowane kierownictwo zaangażowane

nieustannie sporadycznie
prawdopodobieństwo sporów stabilne relacje międzyludzkie
i kon iktów
fl
Przykłady procesów

• Zamykanie księgowań w przedsiębiorstwie - cyklicznie co miesiąc

• Naliczanie wynagrodzeń - cyklicznie co miesiąc
• Comiesięczny przegląd portfela projektów
• Produkcja przemysłowa - linia produkcyjna
• Obsługa reklamacji
• …
Podstawowe wymiary projektu
Trójkąt projektowy
Zakres, czas, budżet
Czas

Oczekiwania Budżet

Zakres
 Czas

Trójkąt projektowy
Interpretacja #1
Oczekiwania Budżet

• Nasza rma wykonuje projekty:

dobre, szybkie, tanie. Zakres

• Można wybrać maksymalnie 2:

• Dobre i szybkie -> nie są tanie
• Szybkie i tanie -> nie są dobre
• Dobre i tanie -> nie są szybkie (są w ogóle najmniej możliwe…)
fi
 Czas

Trójkąt projektowy
Interpretacja #2
Oczekiwania Budżet

• Istnieją 3 rodzaje projektów:

• Stały zakres i budżet Zakres

• możemy sterować wyłącznie czasem, projekt “klasyczny”. Zakres określony precyzyjnie.

• Stały czas i budżet
• możemy sterować wyłącznie zakresem, projekt “agile”. Zakres określony mniej-więcej
• Stały czas i zakres
• “budżet nie gra roli”, projekty realizowane w dramatycznych okolicznościach np.
opanowanie wycieku ropy po awarii platformy wiertniczej Deepwater Horizon,
restrukturyzacja kopalń chroniąca je przed bankructwem za 3 tygodnie, misja w lmie
Armageddon, itp.

fi
Środowisko realizacji projektów
Projekt w organizacji
• Projekt wymaga powołania dedykowanej organizacji projektowej do jego
przeprowadzenia

• Z drugiej strony, projekt jest realizowany w już istniejącej organizacji

• Organizacja może być gotowa do realizacji projektów w różnym stopniu:
• przeszkadza projektom -> struktura wydziałowa/pionowa (silosy),
• nie pomaga projektom -> struktury macierzowe: słaba i zbalansowana,
• wspiera projekty -> struktura macierzowa silna,
• jest zorientowana na projekty -> organizacja stricte projektowa.
Struktura wydziałowa
Struktura macierzowa słaba
Struktura macierzowa zbalansowana
Struktura macierzowa silna
Struktura projektowa
Typy projektów
Typy projektów
Różne projekty dla różnych organizacji

• W organizacjach, których biznesem jest realizacja procesów (np. sprzedaż produktów lub usług):
• Projekty związane są głównie ze zmianą procesów w organizacji lub z pracami R&D i rozwojem własnych
produktów i usług

• Często realizacja projektów jest outsourcowana, chociaż duże organizacje mają zwykle własne działy projektowe
lub R&D

• Firmy produkcyjne, banki, rmy ubezpieczeniowe, szpitale itp.

• W organizacjach, których biznesem jest realizacja projektów:
• Realizacja projektów jest głównym celem istnienia organizacji, zatem zwykle projekty nie są outsourcowane
• Głównie projekty dla klientów zewnętrznych
• Projekty wewnętrzne są zwykle mniejsze i dotyczą samej organizacji jako takiej
• Agencje interaktywne, produkcja oprogramowania na zlecenie (software house), studia lmowe, rmy eventowe
fi
fi
fi
Fazy projektu
 Fazy projektu
Potrzeba
zmiany /
Presales

De nicja
i organizacja
Projektu

Realizacja
Projektu

Wdrożenie
Projektu

Zamknięcie
Projektu

Ocena
Projektu
fi
Fazy projektu
Potrzeba zmiany / Presales

• W organizacjach, których biznesem jest realizacja procesów, źródłem projektów

jest potrzeba zmiany:

• Wewnętrzna: zidenty kowany błąd lub problem w organizacji procesu lub w

produkcie, niesatysfakcjonujące wyniki rmy/działu – oczekiwania zarządu,
rady nadzorczej, właścicieli

• Zewnętrzna: presja konkurencji, oczekiwania klienta, zmiany w otoczeniu

prawnym - przepisach zewnętrznych, postęp technologiczny - innowacje

• W organizacjach, których biznesem jest realizacja projektów, źródłem projektów

jest otrzymane zapytanie ofertowe lub “pitch” do potencjalnego klienta
Potrzeba
zmiany /
Presales
fi
fi
 Potrzeba zmiany / Presales
Sponsor

• Sponsor – menedżer wyższego szczebla, który:

• jest osobiście zainteresowany efektami wdrożenia zmiany
• ma wizję
• de niuje potrzeby/priorytety rmy
• dysponuje zasobami (ludzie, budżet) oraz
• podejmuje kluczowe decyzje w Projekcie
• zatwierdza najważniejsze etapy i wyniki prac
• monitoruje postęp prac w Projekcie
Potrzeba
• wspiera Kierownika Projektu i Zespół Projektowy. zmiany /
Presales
fi
fi
 Definicja i organizacja projektu
Ramy projektu

• Wstępna de nicja projektu - jego ram, zakresu, założeń dla realizacji i budżetu, celu
biznesowego, spodziewanych efektów (celów operacyjnych) i oczekiwanej daty wdrożenia
jest przygotowywana przez Sponsora Projektu i stanowi punkt wejścia do opracowania Karty
Projektu i Planu Projektu przez Kierownika Projektu

• Wstępne analizy i studia wykonalności (Feasibility Study),

• Podjęcie decyzji zrobić/kupić, zapytania do rynku (RFI, RFQ, RFP)
• Określenie optymalnej metodyki prowadzenia prac projektowych
• Cel i zakres opisany precyzyjnie i zasadniczo niezmienny -> metodyka klasyczna (np. PMI)
• Cel i zakres zde niowanie ogólnie, jednym z celów projektu jest określenie, De nicja
co należy zrobić, i to może ulegać zmianom na bieżąco -> metodyka Agile i organizacja
Projektu
fi
fi
fi
 Definicja i organizacja projektu
Karta Projektu

• Karta Projektu (Project Charter)

• dokument będący rodzajem umowy pomiędzy zespołem projektowym a
klientem/sponsorem

• określa zasadniczy kształt projektu

• jest sporządzana przez Kierownika Projektu i przedkładana do akceptacji
klientowi lub sponsorowi.

De nicja
i organizacja
Projektu
fi
 Definicja i organizacja projektu
Plan projektu

• Plan Projektu (Project Plan)

• P&L i budżet projektu
• Harmonogram z kamieniami milowymi
• Skład zespołu projektowego i jego organizacja
• Plan komunikacji
• często wiele więcej, w zależności od organizacji: plan zarządzania ryzykiem,
plan zapewnienia jakości… De nicja
i organizacja
Projektu
fi
 Definicja i organizacja projektu
Zakres projektu, czyli co jest do zrobienia

• Zde niowanie zakresu projektu

• Struktura Podziału Prac (Work Breakdown Structure, WBS)
• Dla projektów realizowanych wg metodyki klasycznej, całość prac
projektowych jest zde niowana w WBS

• Dla projektów Agile, związanych przede wszystkim z wytwarzaniem

oprogramowania, WBS zwykle obejmuje czynności związane z administracją
oraz środowiskiem projektu (wdrożenia, szkolenia, migracje danych, integracje,
koordynację podwykonawców). Obszar zakresu projektu związany
bezpośrednio z wytwarzaniem oprogramowania jest de niowany w tzw. De nicja
Product Backlogu. i organizacja
Projektu
fi
fi
fi
fi
 Warsztat - smartsheet.com
De niowanie zakresu projektu
fi
Realizacja projektu
Kick-o

• Kick-o Meeting czyli rozpoczęcie projektu

• Spotkanie wszystkich udziałowców projektu (stakeholders): sponsor / klient,
kierownik projektu, zespół projektowy, kluczowi dostawcy

• Prezentacja celów i założeń projektu

• Omówienie harmonogramu i zakresu prac
• Omówienie narzędzi, zasad i organizacji pracy w projekcie, w tym komunikacji
• Nadanie odpowiedniego autorytetu kierownikowi projektu
przez sponsora Realizacja
Projektu
ff
f
Realizacja projektu
Komunikacja
• Regularne spotkania całego zespołu projektowego
• Ustalona pora i agenda, notatka ze spotkania w dostępnym dla każdego miejscu
• Action Items - zadania do wykonania po spotkaniu
• Nadzór nad realizacją zadań (status realizacji), identy kacja problemów
• Regularne spotkania projektowe nie służą rozwiązywaniu problemów!
• Regularne spotkania kierownika projektu ze sponsorem / klientem
• W projektach Agile ponadto:
• Codzienne, krótkie spotkanie zespołu projektowego - Daily Scrum (Co zrobiliśmy
wczoraj, co robimy dzisiaj, co zamierzamy robić jutro)

• Spotkania poświęcone na cykliczne planowanie i prezentację osiągniętych rezultatów Realizacja

Projektu
• Uwaga - nieskuteczna komunikacja jest przyczyną 90% porażek przy realizacji projektów!
fi
Realizacja projektu
Lista TODO
• Zakres projektu powinien zostać doprecyzowany w formie listy zadań do realizacji (Lista
TODO)

• Każde zadanie powinno zostać precyzyjnie opisane, w szczególności oczekiwane

produkty zadań

• Każde zadanie powinno mieć określone ramy czasowe (deadline)

• Każde zadanie powinno mieć przypisanego konkretnego członka zespołu projektowego,
odpowiedzialnego za jego realizację

• Lista TODO jest tworzona przez kierownika projektu i jest jego podstawowym narzedziem
zarzadzania zadaniami

• Podstawowy błąd - ustne ustalanie zadań do wykonania, nawet trywialnych!

Realizacja
Projektu
Warsztat - basecamp.com
Zarządzanie realizacją zadań i komunikacją w projekcie
Realizacja projektu
Zarządzanie ryzykiem

• Ryzyko - niepewne zdarzenie w przyszłości:

• Zagrożenie - ryzyko negatywne
• Okazja - ryzyko pozytywne
• Wstępna identy kacja i ocena ryzyk - wpisanie do Karty Projektu
• Regularny przegląd ryzyka - identy kacja i ocena nowych i istniejących ryzyk
• Ocena ryzyka jest trudna, warto stosować proste i intuicyjne miary
• Popularny sposób: ocena w 2 kategoriach:
• Prawdopodobieństwo wystąpienia: niskie, wysokie
• Wpływ wystąpienia na cele projektu: niski, wysoki Realizacja
Projektu
fi
fi
 Realizacja projektu
Zarządzanie ryzykiem
Strategia zarządzania ryzykiem powinna być uzależniona od prawdopodobieństwa
jego wystąpienia i wpływu tego wystąpienia na cele projektu
Prawdopodobieństwo zagrożenia

Wysokie Niskie

Unikanie (zmiana w projekcie)

Wpływ zagrożenia

Transfer ryzyka (Ubezpieczenie od skutków)

Wysoki
Redukcja (prawdopodobieństwa i/lub
Redukcja (tylko wpływu)
wpływu)

Plan awaryjny (raczej się przyda) Współdzielenie

Niski
Redukcja (tylko prawdopodobieństwa) Akceptacja Realizacja
Projektu
 Realizacja projektu
Zarządzanie ryzykiem
Strategia zarządzania ryzykiem powinna być uzależniona od prawdopodobieństwa
jego wystąpienia i wpływu tego wystąpienia na cele projektu
Prawdopodobieństwo okazji

Wysokie Niskie
Wpływ okazji

Wysoki Wykorzystanie Wzmacnianie (prawdopodobieństwa)

Współdzielenie
Niski Wzmacnianie (wpływu)
Odrzucenie Realizacja
Projektu
Warsztat - Zarządzanie ryzykiem
https://docs.google.com/spreadsheets/d/1h9eG6-GWuGuXoMnvA0t3DxBsO3vTzIvPHpX1qrswkiU/edit?usp=sharing
Realizacja projektu
Zarządzanie czasem
• Harmonogram jest podstawowym narzędziem do zarządzania czasem w projekcie
• Harmonogram to lista zadań (elementów WBS) ułożona w czasie, z uwzględnieniem zależności
pomiędzy zadaniami

• Finish-to-Start (FS) -> poprzednie zadanie musi się skończyć, żeby mogło rozpocząć się
kolejne zadanie

• Start-to-Finish (SF) -> kolejne zadanie musi się zacząć, żeby poprzednie mogło się skończyć
(żołnierz może zejść z warty dopiero, kiedy wartę rozpocznie następny żołnierz)

• Start-to-Start (SS) -> kolejne zadanie może się rozpocząć, kiedy tylko rozpocznie się
poprzednie zadanie (oba zadania biegną równolegle)

• Finish-to-Finish (FF) -> kolejne zadanie może się zakończyć dopiero wtedy, kiedy skończy
się poprzednie zadanie (np. usługa wsparcia testów akceptacyjnych może się
zakończyć dopiero wtedy, kiedy zakończą się testy akceptacyjne) Realizacja
Projektu
Realizacja projektu
Zarządzanie czasem
• Ścieżka Krytyczna
• Zazwyczaj wiele prac w projekcie można prowadzić równolegle, są
jednakże takie zadania, które bądź to ze względu na logiczne połączenia
bądź też ze względu na ograniczenia zasobów, muszą być realizowane
jedno po drugim.

• W każdym projekcie jest przynajmniej jeden łańcuch powiązanych zadań,

mający taką cechę, że wydłużenie dowolnego zadania z tego łańcucha o
nawet jeden dzień, spowoduje wydłużenie projektu przynajmniej o jeden
dzień.

• Taki łańcuch zadań nazywamy ścieżką krytyczną. Realizacja

Projektu
Realizacja projektu
Zarządzanie czasem
• Kamienie milowe
• Kamienie milowe to punkty podejmowania decyzji co dalej (np. na
zakończenie etapów)

• Nieosiągnięcie kamieni milowych jest ryzykiem, które powinno być aktywnie

zarządzane, gdyż może spowodować przerwanie projektu i jego porażkę

• Kamienie milowe w harmonogramie oznaczamy tradycyjnie jako zadania

o czasie trwania 0 dni

Realizacja
Projektu
Warsztat - smartsheet.com
Harmonogram - tworzenie i zarządzanie
Fazy projektu
Wdrożenie projektu

• Po realizacji projektu następuje wdrożenie jego rezultatów, pod warunkiem:

• Osiągnięcia kamieni milowych
• Realizacji zakładanych produktów projektu
• Biznesowej zasadności przeprowadzenia wdrożenia
• Wdrożenie projektu rozpoczyna fazę, podczas której wyniki projektu stają się
widoczne poza zespołem projektowym. Często wdrożenie wyników projektu
oznacza wdrożenie zmiany biznesowej.
Wdrożenie
Projektu
Fazy projektu
Wdrożenie projektu
Efektywność wzrasta

Poprzednia sytuacja
Efektywność

Efektywność powraca
do poprzedniego stanu
Zmiana

Wdrożenie
Czas Projektu
Krzywa efektywności
Fazy projektu
Wdrożenie projektu

• Przyczyny powstania “dołka kosztów”

• wydłużenie czasu potrzebnego na realizację zadania
w związku ze zmianą

• błędy i problemy
• koszt doskonalenia kwali kacji (nauki)
• koszt przeprowadzenia zmiany i wdrożenia projektu zmiany
• opór ludzi przeciwko zmianom
• uleganie niekorzystnym naciskom wewnętrznym i zewnętrznym Wdrożenie
Projektu
fi
Fazy projektu
Wdrożenie projektu
Co mogą mówić pracownicy w procesie zmian?

To wszystko już było, Kolejny

tylko teraz inaczej się beznadziejny
Za chwilę rozwalą nazywa… pomysł tych na
firmę… górze – nudzą
się, to
wymyślają..
Nikt się z nami nie liczy…

O wszystkim
dowiadujemy
się po fakcie…
Nasza firma jest
specyficzna,
te rozwiązania
do nas nie pasują…
Ci „nowi” teraz
muszą się Wdrożenie
czymś wykazać… Projektu
Fazy projektu
Zamknięcie projektu

• Uporządkowanie dokumentacji projektowej, na którą zwykle nie ma czasu w

ostatnich tygodniach projektu, kiedy jest najwięcej pracy z dotrzymaniem
terminu

• Zdobycie wszystkich odbiorów, podpisanie protokołów

• Rozliczenie nansowe projektu
• Rozliczenie podwykonawców
• Uzyskanie referencji
• Świętowanie - szczególnie, gdy zamiast satysfakcji jest tylko ulga… Zamknięcie
Projektu
fi
Fazy projektu
Ocena projektu

• Ocena realizacji projektu - doskonalenie organizacji

• Kolejny projekt będzie lepszy
• Nie popełnimy tych samych błędów
• Lepiej wykorzystamy szanse
• Ocena wyników/celów projektu
• Czy było warto?
Ocena
Projektu
Agile - zwinne zarządzanie
projektami
Agile
Manifesto

Odkrywamy nowe metody programowania dzięki praktyce w programowaniu

i wspieraniu w nim innych.
W wyniku naszej pracy, zaczęliśmy bardziej cenić:

Ludzi i interakcje od procesów i narzędzi

Działające oprogramowanie od szczegółowej dokumentacji
Współpracę z klientem od negocjacji umów
Reagowanie na zmiany od realizacji założonego planu.

Oznacza to, że elementy wypisane po prawej są wartościowe,

ale większą wartość mają dla nas te, które wypisano po lewej.
•
Scrum
Wprowadzenie

Scrum to uproszczone ramy postępowania, które pomagają poszczególnym osobom,

zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie
złożonych problemów.

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 sprawdzają efekty i dostosowują swoje działania na
potrzeby kolejnego Sprintu.
4. Scrum Master przyczynia się do tworzenia środowiska, w którym taki proces jest możliwy
5. Powtórz
Scrum
Teoria

Scrum wykorzystuje iteracyjne, przyrostowe podejście w celu zwiększania

przewidywalności oraz kontrolowania ryzyka.

Scrum polega na pracy grup osób wspólnie posiadających wszystkie umiejętności oraz
specjalistyczną wiedzę potrzebne do wykonania pracy oraz dzielą się tymi
umiejętnościami bądź nabywają je w miarę potrzeby.

W Scrumie odbywają się cztery formalne wydarzenia umożliwiające inspekcję i

adaptację w ramach obejmującego je wszystkie wydarzenia, jakim jest Sprint.
Scrum
W pigułce

Artefakty Filary Role Wydarzenia

Product Backlog Przejrzystość Product Owner Sprint Planning

Sprint Backlog Inspekcja Scrum Master Sprint Review

Increment Adaptacja Developerzy Retrospective

Daily Scrum
Scrum
Artefakty

• Product Backlog - to ewoluująca, uporządkowana lista tego, co jest konieczne do ulepszenia

produktu. To jedyne źródło pracy podejmowanej przez Scrum Team.
• Sprint Backlog - to plan przygotowany przez Developerów dla nich samych. Jest dobrze widoczną, na
bieżąco aktualizowaną reprezentacją pracy, którą Developerzy planują wykonać w trakcie Sprintu, aby
zrealizować Cel Sprintu.
• Increment - to konkretny krok w kierunku osiągnięcia Celu Produktu. Każdy kolejny Increment
rozbudowuje wszystkie wcześniejsze, jest też skrupulatnie wery kowany po to, aby zapewnić, że
wszystkie Incrementy są do siebie dopasowane.

Każdy artefakt wiąże się ze zobowiązaniem, które zapewnia dostępność informacji poprawiających
przejrzystość i skupienie, w odniesieniu do których można mierzyć postępy:
• Dla Product Backlogu to Cel Produktu.
• Dla Sprint Backlogu to Cel Sprintu.
• Dla Incrementu to De nicja Ukończenia.
fi
fi
Scrum
Filary

• Przejrzystość - transparentność procesu i pracy jest konieczna dla osób je wykonujących.

Niedostateczna przejrzystość artefaktów może prowadzić do decyzji, których wynikiem jest
zmniejszona wartość bądź zwiększone ryzyko.
Przejrzystość umożliwia inspekcję. Inspekcja bez przejrzystości prowadzi do błędów i strat.
• Inspekcja - artefakty Scruma oraz postępy w dążeniu do uzgodnionych celów muszą być poddawane
częstej i rzetelnej inspekcji, aby możliwe było wykrycie potencjalnie niepożądanych odstępstw lub
problemów.
Inspekcja umożliwia adaptację. Inspekcja bez adaptacji jest uznawana za bezcelową. Celem wydarzeń w
Scrumie jest wywoływanie zmian.
• Adaptacja - jeśli jakikolwiek aspekt procesu wykracza poza dopuszczalne limity lub jeśli uzyskany
produkt jest niemożliwy do zaakceptowania, stosowany proces lub wytwarzane materiały należy
odpowiednio skorygować. Zmian tych należy dokonać jak najszybciej, aby zminimalizować dalsze
odstępstwa.
Scrum
Role

• Scrum Team - w jego skład 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. Jest interdyscyplinarny i tym odróżnia się od standardowego zespołu.

• Developerzy - to osoby zobowiązane do wytworzenia każdego aspektu użytecznego

Incrementu w każdym Sprincie.

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

• 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 Teamu bądź poszczególnych osób.
Scrum
Wydarzenia - Sprint

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ędnieniem 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 Sprintu;

● jakość nie spada;

● Product Backlog jest w razie potrzeby uszczegóławiany;

● zakres pracy może być doprecyzowywany lub renegocjowany z Product Ownerem wraz z rosnącym
zrozumieniem.
Scrum
Wydarzenia - Sprint Planning

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 inne osoby w charakterze doradców.

Sprint Planning to wydarzenie, podczas którego uczestnicy zajmują się następującymi

tematami:

• Dlaczego ten Sprint ma wartość?

• Co może zostać Ukończone w tym Sprincie?
• W jaki sposób zostanie wykonana praca?
Scrum
Wydarzenia - Daily

Celem Daily Scrum jest sprawdzenie postępów w dążeniu do osiągnięcia Celu Sprintu oraz w
razie konieczności adaptacja 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 o tej samej porze i w tym samym miejscu w każdy dzień roboczy w
trakcie trwania Sprintu. Jeśli Product Owner lub Scrum Master wykonują pracę związaną z
elementami Sprint Backlogu, uczestniczą w spotkaniu jako Developerzy.

Product Owner i Scrum Master nie są managerami podejmującymi decyzje nad czym i w jakiej
kolejności pracują Developerzy podczas Sprintu. Scrum to nie micromanagement!
Developerzy mogą zdecydować się na dowolną strukturę oraz techniki, o ile tylko Daily Scrum
dotyczy postępów w realizacji Celu Sprintu, a efektem tego wydarzenia jest możliwy do
wykonania plan na nadchodzący dzień pracy. Pozwala to osiągnąć większe skupienie i poprawia
umiejętność samozarządzania.
Scrum
Wydarzenia - Sprint Review

Celem Sprint Review jest inspekcja efektów pracy wykonanej w Sprincie oraz wskazanie
przyszłych zmian.

Scrum Team prezentuje rezultaty swojej pracy kluczowym interesariuszom, omawiane są także
postępy w dążeniu do Celu Produktu.

Podczas tego wydarzenia Scrum Team wraz z interesariuszami oceniają to, co zostało
zrealizowane podczas Sprintu oraz zmiany, jakie zaszły w ich otoczeniu. Na podstawie tych
informacji uczestnicy wspólnie ustalają, co należy robić w następnej kolejności. Product
Backlog może także zostać zmody kowany, aby uwzględnić nowe możliwości.

Sprint Review to spotkanie robocze, a Scrum Team powinien unikać ograniczania go jedynie do
prezentacji.

Sprint Review to nie jest ocena indywidualnej produktywności któregokolwiek z developerów.

fi
Scrum
Wydarzenia - Retrospective

Celem Sprint Retrospective jest planowanie sposobów na podniesienie jakości i

efektywności.

Scrum Team sprawdza, jak przebiegał ostatni Sprint w odniesieniu do osób, interakcji,
procesów, narzędzi oraz De nicji Ukończenia. Sprawdzane elementy często różnią się w
zależności od specy ki pracy. Ujawnia się założenia, które doprowadziły zespół do
błędnych wniosków, bada się także ich pierwotną przyczynę.

Scrum Team omawia to, co poszło dobrze w trakcie Sprintu, jakie problemy się pojawiły,
a także w jaki sposób te problemy zostały (lub nie zostały) rozwiązane.

Scrum Team określa zmiany najbardziej pożądane pod kątem poprawy swojej
efektywności. Najbardziej znaczące usprawnienia wprowadza się jak najszybciej. Można
je wręcz włączyć do Sprint Backlogu na kolejny Sprint.
fi
fi
Scrum
Proces
Warsztat - atlassian.com
Zarządzanie projektem zwinnym w JIRA
Ćwiczenie: Nowy projekt
• Tworzymy nowy projekt: Projects > Create Project
• Wybieramy szablon nowej generacji i tworzymy projekt typu Scrum
Ćwiczenie: Workflow
• Każde zadanie może przechodzić przez wiele statusów, w zależności od
przyjętego przez Scrum Team sposobu realizacji zadań. Można dodać status
np. Testowanie lub Oczekuje na Wery kację.

fi
 Ćwiczenie: Tworzenie Product Backlogu
• Pracujemy albo nad projektem szkoleniowym z poprzedniego tygodnia, albo wyobrażamy sobie, że jesteśmy twórcami
Net ix, Spotify, Instagram…

• Tworzenie Product Backlogu polega na zbudowaniu listy wymagań, które są niezbędne do wykonania projektu (np.
stworzenia Net ixa)

• Wchodzimy w rolę Product Ownera

• Identy kacja wymagań: brainstorming. (Około 30 wymagań powinno wystarczyć do ćwiczenia)
• Myślimy o wymaganiach funkcjonalnych: co rezultat naszego projektu (tzn. oprogramowanie) ma robić? Jakie funkcje
realizować? Jakie elementy interfejsu użytkownika trzeba wykonać? Jakie ekrany, okna dialogowe ma aplikacja? Czy
jest ekran logowania, zakładanie konta, logowanie przez Google itp.

• Myślimy o wymaganiach niefunkcjonalnych: zapewnienie bezpieczeństwa aplikacji, możliwość pobrania ze sklepu z

aplikacjami mobilnymi, zgodność z przeglądarkami webowymi itp.

• Wymagania opisujemy jako User Stories (Historyjki Użytkownika)

• Jako <użytkownik> chcę <potrzeba>, żeby <cel do osiągnięcia>.
fl
fi
fl
Ćwiczenie: Priorytetyzacja Product Backlogu
• Wchodzimy w rolę Product Ownera
• Product Backlog układamy wg priorytetów zadań
• Pamiętajmy, że im niżej dane zadanie w backlogu, tym później zostanie potencjalnie zrobione i tym większe
prawdopodobieństwo, że zadanie może nie zostać zrealizowane nigdy

• Priorytetyzację najlepiej przeprowadzać metodą porównywania wymagań parami

• Wyobrażamy sobie, jaki będzie stan naszego oprogramowania (Increment) po zrealizowaniu określonej
liczby zadań ze szczytu backlogu. Czy taki Increment będzie mieć wartość biznesową?Czy będzie możliwe
jego zaprezentowanie?

• Koncepcje:
• Minimum Viable Product (MVP)
• Potentially Shippable Increment
Ćwiczenie: Planowanie Sprintu
• Do celów ćwiczenia - 1 osoba wchodzi w rolę Product Ownera, pozostałe osoby - w rolę Developerów
• Product Owner przedstawia Developerom po kolei zadania do realizacji zaczynając od najważniejszych i przeciąga je
do kolejnego sprintu

• Developerzy zadają pytania uszczegóławiające i wspólnie decydują, kto będzie realizował konkretne zadanie.
Następuje przypisanie zadań do osób w JIRA (uwaga - wymaga to założenia kont użytkowników)

• Na tym etapie można tworzyć pod-zadania wewnątrz historyjek użytkownika i dodatkowe zadania (Task)
niezbędne do realizacji historyjek użytkownika

• Po wyczerpaniu ilości pracy możliwej do realizacji w ramach Sprintu, zakres sprintu zostaje ustalony. Scrum Team
decyduje, czy kolejna historyjka “jeszcze się zmieści”

• Jeśli wg Scrum Teamu, dana historyjka jest wyjątkowo pracochłonna, Product Owner rozważa, czy nie lepiej zastąpić
ją inną, mniej pracochłonną, i jeszcze raz przemyśleć czy oryginalna historyjka jest dobrze zde niowana. Product
Owner pamięta o maksymalizacji wartości biznesowej wygenerowanej podczas Sprintu.

• Można wystartować Sprint i przejść do tablicy Sprint Board

fi
Ćwiczenie: Planowanie Sprintu
• Możemy przeciągać zadania do sprintu, lub “naciągnąć” granicę sprintu na
zadania
Ćwiczenie: Planowanie Sprintu
• Historyjki użytkownika możemy grupować w Epiki
Ćwiczenie: Symulacja Daily Scrum
• Jest 10:00 rano, środa. Sprint wystartował w poniedziałek.
• Spotykamy się na stojąco, w tym samym kącie biura co zawsze
• Otwieramy tablicę Sprint Board
• Każdy mówi co robił wczoraj i nad czym będzie pracował dzisiaj. Sygnalizuje, czy
napotkał na problemy.

• Nie rozwiązujemy tych problemów podczas Daily Scrum. Tylko je sygnalizujemy i

umawiamy się na spotkania poświęcone ich rozwiązaniu już w mniejszym gronie.

• Zamknięte zadania przesuwamy do odpowiedniej kolumny na Sprint Boardzie