Jest pierwsza sobota lutego 2011 roku. Po tygodniowym urlopie we Włoszech wracam autostradą A12 łączącą stolicę Alp, Innsbruck z Monachium i Salzburgiem. Wraz ze mną wraca pół zjednoczonej Europy. Drugie pół podąża w przeciwnym kierunku. Z mijanych dolin dołączają do nas kolejne samochody. Mimo dużego ruchu jedziemy w miarę szybko, gdy na wyświetlaczach umieszczonych nad drogą pojawiają się ograniczenia prędkości. Najpierw do 80-ciu, potem 60 km na godzinę. Względy bezpieczeństwa? Raczej nie, bo dzień jest słoneczny, a asfalt suchy. Zmniejszenie prędkości ze 130 km/h o połowę powoduje skrócenie drogi hamowania o około 3/4. To może jakiś wypadek? Też nie… Oto co się stało. Kilkanaście minut wcześniej i kilkanaście kilometrów dalej jeden samochód podjechał trochę za blisko drugiego i kierowca mocno przyhamował zwalniając z dozwolonych 130 km/h do setki. Ten za nim musiał przyhamować jeszcze mocniej. Następne auta zwalniają coraz bardziej, wreszcie któryś kierowca przeskakuje na sąsiedni pas powodując, że on również zwalnia. Chwilę później oba pasy stoją. Bez widocznej przyczyny tworzy się korek. Oczywiście dojeżdżające samochody natychmiast go powiększają. Korek szybko rośnie i już nie jest to kilka aut, ale ponad setka. Właśnie w tym momencie zapalają się ograniczenia prędkości przed moim samochodem. Jeżeli wszyscy uczestnicy ruchu będą przestrzegać przepisów, to zanim dojedziemy na miejsce, korek się rozładuje. Jeżeli będziemy pędzić, mamy gwarancję przymusowego postoju.
Ciągnij zamiast Pchać
Autostrada zadziałała jak system z ograniczoną przepustowością. Zbyt duża ilość samochodów spowodował zatkanie się drogi. Korek dla odmiany zmniejszył ilość samochodów przejeżdżających dany odcinek drogi w ciągu godziny. Dlatego, aby ponownie udrożnić drogę trzeba było zmniejszyć napływ nowych pojazdów. Zamiast pozwolić wszystkim jechać z największą prędkością i mieć nadzieję, że ci z tyłu klaksonami zmotywują tych na początku do szybszej jazdy, system pozwala dojechać kolejnym autom dopiero w momencie kiedy będą mogły płynnie przejechać.
Tym samym do regulacji systemu został wykorzystany model „ciągniony” (pull). Napływ kolejnych elementów (pojazdów) został ograniczony do momentu uzyskania płynności w danym miejscu, a tym samym zwiększenia jego przepustowości. Oczywiście, można pójść krok dalej, ustalając maksymalną ilość samochodów w systemie, np. stawiając bramki i wpuszczając kolejny pojazd dopiero kiedy inny przejedzie dany odcinek (czyli opuści system). Jednak w przypadku autostrady nie jest to optymalna metoda, gdyż nie rozwiązałaby problemu zatłoczonej autostrady, a tylko spowodowałaby korki przed bramkami. Rozwiązanie to stosuje się jedynie w specjalnych przypadkach, takich jak długie tunele lub drogi na przełęczach, gdzie mogą panować trudne warunki atmosferyczne.
Lean, czyli szczupła produkcja
Co ma autostrada z produkcją oprogramowania? Całkiem sporo. Najpierw jednak warto powiedzieć, co ją łączy z produkcją. W tradycyjnym podejściu tworzymy plan produkcji, a następnie przepychamy (push) wyroby przez cały system zgodnie z harmonogramem. Powoduje to olbrzymie problemy, a to tworzenie nadmiernych zapasów wewnątrz systemu, a to nadprodukcję, czyli wytworzenie produktów, na które nie ma zbytu. Dlatego alternatywną metodą, stosowaną od kilkudziesięciu lat w przemyśle na całym świecie, są systemy typu ciągnionego (pull). Są one oparte na koncepcji pracy linii produkcyjnych w fabrykach Toyoty (Toyota Production System, TPS) i wywodzących się z nich Szczupłych Systemów (Lean). Zamiast produkować wyroby nie patrząc czy jest na nie zapotrzebowanie, dopiero gdy pojawi się zamówienie będziemy jak najszybciej „przeciągać” je przez cały system. Żeby uniknąć nadprodukcji i gromadzenia zbędnych zapasów każdy element systemu (np. montażownia) informuje swojego poprzednika (np. lakiernię), kiedy jest w stanie pobrać następny wyrób. Tym samym unika się nadprodukcji półproduktów i gotowych produktów na które nie ma zbytu.
Karta Kanban
Ograniczając ilość wyrobów w systemie (Work in Progress, WIP) i odpowiednio ustalając maksymalną ilość tych wyrobów, mogących przebywać w jednym stanie (np. nie więcej niż pięć pojazdów może być na montażowni i siedem na lakierni), to uzyskamy samoregulujący się system, który bez odgórnej kontroli będzie pobierał kolejne elementy „ciągnąc” je przez cały cykl produkcji. Prostą i efektywną metodą wprowadzenia sztywnych limitów, jest wydrukowanie ograniczonej ilości kart. Każda karta zawiera opis związanego z nią wyrobu. I tak w naszym przykładzie lakierownia będzie posiadała siedem takich kart, a montażownia pięć. Lakierownia będzie mogła przesłać karoserię do montażowni, dopiero gdy ta dostarczy jedną kartę. Oczywiście w tym celu musi ona wcześniej przekazać jeden wyrób dalej. Ponieważ żaden wyrób nie może przebywać w systemie bez przypisanej mu karty, tym samym ilość elementów jest z góry ograniczona przez ilość kart. Ten wizualny znak, to po japońsku właśnie Kanban.
Kanban w usługach
Ponieważ system Pull sam się reguluje, koncepcja karty Kanban zaczęła być szeroko stosowana również poza przemysłem. Przychodząc na basen dostajesz klucz lub „zegarek”. Ilość zegarków jest ograniczona, dlatego służą one również jako karty Kanban. Dopóki jest mniej chętnych niż zegarków, cały system zachowuje się płynnie. Dopiero gdy pojawi się zbyt wiele ludzi, system zablokuje kolejnych chętnych przed kasami do czasu oddania zegarków przez osoby wychodzące. Dzięki temu nie spowoduje to ścisku uniemożliwiającego wypoczynek i korzystanie z basenu. Żadnej odgórnej kontroli i żadnego sterowania.
Kanban w Tworzeniu Oprogramowaniu
Jeżeli Kanban jest tak skuteczny zarówno w produkcji jak i w usługach, to dlaczego nie wykorzystać go przy tworzeniu oprogramowania? Oczywiście chcemy zastosować koncepcję „ciągnięcia” pracy, a nie kopiować wszystkie elementy z linii produkcyjnej. W tym celu musimy popatrzeć na wytwarzanie oprogramowania jak na przepływ informacji przez kolejne fazy systemu (np. analiza wymagań, kodowanie, testy i wdrożenie). Jako wyrób możemy traktować wszystko, co posiada wartość dla klienta. Mogą to być Historia Użytkownika (User Story), Przypadek Użycia (Use Case), błąd, zgłoszenie od klienta, funkcjonalność (Minimal Marketable Feature, MMF), czy też żądanie zmiany. Teraz wystarczy ustawić limity na ilość wyrobów dla każdej z faz i system Kanban gotowy. Dla przykładu poniższa tablica zawiera cztery fazy i limity przypisane do każdej z faz.
Limity nie są wyznaczone dla Rejestru Produktu (Backlogu), który może zawierać wszystkie „przyszłe” Historyjki oraz dla pracy już dostarczonej do klienta. Fazy analizy wymagań, kodowania i testowania maja dwie pod-kolumny: „W trakcie” (In progress) oznaczającą, że praca nad daną Historyjką wciąż trwa, oraz „Gotowe” (Done), skąd Historyjki będą pobierane przez następną fazę. Faza Wdrożeń nie potrzebuje takiego rozróżnienia, gdyż po ukończeniu pracy wdrożeniowcy przesuwają Historyjkę od razu do staniu „Dostarczone”. Tym samym nie blokują pojemności swojej fazy.
Zespół nie będzie nigdy pracował nad więcej niż 18-toma Historyjkami równocześnie (3 w analizie wymagań, 5 w kodowaniu, 4 w testach i 6 we wdrożeniu). Po osiągnięciu limitu w danej fazie, następna praca może być rozpoczęta dopiero kiedy kolejna faza „pociągnie” ukończoną Historyjkę. I tak gdy w fazie kodowania osiągnęliśmy maksimum pięciu Historyjek, to kolejną zaczniemy nie wcześniej niż gdy testerzy zaczną pracować nad jedną z już ukończonych. Żeby to nastąpiło, musi się najpierw rozpocząć wdrażanie przetestowanej już Historyjki. Dzięki temu limity Kanban powodują „przeciąganie” Historyjki, czyli jej przepływ przez cały proces tworzenia oprogramowania. Definiując jednoznaczne metody wybierania kolejnej Historyjki (np. najdłużej przebywającą w systemie) uzyskujemy samoregulujący się system. Wdrożeniowcy, testerzy, developerzy i analitycy pobierają następne zadanie według wyznaczonych reguł. Natomiast managerowie, zamiast zajmować się „przepychaniem” opóźnionej pracy, mogą skupić się na wspieraniu zespołu w rozwiązywaniu problemów. Jednocześnie limity Kanban nie pozwalają na „nadprodukcję”. Tym samym nie powstanie dokumentacja do dziesiątek historyjek, których nie będziemy w stanie zaimplementować, albo nie napiszemy kodu, którego nie będziemy mieli czasu przetestować. Dodatkowo ograniczenie pracy umożliwia szybki przepływ Historyjki przez system, co jest szczególnie ważne w projektach utrzymaniowych (maintenance). Ponadto, jeżeli nie został osiągnięty limit w pierwszej fazie (w powyższym przypadku mamy dwie Historyjki w trakcie analizy wymagań przy limicie trzech) to pracę nad nowym żądaniem od klienta możemy zacząć zaraz po zgłoszeniu.
Poprawa procesu gratis
Poza regulacją przepływu Kanban bardzo skutecznie pomaga odnaleźć wąskie gardła w systemie oraz wspiera współpracę zespołu przy rozwiązywaniu problemów i usuwaniu przeszkód. Ponadto wizualizacja procesu gwarantuje jego przejrzystość i ułatwia zespołowi jego ciągłe doskonalenie poprzez usuwanie nieefektywności i eliminacje strat. O tym wszystkim już w innym artykule.
