Swarming – technika dla zespołu pomagająca kończyć zadania

Swarming w praktyce

Swarming w praktyce

Pomagałem ostatnio nowo powstałemu zespołowi podczas ich drugiego Sprintu. Kiedy się u nich pojawiłem – dzień przed Sprint Review – na tablicy korkowej wisiało 10 zadań, z czego tylko 1 było zakończone. Co więcej, było to zadanie znajdujące się na ostatniej pozycji ich Sprint Backlogu.

Podczas rozmowy ze Scrum Masterem tego zespołu dowiedziałem się, że mają problem z finalizowaniem zadań oraz, że to kolejny sprint, kiedy dużo pracy jest w trakcie realizacji, a pomimo tego niewiele jest faktycznie skończone.

Co to jest swarming?

Zaproponowałem użycie techniki zwanej swarming (ang. rój). Polega ona na tym, że w danym momencie cały zespół pracuje nad jedną, wybraną historyjką i nie przechodzi do kolejnej, zanim poprzednia nie zostanie zakończona.

Jak podzielić się pracą?

Oczywiście od razu pojawiło się pytanie – „no dobrze, ale jak zorganizować pracę, żeby wszyscy mieli co robić?”. Poniżej kilka przykładów pracy, która może zostać wykonana równocześnie w ramach pracy nad jednym zadaniem:

  • przygotowanie scenariuszy testowych
  • zdobycie brakującej wiedzy biznesowej potrzebnej do realizacji zadania
  • napisanie unit testów
  • konfiguracja środowiska testowego (zapewnienie danych, połączeń do zewnętrznych systemów, konfiguracja)
  • nagranie testów automatycznych (początkową będą świecić na czerwono)
  • opracowanie planu prezentacji przyrostu na Sprint Review
  • przyglądnięcie się zadaniu z perspektywy Definition of Done
  • programowanie w parach
  • konsultacja rozwiązania z innymi deweloperami (spoza zespołu)

Na co zwrócić uwagę?

  • rozmiar zadania – zbyt małe zadanie może powodować, że trudno będzie sensownie podzielić się pracą; z drugiej strony zbyt duże może spowodować, że w rzeczywistości każdy zajmie się swoim, niezależnym fragmentem większej historyjki
  • liczba jednocześnie realizowanych zadań – spotkałem się z wariantem „dwie historyjki na raz” oraz „tyle historyjek na raz, ilu testerów w zespole”

Fotografia użyta na licencji Creative Commons od użytkownika SidPix.

Sposoby dzielenia User Stories na małe części

Małe, zbywalne kawałki - tak myśl o user stories

Małe, zbywalne kawałki – tak myśl o user stories

Efektem każdego sprintu w Scrumie powinien być działający fragment oprogramowania. Problematyczne dla wielu zespołów – szczególnie jeśli wcześniej pracowali w modelu kaskadowym – jest dzielenie wymagań produktowych na małe, zbywalne przyrosty. Często słyszy się głosy z zespołu mówiące, że krótkie sprinty uniemożliwiają oddanie sensownego przyrostu, a jako rozwiązanie proponują wydłużyć sprint.

Idąc tym tokiem myślenia możemy założyć, że skoro w ciągu jednotygodniowego sprintu oddajemy zero działającego oprogramowania, to w ciągu dwutygodniowego sprintu oddamy… 2 razy zero.

Jak zatem uporać się ze wspomnianym zerem? Przy dzieleniu wymagań na mniejsze części, pomocne może być spojrzenie z kilku perspektyw i próba odpowiedzi na proste pytania:

  • użytkownik – Która rola jest najważniejsza? Czy możemy obsłużyć na początku tylko zwykłego użytkownika? Który typ użytkownika jest najczęściej wykorzystywany?
  • dane – Czy możemy pewne dane odczytać z pliku zamiast z bazy? Czy możemy użyć wygenerowanych danych? Które dane są najistotniejsze, a które opcjonalne?
  • algorytmy – Jak możemy maksymalnie uprościć algorytm? Czy zamiast pisać kompletny algorytm, możemy go zasymulować? Czy możemy użyć Mechanicznego Turka?
  • wydajność – Czy zanim wydajność będzie satysfakcjonująca, funkcjonalność może po prostu zacząć działać? Czy musimy od razu umożliwiać obsługę 100 tys żądań na sekundę? Czy możemy póki co poczekać 5 sekund na wynik zapytania i upewnić się, że wynik (dane) jest dla nas satysfakcjonujący?
  • bezpieczeństwo – Czy moglibyśmy najpierw udowodnić, że nasz pomysł działa, zanim zabezpieczymy się przed każdym możliwym sposobem ataku?
  • interfejs – Czy możemy wyświetlić wynik w konsoli zamiast na stronie internetowej? Czy możemy odczytać wynik z logów? Czy możemy przygotować formularz w czystym HTML’u, zanim zaczniemy zaokrągląć rogi w CSS?
  • ścieżki procesu – Czy możemy obsłużyć najbardziej prawdopodobną scieżkę procesu bez ścieżek warunkowych? Która ścieżka jest najbardziej prawdopodobna? Którą scieżką użytkownicy porusząją się najczęściej?
  • walidacja danych – Czy możemy zrezygnować z walidacji danych w formularzu? Czy możemy zrezygnować z walidacji w Javascripcie? Czy możemy tymczasowo przyjąć, że klient wie co wpisuje?
  • zarządzanie danych – Czy potrzebujemy panel administratora, czy możemy aktualizować dane bezpośrednio w bazie danych? Czy możemy aktualizować pliki z danymi ręcznie? Czy możemy przyjąć domyślne dane i póki co ich nie aktualizować?
  • częstotliwość użycia – Które funkcje są najważniejsze/najczęściej używane przez użytkowników? Które składają się na MVP (ang. Minimum Viable Product)?

Gdy następnym usłyszysz, że „tej historyjki się nie da pociąć na mniejsze części”, zaproponuj spojrzenie na problem z perspektywy powyższej listy.

Fotografia użyta na licencji Creative Commons od użytkownika Ben Sutherland.

Jak utrzymać timebox na Daily Scrum?

Jak utrzymać timebox na spotkaniu?

Jak utrzymać timebox na spotkaniu?

Limity czasowe dla wszelkiego rodzaju aktywności w Scrumie potrafią sprawiać nie lada problem. Szczególnie w nowych zespołach problematyczne jest przeprowadzenie Daily Scruma w ciągu 15-minutowego timeboxa.

Utrzymanie reżimu czasowego może być wyjątkowo trudne w zespołach, dla których praca z timeboxem jest czymś nowym. Przyzwyczajenia wyniesione z kiepsko moderowanych spotkań, również nie pomagają w zrozumieniu idei działania pod presją upływającego czasu.

Na szczęscie istnieje kilka prostych technik, które wspomagają zespół w utrzymaniu 15-minutowego ograniczenia czasowego – oto kilka z nich:

  • regularne informowanie o upływającym czasie – prosta, nieinwazyjna technika, polegająca na uświadamianiu zespołu, że czas upływa nieubłaganie. Scrum Master może co 5 minut o tym przypominać, mówiąc np: „Pięć minut za nami„. Można zwiększać lub zmniejszać częstotliwość informowania, w zależności od przebiegu wydarzeń na spotkaniu
  • limit czasowy na każdego członka zespołu – spotkanie trwa 15 minut, zespół składa się z 10 osób, tak więc każda osoba otrzymuje timebox w wymiarze półtorej minuty na swoją wypowiedź
  • przekazanie swoich obserwacji do zespołu – przez cały czas trwania spotkania, Scrum Master nie zabiera głosu w kwestii upływającego czasu. Po zakończeniu spotkania, które przekroczyło swój limit, przekazuje swoją obserwację do zespołu, mówiąc przykładowo: „Chłopaki, przekroczyliście limit czasu, przewidziany na to spotkanie. Co zrobicie jutro, aby wyrobić się w 15 minut?”
  • parking (ang. Parking Lot) – wymaga sprawnej moderacji ze strony Scrum Mastera. Za każdym razem, kiedy ktoś z zespołu zaczyna odchodzić tematycznie od formuły spotkania lub opowiada zbyt szczegółowo, albo nie na temat, interweniuje Scrum Master: „To interesujący temat, zaparkujmy go i omówmy po spotkaniu, OK?”. Tematy „zaparkowane” można omówić zaraz po Daily Scrumie albo w innym dogodnym terminie.
  • zakończenie spotkania (kontrowersyjne)– równo po 15 minutach Scrum Master mówi: „Panowie, czas nam upłynął. Koniec spotkania.” – licząc oczywiście, że zespół odczyta to zachowanie w pożądany sposób i zmodyfikuje swoje podejście do spotkania

Oczywiście nie ma jednej idealnej techniki, które zapewni sukces. Wszystko zależy od składu oraz doświadczenia zespołu. W dojrzałych zespołach nie ma konieczności kontrolowania przebiegu spotkania, ponieważ każdy z członków zespołu robi to niejako niezależnie, moderując spotkanie we własnym zakresie – w początkowym okresie rozwoju teamu podparcie się technikami może jednak okazać się pomocne.

Utrzymanie limitu czasowego to nie jedyna trudność podczas codziennego spotkania zespołu – poważnym wyzwaniem jest bowiem osiągnięcie celu spotkania, czyli przygotowalnie planu działań na najbliższe 24 godziny.

Udzielenie odpowiedzi przez każdego z członków zespołu na 3 podstawowe pytania ze Scrum Guide to tylko wierzchołek góry lodowej – ale o tym przy innej okazji.

Fotografia użyta na licencji Creative Commons od użytkownika mpclemens.

Prognoza oraz zobowiązanie w Scrumie

Nostradamus

Nostradamus

W połowie 2011 roku miała miejsce aktualizacja Scrum Guide’a. Jedną z większych zmian było zastąpienie słowa „zobowiązanie” na „prognoza” w kontekście zakresu sprintu, ustalanego przez zespół deweloperski.

Zmiana ta jest akceptacją faktu, że tworzenie oprogramowania to skomplikowany i mało przewidywalny proces. Trudno wobec tego wymagać od zespołu, aby zobowiązał się do wykonania konkretnej liczby zadań, wybranych podczas planowania sprintu. To, co zespół może wykonać, to prognoza zakresu, który planuje dostarczyć w kolejnym sprincie.

Pozornie wygląda to jak zwolnienie zespołu z odpowiedzialności. Nic bardziej mylnego – zespół nadal zobowiązuje się do wykonania pracy na poziomie celu sprintu.

Przykład

Załóżmy, że zespół scrumowy tworzy sklep interentowy.

Zespół wraz z Product Ownerem formułuje cel sprintu, który zobowiązuje się zrealizować: „Zwiększenie liczby sposobów dostawy przedmiotów”.

Zespół prognozuje, że będzie w stanie dodać możliwość:

  • odbióru osobistego
  • przesyłki Pocztą Polską
  • usługi kuriera
  • odbioru w Paczkomacie

Nawet jeśli zespół nie dostarczy na koniec sprintu możliwości odbioru w Paczkomacie, a wszystkie pozostałe sposoby odbioru zostaną ukończone, cel sprintu zostanie spełniony – liczba sposobów dostawy zostanie zwiększona.

Podsumowanie

Zgodnie z aktualną wersją Scrum Guide’a, zespół zobowiązuje się zrealizować cel sprintu i prognozuje zakres, który będzie realizował ten cel.

Wspomniana zmiana przekłada ciężar z zakresu sprintu na cel sprintu. Wymaga dobrze przygotowanego Product Backlogu oraz przemyślanych celów na kolejne sprinty.

Fotografia użyta na licencji Creative Commons od użytkownika dierk schaefer.

ACE! Conference 2012 Kraków – „Journey to agility in Allegro Group”

ACE! Conference 2012

ACE! Conference 2012

W czerwcu odbyła się w Krakowie kolejna edycja konferencji ACE! Conference, poświęconej głównie tematyce agile oraz lean.

Konferencja była udana, głównie ze względu na możliwość wymiany doświadczeń z praktykami agile’a z różnych krajów. Dla nieobecnych – za co zdecydowanie należy pochwalić organizatorów – wszystkie prezentacje dostępne są w formie video.

To, czego nie znajdziemy w nagraniach, to oczywiście masa ciekawych tematów poruszonych na sesjach Open Space oraz w kuluarach – i jest to powód, dla którego zdecydowanie warto było fizycznie pojawić się w Krakowie.

Drugiego dnia imprezy, razem z Kubą Szczepanikiem, opowiedzieliśmy historię przejścia z modelu kaskadowego do Scruma w allegro.pl.

Patrząc na nasze polskie podwórko, brakuje przykładów udanych wdrożeń agile’a w dużych firmach. Często można usłyszeć, że agile nadaje się tylko dla małych zespołów, oraz że nie zdaje egzaminu na dużą skalę – co jak sami możecie się przekonać, nie jest prawdą.

Poniżej nasza prezentacja – „Journey to agility in Allegro Group”.

JAKUB SZCZEPANIK/JACEK WIECZOREK – Allegro’s Journey Into Agility from ACE! Conferences on Vimeo.