Gdy pojawia się problem z produktem

„Houston, mamy problem” (ang. Houston we have a problem) to chyba jedno ze sformułowań, które zna każdy. Słyszał je, używał, oglądał film, gdzie ono padło czy nawet zna historię tego sformułowania (choć w rzeczywistości brzmiało trochę inaczej). A może ktoś czytał książkę o takim tytule? Ale nie, spokojnie dzisiaj nie będzie o filmie, książce czy podboju kosmosu, będzie o problemach. Słowo to pada w różnych określeniach… „mam problem”, „chyba mamy problem”, „problem do rozwiązania”, „problematyczne”, „zarządzanie problemami”, „rozwiązywanie problemów” itd.

Czasami mówi się, że lepiej powiedzieć zamiast problemu, że istnieje wyzwanie (podobno lepiej brzmi). Fakt jest taki, że zadziało się coś, czego się nie spodziewaliśmy, co powoduje nieprawidłowe działanie, niedostępność usługi/procesu/produktu, powołanie komitetu sterującego czy konieczność podejmowania szybkich decyzji. Mamy tutaj więc dwie strony „medalu” – identyfikację problemu oraz reakcję na problem.

Z nazwaniem czy identyfikacją problemu, stwierdzeniem faktu jego istnienia przez osobę, która ma z nim do czynienia, nie ma jakiejś wielkiej trudności. Wyzwanie (świadomie używam tego słowa) pojawia się z drugiej strony – w reakcji na znaleziony problem. W zależności od przyczyny problemu czy zależności od tego, co wcześniej wykonała dana osoba, z komunikowaniem problemu szerszemu gronu może być trudniej, a czasami może to powodować strach/przerażenie czy też inną reakcję, może ucieczkę.

Mając w pamięci różne sytuacje, zarówno te, w których byłem odbiorcą komunikatu, czy biernym obserwatorem czy też osobą identyfikującą problem, mogę pokusić się o identyfikację (czyt. nazwanie) kilku podejść do takiej sytuacji (podane nazwy to pierwsze skojarzenia z zachowaniem, moje bardzo subiektywne określenia):

• śpioch – nie robi nic, niech problem sam się rozwiąże, może ktoś inny go też znajdzie i podejmie kroki; nie musi się martwić i tłumaczyć, sprawdzać itd. W tej sytuacji nie czuje się odpowiedzialny za problem a także jego/jej działania nie przyczyniły się do niego;
• konspirator – również nie robi nic, a wręcz ukrywa problem. Może ktoś przy okazji znajdzie go w innej sytuacji i powie o nim. Wtedy może udać zdziwienie lub podejść do tego inaczej. Reakcja wynika często z tego, że po pierwsze nie chce podjąć działań, boi się reakcji, oceny ale z drugiej nie chce wziąć odpowiedzialności za swoje działania lub brak działań, które przyczyniły się do pojawienia problemu;
• ofiara – mówi, że jest problem. Żali się jak do niego mogło dojść, że to przeoczył/a. Niech każdy pomoże, on/a sobie nie poradzi. On/a nic nie potrafi, jak robi takie błędy. Plus jest taki, że problem wychodzi na jaw, ale równocześnie trzeba sobie poradzić z osobą zgłaszającą, która tworzy niezbyt przyjemną atmosferę;
• współpracownik – mówi, że jest problem, ale stara się do niego podejść racjonalnie. Znaleźć przyczynę, porozmawiać o skutkach, przyznać się do błędu, ale nie robić wokół siebie zamieszania jak w przypadku „ofiary„. Wtedy skupiamy się na faktach i działamy. Nie szuka winnego. Współpracujące zachowanie może się pojawić także wtedy, gdy ktoś nie ma wpływu (jak w przypadku „znalazcy” poniżej), ale chce pomóc bardziej (na przykład sprawdzić po rozwiązaniu, uczestniczyć w testach, dostarczyć szczegółowe dane dotyczące problemu lub nawet zaangażować się w zespół wraz z propozycją rozwiązań). Postawa ta może być także w przypadku powiązania z problemem;
• bohater – stwierdza, że jest problem i już znalazł jego rozwiązanie. Wskazuje wokół co trzeba zrobić, kogo poinformować, jak działać. Bierze na siebie odpowiedzialność równocześnie stając się liderem tematu od „a” do „z”, nawet przygotowując lessons learned, aby taka sytuacja nie powtórzyła się w przyszłości. Nie szuka winnego;
• sędzia – wskazuje, że jest problem, równocześnie wskazując co jest przyczyną, najlepiej ze wskazaniem osoby/procesu/tematu, który się do tego przyczynił. Jeżeli problem jest spowodowany przez kogoś innego, to bez skrupułów następuje ocena sytuacji. Jeżeli problem jest spowodowany przez działania danej osoby, wskazywana jest słabość systemu lub procesu, który nie zabezpieczył przed problemem;
• znalazca – mówi, że jest problem, ale nie ma możliwości zajęcia się nim, nie ma wpływu na system, proces, jednostkę itd. W szczególności ma to miejsce, gdy jest Klientem, użytkownikiem, odbiorcą.

Wyobraźmy sobie, że przez kilka sprintów zespół deweloperski pracował nad produktem, zgodnie z kierunkiem wskazanym przez product ownera. Wszystkie ceremonie przeszły bez problemów. Na planowaniu była pełna gotowość do realizacji zmian, na review prezentowany był pięknie działający produkt z kolejnym przyrostem. Na daily czy retrospektywnie nikt nie zgłaszał problemów czy trudności. Zadecydowano o wdrożeniu, mijają dwa dni i następuje wielkie bum… w jednym z kluczowych procesów produktu, następuje błąd. Trafia zgłoszenie do zespołu w kolejnym sprint, wszystkie prace są wstrzymane w celu jego rozwiązania. Jest problem z produktem. Wiadomo gdzie, w którym miejscu i… Ktoś zgłosił problem, więc zachował się jako „znalazca” a nie „śpioch”. W zespole (oznaczonym jako osoby na kole przerywanym na diagramie powyżej). zaczyna się szukanie przyczyny problemu i w zależności od przyczyny problemu mogą pojawić się różne z wymienionych zachowań – na przykład:

• „sędzia” może powiedzieć, że to przez brak odpowiednich testów, które powinny być wykonane przez osobę X, zespół XYZ (przykład oznaczony na diagramie powyżej na szaro jako osoba poza zespołem);
• „ofiara” może powiedzieć, że to moja część pracy, zacząć płakać na spotkaniu, że przez nią Klienci mogą nas oczernić na forach. Że ja sobie nie poradzę z tą sytuacją (przykład na czerwono oznaczony na diagramie powyżej).
• „bohater” może powiedzieć, że wie jak obejść problem. Na przykład może wskazać, że problem znika, gdy na danym ekranie, użytkownik zapisze dany stan, zrestartuje aplikację i ponownie wejdzie (przykład na zielono oznaczony na diagramie powyżej).
• „konspirator” może powiedzieć, że to nie nasz problem, u nas wszystko działało, mamy potwierdzenia z testów i kto inny powinien się zająć problemem (przykład oznaczony na fioletowo na diagramie powyżej).

Spotkałem się z różnymi reakcjami w takich sytuacjach i moim zdaniem najłatwiej jest, gdy wszyscy są albo „współpracownikami” (przykład na pomarańczowo zaznaczony na diagramie powyżej) albo „bohaterami” bo wtedy najszybciej można rozwiązać problem, nie ma szukania winnych. Jeżeli osoba, która zawiniła przyzna się do błędu i pomoże w identyfikacji miejsca, ułatwi to wszystkim pracę. Gdy ze względu na duch współpracy, zaangażuje się, też to ułatwi wszystkim zadanie.   

Powyższe określenia są moją subiektywną próbą zobrazowania zachowań, które obserwowałem w różnych sytuacjach biznesowych i prywatnych. Pewnie nie pokrywają pełni możliwości, ale moim zdaniem wskazują te, które dość często można zaobserwować. Te, które są bardzo wyraziste.

Reklama

Weryfikacja i potwierdzenie

1 czerwca 2020, to nie tylko Dzień dziecka, który z jednej strony powoduje radość u wielu dzieci, ponieważ dostały prezenty lub mają zaplanowane inne aktywności niż zwykle, a z drugiej strony „wymusza” na rodzicach/opiekunach inną organizację pracy w tym dniu. To także początek tygodnia, miesiąca oraz okresu, w którym pracownicy różnych firm biorą swoje pierwsze wakacyjne urlopy. To także dzień będący początkiem sprintu dla wielu zespołów, zarówno tych sprintów trwających miesiąc, jak i dwa tygodnie. Osoby, które planują pracę w tych zespołach, biorą pod uwagę różne elementy, wpływających na capacity zespołu (czyli tzw. dostępność zespołu lub pojemność zespołu).

Podczas planowania sprint, capacity zespołu, co wskazałem jako element wejściowy do kroku „Wybierz elementy z backlog” na diagramie w poprzednim wpisie (oraz poniżej), determinuje to ile pracy można zaplanować na najbliższy sprint. Osoba przygotowująca planowanie, czyli przeważnie product owner, podczas weryfikacji capacity zepsołu, bierze pod uwagę takie elementy jak (są to przykłady, mogące wystąpić w różnych zestawach):

• planowane nieobecności (urlopy, szkolenia, konferencje itp.),
• nieplanowane wcześniej nieobecności (choroby/zwolnienia, opieka nad dzieckiem),
• długie weekendy/dni wolne od pracy,
• wydarzenia firmowe, wymagające obecności członków zespołu,
• odejścia pracowników na koniec poprzedniego miesiąca lub zaplanowane na najbliższy sprint (czas potrzebny na przejęcie wiedzy a nie na prace związane z rozwojem produktu),
• informacje z retrospektywy sprint,
• uzgodnienia wewnątrz organizacji dotyczące na przykład ograniczonego udziału niektórych członków zespołu w pracach danego zespołu,

Uwzględniając to, że tych elementów wpływających na capacity zespołu jest wiele a sama czynność weryfikacji ma ogromne znaczenie dla możliwości wytwórczych zespołu, postanowiłem wydzielić na diagramie procesu planowania sprint, który przygotowałem w ramach wcześniejszego wpisu (uwzględniając kroki 1*,2*,3* z wpisu o zdalnych ceremoniach), dwa dodatkowe kroki (oznaczone czarnym tłem) . Na diagramie oznaczyłem, że te dwa zadania są „pochodną” danych wejściowych do wskazanego powyżej kroku procesu („Wybierz elementy backlog„).

Pierwszy: Zweryfikuj capacity
Krok ten ma miejsce przed samą ceremonią, w ramach przygotowania. Jest wykonywany na bazie dostępnych na dany moment informacji o capacity zespołu. Atualność powinna zostać zweryfikowana wspólnie z zespołem deweloperskim podczas samego planowania. Product owner bierze pod uwagę wskazane powyżej elementy i dostosowuje swoją propozycję prac na najbliższy sprint.

Patrząc dodatkowo na dotychczasową prędkość zespołu, napotkane problemy, zakończone i niezakończone zadania, może zadecydować o przesunięciach zadań między planowanymi sprintami, rezygnacji z pewnych zadań lub przygotowaniu innego podejścia do określonych zadań. Może także wytypować zadania, które wymagają ponownego refinementu. Jest to propozycja kolejności – można ustawić kroki wskazane na diagramie w ramach przygotowania ceremonii w innej kolejności. Propozycja przygotowania przed ceremonią jest efektem różnych zasygnalizowanych działań, pamiętając o tym, że ostateczny zakres sprint backlog zostanie ustalony dopiero podczas właściwej ceremonii.

Drugi: Potwierdź capacity
Podczas samej ceremonii następuje potwierdzenie planowanych nieobecności, przyjętych założeń oraz ewentualna aktualizacja o informacje przekazane w ramach zespołu. Zespół wymienia się wewnętrznie informacjami o nieobecnościach i określa swoją dostępność. Działanie to zaproponowałem na diagramie po przedstawieniu propozycji planu sprint. Uzasadniam to tym, że zespół może lepiej osadzić to, co wie o dostępności członków zespołu i na przykład odnieść się do określonych zadań, że ich nie ruszymy bez udziału określonej osoby lub bez rozwiązania problemu, którym ta osoba się zajmowała.

Teoretycznie takie informacje powinny zostać przekazane na koniec poprzedniego sprint – jednak w momencie planowania może to okazać się bardziej lub mniej kluczowe, bazując na wizji zespołu odnośnie realizacji proponowanych zadań. Jest to propozycja – kolejność można zamienić. Istotne jednak jest następny krok, w którym bazując na tych ustaleniach, następuje aktualizacja elementów a następnie potwierdzenie ich kompletności.

Przesłanki postępu w sprint

Codziennie, o tej samej porze, na 15 minut, przed tablicą papierową, suchościeralną lub elektroniczną, w ustalonym miejscu lub za pomocą ustalonego środka komunikacji (gdy ceremonie odbywają się zdalnie,  lub zespół nie znajduje się w jednym miejscu), cały zespół scrumowy, bez wyjątków, opóźnień spotyka się tzw. daily (dokładnie daily scrum). Jest to spotkanie, które ma umożliwić wymianę zespołowi informacji o tym, czy przybliżamy się do celu sprintu, czy pojawiły się jakieś problemy, czy są zagrożenia. To także okazja do synchronizacji, podjęcia szybkich decyzji oraz ustalenia zasad pomocy czy współpracy. W czasie takiego spotkania każdy z obecnych uczestników powinien zabrać głos i zostać wysłuchanym. To moment oderwania od realizowanych prac i skupienia się w danym momencie na tym spotkaniu – w celu inspekcji prac i odpowiedniego dostosowania (adaptacji) działań. Spotkanie to odbywa się przez cały sprint od momentu jego rozpoczęcia na planowaniu sprint, aż do jego zakończenia. Samo spotkanie może być też jednym z tematów poruszanych na spotkaniu retrospektywy.

Miałem okazję uczestniczyć w spotkaniach daily, które były zróżnicowane pod względem sprawności przebiegu, liczby podejmowanych decyzji czy też zaangażowania członków zespołu. Obserwowałem także spotkania w innych zespołach, których nie byłem członkiem. Co ciekawe można podczas takiego spotkania usłyszeć różne sformułowania i wypowiedzi. Jedni się rozwodzili, inni przechodzili do sedna i w żołnierskich słowach mówili, to, co uważali za stosowne. Uczestniczyłem też w spotkaniu, w którym podczas daily, następowało przejście po blokach tematycznych, przy których każda z osób mogła się wypowiedzieć. W innych spotkaniach, każda z osób wypowiadała się po kolei, jedna po drugiej, czy to alfabetycznie czy też w ustalonej na bieżąco kolejności.

Załóżmy, że mamy 7 osobowy zespół i w ramach danego sprint, trzy wybrane spotkania daily, wyglądały jak na poniższym diagramie pod kątem użytych sformułowań i przekazanych informacji.

Można zauważyć, że część sformułowań (jak nie większość) odpowiada na pytania, które „określają” formułę daily – Scrum Guide proponuje następujące pytania:

• Co zrobiłem wczoraj, co pomogło Zespołowi (Deweloperskiemu) przybliżyć się do osiągnięcia Celu Sprintu? (oznaczone na diagramie zielonym tłem)
• Co zrobię dzisiaj, co pomoże Zespołowi (Deweloperskiemu) przybliżyć się do osiągnięcia Celu Sprintu? (oznaczone pomarańczowym tłem)
• Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu? (oznaczone tłem czerwonym)

Każda z osób formułując swoją wypowiedzieć zadecydowała o czym chce powiedzieć i co powinna powiedzieć – w zależności od wykonanej pracy, postępów, tego, co się wydarzyło poprzedniego dnia lub planu na kolejny dzień czy nawet dni. Można powiedzieć, że przeprowadza pewien proces decyzyjny – próba jego zobrazowania znajduje się na poniższym diagramie

Na diagramie dodałem dodatkowe wyjaśnienia, które z jednej strony uzasadniają umiejscowienie danego pytania w drzewku decyzyjnym (ang. decision tree) a z drugiej – tak myślę – wyjaśniają przyjęte założenia. Na diagramie analogicznymi kolorami zaznaczono elementy odpowiadające powyższym pytaniom ze Scrum Guida. Pierwszym pytaniem jest to o zakończenie swoich zadań, ponieważ najbardziej przybliża do realizacji celu sprintu. Kolejne pytania wskazują na postęp w realizacji przyjętych zobowiązań na sprint. Na końcu każdej ścieżki jest pytanie o urlop, które mógłbym pominąć, jednakże nieobecności, w szczególności te niezaplanowane, mogą znacznie wpłynąć na realizację zobowiązań – dlatego to zasygnalizowałem.

Analizując wskazane komentarze członków zespołu, można powiedzieć, że odpowiedzi na niektóre pytania można się domyślić . Może być tak, że zespół umówił się na to, że mówi – nie mam problemów lub nie widzę zagrożeń dla realizacji zadań, gdy to jest faktem. Z tego co zaobserwowałem bardziej jest to odpowiedź w domyśle przy założeniu, że jak jest problem, to osoba, która go znalazła, go poruszy. Zespół mógł się także dowiedzieć wcześniej o problemie lub efekcie dotychczasowych prac. Uczestniczyłem też w daily, gdzie padało na koniec pytanie – czy są jakieś problemy lub zagrożenia dla realizacji prac. Przeważnie członkowie zespołu skupiają się na dwóch aspektach – co zrobili i planują robić w kolejnym dniu.

Odpowiadając sobie samemu na te pytania, co w sumie obrazuje diagram, skupiamy się na tym, co jest istotne z perspektywy celu sprintu oraz pozwala się zespołowi zmieścić w ograniczonym czasie dla tego spotkania. W szczególności, gdy informujemy o zakończeniu zadań, które się podjęło, dajemy sygnał zespołowi, że jest przestrzeń na pomoc, dodatkowe zadania lub uzgodnione działania.

Na diagramie umieściłem 2 rozdzielone pytania: o problem i o zagrożenie. Mógłbym to połączyć w jedno pytanie lub zamienić kolejność. Przyjąłem założenie, że najpierw rozwiązujemy problem, który może mieć skutek w braku realizacji danego zadania lub powiązanych. Podobnie jest z zagrożeniem, ale jest to ocena wykonującego zadania, które może się zmienić w przeciągu najbliższego dnia lub po dopytaniu przez członków zespołu, może być ograniczona przez odpowiednią pomoc, dodatkowe wyjaśnienia lub może być istotnym problemem, którym należy się pilnie zająć.

Na diagramie zaprezentowałem tylko trzy dni (opierając się na przykładowych wypowiedziach, które są zebrane z różnych dni), a biorąc pod uwagę, że sprint trwa dwa tygodnie lub dłużej, tych możliwych komentarzy i ich wariantów może wystąpić znacznie więcej i mogą wskazywać na różnorodne podejście poszczególnych członków zespołu. Jednakże idea jest wpólna – są one wynikiem refleksji nad poprzednim dniem oraz tym, co planuje się zrobić kolejnego dnia.

Zdalne ceremonie

Panująca epidemia/pandemia oraz wprowadzone ograniczenia przez władze państwowe oraz lokalne spowodowały, że wiele podmiotów gospodarczych zaczęło się zastanawiać nad swoją przyszłością, swoim modelem działalności oraz sposobem działania. Wiele firm, co można zaobserwować na ulicy, w artykułach oraz w serwisach internetowych, wprowadziło pracę zdalną. Pracownicy przebywając w domu wykonują obowiązki związane ze swoim stanowiskiem. Muszą się przestawić na inny sposób komunikacji, interakcji oraz wykorzystywane narzędzia.

Czytałem ostatnio artykuły dotyczące pracy zdalnej. Pojawiło się wiele rad o tym jak sobie radzić, jakie zasady stosować, aby było to efektywne, jak poradzić sobie z ograniczeniami oraz jakie narzędzia wybrać. Pojawiają się rozbudowane materiały jak korzystać z określonych narzędzi komunikacji i współdzielenia pracy. Rozpatrywane są także zalety i wady każdego z nich, a także aspekt bezpieczeństwa. Dlatego postanowiłem, że nie będę skupiać się na dostępnych narzędziach – odsyłam do wielu dostępnych publikacji. Chciałbym się skupić na umiejscowieniu elementów związanych z organizacją pracy zdalnej w dwóch procesach, o których pisałem ostatnio na swoim blogu, a mianowicie planowaniu sprint oraz retrespektywie sprint.

Na poniższym diagramie są zamieszczone te dwa procesy, z usunięciem obiektów dodatkowych. Zostały wzbogacone o pewne elementy wspólne oznaczone numerami wraz z ich odpowiednim umiescowieniem w procesie (wszystkie elementy dodatkowe są zaznaczone na pomarańczowo).

Dodane elementy wskazują 3 dodatkowe kroki w procesie, które są silnie związane z przejściem zespołu agile’owego na pracę zdalną. Poniżej, krótkie przybliżenie każdego z tych kroków.

Krok oznaczony (1): Przygotuj narzędzia
Pierwszy krok, od którego warto zacząć proces planowania sprint czy retrospektywy, to wybór narzędzia, za pomocą którego będzie przeprowadzone spotkanie. Po wyborze narzędzia trzeba przygotować odpowiednie środki, zaproszenie oraz wskazać zespołowi czy potrzebuje określonych mechanizmów, instalacji czy innych elementów. Wybór narzędzia jest uzależniony od potrzeb zespołu: czy zależy zespołowi, aby tylko się słyszeć oraz móc zaprezentować swój ekran, czy też potrzebne są szersze możliwości. Może jednak potrzebne są rozwiązania w zakresie zdalnej współpracy zespołu. Może zespół chce się przez całe spotkanie widzieć (co na przykład w przypadku retrospektywy byłoby przydatne, aby widzieć reakcje). Ten krok ma miejsce przed spotkaniem, na etapie jego przygotowania.

Krok oznaczony (2): Wdróż narzędzia
W momencie rozpoczęcia spotkania, warto wykonać weryfikację czy wszyscy słyszą dobrze (w sposób akceptowalny) pozostałych uczestników i czy nie mają problemów z wybranym narzędziem. Warto też sprawdzić czy jest możliwość wyświetlenia prezentacji czy przeprowadzenia sesji współpracy przy pomocy wybranego narzędzia. Jeżeli zespół korzysta z połączeń video, to dobrze sprawdzić czy obraz spełnia oczekiwania. Dobrą praktyką jest aby na początku spotkania także ustalić zasady wykorzystania narzędzia – na przykład mutowanie się uczestników, którzy w dany momencie nie mówią lub informowanie natychmiast o problemach. Element dodany jako pierwsza część spotkania.

Krok oznaczony (3): Zweryfikuj działanie
W trakcie spotkania, warto co jakiś czas upewniać się czy nikt nie wypadł ze spotkania lub czy nadal wszyscy słyszą w sposób akceptowalny pozostałych uczestników. Uczestnicy mogą też utwierdzać się, że każdy z uczestników widzi wykonane zmiany lub cały udostępniony ekran. W sytuacjach problemowych uczestnicy przypominają o ustalonych zasadach – prosząc na przykład o wyłączenie mikrofonu, poprawę mikrofonu czy też zmianę lokalizacji w domu, bo na przykład w tle są rozpraszające dźwięki. Ten element został umieszczony na diagramie jako ścieżka równoczesna procesu, dołączona do odpowiednich miejsc w procesie – tzw. bramka równoległa (ang. parallel gateway).

 

Proces planowania sprintu

Na początku stycznia na LinkedIn jeden z jego użytkowników udostępnił wpis ze strony agileinstitute.pl o tytule „Czy cel sprintu w Scrumie jest opcjonalny?”. Autorem artykułu jest Aleksander Kóska i pod jego udostępnieniem rozwinęła się ciekawa dyskusja. W trakcie dyskusji wyraziłem swoje zdanie, że moim zdaniem dobrze jest, gdy ten cel sprintu jest zdefiniowany, bo wiemy wtedy do czego zespół dąży i łatwiej podejmować decyzje, gdy pojawią się wątpliwości. O tym więcej za chwilę… Swoją drogą warto zapoznać się ze wskazanym artykułem oraz z powiązanymi treściami.

Po zapoznaniu się z tą dyskusją, zacząłem się zastanawiać jak w „rzeczywistości” wygląda proces planowania sprintu oraz jak on jest powiązany z określonym celem sprintu. Specjalnie jedno ze słów w powyższym zdaniu umieściłem w cudzysłowie, ponieważ będzie to pewne spojrzenie na ten proces. A proces ten, czego mam świadomość, może wyglądać różnie w zależności od specyfiki produktu, składu zespołu, jego dojrzałości agile’owej, a także zebranego doświadczenia w trakcie dotychczas zakończonych sprintów. Zaznaczam, że jest to spojrzenie z perspektywy product ownera. Gdyby zapytać różne zespoły lub product ownerów, pewnie można byłoby zidentyfikować różnice, ale myślę, że pewne ramy pozostałyby wspólne.

Zacznę od próby zobrazowania tego procesu na diagramie. Następnie spróbuję go przybliżyć. Do zobrazowania procesu użyłem notacji BPMN (pokolorowanej w specjalny sposób), której staram się używać, gdy próbuję graficznie przedstawić diagramy i koncepcje omawiane we wpisach na tym blogu.

Na diagramie zostały umieszczone następujące kroki:
1) Określ cel sprintu
Choćby wstępnie, product owner powinien określić czy w kolejnym sprint zespół ma się skupić na dalszym rozwoju funkcjonalności, dodaniu nowej funkcjonalności, likwidacji długu technologicznego, poprawie błędów, dokończeniu zadań z bieżącego sprintu lub zmianie funkcjonalności po zebranych uwagach np. z pilotażu. Możliwości jest wiele, zależy to od produktu, etapu jego rozwoju oraz ustalonego wcześniej planu działań. Product owner określając cel sprintu kieruje się wizją produktu, do której dąży. Przygotowanie sprintu oraz sama ceremonia planowania odbywa się w odpowiednim momencie czasu (dlatego zastosowałem na starcie procesu zdarzenie start event – timer).
2) Wybierz elementy z backlog
Product owner może wybrać wstępną listę elementów, którymi powinien się zespół zająć w następnym sprint. Elementy wynikają z przyjętego celu sprintu oraz priorytetów w ramach backlogu (wejście do kroku procesu oznaczone za pomocą asocjacji na diagramie). Zadania powinny być już wycenione na refinement (polecam wpis na blogu agile247.pl na temat tej ceremonii). Podczas ich wyboru uwzględnia prędkość (ang. velocity – odsyłam do szczegółowej informacji na scrum.org) oraz możliwości (ang. capacity – odsyłam do szczegółowej informacji na scrum,org) zespołu (kolejne wejścia do tego kroku, które oznaczyłem na diagramie – są to elementy wykorzystywane podczas realizacji kroku). Efektem jest wstępna wersja sprint backlog (wyjście z kroku procesu).
3) Omów elementy z zespołem
Na ceremonii planowania, wstępny sprint backlog omawiany jest z zespołem, wyjaśniane są wątpliwości (jeśli się pojawią). Często pojawia się dyskusja o tym, czy zadania są możliwe do wykonania, czy jednak nie powinny być wykonane inne zadania – bazując na doświadczeniach wcześniejszych sprintów i tym, co się wydarzyło od momentu wyceny i omówienia danego zadania podczas refinement). Product owner powinien także omówić jak dane zadanie, które wybrał w poprzednim kroku, przyczynia się do realizacji celu sprintu, który także powinien przedstawić. Zespół z kolei patrząc na proponowany cel sprintu może zaproponować inne zadania, które jego zdaniem przyczynią się do realizacji celu.
4) Zaktualizuj elementy
Jeżeli to jest konieczne elementy sprint backlog są aktualizowane i wyceniane ponownie. Podczas tego kroku mogą się pojawić dodatkowe zadania, nowe lub wzięte z backlog lub mogą zostać jakieś zadania „zrzucone” do backlog. W tym kroku może także nastąpić wstępne przypisanie opiekunów elementów (wyjście z kroku) – na przykład zespół może określić, którymi zadaniami zajmie się w pierwszej kolejności i kto z zespołu podejmuje jakie kroki. Poszczególni członkowie zespołu sami wskazują, które zadania zamierzają zrealizować. Efektem jest zaktualizowany sprint backlog.
5) Potwierdź kompletność elementów
Krok, którego celem jest ostateczne potwierdzenie czy cały zespół wie i rozumie co jest do zrobienia, do czego dąży zespół (wskazane poprzez cel sprintu), jaki jest wstępny plan na realizację zadań oraz tego, że wszystkie konieczne zmiany w sprint backlog zostały wykonane.
6) Uruchom sprint
W tym momencie powstaje pewien rodzaj umowy między zespołem a product ownerem. Pozwala ona zespołowi skupić się na wykonywaniu zaplanowanych prac. Formalne uruchomienie sprintu następuje przeważnie w narzędziu wspierającym pracę zespołu, monitorowanie postępów, dokumentowanie działań. Takie narzędzie może także wspierać liczenie prędkości zespołu.

Powyższy proces jest ważnym elementem pracy w zespole agile’owym. Planowanie to ceremonia, która decyduje w dużym stopniu o tym jak dużymi krokami rozwija się produkt. Jeżeli capacity zespołu lub jego prędkość spada, zespół w porozumieniu z product ownerem podejmie na kolejny sprint mniejsze zobowiązanie. Efektem może być późniejsze dostarczenie oczekiwanej funkcjonalności dla klienta. Może także wystąpić sytuacja, gdy konieczne będzie ograniczenie wymagań odnośnie produktu.

Jak widać cel sprintu przewija się na każdym kroku tego procesu planowania. Pomaga decydować o tym, co powinno zostać podjęte w danej iteracji a co porzucone. Bez niego będzie o wiele trudniej. Planowanie jako czynność biznesowa, zgodnie z jej definicją, zakłada silną korelację między celem oraz sposobem dojścia do niego.

W definicji zawartej w business dictionary mamy zapis: „Podstawowa funkcja zarządzania obejmująca jeden lub wiele planów do osiągnięcia optymalnego połączenia potrzeb [czyli wymagań zapisanych w backlog i planie rozwoju produktu] z dostępnymi zasobami [capacity zespołu, jego umiejętności]. Proces planowania obejmuje: (1) identyfikację celów do osiągnięcia; (2) definiuje strategię do ich osiągnięcia; (3) tworzy lub organizuje niezbędne środki [omawiane podczas planowania] (4) wdraża, prowadzi i monitoruje kroki z zachowaniem odpowiedniej sekwencji [codzienne daily pozwala na weryfikację postępu prac, identyfikację problemów]”. W nawiasach kwadratowych umieściłem komentarze odwołujące się do treści poruszonych powyżej podczas opisu procesu planowania w agile.

Myślę, że zdefiniowanie celu dla sprintu tworzy całość z ceremonią oraz jest spójne z rozumieniem procesu planowania.

—

Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

Od początku do końca, czy na odwrót?

Jakiś czas temu opisywałem na prostym przykładzie zakupów jakie zależności w projekcie występują między czasem, zakresem oraz budżetem. Zwiększając listę zakupów nastąpi prawodpodobnie wzrost pozostałych wartości (czasu realizacji oraz potrzebnego budżetu). Ograniczenie z kolei czasu lub budżetu może się wiązać z ograniczeniem możliwych do wykonia zakupów. Takie podejście jest specyficzne dla waterfallowego zarządzania projektami.

Załóżmy jednak teraz, że mamy listę zakupów i wiemy ile z jej pozycji możemy zrealizować w określonej jednostce czasu. Dzieląc wielkość listy zakupów przez ilość pozycji (prędkość) otrzymujemy wielkrotność jednostek czasu (liczbę iteracji), którą potrzebujemy do zrealizowania pełnych zakupów. Jest to tzw. planowanie z ustalonym zakresem – diagram A.

Postawmy się jednak teraz w sytuacji, gdy narzucono mam termin, do którego mamy wykonać zakupy. W takiej sytuacji, znając prędkość zakupów, jesteśmy w stanie określić jaki zakres listy jesteśmy w stanie zrealizować w narzuconym czasie. Dzieląc dostępny czas przez jednostki czasu, otrzymujemy wielkrotność prędkości realizacji (liczbę iteracji). W takiej sytuacji istotne jest określenie kryteriów szacowania wartości/użyteczności poszczególnych pozycji listy. W szczególności, gdy z wyliczeń okaże się, że realizacja pełnej listy nie jest możliwa w zaplanowanym czasie. Jest to tzw. planowanie z ustaloną datą – diagram B.

Takie sposoby planowania stosuje się w projektach opartych o metodyki zwinne (m.in. Agile). W przypadku tych metodyk, odpowiednikiem prędkości zakupów jest prędkość realizacji/zespołu liczona dla jednostki czasu, jaką jest długość tzw. sprint. Sama prędkość realizacji/zespołu jest liczona w tzw. story point-ach, w których wycenia się (w ramach wyceny zakresu) także poszczególne wymagania, będące odpowiednikami pozycji zakupów.

Opisane metody można zaprezentować jak na powyższym diagramie. Pierwsze co się rzuca w oczy to fakt, że ten sam element – lista zakupów/zakres realizacji – jest w pierszym (diagram A) przypadku wejściem dla procesu, a dla drugiego (diagram B) – wyjściem. W przypadku ustalonej (planowanej) daty zakończenia – sytuacja jest wręcz odwrotna, w pierwszym przypadku (diagram A) jest wyjściem, a w drugim (diagram B) wejściem. Procesy opierają się na tych samych podstawach – m.in. prędkości realizacji/zespołu oraz zakresie realizacji (oczekiwanym/pełnym).