Dekalogiem zawierającym esencję mindsetu zwinności jest Manifest Agile. Krótki dokument przedstawia nam wartości i zasady coraz częściej wybieranego podejścia do wytwarzania produktów. Ma on jednak moim zdaniem bardzo dużą wadę – czytany „sam” bez wsparcia w postaci dodatkowych (rzetelnych) źródeł wiedzy, przez swoją prostotę może być nieprawidłowo zinterpretowany.


W  artykule przedstawię 12 zaobserwowanych i subiektywnie najciekawszych błędnych interpretacji zasad Agile prowadzących do powstania antywzorców.

#1 Klient nasz Pan

Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.

 Koncentrując swoją uwagę na frazie „Najwyższy priorytet ma dla nas zadowolenie klienta” można dojść do wniosku, że klient jest w epicentrum uwagi. Idealną parą dla takiej interpretacji jest rozwiązanie „Klient nasz Pan”, najlepiej w  swej skrajnej postaci. Zgadzanie się na wszystko, co chce Klient szybko przynosi rezultat w postaci jego zadowolenia, jednak w  dłuższej perspektywie czasu, bez odpowiednio prowadzonej analizy, może doprowadzić do powstania produktu o  niskiej wartości. Ważny, a  często pomijany w  tej zasadzie jest łącznik „dzięki”. Podkreśla on, że satysfakcja klienta jest konsekwencją dostarczenia wartościowego produktu. To właśnie nie skupienie na kliencie, a  skupienie na produkcie powinno być pierwszorzędnym celem, ponieważ jest kluczem do długotrwałego zadowolenia.

#2 Pożarowy tryb zmian

Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.

„Bądźcie gotowi” oznacza dla wielu natychmiastową reakcję na zmiany. Pożarowy tryb działania daje poczucie „pchania” tematów do przodu, a  w  przypadku kluczowych dla rynku funkcjonalności, można nawet całkiem szybko osiągnąć konkurencyjność. Jest to jednak bardzo szkodliwe podejście, zazwyczaj doprowadzające produkt do stanu, w którym wprowadzanie kolejnych zmian staje się czasochłonne, a w ekstremalnych przypadkach – niemożliwe. Pryncypium skupia nas nie tylko na gotowości podejmowania zmian w  kontekście szybkości ale, co ważniejsze, w  kontekście umożliwienia ich implementacji nawet na późnym etapie rozwoju produktu. Możliwe jest to dzięki prowadzeniu w  całym cyklu wytwórczym odpowiedniego zarządzania wymaganiami, którego nie mogą zapewnić pożarowe reakcje. Takie podejście umożliwi tworzenie rozwijalnego produktu, co pozwoli klientowi osiągnąć konkurencyjność nie tylko na moment, a na dłuższy okres czasu.

#3 Testy na prodzie

Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.

Rozumienie „dostarczajcie” jako rozkazu powoduje, że zdawanie częstych i regularnych inkrementów staje się czymś obligatoryjnym. Wdrażane jest więc, kolokwialnie mówiąc, „cokolwiek”, aby sprawić wrażenie szybkiego postępu prac. Najczęściej są to elementy wątpliwej jakości, stąd użytkownicy końcowi doznają przeprowadzania tzw. „testów na prodzie”, co odbija się na wizerunku nie tylko firmy wykonawczej, ale przede wszystkim – klienta. Absolutnie nie jest obligatoryjnym, aby mimo wszystko dostarczać inkrementy! Należy dostarczać tylko te inkrementy, które spełniają określone kryteria ukończenia (np. DoD), dzięki czemu możliwe jest zdobycie wartościowej informacji zwrotnej i ograniczenie ryzyka utraty wizerunku.

#4 Rozmyte obowiązki

Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.

Biorąc zbyt dosłownie przykazanie o  współpracy, zespoły decydują się na codzienne spotkania, by wspólnie pracować. Najczęściej skupia się wtedy uwagę na problemach biznesowych przy których, w  przeciwieństwie do problemów technicznych, stosunkowo łatwo jest skoncentrować uwagę większej liczby osób. Wartość ogromna, „co dwie role to nie jedna”, ale należy pamiętać, że rozproszenie uwagi zespołu deweloperskiego wpływa na postęp prac wytwórczych leżących w jego zakresie obowiązków, a co za tym idzie – może być bezpośrednią przyczyną opóźnień. „Współpraca” oznacza w  Agile szybszą komunikację, negocjacje oraz kompromisy. Rozumiana jako rozmycie zakresu obowiązków jest błędna – każda z  ról musi mieć jasno określony zestaw zadań, za który jest odpowiedzialna. Ograniczenie zajmowania się sprawami leżącymi poza obszarem kompetencji staje się w perspektywie czasu, między innymi, oszczędnością czasu.

thodonal – stock.adobe.com

#5 Matkowanie

Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.

Zapewnienie odpowiedniego środowiska i  wsparcia często rozumiane jest jako „matkowanie”, czyli: niedopuszczanie do popełniania błędów, ochronę przed negatywnym feedbackiem, usuwanie każdej możliwej przeszkody itd… Przy takim podejściu, w krótkiej perspektywie czasu można zauważyć wzrost zadowolenia i  satysfakcji z  pracy deweloperów, jednak odbiera ono zespołowi niezbędną do jego wzrostu naukę na błędach, transparentność oraz samodzielność. Wsparcie zespołów powinno być tutaj rozumiane jako wzajemne podtrzymywanie się w  działaniach. Zamiast matkowania powinno się wybierać rozwiązania wspierające dążenie do samoorganizacji i samodzielności oraz umożliwiające zespołowi naukę. Tylko wtedy dawana jest mu możliwość rozwoju i brania pełnej odpowiedzialności za realizację zadań.

#6 Zakotwiczenie 

Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.

Czytając „twarzą w  twarz” z  reguły wyobrażamy sobie rozmowę odbywającą się w  jednym pomieszczeniu. Rygorystyczne podejście do zasady może zakładać więc absolutny zakaz pracy zdalnej. O  ile zakotwiczenie się w tej samej przestrzeni biurowej jest niepodważalnie wygodne, o tyle nie jest jednoznaczne z  efektywnością i  wydajnością, a  samo ograniczenie się tylko do pracy stacjonarnej powoduje, że zamykamy się na wielu specjalistów. Ważna w  tej zasadzie jest bezpośrednia komunikacja. W  dzisiejszych czasach jest ona bardzo prosta do osiągnięcia przy użyciu dedykowanych rozwiązań technologicznych. Posiadanie kamery, mikrofonu i  odpowiedniego oprogramowania umożliwia efektywną komunikację zdalną, dzięki czemu nie ograniczamy się do specjalistów z naszej lokalizacji i  możemy budować wartościowy, rozproszony geograficznie zespół.

#7 Na jedną miarę  

Działające oprogramowanie jest podstawową miarą postępu.

Wielu adeptów Agile ma jedną, jedyną miarę postępu – działające oprogramowanie. Jest to niezwykle wartościowa informacja, dająca ogólny obraz sytuacji… który z czasem może nie być wystarczający. Poleganie wyłącznie na „działającym oprogramowaniu” i  intuicji może sprawiać złudne wrażenie prawidłowego kierunku rozwoju, jednak aby rzetelnie badać progres i  móc nim sterować należy wprowadzić metryki wspierające. Taka interpretacja może być spowodowana tym, że czytając zasadę podświadomie pomija się wyraz „podstawową”. Istnieje wiele miar, z których możemy i powinniśmy korzystać np. miary związane z  udokumentowaniem funkcjonalności, znalezionymi błędami, wdrożeniami itd. Są one fundamentem do badania czy obrany kierunek rozwoju jest odpowiedni.

#8 Studnia bez dna

Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.

Możliwość rozwoju jest ogromną, jednak wciąż nadużywaną przez zespoły wytwórcze wartością. Oczywiście rozwój zespołu jest korzystny dla wszystkich stron i warto w niego inwestować, lecz często deweloperzy skupiają się na rozwoju tak bardzo, że koszt zaspokajania ich ambicji jest wyższy niż przynoszone korzyści biznesowe. Należy pamiętać, że każdy projekt jest maszyną do wypalania pieniędzy. Nie powinno się więc bez żadnej kontroli poświęcać całej uwagi na rozwój. Ważny jest tutaj balans, czyli rozwój w taki sposób, by być konkurencyjnym na rynku a przy tym nie zbankrutować.

#9 Perfekcjonizm

Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.

Narzędziem do zwiększenia zwinności jest doskonałość – w taki sposób zespoły mogą zrozumieć główną myśl tej zasady. To dzięki niej będziemy zdolni tworzyć produkt bezkonkurencyjny, ale pamiętajmy, że wymagać to będzie od nas czasu. Konsekwencją nadmiernej perfekcji mogą być rzadkie wdrożenia, czyli rzadsza pętla informacji zwrotnej, a co za tym idzie – mniej okazji do weryfikacji rezultatów. Skupienie na technicznej doskonałości i  dobrym projektowaniu nie polega na osiąganiu perfekcji. Pryncypium to mówi, że należy przygotować produkt w taki sposób, by umożliwić w przyszłości (chociażby) szybsze wprowadzanie zmian. Takie podejście pozwoli na jego odpowiedni rozwój i utrzymanie konkurencyjności.

#10 Cięcia technikaliów

Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.

Zasada ta postrzegana jest przez adeptów zwinności jako miejsce do optymalizacji czasu pracy. Wymaga się wtedy od zespołów, aby rezygnowały z pewnych rozwiązań technicznych bądź dobrych praktyk, które z punktu widzenia biznesu nie przynoszących korzyści a dodają tylko pracy. Praktykowanie takiej „optymalizacji” daje możliwość szybszego ukończenia zadań, natomiast długofalowo doprowadza do powstania produktu o niskiej jakości, zblokowanego na rozwój. W Agile rzeczywiście optymalizuje się… ale nie czas a zadania. Funkcjonalności poddaje się dekompozycji w  taki sposób, by ich elementy były możliwie jak najmniejsze. Błędne rozumienie zasady wynika z faktu, że „biznes” nie jest świadomy istotności „technikaliów”. Z  drugiej strony zaś często nie może sobie wyobrazić upraszczania funkcjonalności, a jedynie skupienie uwagi na elementach najważniejszych pozwala na szybsze utworzenie wartościowego produktu. 

#11 Anarchia

Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.

„Samoorganizacja” często rozumiana jest jako przyzwolenie na anarchię. Praca organizowana jest w taki sposób, że każdy robi co chce, kiedy chce i jak chce. Być może na początku taka dowolność jest wygodna, jednak bardzo szybko przeistacza się w  chaos rozwalający cały proces wytwórczy. Zespół samoorganizujący się to wbrew pozorom zespół z doskonałą wewnętrzną dyscypliną. Odpowiednio przygotowany do takiego stylu pracy i  liderowany nie będzie działał chaotycznie lecz w  sposób przemyślany. Zespoły samoorganizujące się są silnie zmotywowane, biorące odpowiedzialność za swoje działania – siła którą niosą jest niezastąpiona dla rozwoju produktu.

#12 Milczenie owiec

W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.

Szukanie możliwości poprawy wydajności często mylone jest z  wytykaniem palcem winnych. Często na retrospektywach można zauważyć, że zespoły milkną, próbując przetrwać, tym samym nie „wkopując” innych. O ile takie zachowanie można uznać za niezwykle solidarne, o tyle dla samego procesu jest krzywdzące, ponieważ bez analizy obszarów do poprawy, nie można mówić o dostrajaniu w celu optymalizacji wydajności działań. Wyciąganie wniosków z działań jest jednym z ważniejszych elementów zwinności. Szczera rozmowa podczas retrospektywy jest niezwykle ważnym punktem wyjścia do samodoskonalenia się, a milczenie oznacza odebranie tej możliwości.

Podsumowanie

Dla tych, którzy doświadczyli wymienionych antywzorców chciałabym wlać nieco otuchy. Błędy są bardzo ważnym i nieuniknionym elementem naszego życia oraz niezbędnym elementem rozwoju. Cytując Napoleona: „Tylko ten nie popełnia błędów, kto nic nie robi”. Pamiętajmy o tym!