Rola analityka i znaczenie analizy w wielu organizacjach umacnia się a w innych zanika. Dość często tam, gdzie pojawia się zwinne podejście rola analityka jest trudna do zdefiniowania. W manifeście programowania zwinnego (http://agilemanifesto.org/iso/pl/manifesto.html) można przeczytać:
W wyniku naszej pracy, zaczęliśmy bardziej cenić:
Ludzi i interakcje od procesów i narzędzi
Działające oprogramowanie od szczegółowej dokumentacji
Współpracę z klientem od negocjacji umów
Reagowanie na zmiany od realizacji założonego planu.
Celowo podkreśliłem od szczegółowej dokumentacji. W skrajnym przypadku oznacza, to brak dokumentacji. A raczej są taski w JIRA, ale nie wszystkie zadania w JIRA są dokumentacją. Raczej nie są niż są 🙂
W tej nowej układance pojawia się analityk. Analityk kojarzy się z procesami BPMN, przypadkami użycia, tabelką z wymaganiami oraz podejściem, że raz zaplanowane ma być zakodowane. O wielostronicowej dokumentacji w Word nie wspominam :-).
Wracając do manifestu. W wielu miejscach manifest zwinnego wytwarzania oprogramowania mówi, że analityk nie jest potrzebny. Zespół deweloperski ma zrozumieć istotę problemu. Powinien być, jak najbliżej problemu, który stara się rozwiązać. Wydaje się, że to zespół deweloperski powinien dowiedzieć się, jaki jest problem i go rozwiązać poprzez dostarczenie działającego rozwiązania. Tak mówi teoria, w dość dużym uproszczeniu. W praktyce wydaje się, że jest potrzebny analityk niezależnie od tego, czy pracujemy zwinnie, czy też klasycznie, czy też (oby nie) kaskadowo. Złożoność procesów biznesowych, zależności pomiędzy przedsięwzięciami, wielorakość rozwijanych produktów sprawiają, że dojrzała analiza może być bardzo potrzebna.
Wariant 1 – brak analityka
To podejście, w którym nie ma analityka. Zespół pracuje zwinnie. Nie ma analityka, nie ma sensownej dokumentacji. Czasem są zdjęcia z tablic w komórkach zespołu lub wiki, lub Confluence. Praca jest wykonywana bez szerszego patrzenia na produkt. Iteracje dowożą pewne funkcje.
Tutaj można wpaść w pułapkę, w której zespołowi wydaje się, że wiedzą lepiej jak powinna działać aplikacja i czego oczekuje biznes. W takim podejściu czasem może zabraknąć czasu na zrozumienie istoty produktu i przedsięwzięcia.
Wariant 2 – analityk poza zespołem
Podejście klasyczne to takie, że analityk jest i działa iteracyjnie. Co określony czas dostarcza produkty analizy. To model bliski klasycznej kaskadzie, bo sprinty czy też iteracje zespołu deweloperskiego nie są bezpośrednio i ściśle związane z pracą analityka.
Analityk wytwarza produkty analizy z dosyć dużym wyprzedzeniem. Produkty analizy może się zdezaktualizować od czasu wytworzenia do czasu implementacji. Tutaj podejście jest jakby zwinne, gdyż dotyczy tylko programistów. To podejście można zauważyć w organizacjach, w których zwinność jest tylko u deweloperów. Są klasyczne projekty z budżetami, ramami czasem i PM. To taka hybryda, która w przypadku gdy Analityk bardzo aktywnie uczestniczy w planowaniu sprintu i jest dostępny dla zespołu to „jako tako” zadziała. Jeśli tylko dostarczy artefakty to mamy mało sensowne podejście.
Wariant 3 – analityk w zespole
Analityk jako część zespołu wykonuje prace analityczne zgodnie z iteracjami zespołu. Jest jego częścią. W moim przekonaniu to najlepsze rozwiązanie.
Dlaczego tak myślę?
Po pierwsze a w założeniach manifestu programowania zwinnego dodatkowo pojawia się:
Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.
(Podkreślenia są moje)
Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.
Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.
Najmniej szczęśliwy model, w moim odczuciu, to taki w którym analityk przejmuje odpowiedzialność za wymagania a deweloperzy za kodowanie.
W tym podejściu i takim układzie odpowiedzialności deweloperzy odcinają się od bardzo ważnego aspektu, jakim jest próba zrozumienia produktu, procesów lub rozwiązywanego problemu. W takim układzie mamy sytuacją niemal podobną jak w wariancie 2. Analiza powstaje osobno a kod osobno.
Analityk ma współpracować z zespołem. Ideą zwinności jest wytworzenie odpowiedniej ilości dokumentacji (jak naj mniej) a czas powinien być poświęcony na komunikację czytaj rozmowę, analizę. Chodzi o to by wszyscy wiedzieli jaki mamy problem do rozwiązania. Zbyt wiele diagramów może być nadinterpretowana przez deweloperów. Co więcej, za mało np.: tylko user stories lub przypadki użycia bez podania kontekstu, celu przedsięwzięcia, dobrze zdefiniowanych potrzeb biznesowych, określonych procesów biznesowy może spowodować, że wytworzone rozwiązanie będzie realizować historyjki a nie rozwiąże problemu biznesowego.
Wydaje się, że lepiej jest rozmawiać i budować dokumentację nie jako w trakcie tej rozmowy.
Tutaj ważna uwaga. Można oczywiście zarysować wiele tablic, zrobić zdjęcia, ale w moim odczuciu to dobre na jeden raz. Jeśli chcemy potem korzystać z dokumenacji z wyników naszych ustaleń to trzeba zastosować choć minimum formalności. Korzystać z języków i notacji znanych szerzej. Pomoże to wdrożyć się kolejnym osobom.
Prosty BPMN, wymagania, user stories, diagramy maszyny stanowej, model dziedziny. Kilka elementów adekwatnych do zakresu rozwiązywanego problemu. Nie muszą to być wysublimowane artefakty. Mają być proste jak się tylko da. Na tyle proste by pozwalały zrozumieć problem i na tyle złożone by przy kolejnej iteracji udało się je wykorzystać do rozwoju, do przygotowania kolejnej wersji produktu.
Wydaje się też, że analityk ma rację w większych firmach lub zespołach. W mniejszych, przy rozwoju jednego czy dwóch produktów bezpośredni kontakt developerów z biznesem może się okazać lepszym rozwiązaniem. Brak analityków nie oznacza, że w zespolenie może zabraknąć kompetencji analitycznych. Kompetencje analityczne nie zależnie od tego, czy analityk jest, czy też nie – muszą być.
Analityk ma ogromną pracę do wykonania zwłaszcza tam, gdzie mamy wiele zależności pomiędzy procesami biznesowymi.
Jeśli jest wiele zespołów to być może warto by w organizacji był architekt biznesowy by powstała mapa procesy tak by zespoły a zwłaszcza analitycy mieli łatwiej odnaleźć zależności pomiędzy procesami, wymaganiami a iteracjami. Co więcej, analityk musi być w stałym kontakcie z deweloperami by jego analiza była implementowalna. Analityk powinien być klejem pomiędzy oczekiwaniami biznesu a możliwościami systemu oraz zespołu. Ponadto, w moim odczuciu, analityk wnosi do zespołu po prostu swoje doświadczenie swoją historię w poprzednich projektów.
Analityk musi uczestniczyć w sprincie, a nie mówić, “czekajcie na dokumentację”.
Dojrzały analityk jest osobą, która zadaje pytania i próbuje ustalić z zespołem odpowiedzi. Analityk zadaje pytania, które mają za zadanie uchwycić istotę problemu. Analityk nie może być tylko skrybą a powinien rozwijać swój warsztat by moderować dyskusję, Może wykorzystać swoje umiejętności facylitacyjne, by wspierać zespół w pracy nad złożonym problemem. Rysowanie diagramów jest w pewnym zakresie potrzebne, ale raczej jako efekt/dokument podjętych decyzji projektowych. Analityk powinien poza klasycznym BPMN używać technik bardziej zwinnych takich jak story mapping. Ponadto rola analityka to patrzenie trochę szerzej i dalej. Tutaj analiza wpływu, kontakt z innymi analitykami lub wsparcie architekta biznesowego mają ogromne znaczenie.
Reasumując analityk w ujęciu zwinnym jest saperem: co ma rozbroić miny, co buduje mosty przez napotkane rzeki. Analityk jako członek zespołu ma pomóc tworzyć lepsze, bardziej doskonałego oprogramowanie.
Czy jest to łatwo jest zbudować taką pozycje analiytyka, który wnosi wartość? Nie. Nie jest łatwo. Jest raczej trudno. W moim przekonaniu warto ten trud jednak podjąć, gdyż cytując wspomnanych założeń manifestu programowania zwinnego “Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania”.
I takiego oprogramowania Tobie życzę 🙂
Trudno się nie zgodzić z tym co napisałeś. Sam chciałem zmierzyć się z tym problemem i popełnić jakiś wpis ale mnie ubiegłeś. Co do meritum – myślę, że ważne jest tu jedno założenie – to co piszesz o tej roli to mowa o dojrzałym analityku. Osobie, która ma warsztat, rozumie biznes i zna swoje miejsce w zespole/organizacji. Myślę, że rola klasycznego analityka odchodzi do lamusa ale też nie pozycjonowałbym go na równi z developerami (widziałem już takie sugestie, że analityk poprawia kod 🙂 ). Analityk zmierza w kierunku interdyscyplinarności, niemniej jego rola się wciąż pozostaje podobna – ma rozumieć biznes, jego troski i umieć przełożyć je na język wytycznych dla zespołu wytwórczego. I tu znowu zgoda – im bliżej jest on tego biznesu a jednocześnie stanowi część a wręcz trzon zespołu, tym efekty będą lepsze. Developerzy znający specyfikę biznesu to skarb ale z doświadczenia wiem, że często brakuje im tej szerszej perspektywy – i chyba tak bym tę rolę analityka widział; przede wszystkim nie tylko rozwiązania IT, trochę wizjoner, trochę doradca biznesu, a jednocześnie ktoś umiejący priorytetyzować zadania dla zespołu, jego dobry duch, głos rozsądku, czasem mediator, czasem ktoś kto mówi stanowcze nie, to też trzeba umieć…
Czy będzie kontynuacja np. „Architekt w podejściu zwinnym”? I to zarówno ten „Systemowy” jak i „Korporacyjny”. Jednak są firmy z na tyle rozbudowaną strukturą systemów IT (niezależne czy to dobre, czy złe rozwiązania- ale nawet w okresie przejściowym „trzeba z tego korzystać”) gdzie jednak wiedza, wsparcie, udział takiej osoby jest potrzebny. To jest też temat na dalszą dyskusję- np. w czym się nie sprawdzi „samo tylko podejście zwinne”
Tekst Architekt w podejściu zwinnym chodzi mi po głowie :-). Nie obiecuję jednak niczego 🙂
To bardzo fajny tekst niestety nie mający podstaw realnych.
Scrum i techniki zwinne zakładają 2 elementy:
1. Bardzo wysoki poziom kompetencji zarówno merytorycznych jak i interpersonalnych w zespołach (w PL jak pokazują badania jest o to bardzo trudno). Wyklucza to ok 60-80% zespołów gdzie sensownego developera na zespół 20 osobowy jest 1-3, a reszta to początkujący koderzy nie ogarniający zależności i skutków swoich decyzji.
2. Chęć tych ludzi do pracy w modelu analitycznych. Rozmowa twarzą w twarz przy zespole 10 osobowym powoduje że z biznesem rozmawiają 2 osoby, 3 coś tam słuchają, 1 nie rozumie, ale się nie odezwie, a 4 mają to totalnie w nosie bo bawi je pytanie „kiedy zastosujemy najnowszą bibliotekę XYZ” i po cholerę spędzać tyle czasu na tych głupich rozmowach. Równocześnie jak ta osoba analityczna próbuje porozmawiać na temat powodów wyboru danego rozwiązania technicznego to osoby biznesowe się nudzą (bo nie rozumieją wagi tego rozwiązania).
Oczywiście ktoś może powiedzieć że „komunikacja, komunikacja, komunikacja”. Ale to nie tak. Można do usranej śmierci opowiadać, ale gdy daną osobę dyskusja na temat kontekstu biznesowego nie interesuje to nie nie ma siły by zmusić do realnego zainteresowania.
Efekt? frustracja po wszystkich stronach i refleksja że analityk jako „klej” łączący 2 światy jest potrzebny. To analityk biznesowo-systemowy powinien podejmować działanie mające na celu realizację celu – z umiejętnością rozmowy z biznesem i IT zarazem. I w obu przypadkach posiadać umiejętność wyjaśnienia w 2 zdaniach dlaczego tak należy zrobić.
Oczywiście ze względu na modę nikt nie liczy tych tysięcy godzin spędzonych na wycenach, gdzie połowa ludzi jest zupełnie niepotrzebna i nic nie wnosi do spotkań.
Model gdzie analityk wykonuje prace analityczne przed zespołem developerskim i nie wnika jak to jest wykonywane (mogą robić w sprintach, mogą robić waterfallowo, mogą jak chcą) jest chyba optymalny. Przeniesienie „modułowości” na analizę rzeczywiście przynosi korzyść, tylko trzeba wiedzieć że aby analiza (a zatem wykon) miał sens to trzeba zrozumieć przedmiot analizy, zaproponować odpowiednią architekturę rozwiązania (nie oprogramowania), wyznaczyć roboczy model danych i wtedy można przejść do modelowania procesów. I po zamodelowaniu procesu można go przekazać (wraz z ogólnym wsadem) do programistów. Inaczej bedziemy mieli potworki „zmiana zawsze spoko, zróbmy to tak, a potem się zmieni”. Nie zmieni się bo koszt zmiany architektury po 300, 500 czy 1000MD jest zbyt wysoki. I o tej stronie „metodyk zwinnych” się nie mówi…
Pingback: Architekt w podejściu zwinnym | Michał Wolski