Wydaje się, że czas tworzenia oprogramowania, czas zmian w oprogramowaniu bez wykorzystania technik wizualnych jest już przeszłością. Złożoność realizowanych przedsięwzięć wymaga dekompozycji na mniejsze, bardziej zrozumiałe fragmenty. Techniki jest wiele. W moim świecie króluje klasyka, czyli BPMN, UML, ArchiMate. Problem jest nie to czy wspomagać się rysunkami czasem mającymi znamiona diagramów a kto co z tym rysunkiem zrobić później. Gdzie opublikować, jak zebrać informację zwrotną. Szczególnie dotyczy to modeli procesów biznesowych, które powszechnie występują i w zwinnym, i klasycznym podejściu.
Modelowanie procesów biznesowych – znaczenie
Modelowanie procesów biznesowych w procesie wytwórczym oprogramowania to, w moim mniemaniu podstawa, do której odnoszą się kolejne etapy tego procesu. Zależnie od podejścia zespół na podstawie procesów biznesowych i wymagań biznesowych identyfikuje przypadki użycia i wymagania na system albo powstają historyjki użytkownika wraz z kryteriami akceptacji. Programiści „łapią” kontekst zmiany a testerzy budują plany testów i scenariusze testów (zwłaszcza jeśli chodzi o testy integracyjne). Programiści mają ułatwione zadanie w planowaniu kolejności implementacji poszczególnych funkcji.
Modelowanie procesów biznesowych w procesie wytwórczym oprogramowania będzie miało sens, gdy wybierze się dobrze poziomy abstrakcji opisu modeli. Poziom abstrakcji określa jak wiele szczegółów ma być zaprezentowane na danym diagramie. Innymi słowy, poziom abstrakcji nie określa nam ilości informacji a ich zakres. O poziomach abstrakcji więcej pisałem w tekście: Architektura procesów biznesowych a modelowanie procesów biznesowych – poziomy modelowania.
Drugim ważnym elementem jest to co stanie się z narysowanym procesem. Nie sztuką jest to by powstał proces. Sztuką jest, by proces biznesowy żył i wspomagał proces tworzenia bądź zmiany oprogramowania. W moim odczuciu niezależnie od tego czy działamy w zwinnie, czy też klasycznie lub kaskadowo modelowanie procesów biznesowych jest potrzebne. Modele biznesowe pozwalają na:
- zrozumienie jak działa obecnie firma i jak wdrożenie zmiany w systemie informatycznym może zmienić jej działanie (dotyczy czasem 1 procesu)
- poprawienie komunikacji, gdyż pokazanie, dokąd zmierzamy pozwala zrozumieć organizację w ten sam sposób,
- przyporządkowanie do aktywności wymagań biznesowych, które później będą zdekomponowane na wymagania dedykowane poszczególnym systemom
- pokazanie procesu biznesowego na różnym poziomie szczegółowości
Wielką wartością modli procesów biznesowych jest to, że notacja jest już dość powszechnie znana a tym, co jej nie znają poznanie nie zajmuje wiele czasu. Utworzenie modelu nie jest trudne. Ponadto wizualizacja poszczególnych kroków angażuje interesariuszy zarówno w zakresie samego kształtu procesu biznesowego jak i dalszego uszczegóławiania w zakresie wsparcia realizacji poszczególnych kroków przez aplikację.
Modelowanie procesów biznesowych – narzędzia
Jak wspomniałem wcześniej, modelowanie procesów biznesowych w swojej istocie to sekwencja kroków (aktywności) prowadząca do określonego celu. Tworząc taki model wizualnie możemy lepiej zrozumieć proces. Mając obraz całości łatwiej jest nam się skupić na elementach składowych procesu – poszczególnych jego krokach. Pisząc nam, mam tu na myśli interesariuszy zarówno tych, co współtworzą diagram jak i go tylko czytają. Co więcej, wykorzystanie narzędzi, którymi się wspomagamy ułatwia ten proces, ale wymaga przemyślenia strategii dalszej pracy na nad wytworzonymi artefaktami.
Po pierwsze należy więc określić jakimi narzędziami dysponujemy. W wielu firmach króluje Enterprise Architect, Jira i Confluence. Cokolwiek by nie pisać o tych czy innych narzędziach trzeba się ich nauczyć. Bez tego pozostaną martwe. Trzeba pokonać barierę wejścia zwłaszcza interesariuszy biznesowych. Jeśli barier nie pokonamy to zostaje nam nieśmiertelny Word i tysiące stron dokumentacji o niskim indeksie czytania :-). Umiejętność czytania BPMN i faktyczne uczestnictwo w procesie walidacji procesów biznesowych są bardzo ważne.
Modelowanie procesów biznesowych – publikacja
Następnie należy określić jakie artefakty wytwarzamy i gdzie publikujemy – za pomocą jakich kanałów czytaj narzędzi będą nasze procesy biznesowe dostępne. W zależności od tego czy pracuję zwinnie, czy klasycznie to powstają trochę inne zestawy artefaktów. W ujęciu klasycznym interesariusze otrzymają modele procesów biznesowych wraz z wymaganiami biznesowymi i często przypadkami użycia. Na poniższym rysunku prezentuje proces z przykładowym mapowaniem na przypadki użycia i dalej na wymagania funkcjonalne. Oczywiście w praktyce ww. elementy są na różnych diagramach a dzięki mapowania pozwalają na dekompozycje procesów.
W świecie zwinnym proces biznesowy, a raczej jego poszczególne kroki mogą zostać uszczegółowione przez historyjki użytkownika. Na poniższym rysunku widać (zaznaczyłem na czerwono), że do kroku „Przyjęcie zamówienia od klienta” jest przypisane zadanie – historyjka użytkownika w Jira.
Kolejny wariant to utworzenie albo publikacja poprzez wklejenie procesu na wspólnej platformie i opisanie poszczególnych kroków. Taką platformą może być plik Word. Na poniższym rysunku przedstawiam proces biznesowy narysowany bezpośrednio w Confluence za pomocą dodatku umożliwiającego modelowanie w BPMN. Pod procesem może znajdować się tabelka z opisem kroków znajdujących się na diagramie.
Oczywiście powyżej to tylko przykładowy zestaw możliwości publikowania procesów biznesowych. Zakres i miejsce publikowania artefaktów jest zależna od posiadanych możliwości technicznych, gdyż to determinuje sposób będziemy współpracować z interesariuszami. Ważne jest to by procesy biznesowe były dostępne dla interesariuszy.
Modelowanie procesów biznesowych – współpraca z interesariuszami
Klasyczne i obecnie mało efektywny sposób współpracy z interesariuszami to publikacja dokumentacji w Word. Scalanie uwag z kilku wersji pliku tekstowego, co jest wynikiem pracy interesariuszy na swoich wersjach dokumentu, bywa pracochłonne. Dużo lepszy wariant to umieszczenie diagramu z opisem na wspólnej platformie. Tu do wyboru mamy możliwości, tradycyjnie ograniczonych zestawem oprogramowania, którym dysponujemy. Wybrane podejścia to udostępnienia interesariuszom diagramów procesów biznesowych to:
- dostęp do wspólnego repozytorium w Enterprise Architect albo innym narzędziu
- prezentacja na wspólnej platformie takiej jak np.: Confluence, SharePoint przekopiowanych manualnie rysunków
- dostęp do diagramów na dedykowanej platformie webowej umożliwiającej przegląd diagramów np.: Pro Cloud Server
- integracja takich narzędzi jak Enterprise Architect z Confluence lub SharePoint
Wszystkie wyżej wymienione sposoby wymagają by interesariusze mogli wykonać to czego się od nich spodziewamy. Analityk lub Product Owner powinni móc zdefiniować proces, utworzyć wymagania albo napisać historyjki użytkownika. Interesariusze biznesowi powinni mieć możliwość przejrzenia procesu biznesowego oraz powinni móc w miarę łatwo skomentować proces, uzupełnić opis poszczególnych aktywności na procesie biznesowym, współtworzyć wymagania albo historyjki użytkownika.
Istotne jest to, że należy tak skonstruować „obsługę” procesu biznesowego by interesariusze mieli łatwy i w miarę intuicyjny dostęp do modeli, mogli je komentować i poprawiać w uzgodnionym zakresie. Zapewnienie pracy asynchronicznej, na wspólnym zasobie wydaje się być standardem, zwłaszcza w czasach gdy praca zdalna jest bardzo powszechna.
Podsumowując. Z moich obserwacji wynika, że efektywność procesu wytwórczego oprogramowania, jest bardzo uzależniona, od zaangażowania interesariuszy, zwłaszcza interesariuszy biznesowych. Jeśli komunikacja z interesariuszami jest oporna, bo ułożona kaskadowo, brakuje mechanizmów wymiany wiedzy i wymagań, to niezależnie od tego czy działamy zwinnie, czy klasycznie, trudno będzie sprawnie przeprowadzać kolejne iteracje.
Z drugiej strony ważny jest warsztat pracy analityka, jakich to technik dobierze, by udokumentować wymagania. Procesy biznesowe wydają się być oczywiste, potem może wymagania i przypadki użycia albo historyjki użytkownika, a może tylko historyjki uzupełnione diagramami aktywności. Możliwości jest wiele.
Warto nie przesadzić, bo zbyt wiele artefaktów zwłaszcza dublujących się zakresem informacyjnym zmniejsza efektywność. Jeśli do tego dojdzie brak użytecznego mechanizmu udostępniania i walidacji tych artefaktów to przepis na szybką demotywację interesariuszy jest gotowy. To istotne, bo jak napisałem kilka akapitów wcześniej zaangażowanie interesariuszy jest bardzo ważne a ono jest właśnie pochodną między innymi motywacji.
Sponsorem tego wpisu jest kurs z Jira i Confluence, który współtworzę z Natalią Cholewą.
