Umówiliśmy się w zeszłym tygodniu, że wrzesień będzie tym miesiącem, w którym raz z tygodniu pojawi się temat związany z Kanban. Wiem, że czekaliście na drugą część opisu techniki. Nie chcę się skupiać wyłącznie na aspektach teoretycznych, dlatego dziś o wykorzystaniu Kanban w tworzeniu oprogramowania.
Tylko do błędów
Najczęściej słyszanym stwierdzeniem, jeśli chodzi o Kanban i tworzenie oprogramowania to „idealnie pasuje do zespołów utrzymaniowych” lub „świetnie się sprawdza w zarządzaniu ticketami w Jira„. Pewnie jedno i drugie stwierdzenie jest prawdziwe. Powoduje jednak, że metodyka Kanban spychana jest do nielubianego przez wielu miejsca, jakim jest utrzymanie systemów.
Myślący w sposób opisany powyżej zakładają, że duża zmienność wymagań i ich szybka fluktuacja mogą wskazywać, że zastosowanie standardowego timebox w postaci Sprintu spowoduje paraliż naszej pracy. „Co zrobimy jak wykonany wszystkie zaplanowane prace?”, czy „Co zrobić, jeśli po planowaniu wpadnie nam nowy ticket? Te dwa pytania sugerują, że nie możemy działać w stałym przedziale czasu. „Timebox nie jest dla nas!” Czy aby na pewno?
Zmienność
Wydaje się, że odpowiedzią na dużą zmienność wymagań w projektach Scrum jest odpowiednio dopasowana długość Sprintu. Pracując w jednotygodniowym Sprincie mamy możliwość odpowiedzi na szybko zmianę wymagań. Proste. Co więcej, wydaje się, że wytrąca to argument z ręki tym, którzy twierdzą, że „się nie da”. Skoro już wiemy, że jesteśmy w stanie działać Sprintach w utrzymaniu to jesteśmy też pewnie w stanie działać w metodyce Kanban rozwijając oprogramowanie. Nie mylicie się.
Dokładanie 10 lat temu (z dokładnością do roku) niejaki David J. Anderson opublikował książkę Kanban: Successful Evolutionary Change for Your Technology Business, w której opisał koncept wykorzystania Kanban w tworzeniu oprogramowania. Tworzeniu, a nie utrzymaniu. Na to jedno, ważne słowo chciałbym zwrócić szczególnie uwagę.
Wiem, zaraz usłyszę, że Kanban w opisywanej książce jest jeszcze bardziej okrojonym Scrumem, i że „możemy go używać w małych projektach, gdzie w prace zaangażowany jest góra jeden zespół”. Nieprawda.
Kanban w tworzeniu oprogramowania
Ramy, jakie narzucił autor książki wydają się być niezbędnym minimum, aby z jednej strony zapewnić implementację podstawowych założeń Kanban a z drugiej spowodować, że to co chcemy wyprodukować naprawdę będzie możliwe do stworzenia. David zdefiniował 3 podstawowe zasady w tworzeniu oprogramowania przy wykorzystaniu tej właśnie metodyki.
Pierwszą z nich jest tak bardzo dziś trudna do utrzymania wizualizacja. Najlepiej, gdy mamy z nią do czynienia w postaci fizycznej. Dziś jednak, w erze middle-COVID nie jest to możliwe do zapewnienia. Jeśli nie możemy tego zrobić fizycznie w biurze, to zapewnijmy, aby w elektronicznym narzędziu, z którego korzystamy, proces wytwarzania oprogramowania w naszej firmie podzielony został na faktycznie występujące fazy.
Najczęściej spotykana sekwencja kroków to BA -> DEV -> QA. Oznacza to, że zajmując się tworzeniem naszego oprogramowania w pierwszej kolejności analizujemy je, później pracujemy nad nim tworząc kod, na końcu zaś poddajemy je testom aby zweryfikować jego poprawność. Uważamy w tym przypadku na Waterfall i jego inne odmiany (jak np. mini-waterfall)! Nie przestanę tego przypominać NIGDY!
Po wizualizacji czas na ograniczenie pracy w toku (ang. Work in Progress). Pisaliśmy już o tym dużo, nie będę się więc powtarzał. Warto jednak ponownie zaadresować przyczyny, dla których powinniśmy ją ograniczać. Praca w toku nie tworzy nam przyrostu. Im jej więcej, tym częściej spotykamy się z koniecznością próby efektywnego multitaskingu, co jak już wiemy z efektywnością ma niewiele wspólnego.
W końcu po trzecie, zarządzajmy przepływem. Mierzmy, sprawdzajmy, weryfikujmy, usprawniajmy. Wykorzystajmy do tego wszystkie znane i dostępne nam mierniki po to, aby maksymalnie zoptymalizować proces wytwórczy. Sprawdzajmy też regularnie, czy dostarczane elementy oprogramowania są pożądane przez naszego interesariusza. Bo powinny!
Zawsze jednak się da
Przeczytawszy powyższe wszyscy dojdziemy do tego samego wniosku. Gdzie lista wymagań i gdzie zarządzanie zakresem? W jaki sposób uzgadniać najważniejsze elementy? Co my właściwie mamy robić? To wszystko prawda.
Wykorzystanie Kanban w tworzeniu oprogramowania to nie kompletny opis prac, które powiedzą nam jak mamy zorganizować projekt. To koncept, który skupia się na optymalizacji sposobu naszej pracy. Ma to jednak swoją zasadniczą zaletę.
Dzięki powyższemu, każdy z nas, w każdym z projektów, które wspieramy może wdrożyć te trzy proste punkty i spowodować, że będzie się nam pracowało lepiej. Właśnie na poziomie Zespołów Deweloperskich. Wydaje się, że w tych trzech punktach kryje się pragmatyzm i przepis na to, jak możemy ułatwić sobie pracę. W tych trzech punktach odnajdą się także osoby zarządzające projektem, Scrum Masterzy, Agila Coach i inni. Pomiary z wykorzystaniem dostępnych miar, wyciąganie wniosków, Gemba Walk, jednym słowem mówiąc zbieranie danych i optymalizacja.
Na koniec pytanie czy warto? Jasne. Nic nas to nie kosztuje, dosłownie. Szybka decyzja i szybkie efekty w postaci informacji zwrotnej z eksperymentu. Spróbujecie?
