[zaktualizowany [last-modified]]
Niedawno pisałem na temat „modelu systemu” i „modelu dziedziny systemu”. Oba te pojęcia są sobie bliskie, pierwsze jest bardzo ogólne, dotyczy systemu zawężonego do jego dziedzinowej specyfiki. Model dziedziny systemu to także, w inżynierii oprogramowania, nazwa konkretnego komponentu, nazywanego Model, w architekturze opartej na wzoru MVC. Swego czasu pisałem, że (Czym jest a czym nie jest model dziedziny…):
Pojęcie system oznacza albo detaliczną strukturę określonej rzeczywistości albo abstrakcję ją reprezentującą (model systemu).
Jest to standardowe tłumaczenie tego pojęcia w literaturze z zakresu teorii systemów a także właśnie inżynierii oprogramowania .
Mam właśnie za sobą kilka spotkań na targach IT Future Expo. Dotyczyły między innymi roli „product ownera”, analityka biznesowego i wymiany informacji pomiędzy developerami i „resztą świata”. Okazuje się, że największym problemem w projekcie jest: (a) zrozumieć czego chce zamawiający biznes, (b) przetworzyć to tak by developer wiedział co ma zaimplementować. I tu niestety jest problem: developer owszem jest bardzo dobry w implementacji… i w niczym więcej. Co ciekawe, programiści, z którymi często mam do czynienia, nie potrafią (nie chcą?) myśleć abstrakcyjnie, oczekują typowej „kawy na ławę” (pierwszy dzień projektu a tu nagle ktoś pyta o typ pola „nazwisko”). Gorzej, wielu z nich myśli wyłącznie o oddaniu kodu „na jutro rano”. Paradoksalnie, nie mała rotacja na stanowiskach programistów oraz regularne przenoszenie wszelkich kosztów i ryzyk na kupującego (który tego nie wie, bo nie rozumie tej technologii), powoduje, że przemyślana architektura całości to coś czego nie nikt robi, developer po prostu koduje…
Nie walczymy z faktami, musimy się z nimi zmierzyć. Jak? Dać developerowi i egzekwować architekturę i logikę systemu jako wymaganie, a nie „zebrane wymagania”. Niestety, osoba zwana analitykiem, nie powinna postrzegać swojej pracy jako „kolekcjonera” („zbieranie wymagań” zawsze kojarzy mi się ze zbieraniem grzybów). Tak zwany analityk musi abstrahować od wszelkich detali, bez tego projekt zostanie już na samym początku „zabity” ich ilością. To się nazywa „utrata panowania nad złożonością projektu” a w konsekwencji „utrata panowania nad zakresem projektu”. W artykule o zegarze [1] opisałem jak to zrobić, tu opiszę źródła tego podejścia.
Analiza systemowa dziedziny problemu
Praca analityka powinna mieć charakter „naukowy”: na bazie faktów opisuje się logikę działania analizowanej organizacji . Przede wszystkim trzeba mieć świadomość, że badanym systemem jest np. organizacja a nie „tylko system informatyczny”. Organizacja (firma, urząd, itp.) to system składający się z ludzi i narzędzi jakich używają a całość jest sterowana regułami (prawo, regulacje wewnętrzne niespisane zasady itp.). Część z tych narzędzi to oprogramowanie. Jeżeli jest to oprogramowanie planowane do zakupu i wdrożenia, to znaczy, że ktoś musi zrozumieć stan obecny, zrozumieć cele i zaprojektować stan przyszły, zakładający istnienie nowego oprogramowania. Nie ma tu znaczenia czy będzie to oprogramowanie wspomagające produkcje czy prawnika i jego pracę.
A gdzie wymagania? Wymaganiem jest projekt logiki (architektura) nowego oprogramowania. Czy to robota analityka? Tak, bo developer jest od wykonania implementacji.
Zegar. Abstrakcja systemu
Przede wszystkim warto uporządkować użyte tu pojęcia, które są często mylone lub źle interpretation:
- abstrahujemy od czegoś
- idealizujemy coś
Modelowanie polega na abstrahowaniu od określonych szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm.
Powinno paść pytanie: Co system robi? (będzie robił jak go wdrożymy).
Jeżeli byłby to zegar, to „system wskazuje aktualny czas”. To jest biznesowy cel, uznano, że potrzebna jest stała znajomość aktualnej godziny, a nie „my chcemy mieć zegar”.
Teraz decyzja: Jak system to robi? Może to być zegar ścienny, analogowy, cyfrowy, może to być stale włączone radio. Decyzja brzmi: zegar ścienny analogowy (poniżej prototyp w postaci mock-up’u).
I dopiero teraz wiem o co pytać dostawców!
Tu drażliwy moment. Jeżeli opiszemy to tylko prostymi historyjkami użytkownika to może się skończyć tak, że developer po prostu stworzy kilkadziesiąt obrazów tarczy zegara i będzie je wyświetlał np. na wiszącym ekranie. To nic innego jak literalnie zrealizowane „zebrane wymagania” (proszę się nie śmiać, tak to nie raz wygląda: „hardkodowanie” wymagań).
Dlatego warto jednak opracować abstrakcyjną architekturę rozwiązania czyli model opisujący mechanizm działania tego co chcemy otrzymać:
To nam zagwarantuje, że developer nie pójdzie na łatwiznę, że nasz zegar będzie się dał w przyszłości rozwijać i modyfikować .
Teraz dopiero developer, mając (i słusznie) nieco związane ręce, opracuje koncepcję realizacji (Jak system został zrealizowany?), my ją zatwierdzimy i dostaniemy np. to:
…albo oprogramowanie zawierające trzy komponenty i wyświetlacz. Jak nam kiedyś przyjdzie do głowy dodanie datownika albo zamiana tarczy analogowej na cyfrową, to będzie to rozwój oprogramowania a nie kosztowne pisanie od zera (gdyby nam dano projektor z filmem z nakręconym zegarem analogowym). To jak ten system został zrealizowany zależy od developera, jednak jego logika i architektura powinny być opracowane wcześniej po stronie zamawiającego i narzucone developerowi (inżynierom).
Inny przykład. Popatrzmy na szklankę jako opisane historyjkami użytkownika wymagania:
- możliwość picia kawy,
- możliwość przechowania cukru,
- możliwość złapania muchy na stole,
- możliwość podlania wodą kwiatów,
- ….
Alternatywą dla tego opisu będzie:
– Szklanka jako projekt: „szklany cylindryczny pojemnik o średnicy 8 cm i pojemności 250 ml”.
Zastanówcie się, który z powyższych opisów będzie większym ryzykiem, jeżeli wyślemy go do huty szkła jako zamówienie na 1000 szt. szklanek dla pracowników… .
P.S.
Czy te „możliwości” to przypadki użycia szklanki? Nie. Przypadek użycia szklanki, to co ona faktycznie robi (usługa systemu), to przechowanie/magazynowanie substancji ciekłej lub sypkiej z pewnymi ograniczeniami takimi jak np. maksymalna temperatura. Te możliwości to co najwyżej historyjki użytkownika… które są może dobrym materiałem do analizy ale nie są dobrym wymaganiem. Większość programistów, jak dostanie tak opisane „możliwości” jako wymagania, to je po protu wprost zakoduje i odda „system zgodny z wymaganiami”… sami oceńcie jego przydatność teraz i w przyszłości…
Jako programista napiszę jak wygląda to z naszej perspektywy. Trzymając się Twojej metafory zegara: ok, klient chce widzieć aktualny czas; mam zespół, który specjalizuje się w składaniu trybików… składaliśmy z nich już rozrzutniki obornika, skrzynie biegów i takie tam; ale nigdy nie składaliśmy zegara mechanicznego, ba nie wiemy, że istnieje takie coś jak zegar mechaniczny czy jakikolwiek zegar oraz, że ktoś w ogóle mierzy czas i co to jest czas.
Tak więc przeskok od pomiaru czasu do obracania się trybików ma po drodze zbyt wiele *przeskoków wnioskowania*. Samo wymaganie jest dla nas niewiele warte, ew. może służyć jako kryterium odbioru ale tutaj można zrobić jak piszesz „wyświetlanie z góry umówionych obrazków” bo nikt nie rozumie JAK to działa, tylko CO ma pokazać.
Wiem, że brzmi to jak Monty Python ale tak powstaje soft:P
Są oczywiście zespoły, które znają się na zegarach mechanicznych lub na czasomierzach ogólnie. Ale generalnie niewielu znajdziesz chętnych aby zawężyć swoją specjalizację do składania trybików z zegary bo w przyszłości może pojawić się klient od skrzyni biegów czy czegoś bardziej intratne i byłoby nieracjonalne aby inwestować wysiłek intelektualny (czas i „miejsce” w głowie) w poznanie natury czasomierzy.
Pytanie brzmi: kto ma zaprojektować implementację? Bo ja spotykam się z:
– my jako developer zrobimy po swojemu bo wiemy i mamy pomysły
– my jako developer oczekujemy detalicznego projektu
I powiedz mi bo chyba mi albo Tobie coś umknęło: jeżeli daję opis mechanizmu jak ten: MECHANIZM to kto powinien opracować implementację? Albo jaki poziom szczegółów należy dać developerowi by nie narzucać mu tego co on sam robi dobrze?
P.S.
Ja stosuję taką strategię:
– daję dość ogólny projekt aby jak najmniej wiązać ręce developerowi (w zasadzie logika biznesowa)
– developer pyta o wszystko czego nie wie lub woli dostać, a ja do doprecyzowuje
Jak Ty to widzisz?
To nie jest takie oczywiste… jeżeli mamy wnioskowanie a->b->c->d gdzie po jednej stronie jest potrzeba biznesowa a po drugiej rozwiązanie techniczne, to teraz zależy do którego poziomu może/chce/powinien dojść wykonawca.
W domenach „życiowych” ludzie miewają zwykle lepsze intuicje niż w bardziej hermetycznych.
Wydaje mi się, że problem jest w kierunku przekazywanie informacji. Klasycznie kierunek jest PUSH: analityk, klient, po,… nie wie czego do swojej pracy potrzebuje wykonawca, nie zna się, nie wie co on wie, więc tworzy jakieś utwory i artefakty.
Często nietrafione, bo to co jest oczywiste dla odbiorcy artefaktów analitycznych jest dobrze opisane a to nie jest nie jest opisane (pomijam jakoś intelektualną tych wytworów oraz zdolność do analitycznego myślenia ich autorów, bo tu można by rozpocząć festiwal użalania się).
Lubię DDD za to, że promuje podejść PULL: wykonawca (który sam wie czego potrzebuje do pracy) wyciąga wiedzę jakiej potrzebuje. Oczywiście nie każdy wykonawca będzie na tylko doświadczony i świadomy aby dobrze to wyciągnąć ale ilość odpadów (waste) w całym procesie produkcji kodziku (bo na koniec dnia to kodzik na serwerze robi lub oszczędza pieniądze) jest znikoma.
Czy to znaczy, że generalnie: jeżeli w pełni opiszę logikę biznesową, tę którą ma realizować aplikacja, to wykonawca, mając to CO I JAK MA ROBIĆ logika, ubierze to w implementację i zagwarantuje jakość (wymagania pozafunkcjonalne)? Bo DDD w zasadzie tak chyba należy rozumieć. Mam teraz taki właśnie problem w projekcie: wykonawca dostał projekt w którym ma dwóch aktorów: klienta firmy oraz pracownika firmy, ich uprawnienia opisują maszyny stanowe obiektów biznesowych i reguły (np. jeżeli zamówienie ma stan „do sprawdzenia” to dostęp do niego ma wyłącznie pracownik dla którego atrybut stanowisko=sprzedawca. Tu ważna jest wiedza, że pracownicy mają często zmieniany zakres uprawnień i mogą one być różne w różnych projektach. Statusy dokumentów zmieniają się dynamicznie (są dla nich opisane maszyny stanowe). Wykonawca jednak forsuje model implementowania skończonej ilości kombinacji uprawnień (nazywają to rolami, było ich nawet kilkadziesiąt plus kłopot z zarządzaniem nimi). Tu faktycznie projektuję „prawie wszystko”, tak jak napisałeś. Czy taki model uważasz za bezpieczniejszy? Bo ja czasami mam nadzieję, ze architekturę detali opracuje na bazie SOLID itp… developer… jednak to co piszesz skłania mnie do jednego wniosku: developer ma dostać logikę biznesową tacy i bez potrzeby domyślania się czegokolwiek. Czy tak?
Podpucha:)
opisz w kilku zdaniach idealnego developera i idealny dokument dla niego 🙂
Przypadek, który opisujesz wygląda jak by wykonawca uznał, że rozwiązywał już podobny problem i najlepsze będzie rozwiązanie, które już zna. Ryzykowna jest teza, że problem jaki kiedyś rozwiązywał jest analogiczny do aktualnego. Jeżeli wykonawca uznał, że tak to prawdopodobnie na własną rękę dokonał analizy – pytanie zatem po co byłeś tam potrzebny Ty;)
Co do idealnego develoepra to w DDD mamy 3 role: ekspert dziedzinowy, modelarz i facilitator. Modela ma za zadanie stworzyć model dziedziny problemu, który będzie implementowalny – więc mamy tutaj nieczęsto występujące w przyrodzie zjawisko, że ktoś jest w stanie rozmawiać z tak zwanym biznesem i jednocześnie mieć wyobrażenie o rozwiązaniu. No ale te kompetencje daje się ćwiczyć i coraz więcej osób na rynku pracy może bez problemu stanąć do roli modelarza.
No to uff.. jednak nie jestem sam w tej opinii… Ja także uważam, że „Ryzykowna jest teza, że problem jaki kiedyś rozwiązywał jest analogiczny do aktualnego. ” (nie znam przypadku gdy w dedykowanych projektach copy-paste miało by sens). Po drugie: jeżeli developer dostaje projekt i mimo to forsuje swój to znaczy, że forsuje swoje inne rozwiązanie, pytanie na jakiej podstawie skoro nie robił analizy? Jeżeli robił swoją mają już moją to pytanie po co skoro to dodatkowy koszt?
Skoro już tak szczerze rozmawiamy, to dodam, że wykonawcy zwykle robią swoją analizę ponieważ nie widzą wartości w artefaktach dostarczonych analityków. Nie widzą jej bo a) nie rozumieją lub b) artefakty te są miernej jakości.
Twój warsztat znam ale widziałem też tony wytworów innych „analityków” i muszę z przykrością zgodzić się ze starym indiańskim przysłowiem, które mówi, że „lepiej nie mieć w projekcie analityka niż mieć słabego analityka”. Wykonawcy zaczynają też instynktownie odróżniać osoby posiadające umysł zdolny do analitycznego myślenia od osób posiadających jedynie wpisy w nazwie stanowiska pracy. Tak więc nie możemy się dziwić, że wykonawcy doświadczeni „życiowo” z automatu przyjmują postawę „panie, idź Pan w %$# z tymi dokumentami, sami się temu przyjrzymy”. Nie chcę oceniać czy to dobrze czy to źle, po prostu „mówię jak jest”:)
🙂 odpowiedziałeś na pytanie …
Ale jest też drugi problem z „niektórymi” developerami: tkwią w technologii i architekturze (narzędziach) z przed 30 nawet lat. Nie stosują „powszechnie znanych wzorców projektowych” (nie tylko DDD), upierają przy waterfall czyli „najpierw zaprojektujemy tę jedynie słuszną relacyjną bazę danych dla całego projektu”… i Ci także mówią ?panie, idź Pan w %$# z tymi dokumentami, sami się temu przyjrzymy?…. ale powody są inne: oni to napiszą w Borlandzie …
Skoro nie działa w ich przypadku mityczna „niewidzialna ręka wolnego rynku” to muszą mieć jakieś walory o jakich nie mamy wiedzy:) Może w tych projektach chodzi o coś innego niż się nam wydaje…
Obserwuję dwa wytłumaczenia:
– jak zauważyłeś: „inne niż nam się wydaje”,
– nie potrafimy inaczej ale mimo to oferujemy swoje usługi.
Ale obserwuję też, że „niewidzialna ręka wolnego rynku” jak najbardziej działa… Zjawisko, o którym tu piszemy to ostatnie podrygi dinozaura, jednak zanim dinozaur padnie, ktoś się z nim jeszcze meczy… Czasami dinozaur przed śmiercią zdąży np. na szkolenie u Ciebie 😉 i uniknie śmierci …