Prolaborate – Less Is More


Chciałbym zaproponować nowe podejście do dzielenia się wypracowanym materiałem analitycznym, które ma na celu odpowiedź na następujące pytania:

  • Jak nie przytłoczyć odbiorcy informacją?
  • Jak zbudować model na miarę potrzeb i udostępnić go przez Prolaborate?
  • Jak przygotować modele EA do pracy w Prolaborate?

Używając Enterprise Architect, nie raz można odnieść wrażenie, że ktoś tu przeszarżował z liczbą atrybutów i operacji, jakie można wykonać w odniesieniu do jednego obiektu. Jak bowiem wytłumaczyć partnerowi biznesowemu, do czego służą te wszystkie statusy, fazy, wersje, stereotypy, typy…? A po co mu to w ogóle tłumaczyć?

Przecież naszym celem jest porozumienie się na poziomie trosk biznesu i sposobów ich zaspokojenia przez rozwiązanie IT. Aby nie przytłoczyć naszego odbiorcę informacją, musimy ją odpowiednio sprofilować. W tym przypadku naprawdę „mniej znaczy więcej”.

Dla projektu istotne będzie przygotowanie odpowiednich punktów widzenia, interesujących z perspektywy procedowanego problemu. Punkt widzenia to nic innego jak diagram w EA, prezentujący wybrany kontekst informacji.

Informacja ta opiera się na zbiorze pakietów (katalogów informacji), zawierających obiekty reprezentujące kategorie informacji przetwarzane w repozytorium, w tym zgłaszane potrzeby w zakresie nazwa potrzeby i jej opis, powiązanych ze sobą relacjami. Czasem można pokusić się o dołączenie jakiejś bardziej rozbudowanej dokumentacji, nadającej kontekst problemowi. Służą do tego Linked Documents (również dostępne z poziomu Prolaborate).

Z drugiej strony, chcemy zaprezentowaće, jak dana potrzeba biznesu będzie zaadresowana do rozwiązania w warstwie IT, z dokładnością do nazwy wymagania na system, jego skróconego opisu.

Technikę tą nazywam dekompozycją funkcjonalną, czyli przejściem z domeny biznesowej (trosk) do domeny aplikacji – pomysłu, jak te troski rozwiązać na poziomie IT.

Mamy więc odpowiedź na pierwsze z postawionych na wstępie pytań.

Jak osiągnąć ten efekt w Prolaborate?

Zaczynamy oczywiście od przygotowania stosownego modelu w EA. Na diagramie umieszczamy obiekt reprezentujący wymaganie biznesowe (troskę klienta). Może on wyglądać następująco:

http://prolaborate.atena.pl/LNZUgv

Do każdego obiektu typu wymaganie klienta, dodajemy Composite Structre Diagram, na którym dokonujemy dekompozycji, czyli analizy zgłaszanego problemu przedstawienia propozycji jego rozwiązania w postaci obiektów wymagań, opisujących fragment aplikacji potencjalnie rozwiązujący ten problem. Diagram taki może wyglądać następująco:

http://prolaborate.atena.pl/LfHow8

Dowiązujemy nowe wymagania funkcjonalne korespondujące z daną troską lub dodajemy i zmieniamy istniejące zapisy na poziomie wymagań funkcjonalnych. Tak przygotowany diagram będzie dobrym początkiem dialogu z klientem nad właściwym zrozumieniem trosk i ich zaspokojeniem w obszarze IT. Ten etap to właśnie synteza, czyli składanie w całość rozwiązania dla zdefiniowanego problemu.

Oczywiście, można wszystko zaprezentować na jednym diagramie. Proponuję jednak samodzielnie  ocenić efekt, jaki uzyskujemy tą metodą.

http://prolaborate.atena.pl/ItNPK

Diagram jest przeładowany informacją i mało czytelny. Sugeruję, by stosować jednak diagramy  kontekstowe , prezentujące wybrany wycinek analizowanego zagadnienia. Naszym celem jest przecież uzgodnienie zakresu projektu w tym konkretnym aspekcie, a nie zaprezentowanie wszystkich jego niuansów od razu, w jednym miejscu. O spójność modelu zadba narzędzie Case – do tego właśnie służy!

Czas na LessIsMore’zm!

Grupie użytkowników definiującej biznesowe troski, dajemy możliwość korekty swoich zapisów z dokładnością do nazwy wymagania biznesowego i jego treści – niczego więcej na tym etapie nie potrzeba.

Dla analityka zaś kluczowe będzie odniesienie się tego wymagania biznesowego na zasadzie dyskusji, komentarzy oraz udostępnienie opisu koncepcji rozwiązania w formie wymagań funkcjonalnych na system (mogą to też być UserStories) wraz z możliwością prowadzenia dyskusji nad tą koncepcją.

W Prolaborate należy udostępnić powyższy diagram (np. w postaci dashboard) i można zacząć pracę. Aby była efektywna, dla powyższych obiektów dajemy dostęp do wybranych atrybutów. W przypadku wymagania biznesowego może to być nazwa i opis do edycji dla klienta, opcjonalnie załącznik do wymagania LD dostępny w sekcji <References> okna <Attributes> oraz status do wglądu (w trybie do odczytu). W przypadku wymagań funkcjonalnych te same atrybuty będą interesujące, niemniej – zgodnie z paktem o nieagresji – dajemy możliwość tylko ich przeglądania z dodatkową opcją prowadzenia dyskusji.

Zakres atrybutów dostępnych dla poszczególnych typów obiektów definiuje się na poziomie całego modelu Prolaborate.

Dla analityka czy też innych interesariuszy projektu dostępne będą więc te same atrybuty, ale na poziomie uprawnień możemy zmieniać poziomy dostępu i ingerencji w odniesieniu do nich.

Nawigacja po modelu odbywa się na podstawie struktury zdefiniowanej w EA. Czasem jawi się potrzeba powrotu do diagramu innego, niż wynika ze struktury EA. W takim przypadku z pomocą przychodzi funkcjonalność EA związana z tworzeniem skrótów do diagramów. Aby link był odpowiednio widoczny, można użyć typu linku „Navigation Cell”.

Cała ta koncepcja skupia się na tym, aby udostępnić i wyeksponować tylko te informacje, które znacząco wspierają budowanie koncepcji rozwiązania. Mimo, że każdy z tych obiektów opisany jest większą liczbą atrybutów, z perspektywy tej fazy projektu kwestie merytoryczne są dominujące i na nich się skupiamy w komunikacji z klientem.

Kwestie projektowe, takie jak statusy dla poszczególnych obiektów, oznaczenia kodowe, opis fazy czy priorytetu, schodzą na plan dalszy. I tak właśnie rozumiem „LessIsMoryzm”. Skupmy się na rzeczach istotnych, zróbmy je raz, a dobrze, i idźmy dalej!

Prezentowana koncepcja organizacji modelu EA i pracy w Prolaborate wspiera to podejście. Oczywiście wymaga ona pewnej praktyki i doświadczenia oraz – a może przede wszystkim – przygotowania i uzgodnienia tej formy współpracy z klientem (odbiorcą informacji). Niemniej powyższy koncept został sprawdzony w boju i wnioski, jakie płyną z doświadczenia, przemawiają na korzyść tego podejścia.

Proszę nie traktować tego artykułu jak instrukcję obsługi. Stanowi on jedynie inspirację dla proponowanego podejścia. Sam proces konfiguracji środowiska i przygotowania wszystkich interesariuszy do tego stylu pracy liczy się w dniach – przy odrobinie wprawy – poniżej tygodnia.

W efekcie dostajemy narzędzie do sukcesywnego i sprawnego budowania specyfikacji rozwiązania już od pierwszego kontaktu z klientem aż po fazę wdrożenia i zarządzania zmianą.

Warto wspomnieć, że ten model pracy można rozpropagować na kolejne fazy przygotowywania specyfikacji rozwiązania.

Oczywiście do każdej z faz należy podejść indywidualnie, ale robimy to raz dla całego modelu i potem już kolejne iteracje możemy prowadzić tak samo, w standardowy sposób.

Myślę, że warto spróbować!

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *