Iterate

Wdrażanie Scrum – kolejne iteracje

W punktach poniżej, przedstawiam wybrane zagadnienia dotyczące kolejnych iteracji.

• Wyznaczanie liczby punktów możliwych do zrealizowania w kolejnej iteracji w przypadku, gdy znacznie zmienia się dostępność członków zespołu.
  
  Dostępność niektórych członków zespołu w kolejnych iteracjach była bardzo zmienna. Wynikało to z ich stosunku pracy oraz innych uwarunkowań. Na czas zespołu dostępny w iteracji wpływ mają także urlopy i inne nieobecności, takie jak na przykład wyjazdy na konferencje. W celu uwzględnienia tych czynników podczas planowania iteracji, stworzony został współdzielony arkusz kalkulacyjny, w którym notowany był plan obecności każdego z deweloperów w kolejnym Sprincie. Na podstawie tych informacji, oraz informacji o zakończonych iteracjach. wyliczana była orientacyjna liczba Story Points, jaką zespół może zrealizować podczas kolejnego sprintu. Arkusz ten zawierał także dwa wykresy. Pierwszy przedstawiał liczbę Story Points zrealizowaną w kolejnych Sprintach, a drugi liczbę Story Points realizowaną w przeliczeniu na jeden dzień pracy jednego dewelopera. Wartość przedstawiona na drugim z tych wykresów jest do pewnego stopnia niezależna od stanu nieobecności deweloperów i z tego względu pomocna była w omawianej estymacji.


• Pomijanie tworzenia testów w przypadku przyjęcia zasady, że pisane są one dopiero po zakończeniu prac nad kodem.
  
  W projekcie tym testowanie oparte było o testy black box i white box, które tworzone były po napisaniu testowanego kodu. W tym przypadku istotne okazało się, aby konieczność stworzenia testów wydzielać jako osobne zadania. W przeciwnym przypadku praca ta bywała pomijana. Potencjalnie wykorzystanie TDD mogłoby zapewnić większe pokrycie kodu testami oraz wpłynąć pozytywnie na architekturę, przez co aplikacja mogłaby być łatwiejsza w testowaniu i długoterminowym utrzymaniu. Zespół jednak nie posiadał doświadczenia w pracy w ten sposób. Nie było także pozytywnych sygnałów w tej sprawie ze strony zarządu i klienta.


• Dodawanie do Sprintu nowych User Stories w przypadku ukończenia zaplanowanych.
  
  Jako, że nowe User Stories tworzone i estymowane były w trakcie trwania projektu, to w przypadku tym sprawdziło się stworzenie Sprint Backlog drugiego poziomu. Backlog ten zawierał User Stories, które w przypadku mniej dynamicznie tworzonego Backlog byłyby na jego szczycie, czyli doprecyzowane, omówione, wyestymowane i o wysokim priorytecie. W przypadku gdy w trakcie iteracji okazywało się, że efektywność zespołu pozwoliła zrealizować zadania szybciej, pozwalało to wciągnąć kolejne zadania do iteracji i zrealizować więcej funkcjonalności. Rozwiązanie takie nie wymaga konieczności zwoływania spotkania z Product Ownerem i przerywania Sprintu.


• Sugestie osób nie realizujących funkcjonalności dotyczące estymacji zadań.
  
  Podczas pierwszych spotkań Sprint Planning zdarzały się sytuacje, w których Tech Product Owner pośrednio wywierał presję na proces estymacji. Przykładem jest wyrażanie opinii podczas estymacji. Komentarze wyrażane w trakcie estymacji oscylowały najczęściej wokół fraz „to zadanie jest łatwe”, „to będzie chwilka” lub „do zrobienia w 5 minut”. Takie uwagi mogą wpływać na estymację i w efekcie zmniejszać jej dokładność i przydatność. Problemem w tym przypadku był fakt, że osoba wyrażająca opinię nie brała bezpośredniego udziału w pracach, a więc nie była odpowiedzialna za dotrzymanie terminu i jakość. Z drugiej strony, był to jeden z reprezentantów klienta, który orientował się w zagadnieniach technicznych i z tego powodu właśnie pomagać miał Product Ownerowi. W celu rozwiązania tej sytuacji przeprowadziliśmy dyskusję wewnątrz zespołu dotycząca tego problemu. Estymacja zespołu zawsze miała na celu możliwie najdokładniejsze określenie wielkości zadania. Nigdy jej celem nie było estymowanie nadmierne, gdyż, pomijając kwestie etyczne, może to mieć negatywne skutki w kolejnych iteracjach. Postanowiliśmy więc, że opinię Tech Product Ownera dotyczące estymacji będziemy traktować z przymrużeniem oka. Scrum Master przedstawił też Tech Product Ownerowi problemy jakie jego opinie mogą powodować. Nadmiernie optymistyczna estymacja w połączeniu z naturalną chęcią zespołu, aby zakończyć wszystkie User Stories w iteracji doprowadzić może do pogorszenia jakości produktu poprzez wprowadzenie długu technologicznego. Poza tym, celem estymacji jest uzyskanie rzeczywistego a nie życzeniowego planu. Plan zakładający, iż zespół wykona w czasie iteracji 10 razy więcej punktów niż jego dotychczasowe Velocity może i ładnie wygląda, ale czy posiada jakąkolwiek wartość? Podczas kolejnych spotkań Tech Product Owner starał się minimalizować swój wpływ na estymację, pozostając przydatnym ekspertem w zakresie domeny i rozwiązań technicznych. Takie przyzwyczajenia trudno jest jednak w pełni wyeliminować. Z tego względu, podczas kolejnych retrospektyw kwestia ta była często poruszana, dzięki czemu wpływ ewentualnych sugestii był dalej ograniczany.


• Ograniczenie dostępu do zasobu a nieobecność osoby posiadającej ów dostęp.
  
  Jedną z propozycji Scrum Mastera było wykorzystanie w projekcie serwera Continuous Integration. Po przedstawieniu zalet takiego rozwiązania zespołowi oraz Product Ownerowi postanowiono, że w czasie jednego z pierwszych Sprintów skonfigurowany zostanie serwer CI Hudson. W późniejszym czasie okazało się, że zarząd wolał, aby do serwera na którym działał Hudson dostęp miał tylko jeden z członków zespołu. Problemem był jednak fakt, że osoba ta pracowała tylko na część etatu i nie zawsze była obecna. Tymczasem Tomcat, na którym uruchomiony był Hudson, a także dwie wersje rozwijanej aplikacji, od czasu do czasu przestawał działać ze względu na problem z brakiem pamięci. W przypadku takim zarówno Hudson jak i aplikacje stawały się niedostępne dla członków zespołu, Product Ownera oraz klienta. Dopiero interwencja osoby posiadającej dostęp do serwera przywracała sytuację do normalności. Aby zapobiec tej sytuacji wszyscy członkowie zespołu zostali poinformowani, w jaki sposób uzyskać dostęp do serwera i uruchomić ponownie serwer Tomcat. Byłoby to jednak rozwiązanie tymczasowe, zmniejszające jedynie skalę problemu. W celu jego całkowitego rozwiązania zaplanowana została zmiana konfiguracji serwerów aplikacji, na których uruchomiony był Hudson oraz wersje deweloperska i testowa tworzonej aplikacji. Jej celem miało być też zapewnienie możliwości prawdziwej ciągłej integracji. Wcześniej, ze względu na opisany problem, aplikacja budowana była tylko raz dziennie. Powodowało to na przykład możliwość pobrania z repozytorium nie kompilującego się kodu lub wersji aplikacji z nieaktualnymi testami.


• Przełączanie się zespołu pomiędzy zadaniami związane z komunikacją z Product Ownerem.
  
  Innym problemem jaki można było zauważyć było przełączanie się członków zespołu między zadaniami. Zjawisko to w jednym z przypadków było szczególnie nasilone. Jego powodem było częste zgłaszanie uwag Tech Product Ownera dotyczących jednego zadania. Ich treścią była kwestia organizacji GUI aplikacji. Okazało się, że nastąpiło nieporozumienie w kwestii konstrukcji jednego jego elementu. Tech Product Owner po zauważeniu problemu poinformował o nim zespół i powiedział, aby nie kontynuować pracy związanej z tym elementem. W tym momencie praca dotycząca tego elementu była już jednak zakończona. Z tego względu, zespół postanowił ,że zachowa efekty tej pracy do najbliższego Sprint Review, kiedy będzie można sprawę dokładnie przedyskutować, gdyż jej wyrzucenie w tym momencie nie poskutkowałoby już oszczędnością czasu. Sposób działania GUI sugerowany przez Tech Product Ownera nie był prosty w realizacji w oparciu o wykorzystywane rozwiązanie warstwy prezentacji. Ściśle mówiąc, w momencie zasygnalizowania tej kwestii zespół nie znał możliwości jego rozwiązania. Tech Product Owner naciskał jednak, aby rozwiązania tego poszukiwać i podkreślał wagę tej części GUI. W wyniku tego, większa część zespołu przestała pracować nad swoimi zadaniami i rozpoczęła na ten temat dłuższą dyskusję. Jeden z deweloperów poświęcił dodatkowo niemałą ilość czasu na próby implementacji kolejnych koncepcji przedstawianych przez zespół i Tech Product Ownera. Niestety, żadna z nich nie spełniała wymagań Tech Product Ownera. Rozmowy telefoniczne dotyczące tego problemu, prowadzone przez głośniki w pokoju zespołu, nie przestały się jednak powtarzać. Dekoncentrowały one zespół, nie zwiększając w żadnej mierze prawdopodobieństwa znalezienia rozwiązania problemu. Prace, które powinny być w tym czasie prowadzone, były przerywane. Scrum Master skontaktował się więc z Product Ownerem i opisał mu tę sytuację. Zaproponował, aby sprawę tę szczegółowo omówić podczas Sprint Review. Do tego czasu, zespół lub Tech Product Owner będzie miał możliwość znalezienia rozwiązania w ewentualnej wolnej chwili, bez negatywnych skutków dla prowadzonych prac. Przy okazji przedstawione zostało też zjawisko spadku wydajności, związane z przełączaniem się pomiędzy zadaniami, oraz zmiany kontekstu pracy i zasady Scrum, które mają je minimalizować. Propozycja ta została przyjęta. Zespół i Product Owner postanowili też dokładniej omówić założenia GUI, aby uniknąć podobnych nieporozumień w przyszłości. Wspomnieć można jeszcze, że w późniejszym terminie okazało się, że ta część GUI nie posiada aż tak wielkiej wagi biznesowej jak mogło się uprzednio wydawać.


• Realizacja zależnych od siebie User Stories w trakcie jednej iteracji.
  
  Podczas jednej z sesji planowania okazało się, że User Stories o wysokich priorytetach są ze sobą mocno powiązane. Były pomiędzy nimi wzajemne zależności. W takim przypadku trzeba pamiętać, że dobra architektura projektu oraz oddzielenie się interfejsami pozwalające w miarę bezkolizyjnie rozwijać taką funkcjonalność, zmniejsza te zależności jedynie do pewnego stopnia. Już sama praca z systemem kontroli wersji wymaga więcej czasu, który poświęcić trzeba na łączenie modyfikowanego kodu. Będąc świadomym tego faktu zespół uzgodnił z Product Ownerem, że weźmie do sprintu jedynie część spośród tych powiązanych zadań. Zgodnie z przewidywaniami, praca przy tych US wymagała więcej czasu niż w przypadku, gdyby były one rozwijane w kolejnych iteracjach. Zespołowi udało się jednak zrealizować zadeklarowaną funkcjonalność. Najprawdopodobniej, w przypadku, gdyby obawiał się przedstawienia Product Ownerowi swoich obaw i zdecydował się na równoczesną realizację wszystkich powiązanych zadań to zakończenie takie nie byłoby możliwe. W przypadku takim suma punktów zrealizowanych podczas takiego Sprintu byłaby znacznie niższa od tej jaką zespół przeważnie realizuje, a więc dostarczono by mniej funkcjonalności w tej samej cenie.


• Aktualizacja Task Board a godziny pracy członków zespołu.
  
  Na początku pracy jednemu z bardziej doświadczonych programistów zdarzało się stosunkowo często nie aktualizować Task Board. Programista ten pojawiał się w pracy zaraz przed Daily Scrum. Inny, młodszy programista, który przychodził do pracy znacznie wcześniej, często nie mógł być pewien, czy zadanie, które wygląda na nierozpoczęte, nie jest już w rzeczywistości realizowane przez pierwszą z wymienionych osób. Zwyczaje panujące wewnątrz zespołu pozwoliły na szczęście na to, aby młodszy programista przedstawił ten problem starszemu programiście podczas Daily Scrum. Brak barier komunikacyjnych umożliwił rozwiązanie tego problemu bez zewnętrznej ingerencji. Dobrą praktyką jest ciągłe wyciąganie na wierzch pojawiających się problemów i ich rozwiązywanie. Jeśli pozostają one nieporuszone, to w efekcie nadal blokują pracę zespołu, a nawet mogą się pogłębiać. W omawianym przypadku poczynione zostały też ustalenia dotyczące zasad pracy zespołu. Task Board miał być aktualizowany w miarę możliwości na bieżąco oraz obowiązkowo przed wyjściem z pracy. Zostało to zapisane na tablicy jako jedna z reguł zespołu.


• Wykorzystanie „ściągi” podczas estymacji relatywnej zadań.
  
  Podczas realizacji projektu zdarzało się, że zespół miał trudność z estymacją User Story pomimo szczegółowego jej przedyskutowania. Gdy problem ten został poruszony podczas jednej z retrospektyw, jeden z członków zespołu zaproponował, aby przejrzeć User Stories zrealizowane w poprzednich iteracjach i dla każdej wartości estymacji wybrać jedno zadanie które najlepiej reprezentować będzie tę wartość. Zestawienie to, oparte o rzeczywiste dane, było później z powodzeniem wykorzystywane. Trzeba jednak pamiętać, że wykorzystanie takiego zestawienia powinno nastąpić dopiero po szczegółowym omówieniu zadania. W przeciwnym przypadku można doprowadzić do przedwczesnego zakończenia dyskusji i w efekcie nie wziąć pod uwagę istotnych spostrzeżeń.


• Niezakończone zadania i wpływ zarządzania nimi na Velocity i jakość produktu.
  
  Nie każda iteracja kończyła się zamknięciem wszystkich User Stories. Czasem zdarzało się że jakieś zadanie nie zostało zrealizowane. W takim przypadku, przenoszone było ono z powrotem do Backlog i mogło być przypisane do kolejnego Sprintu. Bardziej interesującym przypadkiem jest sytuacja, w której praca nad zadaniem została rozpoczęta, ale nie można go uznać za zakończone. Czy w takim przypadku także należy przyjąć, iż punkty tego zadania nie zostały zrealizowane i przenieść je z powrotem do Backlog? Czy lepszym rozwiązaniem jest podział zadania i liczby punktów proporcjonalnie do stanu jego wykonania na część zakończoną i niezakończoną? Na pierwszy rzut oka drugie z opisanych podejść wydaje się rozsądniejsze. Zadanie to wymagało przecież w aktualnej iteracji pewnego nakładu pracy zespołu, a jego dokończenie w kolejnym sprincie powinno zająć mniej czasu niż jego realizacja od zera. Odpowiedź na to pytanie zależy oczywiście od konkretnego przypadku. Przeważnie jednak zalecamy wykorzystanie pierwszego z przedstawionych rozwiązań. Pamiętać trzeba, że Story Points i oparta o nie wartość Velocity to tylko pewna estymacja. Z tego też względu, technika estymacji Planning Poker nie umożliwia przyznawania User Story dowolnej wartości, a jedynie jej wybór spośród pewnego predefiniowanego zbioru wartości, które odpowiadają kubełkom na zadania mniejsze i większe. Jeśli miara Velocity oparta jest o średnią z kilku Sprintów, to te drobne nierówności, wynikające z przeniesienia wszystkich Story Points nie ukończonego zadania do następnego Sprintu, zostaną wygładzone. W aktualnej iteracji zrealizowane zostanie mniej, a w kolejnej więcej punktów. Podejście oparte o podział User Story i przypisanie części jej punktów do aktualnej iteracji może natomiast wywołać pewien negatywny efekt uboczny. W wyniku takich działań Velocity może zostać fałszywie zawyżone. W efekcie, w kolejnych iteracjach zespołowi może brakować czasu na poprawną realizację zwiększonej liczby zadań, co może skutkować wprowadzaniem długu technologicznego. W dalszej perspektywie może to wpłynąć na rzeczywiste zmniejszenie efektywności zespołu. Abstrahując już od rozpatrywanego zagadnienia dodam jeszcze, że naszym zdaniem Velocity przedstawiana powinna być nie w postaci wartości, lecz przedziału. Dostępna wtedy może być jej estymacja pesymistyczną, optymistyczna i średnia, oparte odpowiednio o poprzednie wartości najniższe, najwyższe, i wszystkie.


• Brak propozycji zmian w trakcie retrospektyw.
  
  Podczas jednej z sesji Sprint Retrospective zdarzyło się, że członek zespołu stwierdził, że zespół nie ma się już nad czym zastanawiać, gdyż wszystko świetnie idzie. Nastąpiło to mniej więcej w momencie, w którym zespół opanował podstawowe praktyki Agile i zaczął czerpać korzyści z pracy za pomocą Scrum. Osoba bardziej doświadczona w tym temacie potrafiłaby oczywiście znaleźć jeszcze wiele rzeczy które mogłyby ulec poprawie. Samo wdrożenie Agile Software Development nie kończy całości procesu. Zgodnie z filozofią Kaizen, należy stale dążyć do optymalizacji sposobu pracy. W przeciwnym przypadku, w pewnym momencie można zacząć się cofać. Wpływa to też na zmniejszenie prawdopodobieństwa popadnięcie w rutynę i wypalenia zespołu.