Trochę tym razem chciałbym podsumować moje własne poglądy na całość zbioru pod tytułem Agile. Wszyscy o tym wiedzą, ale dla własnego zsumowania wiedzy pokrótce chciałbym się podzielić moim aktualnym zdaniem na ten temat. Aktualnym, bo oczywiście poglądy ewoluują i niekoniecznie zgodzę się z samym sobą np. za rok czy dwa.
Agile jako całość – zaczynając od agile manifesto mówi o dopasowywaniu produktu do wymagań klientów i robieniu tego w trakcie tworzenia rozwiązań informatycznych. Czyli nic nie jest wyryte w kamieniu, jeśli na którymkolwiek etapie stwierdzimy, że coś jest nie tak, to nie brnijmy w to. Nie brnijmy tylko dlatego, że ktoś kiedyś wpisał to do projektu, planu, excel-a lub czegokolwiek innego. I w sumie chyba już na tym poziomie poważny zgrzyt. Bo niby to takie proste a chyba najtrudniejsze do zrozumienia – i do wdrożenia w życie.
XP – czyli eXtreme Programming porządkuje sferę developmentu w sensie wprowadzenia dobrych praktyk inżynierskich mających na celu tworzenie po prostu dobrego kodu. W wielu wymiarach. Począwszy od prostoty, poprzez czytelność, wymianę wiedzy i w pewnym sensie techniczną doskonałość na tyle na ile to możliwe. W sumie nie sam dobór narzędzi czy technik jest kluczowy ile zrozumienie filozofii i ducha XP.
Kanban – coś, co pozwala mieć zwinność na poziomie zespołów developerskich przy zachowaniu pewnego poziomu zorganizowania powyżej. W większości wypadków powinno chyba być podstawowym modelem – bardzo często tam gdzie pojawiają się architekci, analitycy biznesowi, roadmapy, plany wielomiesięczne itp. to tak naprawdę i tak jest to podstawowy model. Nawet jeśli celebrowane są ceremonie Scrum-owe to w praktyce mamy do czynienia raczej z Kanbanem. Scrum-but, mechaniczny Scrum czy różne inne eufemizmy doskonale to opisują.
Scrum – chyba najbardziej wypaczone pojęcie. Scrum-a trzeba mieć bo wszyscy mają, konsultant zalecił, zarząd kazał, developerzy chcą albo jeszcze milion innych równie ważnych powodów. Więc róbmy Scrum. No ale u nas akurat specyfika firmy powoduje, że … (tu następuje krótszy lub dłuższy wywód na temat czemu się nie da). W związku z tym musimy dopasować Scrum do realiów. Jak napisano w Scrum Guide – łatwy do zrozumienia, trudny w implementacji. Nic dodać nic ująć.
Wniosek jest w sumie trochę dziwny – przywiązanie ludzi do tradycyjnych sposobów planowania jest bardzo silne. Bo w większości wypadków już Agile manifesto jest problemem nie do przejścia. Pozwolę sobie zacytować:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Tia. Dorzuciłbym tu jeszcze jedną, niewynikającą wprost z manifestu ale chyba bardzo istotną cechę Agile. Wszystko to robimy w celu dostarczenia na czas produktu, z którego klient będzie zadowolony. I tak dobrego, jak tylko on może być w zadanym czasie i zasobach. Widziałem to w praktyce i wiem, że działa.
Co w sumie jest przeciwieństwem podejścia planowego – kiedy to po powstaniu planów powinniśmy dopasować zasoby do tego, co zostało wymyślone/zaprojektowane. Jak to działa w praktyce – każdy kto miał okazję zobaczyć w praktyce (ja wielokrotnie) wie.