Choć przez konferencje, blogaski pomysłów na analityka w agile pojawiło się bez liku. Żaden mnie w pełni nie usatysfakcjonował. W takim razie dorzucę i swoje do ogólnego chaosu w tym temacie.

Sobotnie sprzątanie

Gdy byłem dzieckiem przydział sobotniego sprzątania był prosty: ja ogarniałem odkurzanie, łazienkę oraz prasowanie koszul, moja siostra odpowiadała za ścieranie kurzy, ścieranie podłogi na mokro oraz prasowanie t-shirtów i ręczników. Reszta obowiązków też była jakoś tam podzielona. Po jakimś czasie każde z nas nabyło ciekawych umiejętności takich jak wyciągnięcie serwetki spod kryształów bez ich przestawiania, czy szybkie motanie ścierki na szczotce (przypomnę, że mopy nie były na podówczas znane).

Na rysunku przedstawiam proces sprzątania, gdzie kolorami wyróżniłem czynności wykonywane przeze mnie bądź przez moją siostrę.

Nasz podział prac działał szybko i efektywnie, jednak w pewnym momencie pojawiły się niespodziewane okoliczności.

Rodzice idą!

Gdy zostawiwszy nas z przykazaniem sprzątania rodzice udawali się w miasto z jakąś misją, my oczywiście oglądaliśmy telewizję. Z tego błogostanu wyrywał nas dźwięk domofonu i od tego momentu mieliśmy na sprzątnie mieszkanie dokładnie tyle czasu ile dwojgu dorosłym osobom zajmuje wczłapanie na czwarte piętro z torbami pełnymi zakupów.

Od czasu do czasu materializowało się poważniejsze ryzyko, gdyż czasem któryś z sąsiadów zostawiał drzwi do klatki otwarte. Wtedy domofon milczał, a sygnałem do rozpoczęcia sprzątania był dźwięk klucza wkładanego do zamku.

Choć współpracowaliśmy jak szaleni, nie dawaliśmy ogarnąć mieszkania w takim krótkim czasie. Wtedy nie potrafiliśmy tego nazwać, ale przyczyną tamtej szaleńczej bieganiny (prócz odkładania na poźniej) był proces sprzątania zoptymalizowany pod wykonawcę, czyli pod nas. Podzieliśmy się obowiązkami według preferencji i tak, aby każde z nas miało poczucie sprawiedliwości. Zaniedbaliśmy jednak perspektywę klienta - rodziców.

Punkt bez odwrotu

Jest scena w filmie Matrix, gdy Cypher je kolacje z agentem Smithem.

Cypher patrzy na kęs mięsa na widelcu po czym mówi:

I know this steak doesn't exist.I know that when I put it in my mouth, the Matrix is telling my brain that it is juicy and delicious. After nine years you know what I realize? Ignorance is bliss.

I to jest właśnie ten moment w artykule, kiedy możesz przestać czytać i wrócić do konferencyjnych dyskusji o miejscu analityka w adżaljlu. To bardzo dobry moment, przestać czytać i zająć się czymś innym, dalsza lektura z pewnością popsuje ci głowę.

Proces wytwarzania oprogramowania

Popatrzmy sobie na rysunek, na którym umieściłem osoby umoczone w proces wytwarzania oprogramowania.

Ten pipeline jest w porządku. Pozwala dobrze ułożyć prace tak, aby każdy robił to co chce i lubi. Sęk w tym, że - podobnie jak wspomniane sprzątanie - jest procesem zoptymalizowanym "pod wykonawcę", skupia się na wytwarzaniu oprogramowania.

Proces dostarczania oprogramowania

Ów sławnety adżajl zmienia nieco perspektywę i każe optymalizować proces pod klienta. Z związku z tym naszym priorytetem jest nie tyle wytworzenie oprogramowania, co jego dostarczenie klientowi.

Ponieważ skupiamy się na klientach i zmieniamy proces pracy, to skutkuje to również nieco inne patrzenie na kompetencje i sposób pracy zespołu dostarczającego oprogramowanie. Żeby zredukować ilość zamieszania i ułatwić zmianę, też zdefiniujemy nowe role oraz nowe nazwy dla pracowników. Zerknij na kolejny rysunek.

Agile zmienia wytwarzanie w dostarczanie i w pierwszej kolejności optymalizuje proces z perspektywy klienta, a nie z perspektywy wykonawcy. Nie ma tu mowy mapowaniu stanowisk 1:1, np. byłeś analitykiem i "awansowałeś" na PO. Procesy zwinne raczej "wycinają" kompetencje z istniejących procesów wytwórczych organizują je w nowy sposób i nadają im nowe nazwy.

Analityk w adżajlu

Pytanie Jakie jest miejsce analityka w adżajlu? jest źle postawione. Równie dobrze można pytać Co lepiej lać do diesla 95 czy 98?. Nie konstruuje się pytań z jednej przestrzeni poznawczej (patrz: Bounded Context) i nie aplikuje się ich do innej (ponownie patrz: Bounded Context). Wiemy to mniej więcej do 2004 (patrz: niebieska książka o DDD). Takie pytania naruszają istniejącą strukturę wiedzy i nie tworzą nowej. Tworzą za to sporo zamieszania i stresu tak, jak w przypadku pytania o miejsce analityka w adżajlu.

Wytwarzanie a Dostarczanie

Jesteśmy w ważnym momencie. Wydedukowaliśmy przed chwilą, że rola czy też stanowisko analityka pochodzi z kontekstu wytwarzania oprogramowania, gdzie proces wytwórczy optymalizuje się "pod wykonawcę". Analityk jest tu sensowym rozwiązaniem na łączność biznesu i IT.

Z drugiej strony mamy kontekst dostarczania oprogramowania, gdzie optymalizujemy się "pod klienta". W jak najbardziej uprawniony sposób możemy zapytać o relację pomiędzy tymi dwoma kontekstami. Czy pojęcia z pierwszego konwertują się w drugi i jeśli tak, to w jaki sposób?

Idę tej relacji już zaznaczyłem na ostatnim obrazku. Dla porządku wrzucam jeszcze raz.

Jako że w procesach zwinnych organizujemy się przede wszystkim dla regularnego dostarczania klientowi wartościowych z jego perspektywy funkcjonalności, Product Owner przysposobił sobie sporo kompetencji biznesowych, trochę analitycznych i jakiś pakiet technik pomagających mu doprowadzać sprawy do końca.

Developera zaś - jak chcą go wiedzieć adżajlowcy - poskładano z dużej dawki umiejętności programisty, sporo testera i pokaźnej paczki umiejętności analityka tak,aby skutecznie komunikował się z innymi developerami, Product Ownerem a czasem klientami/użytkownikami jeśli akurat potrzeba.

Gdzie się dzieje analiza?

Weźmy sobie dla przykładu rysunek z pętelkami Scruma.

Gdzie Twoim zdaniem wydarza się analiza biznesowa, funkcjonalna i wszelaka?

Pierwszy ma myśl przychodzi refinement. Planning pewnie też. Korzystnie będzie odrobinę analizy pod koniec Review, gdy zbierzemy feedback. Może czasem na Dailu, gdy planujemy pracę na dziś. A gdy już ogarniemy wszystkie techniki udzielania feedbacku i na Retro znajdzie się czas, by pogadać o produkcie i jego technicznej jakości, to można będzie spotkać tam analizę. Czyli co - wszędzie? Wszędzie w różnej ilości.

Gdy goni cię zwinna transformacja

Przede wszystkim nie panikuj 😃.

Jeśli rzeczywiście zaczniecie optymalizować wasze procesy wytwórcze "pod klienta", może się okazać, że w pewnym momencie rola/stanowisko analityka zniknie. Jednak - jak widać z wcześniejszych przykładów - analiza wciąż będzie się wydarzać i będzie ogromne zapotrzebowanie na umiejętności analityczne.

Pewnego dnia ciebie, Analityku, zacznie gonić zwinna transformacja. Nie zastanawiaj się wtedy czy być w zespole, czy poza. Czy zrobić certyfikat dla PO albo stać się ProxyCośTam.

W większość przypadków nie będziesz już rozliczany za przygotowanie takiej czy innej analizy. Zamiast tego poszukaj miejsc w nowym procesach, w których najbardziej brakuje kompetencji analitycznych i tam się zacznij udzielać. Gdy zaczniesz odkrywać swoje sposoby na dokładanie się do tej hołubionej wartości biznesowej, nazwa twojej nowej roli bądź stanowiska pojawi się sama. Dokładniej w tej kolejności: najpierw odpowiedzialność, dopiero potem nazwa. Jak w porządnym OOP.

Przypadki szczególne

Na podstawie powyższego można zapytać, czy w świecie optymalizowania się "pod klienta" istnieją takie obszary, gdzie rola, która nazywamy "Analityk" pasuje jak ulał, czyli mapuje się 1:1 pomiędzy "wytwarzaniem" a "dostarczaniem" oprogramowania? Podam dwa przykłady.

Coś wdrażamy

Są firmy, które u swoich klientów wdrażają narzędzia usprawniające istniejące procesy biznesowe. Bądź wdrażają nowe, nie istniejące wcześniej procesy wraz z narzędziami. W takich wypadach trzeba precyzyjnie zdefiniować proces "AS IS", następnie "TO BE" oraz zaplanować niezbędne funkcjonalności. Kto ma to zrobić? Nie mam najmniejszych wątpliwości, że analityk. Jego rola po prostu pasuje do tego kontekstu.

Skomplikowana domena

Bywają oprogramowania, w których dzieje się znaczenie więcej niż sortowanie list. Widywałem prawników prawa handlowego czy pracy pracujących na pełen etat w zespole developerskim. Domena była tak złożona i sprint w sprint generowała nowe casusy, że bez specjalisty w tym zakresie nie sposób było się obejść.

Czy to nie była robota dla PO? Nie. PO odpowiadał przede wszystkim za maksymalizację ROI i z całą pewnością sporo o prawie wiedział. Nikt przy zdrowych zmysłach, nie prosiłby go jednak o wydanie opinii prawnej.

Wspomniani prawnicy siłą rzeczy uczyli się narzędzi i technik efektywnej współpracy z inżynierami i po jakimś czasie niczym nie różnili się od wysoce wyspecjalizowanych analityków.

Product Owner Kickstarter

W momencie, gdy zrozumiałem na czym polega problem z analitykiem i adżajlem, stało się oczywiste, że Product Ownerom najbardziej potrzebne są dwa rodzaje umiejętności:

• tym, którzy skonwertowali się z Biznesu potrzeba konkretnych narzędzi i technik współpracy z inżynierami
• tym, którzy skonwertowali się z IT np. analitykom potrzeba odnaleźć się w innym stylu pracy

Dla takich osób przygotowałem szkolenie Product Owner Kickstarter, które w wersji otwartej planuję na 26-27 lutego 2020.

TUTAJ zapisz się na to szkolenie i zapoznaj się z jego szczegółową agendą.