W wielu firmach toczy się dyskusja o sformalizowaniu procesu wytwórczego oprogramowania. Spontaniczne tworzenie diagramów, tysiące historyjek rozrzucone po Jira, setki stron w Confluence tworzone przez szeroko rozumianych analityków i projektantów nie buduje wartości dokumentacji. Wartość powstaje, gdy cały zespół dokłada diagram do diagramu jak cegiełka do cegiełki. Dodawane modele procesów biznesowych lub diagramy BPMN uzupełniają się wzajemnie. Tworząc artefakty nie tylko trzeba realizować projekt. Tworząc artefakty należy zostawiać po sobie metodycznie uporządkowany ślad – mapę, która posłuży do podejmowania decyzji w kolejnych iteracjach.
Myśląc o wdrożeniu metodyki, dość często myśli się o narzędziach i notacjach. Notacje mniej absorbują. Upraszczając: jest UML i BPMN jest modelowanie :-). Wybór narzędzia wspierającego modelowanie i analizę jest o tyle ważny, że dziś mamy mix metodyk i podejść. Nie ma już tylko modelowania i tylko opisów słowno muzycznych. Wizualizacja czy to procesów, czy to zależności między elementami składowymi rozwiązania przynosi wartość.
Szukając narzędzia, warto rozważyć by narzędzie lub narzędzia wspierało zespół w poniżej wymienionych obszarach. Oto one (rozwinięcia hasłowo):
Podejście iteracyjne i dekompozycja
Modele są budowane przyrostowo z zachowaniem reguł obiektowości. Istotne jest to, by móc dany fragment procesu zdekomponować, gdyż tylko dekompozycja zapewnia taki poziom szczegółowości, jaki jest w danej chwili danym odbiorcom potrzebny. Nie ma co tworzyć zbyt wielu warstw, bo ich utrzymanie jest kosztowne a zysk z ich utrzymania niewielki. Każdy poziom dekompozycji powinien być dedykowany innym grupom interesariuszy.
Obiektowość i ponowne użycie
Raz zdefiniowany proces biznesowym scenariusz użycia funkcji aplikacji, w przypadku ponownego użycia powinien być raz zwizualizowany i opisany w repozytorium projektu. Szkoda czasu na wielokrotne opisywanie tych samych działań, obiektów (generalnie artefaktów). By tak się stało w repozytorium utrzymywać dwa obszary. Jeden AS-IS – baza do zmian i drugi TO-BE – repozytorium modyfikacji, w których powstają planowane zmiany. Koszt utrzymania i synchronizacji jest sporym narzutem, ale warto go ponieść. Tu istotna jest adekwatna dokumentacja.
Adekwatna dokumentacja
Dokumentacja musi być budowana szybko w ustalonych szablonach. Szablony nie oznaczają formatki Word, a to, że zespół ma ustalone widoki (perspektywy), które chce pokazać. Warto utrzymywać procesy biznesowe (diagram BPMN), architekturę (diagramy komponentów UML) i scenariusze działania funkcji aplikacji (diagramy aktywności). Wszystkie te artefakty mogą być skorelowane z historyjkami użytkownika (JIRA) lub publikowane online (Confluence i Prolaborate) Generatory dokumentacji, publikacja modeli online, nanoszenie zmian i komentarzy na modelach oszczędzają czas.
Modele i notacje
Dobre narzędzie wspierające modelowanie pozwala na zastosowanie notacji zgodnej ze standardami. Modele mogą i powinny uzupełniać się nawzajem. Wybór stosowanych elementów z notacji, przykładowe model pomagają zespołowi pracować lepiej, a odbiorcy dokumentacji przyzwyczajają się i uczą czytać modele, które są reużywalne.
Praca grupowa
Modele budowane są dla ludzi i przez ludzi. Musi istnieć możliwość pracy grupowej, udostępniania zasobów i identyfikacji odpowiedzialnych za zmiany na diagramach. Komentowanie modeli, zarządzanie zmianą pomagają. Nie ma jednej metodyki pracy grupowej.
Jedno repozytorium dla wielu interesariuszy
Budując modele procesów biznesowych, chciałbym móc wykorzystać je w przyszłości do projektowania systemów IT. Tworząc architekturę korporacyjną, dobrze jest mieć referencje do realizacji np.: usług aplikacyjnych. Jedno repozytorium projektu jest tu kluczem do sukcesu.
Kultura organizacji
Nie można zapomnieć o przyjętych praktykach w danej organizacji. Złe praktyki trzeba wyeliminować. Dobre pielęgnować. Narzędzie CASE powinno wpierać ten obszar. Nie ma nic gorszego niż narzucenie “od górne” produktu, który swoim działaniem łamie i niszczy to co jest dobre i zostało już wypracowane przez organizację
Macierze zależności
Aktywność z procesu biznesowego, przypadek użycia powinien być zmapowany z wymaganiami lub regułami biznesowymi. Pozwala ta na lepsze zrozumienie zasad funkcjonowania procesu oraz sprawdzenie pokrycia wymagań. Śledzenie zmian także jest ułatwione. Przemyślane mapowania od ogółu do szczegółu, ograniczona liczba typów elementów w repozytorium pomaga w utrzymaniu modeli oraz analizie wpływu zmiany. Zbyt wiele mapowań i powiązań wbrew pozorom nie pomaga.
Podsumowując. Narzędzia CASE to tylko dodatek, ważny dodatek, ale tylko dodatek do modelowania, gdyż ważna jest metodyka wytwarzania i modyfikacji aplikacji. Warto zachować przestrzeń, bufory między poziomami atrakcji, tak by zamodelowane przykładowo procesy biznesowe dało się uszczegółowić projektem. Bufory są o tyle ważne, że przy obecnych zmianach technologii zbyt szczegółowe projekty są nieaktualne zbyt szybko. Ponadto tak jak pisałem powyżej: szukając narzędzia, warto rozważyć by narzędzie lub narzędzia wspierało zespół w poniżej wymienionych obszarach. W wielu przypadkach będzie to mix narzędzi, ale niech to będzie taki mix, z którego korzystają w swoim zakresie wszyscy. Warto by było jedno miejsce prawdy. To może być Confluence a może modele wykonane w moim ulubionym Enterprise Architect. Ważne jest to, by od ogółu można było przejść do szczegółu.
Myśląc o metodyce, warto przeanalizować obecny proces wytwórczy. Zapewne wiele już ze stosowanych praktyk można udoskonalić. Może warto ograniczyć liczbę diagramów, a może trzeba wręcz odwrotnie zacząć modelować. Niemal zawsze warto poprawić komunikację i zaangażowanie interesariuszy biznesowych. Wdrożenie narzędzi do modelowania powinna być ewolucją, usprawnieniem procesu, a nie rewolucją. I takich właśnie ewolucji Tobie życzę 🙂
