Jak usprawnić współpracę z zespołem deweloperskim?

Przecież nie tak się umawialiśmy, przycisk logowania miał być po prawej stronie.

Dlaczego tego dokładnie nie przetestowaliście przed wypuszczeniem na produkcję? Dostajemy zgłoszenia o niedziałającym formularzu zamówień od naszych użytkowników.

To tylko przykłady zdań, które mogły, a z dużą dozą prawdopodobieństwa, zostały wypowiedziane podczas spotkań zespołów wykorzystujących zwinne metody wytwarzania oprogramowania. Sam kilkakrotnie miałem (nie)przyjemność uczestniczyć w takich „obwiniających innych” spotkaniach. Przy odrobinie zespołowego wysiłku udało się nam z powodzeniem takie spotkania wyeliminować.

Źródła problemów

Każdy uczestnik spotkania wychodzi z niego z różną interpretacją tego co zostało na nim ustalone. Jednym z cyklicznych spotkań, które bardzo często powoduje dużo “zamieszania” jest planowanie sprintu (ang. sprint planning), podczas którego zespół programistyczny (ang. development team) razem z właścicielem produktu (ang. product owner) planują zakres prac na najbliższy sprint (zazwyczaj dwa tygodnie). Podczas omawiania kolejnych historyjek użytkowników (lub wymagań przedstawionych w innej formie) właściciel produktu odpowiada na wszystkie wątpliwości członków zespołu, którzy starają się dokładnie zrozumieć wszystkie wymagania i oszacować wymagany nakład pracy. Zespół programistyczny zobowiązuje się również do wykonania określonej liczby zadań. Pierwszy poważny problem pojawia się wtedy, kiedy omawiane historyjki użytkownika są słabo przygotowane oraz wymagają wiele dodatkowych wyjaśnień ze strony właściciela produktu. Sprostowania te często nie zostają nigdzie zapisane i zanim spotkanie planistyczne zostanie zakończone, odchodzą w zapomnienie.

Drugi problem wpływający na efektywność całego zespołu występuje, kiedy każdy jego członek w inny sposób definiuje, kiedy dane zadanie jest skończone. Dla programisty będzie to moment, w którym ukończył on programować daną funkcjonalność, dla testera moment, w którym skończył ją testować, a dla właściciela produktu chwila, w której będzie mógł ją zaprezentować klientowi.

W celu wyeliminowania powyższych problemów możemy wykorzystać dwa proste, ale jakże przydatne narzędzia – definicję gotowości (ang. definition of ready) oraz definicję ukończenia (ang. definition of done).

Definicja gotowości

Definicja gotowości pozwala na wyeliminowanie pierwszego z dwóch powyżej przedstawionych problemów. Czym jest owa definicja? Jest to lista kryteriów, które powinny być spełnione przez każdą historyjkę użytkownika, która zostanie wybrana do zakresu sprintu przez zespół. Lista ta będzie inna dla każdego zespołu, a jej elementy powinny zostać wspólnie uzgodnione przez wszystkich członków zespołu scrumowego. Bardzo możliwe (a nawet jest to wskazane), że z upływem czasu lista ta będzie modyfikowana, np. rozszerzana o bardziej szczegółowe kryteria na podstawie doświadczeń zespołu (empiryzm).

Należy podkreślić, że praca nad konkretną historyjką użytkownika, celem spełnienia przez nią kryteriów definicji gotowości to zadanie nie tylko właściciela produktu, ale całego zespołu scrumowego. Planowanie sprintu oraz pielęgnacja backlogu (ang. backlog grooming/refinement) to idealne momenty, żeby wspólnie “dopracować” oraz lepiej zrozumieć zakres wcześniej stworzonych historyjek.

Definicja ukończenia

Kiedy element Backlogu Produktu albo Przyrost jest określany jako „Ukończony”, wszyscy muszą rozumieć, co to właściwie oznacza.

Źródło: Scrum Guide

Definicja ukończenia to również lista pewnych kryteriów, która powinna zostać opracowana wspólnie przez cały zespół. W odróżnieniu od definicji gotowości pozwala ona na wyeliminowanie drugiego z powyższych problemów poprzez jednoznaczne określenie kiedy praca nad danym elementem backlogu została zakończona. Tak samo jak w przypadku definicji gotowości, lista ta z upływem czasu powinna ewoluować. Retrospektywa sprintu jest dobrym momentem, żeby poświęcić chwilę czasu i sprawdzić czy któraś z definicji nie powinna zostać uaktualniona.

Zauważ, że każdy kolejny element powyższej listy zwiększa czas potrzebny na ukończenie pracy nad daną funkcjonalnością. Jednak na podstawie własnych doświadczeń bez wątpienia mogę stwierdzić, że im bardziej doprecyzowana definicja ukończenia tym mniej błędów na środowisku produkcyjnym co bezpośrednio przekłada się na stopień zadowolenia użytkowników produktu.

Podsumowanie

Słabo przygotowane historyjki użytkownika oraz brak wspólnej definicji ukończenia zadania to problemy, z którymi boryka się niejeden zespół wykorzystujący zwinne metody wytwarzania oprogramowania. Definicja gotowości i definicja ukończenia to narzędzia, których wykorzystanie pozwala na usprawnienie pracy całego zespołu. Pierwsza z nich pozwala na uniknięcie potencjalnych nieporozumień i konfliktów pomiędzy właścicielem produktu a zespołem programistycznym podczas trwania sprintu poprzez przygotowanie dobrze opisanych historyjek jednoznacznie zrozumiałych przez wszystkich członków zespołu.

Definicja gotowości pozwala na wyeliminowanie różnych interpretacji ukończenia zadania wśród członków zespołu pełniących różne role. Im bardziej precyzyjna tym większa szansa na znaczne zredukowanie liczby błędów wykrytych na środowisku produkcyjnym.

Co więcej, dokładniej przygotowane historyjki użytkownika oraz jednoznaczna definicja ukończenia wśród członków zespołu pozwalają na bardziej dokładne estymaty podczas estymowania przyszłych zadań, ponieważ członkowie zespołu lepiej rozumieją zakres danej historyjki oraz wiedzą jaki zakres prac musi zostać wykonany. Programiści biorą pod uwagę nie tylko czas potrzebny na zaprogramowanie danej funkcjonalności, ale również czas potrzebny na napisanie testów przez testerów.

Rekomenduję wdrożenie obu definicji w Twoim zespole, jeżeli napotykacie na problemy wspomniane na początku artykułu. Pamiętaj jednak, że zdefiniowanie listy kryteriów to dopiero początek. Równie ważne jest pilnowanie siebie nawzajem, żeby ich przestrzegać oraz modyfikować na podstawie zdobytych doświadczeń. Warto, żeby obie listy były w łatwy sposób dostępne dla każdego członka zespołu, możecie je wydrukować i powiesić na tablicy blisko waszych biurek. Powodzenia!

Jeżeli nie wiesz czym są testy regresyjne albo środowisko pre-produkcyjne może zainteresuje Cię nasz Internetowy Kurs Podstaw IT. Czasami fajnie zabłysnąć wśród programistów 😉