scrum i kanban. analiza lekkich metod wytwarzania ... · scrum określa większą liczbę warunków...
TRANSCRIPT
2
SPIS TREŚCI Spis treści .............................................................................................................................................................................. 2
Wstęp ...................................................................................................................................................................................... 5
Inspiracja metod ................................................................................................................................................................. 5
Zarys metod .......................................................................................................................................................................... 5
Scrum ................................................................................................................................................................................. 6
Kanban ............................................................................................................................................................................... 7
Podsumowanie ............................................................................................................................................................... 8
Perspektywa: Wdrożenie Koncepcji .......................................................................................................................... 9
Scrum ................................................................................................................................................................................. 9
Kanban ............................................................................................................................................................................... 9
Podsumowanie ............................................................................................................................................................ 10
Perspektywa: Podział pracy i ograniczenie pracy w toku ............................................................................. 10
Scrum .............................................................................................................................................................................. 11
Podział pracy ........................................................................................................................................................... 11
Praca w toku ............................................................................................................................................................ 11
Kanban ............................................................................................................................................................................ 12
Podział pracy ........................................................................................................................................................... 12
Praca w toku ............................................................................................................................................................ 12
Podsumowanie ............................................................................................................................................................ 13
Perspektywa: Sposób pracy ........................................................................................................................................ 13
Scrum – praca iteracyjna ......................................................................................................................................... 13
Rytm ............................................................................................................................................................................ 14
Skupienie na celu ................................................................................................................................................... 14
Gwarancja realizacji aktywności ..................................................................................................................... 15
Gwarancja częstego odbioru pracy ................................................................................................................ 15
Zaangażowanie członków zespołu w aktywności ................................................................................... 15
Poziom wykorzystania możliwości zespołu ............................................................................................... 15
3
Czas nie w pełni wykorzystany w szerszej perspektywie .................................................................... 16
Efekt ściśle określonego zakresu pracy i czasu pracy. ........................................................................... 16
Kanban – praca ciągła ............................................................................................................................................... 17
Asynchroniczność ................................................................................................................................................. 17
Czas odpowiedzi na zmiany .............................................................................................................................. 18
Praca ad-hoc ............................................................................................................................................................ 18
Możliwość pełnego wykorzystania specjalistów ..................................................................................... 19
Pełne wykorzystanie możliwości zespołu .................................................................................................. 19
Utrzymanie wydajności zespołu w dalszej perspektywie .................................................................... 19
Efekt braku ograniczenia czasowego, konkretnego celu i skupienia na specjalizacji ............... 19
Podsumowanie ............................................................................................................................................................ 20
Perspektywa: Definicja gotowości ........................................................................................................................... 20
Scrum .............................................................................................................................................................................. 20
Kanban ............................................................................................................................................................................ 21
Podsumowanie ............................................................................................................................................................ 22
Perspektywa: Definicja ukończenia......................................................................................................................... 22
Scrum .............................................................................................................................................................................. 22
Kanban ............................................................................................................................................................................ 22
Podsumowanie ............................................................................................................................................................ 23
Perspektywa: Estymacja, planowanie i metryki ................................................................................................ 23
Scrum .............................................................................................................................................................................. 23
Zarządzanie zadaniami ....................................................................................................................................... 23
Estymacja .................................................................................................................................................................. 24
Planowanie sprintu ............................................................................................................................................... 24
Monitorowanie postępu w ramach sprintu ................................................................................................ 25
Planowanie długoterminowe ........................................................................................................................... 25
Długoterminowe monitorowanie postępu ................................................................................................. 26
Kanban ............................................................................................................................................................................ 26
Zarządzanie zadaniami ....................................................................................................................................... 26
Estymacja .................................................................................................................................................................. 27
Monitorowanie postępu ..................................................................................................................................... 27
4
Planowanie ............................................................................................................................................................... 28
Podsumowanie ............................................................................................................................................................ 28
Perspektywa: Adaptacja i organizacja pracy ....................................................................................................... 29
Scrum .............................................................................................................................................................................. 29
Adaptacja produktu i czas odpowiedzi na zmianę .................................................................................. 29
Organizacja pracy i rozwiązywanie problemów ...................................................................................... 30
Adaptacja sposobu pracy mająca na celu jego doskonalenie .............................................................. 30
Kanban ............................................................................................................................................................................ 31
Adaptacja produktu i czas odpowiedzi na zmianę .................................................................................. 31
Organizacja pracy i rozwiązywanie problemów ...................................................................................... 32
Adaptacja procesu ................................................................................................................................................. 32
Podsumowanie ............................................................................................................................................................ 33
Obserwacje ........................................................................................................................................................................ 34
Zespół a proces ............................................................................................................................................................ 34
Subiektywność danych wejściowych adaptacji ............................................................................................. 35
Zróżnicowanie charakteru zadań ........................................................................................................................ 35
Czas odpowiedzi systemu i zadania krytyczne .............................................................................................. 36
Poziom regulowania sposobu wytwarzania produktu i organizacji pracy ........................................ 36
Podsumowanie ................................................................................................................................................................. 38
Bibliografia ........................................................................................................................................................................ 40
5
WSTĘP Wytwarzanie oprogramowania w oparciu o koncepcje Agile Software Development i Lean
Software Development cieszy się na przestrzeni ostatnich lat rosnącą popularnością. Są one
wynikiem poszukiwań efektywnych sposobów wytwarzania i rozwoju systemów
informatycznych, które zostały podjęte ze względu na problemy, z którymi spotykano się
stosując podejścia klasyczne. Szczególnie silnie na poszukiwanie nowych metod wpłynęło
rosnące tempo zmian zachodzących w środowisku biznesowym oraz charakterystyka
innowacyjnych projektów. Nowe metody charakteryzują się odmiennym spojrzeniem na proces
wytwarzania oprogramowania i są aktualnie alternatywą dla klasycznych metod wytwarzania
oprogramowania.
Do najpopularniejszych lekkich technik wykorzystywanych w celu organizacji i wspomagania
procesu wytwarzania oprogramowania należą Scrum i Kanban. Stopień podobieństwa i
zależności pomiędzy tymi metodami rozumiany jest jednak różnie. Postrzegane bywają, jako
dwie delikatnie tylko różniące się odmiany lekkiej koncepcji wytwarzania oprogramowania, jako
kolejne kroki kierujące do celu, jakim jest zwiększanie efektywności i zwinności procesu
wytwarzania oprogramowania, jako osobne koncepcje pozwalające efektywnie organizować
różniące się zadania, lub nawet, jako będące względem siebie w całkowitej opozycji spojrzenia
na zagadnienie organizacji pracy.
Problemy w rozumieniu różnic pomiędzy Scrum i Kanban spowodowane mogą być między
innymi przenikaniem się środowisk stosujących i promujących te koncepcje,
charakterystycznym słownictwem i terminami wykorzystywanymi do ich opisu, pewną liczbą
analogicznych założeń i terminów wykorzystywanych w obu przypadkach, możliwością
wykorzystywania ich w różnych domenach, oraz wreszcie czynnikami społecznymi takimi jak
trendy. Praca ta jest próbą obiektywnego spojrzenia na obie koncepcje, oraz w miarę możliwości
nie emocjonalnego rozważenia podobieństw i różnic, jakie je w rzeczywistości cechują.
INSPIRACJA METOD Zarówno Scrum jak i Kanban oparte są o strategię dostarczania produktu w oparciu o
rzeczywiste zapotrzebowanie (ang. pull strategy). Koncepcje te charakteryzują się także w
pewnym stopniu pobieraniem nowych zadań tylko wtedy, gdy nie spowoduje to przeładowania
opartego o nie systemu, a więc dopiero, gdy istnieje możliwość faktycznego rozpoczęcia pracy.
Ze względu na aspiracje obu metod dotyczące umożliwienia efektywnej pracy w szybko
zmieniającym się środowisku skupiają się one w mniejszym lub większym stopniu na prostocie,
przejrzystości, częstym dostarczaniu małych elementów produktu, oraz adaptacji do
zmieniających się warunków i wymagań. Pozwala to dokonywać częstych i szybkich zmian
zarówno w wytwarzanym produkcie jak i wykorzystywanym w tym celu procesie.
ZARYS METOD Dokonanie sensownej analizy podobieństw i różnic pomiędzy Scrum i Kanban oraz próba
wyciągania na tej podstawie wniosków wymaga określenia poziomu zależności pomiędzy
problemami, które starają się rozwiązać. Pomocne jest także określenie poziomu
6
szczegółowości, jaki zapewniają w konkretnych dziedzinach. Daje to możliwość określenia tego,
co w zasadzie poddane jest porównaniu i wybór odpowiednich perspektyw, które będą w tym
celu wykorzystywane. Inaczej realizowane będzie porównanie łyżki z widelcem w kontekście
spożywania pokarmu, łyżki z widelcem w kontekście wybierania wody z tonącej łodzi, oraz łyżki
ze scyzorykiem szwajcarskim w kontekście naprawy szafki.
SCRUM Scrum definiowany jest jako iteracyjna metodyka, lub z angielskiego framework, prowadzenia
projektów zgodnie z zasadami Agile Software Development których podstawą jest
opublikowany w 2001 roku manifest zwinnego wytwarzania oprogramowania (ang. Agile
Manifesto).
Scrum skupia się mocno na dostarczanym produkcie, bliskiej kooperacji z klientem biznesowym
i zespole, który odpowiada za dostarczenie tego produktu. Organizuje on pracę za pomocą
powtarzających się w równych odstępach czasu, ograniczonych czasowo iteracji zwanych
sprintami. Praca w trakcie sprintów wykonywana jest przez zespół złożony z osób
dysponujących wszystkimi potrzebnymi do dostarczenia produktu umiejętnościami, a więc
mogący składać się z osób o różnych specjalnościach. Zespół ten w każdym sprincie
odpowiedzialny jest za dostarczenie części produktu, do której dostarczenia zobowiązał się
przed jego rozpoczęciem. Realizacja celu sprintu nie jest w żaden sposób regulowana, dzięki
czemu zespół pracuje w warunkach sprzyjających samoorganizacji. Co więcej cel sprintu nie
powinien ulegać zmianie w trakcie jego trwania. Po zakończeniu sprintu stworzony produkt
przedstawiany jest przez zespół klientowi biznesowemu, a zespół dokonuje retrospekcji
dotyczącej sprintu i sposobu pracy.
Sposób realizacji powyższego scenariusza określony jest bardziej szczegółowo w formie zasad
Scrum, których podstawowym zbiorem jest Scrum Guide. Określa on dodatkowo role zespołu
Scrum, o różnych odpowiedzialnościach, spotkania poświęcone odpowiednim zagadnieniom,
oraz opis i sposób wykorzystywania artefaktów związanych z metodyką.
Role definiowane przez Scrum to Scrum Master, Product Owner i zespół. Scrum Master
odpowiedzialny jest za to, aby przestrzegane były zasady Agile Software Development i praca
wykonywana była zgodnie z nimi. Organizuje on także aktywności i pomaga w usuwaniu
problemów. Product Owner stanowi dla zespołu jedno spójne źródło informacji na temat
wymagań i priorytetów związanych z wytwarzaniem produktu. Pozostali członkowie zespołu
Scrum odpowiedzialni są za takie zorganizowanie się w trakcie sprintu, aby zatwierdzona przez
nich praca, wciągnięta do iteracji, została w pełni wykonana.
Scrum określa też spotkania, które powinny się odbywać w trakcie każdej iteracji. Są to, zgodnie
z kolejnością, planowanie zakresu sprintu, planowanie sposobu realizacji pracy, przedstawienie
wykonanej pracy, oraz retrospekcja. Co więcej każdego dnia zespół zobowiązany jest odbyć
krótkie spotkanie kontrolne poświęcone problemom i synchronizacji.
Wszystkie aktywności definiowane przez Scrum począwszy od Sprintu do codziennego
spotkania posiadają maksymalny czas trwania, który nie powinien być przekraczany. Sprint
powinien trwać maksymalnie 4 tygodnie, planowanie 8 godzin, prezentacja i retrospekcja 8
godzin, a spotkanie codzienne 15 minut.
7
Scrum określa sposób zarządzania zadaniami, a w przypadku projektów informatycznych,
wymaganiami. Przewidywane jest użycie rejestru produktu, który zorganizowany jest w postaci
listy priorytetowej, w której elementy o najwyższym priorytecie są wyestymowane przez zespół
i przygotowane do wciągnięcia do iteracji.
Powyższy zarys obrazuje liczbę ograniczeń i zasad wprowadzanych przez Scrum.
W rzeczywistych implementacjach zasady te wzbogacane są o dalsze praktyk i reguły.
Istnieją, na przykład, zalecenia dotyczące sposobu przedstawiania informacji na temat
zaawansowania prac w ramach sprintu, wydania a nawet projektu. Dotyczą one wykorzystania
sprawdzonego w praktyce rozwiązania, jakim są wykresy spalania, obrazujące ilość pracy, jaka
pozostaje do wykonania względem kolejnych dni sprintu, lub kolejnych sprintów w wydaniu.
Wprowadza się także specyficzne mechanizmy estymacji, praktyki techniczne, reguły dotyczące
zadań i wykonanej pracy, czy zasady precyzujące sposobu realizacji pracy w trakcie sprintu.
KANBAN Przedstawienie definicji Kanban nie jest tak proste jak w przypadku Scrum. Problem z
przedstawieniem jednej definicji oparty jest o to, że termin kanban nie jest aktualnie
jednoznaczny.
Słowo kanban pochodzi z języka japońskiego i oznacza tablicę sygnałową. Związane jest ono z
koncepcją produkcji opracowaną w latach pięćdziesiątych w zakładach firmy Toyota, opartą o
wytwarzanie produktu w sposób sterowany zapotrzebowaniem. W celu realizacji tej koncepcji
wykorzystywane są tak zwane karty kanban, które umożliwiają przekazanie informacji o
zapotrzebowaniu z węzłów znajdujących się niżej w łańcuchu produkcyjnym do węzłów
znajdujących się wyżej. Termin kanban lub system kanban wykorzystywany jest także jako
nazwa systemu produkcji opartego o tę koncepcję i wykorzystującego w tym celu karty kanban.
Systemy produkcji oparte o koncepcje wywodzące się z pomysłu firmy Toyota (ang. Toyota
Production System) i kładące nacisk na efektywność zyskiwały na przestrzeni lat rosnącą
popularność. W latach dziewięćdziesiątych koncepcje te stały się znane pod nazwami
odchudzonego wytwarzania (ang. Lean Manufacturing) i odchudzonej produkcji (ang. Lean
Production). Kolejną fazą było adaptowanie tych podejść do domeny wytwarzania
oprogramowania i tym samym określenie koncepcji odchudzonego wytwarzania
oprogramowania (ang. Lean Software Development). Termin ten został rozpropagowany przez
Mary i Toma Poppendieck, którzy opublikowali książkę o tej samej nazwie.
Analiza i adaptacja koncepcji odchudzonej produkcji do domeny systemów informatycznych
wpłynęła naturalnie na zaadoptowanie systemu kanban. Prekursorem i jedną z osób, które
wpłynęły na popularyzację tej koncepcji jest David J. Anderson, który dalej precyzuje definicję
Kanban jako opartą o system kanban metodę stopniowej optymalizacji procesu. Jako metodę
Kanban (ang. Kanban Method) definiuje on z kolei zaawansowany system adaptacyjny, który
cechuje się wizualizacją procesu, ograniczeniem pracy w toku, pomiarem i zarządzaniem
przepływem pracy, określonymi regułami postępowania i wykorzystaniem modeli wprowadzania
zmian w procesie jako narzędzia optymalizacji. David J. Anderson w swojej książce o Kanban
wspomina o modelach opartych o analizę wąskich gardeł, analizę zmienności, oraz analizę ilości
pracy nieprowadzącej do uzyskania wartości biznesowej.
8
W środowisku IT termin Kanban rozumiany jest najczęściej zgodnie z ostatnią przytoczoną
definicją, a więc odpowiada stworzonej przez Andersona koncepcji metody Kanban. Wydaje się,
że jest to też koncepcja najdokładniej zdefiniowana i określająca wszystkie zasadnicze reguły
pozwalające na jej praktyczne wykorzystanie. Na potrzeby tej pracy Kanban rozumiany będzie
właśnie w ten sposób.
Zgodnie z przyjętym rozumieniem, Kanban wykorzystuje narzędzie wizualizacji procesu i
określonych explicite reguł w celu adaptacji i optymalizacji procesu mającą na celu zwiększenie
efektywności pracy. Najczęściej wiąże się on także z wykorzystaniem limitów dotyczących ilości
pracy wykonywanej w kolejnych krokach procesu, ale teoretycznie nie zawsze jest to wymagane.
Oczywiście podobnie jak w przypadku metody Scrum w rzeczywistości podczas
wykorzystywania Kanban stosowane są także liczne inne rozwiązania zwiększające liczbę
ograniczeń i zasad.
Różnice pomiędzy implementacjami Kanban mogą być ogromne, gdyż określa on minimalną
liczbę warunków początkowych. Jeden proces Kanban może opierać się na podziale procesu na
analizę, pracę w toku i pracę wykonaną przy określeniu limitu ilości wykonywanej pracy jedynie
dla stanu praca w toku, podczas gdy inny proces może bardzo szczegółowo odzwierciedlać cały
proces biznesowy przedsiębiorstwa posiadając empirycznie i szczegółowo wyznaczane limity,
klasy zadań, korzystać z technik prognozowania, oraz metryk a jego działanie może być opisane
kontraktami określającymi sposób świadczenia usług.
PODSUMOWANIE Scrum i Kanban są koncepcjami skupionymi w mniejszym lub większym stopniu na
wspomaganiu procesu wytwarzania produktu, poprzez zapewnienie określonej organizacji
sposobu pracy lub samego procesu jej wykonywania, oraz powiązanych z tym zagadnieniach.
Zaznaczyć też trzeba, iż, pomimo, że opracowywane były z myślą o systemach informatycznych,
to ich zastosowanie nie jest ograniczone jedynie do tej domeny.
Scrum określa większą liczbę warunków początkowych związanych z jego wykorzystaniem,
podczas gdy Kanban, nawet przyjmując definicję opartą o metodę Kanban narzuca znacznie
mniej wstępnych ograniczeń. Scrum jest stosunkowo szczegółową receptą dotyczącą organizacji
i prowadzenia projektów IT, podczas gdy Kanban jest metodą pozwalającą w odpowiednim
środowisku taką receptę zdefiniować.
Różnice pomiędzy tym, czym są Scrum i Kanban, oraz fakt, iż wzbogacane są one w najróżniejszy
sposób innymi koncepcjami powoduje, iż nawet po doprecyzowaniu tych bytów, ich porównanie
wiąże się raczej z zestawieniem permutacji koncepcji z permutacją koncepcji. Z tego względu w
kolejnych rozdziałach Scrum i Kanban porównywane będą w oparciu o jedną, konkretną,
perspektywę.
9
PERSPEKTYWA: WDROŻENIE KONCEPCJI
SCRUM Wdrożenie Scrum w zależności od środowiska może wymagać niewielkiego nakładu pracy, lub
znacznego wysiłku i zmian obejmujących bardzo szeroki zakres działalności przedsiębiorstwa.
Ich liczba i zakres zależy od sposobu, w jaki praca wykonywana była wcześniej. W przypadku,
gdy wytwarzanie produktu nie jest objęte szczegółowymi regułami możliwe może być przyjęcie
Scrum oddolnie bez konieczności dokonywania większych zmian. W przypadku procesów ściśle
zdefiniowanych i organizacji operujących w oparciu o skodyfikowane ramy postępowania
konieczne bywa natomiast określenie całego planu zmiany procesu i sposobu zarządzania tą
zmianą.
W obu przypadkach pomocne będzie także poznanie i zrozumienie koncepcji Agile Software
Development. Może to wymagać udziału zespołów produkcyjnych i kierownictwa w szkoleniach
dotyczących tej koncepcji, lub ściągnięcie do firmy osób już biegłych w tej tematyce.
Liczba i zakres koniecznych zmian, a także różnica w sposobie zarządzania zespołem, oraz
ogólnie koncepcji pracy może powodować, iż ich realizacja w niektórych organizacjach spotykać
się może ze znacznym oporem. Jego źródłem może być inercja samej organizacji, jak i dążenia
pojedynczych jej członków.
Z drugiej strony, jeśli już uda się zmian tych dokonać należycie, to konstrukcja Scrum, będąca
dość szczegółową receptą zapewnia możliwość wykorzystania charakterystyki Agile Software
Development. Wpłynąć to może na efektywny rozwój wytwarzanych produktów, zapewniając
możliwość wprowadzania zmian i czerpania korzyści z wytworzonej pracy tak szybko jak jest to
możliwe.
Podsumowując, w celu skorzystania z właściwości Scrum konieczne może być wykonanie
pewnej rewolucji. Uzyskanie tego stanu pozwala jednak nawet zespołom niedoświadczonym w
Agile Software Development, uczących się dopiero samoorganizacji, uzyskiwać niezłe rezultaty
w stosunkowo krótkim czasie. Wynika to z tego, iż Scrum oparty jest o sprawdzoną heurystykę
wytwarzania oprogramowania zgodną z Agile Software Development.
KANBAN Kanban, ze względu na minimalizm wymaganych warunków początkowych, pozwala na
zamodelowanie istniejącego procesu, pozostanie przy zdefiniowanych w organizacji rolach i jego
stopniową empiryczną adaptację opartą o obserwację. Cecha ta powodować może, iż jego
przyjęcie w organizacjach bardziej konserwatywnych lub skupionych na specjalizacji
pracowników, będzie znacznie łatwiejsze niż w przypadku Scrum. Co więcej, adaptacja procesu
w Kanban oparta jest o obserwowane problemy specyficzne dla każdego przypadku. Dzięki temu
zmiana i jej przyczyna może być rozumiana bez konieczności jakichkolwiek szkoleń i wspierana
przez tych, których bezpośrednio dotyka, lub wprowadzana właśnie przez te osoby. Przy
założeniu braku konfliktu interesów wewnątrz przedsiębiorstwa związanych z tą zmianą
przekłada się to na zmniejszenie oporu względem wprowadzanych zmian. Z powodu
wystąpienia wspomnianego konfliktu opór taki jest jednak zawsze możliwy.
10
Niestety niewielka liczba warunków i wymaganych zmian związanych z wykorzystaniem
Kanban, może wpłynąć na niezrozumienie celu Kanban, jakim jest między innymi sterowanie i
wspieranie zmian. Może to skutkować brakiem możliwości ich dokonywania w wyniku czego
proces i organizacja może pozostać w punkcie wyjścia. Podobnie w przypadku, gdy koncepcja
Kanban zostanie zrozumiana i zaakceptowana jedynie przez część organizacji, możliwe jest, iż
zgłaszane propozycje odbierane będą jako problemy wynikające z zastosowania Kanban a nie
jedynie wizualizowane przez to narzędzie.
Kanban można wprowadzić wprowadzając pewną liczbę zmian od razu jak i poprzez stopniową
ewolucję. W obu przypadkach wymagać to może dogłębnego rozumienia celu, do którego się
zmierza, oraz szerokiej akceptacji dążenia do tego celu poprzez wprowadzanie rozmaitych
zmian, a więc dojrzałości pewnej, najczęściej szerokiej, części organizacji.
Kanban, ze względu na praktyczny brak narzucanych z góry ograniczeń, charakteryzuje się
ogromną liczbą możliwości dostrajania, co wpływa także na skomplikowanie jego efektywnego
wykorzystania. Podjęcie decyzji, od czego zacząć i co jest istotne w wielu przypadkach może być
trudne i ze względu na możliwy brak szybkich efektów, widocznych zaraz po rozpoczęciu
korzystania z Kanban, zaowocować porzuceniem tej koncepcji. Pod tym względem Scrum
wydaje się być łatwiejszy we wdrożeniu.
PODSUMOWANIE Perspektywa: Wdrożenie Koncepcji
Scrum Kanban
Przepis na ogólne ramy organizacji pracy oparte o heurystykę.
Przepis na analizowanie i zmianę organizacji pracy.
Wstępne ograniczenia narzucane przez metodę.
Ograniczenia dobierane w trakcie korzystania z metody.
Możliwośd uzyskiwania szybkich rezultatów, przy ograniczonej liczbie decyzji, które trzeba podjąd.
Możliwośd uzyskiwania szybkich rezultatów zależy od wykorzystania. Liczba decyzji, które trzeba podejmowad i opartych o nie działao może byd ogromna.
Dużo zmian wykonuje się już w trakcie wdrażania metody, następnie w trakcie korzystania z metody realizowana jest optymalizacja procesu.
Wdrożenie metody wymaga minimalnej liczby zmian. Większośd modyfikacji ma miejsce w trakcie korzystania z metody.
Średni zakres możliwości dostosowywania do środowiska pracy.
Szeroki zakres możliwości dostosowywania do środowiska pracy.
Proces wdrażania może byd długotrwały. Rozpoczęcie korzystania z Kanban nie wymaga długiego okresu czasu.
PERSPEKTYWA: PODZIAŁ PRACY I OGRANICZENIE PRACY W TOKU Podział pracy na mniejsze części jest jedną z metod pozwalających uprościć wykonanie całości
pracy. Dokonanie umiejętnego podziału umożliwia realizację zadań o mniejszym stopniu
skomplikowania i skupionych na konkretnym zagadnieniu, których realizacja posiada nadal
wartość dla klienta biznesowego.
11
Dostarczanie pracy w postaci mniejszych elementów zapewnia też większy stopień kontroli nad
wytwarzanym produktem. Wynika to z możliwości uzyskiwania informacji zwrotnej opartej o
już istniejące elementy produktu i adaptację zadań w oparciu o te obserwacje. Pośrednio
podejście takie minimalizuje też koszty w przypadku, gdy wykonana praca okazuje się różnić od
rzeczywistych wymagań, lub być oparta o wymagania, które nie są już aktualne.
Podział pracy i dostarczanie jej w postaci mniejszych elementów umożliwia ograniczanie ilości
pracy wykonywanej jednocześnie. Minimalizuje to niekorzystny wpływ związany z
przełączaniem się między zadaniami, skutkuje skupieniem nad aktualnie wykonywaną pracą i
wpływa na skrócenie czasu realizacji zadań.
Poniżej przedstawione jest wykorzystanie koncepcji podziału pracy i ograniczania ilości pracy
wykonywanej jednocześnie w Scrum oraz w Kanban.
SCRUM
PODZIAŁ PRACY Scrum nie określa maksymalnego dopuszczalnego rozmiaru zadania w postaci wielkości
bezwzględnej. Nie ma zasady mówiącej, iż zadanie o złożoności, wyliczonej za pomocą
konkretnej matematycznej metody, jest odpowiednie, lub zbyt złożone.
Wartość określająca czy zadanie jest odpowiedniego rozmiaru jest w Scrum zdefiniowana
pośrednio, poprzez zasady związane z pracą iteracyjną. Najistotniejsza jest w tym przypadku
reguła mówiąca, że zespół powinien być w stanie w pełni zrealizować wszystkie zadania
przyjęte do iteracji. W efekcie maksymalna wielkość zadania, jest wielkością względną,
określoną poprzez złożenie możliwości zespołu i długości iteracji. Same zadania mogą być
różnych rozmiarów, przy założeniu, że zespół będzie w stanie je wszystkie zrealizować w trakcie
iteracji. Zaznaczyć trzeba, że współczynnik, jakim jest czasu trwania iteracji, jest ograniczony.
Scrum określa, że sprint nie powinien trwać dłużej niż cztery tygodnie, a w rzeczywistości często
przyjmuje się okresy dwóch tygodni, czy nawet pojedynczego tygodnia. Drugi czynnik
określający maksymalną wielkość zadań, czyli efektywność zespołu, wyznaczany jest
empirycznie.
Cechy Scrum zapewniają możliwość korzystania z wymienionych wcześniej pozytywnych
efektów związanych z podziałem pracy i ograniczaniem pracy w toku. Wymaga to jednak
odpowiedniego przygotowywania zadań. Konieczne jest dokonywanie podziału w taki sposób,
aby wydzielone części były wartościowe i mogły być zrealizowane w trakcie jednej iteracji, co
wymaga poświęcenia pewnego nakładu pracy i wiąże się z poświęceniem pewnej ilości czasu.
PRACA W TOKU Limit ilości pracy, jaka wykonywana może być jednocześnie, jest w Scrum wyznaczany w
analogiczny sposób jak maksymalny rozmiar zadań. Ilość ta nie powinna przekraczać wartości
wynikającej z efektywności zespołu i czasu trwania iteracji, a więc zapewniać możliwość
realizacji całości tej pracy w trakcie jednego sprintu. Krótsze sprinty skutkują większym
ograniczeniem dotyczącym dopuszczalnej ilości pracy w toku. Jest to jedna z przyczyn, dla
których sprinty są w Scrum często krótsze od maksymalnej dozwolonej długości ich trwania.
12
Iteracyjny model pracy w Scrum ułatwia także empiryczne wyznaczanie limitu pracy w toku. W
przypadku, gdy okazuje się, że zespół nie był w stanie zrealizować wszystkich zadań, konieczne
jest przenalizowanie przyczyn zaistniałej sytuacji, gdyż może to wskazywać, że przyjęta ilość
pracy była zbyt duża. W celu ułatwienia określania odpowiedniej ilości pracy, jaką zespół zdolny
jest wykonać, wykorzystywane mogą być w Scrum techniki planowania oparte o estymację i
dane historyczne. Polegają one na wykorzystaniu miary określającej ilość wyestymowanej pracy,
jaką zespół może być w stanie zrealizować w trakcie sprintu. Miara ta, zwana z angielskiego
Velocity, aktualizowana jest po zakończeniu każdego sprintu, a następnie wykorzystywana w
celu wsparcia procesu planowania kolejnej iteracji.
KANBAN
PODZIAŁ PRACY Kanban nie jest oparty o iteracje i nie posiada w związku z tym ograniczenia analogicznego do
tego, które obecne jest w Scrum. Teoretycznie możliwa jest, więc praca nad zadaniami o
dowolnym rozmiarze. W przypadku takim nie jest konieczne poświęcanie czasu na odpowiedni
podział pracy.
Charakter Kanban związany z wizualizacją procesu i przepływu pracy pozwala jednak na
identyfikację rozmaitych problemów, w tym też takich, które mogą wynikać z pracy nad
zadaniami o zbyt szerokim zakresie. Skutki wprowadzenie takiego zadania do systemu Kanban
widoczne mogą być między innymi poprzez znaczne zwiększenie czasu potrzebnego na
dostarczenie funkcjonalności, oraz zakłócenie pracy nad innymi zadaniami. W efekcie w sytuacji
takiej powinny zostać uruchomione mechanizmy wprowadzania zmian, promowane przez
Kanban jako technikę adaptacji. W przypadku, gdy czas realizacji zadania okazuje się zbyt długi i
wynika to z szerokości jego zakresu, możliwe jest przyjęcie odpowiednich reguł mających na
celu zapobieganie dostrzeżonym problemom w przyszłości. Jednym z takich rozwiązań mogłoby
być określenie maksymalnej dopuszczalnej wielkości zadań, a więc poświęcanie pewnej ilości
czasu na wstępną analizę zadań i w razie konieczności ich podział.
Istotną cechą takiego podejścia jest jednak fakt, iż ograniczenia dopasowane są do charakteru
zadania, środowiska i zespołu. Czynniki te wpływają bowiem na to czy dane zadanie będzie
powodem zakłóceń w pracy czy też nie.
W rzeczywistości korzystając z Kanban i będąc świadomym zjawiska związanego z
wprowadzaniem do systemu zadań znacznie odbiegających od przeciętnego rozmiaru
zabezpieczyć się można poprzez odgórne ustalenie ograniczeń dotyczących rozmiaru
przyjmowanych zadań i poddawaniu ich empirycznej weryfikacji. Wymaga to oczywiście
poświęcenia pewnej ilości czasu na analizę zadań poprzedzającą wprowadzanie ich do systemu.
PRACA W TOKU Ograniczanie pracy w toku jest jednym z centralnych założeń metody Kanban. Jest ona ściśle
kontrolowana poprzez wizualizację pracy i nakładanie limitów określających maksymalną liczbę
zadań dla kolejnych stanów procesu, przez które zadania muszą przejść. Jest to podstawowe
narzędzie wykorzystywane w celu optymalizacji procesu. Umożliwia ono adaptację procesu w
taki sposób, aby czas jego odpowiedzi a więc też czas realizacji zadań był odpowiednio krótki.
13
Wprowadzenie limitów ułatwia identyfikację problemów i wąskich gardeł. W przypadku
zastosowania limitów, omawiany wcześniej problem dotyczący wprowadzenia zadania o bardzo
szerokim zakresie, wpłynąłby na ograniczenie przepustowości pewnego kroku w procesie i
gromadzenie się zadań w krokach poprzedzających, co byłoby widocznym wskaźnikiem
zaistnienia jakiegoś problemu.
Limity i inne ograniczenia Kanban wyznaczane mogą być empirycznie podczas pracy i oparte o
rzeczywiste wymagania. W efekcie zdarza się, iż proces oraz limity zadań dla poszczególnych
jego faz definiowane są bardzo dokładnie. Wprowadzane mogą być też klasy usług, do których
część zespołu może być przypisana lub zadania o różnych priorytetach.
PODSUMOWANIE Perspektywa: Podział pracy i ograniczenie pracy w toku
Scrum Kanban
Wymuszenie pewnego stopnia granulacji zadao pracy przez metodę
Zadania mogą byd dowolnej wielkości
Koniecznośd podziału pracy do pewnej granularności
Koniecznośd uczenia się, jaki jest odpowiedni rozmiar zadao, aby nie wpływał negatywnie na pracę
Ograniczenia jako przepis oparty o heurystykę
Koniecznośd wyznaczania efektywnych ograniczeo
Wpływ wielkości zadao na pracę średnio widoczny
Wpływ wielkości zadao na pracę wysoce widoczny
Adaptacja oparta o uwagi zespołu i ilośd wykonywanej pracy w trakcie iteracji.
Adaptacja oparta o ograniczanie pracy w toku i obserwację problemów.
PERSPEKTYWA: SPOSÓB PRACY
SCRUM – PRACA ITERACYJNA Jedną z najistotniejszych cech Scrum jest ściśle iteracyjny sposób pracy. W trakcie każdej z nich
zespół zobowiązany jest do realizacji pewnych określonych aktywności.
Pierwszego dnia sprintu odbywa się spotkanie dedykowane zaplanowaniu zakresu pracy.
Podczas tego spotkania zespół ustala z właścicielem produktu cel sprintu i wybierane są
zadania, które zespół obliguje się zrealizować. W drugiej części spotkania zespół może bardziej
szczegółowo omówić sposób realizacji wybranych zadań.
Każdego dnia iteracji odbywa się spotkanie poświęcone empirycznej kontroli pracy. Jego celem
jest analiza postępu, sygnalizowanie problemów, synchronizacja pracy i kierunkowanie zespołu
na samoorganizację.
Ostatniego dnia iteracji odbywa się spotkanie podsumowujące sprint. Zasadniczym celem tego
spotkania jest kontrola rozwoju projektu i sterowanie jego kierunkiem. Podczas tego spotkania
zespół przedstawia właścicielowi produktu zrealizowaną funkcjonalność. Właściciel produktu
może zorientować się czy funkcjonalność ta odpowiada jego wyobrażeniu, czy też konieczne są
modyfikacje, lub zmiana kierunku prowadzenia prac. Właściciel produktu dostarcza też
informacji zwrotnej mogącej być wskazówkami dla zespołu, pozwalającymi zwiększyć stopień
14
samoorganizacji zespołu poprzez zapewnienie dostępu do informacji umożliwiającej mu
podejmowanie odpowiednich decyzji w sytuacjach niejednoznacznych.
Ostatniego dnia odbywa się także spotkanie podsumowujące pracę w sprincie. Podczas tego
spotkania zespół omawia problemy, jakie napotkane zostały w czasie pracy, pomysły na ich
rozwiązanie, oraz inne pomysły dotyczące adaptacji sposobu pracy. Kontrolowany jest także
wpływ podjętych wcześniej decyzji, oraz stopień wdrożenia omawianych koncepcji.
RYTM Metoda Scrum wprowadza ściśle określony rytm pracy. Wszystkie spotkania odbywają się w
stałych odstępach czasu. W przypadku iteracji trwającej dwa tygodnie spotkania planowania,
podsumowujące efekt i podsumowujące pracę odbywają się co dwa tygodnie.
Umożliwia to ustalenie powtarzającego się planu spotkań z wszystkimi osobami, które powinny
w nich uczestniczyć. Jest to często znacznie łatwiejsze niż zwoływania takich spotkań ad-hoc, lub
w różnych terminach co iterację. Rytm ten ma także wpływ na zespół, który przyzwyczaja się do
niego i jest pewien realizacji okresowych aktywności.
Powiązanie okresu tych spotkań nie zawsze może być jednak optymalne. Przykładowo nie
zawsze praca, dostarczana przez zespół w trakcie sprintu obejmować będzie całość, którą
właściciel produktu będzie chciał wykorzystać. Czasem może być potrzebna więcej niż jedna
iteracja, aby sensowne było wydanie zmian. Z drugiej strony zapewnia to postępującą kontrolę
kierunku prac.
SKUPIENIE NA CELU Podział czasu na okresy iteracji zapewnia możliwość zdefiniowania celu, jaki zespół powinien
osiągnąć w tym czasie i na którym powinien się skupić. Stanowi to dodatkową informację
pozwalającą na lepszą samoorganizację zespołu w trakcie sprintu. Przynosi to też korzyść w
postaci świadomości zespołu, jaki jest kierunek rozwoju produktu. W przypadku jakichkolwiek
problemów zespół podejmować może decyzje, które skutkować będą zmierzaniem do tego celu.
Istnienie i świadomość celu pozwala także odblokować kreatywność zespołu i dostarczać
rozwiązania, które w danym momencie najbardziej odpowiadają potrzebą biznesu w oparciu o
możliwości zespołu. Dzięki temu cel biznesowy może zostać zrealizowany nawet poprzez pewną
zmianę zakresu sprintu.
Scrum zakłada niezmienność zakresu prac prowadzonych w trakcie iteracji, co w założeniu ma
pozwolić zespołowi w pełni skupić się nad celem iteracji i realizacją zadań. Zapobiega to
niekorzystnemu zjawisku, jakim jest przełączanie się pomiędzy zadaniami. Nie jest konieczne
odrywanie się od aktualnie realizowanych zadań, które otrzymały przecież najwyższy priorytet,
i w efekcie zmniejszanie efektywności pracy. W przypadkach, gdy zmiana kierunku prac jest
rzeczywiście wymagana właściciel produktu dysponuje możliwością anulowania sprintu. Wiąże
się to jednak z brakiem konieczności dostarczenie zrealizowanej w trakcie tej iteracji pracy i
powoduje, iż decyzja taka podejmowana jest rzeczywiście jedynie w uzasadnionych
przypadkach. Zasada ta wpływa jednak oczywiście na określenie czasu odpowiedzi systemu na
poziomie czasu trwania iteracji.
15
GWARANCJA REALIZACJI AKTYWNOŚCI Wpisanie spotkań metodyki Scrum w rytm iteracji gwarantuje ich realizację, a więc pośrednio
możliwość kontrolowania rozwoju produktu, synchronizowania pracy, omawiania problemów i
poszukiwania ich rozwiązań. W przypadku, gdyby aktywności te nie były wpisane w
harmonogram prac, wiele zespołów mogłoby ich nie realizować. Dotyczy to szczególnie
zespołów niedoświadczonych i nie świadomych wszystkich aspektów aktywności. Konieczność
odbywania tych spotkań skutkuje nabywaniem doświadczenie i nauką samoorganizacji w
przypadku zespołów wkraczających dopiero w świat zwinnego rozwoju oprogramowania.
GWARANCJA CZĘSTEGO ODBIORU PRACY Stały okres odbioru efektów pracy wykonanej umożliwia monitorowanie postępu prac, oraz
sterowanie rozwojem produktu w oparciu o dostarczane elementy produktu. Zapewnia to
możliwość wprowadzania zmian wynikających ze stanu istniejącego już produktu. Co więcej
okresowy odbiór pracy stanowi element zarządzania ryzykiem. Sytuacja, w której zespół nie jest
w stanie dostarczyć funkcjonalności w trakcie kilku krótkich iteracji może być sygnałem
alarmowym świadczącym o braku możliwości realizacji projektu w istniejących warunkach. Co
istotne informacja ta generowana jest szybko i często. Już pierwsza iteracji pozwala uzyskać
pewne informacje, które aktualizowaną są po zakończenie każdego kolejnego sprintu. Pozwala
to podejmować decyzje mogące zminimalizować straty finansowe, poprzez na przykład
zamknięcie projektu, lub wpłynąć na zmianę środowiska pracy, poprzez na przykład
przydzielenie zespołowi testerów.
Stały okres odbioru efektów pracy wykonanej podczas iteracji nie tylko umożliwia sterowanie
rozwojem produktu, ale wpływa też pozytywnie na motywację zespołu. Sytuacją idealną jest
wdrażanie wytworzonego produktu do użycia i otrzymywanie informacji zwrotnych na ten
temat. Jeśli nie jest to możliwe to nawet prezentacja wykonanej pracy skutkuje poczuciem
satysfakcji zespołu. Istotą jest świadomość zapotrzebowania na produkt i fakt, iż odpowiada on
wymaganiom klienta. Stały okres przekazywania wytworzonego produktu wpływa też na
budowanie zaufania pomiędzy klientem biznesowym a zespołem.
ZAANGAŻOWANIE CZŁONKÓW ZESPOŁU W AKTYWNOŚCI W Scrum wszyscy członkowie zespołu, niezależnie od specjalizacji biorą czynny udział we
wszystkich aktywnościach. Powoduje to konieczność brania udziału w aktywnościach członków
zespołu, którzy mogą się w nie nie angażować, i niebędących aktywnymi, którzy czas ten
mogliby poświęcić na inne zadania. Jest to jednak rozwiązanie celowe. Zgodnie z założeniami
Agile Software Development, cały zespół ma pracować jako jedna drużyna i angażować się we
wszystkie aktywności. Skutkuje to spójnym stanem wiedzy całego zespołu na temat kierunku
rozwoju produktu i ewentualnych problemach. Świadomość celu projektu i wiedza o
możliwościach wpływania na jego realizację dostępna jest wszystkim członkom zespołu.
Środowisko takie sprzyja aktywnemu współudziałowi wszystkich członków zespołu w procesie
tworzenia produktu oraz przejmowanie zadań w przypadku zaistnienia takiej konieczności.
POZIOM WYKORZYSTANIA MOŻLIWOŚCI ZESPOŁU Praca oparta o wiele, następujących po sobie iteracji, podczas których za każdym razem stan
początkowy zdefiniowany jest przez pewną liczbę nierozpoczętych zadań, następnie zadania te
są w coraz większym stopniu wykonywane, a finalnie wszystkie zadania są wykonane, cechuje
się trudnością z wykorzystywaniem pełni możliwości zespołu. Zjawisko to jest szczególnie silne
16
w przypadku zespołów składających się ze specjalistów zajmujących się konkretnymi
dziedzinami. Na początku iteracji trudno jest wykonywać działania wymagające wykonania
wcześniej innych działań. Przykładem takiego działania jest testowanie. Wymaga ono istnienia
produktu, który ma być poddany testowaniu. Podobnie wraz ze zbliżaniem się końca iteracji
zmniejsza się liczba działań będących działaniami pierwszymi. Zjawisko to jest uzależnione od
granulacji zadań w sprincie, specjalizacji zespołu i sposobu pracy. Niezmiennie jednak w
mniejszym lub większym stopniu cechuje ono iteracyjny model pracy.
Pewną analogią pozwalającą zobrazować ten sposób pracy jest realizacja wielu następujących po
sobie cykli Kanban bez limitowania liczby zadań w kolejnych stanach procesu. Możliwym
skutkiem tego modelu pracy jest realizacja zadań w taki sposób, że są stają się one w pełni
ukończone i wartościowe dopiero pod koniec sprintu. Zjawisko to nazywane bywa z
angielskiego scrumfall ze względu na podobieństwo do realizacji pracy w modelu waterfall,
gdzie wartość uzyskiwana jest dopiero pod koniec projektu. Ze względu na ograniczenie czasu
trwania iteracji skutki tej sytuacji w Scrum są jednak znacznie mniej kosztowne. W przypadku
takim jednak ilość pracy w toku zbliżać się może do całości pracy zaplanowanej na iterację.
Typowym wskaźnikiem istnienia tego problemu jest sytuacja, w której sprinty kończą się często
nie ukończeniem znacznej części zaplanowanych zadań przy jednoczesnym rozpoczęciu pracy
nad większością zadań. Zespoły Scrum w ramach samoorganizacji mogą ograniczać to zjawisko
nawet bez konieczności określania procesu i definiowania limitów a jedynie poprzez
odpowiednią organizację pracy ograniczając pracę w toku.
CZAS NIE W PEŁNI WYKORZYSTANY W SZERSZEJ PERSPEKTYWIE Na wspomniane wcześniej niepełne wykorzystanie możliwości zespołu przy pracy za pomocą
metody Scrum można spojrzeć także, jako zapewnienie niezbędnego zapasu czasu potrzebnego
na rozwój zespołu zarówno pod względem technicznym jak i organizacyjnym. Nie
wykorzystywanie zespołu w pełni do budowania funkcjonalności może, więc w efekcie okazać
się cechą pozytywną, wpływającą na wykorzystanie lepszych rozwiązań technicznych, czy
prezentację wartościowych sugestii dotyczących kierunku rozwoju produktu. Efektywna
adaptacja sposobu pracy także wymaga zapewnienia pewnej ilości czasu w trakcie, którego
zespół może analizować aktualne podejście.
EFEKT ŚCIŚLE OKREŚLONEGO ZAKRESU PRACY I CZASU PRACY. Zobligowanie się zespołu do dostarczenia pracy przyjętej do iteracji wpływa na wysoką
motywację ukierunkowaną na osiągnięcie celu, efektywną pracę oraz zespołowe rozwiązywanie
problemów, które mogą stać na drodze do jego osiągnięcia.
Cecha ta może mieć też w określonych przypadkach specyficzne efekty uboczne. Poziom ich
występowania zależny jest od restrykcyjności środowiska związanej z ewentualnym nie
wykonaniem całości pracy składającej się na iterację. W środowiskach penalizujących takie
sytuacje możliwe jest występowanie efektu polegającego na dostarczeniu produktu o niskiej
jakości. Skutkuje to wprowadzeniem długu technologicznego, który z dużym
prawdopodobieństwem spłacić trzeba będzie w przyszłości z odsetkami, a więc poświęcając
więcej czasu, niż zaoszczędzono. Barry Boehm stwierdził, że poprawienie błędu, który miał
miejsce na początku projektu, może kosztować 50 do 1000 razy pod koniec projektu, w
porównaniu z kosztami jego poprawienia mniej więcej w czasie, gdy został popełniony.
Wprowadzanie długu technologicznego jest to sprzeczne z koncepcją Agile Software
17
Development, która zakłada konieczność wytwarzania produktu o wysokiej jakości. To
niekorzystne zjawisko przybiera na sile także w sytuacji, gdy liczba zadań w iteracji ma
tendencję do przekraczania rzeczywistych możliwości zespołu, co jest stosunkowo częstym
zjawiskiem w przypadku oparcia procesu planowania jedynie o miarę „velocity” przy
jednoczesnym niewłaściwym jej wyznaczaniu.
Istotne jest też pytanie jak długo zespół może podejmować wyzwanie mierzenia się z kolejnym
sprintem. Czy możliwe jest spełnienie przy takim sposobie pracy założenia o utrzymaniu
wydajności w dowolnie odległej perspektywie? Przeformowując to pytanie można spytać czy
zespół może przebiec maraton składający się z biegów sprinterskich. Odpowiedź zależy od
stopnia eksploatacji zawodników w trakcie tych biegów. Jeśli jest to rzeczywiście bieg
sprinterski to przebiegnięcie maratonu raczej nie będzie możliwe. Obserwując rzeczywiste
implementacje wydaje się, że niestety nawet zespół odpowiedzialny za realizację zadań często
nieświadomie dąży do eksploatacji swoich możliwości ponad miarę w trakcie sprintów.
Zjawisku temu w Scrum zapobiegać ma Scrum Master.
KANBAN – PRACA CIĄGŁA Kanban oparty jest o model pracy ciągłej, w którym gotowe zadania pobierane są płynnie do
kolejnych faz procesu, gdy pojawia się możliwość rozpoczęcia nad nimi pracy. Elementem
regulującym przepływ zadań są limity pracy w toku zdefiniowane dla kolejnych faz procesu. Gdy
liczba zadań w danej fazie jest mniejsza od zdefiniowanego dla niej limitu i istnieje gotowe do
pobrania zadanie w fazie poprzedniej, możliwe jest wciągnięcie go do fazy kolejnej.
Kanban nie definiuje aktywności poświęconych realizacji określonych celów tak jak Scrum.
Wymaga jednak, spełnienia pewnych wymagań. Należą do nich wizualizacja procesu,
ograniczanie pracy w toku, zarządzanie i pomiar przepływającej przez system pracy,
dokonywania analizy mającej na celu identyfikację możliwości zwiększenia efektywności
procesu, oraz definiowania reguł wynikających z tej analizy. Szczegóły dotyczące realizacji tych
wymagań mogą się różnić w przypadku różnych implementacji Kanban.
ASYNCHRONICZNOŚĆ Model pracy ciągłej w Kanban skutkuje brakiem konieczności powiązania częstotliwości
realizacji aktywności. Zapewnia to możliwość pełnego dopasowania częstotliwości każdej z
aktywności z osobna do specyfiki pracy.
Aktywnościami, które odbywać się mogą w ramach Kanban są aktualizacja i uzupełnianie kolejki
wejściowej procesu, oraz prezentacja i oddawanie wytworzonego produktu. Charakter Kanban
pozwala na to, aby aktywności te odbywały się zarówno ad-hoc, w momencie, gdy pojawia się
taka konieczność, jak i okresowo. Możliwe jest też przyjęcie rozwiązania mieszanego, w którym
część aktywności jest okresowa a część odbywa się ad-hoc. Co więcej, przypadku przyjęcia
rozwiązania okresowego, częstotliwość odbywania się różnych spotkań nie musi być jednakowa.
W efekcie stan kolejki może być aktualizowany raz w tygodniu a produkt może być oddawany
ad-hoc, stan kolejki może być aktualizowany dwa razy w tygodniu a produkt może być
oddawany raz w miesiącu, itd.
Możliwość ta pozwala na dopasowanie specyfiki procesu do środowiska pracy, co przekładać się
może na efektywność finansową. Trzeba tu jednak zachować ostrożność, gdyż możliwość ta
18
pozwala łamać zasadę szybkiego dostarczania wytwarzanej pracy, co może doprowadzić do
problemów z wdrożeniem, kontrolą rozwoju produktu itd.
CZAS ODPOWIEDZI NA ZMIANY Kanban nie określa ograniczeń dotyczących wprowadzania zmian do zakresu prac tak jak dzieje
się to w Scrum w czasie sprintu.
Teoretycznie możliwe jest modyfikowanie kolejki wejściowej w dowolnym momencie, co
pozwala reagować na zmiany szybciej niż w przypadku Scrum. Korzyść z możliwości
wprowadzania takich zmian zależeć będzie jednak od charakteru procesu. Na przykład w
przypadku realizacji powtarzalnych zadań niewymagających dodatkowej pracy związanej z ich
wprowadzaniem do procesu może być to rozwiązanie korzystne. W przypadku konieczności
zmiany kontekstu przez zespół na pracę związaną z doprecyzowaniem zadania, zdobywaniem
informacji o wymaganiach i dokonania klasyfikacja rozwiązanie takie może okazać się jednak nie
korzystne.
Kanban nie określa też reguł uniemożliwiających wstrzymywanie aktualnie realizowanych
zadań i rozpoczynania pracy nad nowymi o wyższym priorytecie. Sytuacje takie obsługiwane są
najczęściej poprzez definiowanie klas zadań o różnych priorytetach i definiowanie reguł
dotyczących działania w takich sytuacjach. Jeśli, na przykład, w kolejce pojawia się zadanie o
wysokim priorytecie, może być ono automatycznie wciągane do pierwszej fazy procesu a inne
zadania w tej fazie mogą być wstrzymywane. Skutkuje to jednak możliwym do zaobserwowania
opóźnieniem innych zadań i zakłóceniem przepływu. Rozwiązanie to jest jeszcze bardziej
problematyczne niż opisane powyżej i korzyść z jego przyjęcia ponownie zależy od specyfiki
procesu. Rozwiązanie takie wprowadza też dalsze komplikacje. Konieczne może być określenie
limitu dotyczącego takich zadań o wysokim priorytecie w celu zapewnienia, iż przepływ nie
zostanie całkowicie przez nie wstrzymany, lub zabezpieczenie dedykowanego bufora
wydajności dla takich zadań Drugie z opisanych rozwiązań umożliwia zapewnienie poziomu obsługi
dla takich wysoce priorytetowych zadań, przy czym jeśli się one nie pojawiają to system operuje
poniżej swoich rzeczywistych możliwości.
PRACA AD-HOC Acykliczność Kanban pozwala na minimalizację czasu odpowiedzi systemu poprzez realizację
zadań w pełni w trybie ad-hoc. W sytuacji takiej nowa praca pobierana jest jak tylko pojawia się
możliwość pracy nad kolejnym zadaniem, a w momencie, gdy zadanie trafia do ostatniej fazy
procesu następuje wydanie produktu.
Taki sposób pracy wymaga jednak dojrzałości organizacji i odpowiadającego jej środowiska
projektu. Wymagana tu może być pełne ukierunkowanie na projekt wszystkich
współpracujących stron. Na przykład w momencie pobierania pracy, czy jej wydawania
konieczna jest dostępność wszystkich potrzebnych do tego osób.
Korzyścią, jaka płynie z takiego sposobu pracy jest minimalny czas odpowiedzi systemu.
Sterowanie kierunkiem pracy poprzez wybór zadań następuje na bieżąco. Podobnie wytwarzana
praca dostarczana jest na bieżąco, co pozwala czerpać z niej natychmiastowe korzyści. Może to
w niektórych przypadkach prowadzić do możliwości uzyskania przewagi konkurencyjnej.
19
MOŻLIWOŚĆ PEŁNEGO WYKORZYSTANIA SPECJALISTÓW Szczegółowa definicja procesu w Kanban i wynikający z niej podział na ściśle określone
aktywności umożliwia specjalistom skupienie się tylko na fazach, za które odpowiadają i w
dziedzinie, których ich wydajność jest największa. Nie istnieje konieczność brania przez nich
udziału w aktywnościach, które ich nie dotyczą lub pozyskiwania wiedzy związanej z
zagadnieniami pośrednio jedynie ich dotyczącymi.
Zaznaczyć trzeba, że ponownie korzyść z takiej organizacji pracy zależeć będzie od specyfiki
pracy, organizacji i zespołu. W niektórych przypadkach rozwiązanie takie może okazać się nie
efektywne. Zaznaczyć trzeba, że pomimo możliwości pracy specjalistów niejako w oderwaniu od
siebie, to David J. Anderson postuluje realizować tak zwany „swarming”, czyli wspólną analizę
występujących problemów, wizualizowanych na tablicy. Koncepcja ta pozwala spojrzeć na
zagadnienie z różnych stron i wypracowanie rozwiązania opartego o wiedzę wszystkich
specjalistów pracujących w procesie.
PEŁNE WYKORZYSTANIE MOŻLIWOŚCI ZESPOŁU Praca ciągła umożliwia uzyskanie pewnej równowagi dotyczącej pracy, która obecna jest stale w
systemie poprzez operowanie limitami, składem zespołu czy podziałem na klasy zadań. Dzięki
temu wysiłek zespołu jest bardziej równomierny niż w przypadku pracy opartej o powtarzające
się iteracje. W przypadku dobrej organizacji pracy pozwolić to może na pełniejsze
wykorzystanie możliwości zespołu. Pamiętać jednak trzeba, iż pozostawienie członkom zespołu
bufora umożliwiającego rozwój, oraz analizę procesu także przynosi korzyści.
UTRZYMANIE WYDAJNOŚCI ZESPOŁU W DALSZEJ PERSPEKTYWIE Praca oparta o płynne pobieranie nowych zadań, charakteryzować się może mniejszą tendencją
do nadmiernej eksploatacji zespołu, względem pracy opartej o powtarzające się sprinty.
Odpowiedni poziom pracy jest z kolei kluczowym aspektem utrzymania wysokiej efektywności
w dalszej perspektywie. W innym przypadku dochodzi do wprowadzania długu
technologicznego i/lub wypalenia członków zespołu. W Scrum zapewnienie odpowiedniego
poziomu pracy wymaga poprawnego zarządzania planowaniem i pomiarem pracy, co niestety
często nie jest wykonywane prawidłowo. W Kanban zabezpieczenie przed przeładowaniem
systemu jest łatwiejsze i pewniejsze, przy czym pamiętać trzeba, iż wymaga to pewnej
dojrzałości zarówno zespołu jak i jego otoczenia.
EFEKT BRAKU OGRANICZENIA CZASOWEGO, KONKRETNEGO CELU I SKUPIENIA NA
SPECJALIZACJI Kanban nie posiada ograniczenia czasowego dotyczącego realizacji pracy analogicznego do
czasu trwania sprintu w Scrum. Specyfika ta może w niektórych przypadkach skutkować niską
wydajnością zespołu lub wykonywaniem dodatkowej, niezaplanowanej pracy. Wymaganie
dotyczące automotywacji i odpowiedzialności zespołu jest więc w Kanban szczególnie istotne.
Pomiar pracy, będący jednym z wymagań Kanban, może służyć w celu wykrywania takich
przypadków. W oparciu o statystykę czasu wykonywania podobnych zadań w przeszłości
zadania opóźniające się względem tej miary mogą być bardziej szczegółowo analizowane.
Podobnie jednak jak w przypadku efektów ubocznych Scrum tu też pamiętać trzeba, iż każdy
pomiar wpływa na zmienię procesu. Nadmierna restrykcyjność związana z opóźniającym się
zadaniem może odnieść niespodziewane negatywne skutki. Wykonywana praca może być
20
niskiej jakości, zmianie może ulec estymacja zadań i nie odpowiadać rzeczywistości, lub nawet
zadania mogą być minimalnie opóźniane w celu zmiany średniej miary czasu ukończenia
zadania.
Brak cykli ukierunkowanych na osiągnięcie konkretnego celu utrudnia podejmowania decyzji ze
względu na możliwość braku dostępu do takiej informacji. Ogranicza to prawdopodobieństwo
podejmowania właściwych decyzji przez zespół w sytuacjach niejednoznacznych a więc
poniekąd stopień samoorganizacji. Informacje takie mogą być dostarczane w inny sposób niż ma
to miejsce w Scrum, metoda Kanban tego jednak nie wymaga, co skutkuje koniecznością
ewentualnej identyfikacji i rozwiązania tego problemu w trakcie pracy.
Podkreślić też trzeba, iż nadmierna specjalizacja podgrup tworzących zespół i ich skupienie
jedynie na sprawach bezpośrednio ich dotyczących może doprowadzić do utracenia szerszej
perspektywy, co także może odbić się negatywnie na pracy, poprzez na przykład implementację
funkcjonalności niezgodnie z wymaganiami lub zgodnie z wymaganiami, ale niespełniającej swej
funkcji.
PODSUMOWANIE Perspektywa: Sposób pracy
Scrum Kanban
Rytmicznośd pracy Płynnośd pracy
Synchronizacja aktywności Aktywności mogą byd synchroniczne lub asynchroniczne
Skupienie na celu, minimalizacja przełączania pomiędzy zadaniami
Niski czas odpowiedzi systemu na zmiany
Pewnośd realizacji aktywności związanych z Agile Software Development
Możliwośd doboru czynności dopasowanych do środowiska
Pełne zaangażowanie zespołu w projekt, wiedza ogólna i współodpowiedzialnośd
Możliwośd pełnego wykorzystania specjalistów i wiedza specjalistycznej
Trudnośd w pełnym wykorzystaniu zespołu ze względu na skokowy sposób pracy
Możliwośd pełnego wykorzystania zespołu ze względu na płynny sposób pracy
Niebezpieczeostwo przeładowania poprzez stosowanie źle wyznaczanych miar podczas planowania i penalizacji związanej z niedostarczeniem funkcjonalności
Niebezpieczeostwo przeładowania poprzez nadmierną optymalizację wykorzystania zespołu i restrykcyjności związanej z niedostarczeniem funkcjonalności
Utrzymanie wydajności zespołu w dalszej perspektywie wymaga znacznego doświadczenia.
Utrzymanie wydajności zespołu w dalszej perspektywie wymaga mniejszego doświadczenia.
PERSPEKTYWA: DEFINICJA GOTOWOŚCI Definicja gotowości określa warunki, jakie spełnić musi zadanie, aby można było rozpocząć jego
realizację.
SCRUM Wymagania Scrum dotyczące przyjmowanych do realizacji zadań zdefiniowane są stosunkowo
ogólnie. Mówią one, że zespół powinien w pełni rozumieć zakres i cel tych zadań. Celem tych
wymagań jest zapewnienie możliwości efektywnej pracy zespołu w trakcie iteracji. Zadania,
21
których zakres nie jest zdefiniowany, lub zadania o niejednoznacznym celu nie powinny być
pobierane do sprintu dopóki nie zostaną doprecyzowane. Dzięki temu, w trakcie iteracji, zespół
może się w pełni skoncentrować na wykonywaniu pracy. Ograniczona jest konieczność
przełączania się pomiędzy zadaniami i możliwość wykonania pracy niestanowiącej wartości dla
klienta.
Realizacji zadania w Scrum wynika z wspólnej decyzji właściciela produktu i zespołu. Umożliwia
to właścicielowi produktu możliwość wykorzystania wiedzy i pomysłów pozostałych członków
zespołu, dotyczących zarówno biznesu jak i zależności technicznych. Koncepcja ta wiąże się
także z faktem zobowiązania się przez zespół do zrealizowania takiego zadania, co wpływa
pozytywnie na motywację i stopień precyzji zadań przyjmowanych do iteracji. Nie jest możliwe
narzucenie zespołowi zadania niejednoznacznego czy zadania o zbyt szerokim zakresie, co
mogłoby mieć niekorzystne skutki zarówno dla zespołu jak i klienta.
Zespoły Scrum uzgadniają często bardziej szczegółową definicję gotowości zadania.
Odpowiednio dobrana ułatwia ona właścicielowi produktu i zespołowi organizację pracy.
Zadania wymagające doprecyzowania i uzupełnienia brakujących informacji nie spełniają tej
definicji i mogą być oznaczane w wybrany sposób. Często definicja gotowości wymaga
zdefiniowania przypadku testowego, który z jednej strony czytelnie obrazuje cel zadania a z
drugiej umożliwia oparcie o niego rzeczywistego przypadku testowego, który pozwala
stwierdzić czy implementacja zgodna jest z wymaganiami.
Scrum nie wymaga korzystania z omówionej powyżej szczegółowej definicji gotowości. Oparty
jest on o koncepcję Agile Manifesto, która mówi, iż osoby i interakcja pomiędzy nimi są
istotniejsze niż procesy i narzędzia. Zgodnie z tą koncepcją zauważyć można pewne negatywne
aspekty związane z wprowadzaniem szczegółowej definicji gotowości. Przeniesienie uwagi z
interakcji na tworzenie specyfikacji może skutkować dostarczeniem produktu w pełni zgodnego
z opisanymi wymaganiami i spełniającego warunki testowe, ale nieodpowiadającego potrzebie
klienta i niestanowiącego dla niego wartości. Wynikać to może z wielu czynników takich jak
brak rozumienia kierunku rozwoju produktu, czy zmniejszeniem poczucia odpowiedzialności
zespołu za produkt.
KANBAN Formalnie sam Kanban nie nakłada na zadania wchodzące do systemu żadnych warunków.
Ewentualne ograniczenia i zasady dotyczące tej kwestii opracowane być mogą w oparciu o
analizę procesu i przepływu pracy, dzięki czemu mogą być dopasowane do specyfiki procesu.
Oznacza to też, że zadania mogą być przyjmowane bez udziału całości zespołu, stopień ich
precyzji może być różny, a informacja na temat wymagań może być dostępna tylko pewnej
grupie osób.
Samo tworzenie zadań może w Kanban przebiegać całkiem inaczej niż w Scrum. Zadania
interesujące dany podzespół mogą być na przykład wciągane z wcześniejszych faz procesu
Kanban, gdzie stany procesu mogą określać wytwarzanie potrzebnych dalej informacji. Mogą
być też tworzone podobnie jak ma to miejsce w Scrum.
22
PODSUMOWANIE Perspektywa: Definicja gotowości
Scrum Kanban
Heurystycznie nałożone ogólne warunki na zadania.
Przyjęcie lub nie jakichkolwiek warunków opcjonalne.
Zapewnienie partycypacji całego zespołu w procesie określania celu iteracji i wyborze zadao.
Zadania mogą byd narzucane, precyzowane w ramach kroków procesu, dobierane jak w Scrum, lub w dowolny inny sposób.
Cały zespół powinien rozumied zadania. Wiedza na temat zadao może byd jedynie konieczna dla osób pracujących bezpośrednio nad pierwszym krokiem w procesie, do którego one trafią.
PERSPEKTYWA: DEFINICJA UKOŃCZENIA Definicja ukończenia określa warunki, jakie muszą być spełnione, aby zadanie można było uznać
za ukończone.
SCRUM Podobnie jak definicja gotowości, zagadnienie definicji ukończenia jest w Scrum określone dość
ogólnie. Jeśli zadanie uznane jest za zakończone to wiadomym powinno być, co kryje się pod
terminem ukończenia, czyli jakie działania zostały wykonane. Co więcej zarówno klient
biznesowy jak i wszyscy członkowie zespołu powinni operować tą samą definicją, dzięki czemu
ukończenie zadania oznacza dla wszystkich to samo.
Działaniami, które muszą zostać ukończone w celu uznania zadania za zakończone mogą być na
przykład ukończona implementacja, stworzenie i wykonanie testów jednostkowych, stworzenie
i wykonanie testów integracyjnych, stworzenie i wykonanie testów funkcjonalnych,
przeprowadzenie analizy kodu, itd. W zależności od przyjętej formalizacji elementy te mogą być
określone umową słowną, lub spisane. W drugim przypadku możliwe jest udostępnienie ich w
postaci listy punktów dla każdego typu zadania, lub listy dotyczącej wszystkich zadań.
KANBAN Podobnie jak w przypadku definicji gotowości, tak w przypadku definicji ukończenia Kanban
zapewnia pełną dowolność. W zależności od sposobu zamodelowania procesu może być ona
rozumiana na kilka sposobów, przy czym identyfikowanie jej nie jest wymagane.
Jedną z możliwości jest określenie jej analogicznie jak w Scrum, czyli w postaci listy wymagań,
koniecznych do spełnienia w celu uznania zadania za ukończone.
Inną koncepcją jest przyjęcie, że przejście przez wszystkie kroki procesu wiąże się
automatycznie ze spełnieniem wymaganych warunków ukończenia.
Można także określać osobną definicję ukończenia dla każdego z kroków procesu z osobna,
której spełnienie wymagane jest w celu przejścia do kolejnej fazy.
23
PODSUMOWANIE W zależności od przyjętych rozwiązań ukończenie zadania może zarówno w Scrum jak i Kanban
wiązać się z koniecznością spełnienia wielu warunków. Kanban jednak, poprzez zamodelowanie
procesu nawet bez tworzenie dodatkowej definicji ukończenia definiuje automatycznie
charakter zadania, które przejść musi w określony sposób przez ściśle określony łańcuch
stanów.
Perspektywa: Definicja ukooczenia
Scrum Kanban
Wymaga, aby ukooczenie zadania oznaczało dla wszystkich to samo
Sama metoda nie identyfikuje definicji ukooczenia
Bardziej szczegółowe implementacje korzystają z listy warunków jakie praca musi spełnid, aby można ją uznad za ukooczoną
Bardziej szczegółowe implementacje określają warunki uznania zadania za ukooczone poprzez przejście przez wszystkie stany procesu
PERSPEKTYWA: ESTYMACJA, PLANOWANIE I METRYKI Omawiane dotychczas zagadnienia dotyczyły głównie sposobu wykonywania pracy i charakteru
określających ją zadań. Równie istotnymi zagadnieniami związanymi z organizacją pracy są
tematy w mniejszym stopniu związane z wytwarzaniem produktu. Należą do nich estymacja,
planowanie oraz zbieranie o prezentacja informacji na temat charakteru procesu. Pozwalają one
na podejmowanie właściwych decyzji związanych z wieloma aspektami wytwarzanego
produktu, takimi jak kierunek prac, komunikacja z interesariuszami, czy realizacja innych zadań
związanych z projektem.
Kolejne rozdziały przedstawiają sposoby, w jakie zagadnienia planowania i kontroli
zaawansowania pracy realizowane są w Scrum i Kanban.
SCRUM
ZARZĄDZANIE ZADANIAMI Istotnym czynnikiem związanym z planowaniem w Scrum jest definicja roli właściciela
produktu. Jest to rola mająca reprezentować klienta biznesowego. Osoba taka odpowiedzialna
jest za przekazywanie zespołowi spójnej koncepcji produktu i kierowanie jego rozwojem.
Kolejnym charakterystycznym czynnikiem określającym charakter Scrum jest koncepcja rejestru
produktu. Zawiera on informacje określające w danym momencie wizję produktu. W rejestrze
produktu znajdować się mogą elementy znacznie różniące się od siebie. Może on zawierać
pewną liczbę elementów określających ogólnie szeroki zakres cech produktu, które nie mogą
być pobierane do iteracji i przechowywane są jedynie w celu ewentualnego późniejszego
przekształcenia ich na większą liczbę bardziej szczegółowych elementów. Może zawierać także
zadanie nie do końca sprecyzowane, które są w trakcie precyzowania. Wreszcie zawiera też
elementy o odpowiednio małej granulacji, które po odpowiednim przygotowaniu określają
pracę, jaka ma zostać wykonana w czasie kolejnych iteracji. Podział taki ogranicza możliwość
poświęcenia czasu i wysiłku na precyzowanie zadań, które nigdy nie będą wykonane, lub
wymagać będą modyfikacji.
24
Odpowiednio przygotowane elementy podlegają w Scrum obowiązkowej estymacji. Jest ona
realizowana przez cały zespół. Dostarcza to dalszych informacji na temat zadań, pozwalających
właścicielowi produktu określić ich wartość biznesową i wyznaczyć priorytet.
Istotnym jest, że rejestr produktu nie jest stały. Jego cechą jest zmienność, wynikająca z ciągłej
jego aktualizacji wykonywanej przez zespół Scrum.
Założenie dotyczące istnienia rejestru z informacjami o planowanych zadaniach może
sugerować, iż głównym celem Scrum jest wytwarzanie produktów. Skupienie na zmienności
rejestru sugeruje także innowacyjność i adaptacje do zmieniających się warunków. Koncepcja
taka pasuje także do planowej pracy dotyczącej aktualizacji i utrzymania produktów.
ESTYMACJA Scrum wymaga estymacji zadań. Metoda mówi też, iż estymacja realizowana powinna być przez
zespół. Pozostałe aspekty, takie jak wykorzystywane techniki i jednostki estymacji nie są
określone.
Efekt estymacji wykorzystywany jest w celu umożliwienia planowania Sprintów, analizowania
szybkości pracy zespołu, oraz planowania dalekoterminowego. Praca ta charakteryzuje się też
pewnymi korzystnymi efektami ubocznymi. Jednym z nich jest identyfikacja i
doprecyzowywanie zadań, które w trakcie okazują się niewystarczająco zrozumiałe, lub
niejednoznaczne. Kolejnym efektem jest fakt, iż cały zespół rozumie cel, do którego powinien
zmierzać i posiada spójne informacje na temat produktu.
Wymaganie estymacji wiąże się oczywiście z koniecznością poświęcenie pewnej ilości czasu na
to zadanie. Zdania na temat przydatności tej aktywności są podzielone, gdyż nie do końca wiąże
się z ona z wytwarzaniem ostatecznej wartości, czyli produktu.
Jedną z najbardziej popularnych metody estymacji wykorzystywanych przez zespoły Scrum jest
estymacja relatywna, polegająca na wyznaczaniu wielkości zadania względem innych zadań.
Popularne jest także estymowanie w oparciu o koncepcję idealnych dni.
PLANOWANIE SPRINTU Planowanie sprintu w Scrum oparte jest o kilka warunków. Pierwszy wymaga, aby do sprintu
wybierane były zadania o możliwie najwyższym priorytecie, a więc reprezentujące pracę, której
wykonanie przyniesie klientowi w najbliższym czasie największą wartość. Kolejny wymaga, aby
zadania te były zrozumiałe dla całości zespołu i jednoznaczne. Ostatni warunek ogranicza liczbę
pobieranej pracy stawiając wymaganie związane z możliwością ukończenia przez zespół całości
pracy w trakcie iteracji.
Planowanie jest najbardziej efektywne, gdy zespół może bez niepotrzebnych przerw pracować
przez cały okres trwania iteracji, a cała zaplanowana praca zostaje wykonana.
Spełnienie opisanych warunków zapewnia zgodność z definicją Scrum. W rzeczywistości
efektywne zaplanowanie sprintu nie jest łatwe. Dotyczy to szczególnie warunku ograniczającego
ilość pracy. Pod uwagę trzeba też wziąć charakterystykę zespołu i innych interesariuszy. Zdarza
się, że zespół ma tendencję do pobierania większej ilości pracy niż jest w stanie dostarczyć.
25
Innym przypadkiem jest pobieranie ilości pracy znacznie mniejszej od możliwości zespołu, w
celu „zapewnienia sukcesu sprintu”. Zachowania takie powodowane mogą być przez czynniki
zewnętrzne.
Najbardziej popularnymi technikami planowania sprintów są metoda oparta o miarę prędkości
zespołu, oraz metoda oparta o wyczucie zespołu. Pierwsza z nich oparta jest o estymatę
efektywności zespołu wyliczaną na podstawie estymat przypisanych zadaniom, które zespół
zrealizował w poprzednich iteracjach. Liczba ta wykorzystywana jest w trakcie planowania jako
orientacyjna ilość pracy, którą zespół może dostarczyć w trakcie iteracji. Druga z wspomnianych
metod, opiera się jedynie na wyczuciu i doświadczeniu zespołu, obowiązującego się do
wykonania określonej ilości pracy.
Produktem wyjściowym aktywności planowania sprintu jest tak zwany rejestr sprintu, który
określa zadania wybrane do realizacji w trakcie rozpoczynającej się iteracji.
MONITOROWANIE POSTĘPU W RAMACH SPRINTU Scrum zaleca monitorowanie postępu pracy w trakcie sprintu w formie ilość pracy pozostającej
do wykonania względem dni iteracji. Zapewnia to dostęp do informacji pozwalającej, w oparciu
o rzeczywiste dane, oceniać prawdopodobieństwo ukończenia sprintu, oraz wskazującej na
występowanie problemów. Pierwsza z tych informacji zapewnia możliwość podjęcia działań
opartych o informacje związane z możliwym wcześniejszym ukończeniem prac, lub nie
ukończeniem prac w trakcie iteracji. Druga z opisanych informacji stanowi uzupełnienie
codziennych spotkań kontrolnych i jest pomocna w poszukiwaniu źródeł problemów.
Technikami przedstawiania postępu pracy w Scrum są wykresy spalania. W trakcie sprintu
wykorzystuje się wykresy tego typu zestawiając sumę estymat pozostających do wykonania
zadań każdego dnia iteracji. Informacja ta przedstawia rzeczywisty stopień zaawansowania
prac, gdyż jest zgodna z definicją ukończenia. Wykresy tego typu charakteryzują się jednak
skokową zmianą wartości ze względu na niska granularność przedstawianych informacji.
Drugim podejściem do przedstawiania postępu prace jest korzystanie z wykresu opartego o
zdefiniowane przez zespół, bardziej granularne aktywności związane z zadaniami. Rozwiązanie
to posiada jednak istotną wadę, opartą o brak związku przedstawianej informacji z definicją
ukończenia. Zadanie niespełniające tej definicji nie może zostać uznane za ukończone nawet,
jeśli wszystkie poza jednym podzadaniem składającym się na całość pracy zostały wykonane.
Często oba przedstawione podejścia wykorzystywane są równocześnie.
Monitorowanie postępu na poziomie iteracji wymaga poświęcenia pewnej ilości czasu i
zaangażowania zespołu w tą czynność. Zapewnia to jednak dostępność czytelnej dla wszystkich
interesariuszy, potencjalnie wartościowej, informacji.
PLANOWANIE DŁUGOTERMINOWE Fakt istnienia rejestru wyestymowanych zadań oraz możliwość wyznaczania orientacyjnej ilości
pracy wykonywanej przez zespół w trakcie jednej, ograniczonej czasowo , iteracji zapewniają w
Scrum możliwość planowania długoterminowego.
Planowanie to oparte może być zarówno o zakres pracy do wykonania jak i o określoną datę
graniczną. W pierwszym przypadku wyznaczany jest przewidywany czasu realizacji określonego
26
zbioru wyestymowanych zadań. W drugim przypadku określany jest zbiór wyestymowanych
zadań, które mogą zostać zrealizowane w wyznaczonym przedziale czasu.
Dokładność takiego planowania zależy między innymi od jakości i definicji zadań, estymat.
Wyższy poziom dokładności osiąga się planując w krótszej perspektywie, gdy zadania są dobrze
określone i spełniające warunek dopuszczalnej wielkości. Im dalsza perspektywa tym
planowanie takie jest bardziej orientacyjne ze względu na mniejszą ziarnistość zadań i mniejszą
dokładność definicji. Na dokładność planowania wpływa też stopień zmienności zakresu prac.
Często spotykanym podejściem jest zasada utrzymywania w rejestrze produktu mniej więcej
takiej liczby zadań, aby możliwe było zapełnienie nimi dwóch najbliższych iteracji. Pozostałe
elementy rejestru to wstępnie wyestymowane zarysy pracy przewidzianej do dalszej realizacji.
Podsumowując, w Scrum możliwe jest podjęcie próby wyznaczenia czasu zakończenia
określonego zakresu pracy, oraz określenia zakresu pracy, która może zostać wykonana w
konkretnej perspektywie czasowej.
DŁUGOTERMINOWE MONITOROWANIE POSTĘPU Długoterminowe monitorowanie postępu realizowane jest w Scrum podobnie jak
monitorowanie postępu na poziomie iteracji. Głównym narzędziem, jakie jest w tym celu
wykorzystywane są wykresy spalania. Różnicą jest jednak skala czasu. Monitorowanie odbywa
się nie na poziomie dni, lecz na poziomie iteracji. W przypadku tym granularność na poziomie
zadań jest wystarczająca i nie korzysta się z analizy postępu aktywności związanych z
zadaniami, które zresztą w przypadku zadań spoza aktualnej iteracji nie istnieją.
Popularną techniką jest wzbogacanie długoterminowych wykresów spalania o linię trendu
opartą o zmianę zakresu planowanych pracy. W przypadku, gdy liczba zadań rośnie, efektem jest
oddalanie się przewidywanej daty zakończenia projektu.
Informacje dostępne dzięki długoterminowemu monitorowaniu postępu pozwalają, w oparciu o
empiryczne dane, aktualizować plany wydań i synchronizować inne prace związane z projektem.
Przykładem mogą być konferencje, kampanie reklamowe związane z wytwarzanym produktem,
czy realizacja innych projektów.
KANBAN
ZARZĄDZANIE ZADANIAMI Kanban nie wskazuje koncepcji zarządzania zadaniami, jaką należy przyjąć wykorzystując tą
metodę. Możliwe jest przyjęcie dowolnego rozwiązania, które następnie zgodnie z charakterem
Kanban będzie adaptowane w oparciu o dane empiryczne.
Stosowanie Kanban nie wiąże się więc z żadnym konkretnym podejściem. Sam moment
pojawienie się zadania w procesie oraz definicja zadania może być bardzo zróżnicowana.
Zadania mogą być zarówno przyjmowane w postaci precyzyjnie określonego opisu pracy jak i
być niejako tworzone w samym procesie. W przypadku takim do pierwszej fazy procesu
pobierane mogą być nawet puste kartki, które dopiero w procesie będą wypełniane treścią
mogącą stanowić na przykład wymagania dla kolejnych faz procesu. Wynika to z faktu, iż
Kanban nie określa analogicznie jak Scrum, iż do iteracji przyjmowane są zadania, którymi
27
zarządza się w rejestrze produktu. W Kanban możliwe jest wytwarzanie samych zadań w
ramach procesu.
Brak wskazań w dziedzinie zarządzania zadaniami i wynikający z tego szeroki wachlarz
możliwości wiąże się również z brakiem wymagań względem stopnia przygotowania
pobieranych zadań.
ESTYMACJA Estymacja i jej forma nie jest w Kanban uregulowana. Nałożenie jakiegokolwiek wymagania przy
pozostawieniu pełnej dowolności w kwestii zarządzania zadaniami nie jest nawet możliwe.
Kanban pozwala więc na realizację zadań pozbawionych estymat. Nie jest to cecha negatywna,
gdyż w wielu potencjalnych zastosowaniach tej metody aktywność taka byłaby bezcelowa. W
przypadkach, gdy estymacja mogłaby przynosić korzyści, Kanban zakłada, iż analiza i adaptacja
procesu powinna doprowadzić do określenia tej aktywności.
W przypadkach, w których aktywność analizy zadań jest realizowana, polega ona często na
przyporządkowania zadania do konkretnej klasy.
MONITOROWANIE POSTĘPU Monitorowanie jest w Kanban, podobnie jak w Scrum, oparte o obserwację wykonywanej pracy.
Wykorzystywane metody, ze względu na inny model pracy, są jednak odmienne. Kanban
pozbawione jest iteracji. Nie mogą być one więc podstawą obserwacji wykonywanej pracy.
Teoretycznie możliwe jest wprowadzenie sztucznego podziału czasu, ale nie jest to typowe
rozwiązanie w Kanban. Metoda ta kładzie nacisk efektywność i krótki czas odpowiedzi. Miarą,
która wydaje się odpowiadać tym celom jest czas potrzebny na wykonanie zadania mierzony od
momentu, w którym pojawił się on w procesie do momentu, w którym zostało ono z punktu
widzenia procesu zakończone.
W przypadku podziału zadań na klasy, czy to w zależności od wielkości, czy w oparciu o inne ich
cechy, statystyka czasu realizacji wyznaczana jest dla każdej z nich osobno. Zmniejsza to
zróżnicowanie wartości i dostarcza bardziej szczegółowej informacji o średnim czasie ich
realizacji.
Informacje oparte o monitorowanie czasu realizacji zadań pozwalają na określanie, czy
konkretne zadanie zrealizowane zostało szybciej niż przeciętnie, czy też czas jego realizacji
przekracza termin średniego czasu realizacji analogicznych zadań. Identyfikacja drugiego z tych
przypadków umożliwia przeprowadzenie analizy problemu i szybkiego jego rozwiązania.
Możliwe jest też przyjęcie zasad, które zmniejszą prawdopodobieństwo występowania
podobnych problemów w przyszłości.
Kolejnym popularnym narzędziem monitorowania procesu wykorzystywanym w Kanban jest
skumulowany diagram przepływu. Przedstawia on liczbę zadań w określonych stanach procesu
na przestrzeni dni. Można powiedzieć, że obrazuje on płynność wykonywania pracy w czasie.
Wykres ten pozwala analizować średni czasu wykonywania zadań względem pracy w toku, oraz
zestawiać te dane z podejmowanymi podczas pracy decyzjami. Wykres taki obrazować może
między innymi skutki podjęcia decyzji o realizacji zadania większego niż zwykle, lub też zadania
28
nie w pełni zdefiniowanego. Udostępnia on informacje na temat wąskich gardeł i może być
pomocny w ich ewentualnym usuwaniu.
PLANOWANIE Koncepcja planowania w Kanban różni się znacznie od planowania w Scrum. Sam termin
planowanie można tu rozumieć w odmienny sposób. Formą planowania najbardziej
odpowiadającą Kanban jest określanie maksymalnych czasów realizacji zadań. Mogą być one
definiowane dla różnych typów zadań w oparciu o dane empiryczne uzyskane w trakcie
monitorowania prac. Charakterystyka ta umożliwia gwarantowanie czasu realizacji zadań w
postaci umów Service Level Agreements. W przypadku wielu środowisk taki typ planowania jest
bardziej odpowiedni. Dziedzinami takimi są na przykład wsparcie i utrzymanie systemów.
Przedstawiona koncepcja kładzie nacisk, nie na określanie przewidywanej daty zakończenia
grupy zadań, lecz na czas zakończenia pojedynczego zadania. Można oczywiście doszukiwać się
pomiędzy tymi koncepcjami pewnych analogii. Czas realizacji zadania oraz pewna liczba zadań
określonych typów mogą dostarczyć nam przecież pewnej przybliżonej informacji na temat
czasu potrzebnego do realizacji tych zadań.
Termin planowanie można również w Kanban rozumieć inaczej niż jako określanie czasu
potrzebnego na ukończenie zadań. Kanban oprócz planowania pracy charakteryzuje się także
stosunkowo szczegółowym planowaniem sposobu jej realizacji. Zgodnie z koncepcją wizualizacji
procesu określane są kolejne kroki realizacji zadań i warunki definiujące maksymalną liczbę
zadań w każdym z kroków. Definiuje się też typy zadań określające złożoność, klasy zadań
określające różnice w zadaniach, sposób przełączania pomiędzy zadaniami, a nawet określa się
podział czasu jakim dysponuje zespół dla wybranych klas zadań. W Scrum, gdzie zespół w
ramach iteracji może dowolnie organizować swoją pracę, nie istnieją tak szczegółowe
rozwiązania na poziomie wykonywania pracy.
PODSUMOWANIE Scrum z koncepcją rejestru produktu i miarą Velocity wydaje się bardziej skupiać na
wytwarzaniu nowej funkcjonalności, podczas gdy Kanban z koncepcją skupienia na czasie
zakończenia pojedynczego zadania wydaje się bardziej skierowany w stronę pojawiających się
ad-hoc zadań, które muszą być wykonane możliwie najszybciej tak jak jest to w przypadku
działów zajmujących się działaniami operacyjnymi systemów.
Perspektywa: Estymacja, planowanie i metryki
Scrum Kanban
Określony sposób zarządzania zadaniami do realizacji w rejestrze produktu
Zadania do realizacji mogą pochodzid z różnych źródeł, a także byd tworzone w ramach procesu
Estymacja zadao prowadzona przez zespół, najczęściej relatywna
Brak wymagao względem estymacji, ewentualnie prosty podział typów zadao
Estymacja zwiększa poziom zrozumienia zadao przez cały zespół
Brak konieczności poświęcania czasu na szczegółową estymację zadao
Planowanie jako ilośd pracy realizowanej w trakcie jednej iteracji
Planowanie oparte o przewidywany czas zakooczenia zadania
Zespół zobligowany do realizacji całości zaplanowanej pracy w trakcie iteracji
Wykrywanie zadao, przekraczających średni czas realizacji
29
Zespół bierze czynny udział w planowaniu pracy Zespół niekoniecznie musi brad udział w planowaniu pracy
Postęp prac w ramach iteracji monitorowany na wykresach spalania
Postęp prac monitorowany na tablicy kanban oraz poprzez analizę średnich czasów wykonania
Velocity – jedna miara dotycząca różnych zadao Lead time może byd określany dla zadao o różnej złożoności.
Velocity – określa ilośd pracy w okresie czasu Lead time – określa czas wykonania pewnej ilości pracy w postaci jednego zadania.
Diagram zmiany velocity. Diagram zmiany lead time.
Brak konieczności posiadania zdefiniowanego przepływu zadao w ramach iteracji. Jeśli jest zdefiniowany można korzystad z Cumulative flow diagram.
Cumullative flow diagram udostępniający informacje o pracy w toku i wpływie decyzji na lead time w sposób ciągły.
Możliwośd planowanie pracy w dalszym terminie Możliwośd gwarantowania czasu obsługi zadania
Możliwośd analizowania postępu w dalszym terminie Dostosowanie procesu do charakterystyki obsługiwanych zadao i warunków nałożonych na ich czas realizacji.
PERSPEKTYWA: ADAPTACJA I ORGANIZACJA PRACY
SCRUM
ADAPTACJA PRODUKTU I CZAS ODPOWIEDZI NA ZMIANĘ Scrum poświęca wiele uwagi zagadnieniu zarządzania kierunkiem pracy. Jego konstrukcja
zapewniać ma wykonywanie pracy stanowiącej w danym momencie największą wartość
biznesową dla klienta. Jednocześnie dąży do maksymalizacji efektywności zespołu poprzez
skupianie jego wysiłku na realizacji tej pracy poprzez samoorganizację. Realizacji tych celów
służy określenie roli właściciela produktu i koncepcja pracy z rejestrem produktu.
Realizacja pracy stanowiącej dla klienta największą wartość wymagać może zmiany priorytetów
w rejestrze produktu, wprowadzania nowych zadań i modyfikacji zadań już zdefiniowanych.
Podejmowanie takich decyzji wymaga zestawiania aktualnych, mogących ulegać zmianom,
wymagań biznesowych, zawartości rejestru produktu, oraz aktualnego stanu wytwarzanego
produktu. W Scrum obowiązek rozumienia aktualnych wymagań spoczywa na właścicielu
produktu. Znajomość i aktualizacja rejestru produktu jest współdzielonym obowiązkiem
właściciela produktu i zespołu Scrum. Informacja na temat wytwarzanego produktu,
przekazywana jest natomiast podczas spotkania podsumowującego iterację (ang. sprint review).
Celem tego spotkania jest synchronizacja stanu wiedzy zespołu i właściciela produktu na temat
produktu. W oparciu o tę wiedzę właściciel produktu może efektywnie kierować dalszymi
pracami. W przypadku, gdy wyobrażenie klienta o pożądanej funkcjonalności nie jest zgodne z
uzyskanym produktem może on odpowiednio adaptować rejestr produktu, oraz przekazać
zespołowi informacje, które mogą zwiększyć trafność podejmowanych przez zespół decyzji.
Spotkanie to ma także aspekt psychologiczny związany z budowaniem zaufania pomiędzy
30
zespołem a odbiorcą produktu. Może być także czynnikiem wpływającym na motywację zespołu
opartym o satysfakcję z odbioru pracy i rozumienie celu wykonywanej pracy.
Założenie pełnego skupienia zespołu na wykonywaniu pracy, poprzez niezmienność zakresu
prac zaplanowanych do wykonania w trakcie sprintu, wpływa jednak na ograniczenie czasu
odpowiedzi systemu na zmianę. W ogólnym przypadku jest on równy połowie czasu trwania
iteracji. Niekorzystny wpływ tego czynnika niweluje w znacznym stopniu ograniczenie długości
trwania iteracji. W zależności od charakteru projektu może być to ograniczenie dopuszczalne,
lub restrykcyjne.
W szczególnych przypadkach Scrum przewiduje możliwość anulowania sprintu. Wiąże się to
jednak z brakiem obowiązku dostarczenia wykonanej do tego momentu pracy. Ta
problematyczna często zasada ma na celu między innymi skupienie zespołu na wykonaniu
zadań, oraz podejmowaniu przez właściciela produktu przemyślanych decyzji. Fakt, iż w
rzeczywistych implementacjach anulowanie sprintów nie jest często praktykowane zdaje się
potwierdzać słuszność tej zasady.
ORGANIZACJA PRACY I ROZWIĄZYWANIE PROBLEMÓW Jedną z istotniejszych koncepcji Agile Software Development jest samoorganizacja zespołu.
Scrum zdecydowanie przyjmuje takie właśnie podejście do rozwiązywania rozmaitych
problemów. Definiuje on ogólne ramy wykonywania pracy, pozostawiając szczegóły jej
wykonywania zespołowi. Istotne jest, aby praca wciągana była do iteracji zgodnie z konkretnymi
regułami i aby opuszczała iterację zgodnie z konkretnymi regułami. To, co dzieje się w trakcie
iteracji a więc sposób wykonanie tej pracy pozostaje w gestii osób będących najbliżej tego
procesu, czyli w gestii zespołu.
Rozwiązywanie problemów występujących w trakcie sprintu jest obowiązkiem zespołu. Scrum
zakłada, iż realizacja założeń tej metody powinna zapewnić zespołowi informacje potrzebne do
efektywnej samoorganizacji, której celem jest dążenie do dotrzymania zobowiązania
dostarczenia produktu. Elementem dalej wspomagającym taki sposób pracy, są w Scrum
codzienne krótkie spotkania, w trakcie których zespół wymienia się informacjami na temat
wykonywanej pracy.
Scrum określa także rolę Scrum Mastera, która odpowiedzialna jest między innymi za
wspomaganie zespołu w rozwiązywaniu problemów, oraz budowanie i wspieranie
samoorganizacji w zespole. Ma on też za zadanie wykrywanie mniej widocznych problemów,
które mogą umknąć osobom w pełni zaangażowanym w samo wytwarzanie produktu. Jego
obowiązkiem jest też odciążanie zespołu względem obowiązków niezwiązanych bezpośrednio z
wytwarzaniem produktu. Zadaniem takim jest na przykład koordynacja współpracy z osobami
w organizacji, które odpowiedzialne są za zagadnienia, które wpływają na efektywność
wykonywanej przez zespół pracy.
ADAPTACJA SPOSOBU PRACY MAJĄCA NA CELU JEGO DOSKONALENIE Adaptacja sposobu pracy w Scrum opiera się głównie o wytworzenie otwartego środowiska, w
którym koncepcje wprowadzania zmian są przyjmowane jako pozytywny wkład w pracę, a
nawet część pracy i dąży się do ich realizacji. Istotnym aspektem jest tu też koncepcja wspólnego
celu wszystkich członków zespołu. Podejście takie ma doprowadzić do rzeczywistego wdrożenia
31
Kaizen, czyli filozofii skupiającej się na ciągłym doskonaleniu procesu przez wszystkich
pracowników, nawet w środowiskach, które wcześniej odległe były od tej koncepcji.
Realizację opisanego celu, zapewniać ma w Scrum przede wszystkim, wpisane w proces,
spotkanie poświęcone adaptacji sposobu pracy. Za jego prowadzenie i efektywne wykorzystanie
odpowiada Scrum Master. Zdefiniowanie tego spotkania jako części procesu organizacji pracy,
zwiększa prawdopodobieństwo uzyskania otwartego na zmiany środowiska. Zgłaszane
problemy i pomysły są odbierane jako pozytywny wkład i część wykonywanej pracy. Jest to
istotne szczególnie w bardziej konserwatywnych środowiskach.
Okresowość tego spotkania ma także pewną cechę negatywną. Jest ona związana z tym, iż
odbywa się ono po iteracji, w trakcie której występuje większość problemów. W sytuacji takiej
uzyskanie informacji pozwalających na identyfikację rzeczywistego źródła problemu może być
utrudnione. Także podatność środowiska na zmianę w momencie, gdy sytuacja kryzysowa
została już zażegnana może być mniejsze, niż momencie jej występowania.
Adaptacja w Scrum nie dotyczy metod założeń i reguł samego Scrum, które powinny pozostać
zgodne z oryginalnymi założeniami metody. W praktyce nie jest to istotne ograniczenie, gdyż
pomimo wszystko Scrum pozostaje stosunkowo prostą metodą pracy pozostawiającą dużo
swobody w regulacji pracy. Często przypadkami, w których, rozważana jest zmiana lub
porzucenie pewnych zasad metody jest ich niedostateczne zrozumienie, lub brak pełnej
akceptacji środowiska na pracę w sposób zgodny ze Scrum, dlatego ruch taki powinien być w
pełni przemyślany.
KANBAN
ADAPTACJA PRODUKTU I CZAS ODPOWIEDZI NA ZMIANĘ Sposób wprowadzania zmian dotyczących kierunku pracy zespołu w Kanban opiera się na
krótkim czasie realizacji zadania od momentu, gdy zostaje ono umieszczone w procesie.
Umożliwia to uzyskanie bardzo krótkiego czasu odpowiedzi na zmiany. Nowe zadanie,
zakładając jego najwyższy priorytet, zostanie wprowadzone do procesu, gdy tylko możliwe
będzie rozpoczęcie nad nim pracy. W przypadku zdefiniowania klasy zadań o wyższym
priorytecie stać się to może nawet ad-hoc.
Kanban nie definiuje odgórnie okresu, w trakcie którego wprowadzanie zmian zakresie pracy
jest zablokowane, ani metody postępowania w sytuacji w której konieczna jest zmiana zakresu
pracy która została już rozpoczęta. Nie są też zdefiniowane żadne aktywności dotyczące
adaptacji wytwarzanego produktu. Rozwiązywanie tego typu kwestii nie jest istotą Kanban.
Brak iteracji w Kanban umożliwia pobieranie i oddawanie pracy w trybie ad-hoc. Taka metoda
pracy umożliwia minimalizację czasu odpowiedzi systemu i ilości pracy znajdującej się w
systemie. W wielu zastosowaniach rozwiązanie takie będzie bardzo efektywne. Przykładem jest
proces, w którym definiowanie i zbieranie wymagań nie jest potrzebne, ze względu na fakt, iż
zadania są ustandaryzowane. W wielu projektach rozwiązanie takie może jednak nie być
realizowalne. Konieczność przekazywanie informacji o wymaganiach powoduje na przykład
przełączanie się zespołu pomiędzy kontekstami, co finalnie może zmniejszać efektywność.
Podobnie w przypadku, gdy osoby odpowiedzialne za definiowanie zadań nie są dostępne ad-
hoc praca w taki sposób byłaby trudna do realizacji.
32
Kanban nie określa sposobu, w jaki zadania przyjmowane są do procesu, ani sposobu ich
wydawania. Nie definiuje też uczestniczących w tym stron. Produkt może być analizowany w
momencie wydania lub nie, w zależności od przyjętych reguł.
ORGANIZACJA PRACY I ROZWIĄZYWANIE PROBLEMÓW W Kanban rozwiązywanie problemów oparte ma być przede wszystkim o pełną wizualizację
procesu. Zakłada się, że występowanie problemu będzie widoczne na tablicy Kanban, a nawet
odwracając to stwierdzenie tablica Kanban identyfikować będzie istnienie problemu. Może być
to między innymi fakt pozostawania zadania dłużej niż powinno w jednym stanie, lub
zatrzymanie przepływu w jednym z stanów procesu.
Wizualizacja procesu pomaga w identyfikacji rzeczywistych źródeł problemów i uzyskaniu
skupienia grup potrzebnych do jego rozwiązania poprzez jego aktualność. Przykładem
rozwiązywania problemów w Kanban jest przypadek zablokowania się procesu
spowodowanego przyjęciem zadania o zakresie znacznie większym niż przeważnie
przetwarzane zadania, lub przyjęciem zadania łamiącego limit pracy w toku. W przypadku takim
Kanban umożliwia zestawienie tego faktu z negatywnymi zjawiskami, które spowodował i
ustalenie zmiany sposobu postępowania w analogicznych przypadkach w przyszłości.
Dane w oparciu, o które podejmowane są decyzje dotyczące adaptacji sposobu pracy są w tym
przypadku obiektywne i łatwiej dostępne niż potencjalnie subiektywne dane w omawiane w
trakcie okresowych spotkań w Scrum. Wykorzystanie dostępu do tych danych wymaga jednak
rzeczywistej analizy problemu w momencie jego występowania. Doprowadzenie jedynie do
możliwości kontynuowania pracy uniemożliwi wykorzystanie tej możliwości.
Kanban nie definiuje spotkania poświęconego analizie występujących problemów i w celu
wykorzystania dostępnych danych analiza taka powinna być uruchamiana przez zespół, co
stawia pewne wymagania względem dojrzałości zespołu i całej organizacji. Co więcej,
stwierdzenie czy obserwacja procesu jest źródłem wszystkich potencjalnie przydatnych danych
mogących wpływać na efektywność pracy jest trudne do określenia.
W celu wykorzystania osób związanych z procesem do jego adaptacji wymagać może już
rozwiniętej kultury Kaizen, w której każdy pracownik czuje się zobowiązany do zgłaszania
swoich sugestii dotyczących problemów i ewentualnych modyfikacji sposobu pracy. W
przeciwnym przypadku brak zdefiniowanych aktywności zachęcającej do takich praktyk może
uniemożliwić wykorzystanie tego źródła informacji. Z tego też względu zespoły korzystające z
Kanban a znające koncepcje Agile często zapożyczają ze Scrum zarówno codzienne spotkania jak
i spotkania dotyczące omówienia pewnego okresu pracy.
ADAPTACJA PROCESU Adaptacja procesu w Kanban rozumiana może być inaczej niż adaptacja sposobu pracy w Scrum.
W Kanban dotyczy ona w głównej mierze rzeczywiście zamodelowanego procesu wytwarzania
produktu, który przedstawiony jest w mniej lub bardziej dokładnej formie na tablicy Kanban.
Częstymi czynnościami są między innymi: dodawanie, usuwanie, dzielenie, łączenie stanów
procesu; Modyfikacja limitów dotyczących zadań w danym stanie procesu; Wprowadzanie
stanów będących buforami; Wprowadzanie typów zadań o różnych priorytetach; Wprowadzanie
typów zadań mogących łamać limity zadań i reguł tym procesem rządzących; Wprowadzanie,
33
rezygnacja z monitorowania podzadań; Wprowadzenie podziału tablicy względem typów lub
wielkości zadań; Określenie limitów pracy dla różnych typów zadań osobno.
W wyniku tych działań powstaje dokładnie, wręcz technicznie, zdefiniowany model procesu
pracy, który powinien być przestrzegany przez zespół. Taka szczegółowość, często wsparta
dodatkowymi spisanymi regułami postępowania w określonych sytuacjach posiada swoją
specyfikę. Z jednej strony powoduje, iż każdy członek zespołu wie jak w danej sytuacji powinien
się zachować. Z drugiej strony jednak praca regulowana jest w bardzo szczegółowy sposób,
który z pewnością nie będzie nigdy w stanie opisać wszystkich możliwych sytuacji, które mogą
zaistnieć. Tego typu mechaniczny opis pracy może także pomijać czynniki związane z
psychologią pracy. Jego szczegółowość i dopracowanie może też wpływać na ograniczanie jego
adaptacji, co stoi w sprzeczności z ideą Kaizen.
Poziom regulacji dostępny w Kanban jest szerszy niż w Scrum ze względu na mniej reguł
określających model pracy. Może być to traktowane zarówno jak cecha pozytywna jak i
negatywna.
PODSUMOWANIE Różnice pomiędzy Scrum i Kanban w dziedzinie rozwiązywania bieżących problemów i adaptacji
sposobu pracy można podsumować stwierdzeniem, iż podchodzą one do tego zagadnienia w
całkiem odmienny sposób.
Scrum skupia się na zespole, który obdarzony jest jednocześnie zaufaniem jak i
odpowiedzialnością związaną z samoorganizacją i rozwiązywaniem problemów pojawiających
się w trakcie pracy. Podobnie zespół zgłasza propozycje zmian w trakcie spotkania
zamykającego iterację.
Kanban z kolei skupia się na wizualizacji procesu oraz eksponowaniu pojawiających się
problemów, co powinno spowodować odpowiednią reakcję wielu zaangażowanych w pracę
stron. Źródłem i inspiracją do zmian jest więc zwizualizowany stan procesu.
Czas odpowiedzi oraz kierunek prac w Scrum wynika z obowiązkowych, okresowymi
aktywności. W Kanban czas odpowiedzi i kierunek prac oparte są o czas realizacji zadania.
Perspektywa: Adaptacja i organizacja pracy
Scrum Kanban
Wspieranie Kaizen oparte o aktywności o określonym celu
Wizualizacja procesu, wymagająca Kaizen w celu wprowadzania zmian
Zespół zajmuje się efektywnym wytworzeniem pracy
Sposób wytwarzania pracy ściśle zdefiniowany przez proces
Zdefiniowane aktywności związane z organizacją pracy (aktywności Scrum).
Zdefiniowane aktywności związane z wykonywaniem pracy (stany Kanban).
Sposób wykonywania pracy opisany na poziomie ogólnym.
Sposób wykonywania pracy szczegółowo określony.
Adaptacja ma źródło w obiektywnej ocenie rezultatów sprintu, oraz subiektywnych odczuciach zespołu.
Adaptacja ma źródło w zwizualizowanym procesie.
34
Aktywnośd adaptacji dotyczyd może wszystkich aspektów pracy.
Sposób identyfikacji problemów skupia się przede wszystkim na aspektach pracy związanych z mechaniką procesu.
Możliwośd adaptacji sposobu pracy w ramach reguł Scrum.
Bardzo szeroka możliwośd adaptacji sposobu pracy.
Skupienie na produkcie i zespole. Skupienie na procesie wytwarzania produktu. Kolizja z manifestem Agile.
Brak dostępności aktualnej informacji na temat stanu środowiska procesu w momencie wystąpienia problemu.
Dostępnośd aktualnej informacji na temat stanu środowiska procesu w momencie wystąpienia problemu.
OBSERWACJE
ZESPÓŁ A PROCES Scrum i Kanban różnią się znacznie pod względem podejścia do zespołu. W Scrum zespół
znajduje się w centrum uwagi metody.
Scrum określa preferowany skład zespołu, jako na tyle interdyscyplinarny, aby możliwe było
wykonanie wszystkich zadań związanych z dostarczeniem produktu. W skład jednego zespołu
zaliczane są, więc osoby o różnych specjalizacjach a więc zarówno programiści jak i architekci,
testerzy, itd.
Scrum zakłada, iż zespół, rozumiany jako wszystkie te osoby o różnych specjalizacjach
zaangażowane w pracę nad produktem, bierze na siebie odpowiedzialność za całość produktu
na który składa się wykonywanie różnych zadań.
Większość zaleceń związanych ze Scrum dotyczy zespołu w taki sposób, iż staje się on bytem
podstawowym. Bierze udział we wszystkich spotkaniach, dzięki czemu posiada dostęp do
wszystkich istotnych informacji i możliwość ich pozyskiwania. Zespół jako całość estymuje
zadania, bierze udział w planowaniu pracy, odpowiada za przedstawianie wyników pracy, oraz
jest głównym źródłem propozycji dotyczących zmian w sposobie pracy.
Udział wszystkich osób składających się na zespół we wszystkich tych aktywnościach zapewnić
ma dostępność informacji dla wszystkich stron, możliwość analizy pracy przez możliwie
szerokie grono związane bezpośrednio z wytwarzanym produktem, oraz umożliwiać efektywną
kooperację.
Opisana specyfika w podejściu do zespołu w Scrum wynika z faktu, iż zespół odpowiedzialny jest
tu za takie zorganizowanie pracy w trakcie iteracji, aby praca przyjęta do iteracji została
wykonana w trakcie jej trwania. Co więcej powinna ona także dostarczyć wartość klientowi
biznesowemu. W trakcie iteracji zespół sam organizuje swoją pracę bez oparcia o szczegółowo
wyspecyfikowany proces.
Wszystkie opisane cechy Scrum wynikają z faktu, iż jest to metoda oparta o koncepcje Agile
Software Development.
Kanban jest metodą skupiającą się na wizualizacji procesu i wynikającej z tego możliwości
efektywnej jego adaptacji. Zasadniczym zadaniem osób wykonujących pracę w tej koncepcji jest
35
wykonywania zadań określonych przez proces. Szczegółowe modelowanie procesu
wykonywania pracy w Kanban wskazuje, że nie charakteryzuje się on wspieraniem koncepcji
zespołu analogicznej do tej w Scrum. Możliwe jest wyróżnianie specjalistów zajmujących się
poszczególnymi fazami procesu i traktowanie ich jako osobne podzespoły. Kanban nie stawia
także żadnych wymagań względem udziału wszystkich osób związanych z procesem w
jakichkolwiek aktywnościach. Postulowana jest jednak realizacja wspomnianej wcześniej koncepcji
„swarming”, polegającej na wspólnej analizie i rozwiązywaniu wizualizowanych na tablicy Kanban
problemów.
Koncepcja Kanban pozwala na łatwiejszą organizację pracy większej grupy osób o określonych
specjalnościach. Trudniej jest jednak w takiej sytuacji zapewnić współodpowiedzialność za
wykonywaną pracę.
SUBIEKTYWNOŚĆ DANYCH WEJŚCIOWYCH ADAPTACJI Brak szczegółowego modelu procesu pracy w Scrum, pozostawienie zarządzania pracą
zespołowi, oraz analiza problemów odbywająca się po zakończeniu iteracji może wpływać na
pewną subiektywność informacji wykorzystywanych do adaptacji sposobu pracy. Poziom
subiektywności tych informacji zależy od tego czy są one oparte o dane zebrane w momencie
wystąpienia problemu. Nie są to oczywiście jedyne dane wykorzystywane w trakcie adaptacji.
Podstawową informacją stanowi zawsze obiektywny stan produktu po zakończeniu sprintu.
W przypadku Kanban wizualizacja procesu zapewnia możliwość szczegółowego określenia
problemu oraz stanu procesu, w jakim zdarzenie to miało miejsce. Analiza problemu w takiej
sytuacji oparta być może o szczegółowe i aktualne dane. Skutkuje to możliwością adaptacji
opartą o dane w znacznej mierze obiektywne.
Na dane zbierane w związku z występowaniem problemu poza kwestiami omówionymi powyżej
wpływają także inne aspekty organizacji pracy. Wpływa na to na przykład struktura zespołu. W
zespole współodpowiedzialnym za pracę łatwiej może być zebrać obiektywne dane niż w
przypadku wielu konkurujących ze sobą grup. Informacje zależeć będą też od tego, kto i jak
zbiera dane na temat występującego problemu. Przekazane informacje mogą być inne w
przypadku zbierania ich przez kogoś spoza zespołu, kto poszukuje odpowiedzialnego za
problem w celu wyciągnięcia konsekwencji z zaistniałej sytuacji niż w przypadku, gdy zespół
sam poszukuje przyczyn. Subiektywność informacji nie zależy jedynie od tego czy ich źródłem są
ludzie czy proces, ale też od innych czynników w tym tego, kto je zbiera.
ZRÓŻNICOWANIE CHARAKTERU ZADAŃ Szczegółowy model procesu realizacji zadań w Kanban zapewnia możliwość obserwacji
charakterystyki pracy i udostępnia informacje pomocne w zwiększaniu jej efektywności i
jakości. Umożliwia on także określenie sposobu postępowania w znanych sytuacjach
wyjątkowych i zróżnicowanie poziomu obsługi zadań poprzez możliwość wprowadzania klas
usług. Rozwiązanie takie zmniejsza też wymagania względem samoorganizacji pracy zespołu
zapewniając stałą, dokładnie określoną ścieżkę postępowania dla znanych typów zadań.
W przypadku pracy, charakteryzującej się zadaniami o bardzo różnej specyfice określenie
jednego lub nawet kilku zależnych od typu przepływów może nie być proste w realizacji. Mogą
36
pojawiać się zadania, dla których zdefiniowane sposoby postępowania są nieefektywne, lub
całkiem nieodpowiednie.
Scrum nie wymaga definiowania procesu realizacji pracy, a jedynie konieczność zrealizowania
jej w trakcie określonego przedziału czasu. Zespół Scrum, jeśli tylko składa się z osób
posiadających odpowiednie umiejętności, może bez większych problemów pracować nad
projektem, na który składać się mogą bardzo zróżnicowane zadania stanowiące wartość dla
klienta.
CZAS ODPOWIEDZI SYSTEMU I ZADANIA KRYTYCZNE Kanban umożliwia zorganizowanie procesu w taki sposób, że czas odpowiedzi systemu na
zmianę może być znacznie krótszy niż w przypadku Scrum, w którym średnio wynosi on połowę
okresu trwania iteracji. Rozwiązaniem takim jest na przykład pobieranie zadań ad-hoc.
Kanban nie ogranicza również wprowadzania zadań o wyższych priorytetach. Jedną z metod
obsługi tego typu zadań jest definicja klas zadań. W przypadku takim określone mogą zostać
reguły przerwania pracy nad zadaniem o niższym priorytecie i przełączania się na nowe bardziej
priorytetowe zadanie. Możliwe jest uzgodnienie, iż zadnia tego typu będą nawet łamać limity
nałożone na kolejne fazy procesu. Wprowadza to niekorzystny czynnik w postaci przełączania
się pomiędzy zadaniami, ale umożliwia uzyskanie w pewnych przypadkach minimalnego czasu
odpowiedzi systemu na zadania krytyczne. Mogą to być na przykład wysokiej wagi błędy
dotyczące systemów produkcyjnych.
Niektóre implementacje Kanban rozwiązują ten problem poprzez rezerwację określonej części
wydajności zespołu na pracę dotyczącą zadań poszczególnego typu. Realizowane jest to poprzez
podział procesu na przepływy dla różnych klas i zdefiniowanie dla nich osobnych limitów.
Umożliwia to zagwarantowanie poziomu obsługi każdego typu zadania bez negatywnego
wpływu na obsługę zadań innych typów.
Scrum nie przewiduje częstego wprowadzania do systemu niespodziewanych, wysoce
priorytetowych zadań. Jest to niejako sytuacją wyjątkową, która może zostać obsłużona poprzez
anulowanie aktualnego sprintu. W pozostałych przypadkach zmiany mogą zostać wzięte pod
uwagę podczas kolejnego spotkania dotyczącego planowania sprintu, co może mieć miejsce za
pięć minut, lub w najgorszym przypadku za cztery tygodnie w przypadku czterotygodniowej
iteracji.
Zdarza się że w celu obsługi tego typu nagłych zadań, zespoły Scrum pozostawiają sobie pewien
bufor względem zadań, które przyjęte zostały do iteracji, który może zostać wykorzystany w
przypadku pojawienia się takiego wysoce priorytetowego zadania. Jeśli zadanie takie się nie
pojawi dobrane może zostać inne omówione wcześniej zadanie z rejestru produktu.
Rozwiązanie takie łamie jednak koncepcję skupienia zespołu na celu iteracji i nie przełączania
się pomiędzy zadaniami a więc nie jest zgodne z koncepcją Scrum.
POZIOM REGULOWANIA SPOSOBU WYTWARZANIA PRODUKTU I ORGANIZACJI PRACY W pierwszych rozdziałach pracy przedstawione zostały ogólne zasady dotyczące metody Scrum
i metody Kanban. Porównanie liczby regulacji tych metod wskazuje jednoznacznie, że Scrum jest
procesem bardziej zdefiniowanym a więc pozostawiającym teoretycznie mniejsze możliwości
adaptacji sposobu pracy.
37
Jeśli przyjrzeć się zasadom definiowanym przez Scrum można zauważyć, że nie dotyczą one
jednak bezpośrednio sposobu wykonywania pracy w sensie procesów, które doprowadzają do
wytworzenia produktu. Określają one pewne ramy organizacyjne, które stworzyć mają
środowisko przyjazne efektywnemu wykonywaniu właściwej pracy, a więc dostarczaniu
wartość klientowi biznesowemu. Ramy te definiują organizację pracy w taki sposób, aby zespół
w maksymalnym stopniu mógł skupić się na dostarczeniu tej wartości i posiadał możliwość
wprowadzania zmian usuwających problemy i zwiększających efektywność pracy. Całość
metody ukierunkowana jest na uzyskiwanie właściwego produktu, empiryczną adaptację i
zapewnienie możliwości efektywnej pracy.
W Scrum szczegóły dotyczące wykonywania przez zespół pracy w trakcie iteracji pozostawione
są zespołowi.
Kanban skupia się na procesie i jego adaptacji. Wymaga on wizualizacji procesu i jego adaptacji
opartej o obserwację, oraz zaleca minimalizację pracy w toku. Liczba i skala tych ograniczeń jest
bardzo mała. Fakt ten wpływa na brak konieczności wykonywania większych zmian w
organizacjach i wpływa na możliwość wykorzystanie Kanban do optymalizacji istniejących
procesów. W przypadku takim liczba ograniczeń niezwiązanych z Kanban, lecz istniejącymi już
regułami może znacznie przewyższać liczbę zaleceń Scrum.
Zjawisko to nie jest problemem w przypadku wdrożenia Kanban w oparciu o już efektywnie
działający proces. Może jednak stanowić wyzwanie, gdy wdrożyliśmy go w oparciu o proces,
który jest wysoce nieefektywny a środowisko stawia opór zmianom.
W przypadku takim adaptacja w oparciu o Kanban może być bardzo trudna do realizacji. Może
być to proces trudniejszy niż przyjęcie ad-hoc kilku zasad Scrum, gdyż problemy wykazywane
będą znacznie dłużej niż trwa okres przyjmowania nowej metody. W niektórych przypadkach,
gdy wykonywana praca odpowiada charakterystyce Scrum, uzyskanie efektywności
porównywalnej z przyjęciem Scrum może trwać bardzo długo.
Abstrahując od przypadków tego typu Kanban skupia się na definiowaniu tego jak praca będzie
wykonywana poprzez zdefiniowanie i wizualizację procesu. Z czasem liczba reguł dotyczących
tego procesu może zacząć znacznie przyrastać, w związku z działaniami mającymi na celu
zwiększanie efektywności procesu. Proces stawać się może coraz bardziej szczegółowy i skupiać
się na efektywnej realizacji wąskiej grupy zadań. W przypadku takim efektywna realizacja pracy
odbiegającej od tej w oparciu o jaką został zaprojektowany staje się coraz trudniejsza.
W praktyce trudno określić, która z metod charakteryzuje się większym poziomem regulacji.
Scrum narzuca pewne ograniczenia na samym początku. Kanban robi to w trakcie pracy i na
nieco innym poziomie.
Widoczne jest że Scrum i Kanban charakteryzują się nakładaniem zasad na inne aspekty pracy.
Scrum skupia się bardziej na otoczeniu pracy, pozostawiając sposób jej wykonania zespołowi
Kanban nie określa zasad dotyczących otoczenia, wpływa jednak na definiowanie samego
sposobu wykonywania pracy. W tym sensie można powiedzieć, że Scrum stara się bardziej
kontrolować czynniki zewnętrzne a Kanban skupia się na czynnikach wewnętrznych.
38
Obserwacja poziomu regulacji
Efektywne wykorzystanie metody nie wymaga dużego doświadczenia zespołu i dojrzałości organizacji. Wymaga jednak wsparcia i zrozumienia na szczeblu kierowniczo-liderskim.
Efektywne wykorzystanie metody wymaga dużego doświadczenia zespołu i dojrzałości organizacji. Konieczne jest przyjęcie i kultywowanie filozofii Kaizen.
Efektywne wykonywanie pracy w ramach metody wymaga sporej dojrzałości zespołu związanej z samoorganizacją.
Efektywne wykonywanie pracy w ramach metody nie musi nie wymagad dużej dojrzałości zespołu.
PODSUMOWANIE Scrum i Kanban pomimo analogii celów, do jakich dążą charakteryzują się dość znaczącymi
różnicami. Różnice te mogą w znaczny sposób wpływać na efektywność danej metody w
konkretnym zastosowaniu. Świadomość i rozumienie tych różnic, pozwolić może na uniknięcie
rozczarowania spowodowanego niedopasowaniem metody do pracy, jakiej wykonywanie ma
wspomagać i środowiska, w jakim praca ta jest wykonywana.
Cechą wspólną tych metod, niezwiązaną bezpośrednio ze sposobem pracy jest to, iż obie
pomimo tego, iż teoretyczne ich opanowanie nie wymaga dłuższego czasu, są w rzeczywistości
bardzo skomplikowane w rzeczywistej implementacji. Zarówno w przypadku Scrum, które
organizuje w pewnym stopniu ramy organizacji pracy jak w przypadku Kanban, gdzie konieczne
jest zdefiniowanie ich samemu, lub stopniowa ich adaptacja istotne często stają się kwestie
niezwiązane z mechanicznymi aktywnościami metod. Są to na przykład różne aspekty
współpracy osób, które współpracują podczas wykonywanych zadań, charakter komunikacji z
resztą organizacji i klientem, czy dojrzałość i otwartość na zmiany wszystkich współpracujących
stron.
Próba określenie typów prac, czy też rodzajów projektów, w przypadku których lepsza byłaby
metoda Scrum lub Kanban wydaje się być, ze względu na różnorodność środowisk, projektów,
zespołów i oczekiwań skazana na niepowodzenie.
Nie oznacza to, iż znając zagadnienie i środowisko, w którym będzie prowadzony projekt nie
można dokonać opartego o analizę wyboru koncepcji, którą będziemy chcieli wykorzystać. W
przypadku takim należy próbować zestawić wszystkie możliwe do zebrania informacje na temat
charakteru pracy, oraz wiedzę na temat metod pracy i wybrać to, co w danym momencie wydaje
się spełniać w największym stopniu oczekiwania.
Najczęstszym podziałem prac, jaki przedstawiany jest dla Scrum i Kanban jest odpowiednio
realizacja nowych innowacyjnych projektów, oraz praca operacyjna. Przedstawione w tej pracy
rozważania dotyczące obu metod potwierdzają w pewnym sensie poprawność tej tezy. Nie jest
to jednak klucz, jakim należy się kierować, gdyż nie bierze on pod uwagę konkretnego zadania i
konkretnych warunków.
Czasem zastanowić się można czy nie byłoby korzystnym wykorzystanie elementów obu
koncepcji, co popularnie zwane jest aktualnie metodą Scrumban. Wszystkie decyzje powinny być
jednak dogłębnie przemyślane i dyktowane rzeczywistymi potrzebami i potencjalnymi
korzyściami a nie tylko chęcią wypróbowania czegoś nowego. Kanban niekonieczne jest,
39
bowiem naturalnym kolejnym krokiem prowadzącym do jeszcze bardziej zwinnego
wytwarzania oprogramowania.
Nie istnieje idealny Scrum, czy idealny Kanban. Celem obu tych metod jest zapewnienie ciągłej
adaptacji do zmieniających się przecież warunków zewnętrznych jak i wewnętrznych, oraz
poszukiwania rozwiązań bardziej odpowiadających aktualnie wykonywanej pracy.
40
BIBLIOGRAFIA
David J. Anderson: Kanban: Successful Evolutionary Change for Your Technology Business,
Blue Hole Press, 2010
Mike Cohn: User Stories Applied: For Agile Software Development,
Addison-Wesley Professional, 2004
Mike Cohn: Agile Estimating and Planning, Prentice Hall, 2005
Mike Cohn: Succeeding with Agile: Software Development Using Scrum,
Addison-Wesley Professional, 2009
Henrik Kniberg: Scrum and XP from the Trenches, InfoQueue, 2007
Henrik Kniberg, Mattias Skarin: Kanban and Scrum - making the most of both, InfoQueue, 2010
Ken Schwaber: Agile Project Management with Scrum, Microsoft Press, 2004
Ken Schwaber, Jeff Sutherland: The Scrum Guide, scrum.org, 2011
Mary Poppendieck, Tom Poppendieck: Implementing Lean Software Development:
From Concept to Cash, Addison-Wesley Professional, 2006
Mary Poppendieck, Tom Poppendieck: Lean Software Development course materials
Geoff Watts: Certified Scrum Master Training course materials
www.wikipedia.org
www.limitedwipsociety.org
blog.mountaingoatsoftware.com
requirements.seilevel.com/blog/