Ежедневные ожидания - да или нет? [закрыто]

Насколько ценны (или нет), как вы думаете, ежедневные встречи ?

Если вы не знакомы с ним, это относится к ежедневному собранию, которое является частью приверженцев Scrum (и некоторых других гибких методологий). Идея заключается в том, что вы проводите ежедневное собрание, рассчитанное на 15 минут и на котором все должны стоять (чтобы побудить людей быть в курсе дела).

На собрании вы ходите по комнате и каждый говорит: - Что вы сделали вчера - Что вы планируете делать сегодня - Любые препятствия или препятствия на пути вашего прогресса.

Как вы думаете, эта практика имеет ценность? Кто-нибудь работал в месте, где это было сделано, и что вы думаете?

У нас были ежедневные дежурства на моей первой работе. Ну, со всеми кооперативами / интернами / временными специалистами, это было на самом деле на длинной стороне - обычно около 30 минут.

Но идея короткой ежедневной встречи с временными рамками очень помогла просто узнать, над чем застряли другие люди - и если бы это было чем-то, над чем я работала, я могла бы переориентировать свои задачи, чтобы закончить то, что им нужно, чтобы продолжить раньше. Это также дало всем шанс узнать, над чем все работали, поэтому, если у кого-то возникла чрезвычайная ситуация, все, по крайней мере, знали о том, что происходит, - снижение коэффициента грузового автомобиля всегда хорошо.

Честно говоря, каждый день может быть немного экстремальным в некоторых случаях. Но идея коротких, регулярных встреч для всех, чтобы оставаться на одной странице, является ценным дополнением к любому процессу.

Я считаю эти встречи очень ценными. Они предлагают следующие преимущества - взамен потратить всего 15 минут!

• Держит всех по теме . Легко разобраться в своих проблемах и забыть о том, что делают другие, или повторить работу, выполняемую кем-то другим. Ежедневные встречи не позволяют этому случиться.
• Не позволяет людям расслабляться . На этих встречах вы даете обещания. Тогда вам просто нужно попытаться сохранить их.
• Заставляет людей взаимодействовать . Программисты обычно не любят общаться с людьми. Однако на таких встречах они получают поддержку (и выговоры) от своих коллег, что положительно сказывается на моральном состоянии.
• Собирает всех в одном месте . Вы получаете бонус, зная, что все придут туда. Это может быть использовано для организации других встреч, объявления и продолжения этой ежедневной встречи в небольших группах для обсуждения конкретных проблем. Обычно организация таких встреч требует много внимания и требует навыков, которые программисты не любят использовать.

Я могу стоять часами подряд. Это не заставляет меня больше говорить, или не имеет никакого реального значения / влияния для короткой ежедневной встречи с догонялками.

Но, эй, если вставать позволяет вам переименовать что-то как проворное, это должно быть хорошо!

Что касается того, являются ли регулярные встречи в целом хорошей идеей ... хорошо, они помогают, если другие процессы неэффективны.

Если вы хотите знать, что кто-то сделал вчера, и каковы его следующие задачи, посмотрите на систему отслеживания проблем, где она уже записана. Если нет четкого фильтра, который говорит вам это для всей команды, настройте его (или найдите лучшее программное обеспечение).

Если вы хотите узнать, есть ли у кого-нибудь блокировщики, проверьте свои сообщения (будь то электронная почта / im / forum / что угодно). Если у кого-то есть, они должны уведомлять как соответствующую сторону, так и руководителя проекта, когда они происходят, не тратя день на ожидание, пока кто-нибудь еще узнает, не говоря уже о возможности действовать.

Конечно, полезно проводить регулярные встречи для обсуждения направления проекта - в общем смысле, а не в деталях, чтобы убедиться, что все понимают общие цели и т. Д. - и проводится еженедельно или раз в две недели (в зависимости от темпа).

Но тратить четверть часа каждый день только для того, чтобы вы могли чувствовать себя проворным, великолепным и все такое? Пустая трата времени.

По моему опыту, стояния не стоили того, особенно ежедневного вида. Это либо одно из двух: пустой ритуал или неориентированная специальная встреча.

1. Пустой ритуал: все идут по кругу и заявляют о своей задаче и своем прогрессе. Никто не заботится о том, над чем работают другие, и ничего не делается (в результате ссоры), если есть проблема.

2. Ненаправленная специальная встреча: кто-то (обычно менеджер, премьер-министр или кто-то из бизнеса) приходит и расстраивает его. Может быть, мы поговорим о сегодняшнем пожаре в мельчайших деталях, или о том, как кто-то начинает беспокоиться, если мы собираемся уложиться в крайний срок и т. Д. 15 минут превращаются в полчаса или дольше. Все стоят, хотя мы действительно должны сидеть, если это будет так долго.

Кроме того, «стоячая» часть заездов не помогает распределять время по встречам, она лишь добавляет физический дискомфорт к миксу.

У меня был намного лучший опыт общения между членами команды, чем официальные встречи. Если кому-то небезразлично, над чем вы работаете или о вашем прогрессе, они спросят вас, или вы скажете им. Если у вас есть проблема или вас заблокировали, вы должны убедиться, что люди, которым нужно об этом знать, знают. Если требование неясно, вы отслеживаете бизнес-пользователя или БА и спрашиваете его об этом.

Я думаю, что они очень ценны, если они выполняются правильно. Формат, который работал хорошо для меня, это ..

Каждый человек дает краткий ответ на следующие вопросы.
а) Над чем вы работаете?
б) Что вы будете делать на следующей встрече (завтра)?
в) Вы выполнили то, что, как вы сказали, вы сделаете на последней встрече?
г) Какие препятствия замедляют / останавливают ваш прогресс?

Любое расширенное обсуждение вышеупомянутого должно быть ограничено во время встречи, чтобы быть кратким. Любой может остаться после (или встретиться позже в тот же день), чтобы обсудить с соответствующими лицами все, что требует расширенного охвата.

Это позволяет достичь следующих целей:
a) Руководитель группы / владелец продукта в курсе возможных задержек.
б) Руководитель команды может быстро устранить препятствия.
в) Руководитель группы может быстро идентифицировать людей, крутящих свои колеса.
d) Это поощряет сотрудничество между членами команды, которые могут быть слишком замкнуты, чтобы просить о помощи, когда им это нужно.
e) Он стимулирует импульс, оставляя обязательства короткими (сводит к минимуму работу, расширяющую время, доступное для проекта).

Я не нашел их полезными, как это практиковалось на моем рабочем месте, где «ежедневный 15-минутный режим ожидания» растягивался до 30, затем до 45, а теперь часто до 60 минут; где все садятся, ожидая, пока менеджер проекта возится с проектором, или с сетевым ресурсом, или с кем-то еще, каким является случайный демон дня; где он настаивает на том, чтобы каждый потратил время на предоставление обновлений статуса перед собранием, но затем снова опрашивает всех (на случай, если мы сделали что-то еще в последние несколько минут); Единственная часть оригинальной концепции, которая остается, - «Ежедневно».

Не делай этого.

Это может быть полезно, но часто не на практике.

Если у вас есть команда, которая не имеет легкого доступа к другим членам команды, когда они работают, или ваша организация затрудняет поиск менеджеров / менеджеров по персоналу / кого бы то ни было, по крайней мере, вы знаете, что у вас есть один выстрел в день, чтобы получить ответ на вопрос.

На практике это иногда побуждает людей не обсуждать проблемы немедленно, и это может стать значительным отсосом времени. Например:

Если я участвую только в одном активном проекте разработки (обычно я в двух), обычно есть хотя бы один завершающий контроль качества и один ускоряющийся одновременно. Это три 15 минут в день. Мои почти никогда не встречаются. Вы теряете некоторое время на то, чтобы убедиться, что находитесь в точке остановки перед каждым, и таким же образом возвращаетесь на правильный путь после каждого. Даже если вы предполагаете, что эти потери равны одной 10 минутам каждый, что означает более чем целый рабочий день, потерянный для стоянок в неделю.

Добавьте в коммит встречи и демонстрации, и это легко съедает целый дополнительный день.

ИМХО, если у вашей команды есть проблемы со связью, то ежедневные встречи могут помочь, но делать их иначе - слишком большая потеря ресурсов.

Задолго до того, как SCRUM и Agile когда-либо задумывались, я был руководителем группы по исследованию рабочей силы, на которое ушло 2 года. Это заняло бы намного больше времени без ежедневных встреч. Во-первых, люди, будучи людьми, будут расслабляться, если будут знать, что никто не обращает внимания. Если им приходится демонстрировать прогресс каждый день, они меньше расслабляются. Если Джо, кажется, делает больше прогресса, чем они, они ослабляют меньше. Кроме того, он позволяет менеджеру (или кому-либо еще) знать, когда возникают проблемы, прежде чем они станут кризисом. Так что, если Стив опаздывает на неделю, а Гарри впереди, тогда мы можем перенести некоторые задачи. Это удерживает проект от отставания, потому что один человек застрял. Кроме того, обычно кто-то может помочь человеку отклеиться.

Сейчас я работал в одном месте, где мы дали большой проект новому сотруднику. (Я не был его начальником.) Отчеты о ходе работы, которые он давал своим менеджерам, были «все великолепно, все будет сделано вовремя», но никаких подробностей, и никто не требовал, чтобы он говорил точно, какой прогресс он добился со дня накануне. Он, как я уверен, опытный из вас догадался, ушёл без уведомления за неделю до крайнего срока, и ни одно из его заданий не было выполнено или даже в состоянии, когда выполненная им «работа» была полезной. Вот почему нужны ежедневные встречи - чтобы эти люди добились реального прогресса и выяснили, когда они этого не делают, прежде чем весь проект рухнет. Я закончил тем, что выполнял его и мои задачи и работал сверхурочно все лето, чтобы мы могли сохранить многомиллионного клиента.

Да, нам всем нравится верить, что наши разработчики внутренне мотивированы и всегда будут производить товары для нас, но правда в том, что вы должны защищать команду и организацию от таких людей. Вы никогда не знаете, кем они будут; иногда это не новый сотрудник, а тот, кто злится на организацию (оправданно или нет) или тот, кто только что потерял свою жену (по крайней мере, вы часто знаете, кто эти люди, но не все разделяют их личные проблемы).

Да или нет и они ценны это два разных вопроса. Ответы также могут быть разными. В случае последнего вопроса ответ может зависеть от перспективы.

Первый вопрос, да или нет? Это да . С точки зрения Scrum или XP, standup является важным видом деятельности. Если у вас нет ежедневных ссор, то это на самом деле не Скрам, это называется «Скрам, но мы не делаем ежедневные приемы» или скрамбут для краткости. Если вы хотите включить перспективу Канбана, большинство команд Канбана делают заезды, даже если их метод не предписывает их.

Второй вопрос, (как) они ценны, является более сложным. Если вы практикуете Scrum или XP, вы должны верить, что резервы необходимы для развития сотрудничества, командной работы и повышения эффективности вашей команды. Так что ответ, безусловно, ценный .

Точка зрения худых сторонников совсем иная . Чрезвычайно скудный взгляд заключается в том, что ваш клиент не заботится о том, что вы делаете дежурный режим, поэтому они просто напрасны. Что вы с отходами? Вы сокращаете его до минимума, в идеале до нуля.

Более умеренная точка зрения заключается в том, что ежедневные перерывы, хотя они и не являются бесполезными, являются затратой на координацию, а не добавленной стоимостью. . Вы можете сыграть в адвокат дьявола со своими коллегами по Scrum и спросить их: если вы считаете, что ваши 15-минутные скиллы являются дополнительным мероприятием, почему бы вам не делать 30 минут из них каждый день или 45 минут и легко увеличивать добавленную стоимость?

Канбан, у которого скудные корни, но который стремится реализовать принципы Agile Manifesto, разрешает этот парадокс, выполняя заезды, но используя совсем другую структуру собраний, чем традиционный формат agile. Результатом является гораздо более короткое совещание, которое соответствует точке зрения Бережливого производства. В этой книге приведен пример, когда команда из 50 человек из Канбана ежедневно делает заезды в течение 10 минут .

Подводя итог, стоит ли делать ежедневные заезды, ответ однозначно да . Но насколько они ценны, насколько они ценны - это зависит .

Наиболее полезным типом стойки является тип Канбан.

1. Вам понадобится доска задач, которая отражает ваш реальный рабочий процесс / поток создания ценности. Эта доска задач является фокусом стенда.
2. Фокус на рабочих элементах, а не на людях
   • Сосредоточьтесь больше на том, какие рабочие элементы вы, как команда, можете выполнить (основываясь на доске задач), чем на том, что вы можете начать
   • Сосредоточьтесь на решении проблем, которые вам показывает доска - узкие места, блоки и т. Д.

(Это, вероятно, не будет работать слишком хорошо в условиях Scrum, где приверженность и сосредоточенность на людях является ключевым механизмом.)

Таким образом, встреча в режиме ожидания может быть короткой, даже со многими людьми, но все же иметь реальное применение.

Насколько ценны (или нет), как вы думаете, ежедневные встречи?

Выделить все собрания Scrum Framework очень важно, но я думаю, что ежедневное повторное собрание является «самой важной» в Scrum Framework. Это как сердце в теле. Если сердце не перекачивает кровь регулярно, то тело неизбежно умирает, тело в этом случае является Организацией или Проектом после схватки, а сердце - собранием схватки.

Как вы думаете, эта практика имеет ценность? Да. Ежедневно Scrums улучшают коммуникации, устраняют другие встречи, выявляют и устраняют препятствия для развития, выделяют и способствуют быстрому принятию решений, а также повышают уровень знаний о проекте каждого на уровне. Daily Scrum не является статусной встречей. Daily Scrum - это проверка прогресса в достижении этой цели спринта (три вопроса). Последующие встречи обычно происходят, чтобы приспособиться к предстоящей работе в Спринте. Цель состоит в том, чтобы оптимизировать вероятность достижения Командой своей цели. Это ключевая проверка и адаптация встречи в эмпирическом процессе Scrum.

Кто-нибудь работал в месте, где это было сделано, и что вы думаете?

Да, в моем последнем проекте мы следовали принципам Scrum Framework и Agile. Мы очень серьезно относились к Scrum Framework в целом, и мы не делали этого нерешительно. Сначала я был в команде из 5 человек, затем я перешел в более крупную команду из 9 человек, а затем снова вернулся к 6 спредам за 4 года. Ежедневные встречи помогли убедиться, что все были синхронизированы, препятствия были прозрачными, и мы, как команда, могли видеть, как команда продвигается вперед, и мы точно знали, кто над чем работает, и где мы можем внести свой вклад. сами. Это определенно легче сделать, когда у вас есть команды из 6 или меньше. Целью скрам-встречи является проверка самопроверки, и если обнаруживается, что что-то идет не в направлении цели или что-то заблокировано, самоорганизующаяся команда адаптируется,

Если нет веской причины для ежедневного общения всей команды между собой, это звучит как пустая трата времени.

Скорее есть еженедельники.

По моему опыту, предварительное планирование того, что вы будете делать на следующий день, приведет к значительному повышению производительности. Таким образом, проведение подобных подобных схваток стоит потраченного времени только по этой причине.

Старайтесь, чтобы они были короткими, или даже делайте это в групповом чате Skype каждый день в одно и то же время. Только не забудьте прочитать обновления друг друга, хотя.

Ежедневный отчет о состоянии в конце каждого дня перед тем, как идти домой, имеет тот же эффект.

Это было эффективно для меня в командах из 3 и 5 человек, и я видел, что оно эффективно использовалось для команды организаторов мероприятий, в которой было около 20 человек. Вы должны держать это коротким, вы должны держать его в движении. Это хорошо, если вы сидите, но не должно быть никаких дополнительных вещей (раздаточные материалы, доска, видео и т. Д.)

Я думаю, что ежедневные упражнения - отличная идея, независимо от того, в какой методологии или области вы работаете - при условии, что вы можете сделать их короткими максимум 15 минут. Если вы не можете регулярно придерживаться этого, тогда либо слишком много людей посещают один стенд, либо собрание недостаточно сфокусировано.

Там, где мы находимся, маркетинговая команда начала копировать нас, и теперь у нее также есть стоянки - так что это не только для разработчиков!

Мы проводили встречи «встать» до того, как узнали, что это проворная схватка, вот уже 7 лет. На мой взгляд, это отличный способ получить общее представление о том, как продвигается проект и нуждается ли кто-то в помощи. Некоторые из членов моей команды не любят просить о помощи, но принимают ее, когда предлагают, это часто делается в ежедневном режиме ожидания.

Встречи должны быть короткими, у нас были встречи обычно под 10 минут с 7 членами команды. Это помогает планировать их как раз перед 10-часовым перерывом. Также мы не используем технологии на встречах, просто доску объявлений с постами и некоторые графики.

С другой стороны, эти встречи могут способствовать повышению производительности с точки зрения достижения неотложных и неотложных бизнес-целей.

С другой стороны, эти встречи (ежедневные: что вы делали? Что вы собираетесь делать? Что у вас на пути?) Препятствуют тому, что мы можем назвать "google-time", или работе / обучению в стороннем проекте, который не имеет немедленное влияние на бизнес, но может оказать существенное влияние в будущем.

Один продукт, для которого я сделал прототип, никогда не прошел бы ежедневное тестовое собрание, и, к счастью, мой старый менеджер дал мне свободу работать самостоятельно, и теперь настоящий продукт - живой. Но теперь, когда старый менеджер ушел и появился новый, который охватывает концепцию ежедневной схватки, я не понимаю, как я мог бы разработать прототип в повседневной схватке.