@Fandarel,
Jakikolwiek wykres burn jest niewymagany w Scrumie. Na pewno nie służy do pokazywania na Review. To wewnętrzna rzecz dla zespołu w celu predykcji prawdopodobieństwa dowiezienia rzeczy w Backlogu Sprintu. I może iść do góry: przecież jak podczas Sprintu który ma cel wyjdzie Ci dodatkowa praca do wykonania do wrzucasz to do Backlogu Sprintu.
Albo nie łapiesz ironii, albo różnicy między teorią i praktyką.
Wiemy, że burndown chart nie powinien mieć znaczenia, ale rzeczywistość jest taka, że we wszystkich scrumowych projektach dochodzi do patologii z nim związanych.
Ja mówię o samej praktyce. Tak jakoś wyszło, że wszystkiego się uczyłem z praktyki. A cały Scrum jest o nią operty.
Nigdzie jako Scrum Master nie dopuściłem do sytuacji by było to narzędzie dla managementu czy jakkolwiek wynoszone poza zespół. Jeśli zespół jest za to pałowany to ktoś nie robi swojej roboty. To jest dla zespołu. Koniec i kropka :) Przyznaję, dwa razy lata temu pokazałem to na Review. I zobaczyłem jakie to było głupie. Na tym też polega eksperymentowanie. Nikt nie jest wyrocznią :)
Najczęściej jest to dopychanie kolanem pod koniec sprintu, ale też fundamentalistyczna odmowa pracy nad zadaniem, które blokuje wszystko inne, ale nie możemy go ruszyć, bo zapomnieliśmy go zaplanować na sprint. Kiedyś nawet ja się tym strasznie przejmowałem, żeby mój zespół miał ładny wykres spalania, za co przepraszam.
No ale o czym Ty piszesz? :D Przecież jak jest coś krytycznego i jest to decyzja PO, że jest to krytyczne to takie rzeczy są wciągane. Zespół Scrumowy nie żyje w próżni np. nie olewa SLA utrzymania produktu. Dlatego zespołom zawsze mówię by nie brały pod korek. A jak PO chce wypełnić taczkę tak, że się g**no z niej przelewa mówię by dołożył drugie tyle bo czemu nie? Skoro wiadomo że i tak g_wno dojedzie to idźmy na całość :D
Wiem, wiem, że zaraz odpowiesz, że w prawdziwym Scrumie to tak nie wolno. Analogicznie do socjalizmu, który jest idealnym systemem, ale jakoś tak zawsze słabo wychodzi implementacja.
Nie, nie odpowiem. Nie jestem kapłanem, wyznawcą, nie odprawiam czarów, nie organizuje ceremonii i nie latam na kolorowych post-itach po biurowcu.
To do tego nie służy, a jak ktoś tego używa niezgodnie z przeznaczeniem to robi źle. I nie mówię, źle bo źle tylko dlatego, że to służy do czegoś innego. I cokolwiek zespołom nie mówię to W ŻYCIU nie powiedziałem "A bo w Scrum Guide jest napisane, że tak i tak". Znam takich, ale tego nie robię. Sam tłumaczę cel każdego spotkania i zadaję pytania.
Swoją drogą z kim będąc w USA masz problem. Rękawicę kuchenną jest napisane "don't etc" a jakiś koleś wcina posolone - do kogo masz pretensje, do producenta rękawicy czy do nieogara kolesia?
No i dalej. Czemu tak koniecznie Scrum? Jeden z moich zespołów pracuje w Kanbanie, i jest dobrze. Możliwości jest mnóstwo. Masz ramy i masz cały parasol agile i lean. Do wyboru do koloru. W zależności od kontekstu i potrzeb.
Bo może są obiektywne przyczyny, dla których nie da się zarezerwować czasu recenzentów. Nie każdy kod, który piszę, jest kontrolowany przez mój zespół. Np częścią zadania może być poprawka w projekcie OS na githubie, albo zmiana wymaga opinii germańskiego ciemiężcy. Trzeba poczekać na akceptację właścicieli i w ramach planowania uwzględnić takie potencjalne obsuwy.
No to lipa. Pytanie czemu to tak działa i czy nie można z tym czegoś zrobić? Przykładowo jeśli owy zespół zaciąga dużo rzeczy do sprawdzania niech ustawi sobie dyżurnych do takich rzeczy. Jeśli to mniejsza struktura, a sytuacje są incydentalne, prośba na Slack powinna wystarczyć. Jeśli dev nie daje rady prosi o pomoc PO (bo mu zależy) czy SM (bo odpowiada za proces).
Ale skąd założenie, że jedno story zamknąć w 1 dniu? Skąd się te wszystkie rzeczy biorą :D
Od ewangelistów Scruma. Pierwszy lepszy scrum guide (scrumguides.org):
For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less.
Już wiele razy dostawałem prośby o dzielenie tasków na mniejsze podzadania, żeby dało się je lepiej planować, bo tak będziemy bardziej Agile. Ja tak nie umiem. Jak podzielę pracę na podzadania dwugodzinne, to 20% czasu zmarnuję na obsługę tego w JIRA, a i tak się okazuje, że mój podział sensu nie ma i robię wszystko na raz.
No ale dalej, gdzie masz napisane, że masz to robić. Nie wiem czy wiesz, ale sam Guide zgodnie z zasadą inspect and adapt o czym pisał CI już @Charles_Ray także jest zmieniany. Czemu? Przez właśnie wyznawców każdego słowa. Tam jest napisane "often done". Nie masz to wymagane. Ja sam o to nie cisnę. Zespół na koniec planowania ma PO i SM przedstawić plan realizacji Sprintu. I są ludzie, którzy lubią to sobie rozpisać na podzadania (bez purystycznego podejścia że ma być na max. 1 dzień), a są ludzie, którzy tego nie lubią.
Natomiast tu jest jeszcze inny case, własne doświadczenia jako początkujący SM. Jeden dev, senior dev. przez 3 tygodnie przychodził na Daily i mówił to samo. "To jest już prawie skończone". I ewolucje tego. "Zostało tylko dopisanie dwóch testów", "Nie skończyłem bo napotkałem na jeden problem". I tak przez 3 tygodnie xD Nawet % sypał na początku, że już 70, 80, 95, no prawie.
Pomijam już fakt, że całe te planningi, estymaty i podobne to zwyczajne zawracanie d**y i zabieranie czasu który mógłby z pożytkiem być przeznaczony na kodowanie, pisanie testów, refactoring, czy chociażby chwilę również istotnego odpoczynku.
Dorzućmy jeszcze do tego by nie gadać. Przecież nie po to został ktoś developerem za #15k by z ludźmi gadać. A w kiblach zamontować zagłuszacze Wi-Fi i sieci komórkowej - szybsze sranie, lepsze zdrowie devów bo mniej hemoroidów ;) I więcej czasu na kodowanie*.
Bez jaj. Kiedyś poproszono mnie o pomoc w takim agileowym zespołe pracującym według metodyki "pożar w burdelu". Nie ma w tym nic złego jeżeli ktokolwiek panuje nad priorytetami i generalnie organizacją. Ale tutaj zasadniczo było tak, że gdzie się bardziej pali na PROD, gdzie który Pan z biznesu mocniej mordę drze, tam zespół kieruje sikawki z wodą. "Utylizacja zasobów" była tak wielka, że po jakimś czasie wchodzenia w temat (najpierw jako obserwator) na osobności ludzie z zespołu mi mówili: tu naprawdę jest tak, że jest taki chaos, że realnie udajemy, że z taczką biegamy, a ona jest realnie pusta - zmiana priorytetów jest taka, że nic nie dowozimy. I chcieli czegoś spróbować, chcieli to usystematyzować. I nagle okazało się, że biznes jest w ogóle nieprzygotowany do rozwoju. Nie ma rzeczy określonych. Planning obnażył ich nieprzygotowanie.
Bo jest taka rzecz, którą niektórzy mówią a ja się z tym zgadzam z własnego doświadczenia. Scrum jest trudny do opanowania i sam w sobie nie rozwiązuje problemów, ale sprawia, że stają się one widoczne.
Co do czasu. 2 zespoły pracujące nad jednym produktem w Sprintach 2 tyg. Klasyka. Przegląd trwa 1,5h (pokazanie roadmapy, celów sprintów, zaprezentowanie co zostało zrobione, omówienie dalszych kroków, update backlogu). Planowanie OBU zespołów trwa 2h. Zespoły najpierw wspólnie dzielą się rzeczami a potem rozchodzą się na swoje Planningi. Retro osobne a potem wspólne, 2h. Wszystko Ci się zamyka w 5,5h w ciągu dwóch dni. Do tego Daily i na całość Ci wychodzi 10% czasu. Oczywiście refinementy w zależności od potrzeb PO czy zespołu dodatkowo.