Scrum i Kanban. Analiza lekkich metod wytwarzania oprogramowania. Kamil Dowlaszewicz

Scrum i Kanban. Analiza lekkich metod wytwarzania oprogramowania Kamil Dowlaszewicz

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 2

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 3

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 4

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 5

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

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

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ę. 8

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

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 Ograniczenia dobierane w trakcie korzystania z metodę. metody. Możliwośd uzyskiwania szybkich rezultatów zależy Możliwośd uzyskiwania szybkich rezultatów, od wykorzystania. Liczba decyzji, które trzeba przy ograniczonej liczbie decyzji, które trzeba podejmowad i opartych o nie działao może byd podjąd. ogromna. Dużo zmian wykonuje się już w trakcie wdrażania metody, następnie w trakcie korzystania z metody realizowana jest optymalizacja procesu. Średni zakres możliwości dostosowywania do środowiska pracy. Proces wdrażania może byd długotrwały. Wdrożenie metody wymaga minimalnej liczby zmian. Większośd modyfikacji ma miejsce w trakcie korzystania z metody. Szeroki zakres możliwości dostosowywania do środowiska pracy. 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. 10

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

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

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ń 13

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

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 15

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 16

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 17

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

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ć 19

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 Niebezpieczeostwo przeładowania poprzez stosowanie źle wyznaczanych miar podczas nadmierną optymalizację wykorzystania planowania i penalizacji związanej z zespołu i restrykcyjności związanej z niedostarczeniem funkcjonalności 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, 20