Prawdziwy potencjał Prolaborate, czyli pakt o nieagresji


Szmat czasu minął, odkąd zaczęliśmy używać Prolaborate. Co więcej, nasi klienci zaczynają dostrzegać potencjał drzemiący w tym rozwiązaniu. Czas więc na małe podsumowanie, czym ono jest, a czym nie jest, oraz jak wpisuje się w nasz proces wytwórczy.

Od lat poszukiwałem sposobu, aby nie powtarzać tej samej pracy wielokrotnie i korzystać z raz już wypracowanych artefaktów w kolejnych etapach projektu. Jednocześnie zależało mi na zaangażowaniu jak największej liczby osób decyzyjnych w pracę nad tymi artefaktami. Kontynuując, ważne okazało się też, aby każda ze stron mogła zachować swoją percepcję problemu jednocześnie mogąc odnosić się do tego co wypracuje inna część zespołu. Na koniec – ważne było, aby nie utracić czytelności w tak rozbudowanym środowisku a jednocześnie pracować efektywnie i budować kolejne rozwiązania nie psując już istniejących!?

Jak można pozwolić biznesowi opowiadać o jego troskach jego językiem, odnosić te troski do rozwiązań na poziomie projektu i jednocześnie pozbyć się inercji jaką wprowadza duży obszar informacji, jakim niewątpliwie jest dokumentacja analityczno – projektowa.

Odpowiedzią jest PROLABORATE.

Zapraszam na cykl artykułów poświęconych temu zagadnieniu. Pierwszy z nich to „Pakt o nieagresji” – czyli jak zachować spójność rozwiązania mówiąc różnymi językami – biznesu i IT i!? ”

W dużym uproszczeniu Prolaborate to dodatek do Enterprise Architect (w skrócie EA), pozwalający udostępniać zawartość modeli EA i aktywnie angażować interesariuszy przedsięwzięcia w uzgadnianie finalnych wytycznych dla projektu. Mówiąc prościej – to, co wypracujemy w EA, możemy w czasie quasi-rzeczywistym udostępnić i uzgodnić z odbiorcami tej informacji oraz przygotować finalną postać zapisów dla całego modelu.

Wydawałoby się, że to nic odkrywczego. Otóż nie do końca, gdyż powszechnie stosowane podejście dokumentowania zakresu projektu w dokumentach MS Word cechuje się dużą inercją – proces uzgodnień, często przebiegający w trybie zmian, potrafi trwać miesiącami. Można oczywiście próbować ratować się rozwiązaniami klasy JIRA, ale tu z kolei nie znajdziemy (podobnie jak w MS Word) śladowania, czyli powiązania z sobą obiektów modelu. Mam tu na myśli dekompozycję, a nie sztywne wiązanie EPIC -> Story – etc…

Dlaczego to takie ważne? Otóż narzędzia CASE, w tym EA, nie są – wbrew powszechnej opinii –  „lepszym Wordem”. Dokumentacja pochodząca z EA jest produktem ubocznym procesu analizy i syntezy wniosków. Największa wartość posiadania modelu to właśnie owo śladowanie. Innymi słowy,  możliwość śledzenia / analizy konsekwencji podejmowanych decyzji, dzięki powiązaniom obiektów modelu. Pozwala to zarządzać ryzykiem decyzji, którego pierwotnie nie dostrzegliśmy. Tu EA i jego funkcjonalność śladowania (Tracebility) pokazują swoją siłę, o czym wspominałem w jednym z poprzednich artykułów. Przypominam o tym dlatego, że do Prolaborate przeniesiono największe atuty podejścia CASE’owego.

Prolaborate bazuje na modelu pochodzącym wprost z repozytorium EA. Tym samym mamy wsparcie w postaci śladowania. Od architektury informacji przyjętej w danym repozytorium analitycznym będą zależały ścieżki drążenia modelu i analiza otoczenia w odniesieniu do procedowanych koncepcji. O tym, jakie to proste, świadczy poniższy link. Wystarczy, że w EA zdefiniuję diagram, udostępniam go bez żadnych restrykcji poprzez link (poniżej). Praca na „żywym” modelu wymaga już autoryzacji niemniej jest równie prosta.

Rysunek: przykładowa architektura informacji:  http://prolaborate.atena.pl/LFsWOY

Punkty widzenia, które prezentujemy w Prolaborate, pochodzą wprost z EA.

W tym miejscu nasuwa się pytanie: po co nam Prolaborate, skoro wszystko pochodzi z EA? Odpowiem pytaniem na pytanie: czy ktoś kiedykolwiek próbował zaangażować biznes do pracy w EA? Polecam to bezcenne doświadczenie. 🙂 Otóż Prolaborate uwalnia biznes od konieczności uczenia się tak zaawansowanego narzędzia, jakim jest EA. W Prolaborate udostępniamy tyle, ile trzeba, w formie zrozumiałej dla odbiorców końcowych i – co najważniejsze – nie tracimy wartości dodanej, jaką generuje EA: wspomnianego już śladowania.

W Prolaborate możemy pracować wprost na obiektach z modelu EA. Głębokość drążenia modelu, jak i dostęp do informacji oraz zakres ich zmiany zależą od konfiguracji. W naszym podejściu bardzo jasno rozkładamy akcenty i deleguję odpowiedzialności. Nazywam to „paktem o nieagresji”. Klient ma prawo decydować o postaci zapisów swoich trosk i oczekiwań wyrażanych w postaci biznesowego celu projektu oraz wymaganiach biznesowych. Natomiast my jako dostawca możemy je co najwyżej komentować, by zgłosić  ewentualne niejasności bądź konieczność doprecyzowania zapisów.

I odwrotnie: wymagania funkcjonalne są tożsame z konkretnym rozwiązaniem. Byłoby zatem  wysoce niewłaściwe, gdyby klient wpływał wprost na ich zapisy. Stąd też dajemy możliwość komentowania i dyskusji nad postacią owych zapisów, ale ich finalna postać pozostaje w naszej – dostawcy – gestii.

Wszystkie te elementy modelu pochodzą wprost z modelu analitycznego, gdzie stanowią całość i są podstawą (fundamentem) dla danego projektu. Nie ma znaczenia, czy projekt zaczynam, czy kontynuuję. Uzupełniam tylko tyle, aby nadać kontekst modelowanemu zagadnieniu i wiąże ze sobą właściwymi relacjami.

Całą resztę załatwiają za nas EA i macierz dekompozycji funkcjonalnej. Oczywiście wszystko to można zaprezentować w postaci KANBAN.

Rysunek: Diagram wymagań klienta http://prolaborate.atena.pl/n3h18

Rysunek: Diagram wymagań systemowych funkcjonalnych http://prolaborate.atena.pl/7CtsAn

Udostępnianie diagramów przez przeglądarkę to – nie powiem – świetna sprawa.  Ale nie po to powstał Prolaborate! Każdy element można podejrzeć, w zakresie przewidzianym przez konfigurację danego repozytorium. Zarówno zakres atrybutów, jak i możliwość ich edycji, zależą od posiadanego zakresu uprawnień. I tak jak już wspomniałem, w tym samym repozytorium nasz klient będzie mógł pracować na obiektach reprezentujących jego troski i postrzeganie problemu z zachowaniem wszystkich specyficznych aspektów opisu (z językiem naturalnym włącznie). Analityk może to co najwyżej skomentować. I odwrotnie –  zapisy dotyczące specyfikacji systemu będą dostępne dla owego analityka do edycji, a dla klienta tylko do opiniowania, a wszystko na bazie aktualnych danych wprost z EA. Proces uzgodnień w tej formie można skrócić w wymiarze czasu o rząd wielkości.

Co istotne, elementy modelu przygotowane w tej fazie projektu będą dostępne w kolejnych fazach, nadając kontekst kolejnym fazom projektowania rozwiązania. To kolejna korzyść i argument na rzecz Prolaborate i pracy w modelu analitycznym. Dokumentacja MS Word zazwyczaj wykorzystywana jest jednorazowo – potem pracę zaczynamy od początku. Tu bazujemy wciąż na tych samych elementach, dokonując ich korekty na bieżąco, w  miarę potrzeb.

Aby rozpocząć dyskusję nad danym zagadnieniem, wystarczy wskazać obiekt, którego ma dotyczyć, a następnie wskazać osoby potencjalnie zainteresowane danym zagadnieniem.

Całą resztę załatwi za nas Prolaborate: wyśle powiadomienia mailowe do osób wskazanych w dyskusji, a na wszystkich diagramach oznaczy dany obiekt, informując że w odniesieniu do danego obiektu wymagana jest akcja – opinia, podjęcie decyzji czy zaproponowanie rozwiązania alternatywnego.

Co jednak wydaje się najważniejsze, śladowanie pozwoli podejrzeć otoczenie omawianego problemu (np. powiązane UC lub prototypy GUI) i zweryfikować, czy projektowane rozwiązanie jest bezpieczne i zgodne z oczekiwaniami. Dla nieco bardziej zaawansowanych analiz przeznaczona jest funkcjonalność trafnie nazwana „Impact analysis”. Daje ona możliwość stworzenia dynamicznego diagramu dla wybranego obiektu i jego otoczenia.

Rysunek: Dynamiczny diagram Impact Analysis: możliwość wielowymiarowej analizy zagadnienia

Pełen zakres funkcjonalności Prolaborate trudno omówić w jednym krótkim artykule. Z perspektywy doświadczeń mogę wskazać jednak następujące interesujące i wykorzystywane w naszym środowisku możliwości:

  1. ograniczenie dostępu do informacji dla wybranych użytkowników (model EA vs to, co w Prolaborate);
  2. różnicowanie zakresu dostępu w zależności od użytkownika (grup użytkowników);
  3. prezentowanie i praca na wybranym kontekście informacji;
  4. przeglądanie zawartości modelu poprzez zagnieżdżanie się w kolejne poziomy informacji (w funkcji przyjętej architektury informacji dla modelu EA);
  5. prowadzenie dyskusji w samym Prolaborate i wizualizacja tego faktu na diagramach;
  6. możliwość przeniesienia dyskusji do JIRA i dwukierunkowe nawigowanie pomiędzy tymi narzędziami w kontekście jednego zagadnienia’
  7. obserwowanie postępu prac poprzez wizualizację statusów dla poszczególnych obiektów;
  8. zaangażowanie w pracę na tym samym modelu całego zespołu bez konieczności szkolenia z EA i wdrażania dedykowanego narzędzia.

Prolaborate wciąż się rozwija, oferując nowe funkcjonalności. Z mojej perspektywy to nie tylko narzędzie, ale przede wszystkim sposób myślenia o pracy w nowoczesnych, zwinnych środowiskach wytwórczych. Mocno kibicuję temu trendowi i sam silnie go wspieram. W kolejnych artykułach postaram się przybliżyć kolejne ciekawostki z tego obszaru.

Dodaj komentarz

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