A co jeśli agile nie jest potrzebny?

CynefinObrazoburczy tytuł, prawda? Tym bardziej na portalu poświęconym zwinnym metodom pracy, co? To może od razu przejdę do sedna, żeby nie trzymać was dłużej w niepewności. W 1999 roku Dave Snowden pracując dla IBM w Institute for Knowledge Management sformułował model Cynefin, który miał pomóc klasyfikować różne typy problemów i wymagań i w zależności od nich miał pomóc dopasować właściwą reakcję. Model ten jest na tyle uniwersalny, że może być stosowany nie tylko do zarządzania firmą, ale także do pracy z zespołem, czy nad projektem. I to właśnie ten model pokazuje, że czasem praca w sposób zwinny może nie tylko nie przynieść spodziewanych korzyści, ale wręcz utrudnić postęp i wpłynąć negatywnie na efekty.

Na rysunku powyżej przedstawiony został właśnie model Cynefin. Jak sam Snowden uważa, każdy model, każda teoria powinny być na tyle proste, żeby można było je narysować na chusteczce – i tak też ma się z Cynefinem. Model ten wyróżnia 5 obszarów złożoności:

1. Simple

Czyli prościzna – problemy, w których ewidentnie widać związek między przyczyną i skutkiem. Doskonale wiemy, co powinniśmy zrobić, żeby zlikwidować problem – istnieje bowiem jedno właściwe rozwiązanie (best practice). Jak zatem działamy? Sense, Categorize, Respond, czyli odczuj, o co chodzi w problemie, skategoryzuj go i zareaguj na niego tym jedynym właściwym rozwiązaniem. W programowaniu to przede wszystkim wszelkie zadania utrzymaniowe, które wykonujemy rutynowo w oparciu o instrukcje, czy proste taski, które jesteśmy w stanie zrobić od ręki, w ciągu 5 minut, bo znamy ich rozwiązanie.

2. Complicated

Jak sama nazwa wskazuje, tu już sytuacja robi się trochę bardziej skomplikowana, bo choć nadal mniej więcej wiemy, co trzeba zrobić, żeby zlikwidować problem, to właściwych rozwiązań jest już więcej niż tylko jedno (good practice). Musimy więc odczuć, o co chodzi w problemie (Sense), następnie przeanalizować go (Analize) i dopiero wówczas zareagować (Respond), wybierając właściwe rozwiązanie. To ten moment gdy korzystać będziemy również z wiedzy eksperckiej, doświadczenia osób, które albo z podobnymi problemami miały już do czynienia, albo są w stanie na podstawie wiedzy historycznej wybrać najlepsze spośród rozwiązań. W tym obszarze całkiem dobrze sprawdza się kaskadowy model wytwarzania oprogramowania, czyli stary waterfall. Dlaczego? Bo jeśli znamy problem, potencjalne rozwiązania i nie mamy zbyt wielu niewiadomych, to praca wg tej metody niesie za sobą naprawdę niewiele ryzyk. Jakie zadania mieszczą się w tym obszarze? Część zadań typu CRUD (create, read, update and delete), czyli dotyczących podstawowych funkcji aplikacji, a także zadania powtarzalne, które aż proszą się o automatyzację, bo przeważnie są wykonywane w ten sam sposób, a kilka wyjątków też jest dobrze znanych.

3. Complex

Wchodzimy na teren złożoności, która ma to do siebie, że niestety dopiero post factum jesteśmy w stanie zaobserwować, jakie były związki między przyczyną a skutkiem. Zabierając się za problem trochę błądzimy po omacku, próbujemy różnych rozwiązań i dopiero po ich implementacji stwierdzamy, które się sprawdziło. Innymi słowy ta nasza najlepsza czy dobra praktyka wyłoni się w trakcie prac (emergent practice). Stąd też musimy zmienić nas styl działania: sondujemy i testujemy  na spokojnie potencjalne różne sposoby rozwiązania problemu (Probe), bo nie mamy tak naprawdę jak zaplanować prac, następnie odczuwamy, co przynosi realne efekty (Sense) i w końcu reagujemy (Respond), co skutkuje wybraniem któregoś z testowanych rozwiązań i jednocześnie powstaniem nowej praktyki. Brzmi znajomo? To właśnie obszar, w którym świetnie sprawdzają się zwinne metody wytwarzania oprogramowania. Scrum, Kanban (choć ze względu na swoją procesowość Kanban również może być używany w obszarze Complicated), TDD, BDD i inne sposoby pracy, które adresują problem wielu niewiadomych, zmieniającego się otoczenia, czy wymagań. Z tego obszaru pochodzą wszelkie zadania wymagające prototypów, mockupów, makiet testujących nasze pomysły, projekty, w których dostarczamy MVP, żeby przekonać się, jak to wpłynie na nasze dalsze prace.

4. Chaotic

Jaki jest chaos, każdy wie – czyli innymi słowy, nic nie wiadomo, nie ma żadnych związków między przyczyną a skutkiem, więc nie mamy też zielonego pojęcia, co zadziała, jakich praktyk użyć. W tym obszarze nie użyjemy z resztą żadnych dotychczas znanych praktyk, bo nie ma czasu na ich wybór. Przed wszystkim bowiem działamy (Act), próbując intuicyjnie rozwiązać problem, następnie staramy się odczuć (Sens), czy nasze działania przynoszą spodziewane efekty, i w końcu reagujemy (Respond) dochodząc do nowego rozwiązania, które się sprawdza (novel practice). Jak zapewne się domyślacie, w tym obszarze znajdą się wszystkie awarie systemów, krytyczne błędy na produkcji, z którymi trzeba sobie już, teraz poradzić. Trudno zatem mówić o metodach pracy, które się tu sprawdzą, ale warto zauważyć, że właśnie codzienna praca zespołu bez wytycznych, bez celu, bez planu zawiera się właśnie w tym obszarze i celem zespołu powinno być zdobycie takich informacji, które pomogą przesunąć się z pracą do któregoś z pozostałych obszarów.

5. Disorder

Czyli innymi słowy, nie mamy pojęcia, gdzie jesteśmy, jak się tu znaleźliśmy i co dalej. To obszar, w którym nie wiemy, z jakiej klasy problemem mamy do czynienia, czy istnieje jakaś przyczynowość i jak powinniśmy postąpić. Rozkładamy ręce w geście bezradności, a potem robimy to, co wydaje nam się właściwe, a tak naprawdę jest reakcją mózgu na ten stan. Szukamy naszej strefy komfortu, czyli działań nam najbliższych, i je staramy się zaimplementować, co oczywiście może i nader często okazuje się porażką. Poprawne działanie w tym obszarze, to zgromadzenie jak najszybciej choć pewnej porcji informacji, które pozwolą nam świadomie zakwalifikować problem do któregoś z czterech wyżej wymienionych obszarów. Wówczas mamy szansę uniknąć poważnych konsekwencji nierozważnych decyzji.

Do tego uproszczonego opisu Cynefina trzeba dodać jeszcze kilka słów o granicy między Simple a Chaotic. Widzicie na obrazku ten zawinięty kawałek linii, który symbolizować ma krawędź? To ostrzeżenie, bo bardzo łatwo z obszaru, gdzie wszystko jest jasne, spaść do chaosu i zupełnie stracić grunt pod nogami. Kiedy tak się dzieje? Gdy przeceniamy swoje możliwości, gdy wydaje nam się, że jesteśmy ekspertami od wszystkiego. Na pewno znacie sytuacje, gdy ktoś się przechwalał, że napisanie tego kodu to mu zajmie 5 min., że to tylko prosta zmiana na tabelce w bazie, czy że zawsze tak robił i było ok. To właśnie ten moment, kiedy trzeba złapać delikwenta za ramię i spytać, czy na pewno wie, co robi. Dopytać o sposób rozwiązania i upewnić się, że faktycznie to nadal obszar Simple.

I to tyle jeśli chodzi o nakreślenie tematu Cynefina. Nakreślenie, bo model ten ma bardzo wiele zastosowań i doczekał się ogromnej liczby opracowań. Wystarczy wspomnieć, że użyto go do analizy podejmowania decyzji przez administrację G. Busha, zaprzęgnięto do walki z bioterroryzmem w USA, a także wciąż wykorzystuje przy kwestiach zawiązanych z szeroko pojętym przywództwem. Jeśli chcecie zgłębić ten temat (a naprawdę warto), to pozostaje mi odesłać was do strony Cognitive Edge, na której znajdziecie mnóstwo materiałów z ośrodka badawczego pod tą nazwą założonego przez Snowdena w celu badań nad teorią złożonych systemów adaptacyjnych.

A wracając do tytułu tego artykułu… To właśnie wiedza o tym, jakich środków należy użyć do jakich zadań, problemów czy projektów stanowi o naszej zwinności. Jeśli spróbujemy na chwilę pozbyć się odruchu wymiotnego słysząc o waterfallu, może dostrzeżemy, że każdy sposób pracy ma swoje 5 minut i tak naprawdę właściwe zastosowanie jednego z nich stanowi o tym, czy wygramy na rynku, czy ruszymy do przodu, czy właściwie wykorzystamy swoją szansę.

Komentarze do wpisu: “A co jeśli agile nie jest potrzebny?

  1. Rafał Dmowski

    Artykuł bazował na nieco starszej wersji freamworku, obecnie sam Dawid Snowden stosuje trochę inną nomenklaturę, ale to szczegóły. Najważniejsze jest propagowanie tego narzędzia i wiedzy na jego temat. Nota bene pan profesor często zwracał uwagi że Agile Manifesto jest błędny w przynajmniej jednym punkcie. Polecam zapoznanie się i przemyślenie tematu


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x