scrum meeting что это
Stand-up, Scrum, Daily meetings — что это и для чего
Часто стал замечать, что люди все больше и больше перетягивают методологии и практики из IT сферы в производственные, банковские, сферы услуг и прочие. Одной из самых распространенных «заимствованных» из мира IT практик является проведение Scrum, Daily, Stand-up митингов ( как их только не называют, но везде суть примерно одинаковая). Ниже будет представлено описание этого процесса таким образом, как его провожу лично я.
Общее
Данный пост описывает цель и регламент проведения ежедневного митинга — Стендапа. Основа данного процесса была взята из scrum методологии и является частью процесса разработки, в будущем может быть адаптирована под текущую команду, а так же и процесс разработки. Как и любой инструмент использование и отношение к нему будут определять результаты.
Общая агенда
Я вчера делал задачу, сегодня будут делать задачу, сложностей нет.
Именно такие ответы являются демотивирующими для проведения статусных митингов. Это потеря времени и бессмысленность. Если вам кажется, что задача одна и ее можно делать неделями, то это уже ошибка в подходе, любая большая задача делится на подзадачи, которые и помогают видеть результаты и прогресс.
Таким образом нужно свое информирование строить следующим образом:
Мои активности за вчера:
Например: напоминаю, я с Х числа иду в отпуск.
Правила проведения митинга
Дополнительная практика
Всех членов стендапа объединяет общая цель, область работы, задачи, команда, и, скорее всего, у вас есть чат-группа со всей командой. В случае, если человек не приходит на стендап по тем или иным причинам мы просим уведомить в чате, что человек сегодня опаздывает, или будет в принципе отсутствовать (это будет полезная информация для всех, у кого с этим человеком совместные планы были), а так же вкратце изложить ответы на основные вопросы стендапа:
Где посмотреть
Пример проведения стендапа, не совсем как проводим мы, но для понимания в целом сойдет:
Daily Scrum Meeting / Ежедневный скрам
Игра команды, да, именно игра команды. Всем, наверное, надоело сравнение Scrum с игрой команды, но, пожалуй, этот образ действительно максимально сильно даёт нам понять, как устроена методология Scrum. Во многих командных играх перед выходом на поле или после какого-то тайм-аута команда собирается в плотное кольцо и очень быстро обсуждает самые важные моменты игры. Не стоит, однако, путать эту встречу с планомерным обсуждением тактики игры задолго до выхода, это будет, скорее всего, Planning meeting.
Такая схватка игроков происходит весьма быстро, ведь нет возможности обсуждать что-то в течении даже 5 минут. В условиях такого ограниченного времени вольно или невольно игроки и тренер говорят только действительно о самом важном на ближайшее время, и все при этом слушают крайне внимательно. Затем они заряжаются боевым кличем и устремляются на поле, полные энергии и задора.
Разговор тренера при этом может состоять, например, из таких фраз: «главный нападающий практически всегда бежит по данной траектории, ты находишься в этой позиции, тебе для перехвата слишком далеко бежать, смени свою изначальную позицию и держись её до следующего тайм-аута»; «я заметил, что тебе тяжело пройти вот эту дистанцию во время нападения, в чем проблема?» и так далее. Daily Scrum Meeting выглядит примерно так же, хотя, может, и без такого напряжения. Так или иначе, цель такого совещания – скорректировать и понять работу команды, узнать, какие у неё текущие проблемы, и предложить варианты решения. Чтобы иметь структурированную систему в методологии Scrum разработаны три простых вопроса, которые должны звучать на Daily Scrum Meeting.
Три главные фразы Daily Scrum Meeting
Данные вопросы, безусловно, задаёт Scrum Master. Все ответы он обязательно должен фиксировать. Проблемы, естественно, могут быть абсолютно разными. Приведем пример из области офисной жизни и разработчиков, хотя, как известно, методология Scrum может применяться к чему угодно.
Естественно, какие-то вопросы Scrum Master может решить сам, для каких-то он должен искать решение, обратившись к компетентным специалистам, или как-то ещё. В любом случае, Scrum Master ответственен за эти проблемы и за их решения.
Кто участвует в Daily Meeting?
Если представить, что в обсуждениях команды примет участие, скажем, водонос, то, наверное, это всё же будет неуместно. И дело не в должностях, так как участие, к примеру, владельца клуба тоже тут неуместно. Ни один, ни второй напрямую не могу повлиять на работу команды в текущий отрезок времени. Данные лица могут помочь только в случае необходимости, если в списке проблем появится что-то, с чем к ним смогут обратиться.
В Daily Scrum Meeting всё точно так же. Участие в 15-минутной встрече обязательно для всей Development Team, также участвуют Scrum Master и Product Owner. Иные лица, будь то заказчики, маркетологи или кто-то ещё, могут присутствовать, однако без права говорить.
Варианты проведения Daily Scrum Meeting
На самом деле вариантов проведения этого мероприятия достаточно много, и разные команды подстраиваются под свои условия.
Возможные проблемы на Daily Scrum Meeting
Все проблемы, в действительности, человеческие. Самая основная – это обсуждение чего-то стороннего во время встречи. Тут речь идёт даже не об обсуждении вчерашнего матча по хоккею или футболу (хотя и такое бывает), а, скажем, бюджета проекта. Также излишние действия в виде чтения почты во время схватки не допустимы.
Sprint Planning Meeting
Основная и открывающая работу встреча непосредственно перед спринтом. Отличие данной встречи от Daily Scrum Meeting практически во всем.
Scrum Master
Человек, который ведет данные встречи. Именно Скрам Мастеру Daily Scrum Meeting нужны больше всего, так как на них он получает всю информацию о проблемах непосредственно от команды.
Product Owner
Владельцу продукта надо знать как работает команда и что её предлагать в первую очередь на реализацию. Правильные действия Product Owner способствуют не возникновению остановки спринта.
Как превратить 15 минут Scrum-собрания в ежедневный аншлаг?
Ежедневное собрание в Scrum-команде должно помочь собственнику продукта оптимизировать разработку и готовить продукт или сервис к релизу в срок и без оплошностей. Это красивая теория. На практике — Scrum meeting может быстро превратиться из эффективной короткой встречи в никому не понятную рутину. Как обеспечить команде полезную ежедневную встречу и не превратить ее в “обязаловку”?
Собрание в Scrum (или Scrum Stand Up) — плановая встреча, которая помогает продуктовым группам быть более эффективными и актуализировать ежедневные процессы. Рекомендуется, чтобы митинг не продолжался более 15 минут. Помимо product owner и Scrum master во встрече также участвуют другие члены команды.
Основная идея собрания в Scrum — провести 15 продуктивных минут всей командой, сообщая друг другу статус работы. Во время собрания каждый член команды рассказывает собравшимся о текущем положении своих дел.
Формат проведения Scrum meeting не предполагает наличия стола и стульев. Все происходит стоя, чтобы не “растягивать” встречу на продолжительное время. Если некоторые вопросы требуют дополнительного внимания, они могут обсуждаться теми, кто вовлечен, после собрания.
Сегодня ежедневное собрание в Scrum часто подвергается критике, его иногда считают устаревшей практикой. Однако Scrum meeting остается довольно популярным среди многих команд разработчиков. Собственники продуктов во всем мире подтверждают, что такой формат встречи помогает более эффективно управлять командой.
Организация эффективной Scrum-встречи для собственников продуктов не является уникальным талантом. Грамотной подготовке и проведению можно научиться, практиковать и постоянно улучшать этот навык. Следующие советы помогут начинающим product owners или тем, кто много раз организовывал Scrum meeting, но что-то пошло не так.
8 простых советов для организации эффективного Scrum-собрания
Определите формат митинга
В Agile-контексте ежедневный Stand up происходит в течение спринта, который является периодом работы в 2-4 недели. Во время спринта определяется набор фич и требований из бэклога для новой итерации.
Важная задача — четко определить временные рамки встречи, и помнить, что ежедневный Stand Up отличается от других встреч (например от retrospective meeting).
Пригласите команду и определите участников встречи
Лучшее решение для Scrum-собрания — это 8-12 человек, заинтересованных в обсуждении. Это упрощает коммуникацию и не затягивает встречу. На собрании рекомендуется присутствовать трем основным заинтересованным сторонам, которые выполняют главные роли в Scrum-команде:
Разберитесь с местом и временем
Как отмечалось выше, место проведения Stand Up не нуждается в определенной технике и атрибутах. Полезной может быть доска со стикерами или монитор для использования специального инструмента или сервиса для управления проектами, где будут отмечаться статусы и записываться заметки. По сути, нужно просто свободное помещение.
Эксперты советуют проводить ежедневный Scrum митинг в одно и то же время каждый день. Лучше это сделать в начале дня — тогда у всех будет четкое представление о том, чему будет посвящен день.
Если у вас есть удаленные члены команды, заранее убедитесь, что они уведомлены о собрании и смогут участвовать. Во многих компаниях для работы с распределенными сотрудниками используются специальные удобные сервисы. Один из них — Standuply. Инструмент помогает проводить собрания или опросы в Slack, а потом отправлять результаты в таск-трекер.
Стоя, зато быстро
Многие согласятся, что собрание стоя не будет затягиваться никем. Кроме того, это помогает сфокусировать внимание на самом главном.
В некоторых креативных командах стало модным проводить короткие собрания в планке или выполняя другие полезные физические упражнения.
Соблюдайте повестку дня
Ежедневное собрание в Scrum должно быть основано на трех основных вопросах, на которые должен ответить каждый член команды:
Не забудьте делать пометки и расшарить их, чтобы все были в курсе и своевременно реагировали.
Упростите процесс
Повестку дня ежедневного Scrum-собрания и статусы желательно визуализировать. Для этого придуманы полезные инструменты управления. Например, Канбан-доски, которые не позволят упустить не один рабочий вопрос и все разложить “по полочкам”. Вот как это выглядит в некоторых сервисах:
Очень важно видеть, что и когда заканчивается, что ждет своей очереди, а от чего вообще лучше избавиться. В этом смысле собственникам продуктов не обойтись без графиков для известных техник приоритизации.
Сотрудничайте и коммуницируйте
Помните, что ваше ежедневное Scrum-собрание — это ценное время, которое следует рассматривать как совместное усилие всей команды. Каждый участник собрания должен понимать, что все, что он говорит, должно быть полезным и эффективным для всех собравшихся. Правильно выстроенная коммуникация — залог продуктивности.
Избегайте типичных ошибок
К наиболее частым ошибкам при проведении Scrum-митинга отнесем следующие:
А какие ваши секреты проведения собрания в Scrum-команде?
Схема scrum — ежедневная работа внутри спринта
В этой, 12 статье из серии «Менеджмент цифрового мира», я продолжаю рассказ о схеме Scrum, начатый в предыдущей статье «Итерации Scrum – целостная схема, а не прикольная картинка».
Схема приведена на рисунке. В прошлой статье мы обсудили изменения, которые потребовал переход к инкрементальной поставки ценности, и процедуру планирования, начинающую спринт. А в эта посвящена организации работы внутри спринта. Казалось бы, что об этом писать? Делаешь себе задачи и делаешь, и получаешь результат ☺ На самом деле, там тоже много интересных особенностей, обеспечивающих успех метода.
А здесь я хочу подчеркнуть, что такая организация работы – через доску, а не путем прямой коммуникации представляет собой один из предохранителей против возврата к классическому менеджменту, встроенных в Scrum. Он физически устраняет место, в котором сотруднику могут дать прямое поручение, все коммуникации инициируются самими сотрудниками.
Передача через доску – предохранитель против возврата к классическому менеджменту. Прямому поручению нет места
Возникает вопрос: а какую задачу член команды должен взять с доски, когда он закончил предыдущую? Ответ: ту, взятие им которой наилучшим образом продвинет спринт к завершению. Это вопрос личного выбора, при котором он учитывает текущую ситуацию, представленную на доски, свои собственные компетенции и компетенции других членов команды. При этом, естественно могут быть приняты определенные правила, которые призваны облегчить выбор, сделать его быстрым. Например, правило выбирать самую важную задачу. Но правила могут быть и более сложными, например, в начале спринта приоритет может отдаваться задачам, которые на планировании оценили как наиболее рискованные по реализации, в том числе длительным, а в конце спринта, наоборот, небольшим задачам, чтобы уменьшить количество незавершенных задач. Могут быть правила, по которым при скоплении задач на поздних этапах исполнения часть членов команды переключались на них. То есть, если говорить об IT разработчики начинали заниматься тестированием, если тестировщики вдруг не успевают. Особую остроту это приобретает, если используются WIP- лимиты. Могут быть и другие правила.
Как правило, sprint backlog фиксируется при планировании. Однако, в конкретных командах может быть необходимо уметь включать в спринт дополнительные задачи, например, если команда не только создает новый функционал, но и устраняет ошибки в старом, или обрабатывает какие-то срочные обращения клиентов или поручения руководства.
Если срочные задачи появляются регулярно, то на такие задачи обычно выделяется резерв мощности команды при планировании спринта. Сгорание этого резерва можно отдельно рисовать на Burndown Chart снизу-вверх.
Управления срочными задачами также желательно вести через доску, а не прямыми поручениями. Задача может быть просто повешена на доску, если ее содержание ясно. Если требуются дополнительные пояснения, то хорошая практика – подождать до очередного Daily Scrum для информации всей команде.
Если задача имеет большой объем, то с Product Owner обсуждают не только ее содержание, но и изъятие соответствующего объема запланированных задач из числа тех, которые еще не начали выполнение. При этом важно, чтобы эти изменения не нарушили достижения целей спринта. Если изменения столь велики, что цель спринта не достигается, то текущий спринт следует прервать, и начать новый спринт, восстановив осмысленность движения.
Начатое выполнение задачи не прерывается. Предполагается, что задачи достаточно малы, чтобы любые срочные задачи могли подождать, пока кто-нибудь завершит свою задачу и увидит на доске новую. Понятно, что это – идеальная картина. Реально коммуникации не запрещены, в каких-либо срочных случаях сотрудника можно и нужно отвлечь, в том числе если при выполнении очередного этапа обнаружились проблемы в ранее сделанном – тот, кто делал может быть призван на помощь.
Однако, запрету отвлекать есть важная причина, характерная для любых задач умственного труда: их выполнение требует погружения и сосредоточения, и нарушение этого представляет собой существенные накладные расходы. По опыту, задача на 2-3 часа требует около получаса погружения, поэтому если исполнителя пару раз отвлекли, то время выполнения возросло в полтора раза. Эти цифры – из моего опыта, но я слышал аналогичные цифры в разных докладах на конференциях, а быстрый поиск выдал, например, эту статью, в которой приведена близкая цифра со ссылкой на исследования.
Задача на 2-3 часа требует около получаса погружения, поэтому если исполнителя пару раз отвлекли, то время выполнения возросло в полтора раза
Если члены команды видят реальные потери производительности из-за частых отвлечений, это следует обсудить на ретроспективе и договориться о правилах работы. Отметим, кстати, этот прием: если кто-то увидел проблему, он начинает немедленно возмущаться и пытаться решить, а фиксирует возникшее напряжение. А потом высказывает его на соответствующей встрече, в данном случае это ретроспектива, а в случае острой проблемы – daily scrum. А результатом обсуждения чаще является не просто выраженное намерение исправиться, похожее на детское «я больше не буду» или «я буду стараться», а правило, учитывающее разные классы ситуаций: «отвлекать можно в случаях 1-2-3, а в остальных не надо», или «отвлекать можно, если отложенное решение несет такие-то риски».
Хотя работа каждого члена команды идет автономно, необходима синхронизация движения. Для этого служит ежедневная встреча – Daily Scrum. В свое время он назывался StandUp meeting, потому что рекомендовалось проводить его стоя вокруг доски. Эта рекомендация по-прежнему актуальна, если команда сидит вместе, но в случае распределенной команды это невозможно. Отметим, сидеть в одном помещении, лучше – отдельном для команды также крайне важно. А проведение митинга стоя, а не сидя способствует, во-первых, тому, чтобы члены команды оторвались от своей текущей работы, а, во-вторых, не затягивали митинг. Это – статус, а не обсуждение работы.
Если на встрече выяснилось, что какая-либо задача требует отдельного обсуждения, то надо зафиксировать, и далее ответственный за задачу должен его отдельно организовать, например, сразу после митинга. Превращение Daily Scrum в обсуждение задач, а не статус – наиболее распространенная ошибка. Рекомендация продолжительности для Daily Scrum – 15 минут, и если команда систематически превышает его, то стоит подумать о причинах и способах сокращения. Что касается времени проведения, то его команда выбирает самостоятельно, с учетом индивидуального расписания работы ее членов. В те времена, когда все начинали работу одновременно, следуя корпоративным традициям хорошим вариантом было утро сразу после начала рабочего дня, но эти времена ушли в прошлое. Может быть выбрано время перед или после обеда, если команда обедает примерно в одно время. На Daily Scrum важно участие всех членов команды, и даже если по каким-то причинам они не могут быть лично, желательно дистанционное участие.
Процедура Daily Scrum следующая: люди говорят о том, что было сделано накануне с прошлой встречи, о том, чем предполагают заниматься, и о том, какие есть препятствия для движения вперед. Коротко. Как легко догадаться, при 15 минутах на команду из 7 человек каждому будет не более 2 минут. Поэтому препятствия – фиксируются и назначаются нужные обсуждения. В каком порядке говорят люди? Есть два подхода, наиболее простой – говорить по кругу. Другой порядок – на основе расположения задач на доске, начиная от крайне правой колонки, поскольку чем задача продвинулась дальше по этапам, тем важнее ее завершение.
Кроме статуса по текущим задачам Product Owner информирует команду о срочных задачах, включенных в спринт, и других важных изменениях. Но это не должно существенно увеличивать размер Daily Scrum, если требуется длительное обсуждение, то о его времени надо отдельно договориться.
Доска с задачами должна быть актуальна в любой момент для того, чтобы член команды мог выбрать очередную задачу. Но это относится к основной доске. Если команда использует электронную и физическую доску одновременно, или физическую доску и таск-трекер, то Daily Scrum является также точкой синхронизации досок, и по его итогам принято обновлять Burndown Chart. Процедура здесь произвольна, это вопрос самоорганизации команды, но забывать об этом не следует.
Мне кажется всё это применимо только к внутренним проектам организации. Для коммерческих задач должен существовать чёткий план со сроками и отчётными точками. И ответственность нужна персональная. Потому что заказчику важно понимать как продвигается проект.
Похоже, это очередной набор отвлеченной ерунды от очередного инфоцигана, никогда ничем не управлявшего. Вы на его сайт зайдите.
Впрочем. спасибо за совет зайти на сайт. Думаю, такая антиреклама поспособствует его популярности среди серьезных людей.
Так что Agile работает сильно лучше, чем тщательное планирование. Иначе бы не стал стандартом отрасли.
Скрам-мастер. Как правильно провести скрам-митинг с командой?
В Scrum, как представителе Agile-методологий, упор делается на качество и контроль процесса разработки. Поэтому весомую роль играют скрам-митинги, которые курируются скрам-мастером. Главная задача митинга (или «скрама») — синхронизировать работу команды проекта.
Кто такой скрам-мастер?
Под описание скрам-мастера лучше всего подойдет английское определение servant leader — служащий лидер.
Его задача — помочь команде повысить эффективность путем:
Вместе с командой скрам-мастер отвечает
за темп работы и скорости завершения проекта
Также скрам-мастер вместе с участниками и владельцем продукта на первом скрам-митинге планируют спринт, за который команда зарабатывает баллы. Не зря Джефф Сазерленд, автор книги «Scrum. Революционный метод управления проектами», называет скрам-мастера главой команды.
Каким должен быть скрам-мастер?
Некоторые проектные команды экспериментируют и вводят модель ежемесячной ротации скрам-мастера, при которой им может стать любой участник. Если посмотреть на список навыков и ситуаций, с которыми приходится сталкиваться мастеру каждый день, становится понятно: такой формат выбора неэффективный.
Идеальный скрам-мастер должен обладать такими качествами:
Что такое скрам-митинг?
Scrum meeting — важный инструмент методологии Scrum. Встречи организовывают каждый день (преимущественно утром), митинги модерирует скрам-мастер, в чьей роли выступают проектным менеджером или тимлидом.
Во время встречи члены команды, задействованные в текущем спринте, проговаривают или пишут на доске ответы на три вопроса:
Помимо синхронизации работы команды Scrum помогает:
Источник
Отличия «Scrum-meeting» от «Meetup»
Meetup, как и meeting в переводе с английского — «встреча». А вот смыслы у них разные.
Так, участниками Meetup в основном становятся случайные люди, которых объединяет тема встречи. В Scrum-meeting участники известны с самого начала. Они заранее знакомы между собой.
Другие отличия Scrum meeting от meetup смотрите в нашей таблице.
Скрам-мастер, члены проектной команды, задействованные в текущем спринте, владелец продукта. Остальные могут присутствовать на встрече в качестве слушателей
Организаторы, заинтересованные люди, не работающие в одной компании над конкретным проектом. Опционально участие партнеров и спонсоров
Конференц-зал, рабочий кабинет — место, максимально близкое
к месту выполнения спринта
Любое, где участники смогут перемещаться и общаться со всеми
Любой желающий с помощью платформ meetup.com, meetup.by и других
Жесткая структура «трех вопросов»
Гибкая структура: презентации, «свободный микрофон», нетворкинг-встреча и т.д.
«Свободный микрофон» — формат мероприятия, на котором участники свободно и открыто делятся своими идеями, мыслями и концепциями с другими. Выступление обычно ограничено регламентом.
6 распространенных скрам-ошибок
Как проводится Scrum-meeting?
Каждый день спринта команда проводит дневные встречи — Scrum-meeting или как их еще называют daily scrum. Встречи обычно проходят в одном и том же месте, в одинаковое время и ограничиваются 15-и минутами. При таком ограничении побочные, несущественные темы отсекаются, обсуждение проходит в тонусе.
Во время Daily-scrum каждый член команды отвечает на три вопроса:
Что я делал вчера?
Что я делаю сегодня?
Какие препятствия стоят у меня на пути?
Фокусируясь на том, чего каждый участник достиг вчера и хочет достичь сегодня, команда поймет объем проделанной работы и то, сколько еще осталось до завершения спринта. Если программист скажет: — «Сегодня закончу модуль базы данных», участникам станет ясно — завтра он скажет закончил или нет.
Проблемы сразу переходят в зону ответственности скрам-мастера. Он может решить их во время Daily-scrum (если проблема небольшая) или записывает в свой план работ.
К типичным проблемам относятся:
Источник
Как правильно провести Scrum-meeting
Геймификация — использование игровых механик (получение опыта, сражение с монстрами, перемещение по игровому полю и т.д.) в неигровых процессах: работе, учебе, личной жизни.
Источник
Вердикт
Скрам-мастер необходим для координации команды.
Дело даже не в соблюдении канонов скрама, а в необходимости адвоката целей проекта на скрам-минингах. Соблюдение единой архитектуры продукта во всех задачах, командного духа и здоровой атмосферы в коллективе, стабильного темпа разработки — это прерогатива скрам-мастера.
Скрам-митинги — мощный инструмент для отслеживания статуса и продвижения проекта к завершению.
Они не только синхронизируют работу команды, но и помогают решить проблемы, сплотить сотрудников, учат ставить реальные задачи и отвечать публично за результат.