Blog

Zapytał mnie ostatnio znajomy Agile coach, co sądzę o pomyśle, by posługując się metodami zwinnymi szacować błędy, które naprawiają Developerzy. Oszacowania te mogłyby być wyrażone w tytułowych story pointach albo mieć dowolną inną formę przyjętą przez Zespół. Po usłyszeniu takiego pytania ma się ochotę odpowiedzieć „to zależy”, ja jednak zacznę od odpowiedzi na zupełnie inne pytanie.

Po co w ogóle coś szacujemy w Agile?

To temat na osobny artykuł, ale upraszczając odpowiedź do absolutnego minimum: po to, żeby wiedzieć, czy coś jest opłacalne i wykonalne w akceptowalnym czasie. Posługując się oszacowaniami wartości, jaką uzyskamy i kosztów wytworzenia (czasochłonności, pracochłonności lub relatywnej wielkości w przypadku story pointów) da się lepiej zidentyfikować, co jest najbardziej wartościowe w danym momencie.

Oczywiście, kiedy już mamy oszacowania, możemy pokusić się o tworzenie na ich bazie prognoz. Z tym zastrzeżeniem, że są one ważne na chwilę obecną i w danym kontekście, a przyszłość może szybko przynieść zmianę, która uczyni je zupełnie nieadekwatnymi. Przykładem może być przewidywanie terminów ukończenia prac z wykorzystaniem velocity – jest tylko mniejsze lub większe prawdopodobieństwo, że prognozowane daty się potwierdzą.

Innym sposobem użycia oszacowań – zwłaszcza tych dotyczących relatywnej wielkości lub czasochłonności – jest ich wykorzystanie w procesie pielęgnacji Backlogu Produktu. Rzeczy zbyt duże wymagają podziału, by dało je się zrealizować w krótkich iteracjach. Natomiast dyskusja o oszacowaniach i możliwej dekompozycji dużych elementów Backlogu pozwala lepiej zrozumieć opisane nimi potrzeby.

Szacowanie błędów

Cały Zespół (a zwłaszcza Developerzy w nim) powinien zastanowić się, czemu oszacowania błędów mają służyć i w jakiej formie wyceny takie będą sporządzone.

Najczęściej wskazywane są następujące powody, by szacować błędy:

1. Podejmowanie decyzji o opłacalności naprawy błędu.
2. Sporządzanie prognozy terminu dostarczenia rozwiązania.
3. Monitorowanie postępu prac (np. w ramach iteracji).
4. Wyliczanie prędkości (ang. velocity) Zespołu.

Kolejność tej listy nie jest przypadkowa. Można powiedzieć, że została ona uporządkowana wedle rosnącej precyzji oszacowań, jakiej potrzebował będzie Zespół. Można też jednak powiedzieć, że kolejność odzwierciedla spadający sens szacowania błędów, zwłaszcza jeśli posłużymy się do tego story pointami. Dlaczego?

Aby podjąć decyzję o tym, czy błąd warto naprawiać, trzeba oszacować dotkliwość jego skutków (ang. severity) oraz zgrubny koszt developmentu. Zgrubny, bo nie da się tego zrobić precyzyjniej bez zrozumienia istoty problemu i pomysłu na jego rozwiązanie. Przy czym błędy krytyczne zostaną rozwiązane nawet wtedy, gdy brak oceny kosztów z tym związanych.

Story pointy, czyli bezwymiarowe jednostki wielkości do relatywnego porównywania ze sobą różnych szacowanych elementów, mogą być całkiem użyteczne przy tego rodzaju szacowaniu, ale trzeba pamiętać: takie punktu nie dają żadnej precyzji i nie da się ich uwymiarowić np. konwersją na czas.

Szacowanie błędów po to, by przewidzieć, kiedy zostaną one rozwiązane, ma zdecydowanie mniejszy sens. Nie wystarczy już tylko ocenić opłacalność naprawy, ale trzeba jeszcze określić, jak długo zajmie wytworzenie rozwiązania. Problem w tym, że to wymaga przeanalizowania błędu i zaprojektowania tego rozwiązania (albo choćby jego koncepcji). Albo więc będzie to naprawdę zgadywanie o niemal zerowej wiarygodności, albo pracę nad błędem trzeba będzie rozpocząć i dociągnąć do dość zaawansowanego etapu.

Jeszcze gorzej jest z monitorowaniem postępu prac w odniesieniu do oszacowań. Jest to w zasadzie wykonalne tylko wtedy, gdy dokładnie wiadomo, jakie rozwiązanie błędu trzeba zaimplementować. Co więcej, żeby ten sposób monitorowania postępu developmentu miał jakikolwiek sens, trzeba by przyjąć, że odbywa się to w domenie na tyle stabilnej, że da się zaprojektować właściwe rozwiązanie, zaplanować jego wytworzenie i wykonać ten plan bez żadnych istotnych zmian lub niespodzianek po drodze.

Czy oszacowań w story pointach da się użyć do sporządzania prognoz terminów naprawy błędu albo monitorowania postępu prac? Można próbować, ale punktów (o ile używane są prawidłowo) nie da się przeliczyć na czas. To oznacza, że dysponując wyrażoną w nich estymatą, możemy jedynie porównać jej wartość z czymś (stąd nazwa: szacowanie relatywne). Zazwyczaj takim punktem odniesienia jest velocity. I tu pojawia się problem:

• jeśli velocity wyliczane jest z pominięciem oszacowań błędów (czyli wyłącznie na podstawie zrealizowanych elementów Backlogu Produktu), to nie stanowi ono adekwatnego punktu odniesienia do porównań z oszacowaniami błędów (których tempo naprawy może być wolniejsze lub szybsze, niż standardowy development),
• jeśli natomiast velocity wyliczane jest z uwzględnieniem oszacowań błędów, wtedy co prawda da się od biedy użyć go do prognozowania terminu usunięcia jakiegoś defektu, ale traci ono wartość jako narzędzie prognozowania tempa realizacji elementów Backlogu Produktu (gdzie zgłoszenia błędów trafiają jedynie sporadycznie).

A już kompletnym kuriozum jest szacowanie błędów przede wszystkim po to, by uwzględniać je przy wyliczaniu velocity.

Oszacowania błędów a velocity

Wiele Zespołów liczy swoje velocity, sumując estymaty zrealizowanych elementów Backlogu Produktu. Jeśli szacowane są również błędy i uwzględniane w wyliczeniu prędkości, velocity Zespołu może być bardzo wysokie nawet wtedy, gdy Developerzy będą wyłącznie naprawiać kolejne błędy. Istnieje ryzyko, że Zespół uzyska fałszywe poczucie, iż robi dużo wartościowych rzeczy. A przecież usuwanie defektów nie kreuje wartości jako takiej, tylko dociąga produkt do stanu, który wcześniej był deklarowany, ale w rzeczywistości osiągnięty nie został.

Z drugiej strony, jeśli błędów jest sporo i nie będą wyceniane ani uwzględniane w velocity, może to skutkować niską motywacją Developerów do ich naprawiania. Będą mieli poczucie, że ciężko pracują, a efektów tej pracy nie widać i velocity szoruje po dnie…

Warto jeszcze spojrzeć na to z trzeciej perspektywy. Jeśli produkt jest wadliwy i trzeba usuwać z niego kolejne defekty, źle to świadczy o poziomie praktyk developerskich. Jeśli Developerów konieczność naprawiania błędów nie zaboli, być może nigdy nie udoskonalą sposobu, w jaki pracują ani nie podniosą swoich kompetencji. A wtedy produkt nadal będzie bublem kiepskiej jakości.

Wyraźnie widać więc, że przy ustalaniu zasad szacowania błędów trzeba znaleźć jakąś równowagę pomiędzy tymi trzema skrajnościami i spowodować, że:

• wysiłek włożony w naprawianie błędów nie będzie uznawany za kreowanie wartości,
• Developerzy będą zmotywowani do usuwania defektów,
• a przede wszystkim będą dbać o jakość tak, by liczba zgłaszanych błędów była możliwie najniższa.

Przy czym osiągnięcie równowagi może być utrudnione zarówno przez zmienność warunków, w jakich funkcjonuje Zespół, jak i niekorzystne procesy, jakie funkcjonują w ramach organizacji. Mówiąc wprost, otoczenie Zespołu może generować presję na to, by szacować błędy albo wręcz narzucać formę, w jakiej ma się to odbywać, nawet jeśli jest to szkodliwe dla motywacji Developerów i nie sprzyja dbaniu o jakość bieżącego developmentu.

W wielkim świecie wielkich firm

Rzecz jasna w dużych organizacjach swobody decydowania o procesach i praktykach bywa mniej, bo najczęściej dążą one do unifikacji procesów i praktyk. Ciężko jednoznacznie określić, czy to dobrze, czy źle. Całkowita swoboda w dużej organizacji, gdzie Zespoły pracują nad czymś wspólnie i mocno od siebie zależą, niekoniecznie pozwoli na ich skuteczne działanie i wzajemną synchronizację. Z drugiej strony zbyt niska autonomia pozbawi Zespoły wpływu na własny proces, a to może zabić motywację.

Jeśli więc mamy do czynienia z dużą organizacją, wtedy obowiązujące w niej standardy stanowią dodatkowy czynnik do uwzględnienia przy decydowaniu, jak i co szacować. Zespół, któremu z racjonalnych powodów standardy wybitnie nie odpowiadają, znajdzie sposób na ich zmianę.

Niezbędna jest rozmowa i zrozumienie potrzeb i ograniczeń wszystkich zainteresowanych (organizacji i wszystkich Zespołów). Pomagają w tym wybitnie wszelkiego rodzaju społeczności lub gildie, które zazwyczaj funkcjonują w sporych firmach. Współpraca przy definiowaniu standardów stosunkowo szybko prowadzi do znalezienia rozwiązania zadowalającego wszystkich. Oczywiście szybko jest pojęciem względnym i w dużych firmach o sporej inercji cierpliwość jest niezbędna.

Z pamiętnika Scrum Mastera

Nie chcę wniosków z moich doświadczeń jako Scrum Master podsuwać jako prawd uniwersalnych – każde miejsce jest inne. Ale chciałem podzielić się trzema.

Pierwszy jest taki: definiowanie twardej reguły, że tylko „biznesowe wymagania” powinny być szacowane, a wszystko inne traktowane jest jako mająca niską wartość praca techniczna, utrwala lub odnawia podział na „biznes” i „technologię”. A to szkodliwe, bo większość dzisiejszych rozwiązań to połączenie procesów biznesowych ze wspierającą je technologią. Zbyt twarde przekonania i wynikające z nich twarde reguły co szacować a czego nigdy nie szacować, co uwzględniać w velocity a czego absolutnie nie, to sygnał, że sporo jeszcze jest do zrobienia w Zespole i organizacji.

Druga moja obserwacja dotyczy pokusy, by tworzyć algorytmy, które jednoznacznie pokierują nami w działaniu. To też szkodliwe, bo wyłącza myślenie. Ustalmy proste zasady i bądźmy otwarci do dyskusji indywidualnie o każdym przypadku. Ważniejsza niż precyzja reguł jest ich prostota i możliwość konsekwentnego stosowania. Złożone reguły generują wiele przypadków, dla których konieczne jest reguł tych doprecyzowanie, więc kodeks się rozrasta i w końcu nikt już go nie ogarnia… a więc i nie przestrzega.

Trzecia, dużo ogólniejsza obserwacja: problem „szacować czy nie szacować błędy” (albo zadania techniczne, tworzenie dokumentacji – dowolną inną rzecz można tu wstawić) pojawia się najczęściej tam, gdzie ludzie skupieni są na procesie, rolach, odpowiedzialnościach, a nie na tym, co mają do zrobienia. Zespół, któremu zależy na produkcie, działający w środowisku, gdzie istnieje minimum wzajemnego zaufania niezbędnego do zadziałania empiryzmu, ustali zasady obsługi błędów szybko i sprawnie. Choćby dlatego, że nie będzie pod nimi tonął, bo – jako że mu zależy – zadba o budowanie dobrych rozwiązań. A wtedy problem obsługi defektów w ogóle przestanie być istotny.