FanatykDemon NR.8Fanatyk Agile ma obsesje na punkcie “użyteczności”.
Będzie poszukiwał sposobów jak zwiększyć efektywność i produktywność swojego zespołu oraz samego siebie.
Przeczytał o tym wiele książek i teraz już wie jak to trzeba zrobić. Wystarczy tylko wprowadzić pewne zasady i procesy usprawnią się o 150% .
Istnieje jednak pewien problem.
Jego rozumienie filozofii Agile i ich implementacja nie jest elastyczna. Jest sztywna i mało ma wspólnego z tym jak rzeczywisty świat działa.
Fanatyk Agile chce dobrze. Chce usprawnić proces tworzenia oprogramowania.
Niestety zapomniał, że zasady powinny być elastyczne, bo niczego w programowaniu nie można zaplanować co do minuty jak nie godziny.
Zasady mają pomagać, a nie przeszkadzać i bardziej denerwować.
Zasady mają spełniać jakiś cel, ale co jeśli same zasady w pewnych przypadkach będą łamać te cele.
Przykład:
Jeśli rozwiązanie błędu trwa dłużej niż 8 godzin to trzeba go rozbić na mniejsze. Czyli stracić jeszcze więcej czasu na analizę problemu i jego podzielenie w systemie zgłoszeń. Co z tego system na produkcji teraz płonie.
Jeśli jakiś sprint trwa dłużej niż dwa tygodnie to musi być on podzielony. Bo sprint nie może trwać 14 dni roboczych. Stracimy czas na kolejny podział zadań.
Każde zadanie musi być rozpisane, nawet jeśli jego rozwiązanie trwa 5 minut, a jego opis i przekierowanie trwa 40 minut.
Jednak ten demon powie:
Żadnych wyjątków. Takie są zasady i musimy ich przestrzegać.
Wszystkie TFS-owe i GitHub-owe wyrzutki kodu muszą zostać wykonane po godzinie 15. Każdy pobiera kod codziennie rano o 8.
Żadnych wyjątków
Wszystkie zgłoszenia w JIRA mają być komentowane i aktualizowane co 4 godziny.
Żadnych wyjątków
Każdy programista może zajmować czas tylko wyznaczonemu programiście tak byśmy nie tracili czasu na pogaduszki.
Żadnych wyjątków
Żaden Stand-Up (codzienna pogawędka o swoich zadaniach) nie może trwać dłużej niż 10 minut.
Żadnych wyjątków
Demon Fanatyka Agile
Fanatyk Agile zapomniał, że celem procesów Agile jest E-L-A-S-T-Y-C-Z-N-O-Ś-Ć.
Elastyczność.
Istnieje pewien powód, dlaczego nazywa się to programowanie zwinne. Programowanie, które ma być dynamiczne i dostosowane do sytuacji. Ustalanie żelaznych zasad jest właśnie odwrotnością tego.
A potem system zarządzania zadaniami jak JIRA leży i kwiczy w paradoksach zasad i nierealnych obietnicach.
Wszystko może wydawać się proste na papierze, a nie w rzeczywistości.
Programiści zaczną uciekać od ustalonego terminarza, bo i tak on nie miał sensu. Nagle się okaże, że w fazie testów jest dopiero tworzone drugie 50% aplikacji, bo ktoś ignorował różowego słonia i zadowolił się swoim papierem zasad.
Wcześniej, czy później programiści się zbuntują albo zmienią pracę.
Jak poradzić sobie z fanatykiem Agile
Zapytać go o cel określonej zasady.
Właściwie to pytanie powinno padać za każdym razem, gdy występuje jakaś “zmiana” bo na tym polega elastyczność procesu.
A co jeśli jesteś fanatykiem Agile
Na podstawie życiowych doświadczeń i informacji zwrotnych od programistów zweryfikuj co działa, a co nie.
A potem wprowadź elastyczne zmiany.
