Prawie 3 lata temu po raz pierwszy pisałem o Prolaborate. Wtedy też opisywałem Pro Cloud Server (Enterprise Architect Pro Cloud Server – modelowanie w chmurze). Pro Cloud Server nadal jest jednym z narzędzi, jakie oferuje Sparx Systems, które umożliwia dostęp do repozytorium modeli poprzez przeglądarkę internetową. W tym wpisie, który jest aktualizacją wpisu z 2019 postanowiłem dopisać spostrzeżenia z pracy w Prolaborate.
Prolaborate to narzędzie, które umożliwia współpracę z modelami, czytanie ich, komentowanie poprzez przeglądarkę internetową. W Prolaborate możemy pracować wprost na obiektach z modelu Enterprise Architect. To kolejne takie rozwiązanie, które pozwala w dość łatwy sposób poprawić komunikację pomiędzy interesariuszami projektu. Do czytania modeli wystarczy zwykła przeglądarka internetowa. “Biznes” nie musi uczyć się już obsługi Enterprise Architect. Może dostać tą informację, która jest mu potrzebna. Publikacja modeli przez internet to także możliwość uniknięcia pracy na MS Word. Z mojego punktu widzenia praca bezpośrednio na modelu ma tę zaletę, że poszczególne elementy wymagania, przypadki użycia, procesy biznesowe, architektura są ze sobą połączone. Mając sieć tych powiązań mogę sprawdzić na co dane wymaganie wpływa, co tak naprawdę zmienia konkretny przypadek użycia? W dokumentach “papierowych” te relacje znikają lub są trudniejsze do zidentyfikowania.
Co znajdziemy w Prolaborate?
Zacznijmy od tego, że Prolaborate pozwala na dostęp do wielu repozytoriów. po drugie umożliwia przypisanie widoczności poszczególnych pakietów wybranym użytkownikom.
To oznacza, że teraz można udostępniać dokładnie to co chcemy danej grupie interesariuszy udostępnić. W ramach uprawnień można dać prawo do czytania modeli, współpracy tj. komentowania oraz dokonywania zmian w modelach. Prolaborate zapisuje te informacje w swojej autonomicznej bazie danych. Warto jest wspomnieć, że ta edycja to zmiana opisów albo dodawanie elementów. Rysować jeszcze nie można. Można za to jednym kliknięciem przenieść do Enterprise Architecta do tego diagramu, który chcemy zmienić.
Prolaborate nie pozwala na to by użytkownik w tym samym momencie korzystał z dwóch różnych repozytoriów. Prolaborate nie scala ich. Trzeba się przełączyć.
Poza możliwością dostępu do repozytorium i przeglądania modeli wielką wartością jaką wnosi Prolaborate to dashboardy. Poniżej kilka dasboardów
Dashboard jest wstępem do bardziej zaawansowanego raportowania, gdzie na skonfigurowanych zakładkach widać ostatnio zaktualizowane dyskusje linki odpowiednie widoki.
Dashboard dla danego repozytorium może być konfigurowany poprzez zdefiniowane Widgety. Możemy przedstawić tą informację, która dla nas jest potrzebna w momencie rozpoczynania pracy z repozytorium.
Dyskusja w Prolaborate
Z punktu widzenia wykorzystania Prolaborate to ta funkcja jest chyba jedną z ważniejszych. Wspólna praca, bez Worda, z dostępem do modeli przez przeglądarkę internetową zmienia sposób współpracy. Zwiększenie zaangażowania interesariuszy jest widoczne i tym samym współpraca jest bardziej efektywna.
To co jest ważne to to, że uprawnieni użytkownicy mogą edytować treść oglądanych elementów. Należy zwrócić uwagę, że Prolaborate kładzie większy nacisk na komunikację. Wszędzie można znaleźć ikonki zachęcające do dyskusji. Dodanie komentarza skutkuje wysłaniem maila z notyfikacją.
Tutaj należy wspomnieć o ważnym elemencie. Dyskusja, jaką znamy z Enterprise Architect i dyskusja z Prolaborate – choć odnoszą się do tego samego elementu to to nie jest ta sama dyskusja. Dostęp do komentarzy zapisanych w Prolaborate jest możliwy po zastosowaniu dodatku Prolaborate add-in for Enterprise Architect.
Prolaborate udostępnianie
Kolejną funkcją, o której warto wspomnieć jest opcja udostępniania, która nie tylko umożliwia przekazanie linka prywatnego lub publicznego do diagramu, ale także pozwala na wklejenie diagramu na inną stronę internetową.
Ostatnią i chyba najbardziej pożądaną, zwłaszcza z punktu widzenia podejścia zwinnego, jest integracja z JIRA i Confluence.
Po pierwsze diagramy i opisy mogą znaleźć się w Confluence i być aktualne w czasie rzeczywistym. Po drugie możemy niemal dowolnie mapować elementy z Enterprise na Elementy JIRA.
Po integracji Prolaborate z JIRA, link do zadania w JIRA zapisuje się przy elemencie. Dodatkowo w Prolaborate można mieć podgląd w statusy realizacji poszczególnych zadań. Przydatną funkcją wydaje się także synchronizacja dyskusji w JIRA z dyskusją zapisana w Prolaborate. Jeśli chcesz zobaczyć, jak to działa to ramach kursu z Enterprise Architect udostępniłem ogólnodostępną lekcję: https://wolski.pro/kursy/zagadnienia/21-prolaborate-integracja-z-confluence-i-jira/
Prolaborate poza instalacją na serwerze umożliwia pracę w chmurze. To rozwiązanie, które Sparx Systems oferuje jako zamknięty produkt. W chmurze jest repozytorium, Prolaborate i PCS. Użytkownik dostaje tylko link do repozytorium. Cały koszt utrzymania jest zawarty w cenie usługi. To bardzo wygodne rozwiązanie, które nie wymaga VPN, stacji przesiadkowych itd. Odciąża też dział IT.
Czy warto korzystać z Prolaborate?
To zależy od organizacji. Moim zdaniem poprawia on jakość komunikacji, dostępność modeli i wpisuje się w zmiany w podejściu do modelowania. Ma być łatwo, jakby przyjemnie i przez weba :-). Zapewne dlatego takie narzędzia jak Jira i Confluence są tak popularne. Usprawnienie komunikacji z interesariuszami to już wymóg. Niestety nie ma róży bez kolcy. Wdrożenie nowego podejścia nie będzie łatwe. “Biznes” ma często problem z przeczytaniem dokumentów w MS Word. Najczęściej brakuje czasu. W sumie to zrozumiałe. Interesariusze bardzo często zajęci nie tylko wymyślaniem co robi system, ale także bieżącą operacyjną pracą. Bardzo często brakuje mu odpowiednich kompetencji. Korzystanie z bardziej zaawansowanych technik i narzędzi wymaga większej dojrzałości organizacji. Ta dojrzałość to nie tylko ogłoszenie, że wdrażamy nowe lepsze zabawki a przede wszystkim zaproszenie “biznesu” do tworzenia procesu wytwórczego oprogramowania, szkolenia i wsparcie komunikacji.
By zaprosić biznes trzeba mu poświęcić trochę uwagi dać realne do wykonania zadania. Narysowanie modelu z prośba o kometarz do niego, albo uzupełnienie treści zdefiniowanych wymagań to dobre kroki na początek tej przygody.
Prolaborate to wiele funkcji wspomagających pracę organizacji, ale nie jest to tanie rozwiązanie. Do swojej pracy potrzebuje Pro Cloud Server w wersji płatnej. Aktualne ceny można znaleźć na stronie: https://modesto.pl/kategoria-produktu/enterprise-architect-prolaborate/
Wydaje się, że nastały dni, w których wybór takich narzędzi jak Prolaborate czy opisywany wcześniej Pro Cloud Server to nie tylko decyzja “IT”. To wspólna decyzja “IT” i “Biznesu”, nie tylko dlatego, że biznes będzie korzystał z tego narzędzia. “IT” i “Biznes” są jak układ oddechowy i układ krążenia. Jeden pompuje krew a drugi zapewnia tlen. Jeden dostarcza oprogramowanie, za pomocą którego drugi zarabia pieniądze, by rozwijać to oprogramowanie. Jeśli jeden z układów przestaje działać to cały organizm – organizacja – zaczyna obumierać.
Myślę, że nadchodzi czas, w którym, w procesie wytwórczym oprogramowania, linia podziału pomiędzy “IT” a “Biznesem” będzie się zacierać. Już działamy zwinnie a takie narzędzia jak Prolaborate będą wspierać ten proces.
Cześć,
Fajny (choć nieco zdawkowy :)) artykuł. Zajmuję się Prolaboratem już drugi rok i mam kilka nieco odmiennych przemyśleń. Na początek zgodzę się Michale, że bez porozumienia z biznesem, żadna zmiana w procesie nie jest możliwa. Ale jak już ją przejdziesz, to zapewniam Cię, że nikt do 'wordów’ nie będzie chciał wracać. To opinia jednego z klientów, z którym współpracujemy w Prolaborate i mamy za sobą projekt w tym środowisku. W tym aspekcie to game-changer!
Zgodzę się też z opinią, że jest to dość kosztowne narzędzie (głównie przez koszt PCS, którego Sparx promuje – ot, takie prawo monopolisty). Z drugiej zaś koszt całego środowiska to jakieś 2-3 pensje specjalisty. Zważywszy, że można przy użyciu tego środowiska zejść z czasem dystrybucji i akceptacji artefaktów projektowych o rząd (!!) wielkości, to jest się o co bić. Prolaborate to agile-enabler, i to nie tylko przez integrację z JIRA i Confluecne ale też dzięki zaimplementowanym w nim samym mechanizmom (chociażby review).
Nie stawiałbym jednak WebEA i Prolaborate w jednym szeregu. Ja osobiście wieszczę przyszłość Prolaborate jako następcy / zastępcy dla WebEA, który się po prostu nie sprawdził.
Na korzyść Prolaborate przemawia argument, że jest to swego rodzaju centrum sterowania i integracji a nie kolejne narzędzie – i tym wg. mnie wygrywa.
Myślę, że kluczowe staje się tu to jak łatwo dostraja się Prolaborate do potrzeb, jak wiele można pokazać, a jednocześnie jak wiele ukryć nie tracąc przy tym spójności modelu.
Kilka przykładów zastosowań Prolaborate opisałem na blogu Ateny, (https://blog.atena.pl/) kolejne w przygotowaniu. Ja jestem zafascynowany tym podejściem.
Jacku dzięki za komentarz :-). Osobiście też uważam, że WebEA odejdzie i zostanie tylko Prolaborate. W artykule nie opisałem wielu opcji, ale to, co jest pod „maską” ma olbrzymi potencjał. Za kilkanaście miesięcy będzie wiadomo czy się przyjmie na naszym rynku.
Trochę słabo wygląda informacja, że komentarze w Prolaborate i komentarze w Sparxie – nie są tożsame. Czyli osoba pracująca w programie – dalej musi skakać po innych miejscach ( w tym wypadku portalu Prolaborate) by zobaczyć czy są jakieś uwagi. Niczym to nie różni się od sytuacji gdzie ktoś komentuje w Wordzie, Conflu itd. Myślałem, iż po takim czasie firma jednak opracuje sprawniejszy mechanizm.
Mam też pytanie odnośnie „Użytkownicy mogą mieć dostęp tylko do tych gałęzi repozytorium, do których jest to konieczne. ” – W dużych repozytoriach powszechne jest, że na diagramach zamieszcza się obiekty leżące „fizycznie” w różnych Modelach/pakietach/gałęziach. Przy generowaniu z samego Sparxa raportu HTML – takie obiekty były „nieklikalne” na stronie. Podobnie przy tworzeniu materiału rtf/doc – dla obiektów spoza pakietu (ale umieszczonych na diagramie w nim) – nie można było wygenerować części informacji. Jak to wygląda tutaj?
Treść artykuł przed momentem uzupełniłem. Dostęp do komentarzy zapisanych w Prolaborate jest możliwy po zastosowaniu dodatku Prolaborate add-in for Enterprise Architect. Nie trzeba skakać :-).
Odnośnie do elementów w różnych pakietach. Elementy, do których nie mam dostępu a są umieszczone na diagramach do których mam dostęp są klikalne. Co więcej, jeśli mam prawo do edycji diagramu, na którym jest element z pakietu, do którego nie mam dostępu to mogę zmienić jego nazwę i treść.
Ok. To już wygląda znacznie ciekawiej. Dziękuję za info
Dla mnie słaba jest konieczność wykorzystywania wersji chmurowej EA – to raz. Nawet duże instytucje obejrzą każdą złotówkę dwa razy, zanim wydadzą na coś, czego nie rozumieją, albo nie widzą podstaw do stosowania (zwłaszcza w metodyce zwinnej, bo „dla mnie najważniejszy jest kod, nie dokumentacja” – to opinia z jednego z projektów, dodam – położonego na wznak przez „wyjadacza agile”, dyrektora działu). Dwa, o wiele bardziej, niż „dyskusja” interesuje mnie możliwość elastycznego generowania dokumentu w Confluence tak, by działała synchronizacja komentarzy, przenosiła się struktura i „klikalne” diagramy, nie koniecznie synchronizacja całych modeli, bo to ja – Analityk jestem odpowiedzialny za model. Biznes nie zna organizacji modelu, a sama organizacja repozytorium (jego struktury), to już wyzwanie! Jeśli wpuścić tutaj kogoś, kto nie rozumie tego kontekstu, pojawia się bałagan. Interesujące byłoby to narzędzie w wersji z klasycznym repozytorium. Trzy – nakładanie na Biznes obowiązku poznania choćby jednego diagramu UML to tak, jakby kazać Programiście nauczyć się myślenia strategicznego Prezesa Firmy, bo akurat musi oprogramować Dashboard dla Zarządu… Nie tędy droga. Confluence to środowisko publikacji dokumentu, który może być podstawą pod dyskusję z Biznesem, ale nie po to, by przenosić Biznes w świat IT i wymagać od niego poznania naszych narzędzi pracy! Nie bez powodu w metodykach teoretycznie „Agile”, takich jak SCRUM, w zespołach często pojawia się… Analityk! Prowokacja zamierzona 😉 Od kilku/nastu projektów pracuję w projektach „Agile”, jako Analityk… Po prostu Agile to dogmat, który nie wytrzymuje zderzenia z rzeczywistością – Biznesem, który nie chce znać technikaliów, z Programistą, który połknął kij od szczotki i jest „elastyczny inaczej” w obliczu zmiany, a w ogóle nie rozumie potrzeby dokumentowania i stosowania standardów, albo z Product Ownerem, który wierzy, że można od razu przekazać Wymaganie Programiście i będzie git. Kończy się „reverse engeneeringiem” kodu w każdej kolejnej wersji systemu… To rolowanie długu technologicznego z wersji n.0 do (n+1).0, co skutkuje tym wspomnianym „reverse engeeneringiem” w wersji (n+1).0. Po czym pojawia się w projekcie Analityk i musi zrobić robotę, której nikt wcześniej nie uważał za konieczną, ale wcześniej musi wytłumaczyć, że w końcu trzeba zacząć pracować na poważnie! Nie wiem, czy to u Ciebie (chyba tak) przeczytałem kiedyś o Budzie dla Pikusia i podejściu do budowania projektów, że trzeba po prostu dostosować metodykę do zadania – święta racja! Do zadania, do skali projektu, Zespołu itd. Nie da się tak samo podejść do budowy Budy dla Pikusia i Mostu przez Wisłę. Warto spojrzeć na to, jak pracują Budowlańcy – oni mają takie podejście projektowe od co najmniej kilkuset lat, a zasady obowiązujące przy budowaniu czegokolwiek liczą co najmniej 11 600 tysięcy lat, jeśli wierzyć w datowanie Goebekli Tepe. Graham Hacock twierdzi natomiast, że niektóre budowle megalityczne liczą po kilkadziesiąt tysięcy lat, pochodzą sprzed Potopu i Epoki Lodowcowej a technologia ich wykonania do dzisiaj nie została wyjaśniona – patrz budowle w Peru. Tak więc uczmy się od Budowlańców, oni nie budują mostów Agile’owo (dlatego kosztują tyle, ile miały, a nie 1,5 mld zł zamiast 700 mln, jak niektóre projekty IT), dlatego mają Architektów (w IT Analitycy) i Inżynierów Budowlańców (w IT Architekci, dla „ułatwienia” mapowania kompetencji)! PS. Żeby nie było – bardzo lubię podejście Agile’owe, ale zgodnie z duchem Agile i Lean, a nie zgodnie z literą tej, czy innej metodyki – czytaj: dogmatem. Agile to mój styl pracy, elementy SCRUMa i innych podejść, to narzędzia. Podobnie jak Prolaborate, ale chyba jednak nie w projekcie, w którym pracuję…