Agility Limited – Revisited

Data: 2014-11-03
Autor: Sebastian Konkol
Agility Limited – Revisited

Niemalże u zarania dziejów tego bloga pisałem o ograniczeniach stosowania podejścia agile. Kilka lat minęło, kilka nowych doświadczeń w głowie i uzupełnienie samo jakoś się wyłania.

Przez ostatnich kilka lat podejście agile do realizacji projektów nabrało negatywnych konotacji. Z niezrozumiałych dla mnie powodów utożsamiane jest z bałaganem, brakiem dokumentacji, brakiem kontroli i ogólną „partyzantką”. Te, bardzo nieuzasadnione, „zarzuty” stawiane są z uśmieszkiem na ustach przez wieloletnich praktyków, szczególnie w sferze projektów informatycznych. Aspiryna nie leczy odcisków – agile nie jest receptą na wszystko, choć, stosowana właściwie, jest receptą na główne „nieudaczności” tradycyjnych metod realizacji projektów w sferze IT.

Każda metoda pracy osadza się na określonych zasadach. Jeśli zasady nie są przestrzegane, to metoda nie działa. Każda. Agile nie jest tu wyjątkiem. Warte przypomnienia są te podstawowe:

  • powtarzalne, tanie eksperymenty – przedmiot projektu musi dać się podzielić na małe przyrosty, które daje się realizować małym wysiłkiem;
  • stała „moc wytwórcza” zespołu projektowego – brak fluktuacji w zespole, brak zaburzeń ich dostępności dla prac projektowych;
  • dbałość o utrzymanie stałego tempa prac – brak wprowadzania zmian do tego małego przyrostu w trakcie jego realizacji
  • wynik użyteczny biznesowo – przyrost określony tak, że zamknięcie projektu po jego realizacji podnosi wartość wyniku prac (użyteczność mierzona i wyrażana w kategoriach finansowych);
  • wspólna praca – duch współpracy a nie kontraktowy, prawdziwy teamwork.

I jeszcze porcja filozofii Agile Manifesto w części, która jest jakoś często pomijana: “That is, while there is value in the items on the right, we value the items on the left more.Agile nie oznacza braku dokumentacji, kontroli itd. Oznacza, zrozumienie, że rzeczona dokumentacja nie jest nigdy celem, a jedynie narzędziem osiągnięcia tego celu. Cel można osiągać dzięki różnym narzędziom, a tradycjonaliści są pod tym względem betonowo konserwatywni. Dokumentacja może być wycyzelowana do ostatniego przecinka, może jej nie być, ale może być good enough – na tyle dobra, aby zakładając dobrą wolę czytelnika dało się zrozumieć przedmiot prac.

Sformułowałem więc „Poradnik z marszu” dla chcących zastosować agile do swojego projektu:

  • materia projektu musi spełniać założenia – musi dać się podzielić na małe kawałki, zapewniające szybą ich realizację, dostarczając dodaną wartość po każdym przyroście – inaczej rzeczywiście powstaje jedynie chaos (nie da się budować mostu stosując agile);
  • zmiany są nieuchronne i jest dla nich miejsce – przed każdym przyrostem musi być podejmowana świadoma decyzja o jego zakresie, ale raz podjęta jest wykutą w kamieniu dla tego właśnie przyrostu;
  • ryzyko, nawet kontraktowo „przeniesione na dostawcę”, uderza w zamawiającego – każdy przyrost jest miarą ryzyka realizacji projektu, to stała „wartość ryzyka” wynikająca z kosztów (stałych!) realizacji pojedynczego przyrostu i trzeba nauczyć się od nowa myśleć o ryzyku w takim projekcie;
  • wszyscy muszą się na to zgadzać – zamawiający i poszczególne „frakcje” w jego organizacji szczególnie, dostawca, management, ludzie od kontraktów i prawnicy, bo przede wszystkim sprawy kontraktowe niszczą ten świat.

Listę zapewne można wydłużać, ale nie o to chodzi. Wszystkie praktyki agile o tym właśnie mówią. Może po prostu, zamiast wyśmiewać, polecam otwarcie umysłów i próbę zrozumienia.

Niedoświadczeni „stosowacze” agile w trudnych sytuacjach projektu zamiast stosować praktyki agile, przechodzą do podejścia tradycyjnego – wydłużają czas realizacji przyrostu, domagają się dokumentacji, przechodzą na mikromanagement. W efekcie projekt rozpoczęty jako agile staje się projektem ocenianym z perspektywy metod tradycyjnych. To nie może się udać, bo nie taki był cel. Jednak w efekcie okazuje się, że „agile jest be”, podczas gdy prawda jest taka, że termin ten jest nadużywany i to często, niestety, świadomie. Efektem jest czarny PR dla podejścia, które jest nieprawdopodobnie skuteczne dla projektów o określonej charakterystyce. Ale nie wszystkich.

Pozostaw komentarz