Terminy w Scrum 

Często słyszymy, że idea zwinności, agile’owych metodyk i tego „łatwego, lekkiego podejścia do tworzenia oprogramowania” jest super. Ale świat wygląda trochę inaczej i każdy realizowany przez nas projekt jest ograniczony czasowo. Powstaje więc pytanie: czy istnieje coś takiego jak terminy w Scrum?

„Bo klient chce wiedzieć…”

Ktoś, kto płaci nam za naszą pracę chce wiedzieć, kiedy zamówiona funkcjonalność będzie gotowa. Wszyscy wiemy, jak wygląda to w klasycznym podejściu. Jeszcze przed rozpoczęciem właściwych prac, a zaraz po zebraniu wymagań powstaje plan wdrożenia. Wraz z nim powstają dwa cenione przez każdego Project Managera artefakty: WBS (ang. Work Breakdown Structure) oraz wykres Gantta.

Korzystając z tych dwóch technik określone zostały terminy wdrożenia funkcjonalności. Ale w jaki konkretnie sposób zostały oszacowane? Lubimy mówić o tej metodzie, że jest „ekspercka”, chociaż lepszym określeniem jest „myląca się”. Ci, którzy pracowali w oparciu o takie „harmonogramy” doskonale wiedzą o czym mówię. Im większy projekt, tym mniej mają one wspólnego z rzeczywistością.

Podejście iteracyjne

Na drugim biegunie organizacji projektów informatycznych stoi podejście iteracyjne. Lekkie, pozbawione nadmiarowej dokumentacji w postaci planowanych terminów i harmonogramów. Jedynymi z góry znanymi datami są początek i koniec każdego ze Sprintów. Bardziej życiowo, jeśli pracujemy nad dużym projektem albo w dużej firmie, znamy także możliwe daty wydań.

Charakterystyczne dla podejścia iteracyjnego jest to, że nie jesteśmy w stanie wprost odpowiedzieć na pytanie o termin dostarczenia konkretnej grupy funkcjonalności, np. wyrażonych jako Epic. Możemy mieć do czynienia z sytuacją, w której funkcjonalność została podzielona na kilka wymagań, a każde z nich może być dostarczane w innej iteracji. Co za tym idzie, na pytanie o termin dostarczenia funkcjonalności (Epica) możemy odpowiedzieć pytaniem „Której jego części?”.

Jak dobrze pamiętamy, każde wymaganie opisane np. jako User Story powinno dostarczać naszemu interesariuszowi wartości biznesowej. Te poszczególne wymagania powinny być potencjalnie używalne na środowisku produkcyjnym i powodować zadowolenie naszego odbiorcy.

„Rozumiem, ale na kiedy to będzie?”

„Przyciśnięci” przez klienta będziemy musieli udzielić odpowiedzi. Zrobi to najczęściej Product Owner, który analizując Product Backlog policzy, na kiedy gotowa będzie wskazana przez klienta funkcjonalność. Przeanalizujmy następujący dialog:

Klient: Drogi Product Ownerze, nasza konkurencja właśnie wdraża nową usługę. Na kiedy gotowa będzie nasza odpowiedź?

Product Owner: Analizując obecny stan Product Backlogu, przy aktualnych priorytetach, nasza funkcjonalność będzie gotowa do potencjalnego wdrożenia na koniec przyszłego Sprintu!

Product Owner nie może jednoznacznie stwierdzić, że funkcjonalność, nad którą pracuje Zespół Deweloperski będzie gotowa w środę, w pierwszy tygodniu Sprintu. To Zespół Deweloperski odpowiedzialny jest za przekształcenie elementów Backlogu Sprintu w działające oprogramowanie, czyli Przyrost. Rozdzielczość, którą posługuje się Product Owner to zawsze Sprint, który może trwać od tygodnia do czterech.

Co wziąć pod uwagę?

Rozmawiając o terminie dostarczenia funkcjonalności powinniśmy wziąć pod uwagę kilka aspektów: długość Sprintu, Velocity (prędkość) naszego zespołu, wielkość tejże funkcjonalności oraz prawdopodobieństwo zmiany priorytetów. Na podstawie tych danych będziemy w stanie bardzo łatwo wskazać spodziewany termin ukończenia prac. Niezależnie od tego czy mówimy o pojedynczym wymaganiu czy całym zestawie funkcjonalności.

W tym miejscu nie możemy nie wspomnieć o jednej bardzo istotnej rzeczy. Wszystko się zmienia, w tym także priorytety naszego klienta i wyceny wymagań. Backlog Produktu jest wiecznie żywy. Powoduje to, że mówiąc o terminie dostarczenia mówimy o prawdopodobnej dacie, wyliczonej na podstawie aktualnie posiadanych informacji. W przypadku zmian, przesunięciu ulegnie także data wdrożenia danej funkcjonalności.

Terminy w Scrum jak najbardziej istnieją!

W metodykach zwinnych jak najbardziej mówić możemy o datach wdrożenia. Nie są one stałe, ale wyliczane na podstawie posiadanych przez nas na daną chwilę informacji. Pytanie tylko, czy te określone np. w WBS utworzonym na początku projektu są dokładniejsze?

Metodyki zwinne dają nam przewagę. Poprzez wykorzystanie iteracyjnego podejścia planujemy mniejsze części funkcjonalności. Nie oszukujemy się w ten sposób, że jesteśmy w stanie przewidzieć odległą przyszłość. Interesuje nas to, co dzieje się teraz.

Na pytanie o termin dostarczenia, zawsze możemy też odpowiedzieć „Wdrożenie pełnej funkcjonalności nastąpi za X czasu, ale na koniec najbliższego Sprintu możemy wdrożyć najpotrzebniejsze na dzień dzisiejszy wymaganie.” Mowa tu oczywiście o MVP.

Niestety, sytuacja będzie wyglądała zupełnie inaczej, gdy mamy z góry ustalone terminy wdrożeń i to nie Product Owner decyduje kiedy dana funkcjonalność trafi na produkcję. Ale to temat na zupełnie inny tekst…