Definition of Almost Done, czyli „prawie skończone” zadania 

Jak głosi stary dowcip, na wielu scrumowych tablicach kolumny nazywają się „to do, in progress, done, really done, this time it’s tested & done” oraz „we just need to polish it next Sprint”. Skąd bierze się problem z „almost done”, czyli rzeczami oznaczanymi jako „prawie skończone”?

Definition of Almost Done

Czym jest „prawie skończone” zadanie? W ramach naszych szkoleń Scrum i agile wypracowaliśmy sobie pewne podejście, które zawsze i wszędzie identyfikuje rzeczy „almost done”. Gdy Zespół Deweloperski deklaruje, że dane wymaganie jest gotowe, wystarczy zakomunikować mu, że jutro ląduje ono na środowisku produkcyjnym i jest udostępniane wszystkim klientom.

Jeżeli usłyszymy „okej”, to wszystko jest w jak najlepszym porządku. Jeśli natomiast zapadnie niezręczna cisza lub rozlegnie się zgiełk przekrzykujących się osób („Nie no, jeszcze musimy dorobić to i tamto!”, „Instrukcja wdrożeniowa jest jeszcze niegotowa!”), to mamy absolutną pewność, że temu zadaniu daleko do „done”.

Oczywiście ten trick w końcu przestanie działać. Dlatego zanim to nastąpi, warto zastanowić się jaka motywacja przyświeca zespołowi, który oddaje nieskończone rzeczy. Zwykle w takich przypadkach nie ma samoorganizacji, a co za tym idzie – odpowiedzialności. Zespół Deweloperski nie czuje, że tworzone oprogramowanie jest „ich”, więc ogranicza swoją rolę do bycia wyrobnikami.

Może to też wynikać z kiepskich relacji z Product Ownerem, bądź przekazywaniem wymagań w postaci ściśle sprecyzowanych zadań. Skoro nie ma żadnego pola do manewru w kwestii realizacji, to nie ma co się zastanawiać się, jak najlepiej zaspokoić potrzeby użytkowników. W takim wypadku ludzie podchodzą do pracy mechanicznie. Nikt się nie zastanawia co jest „done”, a co nie.

Kolejnym powodem może być brak zrozumienia iteracyjnego sposobu wytwarzania oprogramowania i tego co znaczy CD, czyli Continuous Delivery. A tak naprawdę przyczyn takiego stanu rzeczy może być wiele. Tu już rola Scrum Mastera, jako osoby odpowiedzialnej za proces wytwórczy, żeby dotarł do sedna.

„Prawie skończone” w zgodzie z DoDą

Niezależnie od powodu, dla którego zespół nie zwraca uwagi na to, czy przeżyjemy kolejne wdrożenie, warto za każdym razem zadziałać dwutorowo. To znaczy, z jednej strony jak najbardziej spróbujmy dotrzeć do źródła problemu („wyzwania” w slangu korporacyjnym). Z drugiej strony, od razu zaadresujmy ten konkretny aspekt jakościowy naszego produktu.

Czasami żartujemy, że Definition of Done powstaje przez fuckupy. Na przykład, powód spektakularnej katastrofy przy okazji wdrożenia nowej wersji oprogramowania identyfikujemy jako „brak migracji danych”. W takim razie od razu do DoDy trafia punkt „Powstały skrypty migrujące dane (w przypadku zmian struktur)”. Dzięki temu, liczymy, że następnym razem rzeczone skrypty powstaną tam, gdzie są potrzebne.

Oczywiście, nie musimy czekać do momentu wdrożenia. Przytoczony powyżej schemat postępowania podziała równie dobrze. Po prostu postraszmy zespół niespodziewanym wdrożeniem rzekomo gotowej funkcjonalności. Z okrzyków „Nie mamy skryptów aktualizujących bazę danych!” i „Brakuje zmian w instrukcji wdrożeniowej!” powstaną nam kolejne elementy DoD. Wszystko po to, żeby uniknąć „prawie skończonych” wymagań.

Jest to jednak działanie doraźne. Zamiast rozszerzać nasze Definition of Almost Done do kilkudziesięciu punktów (których wtedy już nikt nie będzie sprawdzał), należy zająć się prawdziwą przyczyną. Cały Scrum Team musi rozumieć, po co wydajemy się często, jak wygląda praca iteracyjna i dlaczego MVP to nie prototyp. Bo to przecież nie jest tak, że robimy „byle co”, a w kolejnych Sprintach doprowadzimy nasz produkt do stanu używalności.

Nasz Przyrost jest „używalny” na koniec każdego Sprintu.

Skąd się bierze Almost Done?

Przyczyn „prawie skończonych” zadań szukałbym w braku odpowiedniego mindsetu i zrozumienia sposobu naszej pracy. Jeżeli zespołom wydaje się, że najpierw tworzą rozwiązania niedoskonałe, a w kolejnych iteracjach je poprawiają, to nic dziwnego, że napotkamy na problem „almost done”.

A to przecież nie o to chodzi! Nasze rozwiązanie zawsze powinno być zdatne do użytku i wdrożenia. Jeżeli nie ma sensu upubliczniać kawałków niektórych funkcjonalności, schowajmy je za feature flagami, ale niech od samego początku będą one pisane tak, jakby zaraz miały być używane. Z drugiej strony, Product Owner powinien często wydawać nasze dzieło i przyzwyczaić wszystkich, że wdrożenie może nastąpić w każdej chwili.

Bez takiego nastawienia rzeczy istotne dla naszych użytkowników będą odkładane „na później” i w związku z nieuchronnym rozszerzaniem się naszej pracy (patrz: Prawo Hofstadtera) wypadną na następny Sprint bądź zostaną pominięte.

A w takich sytuacjach Zasada Pareto okaże się dla nas bezlitosna.

„Prawie skończone”, czyli „80%”

Zwykle ostatnie 20% pracy zajmie nam „przysłowiowe” 80% czasu. Dlaczego? Bo właśnie tam znajdują się kryteria jakościowe (które nie są precyzyjne) oraz przypadki szczególne (które są trudniejsze niż standardowy flow). Nie bez powodu prototypy powstają wielokrotnie szybciej niż finalne produkty. Przy ich budowie ignorujemy te problemy, które są istotne dla klientów, ale zupełnie zbędne z punktu widzenia demonstracji pomysłu.

Może też się zdarzyć, że te ostatnie 20% pracy to same wodotryski oraz przypadki tak nieprawdopodobne, że wystarczy je obsłużyć komunikatem o błędzie pod tytułem „Skontaktuj się z nami”. Częściej jednak te zapomniane 20% powiększy nam dług technologiczny i pogorszy nam jakość produktu. A wszystko dlatego, że nie lubimy rzeczy nieukończonych (patrz: Efekt Zeigarnik). Lepiej się czujemy z czymś, co jest „skończone” (nawet kiepsko) niż z czymś, co nad nami wisi.

Rozwiązanie? Dzielmy naszą pracę na takie kawałki, które same w sobie stanowią jakąś wartość, a pozostałe rzeczy chowajmy za flagami i przełącznikami, przemycając je po kawałku na środowisko produkcyjne. Nie róbmy osiemdziesięciu procent naszego docelowego rozwiązania, tylko znajdźmy prostsze wyjście z sytuacji.

Jasne, nasze MVP nie będzie „idealne”, bo nic takie nie jest. Ale powinno ono być satysfakcjonujące (na teraz) i potencjalnie docelowe. Tak jak pytaliśmy zespołów o wdrożenie, tak zapytajmy sami siebie – „Czy gdyby klient stwierdził, że chce zostać z MVP, to czy przypadkiem nie będziemy musieli mu czegoś jeszcze dorabiać?” Jeżeli odpowiedź brzmi „tak”, to nie jest to MVP, tylko nieszczęsny prototyp.

A nie o to w tym całym agile’u chodzi.

Jeżeli uważacie, że „specyfika obszaru, w którym działacie sprawia, że nie da się tak podzielić wymagań”, to zapraszamy na nasze szkolenie Wymagania w projektach agile. Mamy nadzieję, że i Was uda się przekonać, że jednak się da.