niedziela, 12 lutego 2017

I wilk syty i owca cała [aktualizacja]

                                                                  
„W twórczości artystycznej i naukowej oryginalność dzieła sztuki czy koncepcji naukowej polega jedynie na nowości samych skojarzeń między znanymi już twórcy bodźcami.” (M.Mazur)


Jako relatywnie świeżo nawrócony scrumista (co prawda podejście adaptacyjno-iteracyjne uprawiam od mego zawodowego stanu prenatalnego, czyli od studiów, ale stosunkowo niedawno zorientowałem się , że od lat jestem agile (niczym pan Jourdain, który nie wiedział, że całe życie mówił prozą ) z zapałem neofity zgłębiam tajniki mej nowej konfesji. W swych peregrynacjach  do krynic wiedzy agilistycznej, czyli różnych portali poświęconych tej tematyce, często napotykam dość mgliste dyskursy na temat stories, epics, themes i jak się ma jedno do drugiego, z których nic jasno i jednoznacznie nie wynika. Dyskutanci i prelegenci prezentują głównie swe opinie typu IMHO („moim skromnym zdaniem ...”). O ile ze stories nie mam większych trudności, to relacje między epics i themes wciąż są dla mnie zagadką. Może to wynika z neosemantycznego użycia  terminu epika przez przedstawicieli młodszych generacji? Mnie uczono, że epika pochodzi od eposu (opowieść, pieśń), czyli gatunku literackiego. Teraz to czort wie. Może to wymarły gatunek? 
Choć wnikliwie przestudiowałem klika blogów w temacie oraz przewertowałem szereg agile-guidebook-ów przyznaję, że jestem głupszy po niż byłem przed ich lekturą. Co autor, to z lekka inny punkt widzenia oraz  literackie definicje. Dla mojego prostego inżynierskiego łba to trochę za dużo tej dowolności. Cóż, chyba wciąż jestem jeszcze zbyt newbie.

Czy ktoś wie , jak ma być, a nie jak być mogłoby?

Ostatnio trafiłem do projektu, w którym podstawowym narzędziem zarządzania procesem wytwarzania s/w jest powszechnie znany i lubiany Team Foundation Server® firmy Microsoft®, a tam dookoła same epics, features, stories, tasks i inne bugs , choć zauważyłem brak themes. Pojawiły się za to areas, które, jak się domyślam, są zamiennikiem tych ostatnich (o ile mnie pamięć nie myli, w starszych wersjach TFS-a były i themes).

Jako że żadne oficjalne interpretacje ww. terminologii do mnie nie trafiają, a z TFS – em jakoś żyć trzeba, postanowiłem zbudować na potrzeby projektu pewną herezję bazującą na moich wcześniejszych pogańskich poglądach, z czasów kiedy to wytwarzanie oprogramowanie było prostą, by nie rzec prymitywną, działalnością inżynierską, a nie twórczością magiczno-mistyczną.

Sięgnąłem do mych systemowo-usługowo-architektonicznych korzeni i skleciłem taki oto konstrukt metodyczny, który idzie ogarnąć nawet tak fizycznym rozumem jak mój.

A więc ….

… spróbujmy to zobaczyć w notacji ArchiMate® (patrz diagram)
.






Przyjmijmy, że rozwiązaniem problemu biznesowego jest zaoferowanie Produktu Biznesowego (dlaczego – to temat odrębnego postu). Produkt Biznesowy to zestaw Usług Biznesowych (dostawa dobra materialnego to też de facto usługa) dostarczających konsumentom pewnych biznesowych wartości (business value). Ostatecznie każdy biznes istnieje po to, by komuś /czemuś służyć (jak niegdyś śpiewał świeżo upieczony noblista Bob Dylan.

Tak rozumiany Produkt potraktujmy jako agile-owy theme (lub area w przypadku TFS-a).


Poszczególne Usługi Biznesowe są świadczone w drodze realizacji Procesów Biznesowych, które mają początek, środek i koniec oraz dostarczają zdefiniowany i mierzalny efekt (business outcome).

Proces Biznesowy potraktujmy jako agile-owy epic.

Przyjmujemy, że w trakcie przebiegu Procesu Biznesowego, realizując jego poszczególne kroki, intensywnie korzystamy z funkcjonalności systemów IT, udostępnianych użytkownikom w postaci Usług Aplikacyjnych.

Te Usługi Aplikacyjne , opisane zwięźle i z perspektywy Product Owner-a lub biznesowego użytkownika systemu to nic innego jak agileowe features.

Features traktujemy jak wymagania funkcjonalne wobec rozwiązania IT (systemu). 


Per analogiam, Usługi Buznesowe i Procesy Biznesowe możemy potraktować jako "wymagania funkcjonalne (behawioralne)" wobec organizacji biznesowej.

- A co z wymaganiami poza funkcjonalnymi - zapyta bystry czytelnik? 
- Nic. Są one zawarte w specyfikacjach Produktów i Usług Biznesowych oraz features - odpowie prawie tak samo bystry autor.

I tu kończy się rola analityka biznesowego i/lub product owner-a. Features backlog to jego produkt przekazywany dalej. Biznesowe Produkty, Usługi, Procesy oraz features tworzą tzw. CIM+ (Computation Independent Model plus oczekiwana przez użytkownika funkcjonalność w postaci features).
Dalej zaczyna się królestwo analityka systemowego, architekta i/lub projektanta, ktokolwiek pełnić będzie taką rolę.

Features trzeba jakoś zmapować na przyszłą architekturę systemową w konwencji PIM (Platform Independent Model) i/lub PSM (Platform Specific Model).

Implementacja features wymaga wielu stories, w tym user stories, bo nie wszystkie stories muszą być users. Każde story to kilka tasks itd. – słowem czysty, klasyczny agile (Scrum, FDD, XP lub inne)

Jakie korzyści płyną z takiego podejścia?


  • Prosty sposób komunikacji analityków zarówno z przedstawicielami domeny problemowej, czyli biznesem, oraz reprezentantami domeny rozwiązania, czyli architektami, projektantami, a nawet programistami. 
  • Elastyczność w budowie relacji pomiędzy themes, epics, features, stories przy zachowaniu jednoznaczności w interpretacji terminologii.
  • Poręczny sposób dokumentowania wyników analizy.
  • Przydatna dokumentacja na etapie testowania, wdrożenia i utrzymania. 
  • i last but not least,  jednoznaczne powiązanie działań zespołu deweloperskiego z motywacją domeny biznesowej (wartość biznesowa, rezultat biznesowy)
I jest agileowo (wilk syty) i przy okazji powstaje kawałek dokumentacji (owca cała). Lub odwrotnie.

Wasz,

M.




Diagramy zamieszczone w niniejszym tekście zostały wykonane przy użyciu notacji ArchiMate®. ArchiMate® jest znakiem zastrzeżonym The Open Group.

Brak komentarzy:

Prześlij komentarz