Czy szacunek czasu jest równy obietnicy w Scrumie?

Jeśli oszacowanie nie jest obietnicą, to jako właściciel produktu, jak mogę dostarczyć moje projekty, nie wiedząc, jak długo to potrwa?

Czy zespół Scrumowy działa wydajniej, jeśli traktujemy prognozy czasu jako obietnicę?

Ile badań (przygotowanie, wysiłek, aby zrozumieć problem) w historii wystarczy, aby uzyskać właściwą ocenę?

Co z nieoczekiwanymi problemami technicznymi (problemami, które mogą naprawdę popsuć początkowe szacunki), które pojawiają się po oszacowaniu pracy?

Szacunki nie są obietnicami wyrytymi w kamieniu. Są to najlepsze przypuszczenia, jakie zespół może podjąć na temat wysiłku wymaganego do wykonania zadania / historii.

W odpowiedzi na pytanie „jako właściciel produktu w jaki sposób mogę dostarczyć moje projekty z zewnątrz czas jako punkt odniesienia?”, Odpowiedź jest to, że mogą i powinni mieć czas jako punkt odniesienia (to znaczy będzie zwolnić w określonym terminie). To, czego nie masz, to dokładny zakres dostawy.

Zauważ, że to, co powiedziałem, dotyczy każdej metodologii, której używasz do napędzania swojego rozwoju. Różnica między Scrumem a innymi metodologiami (takimi jak Wodospad) polega na tym, że w Scrumie fakt ten jest uznawany i rozliczany. Jako PO będziecie traktować priorytetowo zakres i upewniać się, że zespół w danym momencie będzie:

1. Praca nad najważniejszą (czytaj: wartościową) niedostarczoną funkcją (zadanie, wymaganie, historia użytkownika)
2. Udało mu się ukończyć każdą funkcję, która jest ważniejsza niż ta, nad którą obecnie pracują (odnosi się to do Definicji ukończenia: każda ukończona historia jest testowana, akceptowana, wolna od błędów i kompletna).

Dzięki temu możesz teraz wysyłać lub dostarczać za jednym razem, wiedząc, że w danym momencie najnowsza wersja jest najlepszym produktem, jaki można wysłać. Oznacza to, że w dniu pierwotnego zobowiązania do wydania dostarczysz najlepszy możliwy produkt.

Oczywiście nie obiecuje to, że będzie się składać z każdej historii, którą zespół opracuje, ale wiesz, że pozostałe niekompletne są oczywiście najmniej ważne, a które z łatwością mogą zostać dostarczone w późniejszym terminie.

Ponadto szacunki dokonane przez zespół będą coraz lepsze, dzięki czemu będziesz mieć wczesne rzetelne wyobrażenie o tym, jaki będzie zakres pod koniec wydania. Będziesz w stanie wysłać dobry solidny produkt na czas, z kilkoma dodatkowymi, mniej ważnymi funkcjami, kilka tygodni później (oczywiście będziesz mógł oszacować, kiedy to będzie).

Jeśli chodzi o ilość wymaganych badań - obowiązuje zasada malejących zysków. Jeśli podzielisz swoje historie na wystarczająco małe, wtedy małe badanie powinno dać ci wystarczająco dokładne oszacowanie. Jeśli się pomylisz, poprawisz w następnym sprincie, a prognozy będą lepsze. Średnio w 3-4 sprintach powinieneś dobrze wiedzieć, ile zakresu można dostarczyć w terminie (lub ile czasu zajmie ukończenie zakresu).

Gdy oszacujesz punkty fabularne w Scrumie, powinieneś wiedzieć wystarczająco dużo, aby móc zacząć pisać funkcję. Szacunki nie powinny być w pełni dokładne, cały sens metodologii zwinnego programowania polega na tym, że uznają, że nie można dokładnie przewidzieć, jak długo zajmie rozwój.

Etap, w którym zobowiązujesz się do dostarczenia, polega na zaakceptowaniu historii z rejestru produktów w Sprint. Obiecujesz dostarczyć te historie w trakcie sprintu.

Jeśli podejmiesz to zobowiązanie, oznacza to, że jesteś gotów poświęcić dodatkowe godziny, jeśli wygląda na to, że nie dotrzymasz obietnicy. W rzeczywistości niektóre historie potrwają dłużej, niż myślisz, a inne zajmą mniej czasu, niż ci się wydawało.

Gdy zespół dokona wystarczającej oceny, będzie w tym lepszy.

Możesz także spojrzeć na ...

Czysty koder (książka) - w tej książce znajduje się rozdział zatytułowany „Język zobowiązania”, a także rozdział dotyczący szacowania, który naprawdę otwiera oczy.

Kanban - Kanban jest bardziej stylem ciągłego rozwoju - istnieją również kombinacje Scruma i Kanbana zwane „Scrumban”, które czerpią z obu pomysłów.

Nie.

Suma wszystkich oszacowań dla każdego zakończonego zadania w sprincie nazywa się prędkością . Prędkość jest definiowana jako „liczba ukończonych punktów na sprint”, gdzie „punkt” to jednostka, w której szacuje się drużyna.

Szybkość pozwala więc wiedzieć, ile Twój zespół może wyprodukować w następnym sprincie, zakładając, że używa tej samej metody do oszacowania, a zespół jest stabilny itp.

I w ten sposób możesz być całkiem pewien, co zespół może dostarczyć, bez konieczności składania przypadkowych obietnic.

Szacunki nakładu są narzędziem do prognozowania. Prognoza nie jest ani zobowiązaniem, ani gwarancją. Prognozy są stale poddawane ponownej ocenie w celu uwzględnienia nowej wiedzy i powinny obejmować możliwe alternatywy, takie jak warianty optymistyczne i pesymistyczne.

Spoglądamy do przodu w Agile. Zobowiązania nie wnoszą więcej wartości do planowania organizacyjnego niż prognozy.

Bardzo polecam zwinne oszacowanie i planowanie Mike'a Cohna

Jeśli oszacowanie nie jest obietnicą, to jako właściciel produktu, jak mogę dostarczyć moje projekty, nie wiedząc, jak długo to potrwa?

Nie pracujesz z jednym dużym oszacowaniem, ale z wieloma małymi oszacowaniami na poziomie opowieści. Wiele błędów oszacowania na poziomie opowieści jest przeciętnych. Nie możesz obiecać zarówno treści, jak i daty. Możesz jednak być całkiem pewny, że górna część zaległości dostanie się w wydaniu (alternatywnie, masz dość dokładną - ale nie ustaloną - datę, o której można dostarczyć cały zaległość).

Czy zespół Scrumowy działa wydajniej, jeśli traktujemy prognozy czasu jako obietnicę?

Nie. To prowadzi do oszacowania worków z piaskiem i przekształcenia wykresów prędkości / wypalenia w bezużyteczne dane - co zapobiega poprawie zespołu.

Ile badań (przygotowanie, wysiłek, aby zrozumieć problem) w historii wystarczy, aby uzyskać właściwą ocenę?

Zależy, jak bardzo zależy Ci na precyzji. Możesz spędzić tygodnie ostrożnie przygotowując każdy kosztorys lub podać szybkie szacunki w dobrej wierze i mieć nadzieję, że błędy się ustabilizują. Pierwszym sposobem jest skonfigurowanie na wypadek awarii, ponieważ oszacowanie czegoś, czego nie zrobiłeś wcześniej, jest naprawdę trudne, a inżynieria oprogramowania dotyczy rzeczy, których wcześniej nie robiłeś.

Osobiście nie sądzę, że próba uzyskania bardzo dokładnych szacunków przynosi wiele korzyści. Staram się upewnić, że szacunki są wystarczająco dokładne - tj. Że nie przeoczyłem czegoś, co może sprawić, że historia odbiega od jej szacunków o rząd wielkości. (Zobacz następny punkt).

Co z nieoczekiwanymi problemami technicznymi (problemami, które mogą naprawdę popsuć początkowe szacunki), które pojawiają się po oszacowaniu pracy?

Małe iteracje. Zamówione zaległości. Małe historie. Niebezpieczne są rzeczy, których nie wiesz, których nie wiesz. Brak wiedzy specjalistycznej na temat problemu będzie skutkować złymi szacunkami, ale można to zmienić, zdobywając wiedzę specjalistyczną (więcej opracowań) lub stosując „wystarczająco dobre” szacunki - wszystko dotyczy zarządzania ryzykiem.

Jeśli oszacowanie nie jest obietnicą, to jako właściciel produktu, jak mogę dostarczyć moje projekty, nie wiedząc, jak długo to potrwa?

To jedno z największych nieporozumień na temat Scruma. Pytanie „Jak długo potrwa mój projekt?” zakłada, że ​​w pewnym momencie możesz zdefiniować dokładnie, co pociągnie za sobą projekt w celu jego ukończenia. Ale cała idea Scruma polega na tym, że uznaje on, że rzeczy, których uczysz się o projekcie podczas pracy nad projektem, zmienią jego definicję.

Najczęstszym sposobem definiowania projektu jest lista jego funkcji. Zazwyczaj projekt jest zakończony, gdy wszystkie funkcje zostaną zaimplementowane. Ale co, jeśli podczas pracy nad projektem zdasz sobie sprawę, że 5 funkcji zidentyfikowanych na początku nie będzie potrzebnych, ale istnieje 7 funkcji, o których ludzie pomyśleli w ciągu pierwszych 6 miesięcy, które naprawdę powinny zostać uwzględnione? Co to robi z pytaniem, jak długo to potrwa?

Innym czynnikiem jest to, że rzeczy, których się nauczysz, zmienią twoje rozumienie, jak wdrożyć niektóre funkcje, a gdy zbliżysz się do wdrażania każdej funkcji, twoje prognozy zmienią się. Osobiście nie chciałbym opierać szacunków liczbowych na niczym, co nie zbliża się do horyzontu wdrażania - być może używając opisowych oszacowań takich jak „malutki”, „mały”, „średni”, „duży” i „ogromny” lub „epicki”. Zatem nie sugerujesz, że dokładność jest większa niż jesteś w stanie oszacować.

Prawdę mówiąc, „Ile to zajmie?”, Nie można odpowiedzieć tak samo jak „Co to będzie, kiedy to się skończy?”. Księgowi i tradycyjni ludzie biznesu nienawidzą tego, dlatego bardzo trudno jest odejść od Waterfall w niektórych organizacjach.

Dlatego też musisz dużo rozmawiać o prędkości i pomiarach z odrobiną soli. Projekty oprogramowania mają wbudowaną w nich zasadę niepewności Heisenberga, a jeśli poświęcisz zbyt dużo czasu na dostrajanie pomiarów, skończysz z wyjątkowo precyzyjnymi bzdurami.

Więc nie, szacunek nie jest obietnicą. To jest oszacowanie. „Obietnica” to zobowiązanie zespołu do ukończenia pewnej liczby funkcji lub historii w danym sprincie.

Szacunki muszą być na tyle dokładne, aby umożliwić Zespołowi określenie, ile funkcji (lub historii) można zmieścić w sprincie. Nawet ważniejsza niż dokładność szacunków jest konsekwencja, ponieważ zespół dowie się, ile szacunków można zmieścić w sprincie, nawet jeśli rzeczywista praca okazuje się zwykle dwa razy większa niż szacowano. Tak długo, jak będzie to stale wyłączone, będą mogli planować.