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

Proces manualny (ręczny)

Czekając na swoją kolej u fryzjera (czasami byłem wcześniej, a czasami było opóźnienie) obserwowałem jakie czynności wykonuje fryzjerka podczas obsługi danego Klienta. Nie zawsze występują wszystkie czynności, ale pewien zestaw czynności się powtarza. Najpierw następuje założenie stroju ochronnego, potem umycie włosów, następnie wstępne uczesanie, strzyżenie, modelowanie, mycie włosów a następnie suszenie. Gdy włosy są farbowane lub są dodawane inne czynności (modelowanie czy pielęgnacja) kolejność tych czynności się zmienia.

To jakie czynności i w jakiej one kolejności wystąpią zależy całkowicie od fryzjerki oraz od oczekiwanej usługi przez Klienta. Cechą tych działań jest to, że wszystko fryzjerka wykonuje ręcznie (manualnie). Jest to przykład tzw. procesu manualnego (ang. manual process). Na poniższym diagramie zostały zaprezentowane wybrane kroki tego procesu.

Proces manualny (ang. manual process) charakteryzuje się następującymi cechami (wybrane cechy na bazie różnych publikacji znalezionych w sieci Internet):

• potrzebne jest działanie ludzkie, aby proces toczył się dalej i się nie przerwał – w podanym przykładzie, to fryzjerka zaprasza Klienta na fotel, zakłada zabezpieczenie i wtedy może przejść do następnego kroku. Fryzjerka ocenia kiedy skończyła strzyżenie oraz kiedy włosy Klienta są suche i można przejść do modelowania itd.
• wszystkie czynności są wykonywane ręcznie (manualnie) – mycie głowy, strzyżenie, przycinanie, nakładanie farby, czesanie wykonuje fryzjerka, choć także przy użyciu dostępnych pod ręką narzędzi/urządzeń;
• człowiek informuje samodzielnie o postępie oraz o przejściu do następnych kroków – fryzjera mówi np. proszę usiąść na fotelu, przekręcić głowę czy pyta o oczekiwaną długość włosów po ścięciu;
• uczestnicy procesu reagują na działania innych użytkowników a nie działanie systemu / komunikaty elektroniczne – fryzjer np. reaguje na komunikat Klienta o temperaturze wody podczas mycia głowy;
• bardzo łatwo zmienić kolejność, fakt lub sposób wykonywania kroków – np. fryzjerka może np. zadecydować, że tylko spryska włosy przed strzyżeniem a umyje je po; może także zrezygnować np. z oferty pielęgnacji; może także np. mniej używać maszynki do strzyżenia a więcej nożyczek;

Podobne cechy można zaobserwować także w innych procesach realizowanych w punktach usługowych. Mogą to być działania związane z pielęgnacją ciała, remontami, wspierające zakupy (np. pakowanie prezentów) czy też będące częścią większych procesów biznesowych. Jesteśmy uczestnikami lub beneficjentami takich procesów prawie każdego dnia. Część z nich można próbować automatyzować przy użyciu odpowiednich maszyn/urządzeń (np. robotów), ale pewnie duża ich część pozostanie manualnymi, ponieważ wymagają ingerencji człowieka, aby miały szansę się zakończyć oczekiwanym przez odbiorcę efektem.

Realizując dany zestaw czynności można się zastanowić czy są narzędzia, które mogą je usprawnić czy przyspieszyć oraz czy skorzystanie z nich nie będzie jakąś „stratą”. Wybór między automatyzacją lub działaniami ręcznymi musi wynikać ze świadomej decyzji poprzedzonej analizą procesu (np. metodą 5w2h lub inną), zebranie informacji zwrotnych od uczestników oraz określeniem mocnych i słabych stron danego procesu w obecnej formie.

Obowiązek dla właściciela procesu?

„…może być wykorzystana w celu stworzenia dokumentacji, której celem będzie wykazanie zgodności realizowanych procesów przetwarzania z wymaganiami RODO. Obowiązek wykazania przestrzegania stosowania przepisów RODO wynikający z art. 24 RODO nie określa bowiem w jaki sposób, poprzez jakie dokumenty, czy inne instrumenty zarządzania powinien być zrealizowany. Przepis art. 24 RODO stanowi jedynie, że administrator ma wykazać, że wdraża odpowiednie środki techniczne i organizacyjne, aby przetwarzanie odbywało się zgodnie z RODO.” oraz „...podejmowanie działań zapewniających, że osoby zaangażowane w proces przetwarzania informacji posiadają stosowne uprawnienia i uczestniczą w tym procesie w stopniu adekwatnym do realizowanych przez nie zadań oraz obowiązków mających na celu zapewnienie bezpieczeństwa informacji…” – są to dwa fragmenty artykułu ze strony Urzędu Ochrony Danych Osobowych mówiące o dokumentacji przetwarzania danych osobowych zgodnie z RODO.

Czytając ten artykuł zacząłem się zastanawiać czy przypadkiem z powodu obowiązywania rozporządzenia RODO nie pojawiają się dodatkowe obowiązki dla właściciela procesu. Samo sformułowanie właściciela procesu nie pojawia się w ustawie (o ile dobrze zweryfikowałem). Występują sformułowania odnoszące się do administratora danych, do jednostki przetwarzającej dane oraz rejestru czynności przetwarzania.

Temat wpływu RODO na procesy biznesowe już opisywałem w innym wpisie, niedługo po wejściu ustawy w życie, a był to okres kiedy podmioty funkcjonujące na rynku wysyłały do swoich klientów stosowne klauzule informacyjne. Wskazałem tam takie aspekty jak zebranie danych, zapisanie danych oraz wykorzystanie danych (co zasygnalizowałem również na poniższym diagramie). Są to elementy procesów, np. zamawiania w internecie lub innych, których kształt oraz rozwój określa właściciel procesu wraz z interesowanymi stronami. Przypomnę, że jednym z punktów było odpowiada za zgodność procesu z oczekiwaniami biznesowymi, co wydaje się oczywiste.

Działanie różnych procesów biznesowych, opartych o dane Klientów w nich uczestniczących, jest uzależnione także od innych aspektów – takich jak bezpieczeństwo procesu (w sklepie, z którego korzystam, regulamin to precyzuje), ryzyko procesu czy zgodność procesu z regulacjami obowiązującymi dany podmiot (regulamin sklepu, z którego skorzystam, ma takie zapisy, precyzujące z jakimi ustawami jest zgodny). W zależności od ustaleń i zasad stosowanych w danym podmiocie, można powiedzieć, że na jednostce rozwijającej, utrzymującej lub opiekującej się procesem, leży obowiązek spełnienia tych wymogów. Można uogólnić, że to właściciel procesu powinien odpowiadać za zgodność procesu z wymogami regulacyjnymi, w tym z RODO.  Wskazanie właściciela procesu wydaje się tutaj uzasadnione.

Dlaczego? To właściciel procesu ma (powinien mieć?) najlepszą wiedzę o tym jakie są kroki procesu oraz jakie elementy w procesie są pozyskiwane od Klienta (zasygnalizowane na diagramie). W momencie konieczności zebrania dodatkowych poświadczeń lub danych od Klienta, to właściciel procesu inicjuje samodzielnie lub wspólnie z zainteresowanymi jednostkami odpowiednią zmianę techniczną, zmierzającą do osiągnięcia postawionego celu.

Wracając do cytatu, to właściciel procesu  moim zdaniem wspiera administratora danych w określeniu odpowiednich zapisów w rejestrze czynności przetwarzania oraz wyjaśnia elementy składające się na taką pozycję jak na przykład (co próbowałem także zasygnalizować na diagramie):

• „…
• cele przetwarzania;
• opis kategorii osób, których dane dotyczą, oraz kategorii danych osobowych;
• kategorie odbiorców, którym dane osobowe zostały lub zostaną ujawnione…;
• …”

Czas realizacji a “szybkość” procesu

Składając różne elementy procesu, o których pisałem na blogu, można utworzyć uogólniony proces, który:

• zmienia wejścia procesu w wyjście procesu, na co zwracana jest uwaga w modelu SIPOC.
• ma wejścia i wyjścia procesu, uzależnione od rodzaju procesu.
• posiada kroki dodające wartość dla odbiorcy procesu (kroki oznaczone na diagramie jako VAP) lub tylko dla innych interesariuszy zainteresowanych (kroki na diagramie oznaczone jako VAI) procesem.
• obsługuje wyjątki lub alternatywne ścieżki przebiegu procesu.

Każdy realizowany proces można opisać za pomocą jego czasu realizacji, czyli Delivery Cycle Time. Wartość ta informuje jak długo trwa proces od jego zainicjowania przez Klienta, na przykład poprzez złożenie zamówienia, dostarczenie dokumentu, złożenie zapytania, po zakończenie procesu, rozumiane jako dostarczenie produktu, na przykład przedmiotu zamówienia, akceptacji dokumentu, odpowiedzi na zapytanie.

Wartość ta interesuje nie tylko odbiorcę procesu, ale także księgowość, inwestorów oraz inne grupy interesariuszy. Biorąc pod uwagę powtarzalność procesu, najlepszą sytuacją, gdy w danym czasie, na przykład miesiąca, można zrealizować kilka, kilkanaście lub więcej przebiegów procesu.

Na bazie tych informacji można byłoby spróbować obliczyć “szybkość” procesu. Dostarczając 1 produkt w czasie T, możemy potencjalnie policzyć liczbę dostarczanych produktów, obsługiwanych zamówień w czasie jednostki czasu, np. miesiąca, czyli [Miesiąc/T] sztuk/per miesiąc.

Sformułowanie “szybkość” używam w cudzysłowach, aby zaznaczyć potoczne rozumienie tego słowa, przez porównanie na przykład do szybkości drukowania (10 kartek/minut). Obok tego pojęcia funkcjonuje także pojęcie “prędkości” (wartości z wektorem). W przypadku procesów pojęcia te też podlegają próbie rozróżnienia, wychodząc od pojęć z terminologii angielskiej.