Domain Driven Design – Język wszechobecny

Język wszechobecny to jeden z głównych filarów DDD. Bez niego nie da się dobrze wdrożyć tej metodologii w projekcie. Zespół projektowy to nie tylko developerzy, ale także analitycy, testerzy i klient. Zespół musi się ze sobą komunikować i wzajemnie rozumieć. Często poszczególni członkowie z racji swoich stanowisk używają wewnętrznych żargonów nierozumianych przez resztę zespołu. Prowadzi to do niezrozumienia oraz późniejszych problemów z zaspokojeniem potrzeb klienta, który zamawiając huśtawkę otrzymuje linę. Aby temu zapobiec należy ustalić na początkowym etapie projektu wspólny język, który będzie stosowany przez cały okres trwania projektu oraz w okresie jego utrzymania.

Jak zapobiec nieporozumieniom?

Aby choć w podstawowym stopniu móc przełożyć to na jasny, zrozumiały komunikat, należy zastosować elementy języka uniwersalnego – wszechobecnego (ang. Ubiquitous language). Należy przez to rozumieć przeprowadzenie wspólnej analizy dziedziny, jakiej dotyczy projekt, co pozwoli na stworzenie jednolitego nazewnictwa poszczególnych elementów. Wpłynie to na lepszą oraz szybsza współpracę.

Najbardziej uniwersalną oraz pomocną w tym wypadku będzie metoda wytwarzania oprogramowania, Domain-Driven Design. Polega ona na definiowania obiektów, komponentów systemu oraz ich zachowań, aby jak najwierniej odwzorować rzeczywistość. Po stworzeniu takiego modelu o wiele łatwiej będzie przejść do jego technicznych aspektów. Dzięki takiemu podejściu eksperci znający zapotrzebowanie mogą je przełożyć na informację jasną dla programistów.

Aby stworzyć projekt, który będzie bogaty w wiedzę do jego opisu należy zastosować język używany przez grupy, które odpowiadają za każdy etap procesu. Z mojego doświadczenia mogę przyznać, że eksperci z danej dziedziny mają często bardzo duży problem ze zrozumieniem technicznego języka używanego przez programistów, odpowiadając im, nieświadomie używają żargonu znanego tylko w ich dziedzinie.

Często zdarza się także, że eksperci tworząc zakres projektu oraz zadania, które mają zostać wykonane działają zbyt ogólnikowo, co tworzy problemy przy późniejszym etapie. Jakiekolwiek próby tłumaczenia jednej stronie przez drugą wymagań skazane są na porażkę. Jednak w większości skomplikowanych projektów takich jak np. aplikacje finansowe, nie można sobie pozwolić na najmniejszy błąd. Wtedy właśnie należy zastosować język wszechobecny.

Komunikacja nigdy nie jest prosta

Patrząc na odpowiedzialność każdego ze stanowisk można stwierdzić, że komunikacja biznes – IT musi występować na każdym etapie projektu informatycznego. Sponsor tworząc budżet musi to robić przynajmniej w minimalnym stopniu w porozumieniu z działem IT, który posiada doświadczenie i możliwość wstępnej wyceny. Już na tym etapie bardzo ważne jest pełne zrozumienie treści przekazywanych przez obie strony.

Tak samo ważne, jak nie ważniejsze jest zrozumienie tego, czego oczekuje biznes a co może stworzyć IT. Jest to największy problem, ponieważ biznes nie zawsze jest w stanie zrozumieć możliwości działu IT i czasem wymaga rzeczy, które będą nierealne do zrealizowania w przyjętym budżecie. Dlatego też na tym etapie język uniwersalny odgrywa najważniejszą rolę. Jeżeli tutaj go zabraknie może okazać się, że wymagania, które zostały przedstawione przez biznes, a to, co stworzył dział IT to dwa zupełnie różne projekty.

Dlatego najważniejsze zadanie stoi przed kluczowym użytkownikiem i analitykiem. Ponieważ jeżeli uda się przełożyć na język uniwersalny to, czego chce kluczowy użytkownik, analitykowi będzie prościej przełożyć to na zadania programistów. Jest to najważniejszy proces, który określać będzie wymagania.

Klient z analitykiem muszą stworzyć zbiór wymagań wobec systemu, który będzie zgodny z celami. Jest to moim zdaniem najbardziej czasochłonny proces, ponieważ analityk musi przeprowadzić rozmowy z wszystkimi przedstawicielami biznesu związanymi z projektem, aby poznać ich wymagania. Tutaj napotyka się największe trudności, a będą one związane przede wszystkim z:

  • Brakiem precyzji klienta, który nie wie w jaki sposób osiągnąć założone cele.
  • Brakiem wspólnej terminologii – duży system jest wykorzystywany przez różne grupy ludzi korzystające ze specyficznego języka zawodowego.
  • Brak obecności użytkowników końcowych – bardzo często zdarza się, że analityk współpracuje tylko i wyłącznie z menedżerem procesu, co nigdy dobrze się nie kończy.
  • Różny poziom szczegółowości opisu projektu przez analityków za pomocą języka naturalnego. Rodzi to potem wiele trudności związanych z doprecyzowaniem konkretnych zadań.

Tłumacz projektów biznes – IT

Po zebraniu danych przez analityka od przedstawicieli biznesu pojawia się kolejny problem, którego nie można jednoznacznie rozwiązać. Komunikacja między analitykiem a programistami. Czy analityk po spotkaniu z kluczowym użytkownikiem powinien także za pomocą języka uniwersalnego przekazać informację do programistów? Czy też powinien „przetłumaczyć” na techniczny, wewnętrzny język, dzięki któremu programiści będą dokładnie wiedzieć, co robić? Analityk powinien być swoistym „tłumaczem projektów biznes – IT” rozumiejącym obie strony, tłumaczącym języki każdej ze stron.

Dodatkowo pomocny może być model objaśniający, który wprowadzi członków zespołu w powiązane konteksty, które nie są bezpośrednim elementem modelu. Mogą one tłumaczyć metafory czy skróty myślowe używane przez biznes lub pokazywać inne perspektywy. Dzięki temu programiści mają szerszy obraz tematu lepiej rozumieją zagadnienia i pojęcia języka wszechobecnego.

Jak widać problem w komunikacji zaczyna się od samego początku współpracy. Podziela to także moja obserwacja oraz ankieta. W tej części dział IT musi zrozumieć, że wypłata w kolejnym miesiącu zależy od tego czy projekt będzie realizowany zgodnie z tym, co założył sobie biznes. Nie można jednak traktować tego tylko w taki sposób. Jeżeli dział biznesu długo nie będzie wiedział czego chce i różne firmy nie będą mogły sprostać jego wymaganiom, może okazać się, że nikt więcej nie podejmie się realizacji projektu.

Dlatego w sposób możliwie prosty, dział biznesu musi przedstawić na czym polega dana aplikacja i w jaki sposób będzie na siebie zarabiać. Stworzenie odpowiedniego, zrozumiałego języka, który będzie wspólny dla obydwu „światów” pozwoli na stworzenie dokumentacji. Samo stworzenie dokumentacji nie gwarantuje jednak sukcesu. Sukcesem będzie, kiedy po obydwu stronach, zarówno IT jak i biznesu będzie osoba, która potrafić będzie przetłumaczyć rozwiązania każdej ze stron

Podobne posty

Jestem programistką, która lubi mieć ręce pełne roboty. Do życia potrzebuje komputera z internetem i kubka gorącej kawy. Więcej na stronie o mnie.

Comments

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here