Agile business analyst has the capability to keep the wheel rolling. They?re a transformative funnel through which a requirement passes down to the delivery path towards an expected outcome. This SDLC machine needs continuous fuel in the form of well-defined and informed information which is provided by an agile business analyst. As long as an agile business analyst does the job, this machine will remain on its course to deliver greater solutions.Coming to our original question, is an agile business analyst a myth or a reality? There is a clear answer. It is a reality if an organization realizes the value, but it is a myth for immature organizations whose processes are ill-defined and are nowhere on a path towards best practices. (Is Agile Business Analyst a Myth or a Reality? )

Tak więc (zwinny) analityk biznesowy to model pracy polegający na stałym dostarczaniu (na etapie implementacji) kolejnych informacji. Projekt tworzenia aplikacji zawsze trwa w czasie, więc w toku tworzenia oprogramowania zmienia się biznes.

Developerzy często mówią, że klient zmienia im wymagania, a tak na prawdę ktoś zbyt wcześnie zapisał zbyt wiele szczegółów. Implementacja dedykowanego oprogramowania to tak na prawde pętla iteracyjno-przyrostowa: zbieramy informacje potrzebne do wytworzenia jednej usługi aplikacyjnej i implementujemy ją, wszelkie szczegóły odkładamy na ostatni moment. Wymaga to jednak zmiany podejścia. Trzy lata temu pisałem na tym blogu:

Rynek zmie­nia się szyb­ko, więc nie ma sen­su szcze­gó­ło­we pro­jek­to­wa­nie cze­go­kol­wiek z uwa­gi na czas jaki zaj­mie takie pro­jek­to­wa­nie i ryzy­ko, że taki pro­jekt sta­nie się szyb­ko nie­ak­tu­al­ny. Nikt roz­sąd­ny nie nama­wia dzi­siaj do cze­goś o wdzięcz­nej nazwie ??water­fall?.  Co więc zro­bić? Dla dużych pro­jek­tów two­rzy­my archi­tek­tu­rę, opi­su­je­my mecha­ni­zmy dzia­ła­nia, poli­ty­kę roz­bu­do­wy i opis cyklu życia.  Czyli to co pozwo­li roz­wi­jać roz­wią­za­nie meto­dą ite­ra­cyj­no-przy­ro­sto­wą, w razie potrze­by pozwo­li na prze­pro­jek­to­wa­nie, ale jako całość nadal będzie spój­ne, nie będzie wyma­ga­ło wymia­ny cało­ści gdy zmie­nią się warun­ki na ryn­ku.Można w tym miej­scu zary­zy­ko­wać tezę, że nie ma cze­goś takie­go jak ??inży­nie­ria wyma­gań? bo czym ona jest i co jest jej pro­duk­tem? Uporządkowany spis życzeń? Mamy nato­miast na pew­no ??inży­nie­rię sys­te­mów?.? sys­te­ma­mi są orga­ni­za­cje a tak­że narzę­dzia jakich uży­wa­ją np. opro­gra­mo­wa­nie? (Wymagania umarły. Rozwiązaniem jest cykl życia produktu | | Jarosław Żeliński IT-Consulting)

Z czego należy więc od razu zrezygnować? Z opracowania relacyjnego modelu (bazy) danych dla całej aplikacji, i przestawić sie na idee mikro-serwisów, czyli uznania, że aplikacja nie jest monolitem a zestawem komponentów realizujących usługi aplikacyjne. Usługi aplikacyjne modelujemy jako Przypadki Użycia (notacja UML) i to stanowi kontakt z dostawcą. Jednak “czarna skrzynka” (opis nie zawierający mechanizmu działania) jest bardzo ryzykowny, dlatego skuteczne metody dokumentowania wymagań, to metody zorientowanie na modele (MDA) opisujące logikę działania systemu (model jako wymaganie), a zamiast tworzenia korporacyjnego relacyjnego modelu danych, zamykamy się w dokumentach jako elementarnych nośnikach danych (i nie boimy sie redundancji danych w całym systemie). Ogromne i szczegółowe dokumenty i modele są wyłącznie stratą czasu i pieniędzy:

Dlatego od lat fascynuje mnie niekonsekwencja wielu developerów: najpierw wieszają psy na metodach nazywanych “waterfall”, a już chwilę potem zaczynają projektowanie jednego relacyjnego modelu danych dla całego projektu!

Zwinny Analityk Biznesowy utrzymuje pętlę iteracji przyrostu zakresu projektu: mając opracowaną architekturę całości i paradygmat (politykę) projektowania (np. obiektowy), dostarcza cyklicznie i zawsze na ostatni moment, kolejne szczegóły, bo wtedy ma największą wiedzę, i ryzyko zmiany zakresu jest najmniejsze. To się nazywa ‘nadzór autorski’.

Tak więc kluczem do sukcesu, w dzisiejszych warunkach, jest model oparty na komponentowej architekturze i iteracyjnym dostarczaniu kolejnych usług aplikacyjnych .

Jak? Analiza, projektowanie i implementacja:

• Analiza biznesowa (procesy biznesowe) i systemu informacji w organizacji, i decyzja o ewentualnej standaryzacji dokumentów i procesów. (notacje BMM, SBVR, BPMN, UML)
• Opracowanie modelu informacyjnego czyli szablonów dokumentów, ich wzajemnych powiązań i słownika pojęć. (notacja UML, SBVR)
• Opracowaniu architektury całości i opisanie cyklu życia projektu (notacja UML).
• Przejścia do fazy implementacji z nadzorem autorskim autora projektu (zarządzanie zmianą, stała aktualizacja dokumentacji systemu).

Pierwsze przy punkty, ich realizacja, nie powinny nigdy trwać dużej niż kwartał, a dokumentacja pierwotna raczej nie powinna przekroczyć nigdy 100 stron, bez względy na wielkość projektu! Im większy projekt tym bardziej dokumentacja początkowa powinna być abstrakcyjnym modelem. Innymi słowy: im większy i dłużej trwający projekt, tym bardziej jego opis powinien być strategią jego realizacji, a nie taktyką.

Czy zwinny analityk biznesowy jest mitem czy rzeczywistością? Istnieje jasna odpowiedź: to rzeczywistość, jeśli organizacja zdaje sobie sprawę z wartości takiej pracy, ale jest mitem dla niedojrzałych organizacji, których procesy są źle zdefiniowane.

Źródła