Dokładność estymacji w Agile

„Jeśli powiemy zespołowi, że chcemy poprawić dokładność oszacowania, metryka ta zostanie poprawiona bez względu na skróty, którymi pójdzie zespół.”

Ken Schwaber
„Sprawne zarządzanie projektami metodą Scrum”
przekład : Daniel Czerewacki, Adam Kasprzyk

W firmach zajmujących się tworzeniem oprogramowania z użyciem agilowych metodyk prowadzenia projektu, bardzo czesto dochodzi do sytuacji, w której zarząd wyraża swoje zaniepokojenie faktem, że szacowania (estymacje) dokonywane przez zespół są – delikatnie mówiąć – nieprecyzyjne. Napięcie z każdym sprintem jest coraz większe, aż w końcu zostaje podjęta decyzja – trzeba coś z tym zrobić. Przecież w takich wrunkach nie można prowadzić biznesu!
Zarząd próbuje zaradzić tej niekomfortowej dla siebie sytuacji wprowadzając różnego rodzaju praktyki, które mają pomóc w tym, aby estymacje stały się bardziej precyzyjne. Najczęściej pojawia się pomysł, aby notować rzeczywistą liczbę godzin spędzonych na realizacji każdego zadania i porównywać ją z tą szacowaną. I tu dopiero zaczynają się prawdziwe problemy.

Estymacja (szacowanie) z definicji nie jest precyzyjną miarą pewnej wielkości a jedynie miarą przybliżoną. Nieprzypadkowo twórcy Agile na określenie procesu przewidywania nakładu pracy użyli właśnie słowa estimation. Ma to swoje głębokie uzasadnienie w podstawach metodyki Agile, która opiera się na empirycznej kontroli procesu, którego istotą nie jest idealna przewidywalność ale częsta inspekcja i adaptacja. Przeprowadzamy je właśnie po to, aby na bieżąco lokalizować i poprawiać wszelkie błędne decyzje, przeszkody i nieścisłości wynikające z faktu, że przy tworzeniu oprogramowania mamy do czynienia ze skomplikowanym i złożonym procesem przebiegającym w warunkach zmiennej i nieprzewidywalnej rzeczywistości. Dlatego wszakże zdecydowaliśmy się wprowadzić Agile!

Jeśli zaczniemy wywierać presję na zespół, aby poprawił dokładność estymacji – zrobi to. Jeśli od dokładności szacowania zależeć będą premie, bonusy czy awanse – dokładność estymacji z pewnością ulegnie poprawie… tyle tylko, że poprawa ta pojawi się kosztem innego elementu procesu! W przypadku tworzenia oprogramowania, najprawdopodobniej ucierpi na tym jakość. Jakość implementowanej funkcjonalności lub po prostu jakość kodu. Coś, czego zarząd nie zauważy „gołym okiem” i wszyscy będą szczęśliwi, ale tylko do czasu…

Nie próbujmy działań wymierzonych przeciwko zasadzie samozarządzania i samoorganizacji zespołu chcąc w ten sposób wpływać na dotrzymywanie ustalonych estymacji. Efekty takich działań mogą być katastrofalne.