Uwaga. Wiele terminów występujących w tekście zostało użytych w ramach przyjętej przez autora konwencji terminologicznej. W celu ich wyróżnienia, zostały one zapisane jako nazwy własne.
W poprzednim postcie przedstawiłem wzorzec Procesu Racjonalnie Empirycznego, po angielsku The Rationally Empirical Process, czyli TREP.
Pozornie TREP wydaje się nieco "wydumanym", teoretycznym i uproszczonym, w praktyce jednak, pomimo swej prostoty (a może właśnie dlatego?), okazuje się być poręcznym podejściem przy organizacji działania w bardzo szerokim zakresie. Na jego bazie można skonstruować wiele użytecznych procesów, również w obszarze wytwarzania i utrzymania rozwiązań IT (dalej nazywajmy je "Systemami"), co nas analityków interesuje najbardziej. Zaryzykuję stwierdzenie, że wszystkie znane i praktykowane metodyki w tym obszarze są jego szczególnymi przypadkami.
Nie wierzycie? No to poczytajcie.
Przyjmijmy, że mamy do czynienia z bytem dalej zwanym "Firmą" - takim teminem w języku polskim potocznie określa się twór organizacyjny służący celom biznesowym - czyli złożonym bytem gospodarczym obejmującym:
- Przedsiębiorstwo, byt konceptualny, podmiot prawa, wyodrębnioną prawnie i ekonomicznie jednostkę gospodarczą,
- Organizację, byt socjologiczny, tworzony przez grupę osób intencjonalnie połączonych wspólnym zorganizowanym i celowym działaniem, pozostających w formalnych relacjach (struktura organizacyjna), wykonujących określone sekwencje (procesy) czynności (funkcje) o charakterze gospodarczym (zarządzanie finansowe, transakcje handlowe, marketing, itp), technologicznym (wytwarzanie, świadczenie sług, logistyka) i zarządczym (podejmowanie decyzji odnośnie Struktury i Zachowania i Organizacji). Przyjmijmy dodatkowo, że osoby tworzące Organizację Przedsiębiorstwa posiadają swe indywidulane Racjonalności na tyle zbliżone, że umożliwiają wzajemną komunikację i współdziałanie, czyli nie występuje zagrożenie przypadku budowy wieży Babel.
- System - byt techniczno-technologiczny składający się z kompleksu maszyn i urządzeń (w tym tzw. systemów informatycznych), środków transportu i łączności, nieruchomości wraz z wyposażeniem oraz innych środków trwałych,
(Uwaga. Czasami w niniejszym blogu termin "System" będziemy używać sensu largo w odniesieniu do każdego bytu będącego systemem w rozumieniu teorii systemów)
- Wiedzę branżową i ogólną (byt informacyjny), która podpowiada jak zbudować, utrzymać w ruchu i rozwijać Przedsiębiorstwo, Organizację i System, oraz realizować procesy biznesowe, zarządcze, technologiczne i inne, czyli swego rodzaju Metamodel Przedsiębiorstwa.
Zatem Firma posiada Architekturę, a więc, wobec Firmy można zastosować Podejście Architektoniczne.
Architektura bytu gospodarczego
(Copyright 2020-2021 Marek Bisztyga)
Firma działa w pewnym otoczeniu i w reakcji na jego bodźce oraz zjawiska wewnętrzne zostaje poddawana Zmianom (sposób rozumienia pojęcia zmiany został podany w poprzednim postcie) w celu adaptacji do nowych warunków. Choć Zmiany mogą dotknąć różnych jej elementów, sposób ich przeprowadzenia obejmuje podobny, wręcz identyczny w swej istocie zestaw stanów i Czynności, i choć w różnych konkretnych przypadkach (kontekstach) mogą one występować pod różnymi nazwami, w istocie dotyczą aktywności tego samego charakteru. Oto one.
Uświadamianie (sobie lub interesariuszom) potrzeby Zmiany
Inicjatywy dokonania Zmian wynikają z uświadomionej i niezaspokojonej potrzeby. Zazwyczaj najpierw dostrzegane są niepożądane objawy (symptomy) wskazujące na zaistnienie niepożądanego Stanu Przedsiębiorstwa, Organizacji i/lub Systemu (lub brak Stanu pożądanego, co również stanowi Stan niepożądany), który wywołuje przejaw woli i chęci interesariuszy Przedsiębiorstwa przejścia w Stan pożądany. W tej fazie najczęściej jeszcze nie wiadomo, na czym owa Zmiana miałaby konkretnie polegać, ale panuje przekonanie, że musi nastąpić. Osiągnięcie Stanu pożądanego staje się Celem Strategicznym, przyjmując, że Celem Egzystencjalnym jest trwanie Przedsiębiorstwa i kontynuacja realizacji jego Misji.
Owa wola/chęć dokonania Zmiany może być wyrażona w formie:
- zgłoszenia symptomów Stanu niepożądanego (np. zgłoszenia awarii),
- zgłoszenia wymagań biznesowych odnośnie pożądanej nowej funkcjonalności Organizacji i/lub Systemu (ang. features),
Definiowanie Problemu
Konstatacja potrzeby Zmiany buduje świadomość istnienia Problemu i konieczności jego Rozwiązania. By stwierdzić, na czym ów Problem polega i co jest jego istotą - co jest jego tzw. "root cause", a co za tym idzie, co powinno być przedmiotem Zmiany - należy:
- zbadać scenariusz prowadzący do manifestacji objawów owego niepożądanego Stanu (Dynamika/Zachowanie Problemu) motywującego do Zmiany, lub scenariusz, który powinien być realizowany w ramach postulowanej nowej funkcjonalności,
- zidentyfikować elementy Przedsiębiorstwa, Organizacji lub Systemu, i ewentualnie ich otoczenia, które biorą udział w mechanizmie manifestacji tychże objawów lub w antycypowanym scenariuszu (Struktura Problemu).
- zrozumieć sam mechanizm powstawania objawów Stanu niepożądanego oraz zjawisk, które za nimi stoją, lub inicjacji i przebiegu antycypowanego scenariusza (Metamodel Problemu).
W ten sposób budowana jest tzw. Architektura Problemu obejmująca jego Strukturę, Dynamikę i Metamodel. Pojęcie Architektury zostało wyjaśnione w odrębnym postcie.
Definiowanie Rozwiązania
Dysponując Architekturą Problemu jesteśmy w stanie określić przedmiot (zakres) i sposób Zmiany, która ma polegać na takiej modyfikacji, dodaniu lub usunięciu wybranych elementów Przedsiębiorstwa, Organizacji i/lub Systemu, by w jej następstwie zniknął Stan niepożądany (lub pojawił się Stan pożądany) lub pojawiła się pożądana funkcjonalność. Tak skonstruowana Zmiana definiuje Architekturę Rozwiązania obejmującą:
- Strukturę Rozwiązania, czyli opis zbioru zmodyfikowanych, dodanych lub usuniętych elementów Przedsiębiorstwa, Organizacji lub Systemu (co i na co zostanie zmienione),
- Dynamikę/Zachowanie Rozwiązania, czyli opis pożądanego/oczekiwanego zachowania się zmienionych fragmentów Przedsiębiorstwa, Organizacji lub Systemu,
- Metamodel Rozwiązania, czyli opis ogólnej "mechaniki" wyjaśniającej jak i dlaczego można spodziewać się nowego Zachowania nowej Struktury,
oraz opis metody jego implementacji, czyli plan działań, rezultatem których będzie materializacja Architektury Rozwiązania.
Implementacja Rozwiązania
Dysponując Architekturą (projektem) Rozwiązania można przystąpić do jego implementacji, czyli do przeprowadzenia faktycznej Zmiany Architektury Przedsiębiorstwa, Organizacji lub Systemu. Implementacja zazwyczaj sama w sobie jest procesem złożonym, obejmującym wiele kroków. Przebiega w sposób zróżnicowany, w zależności od przyjętej metodyki inżynierii, użytych technologii i narzędzi.
Walidowanie Rozwiązania, czyli odpowiedź na pytanie, czy dostarczyliśmy właściwe Rozwiązanie właściwego Problemu
Zanim Rozwiązanie zostanie skierowane do wdrożenia, czyli stanie się fragmentem nowej, zmienionej rzeczywistości, należy poddać je walidacji, czyli zbadać, czy i na ile stanowi Rozwiązanie postawionego Problemu, i czy w tym sensie przedstawia wartość (np. biznesową) dla Organizacji. Technicznie rzecz ujmując, należy przeprowadzić "testy akceptacyjne" nowo powstałej wersji Organizacji czy Systemu oraz orzec, czy wprowadzone zmiany Struktury i Zachowania wykazują pożądane cechy, a także, czy nie powodują niespodziewane nowe niepożądane efekty.
Weryfikowanie procesu budowy Rozwiązania, czyli odpowiedż na pytanie, czy rozwiązanie zbudowaliśmy i dostarczyliśmy prawidłowo i właściwie
Na każdym etapie prac nad Rozwiązaniem należny weryfikować, czy proces jego budowy przebiega zgodnie z planem i ze sztuką, oraz czy spełnia wszystkie standardy obowiązujące w danej Organizacji. Rozwiązanie nie może spełniać jedynie wymagań funkcjonalnych. Ważne, aby nie posiadało wad koncepcyjnych, błędów i usterek, nie rodziło zagrożeń naruszenia prawa, zasad bezpieczeństwa i innych pryncypiów, a przy tym spełniało wymogi ekonomiczne, mieściło się w akceptowalnych granicach całkowitych kosztów posiadania (TCO).
Teraz powróćmy na moment do wzorca procesowego TREP.
 |
Wzorzec TREP (Copyright 2020-2021 Marek Bisztyga) |
Z poprzedniego posta pamiętamy, że TREP obejmuje następujące Działania:
- określanie Celu Egzystencjalnego lub Strategicznego rozpatrywanego podmiotu,
- Motywowanie,
- Przygotowanie,
- Oddziaływanie (Implementowanie Decyzji),
- Obserwowanie,
- Decydowanie.
Przyjmijmy, że:
- Zaobserwowanie niepożądanych efektów i uświadomienie potrzeby Zmiany to wytyczanie Celu Egzystencjalnego i/lub Strategicznego (sensu dalszej egzystencji, misji),
- Definiowanie Problemu to wyznaczanie Celu Operacyjnego, czyli Motywowanie. By podjąć konkretne działanie, najpierw należy zrozumieć jego cel, jakim jest Rozwiązanie Problemu.
- Definiowanie Rozwiązania to Przygotowanie do Implementacji Rozwiązania. Bez koncepcji lub planu budowy Rozwiązania Problemu nie można przystąpić do jego faktycznego rozwiązywania. Definicja Rozwiązania, oprócz wiedzy co i jak trzeba zrobić, pozwala oszacować nakłady pracy oraz określić wymagane zasoby, albowiem bezpośrednio zależą one nie tylko od Problemu, a od przyjętego sposobu jego rozwiązywania. Każdy Problem można rozwiązać na kilka sposobów.
- Implementowanie Rozwiązania to ... Implementowanie czyli materializacja zamiaru dostarczenia Rozwiązania,
- Walidowanie Rozwiązania to Obserwowanie/Analiza potencjalnych skutków jego wdrożenia i ocena, czy i na ile Rozwiązanie rozwiązuje Problem, a tym samym przedstawia wartość dla Organizacji,
- Weryfikowanie Rozwiązania to monitoring i sterowanie przebiegiem procesu kreowania Rozwiązania począwszy od uświadomienia potrzeby Zmiany do wdrożenia, zakończone decyzją odnośnie dopuszczenia Rozwiązania do użytku, czyli Decydowanie.
Wtedy wzorzec TREP mógłby skonkretyzować się w postaci następującego procesu:
 |
Proces Panta Rhei (Copyright 2020-2021 Marek Bisztyga) |
i działać przykładowo tak:
Proces Panta Rhei w działaniu
(Copyright 2020-2021 Marek Bisztyga)
Tym sposobem stworzyliśmy przypadek użycia wzorca TREP w sferze praktycznej (np. IT), który na cześć mojego "filozoficznego" patrona, Heraklita z Efezu - praojca dialektyki i filozofii procesu - nazwałem procesem
Panta Rhei.
- Proces inicjuje konstatacja wystąpienia niepożądanego Stanu i woli jego odmiany. Sterowanie zostaje przekazane Koordynatorowi (Decydentowi).
- W pierwszej iteracji zostaje podjęta Decyzja o zdefiniowaniu Problemu.
- Sterowanie zostaje przekazane analitykowi, który opracowuje Architekturę Problemu.
- Następnie, na jej bazie, powstaje Architektura Rozwiązania.
- Dalej, jeśli ta spełnia wymogi poprawności, na jej podstawie zostaje podjęta Decyzja projektowa.
- Kroki 3-4-5 mogą być powtarzane wielokrotnie
- Projekt Rozwiązania zostaje skierowany do Implementacji.
- Po jej ukończeniu, Rozwiązanie zostaje poddane Walidacji.
- Jeśli jest ona negatywna, z reguły jest powtarzana definicja Rozwiązania i Implementacja.
- W pewnych okolicznościach, jednak, może zaistnieć również konieczność zmiany definicji Problemu.
- Wielo iteracyjny cykl trwa dopóty, dopóki Rozwiązanie nie zostanie zwalidowane pozytywnie i nie zapadnie Decyzja o akceptacji Rozwiązania.
W przypadku zastosowania konkretnych ram postępowania, np. Scrum, Proces Panta Rhei mógłby przybrać następującą, bardziej rozbudowaną formę :
 |
Scrum jako implementacja Procesu "Panta Rhei" (1/2) (Copyright 2020-2021 Marek Bisztyga) |
i przebiegać w następujący sposób:
Scrum jako implementacja Procesu "Panta Rhei" (2/2)
(Copyright 2020-2021 Marek Bisztyga)
W powyższym przykładzie poszczególne działania Procesu Panta Rhei odpowiadają tym zaczerpniętym z ram Scrum. Działanie "Implementacja Rozwiązania" zostało przedstawiona w postaci rozwiniętego pod-procesu realizującego przebieg sprinta (Sprint Run), jak łatwo zauważyć również zbudowanego w oparciu o wzorzec TREP. Choć nie jest to uwidocznione na diagramie, Zarządzanie Product Backlog i pozostałe czynności również mogą przebiegać według wzorca TREP.
Można zatem uznać, że mamy do czynienia z implementacją Scrum jako szczególnego przypadku TREP.
Czy ma to jakieś praktyczne zastosowanie?
Po pierwsze, nic nie stoi na przeszkodzie, aby tak właśnie zorganizować pracę zespołu scrumowego (zdaję sobie sprawę, że po tych słowach wielu "fundamentalistów" scrumowych właśnie rzuciło na mnie klątwę i zaprzysięgło dżihad) i zautomatyzować workflow, tym samym implementując ową mityczną empiryczną "kontrolę procesu" w sposób godny miana podejścia procesowego.
Po drugie, procesowe ujęcie praktyki Scrum umożliwia bardzo przydatną z punktu widzenia zarządzania analizę symulacyjną procesu metodą Monte Carlo, na przykład przy użyciu narzędzi implementujących BPSim - standard specyfikacji i ilościowej analizy procesów. Dzięki temu możliwa jest dość dokładna estymacja szeregu parametrów procesu, takich jak np. czas trwania (włącznie z przestojami), koszty przebiegu procesu, stopień utylizacji zasobów i innych. Wiem, że w codziennej praktyce Scruma mało kto podchodzi do analizy procesu na tak szczegółowym poziomie, ale jeśli jest łatwe w użyciu narzędzie, to czemu nie? Przy projektach za "poważne" pieniądze - gdy "omsknięcie" w estymacjach o kilka punktów scrumowych kosztuje wiele kilo złotych monet - może warto spróbować?
Powróćmy do procesu Panta Rhei.
Proces możemy również kontrolować przy użyciu metodyki Kanban i sterować nim za pomocą względnie prostej tablicy. Wykorzystanie narzędzi Kanban dostarcza również dodatkowych "profitów" analitycznych - możliwość ilościowego pomiaru efektywności procesu, na przykład przy pomocy Cumulative Flow Diagram.
Tablica Kanban sterująca Procesem Panta Rhei.
(Copyright 2020-2021 Marek Bisztyga)
Niech Was nie deprymuje mnogość kolumn w powyższej tablicy. Jak to w życiu, po każdej czynności zgłaszamy jej zakończenie i gotowość do weryfikacji ustawiając zadanie w kolumnie "Gotowe / Do Weryfikacji". Weryfikator, po analizie stanu realizacji zadania, wstawia je do kolejki zadań oczekujących na realizację kolejnej wybranej przez Weryfikatora czynności. Dzięki temu zachowujemy w procesie zasadę "pull" - każda czynność zostanie wykonana, gdy pojawią się ku temu warunki, a Wykonawca będzie miał wolne "moce przerobowe". Gdyby zredukować w imię opacznie rozumianej prostoty ilość kolumn i wyrzuci kolejki oczekiwania, proces zamieniłby się w typ "push", a Weryfikator czasami nie mógłby przydzielać kolejnych zadań - musiałby śledzić dostępność poszczególnych Wykonawców. Proces mógłby się "zapychać". Poza tym, śledzenie stanu kolejek zadań oczekujących dostarcza cennych informacji zarządczych na temat efektywności całego procesu. Pozwala zauważyć wąskie gardła (zbyt długie czasy oczekiwania na pobranie) i zasygnalizować potencjalne problemy.
Pewną modyfikacją powyższego układu tablicy, naruszającą nieco kanoniczność metodyki Kanban, jest zastąpienie kolumn zadań "oczekujących" wydzielonym torem (tzw. swimlane). Zadania oczekujące na obsługę są umieszczane w torze "oczekujących", skąd są pobierane do toru "obsługiwanych" w ramach danej kolumny. Zmniejsza to co prawda ilość kolumn, ale przy okazji powoduje wypaczenie wyników analizy czasu obsługi: czas oczekiwania (przebywania w torze "oczekujących") jest sumowany z czasem rzeczywistej obsługi (przebywania w torze "obsługiwanych") zadania, gdyż większość narzędzi Kanban nalicza czas przebywania zadania w kolumnie bez względu na tor. W niektórych okolicznościach jednak może to być nawet pożądaną cechą tablicy, gdy czas oczekiwania zadania ma "obciążać" obsługującego.
Tablica Kanban sterująca Procesem "Panta Rhei".
Wersja 2-torowa.
(Copyright 2020-2021 Marek Bisztyga)
Jako że Weryfikator jednoosobowo (kierownik projektu w podejściu "projektowym") lub kolektywnie (zespół w Scrum) "kieruje ruchem" w Procesie Panta Rhei, od jego decyzji zależy, czy dany przebieg procesu będzie bardziej typu "waterfall", czy "agile". Może nawet mieszać podejścia w trakcie przebiegu Procesu. Jeśli zechce i ma to sens, może "iść waterfallem" (w dowolnej jego mutacji) w fazach definicji Problemu i Rozwiązania, a "agilem" (FDD, Scrumem, Kanbanen, a nawet Scrumbanen) w fazie Implementacji, tworząc wiele przyrostów walidowanych i weryfikowanych w każdej iteracji. Taka sytuacja często ma miejsce, gdy problematyczne zjawisko jest dobrze udokumentowane, a pomysł na jego rozwiązanie wydaje się oczywisty, natomiast wiele niewiadomych czai się w konstrukcji modyfikowanego produktu (np. w kodzie). Podejście można zmieniać z iteracji na iterację, gdy po kolejnej Implementacji nagle okaże się, że należy zmienić ocenę skali Problemu i zakresu Rozwiązania w świetle odkrycia nieznanych przedtem zależności architektonicznych kodu (zjawisko tzw. kompensat Zmian). W takich sytuacjach Panta Rhei daje pełną swobodę w adaptacji do bieżących warunków i potrzeb. Choć to jawne odejście od ortodoksji ( a nawet pachnące herezją), nie powoduje za to żadnych "wojen religijnych" i "walk plemiennych" pomiędzy zwolennikami różnych podejść, ram postępowania i metodyk. Pokój i Harmonia. Spróbujmy sobie to wyobrazić...
Ech...Rozmarzyłem się...
Nieustająco Wasz,
M.
Brak komentarzy:
Prześlij komentarz