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.