„Scrum i Kanban. Analiza lekkich metod wytwarzania oprogramowania”

Kamil Dowlaszewicz

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/