Codzienne awarie - tak czy nie? [Zamknięte]

40

Jak myślisz, jak cenne (lub nie) są codzienne spotkania stand-up ?

Jeśli nie znasz go, odnosi się to do codziennego spotkania, które jest częścią zwolenników Scruma (i innych zwinnych metodologii). Chodzi o to, że odbywasz codzienne spotkanie z 15 minutami, w którym każdy musi stać (aby zachęcić ludzi do rzeczy).

Na spotkaniu chodzisz po pokoju i każdy mówi: - Co zrobiłeś wczoraj - Co planujesz robić dzisiaj - Wszelkie blokery lub przeszkody w twoich postępach.

Czy uważasz, że ta praktyka ma wartość? Czy ktoś pracował w miejscu, które to zrobiło i co myślałeś?

Fishtoaster
źródło
1
Codzienne spotkania stand-up
yegor256

Odpowiedzi:

40

W mojej pierwszej pracy mieliśmy codzienne awarie. Cóż, przy wszystkich spółdzielniach / stażystach / tempach było tak naprawdę na dłuższą stronę - zwykle około 30 minut.

Ale pomysł krótkiego, codziennego spotkania z tim timingsem bardzo pomógł po prostu dowiedzieć się, na czym utknęli inni ludzie - a jeśli to było coś, nad czym pracowałem, mógłbym zmienić priorytety moich zadań, aby zakończyć to, czego potrzebowali, aby kontynuować wcześniej. Dało to również wszystkim szansę na sprawdzenie, nad czym wszyscy pracują, więc jeśli ktoś miał awarię, wszyscy byli przynajmniej świadomi tego, co się dzieje - zmniejszenie czynnika ciężarówki jest zawsze dobrą rzeczą.

Szczerze mówiąc, w niektórych przypadkach każdy dzień może być trochę ekstremalny. Ale pomysł krótkich, regularnych spotkań dla wszystkich, aby pozostać na tej samej stronie, jest cennym dodatkiem do każdego procesu.

Thomas Owens
źródło
4
Uznałem to również za bardzo pomocne w komunikacji, ale musisz także upewnić się, że zdefiniowałeś zadania, które są na tyle małe, aby można było zobaczyć postępy. W przeciwnym razie ludzie mówią „pracując nad interfejsem użytkownika” przez cały miesiąc, co nie jest zbyt pomocne. Proponuję przeczytać książkę Scrum / Agile i spróbować wdrożyć cały proces, a nie tylko spotkanie.
JD Frias,
1
Myślę, że niezbędne jest zachęcanie do produktywnego i uczciwego środowiska pracy, w którym wszyscy koncentrują się na tym samym. Zgodnie z tym, co powiedział J8D, codzienne wstawanie jest znacznie poprawione, jeśli możesz to zrobić przed tablicą zadań, więc kiedy ludzie powiedzą „Wczoraj pracowałem nad xyz”, możesz fizycznie wskazać ten element pracy na tablicy i zobacz, jak postępuje od lewej (nie zrobione) do prawej (zrobione) w nadchodzących dniach. Naprawdę pomaga zidentyfikować blokerów i zapewnia wszystkim uczciwość.
dwynne
1
Wygląda na to, że twoje spotkania wymagają większej struktury. Konfrontacje nie są miejscem dyskusji lub dyskusji. Powiedz, nad czym pracujesz, i powiedz komuś, czy będziesz potrzebować pomocy. Ludzie mogą zadawać pytania, aby upewnić się, że nie wybierasz się na niewłaściwą ścieżkę lub nie robisz kodu, którego nie potrzebujesz, ale to wszystko. 10 minut. MAX.
Jaco Pretorius
2
@Thomas Owens Brzmi dobrze, każda sytuacja jest wyjątkowa. Chciałbym zapytać, czy naprawdę muszę wiedzieć, co robi 17 innych osób. Na przykład często zapraszamy testerów do pojedynków, ale przeważnie są tylko tam, aby je obserwować.
Jaco Pretorius
2
Mamy pojedynki, ale w mniejszych grupach 3-7 osób. Myślę, że zbyt wielu ludzi stojących na stojąco to zły pomysł
Nikt
30

Uważam te spotkania za bardzo cenne. Oferują następujące korzyści - w zamian za poświęcenie zaledwie 15 minut!

  • Utrzymuje wszystkich na temat . Łatwo jest zagłębić się we własne problemy i zapomnieć o tym, co robią inni, lub powtórzyć pracę wykonaną przez kogoś innego. Codzienne spotkania zapobiegają temu.
  • Nie pozwala ludziom zwalniać . Na tych spotkaniach składasz obietnice. Wtedy właśnie ty musiał starać się je zachować.
  • Sprawia, że ​​ludzie wchodzą w interakcje . Programiści zwykle nie lubią rozmawiać z ludźmi. Jednak na takich spotkaniach otrzymują zachęty (i nagany) od swoich kolegów, co ma pozytywny wpływ na morale.
  • Zbiera wszystkich w jednym miejscu . Otrzymujesz premię za to, że wszyscy tam przyjdą. Można to wykorzystać do umawiania innych spotkań, ogłaszania ogłoszeń i kontynuowania codziennego spotkania w mniejszych grupach w celu omówienia konkretnych problemów. Zwykle organizowanie takich spotkań wymaga dużej uwagi i wymaga umiejętności, których programiści nie lubią.
Pavel Shved
źródło
26

Mogę wytrzymać godzinami bez końca. Nie czyni mnie to do rzeczy ani nie ma żadnego realnego znaczenia / wpływu na krótkie codzienne spotkanie nadrabiające.

Ale hej, jeśli wstawanie pozwala ci na zmianę marki czegoś zwinnego, to musi być dobrze!


Jeśli chodzi o to, czy regularne spotkania nadrabiające w ogóle są dobrym pomysłem ... cóż, pomagają, jeśli inne procesy są nieskuteczne.

Jeśli chcesz wiedzieć, co ktoś zrobił wczoraj i jakie są następne zadania, spójrz na narzędzie do śledzenia problemów, w którym jest już zarejestrowane. Jeśli nie ma wyraźnego filtru, który mówi o tym całemu zespołowi, skonfiguruj go (lub znajdź lepsze oprogramowanie).

Jeśli chcesz wiedzieć, czy ktoś ma jakieś programy blokujące, sprawdź swoje wiadomości (e-mail / im / forum / cokolwiek). Jeśli ktoś je ma, powinien powiadomić zarówno odpowiednią stronę, jak i kierownika projektu, kiedy wystąpią, nie marnując dnia na czekanie, aż ktokolwiek się dowie, i nigdy nie ma szansy na działanie.


Z pewnością korzyścią są regularne spotkania w celu omówienia kierunków projektu - w ogólnym sensie, a nie w szczegółach, aby upewnić się, że wszyscy rozumieją ogólne cele i tak dalej - i odbywają się co tydzień lub co dwa tygodnie (w zależności od tempa rzeczy).

Ale spędzanie kwadransa każdego dnia, żebyś czuł się zwinny, wspaniały i tak dalej? Strata czasu.

Peter Boughton
źródło
1
-1 Klasyczna odpowiedź „klasyczna”. Szkoda, że ​​przegapiłeś. -Stand-up to utrzymanie tempa i energii - 15min timebox, aby uniknąć marnowania czasu na „spotkanie statusu”. - 3 pytani są tylko przewodnikiem, celem spotkania jest rozmowa o produkcie / projekcie
Rudi
10
÷ 1 Uważam, że rozpęd jest łatwiejszy, gdy faktycznie coś robię i nie udawanie spotkania statusowego nie jest spotkaniem statusowym, ale czymkolwiek - chyba musimy zgodzić się z tym. :)
Peter Boughton
17

Z mojego doświadczenia wynika, że ​​stand-upy nie były tego warte, szczególnie na co dzień. Są jedną z dwóch rzeczy: pustym rytuałem lub nieukierunkowanym spotkaniem ad-hoc.

  1. Pusty rytuał: każdy krąży wokół koła i określa zadanie, nad którym pracuje, i postępy. Nikt tak naprawdę nie dba o to, nad czym pracują inni i nic nie zostaje zrobione (w wyniku stand-up), jeśli występuje problem.

  2. Nieukierunkowane spotkanie ad-hoc: ktoś (zwykle kierownik, szef rządu lub ktoś z firmy) przychodzi i wykoleja się. Może mówimy o dzisiejszym pożarze w najdrobniejszych szczegółach lub o tym, jak ktoś się niepokoi, jeśli dotrzymamy terminu itp. 15 minut zamienia się w pół godziny lub dłużej. Wszyscy stoją, nawet jeśli naprawdę powinniśmy siedzieć, jeśli to potrwa tak długo.

Ponadto „stand-up” część stand-upów nie pomaga w ustalaniu terminów spotkań, tylko dodaje fizycznego dyskomfortu do miksu.

Miałem znacznie lepsze doświadczenia z komunikacją ad hoc między członkami zespołu niż formalne stand-upy. Jeśli ktoś dba o to, nad czym pracujesz lub o twoje postępy, zapyta cię lub powiesz mu. Jeśli masz problem lub jesteś zablokowany, upewnij się, że wiedzą osoby, które muszą o tym wiedzieć. Jeśli wymaganie jest niejasne, odnajdź użytkownika biznesowego lub licencjata i zapytaj go o to.

Kaypro II
źródło
1
Byłem w obu grupach, w których spotkania stand-up (lub usiąść) albo stanowią wartość dodaną, albo nie są odpowiednie. Powiedziałbym, że porażka jest tym samym, co drugi punkt, który dajesz, że ktoś w zespole z mocą wykoleja się ze spotkania (i jest wobec tego pasywnie-agresywny).
Spoike
Dotyczy to również mnie „Miałem o wiele lepsze doświadczenia z komunikacją ad hoc między członkami zespołu niż formalne stand-upy. Jeśli ktoś dba o to, nad czym pracujesz lub o swoje postępy, zapyta cię, albo ty powiedz im. Jeśli masz problem lub jesteś zablokowany, upewnij się, że ludzie, którzy muszą o tym wiedzieć, wiedzą ”. .... pojedynki to nic innego jak rytuały!
Nawaz
8

Myślę, że są bardzo cenne, jeśli są wykonywane poprawnie. Format, który działał dla mnie dobrze to:

Każda osoba udziela krótkiej odpowiedzi na następujące pytania.
a) Nad czym pracujesz?
b) Co zrobisz na następnym spotkaniu (jutro)?
c) Czy osiągnąłeś to, co powiedziałeś, że zrobisz na ostatnim spotkaniu?
d) Jakie przeszkody spowalniają / hamują twój postęp?

Wszelkie obszerniejsze dyskusje na ten temat powinny zostać ograniczone podczas spotkania, aby było krótkie. Każdy może zostać po (lub spotkać się później), aby omówić z odpowiednią osobą (osobami) wszystko, co wymaga przedłużonego zasięgu.

Osiąga to następujące cele:
a) Kierownik zespołu / właściciel produktu jest na bieżąco w sprawie możliwych opóźnień.
b) Kierownik zespołu może szybko usuwać przeszkody.
c) Kierownik zespołu może szybko zidentyfikować osoby obracające się na kołach.
d) Zachęca do współpracy między członkami zespołu, którzy mogą być zbyt zamknięci w sobie, aby prosić o pomoc, kiedy jej potrzebują.
e) Zachęca do rozpędu poprzez utrzymywanie krótkich zobowiązań (minimalizuje wydłużenie prac do czasu dostępnego na projekt).

JohnFx
źródło
Nie powinieneś potrzebować odpowiedzi c, nie prosisz ludzi o „zgłoszenie się” do zespołu, a raczej rozmowę ze sobą. (a, bid) - Spotkanie NIE jest dla lidera zespołu, tylko dla samego zespołu!
Rudi
Kierownik zespołu JEST członkiem zespołu.
JohnFx
8

Nie uważam ich za przydatne, jak to praktykowane w moim miejscu pracy, gdzie „Codzienny 15-minutowy postój” rozciągał się do 30, potem 45, a teraz często 60 minut; gdzie wszyscy siadają, czekając, aż kierownik projektu zacznie majstrować przy projektorze, udziale sieciowym lub czymkolwiek innym przypadkowym demonem dnia; gdzie nalega, aby wszyscy poświęcili czas na dostarczenie aktualizacji statusu przed spotkaniem, ale następnie ponownie zapytał wszystkich (na wypadek, gdybyśmy osiągnęli coś innego w ciągu ostatnich kilku chwil); Pozostała tylko część oryginalnej koncepcji „Daily”.

Nie rób tego

AShelly
źródło
1
Oczywiste jest, że nie są one użyteczne w tym, co się zmieniło. Dokładnie jednym z powodów, dla których jest to standup, jest właśnie to, aby zapobiec zbyt długiemu spotkaniu i sprowadzeniu rzeczy takich jak projektory itp.
Pete
4
Całkowite pominięcie codziennych konfliktów przez robienie ich źle, nie oznacza, że ​​pomysł jest zły. Spróbuj lepiej zrobić spotkanie stand-up, trzymaj się timeboxu, ustalonego miejsca, ustalonego czasu i ustalonego celu: komunikacji w zespole, a potem to przyjemność. Westchnienie - znowu pojedynek jest dla zespołu, a nie dla premiera czy kogokolwiek innego.
Rudi
1
Pozbądź się projektora.
Kirk Broadhurst,
6

Może to być przydatne, ale często nie jest w praktyce.

Jeśli masz zespół, który nie ma łatwego dostępu do innych członków zespołu podczas pracy, lub twoja organizacja utrudnia znalezienie menedżerów / szefów / kogokolwiek innego, to przynajmniej wiesz, że masz jeden strzał dziennie, aby uzyskać odpowiedź na pytanie.

W praktyce czasami zachęca to ludzi do niezwłocznego omawiania problemów i może to być bardzo czasochłonne. Na przykład:

Jeśli biorę udział tylko w jednym aktywnym projekcie deweloperskim (zwykle mam dwa), zwykle jest co najmniej jeden kończący kontrolę jakości i jeden rozwijający się jednocześnie. To trzy 15-minutowe pojedynki dziennie. Moje prawie nigdy się nie krzyżują. Tracisz trochę czasu, upewniając się, że jesteś w punkcie zatrzymania przed każdym z nich i podobnie wracasz na właściwe miejsce po każdym. Nawet jeśli zakładasz, że straty te wynoszą jedną 10 minut każda, co przekłada się na więcej niż cały dzień roboczy stracony na awarie każdego tygodnia.

Dodaj spotkania zatwierdzające i dema, a to z łatwością zjada cały dodatkowy dzień.

IMHO, jeśli Twój zespół ma problem z komunikacją, codzienne spotkania mogą pomóc, ale robienie ich w inny sposób jest po prostu zbyt dużym pochłanianiem zasobów.

Rachunek
źródło
4

Na długo przed myśleniem o SCRUM i Agile byłem zespołem kierującym badaniem siły roboczej, które zajęło 2 lata. Bez codziennych spotkań zajęłoby to znacznie więcej czasu. Po pierwsze, ludzie są istotami ludzkimi, odpoczną, jeśli będą wiedzieć, że nikt nie zwraca na nie uwagi. Jeśli muszą codziennie pokazywać postęp, tracą mniej. Jeśli Joe wydaje się robić większe postępy niż oni, zmniejszają się. Co więcej, informuje kierownika (lub kogokolwiek), kiedy wystąpią problemy, zanim staną się kryzysem. Więc jeśli Steve spóźni się o tydzień, a Harry będzie przed nami, możemy przenieść niektóre zadania. To powstrzymuje projekt przed opóźnieniem, ponieważ jedna osoba utknęła. Co więcej, zwykle ktoś inny może pomóc tej osobie utknąć.

Teraz pracowałem w jednym miejscu, w którym daliśmy duży projekt nowemu pracownikowi. (Nie byłem jego szefem.) Raporty z postępów, które przekazał swoim menedżerom, brzmiały: „wszystko jest super, wszystko zostanie wykonane na czas”, ale nie było żadnych szczegółów i nikt nie wymagał od niego, aby powiedział dokładnie, jakie postępy poczynił od dnia poprzedniego. Jak zapewne doświadczeni spośród was zgadł, on zrezygnował bez powiadomienia na tydzień przed terminem i żadne z jego zadań nie zostało ukończone ani nawet w stanie, w którym „praca”, którą wykonał, była użyteczna. Dlatego potrzebne są codzienne spotkania - aby ci ludzie robili prawdziwy postęp i aby dowiedzieć się, kiedy nie są, zanim cały projekt zejdzie z toru. Skończyłem robić jego zadania i moje i pracowałem w nadgodzinach przez całe lato, abyśmy mogli zatrzymać klienta o wartości wielu milionów dolarów.

Tak, wszyscy lubimy wierzyć, że wszyscy nasi twórcy są wewnętrznie zmotywowani i zawsze będą produkować dla nas dobra, ale prawda jest taka, że ​​musisz chronić zespół i organizację przed takimi ludźmi. Nigdy nie wiadomo, kim będą; czasami nie jest to nowy pracownik, ale ten, który jest zły na organizację (słusznie lub nie) lub ten, który właśnie stracił żonę (przynajmniej często wiesz, kim są ci ludzie, ale nie wszyscy mają takie same problemy).

HLGEM
źródło
1
Jeśli musisz najechać myszką na programistów, aby je uruchomić, musisz wymienić ciebie lub programistów.
anomalia
4

Tak czy nie i czy są cenne, to dwa różne pytania. Odpowiedzi mogą być również inne. W przypadku drugiego pytania odpowiedź może zależeć od perspektywy.

Pierwsze pytanie, tak czy nie? To tak . Z punktu widzenia Scrum lub XP, standup jest niezbędną czynnością. Jeśli nie masz Codzienne spotkania, to naprawdę nie jest Scrum, to się nazywa „Scrum, ale nie robimy codziennie Standy” lub scrumbut za krótki. jeśli chcesz uwzględnić perspektywę Kanban, większość zespołów Kanban robi awarie, nawet jeśli ich metoda ich nie nakazuje.

Drugie pytanie (jak) są cenne, jest bardziej skomplikowane. Jeśli ćwiczysz Scrum lub XP, musisz uwierzyć, że pojedynki są niezbędne do promowania współpracy, pracy zespołowej i zwiększenia efektywności Twojego zespołu. Odpowiedź jest więc zdecydowanie cenna .

Perspektywa szczupłych zwolenników jest zupełnie inna . Ekstremalnie szczupły pogląd jest taki, że twój klient nie dba o to, czy robisz przerwy, więc są po prostu marnotrawstwem. Co robisz z odpadami? Ograniczasz go do minimum, najlepiej do zera.

Bardziej umiarkowanym uproszczonym poglądem jest to, że choć nie do końca marnuje się, codzienne awarie są kosztem koordynacji, a nie działalnością o wartości dodanej . Możesz grać w adwokata diabła ze swoimi kolegami z Scrum i zapytać ich: jeśli uważasz, że twoje 15-minutowe pojedynki są działaniem o wartości dodanej, dlaczego nie zrobisz ich 30 minut każdego dnia lub 45 minut i łatwo zwiększysz wartość dodaną?

Kanban, który ma szczupłe korzenie, ale chce realizować zasady Agile Manifesto, rozwiązuje ten paradoks, robiąc standupy, ale używając zupełnie innej struktury spotkania niż tradycyjny format agile standup. Rezultatem jest znacznie krótsze spotkanie, które jest zgodne z Lean z punktu widzenia. Ta książka zawiera przykład, w którym 50-osobowy zespół Kanban codziennie wykonuje awarie w ciągu 10 minut .

Podsumowując, czy robić codzienne awarie, odpowiedź jest zdecydowanie tak . Ale czy są cenne, jak cenne są - to zależy .

azheglov
źródło
Mówienie o 50-osobowym zespole, który codziennie wykonuje 10-minutowy postój, jest tym, co się dzieje. Zrób matematykę i stań się rzeczywistością! To 12 sekund na osobę. Wrzuć tę książkę do śmietnika, tam gdzie należy!
Captain Sensible
@Seventh Element: twoja "matematyka" opiera się na założeniu, że celem spotkania jest umożliwienie każdemu z członków zespołu N rozmowy. To z pewnością błędne założenie. Słuchaj, z pewnością możesz przyczynić się do powstania tej witryny, jeśli umieścisz konstruktywne odpowiedzi przed napisaniem negatywnych komentarzy.
azheglov
4

Najbardziej użytecznym typem standupu jest typ Kanban.

  1. Potrzebujesz tablicy zadań, która odzwierciedla Twój rzeczywisty przepływ pracy / strumień wartości. Ta tablica zadań jest centralnym punktem pojedynku.
  2. Skoncentruj się na elementach pracy, a nie na ludziach
    • Skoncentruj się bardziej na tym, które elementy pracy możesz ukończyć (na podstawie tablicy zadań), niż na tym, co możesz zacząć
    • Skoncentruj się na rozwiązywaniu problemów przedstawionych przez tablicę - wąskich gardeł, bloków itp

(Prawdopodobnie nie zadziała to zbyt dobrze w środowisku Scrum, w którym zaangażowanie i koncentracja na ludziach jest kluczowym mechanizmem).

W ten sposób spotkanie stand-up może być krótkie, nawet z wieloma osobami, ale nadal może być przydatne.

Ingvald
źródło
2

Jak myślisz, jak cenne (lub nie) są codzienne spotkania stand-up?

Off-source wszystkie spotkania scrum Framework są ważne, ale myślę, że codzienne spotkanie stand-up jest „najważniejszym” spotkaniem w Scrum Framework. To jest jak serce w ciele. Jeśli serce nie pompuje krwi regularnie, wówczas ciało musi umrzeć, w tym przypadku jest to Organizacja lub Projekt po scrumie, a serce to spotkanie scrumu.

Czy uważasz, że ta praktyka ma wartość? Tak. Codzienne Scrumy poprawiają komunikację, eliminują inne spotkania, identyfikują i usuwają przeszkody w rozwoju, podkreślają i promują szybkie podejmowanie decyzji oraz podnoszą poziom wiedzy wszystkich osób na temat projektów. Daily Scrum nie jest spotkaniem statusowym. Daily Scrum to kontrola postępów w kierunku tego celu sprintu (trzy pytania). Zwykle następują spotkania w celu dostosowania nadchodzących prac w Sprincie. Celem jest optymalizacja prawdopodobieństwa, że ​​zespół osiągnie swój cel. Jest to kluczowa kontrola i dostosowanie spotkania w procesie empirycznym Scrum.

Czy ktoś pracował w miejscu, które to zrobiło i co myślałeś?

Tak, w moim ostatnim projekcie przestrzegaliśmy Scrum Framework i praktyk Agile. Bardzo poważnie podchodziliśmy do Scrum Framework i nie zrobiliśmy tego bez przekonania. Początkowo pracowałem w zespole złożonym z 5 osób, potem przeniosłem się do większego zespołu składającego się z około 9 osób, a następnie ponownie wróciłem do 6-osobowego przedziału w okresie 4 lat. Codzienne spotkanie scrum upewniło się, że wszyscy są zsynchronizowani, przeszkody były przejrzyste, a my jako Zespół mogliśmy zobaczyć, jak Zespół postępuje z wypaleniem przed nami i wiedzieliśmy dokładnie, kto nad czym pracuje i gdzie możemy się przyczynić my sami. Zdecydowanie łatwiej jest to zrobić, gdy masz zespoły po 6 lub mniej. Spotkanie scrumowe ma na celu przeprowadzenie kontroli samokontroli, a jeśli coś zostanie znalezione w kierunku przeciwnym do celu lub jeśli coś zostanie zablokowane, samoorganizujący się zespół dostosowuje się,

sjt
źródło
2

O ile nie ma dobrego powodu, aby codziennie mieć w pełni komunikacyjną sieć między całym zespołem, brzmi to jak wielka strata czasu.

Raczej mają tygodniki.

Paul Nathan
źródło
1

Z mojego doświadczenia wynika, że ​​wstępne planowanie tego, co zrobisz następnego dnia, prowadzi do znacznego wzrostu wydajności. Dlatego organizowanie takich spotkań typu scrum jest warte straconego czasu tylko z tego powodu.

Staraj się, aby były krótkie, a nawet rób to codziennie na czacie grupowym Skype. Pamiętaj jednak, aby przeczytać sobie nawzajem aktualizacje.

Dzienny raport o stanie na koniec każdego dnia przed powrotem do domu ma taki sam efekt.

Brian R. Bondy
źródło
1

Dla mnie jest skuteczny w zespołach 3 i 5 osób, i widziałem, że był on skutecznie wykorzystywany w zespole planistów wydarzeń, w którym było około 20 osób. Musisz krótko mówić, musisz się poruszać. Jest dobrze, jeśli siedzisz, ale nie powinno być żadnych dodatkowych rzeczy (materiały informacyjne, tablica, wideo itp.)

ukradkowy
źródło
1

Myślę, że codzienne stójki to świetny pomysł, niezależnie od metodologii lub obszaru, w którym pracujesz - pod warunkiem, że możesz je utrzymać maksymalnie 15 minut. Jeśli nie możesz regularnie tego przestrzegać, oznacza to, że w pojedynku występuje zbyt wiele osób lub spotkanie nie jest wystarczająco skoncentrowane.

Tam, gdzie jesteśmy, zespół marketingowy zaczął nas kopiować, a teraz także stand-upy - więc nie jest to również tylko dla programistów!

FinnNk
źródło
0

Od około 7 lat prowadzimy spotkania „wstań”, zanim zdaliśmy sobie sprawę, że to zwinny scrum. Moim zdaniem są świetnym sposobem na ogólne zrozumienie postępu projektu i tego, czy ktoś potrzebuje pomocy. Niektórzy członkowie mojego zespołu nie lubią prosić o pomoc, ale akceptują ją, gdy oferowane jest to często w codziennym pojedynku.

Spotkania muszą być krótkie, mieliśmy spotkania zwykle krótsze niż 10 minut z 7 członkami zespołu. Pomaga zaplanować je tuż przed przerwą o dziesiątej. Nie używamy również technologii w spotkaniach, tylko tablicę scrum z zadaniami post it i niektórymi wykresami.

refro
źródło
0

Plusem tych spotkań może być zwiększenie produktywności pod względem realizacji pilnych i natychmiastowych celów biznesowych.

Z drugiej strony, te spotkania (codziennie: co robiłeś? Co zamierzasz robić? Co jest na twojej drodze?) Zniechęcają to, co możemy nazwać „czasem google” lub pracą / nauką przy pobocznym projekcie, który nie ma natychmiastowy wpływ na działalność, ale może mieć znaczący wpływ na wyniki.

Jeden produkt, dla którego zrobiłem prototyp, nigdy nie przeszedłby codziennego testu na spotkanie i na szczęście mój stary menedżer dał mnóstwo swobodnej pracy na własną rękę, a teraz prawdziwy produkt jest już dostępny. Ale teraz, gdy stary menedżer odszedł i dołączył nowy, który obejmuje koncepcję codziennego scrumu, nie rozumiem, jak mógłbym kiedykolwiek opracować prototyp w codziennym środowisku scrumowym.

mg1075
źródło