Scrum i Kanban. Analiza lekkich metod wytwarzania oprogramowania

0
6834

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

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.

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.

PODSUMOWANIA

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

Pełna treść publikacji
Autorem publikacji jest pan Kamil Dowlaszewicz

PODZIEL SIĘ
Redakcja 4PM.pl
Misją 4PM.pl jest pomaganie Project Managerom w ich codziennej pracy poprzez dostarczanie informacji i wiedzy z zakresu zarządzania projektami.

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ