Paweł Brodziński: Zacznę od banałów. Globalizacja postępuje bardzo szybko. Internet i jego powszechna dostępność, zmieniły nie tylko to, jak wygląda oprogramowanie, ale też dramatycznie zmieniły rynki: zarówno rynek dostawcy, jak i rynek odbiorcy. Dodatkowo znikają kolejne bariery chroniące rynki, pozwalające na spokojne czerpanie zysków z istniejących produktów. Konkurencja się zwiększa. To oznacza, że musi się też zmienić sposób działania firm. Modyfikacji ulega sposób zarządzania zmianą. Zamiast formalnego procesu porządkującego prace po stronie dostawcy, coraz częściej akceptujemy, że wymagania klienta się zmieniają i reagujemy na to na bieżąco. Efektem jest coraz szersza adaptacja metod Agile w tworzeniu oprogramowania.

Kolejnym widocznym trendem jest dążenie do skrócenia tzw. time to market, czyli czasu jaki upływa od momentu decyzji o realizacji do momentu, w którym użytkownik otrzymuje gotowy produkt. Dodatkowo coraz częściej zamiast dużego, dokładnie wyspecyfikowanego produktu zrealizowanego i dostarczonego jako całość, mamy do czynienia z rozbijaniem systemu IT na części i dostarczaniem ich przyrostowo. Przykładowo – czy użytkownicy „widzą”, jak dostarczane są nowe wersje Facebooka czy wyszukiwarki Google? W związku z tym konieczna jest zmiana metod wspierających proces tworzenia oprogramowania. Coraz szerzej rozpowszechnione są metody Agile, ze Scrumem na czele. Rynek zdobywają także bardzo pokrewne tzw. metody Lean, a w szczególności Kanban.

PB: Metody Lean mają swoje źródło w przemyśle motoryzacyjnym, a dokładniej w Toyota Production System (TPS), który powstawał w powojennych latach w Toyocie. TPS, który jest połączeniem filozofii zarządzania oraz zestawu praktyk, skupiał się na efektywnym działaniu organizacji jako całości i jest jednym z kluczowych czynników sukcesu, jaki osiągnęła Toyota (pozycja numer jeden na rynku producentów samochodów). Sukces TPS doprowadził do opisania metod stosowanych w Toyocie w sposób ogólny. Powstały spis zasad zyskał nazwę Lean Manufacturing. Wkrótce też metody Lean zostały wykorzystane w innych obszarach np. tworzenia oprogramowania, realizacji usług czy organizacji startupów.

Patrząc przez pryzmat branży IT, niewątpliwie Lean można wykorzystać w obszarze tworzenia oprogramowania. Kanban nie jest pierwszym podejściem do adaptacji zasad Lean w tej branży, jednak jest pierwszym, które stało się popularne.

Czym zatem jest Kanban? Najprostszą odpowiedzią byłoby powiedzenie, że jest to metoda wspierająca tworzenie oprogramowania czy zarządzanie projektami IT. Tyle że byłaby to odpowiedź nieprecyzyjna. Żadna z reguł Kanbana nie mówi wprost, jak tworzyć oprogramowanie czy zarządzać projektem informatycznym. Odnoszą się one na bardzo ogólnym poziomie do tego, w jaki sposób pracujemy. Wśród zasad Kanbana znajdziemy np. wizualizację przepływu prac, ograniczanie prac w toku oraz mierzenie przepływu zadań. Nie odnoszą się zatem do specyfiki branży IT, czy do projektów jako takich. Oznacza to, że nazwanie go metodyką zarządzania projektami lub tworzenia oprogramowania byłoby nadużyciem.

Wróćmy do pytania, czym Kanban jest. Na prostym, bardzo mechanicznym poziomie, Kanban jest narzędziem do zarządzania przepływem prac czy procesem. Jednak pozostawienie takiej definicji byłoby z kolei znacznym uproszczeniem. Efekt dobrego wdrożenia Kanbana wykracza daleko poza zorganizowanie procesu realizacji prac. Kanban jest narzędziem zarządzania i stymulacji zmian oraz usprawnień w organizacji. Możemy go używać równolegle do metodyki zarządzania projektami lub tworzenia oprogramowania i dzięki temu uzyskać efekt ciągłych usprawnień w organizacji. Usprawnień niezbędnych w kontekście zmian zachodzących w naszym otoczeniu.

PB: Kanban projektowany był z myślą o firmach pracujących nad tzw. knowledge work. Firmy produkcyjne to jedynie, i aż, źródło oraz inspiracja dla metody. Mogę zdecydowanie powiedzieć, że Kanban to jest narzędzie, które sprawdza się w projektach IT. Powiem więcej, sposób w jaki zdefiniowany jest Kanban, powoduje, że można go użyć na wielu poziomach. Korzystamy z niego nie tylko w zespołach projektowych, gdzie pomaga w efektywnej realizacji systemów, ale również w zarządzaniu portfolio projektów, gdzie pomaga nam decydować o angażowaniu się w kolejne zlecenia, a część naszych pracowników wykorzystuje go na poziomie indywidualnym (tzw. Personal Kanban), aby efektywnie organizować własne zadania. Oczywiście poszczególne podejścia różnią się szczegółami, ale jednocześnie są zgodne z zasadami opisanymi w metodzie.

PB: Można powiedzieć, że są dwie grupy korzyści. Pierwsza z nich to zyski, które przychodzą szybko i ze stosunkowo małym wysiłkiem. Czasem półżartem mówię, że tablica kanbanowa, czyli główne narzędzie wykorzystywane w metodzie, jest dla mnie narzędziem magicznym – znacząco zwiększa dostępność wszelkiego typu informacji związanych z projektem: statusu zadań, odpowiedzialności za nie, ewentualnych problemów, itp.

Dodatkowo samo przygotowanie wdrożenia Kanbana wymusza na zespole konieczność uporządkowania pewnych obszarów. Rzeczą, która mnie fascynuje za każdym razem, kiedy pomagam kolejnemu zespołowi wdrożyć Kanbana, jest zmapowanie procesu, zgodnie z którym pracują, na tablicę. Wydawałoby się, że zadanie powinno być bardzo proste – w końcu jest to proces, zgodnie z którym zespół pracuje na co dzień, często od wielu miesięcy. Tyle, że jeszcze nie spotkałem zespołu potrafiącego go opisać bez trudności. Kiedy zaczynamy analizować, co się dzieje w specyficznych przypadkach np. zgłoszenie błędu krytycznego, prośba kogoś z VIPów o realizację zadania „na wczoraj”, okazuje się, że proces, który miał być oczywisty, wcale oczywisty nie jest i warto pewne jego elementy jednoznacznie zdefiniować.

Kolejnym szybkim zyskiem z wdrożenia Kanbana jest uświadomienie sobie trudności, z którymi boryka się zespół projektowy. Bardzo często członkowie zespołu skupiają się wyłącznie na realizacji swoich zadań: programiści na pisaniu kodu, inżynierowie jakości na testowaniu, itd. Przy czym często okazuje się, że problemy nie leżą bezpośrednio ani w jednym ani w drugim obszarze, a gdzieś pomiędzy. Jeżeli programiści są w stanie tworzyć nowe funkcjonalności w tempie przewyższającym to, jak szybko są one weryfikowane przez testerów, wkrótce mamy gigantyczną kolejkę zgłoszeń do weryfikacji. Każdy z członków zespołu indywidualnie pracuje świetnie, ale zespół jako całość jest nieefektywny. Wdrożenie Kanbana bardzo szybko pokazuje takie problemy.

PB: Drugą grupą korzyści z wdrożenia Kanbana są te, na które trzeba poczekać trochę dłużej. Są one również warunkowane konsekwencją działania i jakością samego wdrożenia. Są to jednocześnie korzyści warte znacznie więcej.

Charakterystyczne dla Kanbana ograniczanie prac w toku, powoduje, że sposób pracy całego zespołu zaczyna się powoli zmieniać. Trudno wskazać, w jaki konkretnie sposób, gdyż jest to mocno związane ze specyfiką pracy zespołu. W skrócie, tam, gdzie pojawiają się problemy, lub praca zespołu jest nieefektywna, dostajemy swego rodzaju zachętę do zmiany działania.

Trzymając się przykładu z programistami tworzącymi funkcjonalności szybciej niż testerzy są je w stanie zweryfikować: dzięki limitom prac w toku, członkowie zespołu będą w pierwszej kolejności skupiać się na rozładowaniu prac w wąskim gardle, w tym przypadku w testach. Początkowo mogą to być działania doraźne. Jednak gdy sytuacja powtarza się po raz kolejny, zespół dostaje impuls do rozwiązań systemowych, np. przygotowania narzędzi automatyzujących testy, wprowadzenia zasad podnoszących jakość tworzonego kodu, uproszczenia problematycznych części systemu, itp. W efekcie, dostajemy listę usprawnień, które bardzo często nie tylko rozwiązują zaobserwowany problem, ale jednocześnie podnoszą standardy pracy zespołu.

Ten mechanizm usprawnień często przenosi się na kolejne poziomy – organizacji procesu czy pracy innych zespołów. W dłuższej perspektywie oznacza to nie tylko zwiększenie efektywności prac zespołów, ale również większą elastyczność w odpowiedzi na potrzeby rynku.

PB: Nie ma prostej odpowiedzi na to pytanie. Dużo zależy od tego, w jaki sposób jest ułożona współpraca na linii klient-dostawca. Wprowadzenie Kanbana doprowadza do większej elastyczności dostawcy. Pytanie brzmi, czy klient może i chce z tej elastyczności skorzystać. Zależy to od segmentu i branży, w której działa. Coraz częściej jednak właśnie takie są oczekiwania rynku.

Dzięki podwyższeniu elastyczności dostawca szybciej reaguje na zlecenia klienta. Iteracyjne metody tworzenia oprogramowania (np. Scrum) pozwalają decydować o priorytetach dalszych prac na początku każdej iteracji (np. co 2 tygodnie). Jednocześnie w czasie iteracji zespół oczekuje, że będzie izolowany od zmian. Kanban, jeśli taka jest potrzeba, pozwala by klient każdorazowo decydował o kolejnej funkcjonalności, która jest realizowana, nawet jeżeli takie decyzje zapadają kilka razy w tygodniu! Dostarczanie nowych wersji może się wówczas odbywać za każdym razem, kiedy dana funkcjonalność jest zakończona. Skraca to czas potrzebny na wykorzystanie informacji zwrotnych i znacznie zwiększa elastyczność w kreowaniu produktu przez klienta.

W przypadku rozległych projektów z obszerną specyfikacją taka elastyczność jest potrzebna bardzo rzadko. Wrócę jednak do tego, jak zmienia się nasza branża – coraz rzadziej będziemy mogli sobie pozwalać na realizację projektów w takim trybie. Coraz większa część rynku oprogramowania będzie kierowana bezpośrednio do użytkownika końcowego, a elastyczność w realizacji nowych funkcji i reakcji na feedback użytkowników będzie kluczową przewagą konkurencyjną.

PB: Kanban ucieka jasnym definicjom. Dlatego zwykle potrzeba pewnego wysiłku, aby przekonać zespoły czy firmy do adaptacji tej metody. Biorąc pod uwagę fakt, że reguły Kanbana są zdefiniowane na ogólnym poziomie, nie dają prostych odpowiedzi na pytanie „co zrobić żeby było lepiej?”, a czasem takie jest właśnie oczekiwanie firmy. Mimo swej prostoty Kanban zwykle wymaga zrozumienia jak i dlaczego działa. Nie jest to narzędzie, które rozumiemy intuicyjnie.

Samo wdrożenie Kanbana rzadko przysparza trudności. Aby jednak w pełni skorzystać z jego dobrodziejstw, potrzeba codziennej wytrwałości i konsekwencji w korzystaniu z metody. Najczęstszym powodem nieudanych wdrożeń Kanbana jest właśnie fakt, że poszczególni członkowie zespołu przestawali się angażować w codzienne drobne obowiązki, takie jak aktualizacja tablicy kanbanowej, i w efekcie zyski z wdrożenia metody były systematycznie trwonione.

PB: Przede wszystkim celem jaki powinniśmy sobie stawiać wdrażając tę metodę. Kiedy myślimy o najpopularniejszych podejściach Agile – Scrumie czy eXtreme Programming – szukamy przede wszystkim konkretnych odpowiedzi na pytania: jak powinna wyglądać organizacja naszego projektu, jak powinniśmy tworzyć oprogramowanie. Z jednej strony to wyznacza jasną drogę, jaką chcemy podążać. Z drugiej buduje barierę wejścia – nie każda firma chce, albo wręcz może, dostosować się organizacyjnie np. do zasad opisanych przez Scruma.

Na tym tle jedno z pryncypiów Kanbana - „zacznij z tym, co masz obecnie” – pokazuje, że Kanban jest metodą działającą odwrotnie. Daje się zaaplikować w dowolnych środowiskach i nie wymaga natychmiastowych zmian, czy też dostosowania organizacji do określonego sposobu funkcjonowania. W zamian dostajemy narzędzie nie dające instrukcji, a raczej stymulujące i wspierające proces ewolucyjnych zmian w organizacji.

Gdyby spojrzeć na to z innej strony, tak jak moglibyśmy powiedzieć, że istnieje podręcznikowe wdrożenie Scruma, tak nie istnieje podręcznikowe wdrożenie Kanbana – każde z nich będzie inne, bo będzie dostosowane do specyfiki zespołu oraz firmy. Celem wdrożenia Kanbana nie jest bowiem zmiana organizacji w konkretny sposób, a raczej wprowadzenie zespołu czy firmy na ścieżkę ciągłych usprawnień.