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.

Reklama

Przez telefon czy na stronie?

Chyba każdy zna ten moment gdy jest przerwa w dostawie prądu – czy to chwilowa objawiająca się tylko mrugnięciem czy też dłuższa, wymagająca określonych działań (sięgnięcia po latarkę, świeczkę czy inny sprzęt). Gdy ostatnio w sobotę, nastąpiły 3 krótkie „mrugnięcia” a później przyszedł do mnie sąsiad z pytaniem czy coś wiem, przypomniałem sobie o innej sytuacji. Pod koniec roku 2019, dzień przed wigilią byłem w domu z rodziną, mijała właśnie godzina 19 i nagle ciemność – na całym osiedlu. Niezły moment na taki problem – ludzie przygotowują święta, wstawione ciasta, mięsa i inne potrawy a tu brak prądu. Złapałem za telefon i szukam informacji. Za pierwszym razem nic nie znalazłem, a za drugim pojawiła się informacja na mapie dostawcy prądu o  awaryjnej przerwie w dostawie prądu, która jest szacowana na 2 godziny. Minęło kilkanaście minut i prąd znów był dostarczany. A po 20 powtórka, znów ciemność – tym razem na krócej. Informacja na stronie się nie zmieniła.

Mogę sobie wyobrazić, że w momencie pierwszego wyłączenia część osób złapało za telefon i zamiast szukać informacji (sprawdzać samodzielnie) zadzwoniło na pogotowie energetyczne lub na infolinię dostawcy prądu. Mogło być też tak, że ktoś mógł pójść do sąsiada i spytać czy coś wie o na przykład planowanym wyłączeniu prądu. Wyobraźmy sobie jak mógłby wyglądać proces od strony dostawcy, który łączy te dwie możliwości – stronę z informacjami i telefony.

Dostawca na podstawie zgłoszeń telefonicznych i ich weryfikacji mógłby umieścić informację na stronie o awarii. Dzięki czemu zaspokoi potrzebę informacji tych sprawdzających i potencjalnie zmniejszy liczbę telefonów z regionu objętego awarią. Może także mieć system monitoringu, który wskaże mu, że taka awaria nastąpiła. Wejściem do procesu może być zgłoszenie telefoniczne od odbiorcy lub własny monitoring. Wyjściem może być informacja na stronie. Skutkiem pewnie będzie także wysłanie ekipy technicznej w rejon objęty awarią lub inne specyficzne działania.

Na powyższym diagramie próbowałem przedstawić omówiony proces. Na diagramie w notacji BPMN wykorzystałem zdarzenie inicjujące proces, powstałe na bazie zgłoszenia/komunikatu przekazanego przez „zewnętrznego” aktora. Jest to tzw. message start event – jeden z typów zdarzeń (ang. events) używanych w notacji BPMN służącej do modelowania procesów. To zdarzenie na diagramie jest zaznaczone na żółto. Opisany proces nie miałby miejsca, jeżeli takie zdarzenie nie nastąpi. Brak telefonów lub innych zgłoszeń oznacza prawdopodobnie, że nie ma awarii.
—
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.

Black Friday

Black friday, black week, czarny piątek, czarny tydzień, black weekend, promocja, do 50%, do 60%, do 70%, darmowa dostawa … tak przez ostatni tydzień, w piątek a potem w weekend atakowały nas sklepy stacjonarne i internetowe. Wielu się skusiło. Jedni wybrali rzeczy potrzebne a inni mniej, kupując pod impulsem chwili.  Jedni płacili gotówką a inni wykorzystali elektroniczne formy płatności. Ci co korzystali ze sklepów internetowych pewnie użyli pośredników płatności.

Czytając publikacje na ten temat można się spotkać z pojęciem Pay-by-link (PBL), które oznacza że w momencie przejścia do płatności ze sklepu i zalogowaniu się do banku, dane przelewu są już wypełnione i wystarczy tylko zweryfikować (koniecznie!) i potwierdzić transakcję. Potem wracamy do sklepu. Jeden z pośredników udostępnił dokumentację techniczną usługi w sieci Internet. Poniższy diagram jest uogólnieniem procesów znalezionych w różnych publikacjach a odnoszących się do zasygnalizowanego procesu płatności. Działania wymagające współpracy dwóch podmiotów zostały zaznaczone na żółto (odpowiednie oznaczenie na diagramie).

W dokumentacji jednego z pośredników można znaleźć informacje o wejściach (atrybuty na wejściu) które musi zapewnić sklep aby proces się udał (są to wybrane atrybuty):

Atrybut	Komentarz
id sklepu	Ustalony między podmiotami
kwota transakcji	na podstawie zamówienia złożonego (krok „Złóż zamówienie„) przez Klienta oraz kosztów sposobu dostawy wybranego przez Klienta, używane podczas wypełnienia formularza przelewu
waluta transakcji	używane podczas wypełnienia formularza przelewu
opis transakcji	określane przez sklep na bazie zamówienia, używane podczas wypełnienia formularza przelewu
adres powrotny po płatności	określane przez sklep, dzięki czemu pośrednik wie gdzie wrócić w ramach kroku „Obsłuż powrót”
dane osoby dokonującej płatności	dane pomocnicze
dodatkowe parametry techniczne	dane pomocnicze

Powrót do sklepu oznacza wyjścia (wybrane atrybuty):

Atrybut	Komentarz
id sklepu	Analogiczna wartość jak przy wejściu
status transakcji	Informacja o tym w jakim stanie jest transakcja
flaga zakończenia	Oznaczenie dla sklepu czy transakcja się zakończyła
data/czas transakcji	Data/Czas wykonania transakcji
zwrotne wartości parametrów wejściowych	dane pomocnicze
dodatkowe parametry techniczne	dane pomocnicze

Szczegółowe dane i ich opisy można znaleźć w dokumentacji technicznej pośrednika.

Dzięki temu, że pośrednik dba o przekazanie odpowiednich danych w obydwie strony między sklepem a bankiem, korzystanie z tego procesu jest wygodne i szybkie. Wymaga wprowadzenia określonego zestawu danych po drodze, które zapewniają, że transakcja jest bezpieczna i wykonana świadomie przez Klienta. Ogromną zaletą jest to, że formularz przelewu jest wypełniony danymi zgodnymi z danymi podanymi w sklepie internetowym i wynikających z określonych parametrów zamówienia. Nie trzeba ich powtarzać w ręcznie wypełnianym przelewie, co mogłoby nieść za sobą ryzyko błędów.

Taki sposób działania bardzo ułatwia skorzystanie z promocji oferowanych w ramach dni typu black friday i podobnych. Przy korzystaniu z kilku sklepów w czasie jednego dnia Klient unika ryzyka popełnienia błędu podczas ręcznego wypełniania przelewu. Sam czas potrzebny do opłacenia zamówienia produktu lub produktów jest skrócony do minimum.

Pytania o … SIPOC

W książce „Lean Banking” (F. Majorana, A. Morelli) można znaleźć poniższy diagram, który wskazuje „przykład kolejnych czynności , jakie muszą zostać wykonane, aby sporządzić poprawnie SIPOC”. Diagram na potrzeby wpisu został przetłumaczony oraz lekko zmodyfikowany (co widać na diagramie).

Spróbujmy odpowiedzieć na postawione pytania na bazie procesu realizacji zamówienia przy użyciu sklepu internetowego, którego przykład wykorzystuję często na blogu. Jest to proces „łatwo” dostępny dla większości użytkowników sieci Internet. Taki użytkownik ma możliwość poznania całego przebiegu procesu od jego zainicjowania aż do samego końca (otrzymania zamówionego produktu). W sytuacjach problemowych (np. brak zamówionego produktu lub inny problem), to właśnie do niego jest kierowana odpowiednia informacja z prośbą o podjęcie decyzji co dalej z procesem. Użytkownik wybierając konkretny produkt orientuje się przeważnie kto jest jego dostawcą, jaka jest jego cena na rynku oraz parametry.

Odpowiedzi na pytania mogą być następujące (punkty odpowiadają numerom pytań na diagramie a odpowiedzi są poglądowe):

1. Jest to proces realizacji zamówienia ze sklepu internetowego z dostarczeniem produktu w sposób wskazany przez Klienta. Klient płaci z zamówiony produkt w wybrany sposób (wybierając z opcji dopuszczonych przez sklep, po spełnieniu określonych warunków).
2. Pytania odnoszą się do granic procesu. Określenie tego, gdzie zaczyna i kończy dany proces jest istotne z różnych względów. W przypadku procesu zamówienia można przyjąć, że złożenie zamówienia jest początkiem procesu a dostarczenie produktu jest jego końcem. W zależności od tego, czy Klient jest nowy lub istniejący, w trakcie tego procesu następuje rejestracja lub nie nowego użytkownika sklepu internetowego. Jednakże to, że Klient się zarejestruje nie oznacza, że złoży zamówienie – może je np. zapisać na przyszłość. Zarejestrowani użytkownicy mogą przeważnie skorzystać z większej liczby opcji oraz udogodnień jakie daje dany sklep.
3. Output’em procesu jest:
   a. produkt dostarczony do Klienta za pomocą ustalonego sposobu dostawy oraz
   b. zaksięgowana płatność za produkt na koncie sklepu
4. Beneficjentem output’ów są:
   3a. Klient;
   3b. Działa finansowy sklepu internetowego oraz dostawcy produktów;
5. Od output’u:
   3a. Klient oczekuje, że produkt jest zgodny w parametrach z zamówionym produktem, że nie jest uszkodzony; jest kompletny;
   3b. Firma oczekuje, że dokonana płatność przez Klienta dotarła we właściwej wysokości na konto sklepu;
6. Aby proces miał szansę zaistnieć to:
   a. Produkt musi być w magazynie sklepu;
   b. Dostawca produktu dysponuje możliwościami uzupełnienia produktu na zamówienie;
   c. Sklep internetowy musi być dostępny dla użytkowników (strona musi działać a serwery były w stanie obsłużyć ruch);
   d. Sklep musi obsługiwać różne formy płatności;
   e. Sklep musi mieć ustalone mechanizmy dostawy produktów;
   f. Pośrednicy uczestniczący w procesie są gotowi na przewóz produktów;
   g. Powinien istnieć określony regulamin sklepu określający prawa i obowiązki poszczególnych stron transakcji (Klienta oraz sklepu jako całości);
   h. Ceny produktów są adekwatne do produktów;
   i. Klient musi wybrać produkt, określić parametry zamówienia oraz je potwierdzić.
   Warunki zaistnienia procesu są wynikową możliwości technicznych, posiadanych zasobów oraz planowanych do osiągnięcia efektów. Input’y w ramach procesu są łączone i pozwalają na osiągnięcie output’ów – na poszczególnych krokach procesu są jego wejściami przekształcanymi w wyjścia.
7. Dostawcą input’ów są: dział zamówień sklepu (6a), producent produktów (6b), dział techniczny wraz z wsparciem firmy hostingowej (6c-6d), dział dystrybucji (6e-6f), sklep jako całość (6g-6h) oraz Klient (6i);
8. Input’y wskazane powyżej powinny się charakteryzować tym, że:
   a. Są dostępne w momencie czasu, w którym Klient decyduje się na złożenie zamówienia;
   b. Produkty dostępne w sklepie w zakresie parametrów są zgodne z rzeczywistością;
   c. Formy płatności oferowane przez sklep funkcjonują poprawnie i bez zakłóceń;
   d. Firmy pośredniczące działają w ramach zgodnych z regulaminem sklepu;
   Sposób ich wykorzystania oraz efekty są zgodne z regulaminem sklepu;

Powyższe odpowiedzi składają się na uogólniony przykład. Przykładając je do konkretnego procesu uległyby większym lub mniejszym zmianom. Wskazując konkretne produkty (ich rodzaj, charakter) można byłoby dodać dodatkowe wymagania/charakterystyki lub wymagania przy których proces może zaistnieć.

Gdy chcesz wysłać paczkę

Dzwoni domofon. Pytasz kto to? Pada krótka odpowiedź: kurier. Nie przypominasz sobie czy na coś czekasz, więc wpuszczasz i weryfikujesz co to za przesyłka. Sprawdzasz i przyjmujesz paczkę lub nie. Gdy znasz nadawcę jest łatwiej i dane odbiorcy w pełni się zgadzają – przyjmujesz paczkę. W innych sytuacjach – kwestia pozostaje do wyjaśnienia. Te wyjaśnienia ułatwia dołączony do paczki list przewozowy/nalepka adresowa. Oprócz nadawcy i odbiorcy przesyłki zawiera informacje o jej wymiarach, wadze, nazwie firmy oraz dodatkowe informacje. Są one efektem procesu zlecenia wysyłki paczki. Tzw. wyjścia poszczególnych kroków.

Diagram przedstawia standardowy proces w takim przypadku. Przeglądając różne strony internetowe firm kurierskich można zauważyć, że na samym początku następuje pytanie o wagę i wymiary paczki, następnie miejsce dostarczenia. Paramatry te pozwalają określić cenę paczki. Jeżeli nadawca akceptuje te koszty, może podać szczegółowe dane nadawcy i odbiorcy. Czasami najpierw następuje rejestracja nadawcy, a potem reszta procesu. Bez podawania jakichkolwiek danych można wycenić paczkę i określić czy jest standardowa, czy może wymaga innych działań. Na odpowiednim etapie konieczne jest także opłacenie wysyłki.

W sytuacji, gdy zależy nam na ubezpieczeniu lub gwarancji dostarczenia paczki do określonej godziny jesteśmy zobowiązani do poniesienia wyższej opłaty, wykonania dodatkowych kroków lub zlecenia wysyłki paczki w określonych godzinach i miejscu. Elementów tych nie uwzględniłem na diagramie.

Wartość dodana w takim procesie może być tworzona przez dodatkowe udogodnienia, w tym poprzez możliwość śledzenia położenia paczki – jej wysyłki, transportu, dostarczenia, dzięki poznaniu z góry określonym identyfikatorom dla paczki.

Wejścia i wyjścia w procesie

Diagramy zaprezentowane w poprzednim wpisie – diagram procesu w BPMN oraz wizualizację myślenia systemowego – można spróbować połączyć na jednym diagramie, powstałym na bazie diagramu aktywności dla procesu biznesowego. Na poniższym diagramie zostały dodane wejścia do kroków i wyjścia z kroków (kierunek strzałek obrazuje to, czy dany obiekt jest wejściem czy wyjściem z danego kroku procesu).

Można zauważyć, że:

• niektóre wejścia/wyjścia pasują do kwestii zobrazowanych na diagramie myślenia systemowego – np. „Akceptowalna stawka”;
• niektóre kwestie z diagramu można potraktować jako cechę wejść/wyjść – np. „Liczba zgłoszeń” jest cechą „Listy zgłoszeń”;
• niektóre kwestie z diagramu nie są związane z wejściami/wyjściami a bardziej są cechą charakterystyczną dla całego procesu – np. „Czas realizacji rekrutacji”;

Istotne jest to, że cechy wejść do poszczególnych kroków wpływają zarówno na realizację danego kroku, jak i całego procesu. Takimi cechami mogą być liczba zgłoszeń, jakość zgłoszeń, czas potrzebny na zapoznanie się z danym zgłoszeniem, stopień dopasowania poszczególnych zgłoszeń do opisu stanowiska pracy itd.

Świadomość takich powiązań ułatwia realizację procesu. W szczególności, gdy dany uczestnik procesu ma świadomość, że efekt (i jakość) realizacji jego zadania zostanie wykorzystany dalej w procesie, wpłynie na działania dalszych uczestników procesu. Właśnie do pokazania takich zależności w ramach procesu w kontekście produktów dla klientów wewnętrznych procesu można wykorzystać myślenie systemowe. Na analizie wejść/wyjść procesu jest oparte narzędzie SIPOC pochodzące z metodologii Six Sigma (ale o tym innym razem).