Należymy do Grupy Orange Polska

Agile
12 min czytania

Jak przeprowadzić perfekcyjny Refinement? Agile Scrum w praktyce.

Autor artykułu:

Jak przeprowadzić perfekcyjny Refinement? Agile Scrum w praktyce.

Zwinne zarządzanie projektami jest dziś obecne w niemal wszystkich firmach IT. W 2001 r. powstał przełomowy Manifest Agile (agilemanifesto.org). W ciągu ostatnich 20 lat nastawienie firm do zarządzania projektami się zmieniło. Czy była to zmiana na lepsze?

Według Project Management Institute, ponad 70% firm wdrożyło podejście zwinne, a projekty prowadzone w ten sposób są o 28% bardziej skuteczne od tradycyjnych. Prawdopodobnie znasz wszechobecne zasady Agile, które są pielęgnowane i zdefiniowane przez ramy postępowania zwinnego Scrum. Ta zmiana wymaga innego podejścia podczas realizacji projektów. W tym artykule chciałbym się skupić na refinemencie, które zgodnie ze scrumem, jest procesem ciągłym w trakcie trwania sprintu, w którym backlog produktu jest tworzony, dopracowywany i uszczegóławiany. Bazując na moim doświadczeniu zawodowym jako były programista integracji, a także analityk biznesowy i systemowy, a obecnie jako architekt rozwiązań, chciałbym się podzielić wiedzą, która ma proste zastosowanie oraz opisem kilku interesujących spostrzeżeń. Co zatem w praktyce oznacza refinement? Jak rekomendacje zgodne z przewodnikiem po scrumie odpowiadają rzeczywistości? Która strona lepiej odzwierciedla rzeczywistość – purysta czy praktyk? Jeśli chcesz poznać odpowiedzi na te pytania i zaszczepić nawyk przeprowadzania efektywnego refinementu, upewnij się, że siedzisz wygodnie i przejdź do następnego akapitu :).

Zobaczmy, jak to wygląda z punktu widzenia sprintu.

Na samym początku jako architekt muszę upewnić się, że wszystkie zaplanowane wymagania są prawidłowo zdefiniowane oraz analiza danego sprintu została zakończona. Zakładając dwutygodniowy sprint, powinno to zająć nie dłużej niż 2-3 dni. W międzyczasie, strona biznesowa ma chwilę, aby wewnętrznie spotkać się i przeprowadzić np. burzę mózgów, która dotyczy wymagań do realizacji podczas nadchodzących sprintów – w moim przypadku definiowane są wymagania w formie historyjek użytkownika (ang. User Stories) oraz ich kryteria akceptacji. Następnie, organizuję spotkanie poprzedzające planowanie, na którym zespół biznesowy wie, co znajdzie się w zakresie kolejnego sprintu lub dwóch i pracuję z właścicielem produktu nad ustalaniem priorytetów i kolejności zadań. Zazwyczaj to spotkanie daje mi ogólne poczucie tego, co powinno zostać zrobione, aby dostarczyć oczekiwaną wartość biznesową.

Następnie mogę skupić się na dekompozycji wymagań, czyli na rozbijaniu ich na mniejsze kawałki. Czasami jest to możliwe 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 część zdefiniowanych wymagań jest gotowa, organizuję pierwszą sesję estymacji z zespołem, który będzie odpowiedzialny za implementację (pamiętajcie – zgodnie z nowym przewodnikiem po scrumie, jest to tzw. Developers Team). Ta sesja trwa maksymalnie 60 minut. Informacje zebrane podczas refinementu umożliwiają względne szacowanie zadań. Dzięki temu spotkaniu jestem w stanie nie tylko zebrać wyniki estymacji (w moim przypadku używam tzw. Story Points), ale także uzyskuję pierwszą informację zwrotną od zespołu – spisuję pytania, na które strona biznesowa musi odpowiedzieć. W połowie sprintu, architekt powinien udoskonalić wymagania, które zostały omówione na spotkaniu przed planowaniem wstępnym. Najlepiej, aby po dwóch dniach od pierwszego spotkania estymacyjnego odbyło się kolejne spotkanie. To wystarczająco dużo czasu na przygotowanie kolejnej porcji wymagań biznesowych.

Teraz jesteśmy w 7-8 dniu sprintu. Dwutygodniowy sprint ma 10 dni roboczych (w tym jeden dzień na ceremonie scrumowe). Pod koniec sprintu upewniam się, że cały zakres jest dostarczony i odpowiednio przetestowany. Aby to się udało, jestem w ciągłej komunikacji z zespołem i weryfikuję bieżące cele oraz blokady i utrudnienia, które staram się uzyskać od zespołu podczas porannej synchronizacji z członkami. Następnie, w ostatnim dniu sprintu pomagam właścicielowi produktu w wyborze zakresu i akceptowaniu planu na kolejny sprint po to, aby sprawniej przeprowadzić planowanie. Bez problemu można dostrzec, 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 i niekoniecznie spełniają kryteria jakościowe, ale pamiętaj, że w końcu to cały zespół, który dostarcza je podczas sprintu decyduje podczas planowania, czy zgadza się na dany zakres. Kluczowe jest, aby potrafić to wyważyć, ponieważ strona biznesowa polega na mojej ekspertyzie podczas podejmowania decyzji.

Powyższy harmonogram jest świetnym punktem wyjścia dla każdego zespołu. Na początku zaczynam od przestrzegania zasad opisanych w artykule, a następnie dostosowuję plan do aktualnie panujących warunków i otoczenia. Nigdy nie zapominam o utworzeniu z góry spotkań w kalendarzu, które odbywają się cyklicznie, dzięki czemu ja i mój zespół pracujemy wg tego samego rytmu. Pomaga mi to również w organizacji zadań podczas planowania tygodnia, ponieważ kalendarz właściciela produktu jest pełen terminów i ciężko znaleźć czas na nieplanowane spotkania.

Skoro tematy związane ze sprintem zostały omówione, chciałbym zgłębić i omówić wyżej wspomniany refinement jako osoba techniczna, która współpracuje z programistami. Następnie przejdziemy dalej i wejdziemy w buty osoby biznesowej.

Zacznijmy od zespołu – czuję się spokojnie wiedząc, że zespół jest nie tylko pełny samodzielnych specjalistów, ale składa się również z testera. Tak banalne, a jakże prawdziwe. Jeden specjalista od zapewniania jakości produktu powinien być w stanie przetestować pracę maksymalnie 6-7 programistów podczas danego sprintu. W moim przypadku, biorąc pod uwagę zespół składający się z 6 programistów i 1 testera, gdy inżynier QA opuścił zespół, ogólna wydajność sprintu spadła o 20%, ponieważ inni byli zmuszeni przejąć jego obowiązki. Zespół programistów i właściciel produktu przejęli obowiązki związane z testowaniem aplikacji, zwykle nie poświęcając temu zadaniu wystarczająco dużo czasu, a jakość dostarczanej aplikacji drastycznie spadła. Chcę tutaj wyraźnie zaznaczyć, że pracując w zespole, w którym „zredukowano koszty” oraz, gdy klient tylko zaczyna myśleć o usunięciu jakiegoś członka zespołu, wkładam mnóstwo wysiłku w przekonanie go, aby tego nie robił, ponieważ na dłuższą metę to się zdecydowanie nie opłaci. Uczucie nieustannej presji wpływa negatywnie na zachowanie całego zespołu podczas codziennej współpracy (w tym na jakość refinementu). Programiści powinni wykonywać swoją pracę, testerzy swoją, a ja swoją. Synergia dwóch ról – na przykład analityka biznesowego oraz scrum mastera, ponieważ zespół potrzebuje eksperta od metodyki, również nie wchodzi w grę. Niestety, miałem nieprzyjemność doświadczyć skutków takiej zmiany i morale zespołu gwałtownie spadły – wkrótce potem zespół nie czuł się już tak zaangażowany i programiści, zamiast być zaangażowanymi konsultantami, przekładali dokumentację nad kod aplikacji, czyli byli po prostu wyrobnikami.

Co byś powiedział, gdyby ktoś zaproponował Ci małe wsparcie podczas refinementu? Świetny pomysł! Czy znasz „tres amigos”? Dobrze znana praktyka „tres amigos” jest wszechstronnym i wzajemnie uzupełniającym się podejściem do analizy. Przygląda się ona wymaganiom z trzech różnych perspektyw – biznesowej, technicznej i jakościowej. Ta technika pogłębia wspólne zrozumienie inkrementu, który zostanie dostarczony. W skrócie, możemy dzięki niej budować produkt o lepszej jakości. Ważne jest by wspomnieć, że nie musimy się ograniczać tylko do trzech osób. Ja zapraszam też jednego front-end developera, jeśli wiem, że przedmiotem dyskusji będzie również interfejs użytkownika. Umieszczam również na mojej liście zaproszeń jednego programistę back-endu wtedy, gdy będziemy rozmawiać o logice biznesowej. Dlaczego? Ponieważ:

Można też zaprosić dowolną inną osobę, która może przyspieszyć proces refinementu – Scrum jest tak skonstruowany, że wszystkie pomysły można wspólnie przedyskutować na retrospekcji i wdrożyć udoskonalenie w kolejnym sprincie po to, by sprawdzić, czy inne podejście daje lepsze rezultaty. Jednak każdą perspektywę staram się przedyskutować z jak najmniej liczną grupą. Moim zadaniem jest pisanie oraz utrzymywanie analiz i diagramów architektonicznych zgodnie z bieżącymi zmianami. Praktycznie nie da się prowadzić spotkania i w międzyczasie tworzyć dokumentację. Odnotowuję więc wszystkie punkty, które będą musiały zostać wykonane. Oczywiście, nie będę ich wykonywał sam. Wszystkie zadania „do zrobienia” adresuję do zespołu i uzgadniam zakres odpowiedzialności – zgodnie z przypisanymi rolami. Na przykład: strona biznesowa aktualizuje kryteria akceptacji i opis wymagań w JIRA, a ja aktualizuję analizę, diagramy, graficzne interfejsy użytkownika i wszystkie inne rzeczy, które trzymamy w Confluence.

Aby ułatwić nawigację, zadania w JIRA powinny być powiązane z dokumentacją (u mnie ze stronami w Confluence) – wspomaga to szybki dostęp do technicznych wymagań, biznesowych analiz oraz makiet interfejsów użytkownika. Strukturę stron na Confluence utrzymuję w taki sposób, aby nawigacja była intuicyjna i można było efektywnie poruszać się po treści. Jeśli chodzi o JIRA, statusy takie jak „IN REFINEMENT”, „REFINED”, „IN BACKLOG” mogą sprawić, że projekt będzie lepiej zarządzany i bardziej transparentny. Członkowie zespołu dzięki temu mogą w bardziej przejrzysty sposób aktualizować status i zarządzać bieżącymi zadaniami, a interesariusze– mają dostęp do wykresów i statystyk, które lepiej odzwierciedlają rzeczywistość.

Wyznaję zasadę, że diagramy opisują więcej niż słowa. Nie muszą one być wykonane w notacji UML, ale powinny być zrozumiałe dla wszystkich członków zespołu. Rysuję diagramy sekwencji, aby pokazać przepływ komunikatów i odpowiedzialności komponentów. Dla programistów jest to najbardziej interesujący artefakt, gdy rozmowa dotyczy nowych punktów integracji. Odpowiednia 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 maszyny stanowej/czynności, aby lepiej wyrazić wymagania biznesowe i rozpoznać przypadki brzegowe. Ponadto, na końcu każdego sprintu aktualizuję diagramy komponentów architektonicznych, ponieważ nie jestem jedyną osobą, która z nich korzysta. Najważniejsze, to żeby nie bać się rysowania – jest to zarówno analiza wymagań, jak i dokumentacja systemu na przyszłość. Zespół biznesowy szybko zacznie rozumieć wszystkie schematy, a ogólna efektywność wzrośnie – nie wspominając 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 efektywnie, również nie jest najistotniejszym czynnikiem. Architekci powinni projektować najlepszą (dla danego przypadku) możliwą architekturę systemów po to, aby obniżyć koszty utrzymania i uczynić system łatwym do zmiany. Wszystkie elementy wchodzące w skład danej architektury powinny być na tyle elastyczne, aby można je było bezproblemowo dostosować do wymagającego tempa zmian na świecie. Im szybciej się dostosujemy, tym zyskamy większą przewagę konkurencyjną. Z drugiej strony, im więcej linii kodu posiada dany system, tym trudniej jest zmienić jego zachowanie. Dlatego zasady rozwoju oprogramowania powinny być ustalone na samym początku projektu, ponieważ wtedy praktycznie nie da się zauważyć niewydajnej architektury. Warto zaznaczyć, że wcześniej czy później, każda „droga na skróty” i obejścia sprawią kłopoty. Często zdarza się, że klient naciska, aby dostarczać więcej i szybciej. W takich sytuacjach wyjaśniam wszystkie konsekwencje projektowe, jakie ta decyzja pociąga za sobą i upewniam się, że strona biznesowa je rozumie. Nie jest to łatwe i czasami zmieniają zdanie przy każdym sprincie. Dlatego też architektura systemów powinna być jak najbardziej elastyczna, gdyż zmiany są nieodłączną cechą procesu rozwoju oprogramowania. Niemniej jednak, nie projektuj systemów tak, aby każdy element był konfigurowalny – powinno to być przedmiotem dyskusji, a znajomość całego 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 oferuję pomoc w jego przygotowaniu. Wspieram się nim przy podejmowaniu lepszych decyzji architektonicznych, które w przyszłości będą efektywnie współpracować z innymi komponentami systemu. Co więcej, gdy zespół programistów zrozumie kontekst, to z pewnością zwiększy się 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 przedstawiam 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ół jest zbudowany z ekspertów. Nie jest możliwe, aby jedna osoba znała na pamięć każdy element systemu. Argumenty zespołu są również zasadniczo słuszne. Dzielenie się wiedzą powinno stać się codzienną praktyką. Dobry lider rozwija zespół i czyni go samowystarczalnym. To niezwykle satysfakcjonujące, gdy wszystko działa jak w szwajcarskim zegarku. Sprawia to też przyjemność pracy mojej i zespołu :).

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

Właściciel produktu to osoba, która wyznacza cele i akceptuje przyrosty przedstawione na ceremonii scrumowej zwanej przeglądem sprintu. W większych projektach zespół biznesowy, poza właścicielem produktu, składa się z analityków biznesowych, menadżerów operacyjnych i innych osób. Oni wszyscy muszą odnaleźć ten sam rytm pracy, aby móc efektywnie współpracować – i ja również. Najlepszym pomysłem na to jest…poznanie ich osobiście! Jestem przygotowany do regularnych podróży służbowych. Nawet podczas sprintu jestem gotowy na spędzenie 2-3 dni u klienta w celu przedyskutowania najważniejszych tematów. Jeśli niestety nie jest to możliwe (np. z powodu pandemii…), to poproś o włączanie kamer na każdym spotkaniu. Nawiązanie relacji biznesowych niesamowicie pomaga podczas negocjacji. Mój punkt widzenia jest absolutnie wpływowy dla biznesu. Z kolei druga strona polega na moim profesjonalizmie i doświadczeniu. Decyzje są trafniejsze, jeśli szczerze rozumiem ich potrzeby i zależy mi na nich. Zapamiętaj to bardzo ważne zdanie: najpierw staraj się zrozumieć, potem być zrozumianym. Moim obowiązkiem jest uświadamianie stronie biznesowej, jakie są konsekwencje ich wyborów. Nigdy nie pozwalam, aby emocje przejęły nade mną kontrolę – wręcz przeciwnie, działam jak profesjonalista. Dodatkowo, wyjaśniam wpływ biznesowy każdej decyzji na poziomie aplikacji – tylko wtedy będą wiedzieć, jak dokonywać właściwych wyborów. Jestem w pełni transparentny w kwestii moich wszelkich obaw i zidentyfikowanych przez zespół blokerów. Szczerość prędko zostanie doceniona – inni będą wiedzieć, że mogą na mnie liczyć. Kto wie, może dzięki temu uniknę niespodziewanych wpadek?

Równie ważne jest rozwijanie empatii i stawianie się w sytuacji użytkownika. To pomaga mi dostarczyć możliwie najlepszy front end. Zazwyczaj, interesariusze oceniają aplikację na podstawie graficznych interfejsów. Jeśli mam wystarczająco dużo czasu, przygotowuję więcej niż tylko jedną makietę. Oczywiście, zespół biznesowy wybiera tylko jedną, ale działam jako aktywny i troskliwy członek zespołu. Łatwiej jest rozmawiać o funkcjonalnościach, gdy wszyscy widzą szkic projektu. Być może wpadniemy na jeszcze lepszy pomysł, niż początkowo zakładaliśmy. Wizualizacja bez wątpienia odgrywa istotną rolę, szczególnie podczas pracy zdalnej.

Kolejnym aspektem efektywnej pracy jest odpowiednie przygotowanie historyjek użytkownika przed refinementem. Strona biznesowa musi uprzednio przeprowadzić wewnętrzne spotkanie dotyczące wymagań. Nie twierdzę, że burza mózgów nie jest odpowiednia – jest jak najbardziej, ale zrób to na osobnym spotkaniu. Ja, jako koordynator spotkania kieruję się zasadami, które ułatwiają przeprowadzenie refinementu. Udzielam również wskazówek innym, jeśli spotkanie dryfuje w niewłaściwym kierunku. Dlatego dobrze jest wykorzystywać wiedzę i techniki scrum mastera do promowania dobrych praktyk. Tworząc spotkania, przypominam sobie o zasadzie GOAL i wpisuję w opisie: (Cel, ang. Goal) Cel spotkania – czyli co chcę osiągnąć, (Zadanie, ang. Objective) Zadanie – jak chcę to osiągnąć i Agenda – przydatna dla uczestników spotkania, aby mogli się zapoznać ze szczegółami i zaplanowanym czasem trwania spotkania. Używam spike’a, jeśli potrzebne jest rozpoznanie tematu, a także korzystam ze stopera i limitu czasu, gdy czuję, że dyskusja się przeciąga i jest zbyt długa. Historię użytkownika powinny być przygotowane, co oznacza, że kryteria akceptacji należy spisać i opis powinien być uzupełniony. Takie podejście daje mi kolejną możliwość – przesłania tematów i pytań związanych z wymaganiami już przed spotkaniem. Te pytania jasno pokazują, gdzie znajdują się luki w analizie oraz stymulują dalszą dyskusję. Jeśli spotkanie dobiega końca, a pytania są wciąż otwarte, zawsze je wysyłam i naciskam na uzyskanie odpowiedzi w kolejnych dniach pracy.

Jestem pewien, że nawet jedno pytanie pozostawione bez odpowiedzi lub luka w analizie odbije się w trakcie rozwoju oprogramowania 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 – backlog produktu tworzony jest zazwyczaj na samym początku projektu. Oczywiście, wymagania w backlogu 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 jedna z najgorszych sytuacji, jaka może się przytrafić, ponieważ ogromnie komplikuje pracę programistów. Wpływa to na morale całego zespołu – nikt nie chce dwukrotnie robić tego samego. Jeśli dzieje się tak dlatego, że dane wymaganie nie zostało wystarczająco przeanalizowane, wyciągam wnioski i na kolejnych spotkaniach bardziej zagłębiam się w historyjki. W tym przypadku z pomocą przychodzi podział jednej historyjki na kilka mniejszych. Jeśli jednak dzieje się tak dlatego, że zespół biznesowy nagle zmienia swoje decyzje – szacuję, ile pracy wymaga dostarczenie czegoś zgodnie z nowymi ustaleniami. Drobne poprawki zespół jest w stanie zaimplementować w trakcie trwania sprintu – wykazując oznaki pracy zespołowej. Wtedy strona biznesowa czuje, że robię wszystko, aby zaspokoić jej potrzeby. Z drugiej strony powinna czuć, że nie może prosić o zmiany, kiedy tylko zechce. Jeśli część oprogramowania została już zaimplementowana lub zostanę poproszony o dostarczenie zmiany w miejsce zaplanowanych historyjek, wtedy proszę o stworzenie kolejnej pozycji w backlogu i zaplanowanie jej w kolejnym sprincie.

Aby uniknąć takich sytuacji, historie użytkownika powinny być podzielone na mniejsze kawałki. Mniej zakresu oznacza również większą łatwość podczas testów danego wymagania. Na przykład: pokazuję biznesowi pierwszą wersję interfejsu użytkownika, aby mogli zweryfikować, czy to, co widzieli na makiecie, jest tym, co faktycznie zostało zbudowane. Algorytmy mogą być testowane już w trakcie ich implementacji – wystarczy poprosić zespół biznesowy o dostarczenie danych testowych i oczekiwane wyniki – zespół może w szybki sposób uruchomić algorytm na podstawie podanych danych wejściowych i zapisać wyniki np. do pliku. Drastycznie oszczędza to czas i nie muszę ręcznie testować wszystkich scenariuszy. W przypadku napiętego harmonogramu proponuję zmianę zakresu wymagań. Dobrze jest znać idealne rozwiązanie, do którego się dąży, ale w tej sytuacji weryfikuję, które wymagania są najbardziej kluczowe, a które mogą być podzielone i dostarczone w kolejnym sprincie. Zapisuję wszystkie uzgodnienia np. notatki podczas spotkań, procedury zgłaszania błędów, itp. – uwierz mi, to też oszczędza wspólny czas. Co więcej, analiza jest częścią przyszłej dokumentacji. Dobrze napisana, nie wymaga żadnych aktualizacji po sprincie. Piszę to tak, jakby to była ostateczna forma dokumentacji po to, żeby później nie tracić czasu na poprawki.

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 estymacje i bezproblemowe planowania. Mniej czasu poświęca się na wyjaśnienia – dzięki temu praca przebiega bez zakłóceń.

To oczywiste, że muszę przygotować co najmniej jeden sprint do przodu – ponieważ to ja prowadzę spotkania planistyczne. Właściciel produktu ma za zadanie jedynie określić ostateczny zakres – ja wraz z zespołem szczegółowo planujemy prace. Staram się mieć przeanalizowane dwa sprinty do przodu. Dlaczego? To buduje przewidywalność zespołu. Jest ona niezwykle ważna, ponieważ jest potrzeba planowania funkcjonalności na cały rok – podnosi to więc moją jakość w oczach interesariuszy. Wpływa to również na stabilność i ogólny stan zdrowia zespołu.

Podczas planowania, nalegam również na pozostawienie 15% bufora pojemności sprintu na potrzeby refinementu. Mówi się, że powinno to zajmować mniej więcej 10% czasu sprintu, ale skomplikowane projekty potrzebują nieco więcej. Mówiąc skomplikowane mam na myśli, gdy tworzymy nowy produkt, nowy proces lub wymagania nie są dobrze znane i podzielone. Musimy mieć wystarczająco dużo czasu, aby przedyskutować projekt techniczny i wyjaśnić wszystkie niejasności. Ten czas zwiększa również kompetencje wewnątrz zespołu – ponieważ uczą się od siebie nawzajem :).

Posiadanie planu działania lub mapy wpływu/zależności jest oczywiście bardzo pomocne. Bilansuje to, w jakim stopniu wykorzystujemy czas zespołu biznesowego na każde z wymagań. Nie ma potrzeby skupiać się na funkcjonalnościach, które są zaplanowane na kilka tygodni do przodu. Istotny jest również sposób, w jaki komunikuję się ze stroną biznesową i interesariuszami – nie zawsze mają rację. Mam wystarczająco dużo odwagi i umiejętności, aby przekazać to w przyjazny sposób.

Czy jest jedna prawda, jedna poprawna odpowiedź, na pytanie jak przeprowadzać refinement? Myślę, że nie. Nie ma werdyktu – nie ma obiektywnej odpowiedzi na to pytanie. Podejście do refinementu powinno być empiryczne, oparte na doświadczeniach z zespołem i wizją interesariuszy. Spróbuj wdrożyć swoje pomysły – scrum jest stworzony do testowania i udoskonalania!

Co możemy zrobić Dla Twojego biznesu?

Skontaktuj się z nami!

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