Należymy do Grupy Orange Polska

Głos Eksperta Agile
11 min czytania

Jak przeprowadzić perfekcyjne udoskonalenie?

Autor artykułu:

Jak przeprowadzić perfekcyjne udoskonalenie?
Zarządzanie projektami Agile jest dziś obecne w niemal wszystkich firmach IT. W 2001 r. powstał przełomowy Manifest Agile (agilemanifesto.org). W ciągu ostatnich 20 lat mentalność bardzo się zmieniła. Czy była to zmiana na lepsze?

Według Project Management Institute1 ponad 70% firm wdrożyło podejście zwinne, a projekty zwinne są o 28% bardziej skuteczne niż projekty tradycyjne. Przypuszczalnie znasz również dominujące zasady Agile, które są wspierane przez framework scrum. Ta zmiana wymaga innego podejścia podczas realizacji projektów. W tym artykule chciałbym się skupić na dopracowaniu, które zgodnie ze scrumem jest procesem ciągłym w trakcie trwania sprintu. Proces tworzenia, dopracowywania i szlifowania backlogu produktowego. Bazując na moim doświadczeniu zawodowym jako były analityk biznesowy i systemowy, a obecnie jako architekt rozwiązań, dzielę się wiedzą, która po prostu działa i wyjaśniam kilka ciekawych spostrzeżeń. Co zatem w praktyce oznacza wyrafinowanie? Jak rekomendacje scrumowe odpowiadają rzeczywistości? Która strona odzwierciedla doświadczenie – purysta czy praktyk? Jeśli chcesz poznać odpowiedzi i zaszczepić nawyk efektywnego udoskonalania, usiądź wygodnie i przejdź do następnego akapitu :).

Zacznijmy od punktu widzenia sprintu

Na samym początku, ja jako architekt muszę się upewnić, że wszystkie planowane historyjki są dobrze zdefiniowane i że analiza dla danego sprintu została zakończona. W dwutygodniowym sprincie powinno to zająć nie więcej niż 2-3 dni. W międzyczasie zespół biznesowy ma czas, aby wewnętrznie spotkać się i przeprowadzić burzę mózgów, jakie są wymagania dotyczące nadchodzących sprintów – w moim przypadku definiują one historyjki użytkownika i kryteria akceptacji. Następnie organizuję spotkanie przed planowaniem, na którym biznes wie, co będzie czekało na kolejne 1-2 sprinty i pracuję z właścicielem produktu nad ustalaniem priorytetów i zamawianiem. Zazwyczaj to spotkanie daje mi poczucie tego, co powinno być dostarczone na wysokim poziomie.

Kiedy to jest już zrobione, mogę skupić się na historyjkach użytkowników i rozbić wymagania na mniejsze kawałki. Czasami zdarza się to na tym samym spotkaniu, ale ciężko jest skupić się na dłużej niż 90 minut. To naprawdę wyczerpująca praca intelektualna, więc najlepszym pomysłem jest zorganizowanie osobnego spotkania na następny dzień.

Kiedy pierwsza paczka wymagań jest gotowa, organizuję pierwszą sesję estymacyjną z zespołem programistów (pamiętajcie – zgodnie z nowym przewodnikiem po scrum, jest to zespół programistów), która trwa maksymalnie 60 minut. Wynikiem udoskonalenia jest dane wejściowe do spotkania szacunkowego. Daje mi to nie tylko wynik estymacji (w moim przypadku benchmark reguł dla punktów fabularnych), ale także zwracam się do zespołu programistów o pierwszą informację zwrotną – pytania, o których zapominam zadać, biznes powinien wyjaśnić. W połowie sprintu architekt powinien popracować nad wymaganiami, które zostały omówione na spotkaniu przed planowaniem wstępnym. Najlepiej, aby po 2 dniach od pierwszego spotkania szacunkowego odbyło się drugie. To wystarczająco dużo czasu na przygotowanie kolejnej porcji potrzeb biznesowych.

Teraz jesteśmy w 7-8 dniu sprintu. Dwutygodniowy sprint ma 10 dni roboczych (w tym 1 dzień na ceremonię scrumową). Na koniec muszę się upewnić, że cały zakres jest dostarczony i przetestowany. Aby to osiągnąć, jestem w ciągłej komunikacji z zespołem programistów i reaguję na bieżące cele i blokady – które są moim celem, kiedy słucham codziennej ceremonii scrum. Następnie w ostatnim dniu sprintu pomagam właścicielowi produktu w wyborze zakresu i akceptuję plan na kolejny sprint, aby spotkanie planistyczne było nieco łatwiejsze. Widać wyraźnie, które wymagania są dopracowane i oszacowane, a które nie. Czasami właściciel produktu nalega, abyś zgodził się na historyjki użytkowników, które nie są dobrze przygotowane – ale pamiętaj, że w końcu to zespół programistów decyduje podczas spotkania planistycznego, czy zgadzają się na zakres sprintu. Wyrównanie tego jest kluczowe, ponieważ moja opinia jest niezwykle ważna, gdy biznes podejmuje decyzję.

Powyższy harmonogram może być dobrym punktem wyjścia dla zespołu. Zawsze zaczynam od przestrzegania tych zasad, a potem dostosowuję plan do otoczenia. Nigdy nie zapominam o ustaleniu z góry spotkań, które odbywają się regularnie, dzięki czemu ja i mój zespół podążamy w tym samym rytmie. Kalendarz właściciela produktu jest zwykle pełen terminów, więc pomaga również zaplanować tydzień.

Teraz, gdy poruszane są tematy związane ze sprintem, chciałbym się zagłębić i omówić wyżej wspomniane udoskonalenie jako osoba techniczna, która zajmuje się programistami. Następnie przejdziemy dalej i założymy okulary osoby, która radzi sobie z ludźmi biznesu.

Na początek z zespołem czuję się swobodnie, wiedząc, że zespół jest nie tylko pełen samodzielnie zarządzających się specjalistów, ale składa się również z testera. Tak proste, tak prawdziwe. Jeden specjalista od zapewniania jakości powinien być w stanie przetestować pracę maksymalnie 6-7 programistów. W moim przypadku, biorąc pod uwagę zespół 6 programistów i 1 testera, gdy inżynier QA został usunięty z zespołu, ogólna wydajność sprintu spadła o 20%, ponieważ inni musieli przejąć jego obowiązki. Programiści i właściciel produktu występowali jako testerzy, zwykle nie mając na to wystarczająco dużo czasu, a jakość aplikacji natychmiast spadała. Chcę tylko zaznaczyć, że będąc w zespole redukującym koszty i gdy klient zaczyna myśleć, że zmniejszenie zespołu może być dobrą decyzją, wkładam dużo wysiłku, aby go przekonać, aby tego nie robił, ponieważ to zdecydowanie się nie opłaci. Uczucie nieustannej presji wpływa również na zachowanie zespołu podczas codziennej współpracy i doskonalenia. Programiści powinni wykonywać swoją pracę, testerzy swoją, a ja swoją. Przełączenie analityka biznesowego na rolę scrum mastera, ponieważ zespół potrzebuje scrum mastera, również nie wchodzi w grę. Niestety, zauważyłem, że tak się stało i morale gwałtownie spadło – wkrótce potem zespół nie czuł się już tak zaangażowany i stał się pracownikami zamiast zaangażowanymi konsultantami.

Co powiesz na małą kopię zapasową podczas udoskonaleń? Świetny pomysł! Czy znasz „tres amigos”? Dobrze znana praktyka „tres amigos” jest uzupełniającym podejściem do analizy. Przygląda się wymaganiom z trzech różnych perspektyw – biznesowej, testowej i dostarczania. Zwiększa to wspólne zrozumienie przyszłego przyrostu, który zostanie dostarczony. Po prostu, możemy zbudować produkt lepszej jakości. Ale nie musi się to ograniczać tylko do trzech osób. Zapraszam też jednego frontend developera, jeśli wiem, że w ramach dyskusji jest przynajmniej jedna historia związana z interfejsem użytkownika. Umieściłem również na mojej liście zaproszeń jednego programistę backend, jeśli wiem, że będziemy rozmawiać o logice biznesowej. Dlaczego? Ponieważ:

 

Można też zaprosić dowolną inną osobę, która może przyspieszyć proces dopracowywania – scrum jest tak skonstruowany, że wszystko można przedyskutować na retrospektywie i wdrożyć w kolejnym sprincie, żeby sprawdzić, czy inne podejście daje lepsze rezultaty. Zawsze jednak pamiętam o tym, by w jak najmniejszej grupie uwzględnić każdą niezbędną perspektywę. Moim obowiązkiem jest aktualizowanie analiz i architektury. Trudno aktualizować analizę „w locie”. Odnotowuję wszystkie punkty, które będą musiały zostać wykonane. Oczywiście, nie jestem sam. Wszystkie punkty „do zrobienia” adresuję do zespołu i uzgadniam zakres odpowiedzialności – co jest podobne do punktu o jasnym przydziale ról. Na przykład: aktualizują (biznes) kryteria akceptacji i opis wymagań w JIRA, a ja aktualizuję analizy, diagramy, interfejsy użytkownika i wszystkie inne rzeczy, które trzymamy w zbieżności.

Zadania w JIRA powinny być powiązane ze zbieżnymi stronami, aby ułatwić nawigację – łatwy dostęp do technicznych, biznesowych analiz czy makiet interfejsów użytkownika jest niezwykle pomocny. Utrzymuję intuicyjne drzewo stron na zbiegu, aby efektywnie poruszać się po treści. Mówiąc o JIRA, statusy takie jak „IN REFINEMENT”, „REFINED”, „IN BACKLOG” mogą sprawić, że projekt będzie bardziej zarządzany i łatwiejszy do kontrolowania. Dla członków zespołu, ponieważ mogą w bardziej przejrzysty sposób wyrażać swój aktualny status i zarządzać codziennymi zadaniami oraz dla interesariuszy – ponieważ wykresy i statystyki są dokładniejsze.

Wyznaję zasadę, że rysunki wyrażają więcej niż słowa. Nie musi być w prostym UML, ale musi być łatwo zrozumiały dla wszystkich. Rysuję diagramy sekwencji, aby pokazać kolejność przepływu i odpowiedzialności komponentów. Dla programistów jest to najciekawszy artefakt, gdy mowa o nowych punktach integracji. Kolejność komunikacji i dane wejściowe/wyjściowe z każdego z komponentów pomagają mi utrzymać jakość analizy na wysokim poziomie. Co więcej, rysuję diagramy maszyn stanów/czynności, aby lepiej wyrazić wymagania. Ponadto po każdym sprincie aktualizuję diagramy komponentów architektonicznych – nie jestem jedyną osobą, która z tego korzysta. Najważniejsze, żeby nie bać się rysowania – jest to zarówno analiza wymagań, jak i dokumentacja systemu na przyszłość. Biznes szybko zacznie rozumieć wszystkie schematy, a efektywność wzrośnie – a warto wspomnieć o samej praktyce (bardzo lubię tę część mojej pracy :)).

Wspominając o architekturze, chciałbym zadać jedno pytanie – czy wiesz, dlaczego projektujemy przemyślaną architekturę systemów, która odzwierciedla wymagania biznesowe? Nie robimy tego, ponieważ architekci chcą podążać za najnowszymi wzorcami projektowymi. Architektura systemów, która działa sprawnie, również nie jest najistotniejszym czynnikiem. Architekci powinni zaprojektować najlepszą (dla danego przypadku) możliwą architekturę systemu, aby obniżyć koszty utrzymania i uczynić system łatwym do zmiany. Wszystkie elementy robocze powinny być na tyle elastyczne, aby można je było dostosować do wymagającego tempa świata. Im szybciej się dostosujemy, tym większą przewagę konkurencyjną uzyskamy. Z drugiej strony, im więcej kodu posiada system, tym trudniej jest zmienić jego zachowanie. Dlatego zasady rozwoju powinny być ustalone na samym początku projektu, ponieważ początkowo nie można zauważyć złego projektu. Warto zaznaczyć, że każdy skrót i obejście sprawia kiedyś kłopoty. Często zdarza się, że klient naciska, aby dostarczać więcej i szybciej. W takich sytuacjach wyjaśniam wszystkie konsekwencje, jakie ta decyzja pociąga za sobą dla projektu i upewniam się, że biznes je rozumie. Nie jest to łatwe i czasami zmieniają zdanie ze sprintu na sprint. Dlatego też architektura systemu powinna być jak najbardziej elastyczna, gdyż zmiany są nieodłączną cechą procesu rozwoju. Niemniej jednak nie należy konfigurować każdego elementu systemu – powinno to być przedmiotem dyskusji, a znajomość całościowego obrazu pomaga w podjęciu właściwej decyzji. Jeśli zespół nie wie, jaki jest plan na najbliższe miesiące, proszę o harmonogram działań lub pomoc w jego przygotowaniu. Jest to duże wsparcie w podejmowaniu lepszych decyzji architektonicznych, które w przyszłości będą zgodne z innymi komponentami systemu. Co więcej, zespół programistów rozumie kontekst, co z pewnością zwiększa ich zaangażowanie.

Ważny jest nie tylko kontekst, ale także zaufanie. Kiedy daję swobodę i członkowie zespołu mogą faktycznie podejmować decyzje architektoniczne, ich motywacja wzrasta. Ja również dosadnie wyrażam swoje argumenty, ale ostatnie słowo pozostawiam zespołowi – to zwykle działa i decyzje są takie same, jak gdybym to ja był decydentem. Zaufanie sprawia, że zespół jest oddany. Nigdy nie zapominam, że zespół tworzą eksperci. Nie jest możliwe, aby jedna osoba znała na pamięć każdy element systemu. Ich argumenty są również zasadniczo słuszne. Dzielenie się wiedzą powinno być codzienną praktyką. Dobry lider zespołu rozwija zespół i czyni go samowystarczalnym. To niezwykle satysfakcjonujące, gdy wszystko działa jak w szwajcarskim zegarku. Uprzyjemnia to również pracę moją i zespołów :).

Po refleksji na temat współpracy z developerami, chciałbym płynnie przejść do środowiska biznesowego.

Właściciel produktu to osoba, która wyznacza cele i akceptuje przyrosty przedstawione na przeglądzie. W większych projektach zespół biznesowy, poza właścicielem produktu, składa się z analityków biznesowych, kierowników operacyjnych i innych osób. Oni wszyscy muszą odnaleźć ten sam rytm, aby móc efektywnie współpracować – i ja również. Najlepszym pomysłem jest poznanie ich wszystkich osobiście. Jestem przygotowany do regularnych podróży służbowych. Jeśli niestety nie jest to możliwe (sic! covid), poproś o włączenie kamer. Nawiązanie relacji biznesowych pomaga podczas negocjacji. Mój punkt widzenia jest absolutnie kluczowy dla biznesu, a oni polegają na moim profesjonalizmie i doświadczeniu. Decyzje są trafniejsze, jeśli naprawdę zależy mi na innych i ich rozumiem. Zapamiętaj to bardzo ważne zdanie: najpierw staraj się zrozumieć, potem być zrozumianym. Moim obowiązkiem jest uświadomienie biznesowi, jakie są tego konsekwencje. Nigdy nie pozwalam, aby emocje wzięły górę nade mną – zamiast tego działam jak profesjonalista. Dodatkowo wyjaśniam wpływ biznesowy na poziom aplikacyjny każdej decyzji – tylko wtedy będą wiedzieć, jak właściwie dokonywać wyborów. Jestem w pełni transparentny w kwestii wszelkich obaw i zidentyfikowanych blokerów. Szczerość zostanie szybko doceniona – inni będą wiedzieli, że mogą na mnie liczyć. Kto wie, może dzięki temu uniknę nadchodzących wpadek?

Równie ważne jest rozwijanie empatii i stawianie się w sytuacji użytkownika. To pomaga mi dostarczyć najlepszy frontend, jaki jest możliwy. Zazwyczaj interesariusze oceniają aplikację na podstawie interfejsów. Jeśli mam wystarczająco dużo czasu, przygotowuję więcej niż tylko jeden szkielet interfejsu użytkownika. Oczywiście firma musi wybrać tylko jednego, ale działam jako aktywny i troskliwy gracz zespołu. Łatwiej jest rozmawiać o funkcjonalnościach, gdy wszyscy widzą projekt. Być może wpadlibyśmy na lepszy niż początkowo zakładaliśmy, pomysł. Wizualizacja bez wątpienia odgrywa istotną rolę, szczególnie podczas pracy zdalnej.

Kolejnym symptomem efektywnej pracy jest dobre przygotowanie historyjek użytkowników przed dopracowaniem. Firma musi przeprowadzić wewnętrzne spotkanie dotyczące wymagań przed ich osobistym spełnieniem. Nie twierdzę, że burza mózgów nie jest odpowiednia – jest jak najbardziej! Ale zróbmy to na osobnym spotkaniu. Ja, jako gospodarz spotkania kieruję się zasadami, które ułatwiają przeprowadzenie dopracowanie. Udzielam również wskazówek innym, jeśli spotkanie zmierza w złym kierunku. Dlatego dobrze jest wykorzystywać wiedzę i techniki scrum mastera do promowania dobrych praktyk. Tworząc spotkania przypominam sobie o zasadzie CEL i wpisuję w opisie: Cel spotkania – czyli co chcę osiągnąć, Zadanie – jak chcę to osiągnąć i Agenda – przydatna dla uczestników spotkań, aby zapoznali się ze szczegółami i planowaną długością spotkania. Używam spike’a, jeśli potrzebne są badania, a także korzystam z timebox, gdy czuję, że dyskusja jest zbyt długa. Należy przygotować historyjki użytkowników, co oznacza, że należy spisać kryteria akceptacji i przedstawić opis. Takie podejście daje mi kolejną możliwość – przesłania tematów i pytań związanych z wymaganiami przed spotkaniem. Te pytania pokazują, gdzie są luki w analizie i stymulują dyskusję. Jeśli spotkanie dobiega końca, a pytania są nadal otwarte, zawsze je wysyłam i naciskam na odpowiedzi.

Jestem pewien, że nawet jedno pytanie bez odpowiedzi lub luka w analizie odbije się w trakcie rozwoju i będę musiał w końcu na nie odpowiedzieć. Staram się zaszczepić w właścicielu produktu nawyk regularnego przeglądania kryteriów akceptacji – zazwyczaj na samym początku projektu tworzony jest backlog produktu. Oczywiście, pozycje backlogu również mogą się zmieniać, a moim zadaniem jest upewnienie się, że wszystkie z nich odzwierciedlają aktualne potrzeby biznesowe. Skoro mowa o zmianach – jak powinniśmy postępować, gdy wymagania zmieniają się w trakcie sprintu? To najgorsza rzecz, jaka może się przytrafić, ponieważ komplikuje pracę programistów. Wpływa to na morale całego zespołu – nikt nie chce robić tego samego dwa razy. Jeśli dzieje się tak dlatego, że coś nie zostało wystarczająco przeanalizowane, wyciągam wnioski i na kolejnych spotkaniach zagłębiam się w historyjki. Pomocne może być dzielenie historyjki na bardziej szczegółowe fragmenty. Jeśli jednak dzieje się tak dlatego, że firma nagle zmienia swoje decyzje – poziomuję, ile pracy wymaga dostarczenie czegoś zgodnie z nowymi ustaleniami. Można dokonać drobnych korekt i wykazywać oznaki pracy zespołowej. Biznes czuje wtedy, że robię wszystko, aby zaspokoić ich potrzeby. Wręcz przeciwnie, nie mają poczucia, że mogą prosić o zmianę, kiedy tylko zechcą. Jeśli coś już zostało zrobione lub muszę poświęcić inne historie na rzecz wprowadzenia zmiany – proszę o stworzenie kolejnej historyjki użytkownika i zaplanowanie jej w kolejnym sprincie.

Łatwiej jest uniknąć takich rzeczy, gdy historyjki są szczegółowe. Mniejsze historyjki są również łatwiejsze do przetestowania. Na przykład pokazuję biznesowi pierwszą wersję interfejsu, aby mogli zweryfikować, czy to, co widzieli na makiecie, jest tym, co zostało zbudowane. Algorytmy mogą być testowane nawet w trakcie rozwoju – wystarczy poprosić firmę o dostarczenie danych testowych i oczekiwanych wyników – zespół może łatwo uruchomić algorytm na podstawie podanych danych wejściowych. Oszczędza to czas i nie muszę testować wszystkich scenariuszy ręcznie. W przypadku napiętego harmonogramu – proponuję zmianę zakresu. Dobrze jest znać idealne rozwiązanie, które jest w głowach firm, ale w tej sytuacji weryfikuję, które wymagania są najbardziej wartościowe, a które mogą być podzielone i dostarczone później. Zapisuję wszystkie uzgodnienia np. notatki podczas spotkań, procedury zgłaszania błędów itp. – to też oszczędza czas. Co więcej, analiza jest częścią przyszłej dokumentacji. Dobrze napisany nie wymaga żadnych aktualizacji po sprincie. Piszę to tak, jakby to była ostateczna forma, żeby później nie musieć poprawiać.

Myślę, że nadszedł czas na podsumowanie i wyciągnięcie wniosków.

Zasadniczo, im lepiej przygotowane są historyjki użytkowników, tym mniej czasu poświęcam na ich dopracowanie, co przekłada się na bardziej precyzyjne szacunki i łatwiejsze spotkania planistyczne. Mniej czasu poświęca się na wyjaśnienia, a praca przebiega bez zakłóceń.

To oczywiste, że muszę się przygotować co najmniej jeden sprint do przodu – jestem gospodarzem spotkania planistycznego. Właściciel produktu ma za zadanie jedynie wybrać ostateczny zakres – ja wraz z zespołem szczegółowo planujemy prace. Staram się mieć dopracowane 2 sprinty do przodu. Dlaczego? To buduje przewidywalność zespołu. Jest to niezwykle ważne, ponieważ jest potrzebne do planowania funkcji na cały rok – podnosi to więc moją jakość w oczach interesariuszy. Wpływa to również na stabilność zespołu – ogólny stan zdrowia zespołu.

Podczas spotkania planistycznego nalegam również na pozostawienie 15% bufora pojemności sprintu na potrzeby dopracowania. Mówi się, że powinno to zajmować mniej więcej 10% czasu sprintu, ale skomplikowane projekty potrzebują więcej. Mówiąc skomplikowane mam na myśli, gdy tworzymy nowy produkt, nowy proces lub wymagania nie są dobrze znane i rozbite. Musimy mieć wystarczająco dużo czasu, aby przedyskutować projekt najniższego poziomu i wyjaśnić wszystkie niejasności. Ten czas pomaga również zespołowi w zwiększeniu biegłości umiejętności zespołu – uczą się od siebie nawzajem :).

Posiadanie planu działania lub mapy oddziaływania jest oczywiście bardzo pomocne. Bilansuję, w jakim stopniu wykorzystujemy czas służbowy na każde z wymagań. Nie ma potrzeby skupiać się na rzeczach, które są planowane na kilka tygodni do przodu. Istotny jest również sposób, w jaki komunikuję się z firmą i interesariuszami – firma nie zawsze ma rację. Powinienem mieć wystarczająco dużo odwagi i umiejętności, aby przekazać to w przyjazny sposób.

Czy jest jedna prawda, jedna poprawna odpowiedź, jak dokonać udoskonalenia? Myślę, że nie. Nie ma werdyktu – nie ma obiektywnego rozwiązania na to pytanie. Powinna być empiryczna, oparta na doświadczeniach z zespołem i krajobrazem interesariuszy. Spróbuj wdrożyć swoje pomysły – scrum jest stworzony do testowania i dostosowywania!

Co możemy zrobić Dla Twojego biznesu?

Skontaktuj się z nami!

To również może Cię zainteresować