Czy w pojedynku z Scrumem dyskusja o tym, co zostało zrobione wczoraj, powinna ograniczać się do zadań na tablicy lub całej wykonanej pracy?

10

Wiem, że zasady Scruma w codziennych pojedynkach mówią, że zespół powinien rozmawiać tylko o tym, co zrobili wczoraj, o tym, co robią dzisiaj io wszystkim, co ich blokuje. Nic więcej. Problem polega jednak na tym, że czasami programiści spędzają dzień, wykonując pracę nieistotną dla swoich zadań, a następnie rozmawiają o tym w ramach projektu. Tak zrobili wczoraj!

Z mojego doświadczenia wynika, że ​​bardziej efektywne jest rozmawianie o zadaniach na tablicy, utrzymywanie koncentracji na pojedynku i skupianie się na swoich zadaniach, przeglądanie ich oszacowań i codzienne śledzenie zapisów.

Czy można ograniczyć dyskusję do zadań na tablicy?

Shadin
źródło
1
To, że programiści spędzają całe dni bez pracy nad zadaniami, może być problemem, który byłby niewidoczny, gdyby nie został wspomniany?
RemcoGerlich,
Wszyscy mówią 30 sekund, aby powiedzieć, co zrobili wcześniej. O ile bardziej chcesz tego? Zdajesz nie przeglądu szacunków. Śledzisz zadania, gdy przekazujesz je następnemu facetowi (recenzentowi lub testerowi).
gnasher729,

Odpowiedzi:

5

Zgodnie z treścią Przewodnika Scrum na temat codziennych pojedynków trzy pytania do dyskusji to:

  • Co zrobiłem wczoraj, co pomogło zespołowi programistów osiągnąć cel Sprint?
  • Co zrobię dzisiaj, aby pomóc zespołowi programistów osiągnąć cel Sprint?
  • Czy widzę przeszkodę, która uniemożliwia mi lub zespołowi programistów osiągnięcie celu sprintu?

Wszystkie pytania koncentrują się wokół celu sprintu, a nie zadań na tablicy. Ponownie, zgodnie z przewodnikiem Scrum, cel sprintu jest tworzony w planowaniu sprintu i definiuje „cel, który zostanie osiągnięty w ramach sprintu poprzez wdrożenie Backlogu produktu, i dostarcza zespołowi programistycznemu wskazówek, dlaczego buduje Przyrost".

Wszystko, co robi twój zespół programistów, powinno idealnie pomóc zespołowi w osiągnięciu celu sprintu. Mogą to być nieplanowane działania, których nie ma na planszy, które musiały zostać wykonane, lub mogą to być rzeczy na niższym poziomie, które mogły zostać wzięte pod uwagę i oszacowane, ale na niższym poziomie niż przedmiot na planszy.

Powiedziałbym, żeby twój zespół mówił o wszystkim, co robili wczoraj. Jeśli mówią o rzeczach, które nie pomagają zespołowi w osiągnięciu celu sprintu, to ktoś powinien to poruszyć, zwłaszcza jeśli istnieją inne rzeczy, które mogłyby zrobić, które zbliżyły zespół do osiągnięcia celu sprintu.

Jednym wyjątkiem może być sytuacja, gdy osoba wspiera wiele zespołów Scrumowych. Podczas spotkania prawdopodobnie nie powinni rozmawiać o wszystkim, co zrobili wczoraj, ale o tym, co zrobili, aby wesprzeć zespół, który obecnie zajmuje pozycję.

Sprint Retrospective to doskonała okazja, aby porozmawiać o tym problemie z zespołem. Jest wiele pytań do rozważenia:

  • Czy zespół nie jest zajęty przedmiotami związanymi z celem sprintu?
  • Czy jest za dużo nieplanowanej pracy?
  • Skąd pochodzi nieplanowana praca i kto ją autoryzuje?
  • Dlaczego ludzie pracują nad rzeczami, których nie ma na tablicy?
  • Czy powinniśmy pokazywać więcej szczegółów na tablicy, aby łatwiej wiązać rzeczy, które robisz z przedmiotami na tablicy?
Thomas Owens
źródło
2
problem z „celem sprintu” jest zbyt niejasny i życzliwy. w praktyce Cel sprintu == wykonaj zadania na tablicy. jeśli nie pracujesz nad tym, nad czym pracowałeś, albo nie powinieneś nad tym pracować
Ewan
1
@Ewan Klient dzwoni i mówi nam, że oprogramowanie na żywo uległo awarii i mamy dziennik i raport o błędzie. Ważne jest, aby poświęcić trochę czasu na natychmiastowe segregowanie tego raportu, nawet jeśli nie ma go teraz na tablicy. Może być objęty zakresem lub zaległy, ale jest to coś, co zrobiłem wczoraj i może dlatego nie mogłem pomóc Bobowi z jego problemem aż do lunchu. Nie powinienem wykonywać tego zadania na ślepo, ale prawdopodobnie nikt nie umieści go na planszy, chyba że zostanie wciągnięty do tego sprintu. Mogę też wymyślić inne przykłady.
Thomas Owens
1
powinieneś dodać do tablicy bilet „triage live bug” i oznaczyć go jako gotowy. Na koniec sprintu możesz powiedzieć na pewno. „podczas tego sprintu spędziliśmy X godzin na sprawdzaniu błędów użytkowników. Dlatego się spóźniliśmy. musimy lepiej wyszkolić dział pomocy technicznej „Inaczej nie zrobisz nic, co przyspieszy, a premier po prostu usłyszy wymówki od zespołu” och, było mnóstwo błędów do obejrzenia w tym tygodniu! wzruszyć "
Ewan
1
@Ewan Myślę, że jest to niezwykle niepotrzebne. Nie chcę spędzać dnia na pisaniu biletów. Proces musi pozwolić mi na wykonanie mojej pracy i poświęcenie 90 minut na segregację zamiast 95 minut na segregację, a następnie wystawienie biletu, który powiedział, że segregowałem bilet, jest głupie. Zwłaszcza jeśli musisz segregować wiele biletów. Nie potrzebujesz biletów, aby dyskutować na różne tematy z perspektywy czasu. Jeśli używasz narzędzi elektronicznych, możesz znaleźć bilety zmodyfikowane przez zespół w Sprint, aby sprawdzić, czy jest wiele rzeczy do segregowania - nie ma tam żadnych informacji.
Thomas Owens
1
poziom raportowania, jeśli zależy to od twojego śmieciarza / pm / firmy. możesz po prostu napisać jeden bilet na „błędy w działaniu”, aby pokryć całą swoją pracę na cały dzień. Ale ważne jest, aby NAGRYWAĆ TO JAKO CZĘŚĆ WIOSNY. nie zakładaj, że jest to uwzględnione przez inną metrykę
Ewan
0

Nie, powinieneś porozmawiać o tym, co zrobiłeś wczoraj.

Jeśli nie ma go na planszy, musisz wykonać jedną z następujących czynności:

  • połóż to na tablicy,
  • przestań to robić
  • lub zmieniaj zespoły.

Najczęstszym, na przykład w przypadku nieplanowanej pracy w nagłych wypadkach, jest napisanie karty i przyklejenie jej do tablicy. Dzięki temu na końcu sprintu można zmierzyć prędkość i wyjaśnić, dlaczego cele sprintu nie zostały osiągnięte.

Członek zespołu pracujący nad rzeczami, których nie ma w sprincie, jest moim zdaniem jedną z głównych przyczyn niepowodzenia zwinnych adopcji. Najczęściej jest to programista skierowany do rozwiązywania problemów na żywo w innym projekcie.

Inną irytującą rzeczą w sprintach jest „premier mówi o spotkaniach dla innych projektów”. Moim zdaniem PM nie należy do zespołu Scrum, pełnią rolę Scruma „Product Owner”, a zatem są tam, aby odpowiadać na pytania, a nie zgłaszać postępy.

Ewan
źródło
3
Istnieje coś takiego jak nieplanowana praca - praca, którą należy wykonać, aby odblokować kogoś lub wykonać inne zadania na tablicy, ale nie ma jej na tablicy. Często szybsze jest zrobienie tego niż umieszczenie go na planszy. Zespół musi przedyskutować, jak sobie z tym poradzić. Mój obecny zespół ma zasady - wszystko, co jest wdrażane w środowisku produkcyjnym lub kontroli jakości, lub zadania, które wymagają 2 godzin pracy. Czasem trzeba jeszcze wykonać krótsze zadania, o których się mówi, ale nie należy tworzyć tablicy, ponieważ nie spełnia ona kryteriów.
Thomas Owens
@Ewan, czy możesz to rozwinąć? Kto zajmuje się naprawianiem żywych błędów, jeśli nie ma ich w sprincie? W jaki sposób Właściciel Projektu może jednocześnie być Project Managerem? (Mam na myśli, kim on jest, czy też żongluje obiema rolami)
Dennis,
zredagowane dla jasności
Ewan,
@Dennis: Project Manager nie jest rolą Scruma.
RemcoGerlich,
@Ewan, dzięki. Nie ma to zasadniczego znaczenia dla odpowiedzi, ale jestem ciekawy - jak „premier mówi o spotkaniach dla innych projektów”, jak to działa? Czy premierzy spotykają się na temat projektu X, ale mówią o Y? Trudno mi to sobie wyobrazić. Jak / dlaczego to jest możliwe? Czy masz na myśli, że przychodzą i zasadniczo zaczynają plotkować lub odchodzą od tematu, czy jest głębszy powód, aby mówić o nie-natychmiastowych celach / potrzebach związanych ze spełnieniem? Powiedziałbym: „hej, miło to słyszeć, ale nie jestem częścią projektu Y ... brak wiedzy / doświadczenia, czy możemy wrócić do X?”
Dennis