Deadline w Scrum

Czy możemy pracować na ściśle określony deadline w Scrum?

Prawidłowa odpowiedź na tak postawione pytanie powinna brzmieć: Oczywiście, iż tak - każdy sprint ma swój deadline, zwanym również Sprint Review, na którym prezentujemy przyrost produktu. Byłaby to jednak odpowiedź nieco wymijająca:-) Przyjrzyjmy się jak najlepiej podejść do pracy na konkretny termin, w podejściu zwinnym.

Terminy są w naszym życiu i w biznesie czymś naturalnym i nie możemy udawać, iż ich nie ma. Zdarza się, iż mamy komfort pracować w warunkach bez ściśle określonego terminu. Częściej jednak takową datę posiadamy. Powodów może być wiele. Nasza aplikacja może być ściśle powiązana z obowiązującym prawem, które zmienia się określonego dnia. Możemy mieć produkt dedykowany konkretnemu zdarzeniu osadzonemu w czasie, jak choćby konferencja lub zdarzenie sportowe. Powód może być też bardziej prozaiczny - nasz inwestor ma po prostu ograniczony budżet. Albo więc wydamy na rynek produkt w określonym czasie i zaczniemy zarabiać, albo się pakujemy.

Jest to więc poniekąd zaprzeczenie tezy, iż to Product Owner decyduje o wypuszczeniu produktu na rynek. Owszem decyduje, ale pod warunkiem, iż zdarzy się to przed danym terminem. Należy więc dążyć do sytuacji, aby posiadać wartościowy produkt, tzw. Minimum Marketable Product (więcej o MMP znajdziesz tutaj) przed wyznaczoną datą.

Co możemy zrobić, aby uzyskać wartościowy produkt przed terminem?

Bazuj na empiryzmie

Zaplanujmy co i kiedy zrobimy. Powinniśmy to jednak zrobić inaczej aniżeli w tzw. tradycyjnym podejściu, gdzie planowanie odbywa się przed rozpoczęciem prac nad produktem, a często choćby przed uformowaniem zespołu. Scrum bazuje na empiryzmie i to właśnie dopiero na podstawie zdobytej, realnej wiedzy możemy kreślić wstępne plany. jeżeli więc mówimy o zupełnie nowym produkcie powinniśmy pozwolić zespołowi na dostarczenie kilku pierwszych przyrostów (2-4 sprinty).

W ten sposób uzyskujemy naszą prędkość (ang. Velocity), którą możemy uwzględnić w dalszych kalkulacjach.

Dziel i rządź

Pojedynczych wycen najlepiej dokonywać na jak najmniejszych kawałkach wymagań. jeżeli mamy zestaw większych funkcjonalności, na przykład typu Epic, najlepszą drogą jest ich podział na mniejsze elementy, na przykład User Stories i relatywne szacowanie wielkości każdej z nich osobno.

Rozbicie większych wymagań na mniejsze składowe daje nam również możliwość wybiórczej implementacji najbardziej wartościowych z nich. Powinniśmy dążyć do jak najszybszego uzyskania całej, najprostszej ścieżki przejścia użytkownika (ang. Happy Path). Niekoniecznie wdrażając po drodze pełnowartościowe funkcjonalności z wszystkimi dodatkami i bajerami. Uzyskujmy w ten sposób pewien minimalny produkt (ang. Minimum Viable Product, więcej o MVP znajdziesz tutaj), możliwy już na wczesnym etapie do wykorzystania lub przynajmniej przetestowania przez końcowych użytkowników.

Analiza, zrozumienie i dekompozycja wymagań jest bardzo trudnym procesem. Na pomoc mogą nam przyjść techniki typu Event Storming (więcej na temat Event Storming w serii artykułów tutaj) lub User Story Mapping.

Waliduj założenia

Każdą funkcjonalność, czy to zleconą pierwotnie przez interesariuszy, czy to wymyśloną przez nas samych, najlepiej przetestować (przed adekwatną implementacją) z końcowymi użytkownikami naszego produktu. W ten sposób upewniamy się czy założenia, które poczyniliśmy, co do samej podstawowej koncepcji jak i kształtu danej funkcji mają sens. Przy odrobinie szczęścia możemy również dowiedzieć się, które elementy są najbardziej doceniane, a bez których użytkownicy będą mogli się obejść.

Sposobów na sprawdzenie naszych pomysłów jest wiele. Jednym z najlepszych z nich są makiety bądź interaktywne prototypy. W najprostszej wersji może to być forma wywiadu bądź ankiety.

Bądź zawsze gotowy

Traktujmy każdy sprint jakby to miał być ten ostatni. Innymi słowy, gotowość produktu, spełnienie po każdym sprincie Definition of Done (więcej o DoD tutaj) jest niezmiernie istotne. Wykonujmy wydania na środowisko produkcyjne lub pre-produkcyjne najczęściej jak możemy, najlepiej po każdym sprincie. Unikniemy w ten sposób przykrych niespodzianek pod koniec terminu, kiedy mogą wystąpić niespodziewane problemy, na przykład z technicznym wykonaniem wydania lub nieprawidłową konfiguracją produkcji. Jednocześnie śpimy spokojnie, iż praktycznie w każdej chwili, jesteśmy gotowi na prawdziwe uruchomienie naszego produktu.

Zwróć uwagę na zewnętrzne zależności

Innym aspektem, na który chciałbym zwrócić uwagę i który, moim zdaniem, jest największą zmorą przy planowaniu są zewnętrzne zależności. Z własnego doświadczenia wiem, iż to głównie one są źródłem opóźnień i niedotrzymywania terminów. jeżeli proces który automatyzujemy wymaga integracji z zewnętrznym system, powinniśmy rozpoczynać jej wykonanie jak najwcześniej. Być może brzmi to jak oczywistość, ale nadspodziewanie często spotykam się z sytuacją, gdzie zespół pracuje w swoim świecie, symulując integracje zewnętrzne i zostawiając zestawienie realnego połącznia na sam koniec. A na końcu okazuje się, iż struktura danych w rzeczywistym systemie zewnętrznym jest jednak trochę inna niż zakładaliśmy, iż protokół wymiany danych działa inaczej niż w dokumentacji, lub iż w zewnętrznym systemie musi być również dokonana jakaś zmiana, aby współpracował z naszym (opcja najgorsza).

Przechodząc do sedna

Metodyki zwinne jak najbardziej mogą być użyte do pracy na konkretny termin. W końcu, całą ideą framework'ów typu Scrum czy Kanban jest maksymalizacja wartości dostarczanej użytkownikowi w jak najkrótszym czasie. I tu właśnie dochodzimy do sedna. To co naprawdę jesteśmy w stanie powiedzieć potencjalnemu inwestorowi to, iż w danym czasie dostarczymy najbardziej wartościowy produkt, jak to tylko możliwe. Natomiast, niekoniecznie będzie on zawierał funkcjonalności A, B i C, które interesariusz ma w głowie na początku. Wraz z upływem czasu, rozbiciem wymagań, odkrywaniem domeny oraz realnych potrzeb użytkowników może się okazać, iż w wyznaczonym czasie zrealizujemy całą funkcje A i tylko połowę B, bo druga połowa okaże się zbędnym wodotryskiem. A wymagania C w ogóle nie zrealizujemy, bo okaże się zupełnie pozbawione sensu. Za to zrealizujemy funkcjonalność D, której interesariusz nie miał w głowie na początku, ale na podstawie rozmów z użytkownikami, dowiemy się, iż to właśnie ona jest najbardziej oczekiwana.

Zwinności nie należy więc utożsamiać z brakiem ograniczeń. Można pracować w sposób zwinny posiadając ograniczenia czasowe, jak i budżetowe czy ludzkie.