1

Spis treści

 Wstęp............................................................................4
 Czym jest Visual Management...........................................5
 Materiały i środowisko......................................................6
 Co warto pokazać............................................................8
Task Board...................................................................8
Kanban......................................................................11
Cummulative Flow Diagram..........................................14
Wykresy Spalania........................................................14
Wykres Spalania Sprintu..............................................15
Wykres Spalania Wydania............................................16
Story Map.................................................................17
Scrum Board..............................................................18
Parking Lot................................................................19
Mapy Myśli.................................................................20
 Przykład z życia.............................................................21
 Zasady korzystania z Agile Wall.......................................23
 Narzędzia elektroniczne..................................................24
 Podsumowanie..............................................................25
 Źródła..........................................................................26

2
„Karteczki na ścianie nie powstrzymają Cię przed zbudowaniem beznadziejnego
oprogramowania.” – anonim

Krystian Kaczor
Krystian Kaczor to doświadczony coach, trener i konsultant, który na co
dzień́ łączy ze sobą̨ dwa światy, twardych umiejętności i technologii oraz
miękkich umiejętności i psychologii. Jego wieloletnie doświadczenie na
międzynarodowych projektach (m. in. Szwecja, Holandia i Iran) pozwoliło
na zdobycie wyjątkowych i wszechstronnych umiejętności z obu tych ob-
szarów. W swojej pracy kieruje się maksymą, że jedyną miarą postępu są
mierzalne rezultaty.
W trakcie 10 lat pracy w branży IT, Krystian zdobył wszechstronne do-
świadczenie w całym cyklu wytwarzania oprogramowania. Pracował jako
programista, wdrożeniowiec, tester, wsparcie klienta, Scrum Master, Test
Manager i Project Manager, dzięki czemu patrzy na oprogramowanie oraz proces jego wytwa-
rzania z kilku perspektyw i znajduje wspólny język zarówno z biznesem, jak i IT.
Jest jednym z niewielu coachów i trenerów nadal biorących aktywny udział w projektach.
Współpracuje z firmami, których logo jest łatwo rozpoznawalne w wielu krajach usprawniając
Zespoły, procesy, projekty i całe programy. Jako Agile Coach buduje i prowadzi Zespoły Agile,
przeprowadza transformacje organizacji i ulepsza wdrożone procesy. Posiada doświadczenie
w pracy z Zespołami w zakresie od małych, lokalnych zespołów do geograficznie rozproszonych
korporacji, pracujących w modelach skalowanego i rozproszonego Agile. Prowadzi szkolenia
z obszaru Agile, Scrum, testowania oraz umiejętności miękkich i rozwoju osobistego. Szkolił
i konsultował Zespoły z Polski, Holandii, Niemiec i Rosji.
Autor książki “Scrum i nie tylko. Teoria i praktyka w metodach Agile” wydanej przez PWN,
publikacji po polsku i po angielsku w czasopismach oraz na stronach internetowych. Współ-
założyciel czasopisma c0re. Prelegent na polskich i zagranicznych konferencjach z obszarów
Agile i Testowania. Certified Scrum Professional, CSM, PSM I, PMI-ACP, ISTQB Advanced Le-
vel - Test Manager, Master Practitioner NLP, ICF Associate Certified Coach i Erickson Certified
Professional Coach.

3
 Wstęp

Komunikacja czy innymi słowy przepływ informacji pomiędzy interesa-

riuszami projektu jest jak życiodajne soki płynące w drzewie. Kiedy przepływ
jest zakłócony i ich zabraknie, część drzewa zacznie usychać, a całość będzie
podatna na choroby i ataki pasożytów. Nic dziwnego, że brak komunikacji
jest często podawany jako numer jeden na liście przyczyn porażek projektów.
Zaskakujące jest jak często dochodzi do braku informacji i jak proste
są narzędzia do jej przywrócenia. Za doskonały przykład mogą tutaj po-
służyć narzędzia Visual Management zaczerpnięte z Toyota Production
Process i Lean Management. Zgodnie z tym podejściem powinniśmy uży-
wać wizualnej kontroli, żeby żadne problemy nie pozostawały w ukryciu. To
znaczy, że informacja powinna być tak prezentowana, że pomimo małej ilo-
ści tekstu jest zrozumiała, uwidacznia problemy i umożliwia podjęcie decyzji.
Umieszczanie na ścianach różnych map, wykresów i odręcznych rysunków
może wydawać się mało poważne, a nawet dziecinne. Szczególnie kierownicy
projektów mają upodobanie do wykresów Gantta (nazywany zwany też Har-
monogramem Adamieckiego) i arkuszy Excela tworzonych w ich laptopach.
Ale w większości wypadków prędzej, czy później okazuje się, że zgodnie z
zasadą brzytwy Ockhama, najprostsze rozwiązania są najskuteczniejsze w
prawdziwym życiu. Zastanów się. Czy wolisz tablice z instrukcjami zamiast
znaków drogowych? Czy zdajesz sobie sprawę, że kontrolki na desce roz-
dzielczej Twojego samochodu to też przykład Visual Management?
W tym e-booku przedstawię i omówię sposoby pracy z szeroko poję-
tym narzędziem określanym jako Agile Wall, czyli o wykorzystaniu Visual
Management w świecie metod zwinnych. Szeroko pojętym, ponieważ tak
naprawdę nie ma konkretnego standardu określającego co powinno znajdo-
wać się na takiej ścianie lub jak z niej korzystać. Chciałbym przekazać swoją
wiedzę i praktyczne doświadczenia z tym narzędziem, które bardzo często
okazywało się świetnym katalizatorem lub platformą do wymiany informacji
w sposób zrozumiały dla wszystkich zainteresowanych. Potraktuj tę publika-
cję jako źródło inspiracji i pozwól zespołowi znaleźć własne, najlepsze praktyki.

4
 Czym jest
Visual Management

Głównym założeniem Visual Management jest przedstawianie infor-

macji w sposób obrazowy zamiast opisowego i przedstawianie tekstu za po-
mocą symboli, tak żeby informacja była łatwo zrozumiała dla odbiorców,
wskazywała problemy lub anomalie i umożliwiała podjęcie akcji korygują-
cych. Czyli w skrócie można powiedzieć, że Visual Management jest to zarzą-
dzanie na podstawie informacji przedstawionych w formie graficznej.

Rysunek 1 Wizualizacja informacji na przykładzie samolotu Flying 101 linii lotniczych kulula.com

Bardzo podobnym i często mylonym pojęciem jest Information Ra-

diator, którego nazwę można przetłumaczyć na język polski jako Grzejnik
Informacyjny lub Promiennik Informacyjny. Takie określenie ma stano-
wić przeciwieństwo lodówek informacyjnych, czyli ukrywania istotnych infor-
macji w niewidocznych miejscach. Alistair Cockburn zdefiniował to narzędzie
w książce Crystal Clear w 2004 roku jako wyświetlanie ważnych dla projektu
informacji w łatwo dostępnych i uczęszczanych miejscach w taki sposób,
żeby odbiorca zrozumiał je nawet tylko mimo chodem rzucając okiem.
Podsumowując chciałbym jeszcze raz podkreślić tę subtelną różnicę.
Jeżeli prezentujemy informację w przystępny sposób i w widocznym
miejscu, to jest to Information Radiator. Natomiast jeżeli dodatkowo
jest to przedstawienie informacji pokazujące problemy i wspomagające
podejmowanie decyzji, to mamy już do czynienia z Visual Management.

5
 Materiały i środowisko

Nie bez powodu fraza „location, location, location”1 jest powtarzana

na szkoleniach dla sprzedawców nieruchomości i terrorystów. Od tego, gdzie
umieścisz informację, zależy, czy będzie użyteczna, czy stanie się tak samo
ignorowaną dekoracją jak plan pomieszczeń USS Enterprise, który rok temu
powiesił jeden z developerów. Więc pozwól, że na początku przyjrzymy się
poszukaniu odpowiedniego miejsca i narzędzi, które umożliwią sukces nowe-
go sposobu korzystania z informacji.
Generalnie w zależności od głównego adresata informacji, są dwa typo-
we miejsca, w których można umieszczać Promienniki Informacji. Pierw-
szym i najbardziej oczywistym będzie wydzielona przestrzeń Zespołu, którą
najczęściej nazywamy Agile Space. Najlepiej oczywiście jest, jeżeli Zespół
Agile może siedzieć w osobnym pokoju, który może zagospodarować tak jak
jest dla niego najlepiej. Jak powinna wyglądać taka przestrzeń można do-
wiedzieć się z e-booka Andrzeja Brandta pod tytułem „Environment for Agile
Teams”. W tej samej pozycji można znaleźć kilka ciekawych materiałów, z
których możemy skorzystać. Drugim miejscem, które jest łatwiej dostępne
również dla osób spoza Zespołu będzie korytarz stanowiący główny ciąg
komunikacyjny na piętrze.
Im więcej będziemy mieli powierzchni do wykorzystania na różne no-
tatki i rysunki, tym lepiej. Najlepiej do tego celu nadają się białe tablice
sucho-ścieralne typu whiteboard. Jeśli powiesimy tablicę na ścianie, to naj-
prawdopodobniej zostanie kawałek pustej ściany wokół niej. Jak to wykorzy-
stać. Możemy tam przyklejać arkusze papieru z kolejnymi informacjami, ale
dużo lepszym pomysłem jest pokrycie ścian farbą idea paint2 i uzyskać dużo
większą przestrzeń do nieskrępowanego wykorzystania. Nie ograniczajmy
się w pomysłach na wykorzystanie takiej powierzchni. Często widzę w użyciu
maksymalnie dwa z czterech standardowych pisaków, np. czarny i czerwony.
Zachęcam do poeksperymentowania z mniej znanymi kolorami, takimi jak
fioletowy, brązowy, pomarańczowy. Na ścianach i tablicach można wydzielać
obszary za pomocą specjalnych łatwousuwalnych, samoprzylepnych taśm
(i te polecam do powierzchni typu whiteboard) lub chociażby zwykłej taśmy
malarskiej dostępnej w marketach budowanych.

1
Przynajmniej tak twierdzi Jeff Dunham i jego postać, Ahmed https://www.youtube.com/
watch?v=uBnv61JkLEM
6 2
http://www.ideapaint.com/products/ideapaint
 Jeżeli na przykład z powodu kontraktu na wynajem przestrzeni w bu-
dynku, nie możemy przemalować ścian, ani zawiesić tablic, to nadal możemy
stworzyć sobie odpowiednią powierzchnię do równie dobrego wykorzystania
obklejając ściany papierem. Możemy użyć elektrostatycznej folii EasyFlip Foil®
od Leitz, lub najzwyklejszego szarego papieru pakowego z dużej rolki. Oczy-
wiście kiedy jesteś w takiej sytuacji, zwróć uwagę czy przytwierdzając papier
taśmą do ściany będziesz mógł łatwo ją usunąć i zmyć ślady kleju rozpusz-
czalnikiem. Taśma typu Scotch Tape daje się łatwo odkleić nie pozostawiając
śladów w przeciwieństwie do zwykłej samoprzylepnej taśmy przeźroczystej.

Rysunek 2 Karteczki samoprzylepne Post-It notes

Kolejnym materiałem jaki najbardziej lubią Agile’owe tygryski to karteczki

samoprzylepne Post-It Notes. Dlaczego? Bo łatwo jest przeklejać w tą i z powro-
tem, usuwać i dodawać takie małe skrawki informacji bez kreślenia po tablicy czy
ścianie. Z tego samego powodu zawsze warto zapłacić trochę więcej i kupić orygi-
nalne karteczki z firmy 3M, a nawet ich wzmocnioną wersję Super Sticky. Po prostu
przyklejają się lepiej i rzadko odpadają w przeciwieństwie do podróbek. Dużo lepiej
sprawdzają się też wyraźne kolory z serii Neon niż te pastelowe, bo po prostu rzu-
cają się w oczy. Zachęcam, żebyś eksperymentował do woli z różnymi kształtami i
wielkościami kartek. Zespół powinien zrobić użytek z gamy kolorów i od początku
określić, przeznaczenie kolorów. Na przykład często się spotyka, że kwadratowe,
różowe karteczki są używane na Task Board, o którym już za chwilę, jako nośnik
zgłoszonych błędów, a z kolei prostokątne żółte do zapisywania User Story. Pilnuj
stanu zapasów, bo jeśli zabraknie, któregoś z wykorzystywanego rodzaju, to spo-
woduje to zamieszanie w Zespole i może załamać korzystanie z ustalonych zasad.
Pamiętaj, żeby kilka bloczków i pisaków było zawsze pod ręką w pobliżu ściany.
Dodatkowo można zamieniać dowolne kartki papieru (na przykład wydruk makiety
ekranu) w samoprzylepne karteczki za pomocą kleju Scotch® Restickable Glue.

7
 Co warto pokazać

Właściwie można by skwitować ten rozdział stwierdzeniem, że należy

umieszczać wszystko, co ma wartość dla osób zainteresowanych i wspomaga
podejmowanie decyzji. Najważniejsze jest, żeby Agile Wall był używany i
użyteczny. Nie mogę jednak pozostawić czytelników z tą myślą. Zgodnie z
zasadą ograniczonej innowacyjności więcej pomysłów powstanie kiedy mamy
narzucone pewne ramy i wiemy gdzie zacząć. Pozwól więc, że przybliżę kilka
pomysłów, które można od razu wykorzystać i które są sprawdzone w prak-
tyce przez różne zespoły.

Task Board

Zacznijmy od najbardziej popularnego narzędzia, które jeśli nie za-

wsze jest dobrze wykorzystywane, to przynajmniej można spotkać w Agi-
le Space wielu Zespołów. Kolokwialnie rzecz ujmując, to powinniśmy się
spodziewać tablicy podzielonej na kolumny i karteczek poprzyklejanych w
tychże kolumnach. Ale, o właściwie w tym chodzi?
Task Board to po prostu tablica z zadaniami prezentująca zawsze
aktualny stan pracy. Karteczki podróżują po tej tablicy od lewej do prawej
przechodząc przez kolejne etapy pracy. Właśnie się zastanowiłem czy w kra-
jach, w których pisze się od prawej do lewej, jak na przykład w krajach arab-
skich, karteczki będą się poruszały od prawej do lewej. Każdy etap jest re-
prezentowany przez własną kolumnę opatrzoną odpowiednim nagłówkiem.
Kolumny powinny odpowiadać rzeczywistym fazom przez jakie przechodzi
każde zadanie, ale można zacząć od Do Zrobienia, W realizacji i Ukoń-
czone. Rzeczywiste oddanie tych faz ułatwi śledzenie sposobu w jaki pracu-
je Zespół Developerski oraz wykrywanie problemów w przepływie pracy.
Dobrym podziałem tablicy na kolumny będzie na przykład Do Zrobienia,
Projektowanie, Kodowanie, Przegląd, Testowanie, Ukończone.
Często spotyka się również na tej tablicy osobne wiersze dla każdej User
Story wyznaczone przez umieszczenie karteczki z User Story w skrajnej lewej
kolumnie, a zadań, które jej dotyczą na tej samej wysokości w poziomych wier-
szach. W ten sposób wyznaczamy dodatkowo poziome linie dla grup zadań.
Dodatkowym udogodnieniem może być używanie karteczek dla zadań w tym

8
samym kolorze co karteczka z odpowiednią User Story. Wtedy łatwiej jest śledzić
postęp i przenosić elementy pomiędzy kolumnami.

Rysunek 3 Przykładowa tablica Task Board

Teraz napiszę coś, co może wydawać się oczywiste, ale nader często spo-
tykam się z popełnianiem tego błędu przez zespoły, które wspieram jako Agile
Coach. Na ścianie powinny znaleźć się absolutnie wszystkie rzeczy, nad którymi
pracuje Zespół Agile. Ta zasada dotyczy zadań, które zostały zidentyfikowane
w czasie trwania Iteracji i tych, które „wpadły z boku”, czyli nieplanowane. Tak
samo należy postępować z wszelkimi wykrytymi i rozwiązywanymi w czasie Ite-
racji defektami. Jeżeli nie będziemy przestrzegać tej reguły, to będziemy mieli
fałszywy obraz, na podstawie, którego podejmujemy ważne decyzje.
Karteczki z User Story i z zadaniami zawierają więcej informacji niż tylko
nazwa. Te pierwsze z uwagi na to, że w myśl Scrum są przedstawicielami Reje-
stru Produktu, czyli są Elementami Rejestru Produktu (ang. Product Bac-
klog Item (PBI)) powinny prezentować takie właściwości jak oszacowany rozmiar
(najczęściej w punktach), porządek na liście i unikalny identyfikator pozwalający
na znalezienie elementu na liście. Z kolei dla zadań nie ma konkretnych wytycz-
nych i to co się najczęściej spotyka to nazwa zadania, oszacowany czas potrzeb-
ny na wykonanie zadania i inicjały osoby, która nad nim pracuje.
Trzeba pamiętać o tym, żeby z góry nie przypisywać zadań do konkretnych
osób na przykład na Planowaniu Iteracji. Żeby umożliwić samoorganizację,
zadania powinny znajdować właściciela dopiero, kiedy mają zostać wykonane.
Zespół Agile zawsze powinien wspólnie tworzyć plan na kolejny dzień. Praca w
metodach zwinnych nie polega na zrywaniu nisko wiszących owoców i robieniu
tego co wygodne, ale na robieniu tego, co najbardziej w danej chwili przybliży
Zespół do osiągnięcia Celu Iteracji. Więcej o planowaniu i samoorganizacji
możesz dowiedzieć się z książki mojego „Scrum i nie tylko”, a teraz trzymajmy
się tematu tablic.

9
10
 W zależności od tego jak Zespół Agile się umówi, tablica jest aktu-
alizowana przez członków zespołu w czasie codziennych spotkań stand-up
takich jak Daily Scrum lub od razu wtedy, kiedy stan zadania zmienił się.
Ponieważ tablica Task Board należy do zespołu, to cały zespół jest odpo-
wiedzialny za jej utrzymanie, a nie Project Manager, Scrum Master lub
najmłodsza osoba w zespole. Drogi czytelniku, jeśli właśnie zdałeś sobie
sprawę, że ktoś Cię wrobił w wykonywanie tej pracy, to możesz to wreszcie
zmienić.
Tak jak wcześniej pisałem, że tablica Task Board wspomaga podej-
mowanie decyzji poprzez Zespół pokazując aktualny stan pracy. Groma-
dzenie karteczek w którejś kolumnie lub wręcz przeciwnie, ich brak skazuje
obszary problemowe procesu. Oczywiście samo narzędzie nie rozwiązuje
problemów. Rozwiązania zawsze powinny pochodzić od członków Zespołu
Agile. Na ogół będzie to oznaczało skierowanie sił całego zespołu na wyko-
nywanie pracy w jednym obszarze, żeby znowu udrożnić przepływ. Można
też na przykład zaczerpnąć z technologii Kanban i wprowadzić limity WIP
(o czym w kolejnym podrozdziale) w kolumnach problematycznych. Oczy-
wiście wszelkie trudności powstałe podczas Iteracji powinny być omówione
na Retrospekcji.
Czy patrząc na Task Board możemy określić co zespół dostarczy na
koniec Iteracji i czy zdąży z wykonaniem pracy przed upływem ramy cza-
sowej? Na pierwszą część pytani możemy odpowiedzieć twierdząco, ponie-
waż, jeżeli wszystkie karteczki dla danej User Story znajdują w kolumnie
Ukończone, to User Story zostanie dostarczona. Natomiast obserwując
liczbę karteczek w kolejnych kolumnach nie możemy powiedzieć jakie jest
tempo pracy i czy jest ono wystarczające do ukończenia pracy w terminie.
Dlaczego tak się dzieje? Odpowiedź jest bardzo prosta. Zadania są różnej
wielkości, więc nie wiemy czy kilka elementów w ostatniej kolumnie to kilka
zadań półgodzinnych, a kolejne kilkugodzinnych jest nadal do zrobienia czy
wręcz odwrotnie. Lepiej na pytanie postawione na początku tego akapitu
odpowiedzą nam wykresy spalania Burndown lub Burnup o których wię-
cej napiszę w dalszych podrozdziałach.

Kanban
Warto wiedzieć, że jest zwinna metoda Kanban i narzędzie Kanban
oraz to, że korzystasz z narzędzia nie oznacza, że korzystasz w prawidłowy
sposób z metody. Ostatnio coraz częściej obserwuje, że Kanban to nowe
„buzz word” na określenie nieudolnego wprowadzenia Agile w organizacji.
Jeszcze kilka lat temu jeżeli organizacja nie miała określonego procesu wy-
twarzania oprogramowania i nie korzystała z żadnej konkretnej metody, to

11
 managerowie twierdzili, że mają Agile. W wolnym tłumaczeniu oznaczało
to „róbta co chceta” i pracę w trybie „pożar w burdelu”. Ponieważ wiedza
na temat Agile wzrosła w ciągu ostatnich kilku lat, taka wymówka stała się
nieskuteczna i wręcz krępująca. Teraz nowymi określeniami bałaganu są
Kanban i stwierdzenie, że zespół ma tablicę z karteczkami.
No dobrze, w takim razie o co chodzi w tym Kanbanie? Narzędzie po-
chodzi się z systemu pracy w Toyocie, czyli osławionego już Toyota Pro-
duction System i nazwa oznacza w języku japońskim tablicę informacyjną.
Tablica Kanban wygląda bardzo podobnie do wcześniej opisanej Task Board
z pewnymi wyjątkami.

Rysunek 4 Przykładowa Tablica Kanban

Jedną ze zmian jest wprowadzenie limitów pracy w toku (ang. Work

In Progress Limit (WIP)) dla każdej z kolumn. Ograniczenie liczby zadań,
które mogą znajdować się w danej kolumnie jest sposobem na kontrolo-
wanie przepływu pracy określanego jako workflow. Przerwy w strumie-
niu karteczek lub blokada spowodowana maksymalną ilością kartek w ko-
lejnych fazach to oczywiście problemy, które zespół powinien rozwiązać
wspólnymi siłami. Nowe zadania są wciągane z puli dopiero, kiedy jest
na to miejsce, więc wszystkim interesariuszom zależy na jak najbardziej
sprawnym procesie. Cały workflow może być jedynie na tyle wydajny na
ile wydajne jest jego najsłabsze ogniwo, czyli wąskie gardło. Powinniśmy
tak dostosować limity, żeby jak najlepiej wykorzystać możliwości wąskie-
go gardła.
Trudno mi się teraz oprzeć, żeby nie podać tutaj sposobu pracy
z wąskimi gardłami, bo to już sięganie do metody Kanban i ma mało

12
wspólnego z tablicą. Zatem, zdradzę Ci, że korzystamy w takim wypadku
z metody pięciu kroków, 5 Focusing Steps.

1. Zidentyfikuj ograniczenie.
2. Zdecyduj jak maksymalnie wykorzystać to organicznie.
3. Podporządkuj wszystko w systemie decyzji podjętej w kroku 2.
4. Zwiększ pojemność ograniczenia, tak, żeby uwolnić wąskie gardło. Teraz
kolejne ograniczenie może pojawić się w innej części systemu.
5. Zidentyfikuj kolejne ograniczenia i wróć do kroku 2.

Drugą różnicą jest to, że często kolumny są dodatkowo podzielone na

dwie części, żeby pozwolić na oczekiwanie zadań i lepiej uwidocznić co oczekuje
na kolejny etap, a gdzie praca jest naprawdę wykonywana. Taki podział tworzy
bufory, które pomagają nadać większą płynność pracy. W ten sposób, jeżeli
programiści zakończyli kodowanie, to mogą przesunąć zadania do buforu fazy
Testowanie zamiast czekać, aż zwolni się tam miejsce. Puryści mogą powiedzieć,
że lepiej nie korzystać z buforów i pozwolić całemu zespołowi wspólnie oczyścić
kolumnę Testowanie.
Kolejną rzeczą jaką możemy spotkać na tablicach Kanban są swimla-
nes, czyli grupy wierszy na tablicy wydzielone poziomymi liniami. Mogą one
oznaczać zadania z różnych obszarów, od różnych sponsorów lub różne priory-
tety. Służy to szybkiej priorytetyzacji pracy. Na przykład zespół może mieć na
tablicy swimlanes z regularnymi zadaniami developerskimi i zadania związane
z rozwiązywaniem problemów na środowisku produkcyjnym. Kiedy pojawiają
się zadania w swimlane z priorytetem, Zespół natychmiast przerywa pracę w
zwykłej swimlane i zaczyna nad nimi pracować.
W metodzie Kanban nie ma iteracji, ale nadal istnieje potrzeba mierze-
nia przepustowości naszego workflow. Mierzy się ile czasu zajmuje wykonanie
zadania oraz ile zadań udało się ukończyć w pewnym odcinku czasu. Dlatego po
rozpoczęciu pracy nad zadaniem wpisuje się dzisiejszą datę.
Największymi zaletami tego narzędzia są jego prostota i lekkość, dzięki
którym możemy wykorzystywać tablicę Kanban niezależnie od metodyki pro-
wadzenia projektów. Nic nie stoi też na przeszkodzie, żeby stosować limity WIP
i eliminację wąskich gardeł za pomocą Five Focusing Steps w połączeniu z tablicą
Task Board w Scrum.

13
 Cummulative Flow Diagram

Cummulative Flow Diagram (CFD) to prosty pomysł zaczerpnięty z me-

tody Feature Driven Development pokazujący jak wygląda przepływ pracy w
ciągu iteracji. Można spotkać się też ze skrótowym określeniem tego narzędzia
jako CFD. Tworzenie takiego diagramu polega na codziennym nanoszeniu sumy
zadań znajdujących się w poszczególnych fazach pracy tak, żeby w sumie dawa-
ły całkowitą ilość zadań. W ten sposób powstają warstwy dla różnych faz.

Rysunek 5 Przykładowy Cumulative Flow Diagram

Patrząc na zmiany w warstwach poprzez okres iteracji, możemy łatwo za-

uważyć wąskie gardła i inne zakłócenia w przepływie pracy.
Jeżeli będziesz korzystała z arkusza kalkulacyjnego Excel do tworzenia
tego wykresu za pomocą narzędzia skumulowany wykres warstwowy spotkasz
się z pewną niedogodnością. W kolejnym dniu, gdzie nie ma jeszcze danych,
Excel będzie rysował wykres dla wartości 0.

Wykresy Spalania

Oprócz tego czym zespół się zajmuje i jak wydajny jest proces wytwarzania,
chcielibyśmy też wiedzieć czy zespół zdąży dostarczyć produkt na czas. Z ta-
blic za zadaniami nie możemy tego wyczytać, bo nie widać tam upływającego
czasu, sumarycznej wielkości zadań czy tempa pracy zespołu. Do Lipca 2013

14
Wykres Spalania Sprintu i Wykres Spalania Wydania były obowiązkową
częścią Scrum. Pomimo pozostawienia większej swobody w doborze narzędzi
jest to nadal najczęstszy wybór zespołów.
Wykres Spalania to pomysł, który Jeff Sutherland zaczerpnął ze swoje-
go doświadczenia jako pilot wojskowy3. Po prostu lądując samolotem na pasie,
trzeba wiedzieć jaką długość pasa masz przed sobą i jak szybko wytracasz pręd-
kość. Zatem na tego typu wykresie zawsze będziemy nanosili ilość pracy jaka
pozostała na osi czasu zakładając, że na koniec okresu będziemy mieli 0 pracy
pozostałej. Właśnie taka forma wykresu nazywana jest burndown. Rzadko zda-
rza się, że Zespół wybiera odwrotną formę tego wykresu czyli burnup nanosząc
ilość pracy wykonanej w czasie zakładając, ze na koniec okresu będzie 100%
zaplanowanej ilości. Wykresy można tworzyć odręcznie, na tablicy pod koniec
codziennego spotkania. Równie dobrze można wykorzystać oprogramowanie ta-
kie jak arkusz kalkulacyjny czy aplikacja wspierająca Agile Development.
Tworzenie wykresów to jedno, a korzystanie z nich i odczytywanie infor-
macji to co innego. Przyjrzyjmy się zatem jakie informacje przedstawiają dwie
podstawowe wersje, czyli Wykres Spalania Sprintu i Wykres Spalania Wy-
dania.

Wykres Spalania Sprintu

Wykres Spalania Sprintu dotyczy, jak sama nazwa wskazuje, pracy wy-
konywanej w Sprincie. Pierwszym krokiem tworzenia takiego wykresu jest wy-
znaczenie linii idealnego spalania. Robimy to przez narysowanie linii od sumy
oszacowanego czasu zadań po Planowaniu Sprintu w pierwszym dniu do
zera godzin ostatniego dnia. W ten sposób mamy linię odniesienia, którą bę-
dziemy wykorzystywali do określenia czy pracując w obecnym tempie zespół
zamknie wszystkie zadania do końca Sprintu czy nie. Teraz już pozostaje
nam tylko rysowanie kolejnych linii pomiędzy punktami oznaczającymi sumę
godzin zadań, które pozostały do wykonania.
Zwykle zespoły aktualizują burndown pod koniec Codziennego
Scrum. Jeżeli praca przebiega dobrze i Zespół Developerski nie odkryje no-
wych zadań, to każdego dnia powinniśmy mieć mniej godzin. Nie przejmuj
się, jeżeli w pewnym momencie ilość pozostałego czasu będzie większa niż
po Planowaniu Sprintu. Również płaska linia przez dzień czy dwa nie ko-
niecznie będzie zwiastowała problemy. Jeżeli zespół zamyka zadania, ale od-
krywa nowe zadania lub inne zajmują więcej niż oryginalnie oszacowano, to
może właśnie wyglądać jak płaska linia. Ważne jest, żeby używać wykresu
jako wskaźnika, a nie wyroczni i zawsze sprawdzać sytuację z Zespołem
Developerskim. No dobrze, ale po co była ta linia idealnego spalania? Jeżeli
trend rysowania kolejnych odcinków wykresu oddala się ponad tą linię, su-

3
http://www.youtube.com/watch?v=HV76WzqpSI0
15
 geruje to, że zespół nie zdąży wykonać zaplanowanej pracy. Z kolei jeżeli ten
sam trend rysuje się poniżej linii idealnego spalania, to możemy wnioskować,
że zespół zakończy pracę wcześniej i może przyjąć więcej pracy.

Wykres Spalania Wydania

Wykres Spalania Wydania obejmuje swoim zakresem większy za-

kres, bo wydanie złożone z kilku Iteracji i korzysta z innych jednostek. Tym
razem nie interesują nas oszacowane idealne godziny zadań, ale oszacowana
wielkość User Story wyrażona najczęściej w punktach4 . Podobnie jak we
wcześniejszym przypadku najpierw rysujemy linię idealnego spalania. Począt-
kiem linii jest suma punktów planowana do dostarczenia w tym wydaniu, a
końcem jest zero punktów na koniec ostatniego Sprintu. Po każdym Sprincie
zaznaczamy ilość User Story jaka pozostała do spalenia. Wykres Spalania
Sprintu spotyka się zarówno w formie liniowej jak i słupkowej. W tej drugiej
postaci dla słupków rysuje się linię trendu, która wyznaczając przecięcie z osią
poziomą pokazuje kiedy zaplanowany zakres będzie ukończony.
W zależności o tego czy używamy planowania z określoną datą, czy z
określonym zakresem możemy podejmować decyzję co do zakresu lub daty
wydania. Więcej na temat tych dwóch rodzajów planowania możesz dowie-
dzieć się z książki „Scrum i nie tylko. Teoria i praktyka metod Agile”

Rysunek 6 Przykładowy Wykres Spalania Sprintu

4
Z mojej książki „Scrum i nie tylko" dowiesz się więcej o technikach szacowania w Agile.
16
Rysunek 7 Przykładowy Wykres Spalania Wydania

Story Map

Story Map, czyli mapa User Story jest narzędziem, które gorąco polecam
każdemu Właścicielowi Produktu, czy też innemu przedstawicielowi biznesu,
który pracuje z Zespołem Agile. Dlaczego? Ponieważ tworzenie Story Map jest
proste, pobudza twórcze myślenie, pomaga uporządkować kierunek rozwoju pro-
duktu, zrozumieć zakres kolejnych wydań i właściwie ustalić priorytety. A tego
wszystkiego można dokonać za pomocą ściany i kolorowych karteczek.
Budowanie takiej mapy zaczynamy od określenia poszczególnych funk-
cjonalności produktu i najprostszego sposobu skorzystania z funkcji systemu
przez użytkownika od początku do końca. Przyklejając kolejne karteczki z
Epikami lub Tematami utworzymy w ten sposób tak zwany kręgosłup sys-
temu. W kolejnych wierszach dokładamy User Story, których implementa-
cja umożliwi korzystanie z tych podstawowych funkcjonalności w najprostszy
sposób. Teraz zbudowaliśmy minimalną implementację produktu, którą na-
zywa się chodzącym szkieletem. Dalej dokładamy „mięsko”, czyli opcjonalne
sposoby korzystania z funkcjonalności systemu takie jak na przykład kilka
sposobów wyszukiwania produktu czy dodawania go do koszyka. User Sto-
ry w niższych wersjach są bardziej opcjonalne niż te w wyższych. Kiedy już
mamy naszą mapę gotową, przedstawiciel biznesu może wyznaczyć zbiory
User Story, które chce mieć dostarczone w kolejnych wydaniach produktu.

17
 Rysunek 8 Przykładowa Story Map

Oczywiście Story Map może ulegać aktualizacji i zmianom zarówno

w priorytetach jak i ilości elementów. Zgodnie z podstawowymi założeniami
opisanymi w Manifeście Agile, zmiana jest mile widziana. Mapę może two-
rzyć grupa sponsorów lub przedstawiciel biznesu razem z Zespołem Agile.

Scrum Board
Zespoły Scrum często korzystają podczas Codziennego Scrum z ta-
blicy, która jest nazywana Scrum Board. Tak naprawdę jest to mix różnych
narzędzi, które zespół uznał za warte skorzystania. Centralnym elementem

Rysunek 9 Przykładowa tablica Scrum Board

18
zawsze jest Task Board albo Kanban Board z zadaniami dla konkretnego
Sprintu. Do tego dochodzą nam Wykresy Spalania i Lista Przeszkód. Zanim
pójdziemy dalej, słowo wyjaśnienia na temat Listy Przeszkód. Scrum Master
utrzymuje taką listę w trakcie iteracji i umieszcza na niej zidentyfikowane prze-
szkody oraz to czy zostały już rozwiązane czy nie. Równie dobrą praktyką jest
umieszczenie listy akcji jakie Zespół uzgodnił do wykonania w trakcie Sprintu
na poprzedniej Retrospekcji Sprintu.
Nic nie stoi na przeszkodzie, żeby na Scrum Board pojawiły się inne na-
rzędzia Visual Management, które Zespół uzna za pożyteczne.

Parking Lot

Diagram Parking Lot jest kolejną techniką, którą możemy zaczerpnąć

z metody Feature Driven Development. Jest to genialny w swojej prostocie
sposób przedstawienia postępu wykonania wszystkich elementów produktu. W
swojej pierwotnej postaci oprócz planowanej daty dostarczenia funkcjonalności
ten diagram śledzi również procent ukończenia tej funkcjonalności, który jest
wyznaczany stosując konkretną regułę. Jednakże w każdej innej metodzie Agile
możemy w tym celu po prostu skorzystać z postępu obliczonego w oszacowanej
wielkości składających się na niego elementów. Na przykład w Scrum możemy
tworzyć raport Parking Lot dla Epików lub Tematów obliczając postęp na
podstawie stosunku ukończonych do wszystkich User Story.
Dzięki temu narzędziu można szybko określić postęp poszczegól-
nych elementów Produktu. Naturalnie, w Agile nie jest celem ukończenie
wszystkich Epików czy Tematów. Wszystko zależy od tego co założyliśmy
na Story Map i co postanowił przedstawiciel biznesu. Warto jednak wie-
dzieć jak wygląda stan Rejestru Produktu i mieć nad nim dobrą kontrolę.

Rysunek 10 Przykładowy diagram Parking Lot

19
 Mapy Myśli

Minęło sporo czasu zanim pomysł Tony’ego Buzana na wizualizację

informacji wszedł do powszechnego użycia. Cała koncepcja wywodzi się z
teorii, że ludzie nie myślą w sposób liniowy, przechowując w głowie wypunk-
towane listy. Nasze mózgi są zbudowane z połączonych ze sobą promieni-
stych neuronów. Zatem sięgając po informacje zawsze przemieszczamy się
pomiędzy kolejnymi neuronami, które mogą prowadzić do całego zbioru
połączonych pojęć. W ten sam sposób powinniśmy przedstawiać informa-
cje, żeby ułatwić ich zrozumienie i zapamiętywanie. Mapy myśli tworzymy
wokół centralnego tematu dodając gałęzie z kolejnymi pojęciami.
Można powiedzieć, że mapy myśli mają się tak do list wypunktowa-
nych jak Rejestr Produktu w arkuszu kalkulacyjnym do Story Map na
ścianie.
Jeżeli taką mapę tworzysz odręcznie, to możesz stosować różne sty-
le linii i liter oraz rysować obrazki zamiast słów. Możesz też skorzystać z
oprogramowania do budowania mapy myśli takiego jak MindManager czy
Xmind, ale wtedy trzeba się pogodzić z pewnymi ograniczeniami.
Jak wykorzystać mapy myśli na projekcie Agile? To doskonałe narzę-
dzie do prezentowania elementów projektu lub produktu. Równie dobrze
można pokazywać stan testów w iteracji lub plan testów.

Rysunek 11 Mapa myśli dla książki Scrum i nie tylko stworzona w programie XMind

20
Przykład z życia

Chciałbym przytoczyć historię, która wydarzyła się w pewnej organiza-

cji, której mogłem pomóc jako Agile Coach. Nie otrzymałem autoryzacji, ani
nie mam w zwyczaju opowiadać o słabościach klientów, którzy obdarzają mnie
swoim zaufaniem, więc nie zobaczysz tutaj szczegółów, które mogłyby ziden-
tyfikować firmę. Jest jednak kilka rzeczy istotnych dla zrozumienia kontekstu
sytuacji. Firma X zajmuje się skomplikowaną technologią wykorzystywaną w
przemyśle medycznym i różnego rodzaju fabrykach dostarczając rozwiązania
w postaci urządzeń oraz wyspecjalizowanego oprogramowania. Ponieważ mam
dużo wiedzy i doświadczenia w zakresie testowania zostałem poproszony o kon-
sultacje dotyczące testowania w jednym z kluczowych projektów. Organizacja
była przekonana, że wprowadziła Agile już dwa lata temu korzystając z pomocy
dwóch coachów, a teraz kiedy korzystają z tej metody w najważniejszym pro-
jekcie modernizującym flagowy produkt, zawodzili testerzy w Zespole Scrum.
Jak życie pokazuje, jest wiele wersji prawdy. Sprawdźmy najpierw skąd pojawił
się taki wniosek? Zespół Scrum dostarczał produkt niskiej jakości na koniec
każdego Sprintu i to było namacalnym faktem. Niska jakość często wiąże się w
świadomości kierownictwa z niewystarczająco dobrym wykonaniem testów. W
takiej sytuacji lubię zawsze odpowiadać, że przecież ktoś napisał niskiej jakości
kod. Nie możemy też zapominać, ze w Scrum cały Zespół Developerski jest
odpowiedzialny za jakość wykonanej pracy i swoje zobowiązania. Mamy jasny,
widoczny skutek, ale przyczyn przecież może być wiele. Po dwóch Sprintach
spędzonych razem z Zespołem okazało się, że oprócz możliwości poprawy
praktyk developerskich i testerskich, co można stwierdzić zawsze, prawdziwym
problemem była jakość wymagań dostarczanych przez Właściciela Produktu.
Nie było ani jednej osoby, która rozumiałaby zakres projektu i wizję produktu,
który budują. Skutek był taki, że każdy Developer budował, to co uważał za
istotne w części produktu, którą znał najlepiej, wybierając lub tworząc odpo-
wiednie User Story. Nie można było określić Celu Sprintu, a testerzy nie mieli
pojęcia jaki jest zakres testów. Testowanie dowolnej funkcjonalności kończyło
się awarią aplikacji po pięciu minutach. Poszczególne moduły nie były zintegro-
wane ze sobą. Znalezione błędy były tłumaczone jako „ta część nie jest jeszcze
gotowa”. Dołóżmy do tego wdrożenie nowej technologii i zbieraninę indywidu-
alności, która nie pracowała ze sobą wcześniej, a otrzymamy przepis na poraż-
kę. Nienegocjowalny deadline na wypuszczenie oprogramowania na rynek za

21
 siedem miesięcy. Zegar ruszył i nie zatrzyma się nawet na chwilę. Powodzenia
panie konsultancie! Jakie kroki można podjąć, żeby szybko i sprawnie zawrócić
tą łódź podwodną na kursie donikąd?
Kierując się zasadą Pareto5 postanowiłem skupić 80% wysiłku na co-
aching i mentoring Właściciela Produktu, a resztę na coaching Zespołu
Developerskiego. Nie mogłem pomóc merytorycznie w określaniu zakresu i
priorytetów produktu, ale mogłem ułatwić proces będąc jego facylitatorem. Po
kilku sesjach udało się zebrać to, co było w tej chwili Rejestrem Produktu
w jednym miejscu i zacząć budować Mapę User Story określając prawdziwą
Wizję Produktu i zakres projektu. Na potrzeby warsztatu z całym Zespołem
Scrum i sponsorami projektu do wizualizacji Mapy wykorzystaliśmy możliwość
drukowania karteczek prosto z Atlassian Jira, białą tablicę, taśmę typu Scotch
Tape i gilotynę do papieru. Było to ćwiczenie, które otworzyło oczy wszystkim
interesariuszom i pozwoliło na rzeczowe dyskusje na temat wizji i zakresu.
Niektóre User Story zostały scalone, powstały nowe i zostało usunięte
sporo zupełnie zbędnych. Po oszacowaniu całego nowego Rejestru Produktu
i kolejnej sesji byliśmy w stanie wrócić z do idealnej linii spalania na Wykresie
Wydania. Na reszcie łatwo było określać cele kolejnych Sprintów. Develope-
rzy i testerzy skupili się na realizowaniu i dostarczaniu pełnych funkcjonalno-
ści oraz zrozumieli kierunek działania. Okazało się, że niektóre funkcjonalności
można dostarczyć w prostszy sposób albo niskim nakładem przy realizowaniu
innych jeśli tylko Developerzy będą pamiętali o tym na poziomie tworzenia ar-
chitektury. Oprócz Mapy User Story, która stała się nieodzownym elementem
pokoju oraz miejscem częstych spotkań i owocnych dyskusji, stworzyliśmy dru-
gą mapę opartą o makiety ekranów dostarczone przez Właściciela Produktu.
Pisząc makiety, nie mam namyśli w pełni gotowych do zaimplementowania pro-
jektów ekranu, ale proste ekrany poglądowe narysowane w Wordzie z powkle-
janymi ikonami ze starej aplikacji. Kiedy tylko jakaś User Story lub ekran były
ukończone, Zespół z niekrytą satysfakcją i radością odhaczał odpowiedni ele-
ment na mapie grubym zielonym pisakiem. Jak można było się spodziewać obie
mapy przyciągały także zainteresowanie sponsorów projektu i prowokowały do
ciągłego feedbacku, który PO6 uwzględniał w kolejnych User Story. Pamiętaj-
my też o tych pozostałych 20%, czyli o coachingu Zespołu Developerskiego,
który również był potrzebny do tego, żeby kolejne Przyrosty Produktu dostar-
czane na koniec Sprintów były ukończone. Jednak największym katalizatorem
tej interwencji była wizualizacja informacji i zbudowanie map, które do końca
projektu przyciągały różnych interesariuszy i zachęcały do wymiany istotnych
informacji niczym ognisko po środku karawanseraj w Nikosii7.
A teraz przypomnij sobie do rozwiązania jakiego problemu zostałem za-
trudniony.

5
Zasada Pareto, lub zasada 80/20

22
Zasady korzystania
z Agile Wall

Zasady powinien ustalić zespół lub inni ludzie, którzy mają z Agile Wall sko-
rzystać. Tak samo jak procesy w Scrum i wokół Zespołu Scrum powinny być
jasne i określone, tak samo powinny być wypracowane i spisane dobre praktyki
oraz zasady korzystania z narzędzi Visual Management. Podam kilka pomy-
słów, które możesz zastosować i kilka decyzji, które na pewno Zespół będzie
musiał ustalić.
Pamiętaj, żeby ustalić kto i kiedy uaktualnia narzędzia. Napisy powinny
być czytelne nawet z pewnej odległości, więc polecam korzystanie z czarnego
pisaka i pisanie drukowanymi literami. Na zadaniach w trakcie realizacji moż-
na wpisywać inicjały osób, które nad nimi pracują albo przyklejać awatary (na
przykład z South Park http://southpark.cc.com/avatar) czy zdjęcia. Trzeba też
ustalić czy zadania, które nie przeszły przeglądu kodu albo testowania wra-
cają do stanu „kodowanie”, czy może do „nowe”. Jeżeli korzystamy z tablicy
typu whiteboard, to możemy dopisywać na niej dodatkowe informacje przy
karteczkach, lub rysować zależności między zadaniami. Zadania, których nie
można wykonać, bo są zablokowane z jakiegoś powodu dobrze jest oznaczyć
w wyraźny sposób. Proponuję przyklejanie na nich małej różowej karteczki.
Zespół musi podjąć decyzję czy takie zadanie ma pozostać w obecnym statusie
czy wrócić na początek tablicy. Jeżeli zdania wiszą dłużej niż dzień w realiza-
cji, to można na karteczkach rysować kropki każdego dnia. Dla spóźnialskich
można stworzyć Wall of Shame z ich zdjęciem i ustalić zasadę, że po trzech
spóźnieniach muszą kupić czekoladki dla całego zespołu albo pączki.
To tylko kilka pomysłów z mojej praktyki i praktyki innych coachów, a kre-
atywność Zespołów Agile jest praktycznie bezgraniczna i często zaskakuje.

6
PO = Product Owner, czyli Właściciel Produktu. Tak samo jak SM dla Scrum Mastera, jest to
popularne skrótowe określenie roli w framework Scrum
7
Karawanseraj – zajazd dla karawan o pomieszczeniami dla podróżnych i magazynami. Takie
zajazdy były budowane przy szlaku handlowym i ułatwiały przepływ towarów, informacji i ludzi.
Jeden najlepiej zachowanych budynków tego typu, Buyuk Han znajduje się w Nikosii na Cyprze.
23
 Narzędzia elektroniczne

Zawsze kiedy rozmawiamy o narzędziach używanych w rozwoju opro-

gramowania lub pracy z zespołami Agile, pada pytanie „Czy jest do tego
aplikacja?”. W przypadku narzędzi opisanych w tym e-booku mamy na ryn-
ku przynajmniej kilka propozycji, które w mniej lub bardziej natywny spo-
sób wspierają ich używanie. Przede wszystkim mamy najbardziej popularną
wśród Zespołów Agile trójkę, czyli Atlassian Jira, Version One i Rally
Software. We wszystkich tych platformach wspierających Agile możemy
spodziewać się pewnej formy Task Board, Wykresów Spalania i Cumu-
lative Flow diagram. W każdej możemy też zbudować elektroniczną tabli-
cę dashboard, którą możemy wyświetlać na ekranach zamiast wersji pa-
pierowej z karteczkami. Takie elektroniczne narzędzia doskonale wpierają
wymianę informacji w zespołach rozproszonych geograficznie. Jednakże u
zdecydowanej większości zespołów spotyka się tendencję do korzystania z
wersji papierowej Agile Wall, co najwyżej synchronizowanej z elektronicz-
ną. Dlaczego tak się dzieje? Zespoły Agile uważają, że karteczki na ścianie
są bardziej namacalne i „należą” do nich. Tworząc własną ścianę z narzę-
dziami Visual Management mamy też większą możliwość dostosowywania
zawartości i wyglądu do naszych preferencji.
Poza wyżej wymienioną trójką znanych na rynku graczy istnieją też
inne alternatywy. Microsoft wprowadził wsparcie dla Agile w Visual Stu-
dio i Team Foundation Server. Narzędzie Trac umożliwia zainstalowanie
pluginów generujących Task Board i Wykresy, ale nie jest to zbyt poręczne
rozwiązanie. Dodatkowo mamy też Scrumwise, SeeNowDo, Basecamp,
rodzimy Banana Scrum i wiele, wiele innych.
Wybierając narzędzie dla swojego zespołu pamiętaj, że nie ma narzędzi ide-
alnych i parafrazując cytat z filmu Miś, każde narzędzie ma plusy dodatnie
oraz plusy ujemne. Musisz je poznać, świadomie dokonać wyboru i przete-
stować w pilocie.

24
Podsumowanie

Przepływ informacji jest niezbędny dla prawidłowego funkcjonowania

projektu. Dzięki prawidłowym i łatwo dostępnym informacjom możemy podej-
mować właściwe decyzje. Wydaje nam się, że w tym celu piszemy setki stron
dokumentacji i tworzymy kolejne arkusze Excela, prezentacje w Power Point,
wykresy Gantta itd. Zapominamy, że istnieją niezwykle proste narzędzia, które
będą wręcz promieniowały informacjami zrozumiałymi dla wszystkich zainte-
resowanych i pomogą dobrze zrozumieć sytuację w mgnieniu oka. Wybierz z
tego e-booka jeden pomysł, który możesz wdrożyć od razu i to zrób. A później
możesz sięgnąć po kolejne. Pamiętaj o pozostawieniu przestrzeni dla zespołu w
dopasowaniu narzędzia i wypracowaniu zasad korzystania z niego.

25