Śledzimy scrum w naszym projekcie. Widzę, że większość razy scrum master przydziela nam zadania. Jednak czytam z wielu książek o scrumie, że scrum działa na odwrót (podejście „pull”), a członkowie zespołu wybierają zadania lub funkcje. Czy scrum master przypisuje zadania poprawnemu podejściu, czy też jest sprzeczne ze zwinną ideologią?
project-management
agile
scrum
prasonscala
źródło
źródło
Odpowiedzi:
Zgodnie z artykułem Wikipedii o Scrumie , zadania Sprint nie są przypisywane przez ScrumMaster:
Co więcej, definicja ScrumMaster jest taka, że on / ona jest osobą odpowiedzialną za upewnienie się, że ludzie przestrzegają zasad procesu Scrum.
ScrumMaster nie przypisuje zadań, prostych i prostych. Zespół samoorganizuje się i decyzje o tym, kto pracuje nad tym, co decyduje zespół.
To jest prawdziwy Scrum. Jednak wiele organizacji może oczywiście korzystać z ich odmian.
źródło
Tak to powinno działać, ale tak jak w przypadku wszystkich rzeczy, które działają świetnie w teorii ... nie zawsze tak naprawdę działa.
Są zależności, potrzeby klientów i sterowniki z zewnątrz. Niektóre rzeczy muszą zostać wykonane, aby można było pracować nad tym fantazyjnym widżetem, nad którym wszyscy chcą pracować.
Istnieją podstawowe umiejętności programistyczne, które można prowadzić od wewnątrz. Niektóre rzeczy są po prostu trudne, a niektórzy są po prostu lepsi. Jasne, pracując w nieskończonym przedziale czasowym, mogę pozwolić ci to rozgryźć; ale kiedy coś musi zostać zrobione, przypisanie do osoby, która jest na najlepszej pozycji, aby zrobić to najszybciej i najlepiej, to ta, która dostanie pracę.
I są też problemy z osobowością, takie jak przejęcie kontroli nad Scrum Master i / lub programistami, którzy nie mogą zawiązać własnych butów bez polecenia. Mój zespół ma na przykład jedno i drugie. Po prostu działa lepiej dla wszystkich, aby w takich przypadkach zignorować ten drobiazg o Scrumie.
Innymi słowy, nie rób tego, ponieważ proces mówi tak. Rób co działa. Pieprzyć resztę.
Oczywiście istnieje również inny podstawowy fakt ludzkiej egzystencji ... może nawet nie wiesz, kim tak naprawdę jest Scrum Master. Może to nie jest osoba o tym tytule. Może nawet nie masz.
źródło
Nigdy.
Scrum jest w tym całkowicie jasny. Zespół programistów, jako grupa, jest odpowiedzialny za uzupełnianie pozycji w rejestrze Sprint. Mają też całkowitą kontrolę nad tym, jak zajmują się tworzeniem oprogramowania i nikt nie może im powiedzieć, jak to zrobić.
Jako trener Scrum Master odgrywa rolę w wskazywaniu tego, gdy widzi, że Drużynie grozi utrata celów Sprinta z jakiegokolwiek powodu. Ale potem musi poprosić ich, aby wymyślili, jak sobie z tym poradzą, a następnie zejść im z drogi.
Innym podejściem może być pozwolenie Zespołowi na ukończenie Sprintu, pociągnięcie go do odpowiedzialności za brak wyników, a następnie umożliwienie omówienia go w Retrospektywie Sprint.
źródło
Jak każda ideologia, zdarzają się sytuacje, w których zbiór reguł trzeba wyrzucić lub ostrożnie zignorować.
Zastanów się, co wydaje się właściwe. Uważaj tylko, aby ktoś został de facto kierownikiem projektu - lub, co gorsza, zastraszanie ludzi do robienia pewnych rzeczy.
Istnieje duża różnica między alokacją zadań przez dyktowanie (MUSISZ zrobić X) a alokacją przez dyskusję i porozumienie. Czasami umowa może być letnia.
Z drugiej strony być może zespół potrzebuje kierowania ... trudno to wiedzieć.
Byłbym jednak zaniepokojony jakimkolwiek procesem, który nalegałby, abyś podążał za procesem do listu, bez miejsca na poruszenie lub osąd. Taki proces zastępuje myślenie.
źródło
Moim zdaniem scummaster nie powinien tego robić, członkowie zespołu powinni sami podejmować się zadań. Jeśli scummaster zajmuje się tylko administracją, jak ma to miejsce w naszym zespole, nie widzę problemu. Nasz Scrum Master dba o to, aby papierowa tablica scrumowa była zsynchronizowana z plikiem programu Excel. Rola pana scrum powinien być jeden ułatwianie my jesteśmy on / ona sprawia, że można zrobić swoją pracę bez przeszkód. To jest sposób, w jaki działa. Czy wiesz, dlaczego ScrumMaster to robi? Czy jest kierownikiem projektu, który boi się stać się nieaktualny? Czy boi się, że zespół sam nie odbierze zadań? Dobrym pomysłem może być omówienie tego podczas retrospekcji.
źródło
Byłem mistrzem scrum w obu typach środowisk (w których przekazywałem zadania poszczególnym osobom i gdzie poszczególne zadania pobierały zadania).
O zespole Push, zasoby programistyczne nie były wymienne. Praca klienta Windows musiała przejść do programisty systemu Windows, a praca w sieci do programisty sieci. Dzięki temu mogłem przekazywać zadania do zasobów podczas sesji planowania. Byłem także w stanie zaplanować indywidualne zdolności produkcyjne, aby wiedzieć, kiedy przestać naciskać.
Metoda ściągania działała dobrze w zespole, w którym każde zadanie mogło być odebrane przez dowolne zasoby. Ale nie mogłem samodzielnie zaplanować wydajności podczas sesji planowania, zamiast tego musiałem polegać na średniej prędkości, aby wiedzieć, kiedy wystarczy. (Minęło ~ 3-4 sprinty, zanim mieliśmy dobry pomysł na prędkość).
Natknąłem się na interesujący artykuł opisujący zalety / wady Push vs. Pull.
źródło