W połowie października Zwinna Łódź zgromadziła chętnych do dyskusji nad sensownością estymowania podczas produkcji oprogramowania.
Po raz kolejny sięgnęliśmy do formuły debaty oksfordzkiej i podzieleni na dwa zespoły, zmierzyliśmy się z tezą iż "Estymowanie to strata czasu".
Upatrując w tej formule efektywnej drogi do wymiany doświadczeń (poza oryginalnym założeniem nauki argumentacji, słuchania i zwięzłości wypowiedzi) stworzyliśmy Propozycję i Opozycję, które debatowały w trzech rundach.
Podczas gdy moja skromna osoba przewodniczyła gorącym obradom, Tomasz pilnie notował przebieg argumentów..
który możecie w przystępnej wersji prześledzić w załączonym dokumencie (Estymacje to strata czasu). Na koniec dokonał zwięzłego podsumowania,
które uznajemy za warte zapisania i rozpowszechnienia.
Podsumowanie
1. Zwrócono szczególną uwagę na znaczenie czasu w projekcie. Z jednej strony brak estymacji podyktowany był oszczędnością czasu dla klienta, a z drugiej strony estymacje pozwalały oszczędzić czas klienta w przygotowaniu i realizacji planu.
2. Zgodzono się, że estymacje wymagają poczynienia dużej ilości założeń, które powinny pozostać względnie niezmienne, aby odpowiadały one rzeczywistości, ponieważ:
- zespół się zmienia,
- technologia się zmienia,
- wymagania się zmieniają,
- rynek się zmienia.
3. Estymacje to zobowiązanie. Klient spodziewa się, że dostając estymację otrzymuje jednocześnie od zespołu zobowiązanie, że czas wykonania projektu nie ulegnie zmianie. Jednak rzeczywistość nie odpowiada założeniom i jest mało prawdopodobne aby przewidzieć przyszłość w projekcie.
4. Aby estymować trzeba posiadać zdolność przewidywania przyszłości; jeśli uważamy że ją posiadamy, plan jest jego materializacją
5. Współpraca z klientem i zaufanie są warunkami koniecznymi w projekcie oraz ważne są także:
- uczciwość we współpracy w klientem,
- szacunek do czasu,
- dotrzymywanie czasu,
- uspokojenie klienta.
