Zanim wybierzesz Agile

Data: 2018-11-05
Autor: Sebastian Konkol
Zanim wybierzesz Agile

Jestem fanem zwinności – nie tylko w rozwoju oprogramowania, ale w zarządzaniu projektami, a przede wszystkim w architekturze rozwiązań informatycznych, na każdym poziomie. Rozumiem jednak także ograniczenia podejścia agile. Wdrażając podejście zwinne w nieprzygotowanym środowisku nie tylko dramatycznie obniża szanse na sukces, ale także deprecjonuje to podejście i na dłuższy czas tworzy konotację agile = porażka. Zanim więc wybierzesz podejście zwinne upewnij się, że środowisko działania ma szanse je przyjąć i wspierać. Jak to zrobić?

Podejście agile jest skuteczne w określonych warunkach. Skuteczne, czyli w porównaniu z alternatywami daje większe prawdopodobieństwo wytworzenia wartości biznesowej. Podejście agile nie jest ani lepsze, ani gorsze od alternatyw – to podejście opiera się na działaniach podporządkowanych zarządzaniu określonym niepewnościom i czynnikami ryzyka. Gdybym miał określić kryteria oceny prowadzące do wyboru podejścia do realizacji projektu, skupiłbym się na następujących elementach:

  • Stabilność wymagań biznesowych. To podstawowa cecha podejścia zwinnego – gotowości do akceptacji zmian podporządkowano sposób działania w zwinnym podejściu. Pamiętajmy jednak, że odbywa się to kosztem zwiększenia ryzyka dokonywania korekt i poprawek w zrealizowanej już części prac. Im bardziej zmienne są wymagania lub priorytety ich realizacji, tym większe znaczenie ma zdolność amortyzacji zmian. Nie można tego jednak mylić z sytuacją braku wymagań, a często slogan „zróbmy to agile’owo” jest synonimem sytuacji braku pomysłu na osiągnięcie celu projektu.
  • Złożoność rozwiązania. Zarządzanie złożonością jest niezwykle kosztowne. Im bardziej złożone rozwiązanie, tym większa niepewność jego działania. Im więcej fundamentalnych wymagań architektonicznych (ASR, Architecturally Significant Requirement), bardziej złożona integracja, czy więcej „starych” systemów (legacy) tym trudniej zapewnić spójność rozwiązania. Im większe ryzyko techniczne, tym mniejsze szanse na powodzenie podejścia zwinnego. Rzecz jasna, ryzyko techniczne to nie jest brak wiedzy czy kompetencji.
  • Oczekiwanie szybkich efektów. To raczej powszechna cecha, nie tylko współczesnego biznesu, ale cywilizacji jako całości – niestety, coraz częściej bezrefleksyjna, „bo tak”, bez wyważenia kosztów i ryzyka. Im większy nacisk na osiąganie wcześniejszych wyników, cząstkowych czy tzw. Quick Wins, tym więcej przemawia za podejściem zwinnym, gdyż skupia się ono na dostarczaniu jakiejś wartości co określony kwant czasu, choć kosztem osiągnięcia celu ostatecznego w sposób nieoptymalny. W tej sferze trzeba jednak uważać na sytuacje oczekiwania szybkich efektów nie z powodów uwarunkowanych biznesowo, a raczej z powodów politycznych, podtrzymania zainteresowania projektem, czy jego wewnętrznego PR.
  • Kultura organizacyjna. Nic trudniejszego nie może spotkać projekt, niż zderzenie z organizacją. Zwinność nie jest możliwa do osiągnięcia bez odpowiedniej kultury organizacyjnej. Realizacja projektu w tym trybie zakłada współpracę i zaufanie – bez tego agile nie ma najmniejszych szans na zadziałanie. Jeśli więc organizacja jest przesiąknięta polityką, relacyjnością, silosowością (wiecie już, o czym mówię), każde podejście agile będzie – w najlepszym wypadku – drogą przez mękę. Projektów zwinnych nie robi się pomimo organizacji – one się udają, bo współpraca, otwartość i zaufanie są osadzone w DNA organizacji. To są krytyczne cechy dotyczące zarówno zespołu projektowego jak i odbiorców wyników projektu.
  • Doświadczenie. W pracy każdego eksperta tworzona jest podświadoma warstwa wspomagająca podejmowanie decyzji z dziedziny wiedzy eksperta. To wspomaganie przejawia się istnieniem niezwerbalizowanej wiedzy dziedzinowej i podświadomymi procesami podejmowania decyzji. Często nazywam to przeczuciem, syndromem „pamiętam jak to będzie”. Braki w tej sferze wymagają większego wysiłku na podejmowanie decyzji i wymagają więcej czasu. Jeśli więc w zespole nie ma ekspertów dziedzinowych, doświadczonych architektów czy programistów, zwinność może być paraliżowana przez procesy decyzyjne. Może być jednak gorzej, kiedy w zespole eksperci są, ale otoczenie projektu (patrz: kultura organizacyjna) pozwala kwestionować każdą opinię i decyzję podjętą przez eksperta. W tym ostatnim przypadku zwinność zostanie skazana na śmierć z dwóch paragrafów.

Na początek to chyba tyle. Zastanowiłeś się? Zwinność w podejściu do projektów to nie jest prosta sprawa i – delikatnie rzecz ujmując – nie każdy projekt powinien iść tą drogą, a już na pewno nie doktrynalnie. Jeśli więc nie Pure Agile, o jak? Proponowałbym rozważenie kilku możliwości:

  • Gotowość do zmian. Taka cecha nie została „zawłaszczona” przez agile – można ją osiągnąć także realizując projektu w innym trybie, nawet jeśli większym kosztem. W miejsce „systemowej” gotowości do wprowadzenia zmiany, można stosować praktyki ułatwiające włączanie zmian do realizacji zadań projektowych, np. utrzymywanie maksymalnie prostych projektów technicznych bez udziwnień i „nadmiernej elastyczności”, weryfikację architektury przez iteracyjne tworzenie rozwiązania, oparcie się o dobre praktyki projektowania rozwiązań, odraczanie podejmowania decyzji, czy planowanie opcji i scenariuszy realizacji rozwiązania.
  • Adresowanie ryzyka. Istnienie ryzyka technicznego nie musi przekreślać zwinnego podejścia w całym projekcie. Jeśli ryzyko takie jest duże, być może warto przeprowadzić etap projektu w „niezwinnym” trybie i podjąć decyzję o trybie dalszej realizacji projektu w oparciu o wyniki prac architektonicznych i analiz ryzyka technicznego. W każdym takim przypadku trzeba jednak rozumieć, czym jest ryzyko techniczne w danym projekcie i jaki jest jego poziom akceptowalny dla organizacji. Tak naprawdę, nie w teorii.
  • Wyłanianie rozwiązania. Są takie projekty, w których po prostu nie da się lub nie opłaca się opracować architektury rozwiązania, które dawałoby podstawy dla zwinnej pracy zespołu realizującego rozwiązanie. W takich sytuacjach architektura rozwiązań także powinna być zwinna – z pełnym zrozumieniem konsekwencji i ryzyka. Jednym z trybów działania w takich przedsięwzięciach jest Emerging Architecture, zakładające nie tyle opracowanie architektury, co jej bieżące kształtowanie w oparciu o wymagania istotne w najbliższym czasie. Reszta przyjdzie później. Polecam dla zespołów dysponujących konkretnym doświadczeniem i odpornością psychiczną.
  • BDUF. Są też takie projekty, w których nie ma sensu lub nie uda się pójść ani kroku dalej bez dużego projektu technicznego wykonanego na początku prac (BDUF, Big Design Up-Front). W szczególności, takie są wszystkie małe projekty, w których wszystko wiadomo od samego początku (np. wdrożenie poczty elektronicznej). Takie mogą być też projekty o wysokim ryzyku (np. lot na Marsa). W takich projektach podejście zwinne jest po prostu za drogie – w kosztach lub konsekwencjach. I nie ma w tym nic złego, bo agile nie do wszystkiego się nadaje.

Podejść i strategii do realizacji projektów jest wiele. Każdy projekt jest inny, a twierdzenie, że istnieje jedna skuteczna metoda zarządzania każdym projektem zaprzecza esencji projektowości. Jak to w przyrodzie bywa, przestrzeń możliwości jest ciągła i nie sprowadza się do decyzji agile vs. waterfall. Nie popadajcie więc w religijne dysputy o wyższości czegoś nad czymś innym. Sprawdźcie, co ma szanse zadziałać w tym konkretnym przypadku. W szczególności, nie pakujcie się w agile bezrefleksyjnie.

Pozostaw komentarz