Podczas mojej pracy zauważyłem, że spory problem stanowią wymagania i w sumie to cała analiza. Trudnością nie jest ich spisanie. Trudnością jest ich wyartykułowanie, przeanalizowanie i potwierdzenie. Pomijam turbulencje związane z celem zamiany czy też budowy systemu. Nie zawsze trzeba wiedzieć, po co się zmienia system. Żartowałem :-). Wiedzieć trzeba.
W tym wpisie podzielić się kilkoma istotnymi zasadami, które, mam nadzieję, że pomogą ustanowić efektywne podstawy dla analizy wymagań.
Model biznesowy to podstawa
Narysuj proces biznesowy. Jeśli robisz drobną zamianę, to zejdź do poziomu systemów. Jeśli większą (np.: wymieniasz system) podnieś poziom abstrakcji. Do aktywności na procesie dodaj wymagania. Mogą być opisane w kroku procesu. Określ w nich, co musi zrobić system, by wesprzeć ten krok procesu biznesowego. Nie zawsze trzeba tworzyć nowy element wymagań, czasem wystarczy zrobić to w opisie kroku. Pisz tak by biznes zrozumiał, co otrzyma z systemu. To cenne informacje, które mogą przerodzić się przypadki użycia albo historyjki użytkownika. Ważne jest to, że zaczynasz zawężać perspektywę patrzenia na system i uszczegóławiasz powoli detale.
Przedstawiciele biznesu są potrzebni
Interesariusze projektu powinni przekazywać swoje wymagania, nadawać im priorytety oraz w odpowiednim czasie podejmować decyzję. Istotnym jest, aby interesariusze projektu zrozumieli tę koncepcję i angażowali się od początku projektu. Stosuje takie techniki, które narzędzia, które wspomogą współpracę, zwłaszcza w obecnym często zdalnym trybie pracy. Miro, Prolaborate to dobre kierunki do zaangażowania interesariuszy. Fajnie jest, jak proces biznesowy ma swojego właściciela. Wtedy on staje się kluczowym interesariuszem. Interesariusze projektu są jedynym źródłem wymagań. Tak, programiści mogą sugerować wymagania, ale interesariusze muszą zaakceptować te sugestie.
Oprogramowanie bez wymagań jest stratą czasu
Jeśli nie ma wymagań, nie ma czego budować. Celem Tworzenia Oprogramowania jest zbudowanie działającego oprogramowania, które spełnia wymogi udziałowców projektu. Jeśli nie znasz tych potrzeb, nie jest w stanie odnieść sukcesu. Twój system musi być oparty na wymaganiach, całościowo na wymaganiach, i na niczym innym jak na wymaganiach. Wymagania możesz zdefiniować za pomocą przypadków użycia, diagramów BPMN (na różnym poziomie abstrakcji), makiet ekranów, opisów itd.. Musisz zmusić/namówić/przekonać przedstawicieli biznesu do tego by powiedzieli, co chcą mieć. Muszą to zrobić w taki sposób, aby dla wszystkich stron stało się jasne, po co to robimy. Lubię iść od ogółu do szczegółu. Od celu zmiany i oczekiwań interesariuszy poprzez wymagania biznesowe albo historyjki użytkownika do scenariuszy działania aplikacji. Scenariusz lubię pokazywać na diagramach aktywności.
Celem jest wzajemne zrozumienie, nie dokumentacja
Podstawowym celem procesu zbierania wymagań jest zrozumienie, czego chcą interesariusze. To, czy stworzysz szczegółową dokumentację opisującą te wymagania, czy być może jedynie zbiór odręcznych szkiców, czy notatek, to już zupełnie inna sprawa. Liczy się zrozumienie.
Modele są dla wszystkich
Jeśli budujesz modele wymagań to pokazuj je publicznie. Modele są ważną częścią kanałów komunikacyjnych, ale działają tylko wtedy, gdy ludzie je widzą i rozumieją. Warto prezentować modele np.: via Prolaborate lub Confluence i na nich/przy nich zbierać komentarze i uwagi interesariuszy. Głęboko wierzę w koncepcję publicznego ujawniania modeli tak, aby każdy miał do nich dostęp i mógł z nimi pracować, nawet jeśli są to tylko szkice lub odręcznie narysowane makiety. Dlatego też…
Modelowanie ma większy sens, gdy modele opisują system z wielu perspektyw
Wymagania odnoszące się do systemu są zazwyczaj złożone, jako że dość często obejmują wiele kwestii. Jako że każdy model ma swoje mocne i słabe strony, żaden pojedynczy model nie jest wystarczający; dlatego też, aby móc wykonać swoje zadanie będziesz potrzebował kilka rodzajów modeli. Warto wymagania przypisać do elementów na modelach albo opisać je w poszczególnych elementach. Wymaganie możesz łączyć z aktywnością procesu biznesowego, ekranem, klasą, komponentem. Możesz wiązać wymagania między sobą. Zwróć jednak uwagę, że…
Nadmiar mapowań też jest szkodliwy
Zachowaj umiar. Potrzebujesz kilku typów mapowań. Ogrom mapowań daje złudne poczcie kontroli nad złożonością oprogramowania. Złudne, bo często ogrom uzyskanych tylko zwiększa koszty ich analizy. Lubię mapowania od góry do dołu. Chodzi o to, by poznając całość dość sprawnie poznać detale, oile na danym etapie analizy i projektu są potrzebne.
Używaj prostych, ogólnych narzędzi i technik
Możliwym jest, a nawet pożądanym, aktywny udział osób zainteresowanych w modelowaniu. Niemniej jednak interesariusze projektu zazwyczaj nie znają technik modelowania ani skomplikowanych narzędzi do modelowania (np.: Enterprise Architect’a). Jedną z opcji jest poświęcenie kilku miesięcy na przeszkolenie udziałowców z zakresu technik i narzędzi modelujących, ale o wiele lepszym podejściem jest użycie prostych narzędzi, takich jak białe tablice i kartki papieru, oraz prostych technik modelowania. Proste narzędzie i techniki są łatwe do nauczenia, dlatego też są one ogólne- każdy może z nimi pracować. Nie strasz ludzi technologią, jeśli nie ma takiej potrzeby. Po uzgodnieniu kształtu i zakresu zmiany/systemu możesz użyć narzędzi Case i utworzyć w nich specyfikację systemu. Na etapie kreowania wymagań, narzędzia takie jak Enterprise Architect są tylko zawalidrogą. Nie zmienia to faktu, że możesz zacząć od kartek a potem w miarę ustalone przebiegi procesów biznesowych narysować w tym czy innym narzędziu. To mały krok, który z czasem może zaowocować w miarę sensowną mapą procesów biznsowych.
Wymagania z czasem zmieniają się
Ludzie często nie wiedzą, czego chcą – a jeśli wiedzą, to zazwyczaj nie wiedzą, jak to przekazać. Co więcej, ludzie zmieniają zdanie – dość często można słyszeć jak udziałowcy mówią „, Teraz kiedy sobie to przemyślałem…” lub „Nie to miałem na myśli”. Co gorsza, środowisko zewnętrzne też się zmienia – być może Twoja konkurencja ogłosiła nową strategię, lub rząd uchwalił nową ustawę. Niestety tak bywa. Jeśli masz wymagania zmapowane na inne elementy dość szybko „ogarniesz” zakres zmiany i przedyskutujesz jej impakt na dotychczasowe prace.
Większość wymagań powinna być niezależna od technologii
Wymagania powinny określać czego (jakich funkcji) spodziewamy się po systemie. Muszą być napisane w języku, jaki używa biznes. Niemniej jednak nie tworzymy oprogramowania w próżni. Ważnym jest być świadomym tego, że niektóre wymagania, takie jak ograniczenia techniczne mówiące, iż Twój system musi używać konkretnych technologii i baz danych stosowanych w Twojej organizacji. Twoi udziałowcy muszą zrozumieć, kiedy ma to zastosowanie i dlaczego. Dlatego też modele i wymagania we wczesnych fazach trzeba konsultować z ludźmi odpowiedzialnymi za bezpieczeństwo, infrastrukturę, architekturę oraz zespołem programistów. Wczesne określenie ograniczeń technologicznych sprzyja w kreowaniu wartościowych wymagań biznesowych.
Mam nadzieję, że te 10 porad sprawi, że Twój proces analizy będzie bardziej efektywny. Powodzenia 🙂
