(Polish) Systemy proste, skomplikowane, złożone i chaotyczne czyli Cynefin.

Być może wcześniej miałeś do czynienia z pojęciami typu systemy złożone, skomplikowane, złożone systemy adaptacyjne na przykład przy okazji czytania Management 3.0 Jurgena Appelo albo czytając rozważania Kena Schwabera na temat aplikowalności Scruma. Być może to brzmi intrygująco, jednak trudno odnaleźć w tym logiczny sens jeśli nie ma się pewnej bazy teoretycznej. I tutaj warto się przyjrzeć koncepcji Dave'a Snowdena zwanej Cynefin opartej między innymi na teorii systemów złożonych, antropologii, psychologii ewolucyjnej,  psychologii poznawczej.

O co chodzi w tym wytwarzaniu oprogramowania

Już niemal od czterdziestu lat ludzie zajmujący się tematem wytwarzania oprogramowania zastanawiali się, co to tak naprawdę jest, do czego można to porównać, jakiego typu to zagadnienie. Pierwotnie próbowano zastosować do tego celu klasyczne myślenie związane z zarządzaniem rodem z Fordowskich fabryk (czytaj: hierarchie, rozdzielona praca, specjalizacja, plany). To niestety się nie sprawdzało. Nie do końca sprawdzała się również metafora odnosząca tworzenie systemów informatycznych do projektowania i budowania budynków. Agile w swoim myśleniu poszedł dalej – założono, że zmiana jest naturalną częścią projektów. Zmieniają się technologie. Zmieniają się wymagania. Zmieniają się ludzie, z którymi pracujemy (co jest dość naturalnie przy kilku lub kilkunastomiesięcznych projektach). Zatem podejście do realizacji projektów powinno zakładać tę zmianę i adaptować się do niej. Tak powstały różne metodyki z rodziny Agile, w tym obecnie najpopularniejszy Scrum. Czasami się sprawdzały. Czasami nie. Zaczęto poszukiwać teoretycznej bazy, która pozwoli odpowiedzieć na pytanie, dlaczego Agile w ogóle ma prawo działać oraz jasnych kryteriów, kiedy warto rozważać jego zastosowanie, a kiedy nie.

Model Cynefin

Z pomocą może przyjść wspomniany wcześniej koncept Cynefin, który jest modelem porządkującym dziedziny problemów, z którymi mamy do czynienia i adekwatności stosowanych podejść. Bazą dla tego modelu jest zależność między przyczyną a skutkiem przez nią wywołanym. Wyróżniono w ten sposób następujące obszary złożoności problemów (systemów):

·         Proste (ang. simple) – to systemy, w których jednoznacznie można powiązać przyczynę ze skutkiem. Dobrze rozpoznane, opisane dziedziny, gdzie dostępna jest wiedza, gdzie występujące problemy nie wymagają złożonej  interpretacji czy doświadczenia należą do tego obszaru. Jeśli właśnie nabyłeś nowy telefon i chcesz go skonfigurować na bazie podręcznika użytkownika, to masz do czynienia z dziedziną prostą (o ile podręcznik użytkownika rzeczywiście wystarczy). W tym obszarze lokują się wszelkie receptury, najlepsze strategie oraz modele, które można bezpośrednio zastosować w praktyce.

·         Skomplikowane (ang. complicated) – są to systemy, w których istnieje powiązanie między przyczyną i skutkiem, ale nie są one proste do wykrycia. Często wymagają wiedzy eksperckiej, dużego doświadczenia oraz złożonej analizy, aby znaleźć rozwiązanie problemy z danej dziedziny. Ponadto system tego typu jest statyczny lub przynajmniej mało zmienny (zmienność można przewidzieć i przeanalizować). Przykładem takiego systemu może być zegarek, samochód, dom. Są one statyczne, jednak żeby je stworzyć, naprawić, rozwiązać problem potrzebna jest wiedza ekspercka.

·         Złożone (ang. complex) – są to systemy, w których nie ma jednoznacznych powiązań między przyczyną i skutkiem, gdyż zmieniają się one w czasie. Może je wykryć poprzez eksperymenty i dociekania obecnego stanu rzeczy. Wiedza ekspercka nie daje jednoznacznych odpowiedzi, może za to służyć jako baza do decydowaniu o kierunku poszukiwań. System tego typu to system żywy, organiczny, zmienny w czasie. Zazwyczaj tam gdzie mamy do czynienia z ludźmi mamy do czynienia z systemami złożonymi. Systemy złożone to także giełda, mózg, układ odpornościowy, społeczności.

·         Choatyczne (ang. chaotic) – są to systemy w których brak jest powiązań między przyczyną i skutkiem. Nie można ich odkryć, bo ich tam nie ma. Wszelkie sytuacje alarmowe, pożary, katastrofy są przykładami takich systemów.

·         Nieuporządek (ang. disorder) – to sytuacja, w której nie jesteśmy w stanie, określić z jakiego typu systemem mamy do czynienia.

Co to ma wspólnego z wytwarzaniem oprogramowania?

Przedstawmy kilka przykładów. Mamy do czynienia z systemem prostym, kiedy myślimy o pierwszej linii wsparcia. Dzwoni klient, bo nie wie jak dodać nowego leada w CRM. Pracownik z pierwszej linii prowadzi klienta za rękę i pomaga rozwiązać problem (który pewnie klient sam byłby w stanie rozwiązać, gdyby poświęcił temu więcej czasu).

Inna sytuacja. Chcesz zainstalować dodatkowe oprogramowanie na komputerze PC. Okazuje się, że potrzebuje ono sterowników. Ściągasz je. Instalujesz. Działa. To przykład problemu z systemu prostego. Ale załóżmy, że pracujesz z systemem operacyjnym z rodziny linux i instalacja sterowników wymaga rekompilacji jądra. Zwykły śmiertelnik dalej tego nie pociągnie. Wyraźnie wchodzimy w obszar systemu skomplikowanego.

W programowaniu większość naszej pracy to systemy skomplikowane. Konfiguracja kontenera, systemu budowania, autoryzacja, uwierzytelnianie. To typowa wiedza ekspercka, która jest potrzebna do skonstruowania oprogramowania. W zasadzie w swojej podstawowej formie projektowanie, programowanie to również systemy skomplikowane. Ale… No właśnie. Tutaj sprawa nie jest tak oczywista. Jeśli weźmiemy pod uwagę taki przypadek, w którym programujesz sam dla siebie, jesteś źródłem wymagań, piszę kawałek kodu, który jest do zrobienia w ciągu kilkunastu godzin, mój kod nie będzie dramatycznie modyfikowany, to wtedy jest to system skomplikowany. Albo nawet w sytuacji, kiedy bierzemy pod uwagę długotrwałe i niebanalne przedsięwzięcie (kilka lub kilkanaście miesięcy) i jesteśmy szczęściarzami, bo nasze wymagania są dość dobrze zdefiniowane, spisane i nie zmieniają się, to cały czas mamy do czynienia z systemem skomplikowanym.

Mówiąc o utrzymaniu również możemy mówić o systemie skomplikowanym, pod warunkiem, że utrzymywany system się znacząco nie rozwija (prace głównie polegają na naprawie bugów).

Jeśli jednak tak nie jest – wymagania się zmieniają, są doprecyzowywane w trakcie, zmieniają się ludzie biorący udział w projekcie, to mamy do czynienia z systemem złożonym. Wtedy samo programowanie - powstający design oraz kod w konsekwencji należy również rozważać w kategorii systemów złożonych. Chyba to już jasne, że duża część projektów programistycznych mieści się w tej kategorii.

Choć pewna część mieści się również w kategorii systemów chaotycznych – tam gdzie nie ma reguł działania, kiedy zespół pracuje ad hoc, kiedy praca odbywa się głównie na zasadzie gaszenia pożarów. Tam mamy do czynienia z chaosem. I dosłownie i w przenośni.

Co z tego jest do wzięcia?

No właśnie. Teoria teorią. Pytanie tylko – po co to wszystko? Mianowicie wg modelu Cynefin, jeśli już określimy z jakiego typu systemem mamy do czynienia, wtedy możemy dobierać środki odpowiednie do kontekstu. Te środki to:

·         Główna strategia

·         Działania lidera

·         Narzędzia

Kontekst	Strategia	Działania lidera	Narzędzia
Systemy proste	1. zintepretuj 2. skategoryzuj 3. zareaguj	pilnuj procesu, standaryzuj, deleguj, używaj najlepszych praktyk	najlepsze strategie, 5 WHYS, podręczniki, receptury, PMBoK
Systemy skomplikowane	1. zinterpretuj 2. przeanalizuj 3. zareaguj	stwórz panel ekspertów, mediuj	procesy, standardy, panele eksperckie, Kanban, PMBoK
Systemy złożone	1. zaeksperymentuj 2. zinterpretuj 3. zareaguj	daj przestrzeń zespołowi do samoorganizacji, usprawniaj komunikację, empowerment	próby, eksperymenty dyskusje samoorganizacja w ograniczonym środowisku Agile, Kanban
Systemy chaotyczne	1. działaj 2. zinterpretuj 3. zareaguj	działaj i wnioskuj na tej bazie, prowadź prostą, jednoznaczną komunikację command and control	zrób cokolwiek, intuicja

Praktycznie żaden projekt nie jest czystej postaci, typy kontekstów są ze sobą przemieszane, natomiast zazwyczaj istnieje typ dominujący. Jeśli mamy do czynienia z dominującym systemem prostym lub skomplikowanym użyteczne będą narzędzia z rodziny PMBoK, jeśli mamy do czynienia z systemami skomplikowanymi lub złożonymi użyteczne będą narzędzia z rodziny Agile, Lean/Kanban (przy czym należy dodać, że w swojej źródłowej formie – Lean Manufacturing, to przede wszystkim narzędzie dla systemów skomplikowanych, które udostępnia dodatkowe do uporządkowania dziedziny problemu).

Na koniec

Jak widzieliśmy Cynefin proponuje nam pewien sposób postrzeganiu złożoności problemów, z którymi mamy do czynienia. Dzieli je na cztery główne obszary sugerując możliwe działania w tych obszarach. Dzięki temu wiemy, że samoorganizujący zespół nie musi być najlepszym rozwiązaniem w każdym projekcie programistycznym, że w przypadku dużego chaosu, najlepsze będzie zarządzanie twardej ręku (typu comand-and-control). A chaos może być efektem częstych i nieprzewidywalnych zmian w projekcie, ludziach czy też może być naturalną konsekwencją kiepskich umiejętności zespołu. Z drugiej strony w przewidywalnych środowiskach, niekoniecznie trzeba się silić na Agile, twierdząc, że jest to jedyne słuszne rozwiązanie. A z trzeciej strony stosowanie klasycznych metodyk będzie nieefektywne w przypadku projektów o charakterystyce  złożonej.

Jednak Cynefin to nie tylko ten model, to także szereg strategii, które można zastosować szczególnie w dziedzinach złożonych, ale to już inna historia.

Łyżka dziegciu. Oczywiście sam model nie daje jednoznacznych odpowiedzi. Nawet sam twórca Dave Snowden ma wątpliwości odnośnie tego, jak przyporządkować niektóre kwestie związane z metodykami zwinnymi (co można prześledzić na jego blogu). W każdym razie mimo wszystko jest to ciekawa perspektywa, którą warto uwzględnić na swojej ścieżce decyzyjnej.