Blog

Wszystkie metody, praktyki i techniki należące do rodziny Agile opierają się o te same pryncypia: mechanizm empiryczny, Manifest Agile oraz 12 Zasad Zwinnego Tworzenia Oprogramowania.

Najważniejszym jest tu istnienie mechanizmu empirycznego – wszystko, co zostało w 2001 roku zawarte w Manifeście i Zasadach wywodzi się właśnie z niego (a wiele metod bazujących na empiryzmie, jak Scrum, XP, Crystal czy Kanban istniało wiele lat wcześniej, nim ukuto termin Agile).

Mechanizm empiryczny składa się z trzech elementów: inspekcji (sprawdzamy jaki jest stan faktyczny), adaptacji (dostosowujemy się, żeby lepiej osiągać cel), przejrzystości-transparencji (zapewnienia, że działamy na prawdziwych danych). Często opisuję go jak termostat – wyobrażamy sobie mechanizm z pokrętłem, który mierzy temperaturę w pomieszczeniu (inspekcja), dostosowuje ją do temperatury zadanej (podnosi, obniża – adaptacja) oraz działa w przejrzystych warunkach (np. nie kładziemy na nim mokrego ręcznika zaburzającego odczyty).

Potrzebujemy empirii przy budowaniu produktów, ponieważ dziedzina produkcji oprogramowania jest złożona – trudno przewidzieć wiele rzeczy, zmiany następują szybko, wymaga dużej wiedzy, często też znamy postawione cele, ale istnieje wiele dróg ich osiągnięcia (technologicznie, biznesowo itd.), a my chcemy je eksplorować, by wybierać te efektywne i maksymalizujące wartość. Nie możemy usztywniać się na realizacji planów rozpisanych na zbyt daleko do przodu, bo wiele czynników zmieni się, a wiele innych nie umiemy nawet dziś przewidzieć.

Dlatego każda metoda czy technika agile’owa jest: empiryczna, inkrementalna (przyrostowo dodaje wartość w produkcie), i iteracyjna (ma stałe cykle pracy). Dzięki tym trzem cechom, produkty budowane w sposób zwinny, mogą być zmieniane i dostosowywane w częsty, acz przemyślany i umotywowany biznesowo sposób.

Czym się charakteryzuje Scrum?

Obecnie istnieje ponad sto różnych metod i narzędzi pod wspólną etykietką Agile. Najpopularniejszym wg badań VersionOne jest Scrum (lub Scrum łączony z innymi metodami, jak np. ScrumXP), z którego korzysta ponad 60% badanych organizacji. Scrum jest metodą ramową, która porządkuje nieco proces budowania złożonych produktów. Nie wdając się szczegółowo w opis, Scrum ma pięć zdarzeń (punktów inspekcji i adaptacji w konkretnym czasie), trzy role oraz trzy artefakty (przedmioty poddawane tej inspekcji) i jako opisany koncept pochodzi z lat 90. Jest „ramowy”, ponieważ jedynie nakłada pewną formę postępowania, ale nie wyjaśnia żadnej „treści” wewnątrz owej „formy” – ten kontekst zależy tylko od zespołu/organizacji używającej Scruma.

Scrum używany jest do budowania złożonych produktów, głównie oprogramowania. Pozwala na eksplorację nowych pomysłów biznesowych lub technologicznych, minimalizuje ryzyko eksperymentowania dzięki stałym iteracjom, oraz na koniec każdej iteracji oddaje nam do rąk używalny przyrost produktu. Dzięki temu świetnie się sprawdza, kiedy chcemy utrzymać stałe tempo rozwoju produktu, którego nie możemy szczegółowo zaplanować na starcie.

Czym się charakteryzuje Kanban?

Kanban jest nie tyle metodą, co pewną strategią optymalizacji przepływu pracy zapożyczoną z japońskiego przemysłu samochodowego (Toyota). Chociaż korzeniami sięga lat 50. i świata Lean, to w Agile jego odmiana Kanban Software Development stawiana jest w rankingu popularności na drugim miejscu. Kanban pomaga zwiększyć efektywność danego procesu, i niekonieczne będzie to proces produkcji oprogramowania. Z Kanbana dobrze też korzysta się w świecie HRu, marketingu, call center czy dziale prawnym – wszędzie tam, gdzie kolejność pracy nie tyle zależy od wartości w produkcie (jak w Scrum), co jest po prostu kolejką tematów do zajęcia się.

Cztery zasady Kanbana to:

1. Wizualizacja przepływu pracy (często kojarzona z kanbanem w japońskim znaczeniu, czyli tablicą, na której różne kolumny i karteczki oznaczają postęp prac).
   Ograniczanie ilości pracy w toku.
2. Aktywne zarządzanie obecną pracą w toku.
3. Poddawanie przepływu pracy inspekcji i adaptacji.

Jak widać, Kanban nie wymusza na starcie żadnych zmian w już istniejącym procesie. Pomaga go tylko zwizualizować, zacząć mierzyć podstawowe metryki i dzięki temu usprawniać. Kanban nie zakłada planowania pracy, lecz obsługę kolejki incydentów.

Owszem, mogą istnieć dwie dodatkowe role (Service Request Manager odpowiedzialny za rozwijanie produktu i potrzeby klientów oraz Service Delivery Manager odpowiedzialny za flow procesu), nie ma żadnych stałych zdarzeń, jedynie kadencje – czyli pętle informacji zwrotnej (może ich być aż siedem). Najważniejsze metryki kanbanowe to:

1. lead time – pełen czas od zgłoszenia incydentu przez klienta do otrzymania gotowego rozwiązania. Chcemy, by malał.
2. cycle time – czas, który zespół spędza nad aktualną pracą nad rozwiązaniem. Chcemy, by malał.
3. throughput – przepustowość, czyli ile jednostek pracy (zadań, karteczek, story pointów itd.) zostaje wykonanych w jednostce czasu (w ciągu dnia, tygodnia itd.). Będzie dobrze, jeśli wzrasta.

Którą z nich wybrać i do jakich zastosowań?

Pomocne w wyborze między Scrumem a Kanbanem są trzy pytania:

1. Jaki rodzaj pracy będzie wykonywać zespół?
2. Czy będzie istniała wspólnota pracy, praca zespołowa, czy też każdy członek zespołu swoje zadania może wykonywać samodzielnie i niezależnie?
3. Czy jest ważne utrzymanie stałego tempa pracy i rozwoju produktu?

Rodzaj pracy

Jeśli można przewidzieć, zaplanować i ustabilizować pracę na bliski horyzont czasu (między 1 a 4 tygodniami), prawdopodobnie powinniśmy stosować Scrum. Dzięki temu ryzyko, że nawet „przestrzelimy” z efektami naszej pracy lub utkniemy nad trudnościami kosztuje nas tylko tę jedną iterację. Praca eksploracyjna, eksperyment, odkrywanie niepewnego lub poszukiwanie najlepszego rozwiązania (znamy cel, nie znamy ścieżki dojścia) – to domena Scruma.

Natomiast, jeśli nie liczy się planowanie, bo i tak obsługujemy kolejkę pracy zgodnie z jakąś regułą, to warto rozważyć Kanban. Ostatecznie służy on procesom, więc jego efektem w przeciwieństwie do Scruma może nie być produkt (np. trudno wskazać, co byłoby produktem konsultantów call center lub zespołu prawników sprawdzających zgodność naszych usług z obowiązującymi przepisami). Prace administracyjne, utrzymanie, kolejka do wykonania, spływające zapytania – jeśli cokolwiek jest trudne do zaplanowania lub wręcz niemożliwe do przewidzenia (np. nie wiemy, ilu klientów i z jak trudnymi pytaniami zadzwonią do konsultantów), a może być obsługiwane tablicą z kolejką incydentów – oto dobre pole dla Kanbana.

Wspólnota pracy

Scrum wymaga wspólnoty pracy w zespole. Ma opisane role Developerów, Product Ownera i Scrum Mastera, którzy wspólnymi siłami przekładają potrzeby biznesowe na używalny produkt. Ma limit wielkości zespołu. Zespół powinien pracować razem, uzupełnia swoje zdolności (jest wszechstronny – ma wszystkie kompetencje potrzebne do zbudowania produktu), a wszystkie role po równo odpowiadają za przyrost produktu.

W Kanbanie może nawet nie istnieć zespół – w sensie grupy mającej wspólny cel i współdziałającej ze sobą – bo każdy może swoją pracę wykonywać sam (wróćmy znowu do przykładu z call center). Kanban jedynie obrazuje przepływ pracy, może wykazać pewne ograniczenia (np. tylko niektóre osoby mogą wykonać jakąś czynność, ktoś czeka aż ktoś inny skończy swoje zadanie itd.). Dobrze jednak wprowadzić rolę Service Delivery Managera, jako osoby dbającej o flow, uczącej i przypominającej o inspekcji, adaptacji i przejrzystości.

Stałe tempo pracy

W Scrumie istnieje coś w rodzaju dżentelmeńskiej umowy: Product Owner zamraża część wymagań, obiecując że w danej iteracji ich nie zmieni, żeby Developerzy mogli je przekuć w przyrost produktu, a Developerzy dają Product Ownerowi wolną rękę w pracy nad pozostałymi, niezamrożonymi wymaganiami. Ten cykl pracy, zwany Sprintem, ma stałą długość i pozwala nadać rytm pracy. Na koniec każdej iteracji powstaje coś gotowego i potencjalnie wydawalnego (tzn. Product Owner zawsze może to wydać przynajmniej na koniec iteracji, ale jest to jego biznesowa decyzja). Wymagania są segregowane względem wartości w produkcie, przez Product Ownera, na liście zwanej Product Backlogiem.

Kanban zakłada, że zmiana może się zadziać w każdym momencie. Dlatego nie da się ani przewidzieć ile pracy wpadnie do kolejki, ani nie trzeba czekać na rytm iteracji – po prostu ile razy coś jest skończone, może być wydane. Kanban jest też systemem pull – wciąganie pracy do wykonania następuje od razu, gdy poprzednia jest ukończona. Nakłada się jednak tzw. kadencje (pętle inspekcji i adaptacji), żeby utrzymać empiryzm.

Oczywiście – jak wszystko w świecie Agile – wybór między Scrum i Kanban jest bardzo kontekstowy. Zależy od wielu czynników, a ten artykuł ma poddać pod rozwagę te najczęściej spotykane. Jeśli nadal nie ma pewności co do zasadności jednej lub drugiej metody, proponuję… podejście empiryczne. Warto wypróbować obie i zobaczyć, która przynosi lepsze efekty (czyli zapewnia lepszą przejrzystość, pozwala usprawniać proces i podnosi wartość biznesową).