Od wielu lat lat, produktem mojej pracy są dokumenty opisujące w obiektywny sposób działanie organizacji, zawierające rekomendacje zmian do poprawy sytuacji, także wymagania na systemy informacyjne. Po opracowaniu rozwiązania i pomocy w wyborze jego dostawcy, prowadzę nadzór autorski nad realizacją opracowanego rozwiązania. [1] Po latach pracy nasuwa mi się dość ciekawy wniosek z obserwacji: Zamawiający działają na swoją szkodę!
Typowy projekt związany z wdrażaniem nowych rozwiązań to realne potrzeby Zamawiającego. Członkowie zespołu Zamawiającego mają nad sobą terminy i „nieuchronność” kary za niepowodzenie. W efekcie Dostawca szybko staje się „Panem projektu”, bo to on dostarcza rozwiązanie, zna się, a bywa że szantażuje. Przewaga merytoryczna Dostawcy nad Zamawiającym jest tak wielka, że ten ostatni w zasadzie nie jest w stanie panować nad projektem. Powoli rynek to dostrzega i dlatego od kilku lat niemalże każda moja umowa na projektowanie zawiera także nadzór autorski (to forma kontroli efektów pracy dostawcy).
Nadal bardzo często Dostawca tworzy jednak pewną atmosferę: „to my realizujemy Wasz projekt i wszystko – Wy także – od nas zależy, nadzór autorski psuje Wam harmonogram bo my musimy te dokumenty czytać i tworzyć”. Dwa razy w ostatnich pięciu lat zdarzyło mi się, że faktycznie Zamawiający zrezygnował z nadzoru autorskiego, bo członkowie zespołu zaczęli „trzymać stronę Dostawcy”, mimo informacji o szkodliwości zmian wprowadzanych przez z Dostawcę. Oba projekty skończyły się niestety klęską (mam kontakt z praktycznie każdym byłym klientem).
Projekt wdrożeniowy bez nadzoru merytorycznego, to bardzo często równia pochyła: od podpisania umowy na wdrożenie z dostawcą jest już tylko coraz gorzej, bo Dostawca upraszcza logikę systemu, pomija trudne do realizacji wymagania, stale organizuje spotkania, na których legitymizuje te zmiany w prosty sposób sposób: „to co macie w dokumentacji wymagań jest złe (nie da się, nikt tak nie robi itp.), nasz system realizuje to inaczej, zróbmy to prościej i szybciej a też będzie dobrze”. Zamawiający z reguły nie ma po swojej stronie żadnych kompetencji by ocenić skutki takich „propozycji” i na spotkaniach godzi się na to, podpisując kolejne notatki projektowe z takich „warsztatów”, małymi kroczkami funkcjonalność dostarczanego produktu oddala się od faktycznych potrzeb i wymagań. Projekt kończy się tak, że Zamawiający „dostał dokładnie to co chciał a nie to co jest mu potrzebne”. Statystyki projektów IT są bezlitosne: ok. 2/3 projektów to nadal projekty nieudane. [2]
Tam gdzie mój projekt był kolejnym podejściem, po poprzednim nieudanym, wyżej opisana sytuacja była praktycznie zawsze przyczyną wcześniejszej porażki. Paradoksalnie jest to – porażka – wręcz standardowa sytuacja, gdy Zamawiający najpierw wybiera Dostawcę a potem zleca mu analizę wymagań i kierowanie projektem.
Zjawisko to zawsze kojarzy mi się ze znanym w psychologii efektem nazywanym Syndrom Sztokholmski. Jest to sytuacja, w której ofiara, wbrew zdrowemu rozsądkowi, zaczyna sympatyzować ze swoim oprawcą.
[Syndrom Sztokholmski] …ofiara porwania czy zakładnik traci krytycyzm wobec swojej sytuacji, zaczyna wierzyć, ze jej oprawca działa w słusznym celu, i darzyć go sympatią. Jak twierdzi amerykańska psycholog, dr Natalie de Fabrique, zajmująca się badaniem tego syndromu, syndrom sztokholmski pojawia się u ofiar nieświadomie, to instynktowny, psychologiczny mechanizm obronny, dzięki któremu łatwiej jest im odnaleźć sens tego, co się dzieje, i uniknąć załamania nerwowego. [3]
W wielu projektach wdrożeniowych mamy podobną sytuację: pracownicy zamawiającego, zamiast działać na rzecz siebie czy swojego pracodawcy, zaczynają trzymać stronę Dostawcy, który żali się, że ma problem z terminami i przerzuca winę za to na swojego klienta. Po pewnym czasie dochodzi do tego, że zespół Zamawiającego tak się „zżył z pracownikami Dostawcy”, że zaczyna ich bronić przed własnymi przełożonymi. Są Dostawcy, którzy celowo stwarzają takie sytuacje (np. organizując wyjazdowe szkolenia i warsztaty z noclegami), ale nie raz dzieje się „samoistnie”. Popatrzmy na poniższą listę, czy nie przypomina Wam to czegoś?
Objawy i symptomy syndromu sztokholmskiego to: – pozytywne uczucia ofiary wobec sprawcy; – zrozumienie przez ofiarę motywów i zachowań sprawcy i podzielanie jego poglądów; – pozytywne uczucia sprawcy względem ofiary; – pomocne zachowania ofiary wobec sprawcy; – negatywne uczucia ofiary wobec rodziny, przyjaciół, autorytetów próbujących ją ratować; – niezdolność zaangażowania się w zachowania, które mogłyby doprowadzić do jej uwolnienia od sprawcy. Syndrom sztokholmski nie dotyczy wszystkich osób dotkniętych tragicznymi zdarzeniami. By zaistniał, muszą wystąpić określone warunki. Ofiara: – spostrzega, że jej przeżycie zależy od dobrej woli sprawcy; – nie widzi możliwości ucieczki; – dostrzega drobne uprzejmości ze strony sprawcy; – jest izolowana od perspektyw odmiennych od perspektywy sprawcy. [4]
Popatrzmy zatem na projekt wdrożeniowy, w którym:
Zespól Zamawiającego wierzy, że „być albo nie być” firmy, zależy od powodzenia projektu,
Zespół Zamawiającego nie widzi alternatywy dla tego wdrożenia,
Zespół Zamawiającego widzi, że Dostawca od czasu do czasu idzie mu na rękę (realizowanie drobnych zachcianek Zamawiającego w zakresie projektu),
Zespół Zamawiającego jest izolowany od innych perspektyw i spojrzenia na realizowany projekt (silne dążenie Dostawcy do wyeliminowania zewnętrznego nadzoru merytorycznego, audytów, nadzoru autorskiego).
Psycholodzy co do jednego są zgodni: człowiek nie jest w stanie bronić się przed swoimi emocjami, dlatego często jedynym sposobem obrony przed manipulacją jest unikanie kontaktu z manipulantem. Nie ma tu znaczenia czy to manipulacja celowa czy nieuświadomiona.
Lekarstwo na sytuacje, takie jak wyżej opisana, jest tylko jedno: zrezygnować z warsztatów grupowych z Dostawcą! Jak to komuś mówię to ma miejsce przerażenie i padają słowa „Ale przecież praca grupowa jest najefektywniejsza! Tak uczyli na szkoleniu i mówili na konferencjach”. W literaturze nie raz spotykałem się z podejściem odradzającym warsztaty grupowe i burze mózgów z uwagi a ich duże koszty i nieefektywność. Nie jest jednak takich opinii zbyt wiele, bo mit efektywności pracy grupowej jest wiecznie żywy (mimo tego, że badania naukowe pokazują, że praca grupowa jest mniej efektywna niż praca samodzielna).
Jednak od czasu do czasu spotykam się książkami czy wpisami na blogach, że odejście od idei JAD (ang. Joint Application Development) wydatnie poprawiło jakość projektów (sam IBM proponuje w to miejsce całkowite zastąpienie warsztatów analizą dokumentów źródłowych a potem pisemne formułowanie uwag i zarządzanie zakresem projektu z użyciem ścisłej procedury, co paradoksalnie trwa krócej, jest tańsze i daje znacznie lepsze efekty).
Co ciekawe, idea taka pojawiła się w np. tak zwanej zwinnej metodzie zarządzania projektem SCRUM, w postaci roli Product Ownera (PO) jako osoby praktycznie całkowicie separującej zespół zamawiającego od zespołu Dostawcy (business vs. developers):
There are several aspects about this role which I think are critical to understand: Product owners bridge the communication between the team and their stakeholders. As Figure 1 shows, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.[…]
The role of Product Owner (Scott Ambler, Agile Modeling)
Ciekawe jest to, że większość znanych mi zespołów deklarujących pracę zgodną ze SCRUM, to zespoły developerskie, które praktycznie całkowicie rezygnują z prawdziwej roli PO. Jak? Po prostu wyznaczają na PO jednego z pośród członków zespołu developerskiego, co jest pogwałceniem zasad SCRUM. Skutek jest taki, że osoba, której podstawową rolą jest zarządzanie funkcjonalnością produktu i separowanie Developera od Zamawiającego, pracuje na rzecz developera i godzi się na każdą zmianę korzystną dla swojego zespołu. Niestety w projektach programistycznych jest to niemalże reguła. W projektach budowlanych (setki lat doświadczeń) dla odmiany jest to prawnie zakazane: nie wolno łączyć roli nadzoru autorskiego (architekt i projektant) ani z rolą wykonawcy ani z rolą inwestora.
Na koniec polecam ciekawy artykuł na podobny temat:
Polacy kupują mieszkania bez usług i zieleni. Wybierają szczelnie ogrodzone betonowe pustynie bez przedszkoli, placów zabaw i komunikacji. A obok rozwiązań prawnych to właśnie decyzje konsumentów ukształtują nam przestrzeń na kolejne dziesięciolecia. (żr. Ufamy deweloperom bardziej niż lekarzom. Przypomina to syndrom sztokholmski).
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Oprogramowanie bardzo często zastępuje konstrukcje rzeczywiste takie jak zegarek, kartoteka, biblioteka, księgi handlowe, programator pralki i wiele innych rzeczy. Dlatego analiza powinna polegać na zrozumieniu i udokumentowaniu mechanizmu działania „tego czegoś” a nie jedynie na spisaniu zewnętrznych oznak tego działania i zarządzanie tym spisem.
Referat miał lekkie podłoże filozoficzne :).
Ten artykuł nie będzie jednak powtórzeniem referatu (wyżej link do pobrania). Do jego napisania skłoniło mnie jedno z pytań z sali:
„Stosujemy TDD, czy to nie wystarczy? Po co więc robić to o czym Pan mówi?”
Otóż odpowiedź brzmiała: TDD nie zastępuje opisu mechanizmu działania. Innymi słowy: sam zestaw testów bardzo często nie stanowi żadnej informacji o tym co ma powstać.
Niedawno pisałem:
Mechanizm jednak to nie zawsze tylko same reguły, bardzo często (praktycznie zawsze dla nietrywialnych systemów) powinien powstać diagram pokazujący wewnętrzną budowę (architekturę) systemu, zestaw komponentów odpowiedzialnych za logikę realizowania tych reguł (a jedną z nich jest np. ?treść dokumentów musi być zapamiętywana z możliwością przywołania jej w dowolnym momencie?). Taki diagram nazywa się Model dziedziny. Jak go tworzyć pisałem nap. w artykule Model dziedziny jako wymaganie. (Źródło: Model To Mechanizm | | Jarosław Żeliński IT-Consulting)
A teraz jako przykład przytoczę dość złożony komponent wielu systemów (pogrubienie moje):
Jak działa scoring w Banku. Klient zainteresowany uzyskaniem kredytu wypełnia wniosek kredytowy dla wybranego produktu kredytowego. Dane z wniosku rejestrowane są w systemie informatycznym, który wspomaga proces obsługi wniosków kredytowych w Banku. Podczas przetwarzania wniosku następuje weryfikacja danych oraz zapytanie o automatyczną rekomendację kredytową kierowaną do silnika decyzyjnego. Silnik decyzyjny wykonuje zdefiniowany w postaci reguł przetwarzania algorytm scoringowy: gromadzi dodatkowe informacje z dostępnych źródeł (np. Biuro Informacji Kredytowej SA, bazy niesolidnych klientów oraz dowodów zastrzeżonych ? MIG BR, MIG DZ), wyznacza wskaźniki, określa przydział do klas ryzyka oraz wylicza ocenę punktową w oparciu o karty scoringowe. (Źródło: Scoring – metoda oceny wiarygodności kredytowej – ERP-view.pl – ERP, CRM, MRP, Business Intelligence, MRP)
Odpowiadając na pytanie o TDD powiem tak: nie da się „jednoznacznie zamówić” Systemu scoringowego, podając jedynie partię danych wejściowych i spodziewanych danych wyjściowych. Testy można opracować znając mechanizm działania tego systemu, tworzymy wtedy reprezentatywny zestaw testów „pokrywający cały kod”, o ile znamy strukturę tego kodu (projekt). Sam kod nie musi istnieć w momencie projektowania tych testów, ale opracowany mechanizm tak, bo jak już pisałem „model dziedziny to struktura kodu realizującego logikę biznesową wraz z metodami”.
Można tu powiedzieć, że nie każdy system to złożoność systemu scoringowego. To prawda, ale to co nazywamy biznesem to reguły biznesowe, mechanizm działania organizacji, a ten nigdy nie jest trywialny. Reguły udzielania upustów, reguły przydzielania kredytów kupieckich, reguły nagradzania w systemach lojalnościowych, reguły rozliczania kosztów i wiele, wiele innych w prawie każdej firmie, organizacji czy instytucji publicznej.
Prawdopodobieństwo tego, że powstanie „poprawne” oprogramowanie tylko na podstawie zapisu szeregu „zewnętrznych obserwacji” (bo czym są wymagania jako zapis burz mózgów, ankiet, wywiadów, itp.?) jest tym bardziej bliskie zeru im bardziej organizacja ma złożony mechanizm działania (czyli większość).
Zjawisko to jest znane już od dziesiątków lat:
Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle ?problemami złośliwymi? (Rittel i Webber, 1973). ?Problem złośliwy? to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.
Dlatego rozwiązanie nietrywialnego problemu nie polega na specyfikowaniu tego co znamy, a na podjęciu próby zaprojektowania rozwiązania. Tym projektem nie jest jednak „opis reakcji systsemu na bodźce” (czarna skrzynka). Projektem jest opisany (jednoznacznie udokumentowany) mechanizm działania rozwiązania (biała skrzynka).
Dlatego wymagania specyfikujemy skutecznie poprzez projekt produktu a nie poprzez listę cech produktu. Zamówienie dla developera powinno zawierać projekt a nie wizualizację efektu końcowego, dokładnie tak jak w branży budowlanej, elektronicznej czy nawet mechanicznej (nawet wykonawca wału korbowego dostaje rysunki techniczne a nie rozwlekłą prośbę o fajny wał do samochodu).
Zilustrować to można tak:
Wymagania biznesowe zgłasza biznes, są one formą opisu i konsekwencją problemu biznesowego, wymagania wobec rozwiązania to ustalony zakres projektu.
Jeżeli jest to projekt z obszaru inżynierii oprogramowania, ma powstać oprogramowanie opisane z użyciem Przypadków użycia i Modelu dziedziny.
Jak przejść od wymagań biznesowych do Przypadków użycia i modelu dziedziny i kto ma tego dokonać?
Kto ma opracować to ostatnie? Programista? A na jakiej podstawie, skoro „nie zna tego biznesu” (to programista a nie analityk biznesowy)? Czy same przypadki użycia opisują reguły (mechanizm działania) działania systsemu scoringowego czy systemu upustów w promocji (to jedna liczba, wartość upustu, na fakturze)? Nie. Czy da się na bazie partii testów (czyli skończonej, ale z reguły niezupełnej liście bodziec-odpowiedź) stworzyć cokolwiek? Mało kiedy. Oznacza to, że wymagania zebrane tylko jako przypadki użycia „mało kiedy” dają szansę na powstanie oprogramowania „za pierwszym razem”, tu prototypów nie jest nigdy przewidywalna. To dlatego metody zwane zwinnymi, bazujące wyłącznie na user story i prototypach, nadają się do problemów prostych. Kompletnie nie sprawdzają się w przypadkach złożonych systemów, rozumianych jako złożone mechanizmy. Te ostatnie trzeba nie raz „od zera” odkryć i opisać.
Paradygmat i metody obiektowe
Kluczem metod obiektowych (i paradygmatu obiektowego) jest hermetyzacja. Oznacza to, że złożoność obiektu „z zewnątrz” nie jest znana nigdy, nie ma znaczenia wielkość obiektu (mała klasa czy mega-komponent), na zewnątrz postrzegany jest wyłącznie jako interfejs. Rozważania na początku pokazały, że odpowiedzi na bodźce to oczekiwane (wymagane) cechy rozwiązania, które jednak nie determinują jego mechanizmu.
Oprogramowanie pomagające w nauce tabliczki mnożenia do 100, może zawierać statyczną tablicę znaną z ostatnich stron starych zeszytów, a może to być mechanizm będący implementacją algorytmu mnożenia. Po pierwsze zestaw testów, jak widać, nie determinuje żadnej z tych metod implementacji. Po drugie specyfikacja w pierwszym wypadku będzie „duża” (kosztowna), w drugim bardzo prosta. Po trzecie rozwijanie (tabliczka mnożenia do 1000) oprogramowania w wersji z tablicą statyczną będzie znacznie droższe niż pierwotne wytworzenie wersji z mnożeniem do 100. W drugim przypadku będzie polegało wyłącznie na zdjęciu blokady mnożenia liczb większych niż 10.
Tak więc co z tym TDD? Popatrzmy na to jak jest definiowane:
Co to jest Test Driven Development
Test Driven Development, czyli TDD, to technika tworzenia oprogramowania sterowana przez testy. Tworzenie kodu składa się z wielokrotnie wykonywanych trzech głównych kroków:
Stworzenie testu jednostkowego, który powinien być możliwie najprostszy, aby uniknąć możliwości popełnienia błędu w samym teście. Test ma sprawdzać funkcjonalność, która będzie implementowana w kroku 2.
Implementacja funkcjonalności ? tworzymy funkcjonalność, którą chcemy zaimplementować. Funkcjonalność ta powinna spełniać założenia testu jednostkowego, a wykonanie testu jednostkowego powinno kończyć się sukcesem.
Refaktoryzacja, czyli porządki w stworzonej funkcjonalności. Ma to na celu uporządkowanie kodu, tak aby spełnione były standardy. Czynności wykonywane w tym kroku nie mogą zmienić wyniku testów.
Pod pojęciem funkcjonalność tu rozumiany jest „oczekiwany efekt”, bo test nie jest niczym innym. Czy testy to są (zastępują) projekt wewnętrznej logiki? W przypadkach trywialnych pewnie tak, tam gdzie logika jest prosta lub nie występuje (przypadki użycia typu CRUD), albo tam gdzie „logika” jest „powszechnie znana” zna ją także programista (np. sposób działania zegara).
Jednak system o nietrywialnej logice działania, nie da się wyspecyfikować w postaci skończonej (lub rozsądnie krótkiej) listy bodziec-efekt (np. przykładowych partii gry w szachy). W jednej ze swoich książek Martin Fowler napisał, że żadna ilość godzin filmu znad stołu bilardowego, jako wymaganie, nie da w efekcie nawet namiastki dobrej gry w bilarda. Ale schemat stołu, wymiary kul, kija oraz prawa fizyki rządzące ruchem kul, pozwolą na napisanie wręcz doskonałej symulacyjnej gry. Taki opis to właśnie model dziedziny gry w szachy, dokładny opis mechanizmu tego co dzieje się na stole bilardowym.
Odpowiedź na to pytanie zawiera pewien artykuł, napisany w 2014 roku na nieco inny temat:
…rolą analityka biznesowego nie jest spisanie przebiegu dziesiątek wywiadów i setek indywidualnych wymagań. Nie mają większego sensu dokumenty na dwa, trzy tysiące stron (nikt ich nie czyta!). Rolą analityka biznesowego jest przeanalizowanie dostępnych dokumentów, informacji, i stworzenie opisu mechanizmu działania organizacji oraz opisu rozwiązania, narzędzia mogącego usprawnić działanie organizacji. Opisu zawierającego reguły biznesowe, przetwarzane informacje (wzory dokumentów) oraz listą usług jakie ma świadczyć planowana do wdrożenia aplikacja wraz z opisem tego, jak te usługi mają być realizowane (umiejętności, które można zautomatyzować). Sens mają więc zwięzłe opisy i modele mechanizmów działania organizacji oraz opisy tego jakie informacje i jak mają być przetwarzane z uwzględnieniem tego, że część tych prac nadal będą wykonywali ludzie. Takie jak reguły gry w szachy: ważne są dwie strony opisu reguł gry a nie setki stron opisów przykładowych partii. (Źródło: Warsztaty Analityczne ? Czyli Malowanie Trawy | | Jarosław Żeliński IT-Consulting)
Tak więc robimy to tak, jak w innych dziedzinach inżynierii: analizujemy, projektujemy i zlecamy wykonanie (implementację).
Na zakończenie
Kim jest, członkiem którego zespołu jest (powinien być) projektant? Przewrotnie odpowiem, że praktyka pokazuje, że – z powodu ryzyka projektowego – wykonawca nie powinien sam sobie stawiać wymagań. To dlatego złożone i ryzykowne projekty mają wydzieloną rolę analityka projektanta, nie jest to członek zespołu biznesu ani developera bo obie te strony mają sprzeczne interesy (zakres i koszt). W branży budowlanej jest to Biuro Projektowe (tu architekt), trzeci niezależna rola, poza inwestorem i wykonawcą (z uwagi na ryzyko, prawo budowlane zabrania łączenia jakiejkolwiek z tych trzech ról). W metodykach takich jak SCRUM, jest to Product Owner, i z powyższego powodu nie jest dobrze gdy jest to „człowiek developera”.
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Szperałem w sieci szukając informacji o architekturze i microservisach, a wpadłem na to:
… communication between two different software modules is proportional to the communication between the designers and developers of these modules. Conway?s law exposes the vulnerability in monoliths as they grow in size. Micro-services may not be the best, but better than monoliths for the contemporary web based applications. (Źródło: Micro-Services: A comparison with Monoliths | My Blog)
To „prawo” wyjaśnia dlaczego powstają złe interfejsy a nawet zła architektura: z reguły dlatego, że to – architektura – jest lepszym lub gorszym kompromisem pomiędzy zespołami programistów, ich obciążenia, krótkich terminów itp. Obserwuję to dość często w organizacji pracy developerów. O projektowaniu interfejsów a także o tym, jak „rozdzielać” odpowiedzialności pomiędzy komponenty, dobrych praktykach, dość ciekawe pisał Fowler w swoim artykule:
Tell-Don?t‑Ask is a principle that helps people remember that object-orientation is about bundling data with the functions that operate on that data. It reminds us that rather than asking an object for data and acting on that data, we should instead tell an object what to do. This encourages to move behavior into an object to go with the data. (źr. TellDontAsk).
Jednak, żeby powstała taka „dobra architektura”, ktoś „ponad zespołem developerów” powinien zaprojektować architekturę: komponenty z ich odpowiedzialnościami i interfejsy między nimi.
Typowym problemem jaki napotykam, nie tylko w dużych projektach dla „budżetówki”, jest architektura będąca efektem przepychanek, polityki, walki o „mendejsy”, czyli o to który dostawca (albo wewnętrzny zespół) dostanie większy budżet. To najgorsze i niestety nie raz spotykane metody budowy architektury.
Jak to robić dobrze? Idąc za Fowlerem, podstawą budowy (ustalania) granicy odpowiedzialności komponentu jest „granica kontekstu”. Można to przedstawić tak:
Powyżej pokazano wynik analizy, mamy tu model pojęciowy. Widać, że pewne pojęcia (docelowo klasy, ich operacje i atrybuty) są dość gęsto powiązane, inne luźno. Granice pomiędzy komponentami powinno budować się tak, by silnie powiązane elementy były w jednym komponencie (nigdy nie rozdzielaj rodziny) a interfejsy między nimi były jak najprostsze. Zasada „tell don’t ask” (mów co chcesz dostać a nie dopytuj się o szczegóły) oznacza, że komponent powinien żądać całego elementu i samemu skorzystać, nawet tylko z części, tego co dostał, zamiast detalicznie prosić o drobiazgi. Innymi słowy niezależnie od tego czy w danym momencie potrzebujemy tylko wartości konkretnej faktury, danych nabywcy czy faktycznie całej jej zawartości, zawsze żądamy całej faktury. Dzięki temu interfejs (API) jest prostsze, liczba wywołań API jest zawsze mała. Powyższy przypadek zaowocuje poniższym podziałem na komponenty:
Metoda ta i podejście (jako dobra praktyka), i u Fowlera (cytowany na początku autor artykułu Tell don’t ask) i u Evansa (autor wzorca Domain Driven Design) nazywana jest „bounded context” (granica kontekstu, rodzina zawsze razem i tylko jedna rodzina w jednym mieszkaniu). Dzięki temu uzyskujemy bardzo dobry, przy okazji zgodny z zasadą „[[Open Close Pryncypia]]”, model architektury, który pozwala zlecić komponenty do wykonania, definiując wyłącznie opracowane już interfejsy, kolejność ich (komponentów) wykonania nie ma znaczenia dla całości.
Przy okazji ujawnia się „zło” jakie wyrządza budowanie złożonego oprogramowania na bazie integracji poprzez współdzielenie danych:
Komponenty są silnie od siebie uzależnione (współdzielona baza danych w modelu relacyjnym), nie da się tworzyć (kodować) tych komponentów niezależnie od siebie, bo trzeba uzgadniać a potem uznać, wspólny model danych. Ingerencja w jakikolwiek komponent z reguły oznacza ingerencję w całą aplikację.
Dzieląc system na niezależne komponenty (każdy komponent sam zarządza swoimi danymi) , ustalamy integrację z użyciem interfejsów a nie współdzieląc dane, z czego całkowicie rezygnujemy:
To jest powód dla którego, w dobrych firmach developerskich kluczową rolę pełni architekt. Na poziomie logiki biznesowej, w zasadzie jest nim – takim architektem – analityk biznesowy-projektant, który po zakończeniu etapu analizy i projektowania, pełni rolę „[[product ownera]]”, prowadzącego nadzór autorski i zarządzanie zmianą wymagań.
Tak więc architektura powinna być efektem głębokiej analizy i projektowania z testami, dopiero potem powinna się stać – być może każdy komponent osobno – materiałem do zlecenia dla developerów. Najgorszy wariant to podział na komponenty z pomocą negocjacji, polityki i walki o budżet.
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta – nabywca systemu ERP – powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika (da się wyczytać) rola oprogramowania ERP w firmie: taktykę czyli opis realizacji strategii firmy z pomocą planowanego do wdrożenia systemu ERP. Ta taktyka, to opis tego kiedy i po co oprogramowanie ma wspierać pracownikw organizacji. To, jak się to będzie odbywało w szczegółach, zostanie opracowane przez dostawcę (wykonawcę) konkretnego produktu, to dostawca gotowego oprogramowania opracowuje koncepcję wdrożenia, na podstawie dokumentu opisującego taktykę użycia tego oprogramowania i wymagania biznesowe (oprogramowanie dedykowane wymaga dodatkowo zaprojektowania i udokumentowania logiki biznesowej jaką ma ono realizować).
I co teraz? Teraz potrzebne jest źródło spójnej wiedzy o organizacji, jej strategii i taktyce w którą ma się wpasować oprogramowanie ERP. Któż jest tym źródłem? [[Product owner]].
Pytane teraz brzmi: kim jest i członkiem czyjego zespołu jest (powinien być) „product owner”? Tu zacytuję ostani akapit mojej ciepłej jeszcze recenzji książki:
…na ile wizja produktu uprawnia jej posiadacza do aktywnego kierowania projektem wraz z kierownikiem projektu (Scrum Master), ale to pozostawiam czytelnikom i praktykom. Jedno moim zdaniem jest pewne: nie ma sensu by zespół developera kontaktował się, z tabunem przyszłych ?userów?, ma sens by dostawał spójną wiedzę o tym co tak na prawdę ma powstać.
Autor powyższej książki nie daje wprost odpowiedzi na to pytanie, jednak milcząco zakłada też, że to zespół dostawcy „walczy” ze zjawiskiem i product owner jest członkiem tego zespołu, nie zmienia to faktu, że wymagana od niego wiedza i zrozumienie tego, do czego user będzie używał oprogramowania, powinna być taka jak opisałem wyżej.
Co usłyszałem po raz kolejny (podobne rozmowy z dostawcami oprogramowania nie raz już prowadziłem) od przedstawicieli dostawcy systemu ERP? Potrzebują bardzo zwięzłej i spójnej dokumentacji (ale raczej 50-ciu stron niż setek, że nie wspomnę o kilku tysiącach (tak – widywałem takie) i po stronie klienta (jednej) osoby, która ten dokument zna, rozumie, ma dostęp do kluczowych osób w organizacji. Najchętniej do autora tego dokumentu… Dostawcy oprogramowania jak dostają listę setek pozycji wymagań podzielonych w mało zrozumiały sposób na funkcjonalne i poza funkcjonalne (i inne) raczej sobie z tych specyfikacji dworują niż cieszą się z ich otrzymania (pomijam, ze nie czytają w całości). Po co są więc robione? Bo zamawiający postrzega swoją pracę przez pryzmat jej złożoności, wariantowości, nie patrzy z perspektywy narzędzia a tym właśnie jest oprogramowanie. To tak jak by cieśla lub stolarz opisał wymagania na młotek ciesielski w postaci setek stron „user story” o tym jak, do czego i kiedy używa(łby) młotka.. dla analityka projektanta taki opis (a konkretnie jego skąpa część) ma sens, dla konstruktora – żadnego, ten raczej oczekuje rysunku technicznego wykonawczego.
The role of Product Owner (Scott Ambler, Agile Modeling)
Powyższy diagram to poglądowy model roli product ownera (PO) autorstwa jednego z moich ulubionych „zwinnych analityków”: Scott’a Amblera (Scott Ambler). Niewątpliwie można dywagować czy PO to „pracownik” dosatwcy czy kupującego ale tu chyba część wątpliwości rozwieją słowa jednego z moich klientów, postrzegam go jako jednego z lepiej zarządzających ryzykiem biznesowym, znanych mi, prezesów firm: „Panie Jarku nie wiem czy jest Pan lepszym czy gorszym specjalistą od ludzi dostawcy, zatrudniłem Pana bo przełożonym tamtych jest Prezes tamtej firmy”.
Where Do Product Owners Come From? The goods news is that there are several viable options for where Product Owners may come from: Business analyst. Although a traditional business analyst could fill the role of product owner, there is a risk that they will fall into their old habits of communicating via documentation. Keep in mind that what agile teams really need are people with agile analysis skills who are empowered to make decisions. So, a better option is an empowered agile business analyst. (za The Product Owner Role: A Stakeholder Proxy for Agile Teams).
Tak więc nasuwa się wniosek, że rolę PO powinien pełnić ten człowiek, który właśnie skończył analizę biznesową i napisał raport z niej. Raport, który zawiera specyfikacją wymagań (najlepiej w formie jak opisana powyżej). W zasadzie nadzór autorski nad realizacją taktyki wdrożenia systemu ERP (oprogramowania w ogóle) to nic innego jak „bycie product ownerem” w projekcie na etapie jego realizacji a SCRUM faktycznie, na dzisiejsze czasy, wydaje się być najlepszą metodą zarządzania takimi projektami a utrzymywanie aktualności dokumentu analizy biznesowej i wymagań w toku projektu prowadzi do tego, że po zakończeniu projektu mamy „niechcący” kompletną i aktualną dokumentacje stanu uzyskanego w toku wdrożenia.
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
A tak poważnie, obserwuję stygnięcie ideologii zwinnych metod i przechodzenie od dogmatów do praktyki. Niewątpliwie otoczenie rynkowe zmienia się szybko i metody strukturalne, tak, te z lat 80’tych polegające na wnikliwej i czasochłonnej analizie i budowie całościowego relacyjnego modelu danych dla systemu i projektowaniu listy jego funkcji, to faktycznie „wodospadowe” złe podejście. Tego nikt rozsądny nie neguje. Zwinność jednak, to nie „rezygnacja z pracochłonnej dokumentacji” (często to właśnie słyszę), a uznanie, że oprogramowanie powinno powstawać relatywnie małymi krokami, przyrostowo. I tyle, nie znaczy to, ze rezygnujemy z planowania. Tak, analiza i modelowanie to planowanie tego co ma powstać. To się nazywa iteracyjno-przyrostowe tworzenie systemu. Ok, jedno z głowy.
A kto ma wiedzę o organizacji i o tym jaki produkt w danym projekcie rozwiąże określone problemy? Ten kto tę organizację przeanalizował, opracował wymagania na produkt (tu oprogramowanie) i jednoosobowo ma wizję tego produktu.
Tak, np. taką osoba jest Analityk Biznesowy. Na etapie Analizy Biznesowej jest tym, kto opracuje opis produktu czyli wymagania jakie ma spełniać. Od momentu podpisania umowy na dostarczenie (wytworzenie) tego produktu… pełni (może to robić) role Product Ownera, roli w metodyce SCRUM odpowiedzialnej właśnie za rozumienie tego czym ma być to oprogramowanie. Gorąco polecam książkę: Agile Product Management with Scrum: Creating Products that Customers Love, która tak na prawdę – nieco wbrew tytułowi – traktuje o roli Product Ownera.
Tu pojawia się problem: na ile wizja produktu uprawnia jej posiadacza do aktywnego kierowania projektem wraz z kierownikiem projektu (Scrum Master), ale to pozostawiam czytelnikom i praktykom. Jedno moim zdaniem jest pewne: nie ma sensu by zespół developera kontaktował się, z tabunem przyszłych „userów”, ma sens by dostawał spójną wiedzę o tym co tak na prawdę ma powstać.
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.