Scrum codziennie - zadaj 3 pytania każdemu programistowi lub przejdź przez bilety?
Jesteśmy małym zespołem około 5 programistów.
Używamy systemu zarządzania biletami, który ma wirtualny Scrumboard.
Na tablicy Scrumboard znajduje się kilka kolumn. Elementy w kolumnach są sortowane według priorytetu:
New | Consultation | Working | Waiting | Test & Review | Done
Konsultacja = potrzebujemy opinii od kogoś z zewnątrz
Czekanie = czekanie na kogoś lub na coś
Mamy około 40-50 aktywnych biletów podczas dwutygodniowego sprintu.
W standardowym dzienniku Scruma zwykle każdy programista odpowiada na 3 pytania:
Co ja zrobiłem wczoraj?
Co ja dzisiaj zrobię?
Jakie są moje przeszkody?
Jakoś nasz proces jest inny:
Idziemy kolumną, a potem każdym biletem w kolumnie.
Robimy to z kilku powodów:
- ten proces rozwijał się samoistnie, nie planowaliśmy go, po prostu się wydarzył
- niektórzy programiści „odstępowali”, gdy inni mówili, a nie słuchali. Tak, zwykle jest to tylko 15 minut dziennie, więc można się spodziewać, że słuchanie przez ten czas powinno być możliwe. Ale ponieważ wszyscy pracujemy w domu, nie możemy zauważyć, czy ktoś słucha, czy nie.
- kiedy programista skończy zadawać swoje 3 pytania, może nie słuchać innych, ponieważ jego uwaga zniknęła
- programista jest widoczny na bilecie, ale wyszukanie własnego nazwiska w celu znalezienia biletów, nad którymi pracujesz, zajmuje trochę czasu. Istnieją sposoby na zmianę widoku, ale ciągłe przełączanie widoku staje się dość szybko irytujące dla wszystkich
- jeśli pójdziemy przez dewelopera, czasami podczas prezentacji przeoczył ważny bilet
Przechodzenie przez kolumny i bilety wydaje się bardziej „naturalne”, a także każdy wydaje się bardziej aktywny w słuchaniu, ponieważ następny bilet może być jego lub jej. Nie pomijamy też żadnych ważnych szczegółów ani biletów. W większości przypadków deweloperzy pośrednio odpowiadają w ten sposób na 3 pytania, ale nie zawsze. Ten proces nadal wydaje się nieco lepszy - przynajmniej w naszym środowisku!
Czy więc ZAWSZE należy odpowiedzieć na 3 pytania, czy też należy skorzystać z biletów?
Czy jest sposób, aby stwierdzić, które podejście jest „lepsze”?
(Może to zdjęcie pomoże zrozumieć moje pytania)
Odpowiedzi
Czy więc ZAWSZE należy odpowiedzieć na 3 pytania, czy też należy skorzystać z biletów? A może jest sposób, aby stwierdzić, które podejście jest „lepsze”?
Wersja przewodnika Scruma z 2020 r. Usunęła trzy pytania, podczas gdy wersja przewodnika z 2017 r. Mówi tak:
Struktura spotkania jest ustalana przez Zespół Deweloperski i może być prowadzona na różne sposoby, jeśli skupia się na postępach w kierunku Celu Sprintu. Niektóre zespoły deweloperskie będą używać pytań, inne będą bardziej oparte na dyskusjach.
Zrób więc to, co uważasz za najlepsze lub zapytaj swój zespół, co wolą i uznają za bardziej przydatne.
Te trzy pytania są przykładem tego, jak można przeprowadzić codzienne zajęcia, ponieważ koncentrują się one w dyskusji na podstawowych zagadnieniach, które należy omówić, aby skoordynować wysiłki na rzecz celu. Jeśli uważasz, że omawianie biletów jest lepszym podejściem, to idź z tym.
Tylko upewnij się, że nie zgubiłeś się w zbyt wielu szczegółach (zawsze możesz omówić bardziej szczegółowo po codziennym) i wyjdź poza ramy czasowe, co z kolei sprawi, że wszystko przekształci się w spotkanie i da ludziom więcej okazji do mentalnej kasy.
TL; DR
Czy powinieneś chodzić po tablicy według programisty lub kolumny? Ani. Oba są anty-wzorcami.
Nie traktuj standupu jako wyciągnięcia statusu ze strony zespołu, a na pewno nie używaj go jako mini-przeglądu statusu każdego zadania zaplanowanego na cały Sprint. Jeśli utrzymasz zakres standupu na poziomie pracy z bieżącego dnia, pytanie, jak najlepiej „chodzić po planszy” (wskazówka: nie ma, bo nie powinieneś tego robić) znika.
Skoncentruj się na koordynacji zespołu
Twoje pytanie zaczyna się od fundamentalnie błędnego założenia: że wykonanie raportu o stanie wszystkich zgłoszeń jest korzystne lub nawet pożądane w Scrumie. To naprawdę X / Y problemem jakim zespół brakuje cały punkt dziennego standup, która ma wykonywać planowania i koordynacji just-in-time dla działań codziennych.
„Trzy pytania” to tylko sposób na osiągnięcie celu. W mniej dojrzałych zespołach posiadanie wskazówek lub punktów do omówienia może pomóc członkom zespołu zidentyfikować zależności między zadaniami. Celem nie jest jednak dostarczanie raportu o stanie. Celem jest zawsze pomoc zespołowi w planowaniu pracy na bieżący dzień. Na przykład:
Sandy: Wczoraj pracowałem nad usprawnieniem centralnego widżetu. Dzisiaj muszę włączyć mały trybik, ale potrzebuję do tego wszystkiego, co zrobiła Susan.
Susan: Wczoraj skończyłam whatchamacallit, więc jest gotowa na Sandy. Dzisiaj chciałem popracować nad frobnostykatorem, ale utknąłem do zakończenia historii MacGuffina. Czy ktoś już nad tym pracuje?
Innymi słowy, nie używaj codziennego wstawania do „chodzenia po desce”. Użyj go, aby umożliwić zespołowi samoorganizację wokół codziennej pracy! Jeśli pytania pomogą zespołowi to zrobić, świetnie. Jeśli nie, rzuć je.
Podobnie tylko prace już w toku lub zaplanowane na dany dzień powinny być omówione na stoisku. Praca w zaległości Sprint lub stanie oczekiwania ma znaczenie tylko jeśli jest to zależność od aktualnego zadania, bloker na coś innego, albo ktoś planuje wyciągnąć go jako work-in-progress dzisiaj .
Jeśli naprawdę chcesz uzyskać status Sprintu, wykorzystaj swoją kolumnę Gotowe i wykres wypalenia, aby określić, czy jesteś na dobrej drodze do osiągnięcia celu sprintu. Jeśli status Celu Sprintu jest kwestionowany, to prawdopodobnie zasługuje na osobne spotkanie poza codziennym standupem i zdecydowanie na uwagę całego Zespołu Scrumowego podczas następnej Retrospektywy Sprintu. W najlepszym przypadku chodzenie po tablicy jest przerwą, aby ukryć nieefektywną komunikację lub brakujące / nieprawidłowe promienniki informacyjne. W najgorszym przypadku aktywnie uniemożliwia zespołowi współpracę przy planowaniu dokładnie na czas, preferując raportowanie stanu nad interakcjami między członkami zespołu.
Podejście oparte na trzech pytaniach koncentruje się na jednostce, ale podejście planszowe koncentruje się na zespole i celach sprinterskich. (Lub przynajmniej cel po prawej stronie tablicy.) Z mojego doświadczenia wynika, że pułapka trzech pytań polega na tym, że dana osoba czuje, że musi udowodnić, że pracowała. Ale wybierając bilety, możesz nawet nie rozmawiać z każdą osobą.
Jak wspomniałem powyżej, co jest lepsze, zależy od twoich celów.
Jeśli zespół jest spójny, a tablica odzwierciedla ścieżkę do celu, to zdecydowanie użyj tablicy. (Proponuję pójść dalej i użyć tablicy wyraźnie od prawej do lewej: skupienie się na ukończeniu rzeczy.)
Ale jeśli zespół jest nowy lub jeszcze nie współpracuje dobrze ze sobą lub jeśli tablica nie reprezentuje celu, to trzy pytania mogą być lepszym rozwiązaniem. Celem sprintu może być w rzeczywistości „zmusić ten nowy zespół do żelowania” lub „na pokładzie Frankie, aby była skuteczna”. Jeśli tak jest, na pewno chcesz mieć pewność, że każdy ma szansę porozmawiać o tym, co robi i co działa, a co nie.
Czy jest sposób, aby stwierdzić, które podejście jest „lepsze”?
Jedną z rzeczy w programowaniu Agile jest to, że oferuje elastyczność w zakresie celów projektu i organizacji. Jedną rzeczą, dzięki której możesz być elastyczny, jeśli chodzi o sposób wykonywania codziennych zadań, jest iteracyjne ulepszanie go. Zbieraj opinie od swojego zespołu, omawiaj codzienną strukturę podczas retrospektywy sprintu i nie bój się eksperymentować z sugestiami zespołu.
Obecnie pracuję w zespole, w którym faktycznie mamy oba podejścia - oboje mamy codziennie zorientowane na zadanie i codziennie „trzy pytania”. Pierwsza to dziesięć minut dziennie między programistami na omówienie aktualnej tablicy i zapewnienie miejsca na kilka uwag technicznych; druga to piętnaście minut dziennie, które są znacznie bardziej skoncentrowane na „trzech pytaniach”, aby mieć bardziej ludzki codzienny kontakt z szerszym zespołem.
Codziennie zajmowaliśmy się programistami i ich zadaniami, ale zdecydowaliśmy się zrezygnować z tego procesu z powodów, o których wspomniałeś, dotyczących koncentracji, obaw o czas i braku spójnego zrozumienia statusu powiązanych zadań. I tak, ciągłe filtrowanie zadań przez programistę było dla nas kłopotliwe.
Nie mogę komentować, więc dodałem moje dwa centy jako odpowiedź.
Jeśli mogę zasugerować: „te trzy pytania” mogą być „wpatrywanie się w twój pępek”, podczas gdy naprawdę chcesz, aby wszystkie „rozglądały się”.
Pierwszą rzeczą, którą bym zrobił, to znaleźć sposób na pogrupowanie listy zadań w taki sposób, który pozwoli Ci wygodnie rozważyć powiązane zadania w sposób „przydatny w biznesie”. (Poza tym znajdź funkcjonalny sposób „oznaczania” zadań, które mogą być związane z więcej niż jedną grupą. W oprogramowaniu wszystko jest zwykle w jakiś sposób powiązane ze wszystkim innym).
Następnie poprosiłbym zespół o rozważenie każdej grupy razem z wami i pomoc Wam wszystkim w wyborze (!), Co - w drodze wzajemnego i świadomego konsensusu - powinno być „trzema pytaniami na dany dzień” zespołu.
Z jednej strony programiści nauczyli się nabywać nadzwyczajnych umiejętności skupiania się na wszystkim, co jest problemem dnia. Można powiedzieć, „dokładnie wiedzą, jak nurkować głęboko i pozostać w dole”. Ale - mówiąc teraz z własnego doświadczenia - okropne jest uświadomienie sobie, zbyt późno, że nie wiedziałeś, że zanurzyłeś się głęboko w niewłaściwym miejscu z niewłaściwego powodu i po prostu zostałeś wessany przez huragan. „Gdybyś wiedział ...”
I tak fundamentalna kwestia jest jasna: skoro deweloperzy są - i muszą być - „nurkami głębinowymi”, to kto zawsze siedzi na łodzi, zawsze suchy, zawsze obserwuje duży obraz? Wypatrujesz rekinów? Pomagając im wiedzieć, kiedy wiosłują po powierzchni, gdzie i dlaczego nurkować dalej? To byłbyś ty.
Teraz - aby dokończyć myśli - czasem te nurków wróci na powierzchnię z jakiegoś ważnego nowym odkryciu, że ty nie mógł wiedzieć. Zawsze pozwól programistom samodzielnie dodawać „bilety” do Twojego miksu.
Jak wspominali inni, Przewodnik po Scrumie nie określa już trzech pytań. I szczerze mówiąc, większość codziennych scrumów opartych na 3 pytaniach jest sprzeczna z celem wydarzenia. Kiedy jest zaaranżowany przez Scrum Mastera, a członkowie zespołu muszą zdać raport z ostatnich 24 godzin, co oznacza 0% samoorganizacji. Nie spowoduje to prawdziwej inspekcji stanu Sprintu i planowania dnia w duchu pomyślnego osiągnięcia Celu Sprintu. Powinna to być wewnętrzna dyskusja zespołu programistów, w której członkowie zespołu są zainteresowani własnym sukcesem.