-
Data: 2013-08-18 12:35:24
Temat: Re: SCRUM umarł, niech żyje SCRUM
Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]On 17/08/2013 22:27, Wojciech Muła wrote:
> On Saturday, August 17, 2013 1:43:28 AM UTC+2, Andrzej Jarzabek wrote:
>>> Nie można zmienić w trakcie spotkania - timebox rzecz święta, right?
>>
>> W trakcie nie, ale jeśli generalnie wychodzi, że timebox za którki, to
>> na retrospektywie można postanowić, że się go wydłuży.
>
> No tak, tylko problem jest właśnie teraz! Po sprincie to już nie
> ma znaczenia.
Weź pod uwagę, że planowanie ma tylko jeden cel - wybranie itemów do
realizacji w czasie sprintu. W tym celu się robi szacunki, żeby można
było określić, ile itemów się da zrobić, i w tym celu się planuje taski
- żeby wyłapać na wczesnym etapie rzeczy wpływające na extymaty (w jedną
i w drugą stronę). Wszystko, co tej decyzji nie służy trzeba wypchnąć
poza timebox planowania.
Oczywiście takie szacunki zawsze są obciążone jakimś ryzykiem błędu i
teoreytycznie można powiedzieć, że każdy dodatkowy czas poświęcony na
analizę i planowanie zadań może przynieść dodatkowe informacje. Pytanie
jednak, ile czasu warto poświęcać na planowanie czegoś, co potencjalnie
w ogóle nie będzie implementowane.
Jeśli na zasadzie wyjątku się zdarzy, że akurat ewidentnie poświęcenie
więcej czasu da istotną rewizję szacunku wpływającą znacząco na to, co
się da, a czego nie da zrobić, to można podejść do sprawy na dwa
sposoby. Po pierwsze, jeśli jest konsensus że warto, to można wyjątkowo
jednorazowo naruszyć timeboxa.
Z drugiej strony można zdecydować, że nie poświęci się dodatkowego czasu
i użyć takiej estymaty, jaką się ma, ewentualnie uwzględniając
istniejącą niepewność w wariancie pesymistycznym (jeśli wygląda na to,
że coś może zająć dwa razy tyle czasu, ale nie ma czasu, żeby zbadać czy
na pewno, to założyć, że zajmie; jeśli wygląda na to, że coś może
zamiast tygodnia zająć pięć minut, to założyć, że nie zajmie). Założenie
jest takie, że jeśli się akurat tę rzecz źle oszacuje to nic strasznego
się nie stanie, bo błędne estymaty zdarzają się dość często i tak, a
poprawność ich jest tylko statystyczna - jeśli jedne rzeczy
przeszacujesz, a inne niedoszacujesz, to w ramach sprintu powinno się
zwykle wyrównać. Jeśli systematycznie estymaty się mylą w jedną stronę,
to znowu kwestia do rozpatrzenia na retrospektywie - dlaczego?
Ostatecznie ponieważ jest to jednorazowe zdarzenie, to nie ma większego
znaczenia, na którą opcję się zdecydujecie. Na retrospektywie trzeba się
zastanowić czy nie wynikało to z błędów (np. że się zbyt wiele czasu
poświęcało na zbyt szczegółową analizę innych itemów, co niewiele
wnosiło do szacunków, i na inne itemy nie zostało czasu w ogóle lub
zostało bardzo niewiele). Wniosek też może być taki, że okoliczności po
prostu były wyjątkowe i wasz proces ich nie przewidział i nie powinien
być modyfikowany żeby je przewidywać, bo najprowadopodobiej się nie
powtórzą. Jeśli "wyjątkowe" okoliczności zaczynają się powtarzać, to
trzeba się zacząć zastanawiać nad zmianami.
> Ale główny problem jest taki, że czasem dopiero po rozgrzebaniu zadania
> widać, że estymata była kosmiczna. Część modułów naszego systemu nie była
> ruszana od dawna i często nawet osoby, które je pisały nie ma pojęcia
> ile będzie kosztowała zmiana.
Trzeba pamiętać, że szacowanie ani nawet realizacja zaplanowanych itemów
nie są celami same w sobie. Celem jest maksymalizacja wartości
dostarczonej klientowi i w tym celu PO musi mieć szacunki, żeby określić
co warto robić kosztem czego i w jakiej kolejności. Jeśli musisz
wszystko rozgrzebać, żeby mieć estymaty, to wartość dostarczona
klientowi cierpi, bo poświęcasz czas na rozgrzebywanie rzeczy, któóre
nie będą dostarczone klientowi (bo po rozgrzebaniu okaże się, że nie
warto), albo z kolei będziesz robić rzeczy, które są mało wartościowe w
stosunku do kosztów, bo koszty będą znane dopiero jak już dana rzecz
będzie w 3/4 gotowa.
Szcrum zakłada, że do pewnego momentu błędy w szacowaniu nie są takim
dużym problemem, bo po pierwsze, jak pisałem, przeszacowania i
niedoszacowania się znoszą i owszem, gdyby rzeczywiste koszty były od
razu znane, to priorytety mogłyby być inne, ale zazwyczaj nie aż na tyle
inne, żeby ponosić koszty przerywania tego, co już jest "rozgrzebane" i
ponownego planowania. A jeśli się okaże, że się w znaczący sposób nie
znoszą, to zawsze jest możliwość pójścia do PO i powiedzenia "są
komplikacje i nie wyrobimy się ze wszystkim, co zaplanowaliśmy, jakby
co, to z których itemów mamy zrezygnować" lub z drugiej strony "okazało
się, że przeszacowaliśmy i mamy dodatkowe zasoby, zróbmy dodatkowe
planowanie i wciągnijmy dodatkowe itemy do sprintu". Jedno i drugie nie
jest wielkim problemem, najważniejsze żeby zrobić to jak najszybciej,
jak tylko dodatkowa informacja jest dostępna.
>> Jeśli specyfika projektu jest faktycznie taka, że regularnie zdarzają
>> się super ważne rzeczy, które trzeba wdrożyć do produkcji w ciągu kilku
>> dni, to prawdopodobnie Scrum nie jest dobrą metodologią.
>
> Nie, to się zdarzyło jak dotąd raz.
No ale rozumiesz chyba, że nie ma sensu budować procesu wokół tego, co
zdarza się jeden raz?
> Owszem, to może być powód, czasem jest za dużo dywagacji. A czasem
> jest n-ta godzina spotkania i wszyscy odlatują.
Możesz konstruktywnie zaproponowac robienie przerw :)
Następne wpisy z tego wątku
- 18.08.13 23:21 Maciej Sobczak
- 18.08.13 23:36 Stachu 'Dozzie' K.
- 19.08.13 00:15 Andrzej Jarzabek
- 19.08.13 02:31 A.L.
- 19.08.13 08:17 Paweł Kierski
- 19.08.13 08:29 Paweł Kierski
- 19.08.13 08:48 Paweł Kierski
- 19.08.13 09:02 Paweł Kierski
- 19.08.13 09:28 Andrzej Jarzabek
- 19.08.13 09:39 Stachu 'Dozzie' K.
- 19.08.13 09:42 Stachu 'Dozzie' K.
- 19.08.13 10:21 Andrzej Jarzabek
- 19.08.13 11:25 Paweł Kierski
- 19.08.13 11:56 kali
- 19.08.13 13:32 Edek
Najnowsze wątki z tej grupy
- Na grupie comp.os.linux.advocacy CrudeSausage twierdzi, że Micro$lop używa SI do szyfrowania formatu dok. XML
- Błąd w Sofcie Powodem Wymiany 3 Duńskich Fregat Typu Iver Huitfeldt
- Grok zaczął nadużywać wulgaryzmów i wprost obrażać niektóre znane osoby
- Can you activate BMW 48V 10Ah Li-Ion battery, connecting to CAN-USB laptop interface ?
- We Wrocławiu ruszyła Odra 5, pierwszy w Polsce komputer kwantowy z nadprzewodzącymi kubitami
- Ada-Europe - AEiC 2025 early registration deadline imminent
- John Carmack twierdzi, że gdyby gry były optymalizowane, to wystarczyły by stare kompy
- Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2025
- Linuks od wer. 6.15 przestanie wspierać procesory 486 i będzie wymagać min. Pentium
- ,,Polski przemysł jest w stanie agonalnym" - podkreślił dobitnie, wskazując na brak zamówień.
- Rewolucja w debugowaniu!!! SI analizuje zrzuty pamięci systemu M$ Windows!!!
- Brednie w wiki - hasło Dehomag
- Perfidne ataki krakerów z KRLD na skrypciarzy JS i Pajton
- Instytut IDEAS może zacząć działać: "Ma to być unikalny w europejskiej skali ośrodek badań nad sztuczną inteligencją."
- Instytut IDEAS może zacząć działać: "Ma to być unikalny w europejskiej skali ośrodek badań nad sztuczną inteligencją."
Najnowsze wątki
- 2025-08-06 Gdynia => Konsultant wdrożeniowy (systemy controlingowe) <=
- 2025-08-06 Białystok => Inżynier oprogramowania .Net <=
- 2025-08-06 "[...] sejmowe wystąpienie posłanki Klaudii Jachiry, która zakończyła je słowami ,,Sława Ukrainie"."
- 2025-08-05 "Chiny przekraczają w wydobyciu 4 mld ton węgla, Indie i USA ponad 1 mld, a Rosja 500 mln ton [...]"
- 2025-08-05 Panuje się 181 159,42 zł./mies. na posła w 2026r.
- 2025-08-05 "Chiny przekraczają w wydobyciu 4 mld ton węgla, Indie i USA ponad 1 mld, a Rosja 500 mln ton [...]"
- 2025-08-05 Czy cos fi przechodzi przez trafo separujące?
- 2025-08-05 kajaki i promile
- 2025-08-05 Re: Tesla jest bezpieczna, wczoraj spaliła się doszczętnie na Ursynowie i nikomu się nic nie stało
- 2025-08-05 Gdynia => Przedstawiciel handlowy / KAM (branża TSL) <=
- 2025-08-05 Re: Atak na lekarza w Oławie. Policja zatrzymała sprawcę na lotnisku Polska Agencja Prasowa 4 sierpnia 2025, 12:16 FACEBOOK X E-MAIL KOPIUJ LINK W szpitalu w Oławie 37-letni pacjent zaatakował lekarza, po tym, jak ten odmówił mu wypisania długoterminowego
- 2025-08-05 B2B i książka przychodów i rozchodów
- 2025-08-04 Re: Atak na lekarza w Oławie. Policja zatrzymała sprawcę na lotnisku Polska Agencja Prasowa 4 sierpnia 2025, 12:16 FACEBOOK X E-MAIL KOPIUJ LINK W szpitalu w Oławie 37-letni pacjent zaatakował lekarza, po tym, jak ten odmówił mu wypisania długoterminowego
- 2025-08-04 Na grupie comp.os.linux.advocacy CrudeSausage twierdzi, że Micro$lop używa SI do szyfrowania formatu dok. XML
- 2025-08-04 Na grupie comp.os.linux.advocacy CrudeSausage twierdzi, że Micro$lop używa SI do szyfrowania formatu dok. XML