Stand-Up Meeting
Материал из AgileWiki
Содержание |
Определение
Очень короткое собрание с целью синхронизации работы команды. Так же известно как "летучка", "митинг стоя", scrum, daily scrum meeting (последние два имёт жёсткую структуру).
Статьи
Ежедневный митинг у доски
Хороший способ проверить, использует ли ваша команда доску для того, чтобы по настоящему управлять своей работой - это посмотреть на их ежедневный митинг (daily standup).
Команда, которая использует визуальный менеджемент для управления своей работой, всегда проводит ежедневное собрание стоя напротив доски
Оно выглядит так:
или так?
Во время ежедневного собрания вы сообщаете свежую информацию о своей работе членам вашей команды. Как та работа, которая была закончена накануне, так и та, которая все еще находится в процессе, обе должны быть ясно и четко отражены на доске. Имеет смысл обращаться к доске только тогда, когда вы говорите. Это будет легче для вас так же, как и для членов команды. Это также помогает визуально поместить в контекст то, о чем вы говорите.
Существует очень простое указание для того, чтобы убедиться, что вы не забудете поговорить о чем-то важном каждый день: проводите ежедневное собрание стоя напротив доски и проверяйте, чтобы все задания в средней колонке ("выполняется", "in progress") были обсуждены.
Из Visual management, автор Xavier Quesada Allue.
Перевел Павел Юров для scrum.com.ua под редакцией Алексея Кривицкого.
http://www.scrum.com.ua/2009/06/daily-scrum-against-board.html
Собрание стоя
Каждое утро проводится собрание для обсуждения проблем, их решений и для усиления концентрации команды. Собрание проводится стоя для избежания длительных дискуссий не интересных всем членам команды.
В типичном собрании большинство участников ничего не вносят, просто участвуют чтобы послушать что скажут другие. Большое количество времени людей тратится чтобы получить небольшое количество коммуникации. Поэтому участие всех людей в собраниях уводит ресурсы из проекта и создает хаос в планировании.
Для такого рода коммуникаций и нужно собрание стоя. Намного лучше иметь одно короткое обязательное собрание, чем множество длинных на которых большинство разработчиков должно все равно присутствовать.
Если у вас проводятся ежедневные собрания стоя, то все остальные собрания должны посещать только те люди, которые необходимы и будут что-либо привносить. Более того, имеется возможность даже избежать некоторых собраний. С ограничением участников, большинство собраний может быть проведено спонтанно перед монитором, где обмен идеями намного более интенсивен.
Ежедневное утреннее собрание это не еще одна трата времени. Оно позволит вам избежать многих других собраний и сэкономит больше времени, чем на него затрачено. Наш опыт.
Это правило нормально внедрилось. На первых порах стоит следить чтобы собрания не затягивались. Часто даже стоя разработчики начинают обсуждать детали, которые они могут обсудить в паре во время работы.
Daily Stand Up Meeting
At a typical project meeting most attendees do not contribute, but attend just to hear the outcome. A large amount of developer time is wasted to gain a trivial amount of communication. Having many people attend every meeting drains resources from the project and also creates a scheduling nightmare.
Communication among the entire team is the purpose of the stand up meeting. A stand up meeting every morning is used to communicate problems, solutions, and promote team focus. Everyone stands up in a circle to avoid long discussions. It is more efficient to have one short meeting that every one is required to attend than many meetings with a few developers each.
When you have daily stand up meetings any other meeting's attendance can be based on who will actually be needed and will contribute. Now it is possible to avoid even scheduling most meetings. With limited attendance most meetings can take place spontaneously in front of a computer, where code can be browsed and ideas actually tried out. The daily stand up meeting is not another meeting to waste people's time. It will replace many other meetings giving a net savings several times its own length.
“Вопрос дня” или зачем мы проводим Daily Scrum
Если вы в своей команде применяете методологию Скрам (Scrum), то, скорее всего, вы проводите и ежедневные собрания «на ногах» (daily stand-up). Что загадочно, так это то, что многие считают, что они работают по Scrum лишь потому, что они проводят ежедневные собрания :-)
Мы проводим собрание «на ногах», чтобы сделать их короткими. Это определение на самом деле не дает нам деталей для определения того, хороша ли форма проведения собрания «на ногах» и вообще, зачем мы его проводим…
Надеюсь, многие, кто «начал делать Scrum», читали хотя бы «введение в Scrum» написанное Майком Коном. Ну, или хотя бы краткое руководство от Кена Швабера или какие либо другие книги Кена или статьи на ScrumAlliance, которые разъясняют, зачем мы собственно собираемся и как провести собрание наиболее эффективно.
Вроде бы все очевидно и просто с этими собраниями «на ногах», но я был немало удивлен, когда впервые увидел, что это не работает. Я понял, что увиденная мной команда не осознает основные принципы и детали, которые позволят им выявлять и решать проблемы собраний «на ногах». Люди, у которых есть опыт хороших собраний «на ногах», обычно знают, что может быть сделано, когда что-то не очень хорошо работает. У новичков, участвующих в собрании «на ногах», когда что-то происходит не так, гораздо меньше шансов понять, что делать.
Итак, для начала давайте разберемся, зачем же мы вообще собираемся каждый день…
В первую очередь, это способ скоординировать действия всей команды, которая совместно взяла на себя ответственность сделать что-то определенное до конца итерации. Важно – это не «отчетная встреча», а способ инспекции и адаптации команды к реальной жизни, которая обычно вносит свои коррективы в то, как мы запланировали наш спринт.
Чтобы провести встречу быстро и эффективно, автор Scrum, Кен Швабер, предложил три простых вопроса, которые должны помочь:
- Что я собираюсь делать до следующей «встречи на ногах», чтобы реализовать наш общий план итерации?
- Что я сделал с прошлой встречи?
- Что может помешать мне или всей команде реализовать наш общий план?
Внимательные читатели, могли обратить внимание, что я специально переставил вопросы местами и даже слегка «подправил» формулировку, чтобы подчеркнуть, что это не «отчетная встреча» и особенно то, что наиболее важный вопрос самый первый: «Что я собираюсь делать до следующей встречи?».
Совместное планирование работ во время спринта (итерации), является одним из важнейших моментов работы «по Scrum» и одновременно эффективным средством личного управления временем. Если член команды не знает, что ему делать сегодня то, скорее всего, на следующей встрече он вряд ли сможет внятно сказать, что он делал. :-) . К тому же, реальная жизнь часто не позволяет нам работать «строго по плану», поэтому важно, чтобы вся команда эффективно распределяла силы и время каждого из участников.
Вопрос «Что я сделал с прошлой встречи?» действительно звучит как некий «отчет», хотя, как уже упоминалось, команда совместно взяла на себя ответственность сделать что-то определенное до конца итерации. Каждый участник команды, проявляя ответственность перед другими участниками, например, уведомляет о завершении работы над компонентом, который могли ждать коллеги, или который необходимо уже протестировать или даже показать Владельцу Продукта, чтобы он осуществил приемку и дал обратную связь как можно скорее.
Такое проявление личной ответственности за командное дело является эффективным способом укрепить командную работу и повысить эффективность всей команды. Конечно, если вы пришли неподготовленным на встречу со звездой с командой, то ваш рассказ о том, как вы вчера играли в Quake перенастраивали компьютер, может иметь негативный эффект для всей команды. Особенно, если на встрече присутствуют Владелец Продукта или вообще посторонние. Возможно, это вопрос доверия внутри команды, хотя проще и лучше, при случае обсудить всей командой, что каждый считает эффективным/не эффективным ответом на этот вопрос.
Думаю, что с вопросом «Что мешает мне или команде?» все достаточно просто и ясно. Как сказал один мой знакомый: «вовремя поднятый “кипиш” может сэкономить потом выходные авральной работы». Если без шуток, то важно, чтобы каждый участник команды задумывался даже над потенциальными проблемами и своевременно обращал на них внимание всей команды. Подумайте немного над реальными примерами из жизни вашей команды, и уверен, вы вспомните много достаточно интересных моментов:
- Не присланный вовремя ответ от заказчика о его предпочтениях, который застопорил работу по новой функциональности и в результате сорвал сроки
- Не полученная вовремя ссылка (информация) с сайта партнеров
- Упавший сервер «непрерывной интеграции» (continuous integration), который вовремя не подняли и тем самым пропустили проблемы сборки всего продукта
и т.д. и т.п. Знакомо? :-)
Для вашей команды может быть необходимо, расширить встречу дополнительными вопросами. Так, однажды я натолкнулся на идею о так дополнительном вопросе как, например: «что я узнал, изучил, решил такого, что может быть важным для кого-нибудь из команды?». Возможно, вы спрашиваете, друг друга о том «как изменились наши первоначальные оценки и повлияют ли они на весь план спринта?». Те команды, которые можно сказать «научились проводить эффективную ежедневную встречу “на ногах”», скорее всего не забывают о цели встречи и не боятся экспериментировать с форматом.
Будем признательны за ваши комментарии, в которых вы расскажете, как вы проводите ваши ежедневные встречи!
Источник: http://tim.com.ua/2009/08/why-we-do-daily-scrum/
SCRUM Митинг (daily scrum meeting)
Существует 2 основных типа, на которые делятся методологии разработки програмного обеспечения (software development methodology). Это структурные и гибкие методологии. Структурные методологии предполагают высокоформализованный подход к разработке ПО (каскадная модель). Гибкие методологии (Agile) ориентированы в основном на итеративную разработку с минимально допустимой формализацией процесса.
Об основных принципах гибких методологий я расскажу в другой статье. А обратить ваше внимание хочу вот на что. Agile методологии очень хорошо себя зарекомендовали и сейчас даже самый высокоформализованный процесс трудно себе представить без “гибких” элементов, в частности митингов.
Итак, SCRUM-meeting.
SCRUM - одна из гибких методологий разработки ПО. Впервые была использована в 1993 с целью улучшить продуктивность команды разработчиков, сделав упор не на качественно определенный, а на качественно контролируемый процесс разработки.
Важной частью этой методологии являются SCRUM-митинги, которые должен курировать компетентный человек - SCRUM-Master (чаще всего project manager или team lead). Такие митинги для большего эффекта нужно проводить каждый день в одно и то же время. Длительность митинга лучше ограничивать 15-30 минутами. Каждый участник проектной команды должен ответить на 3 простых вопроса:
- Что было сделано с момента предыдущего SCRUM-митинга?
- Какие возникли проблемы во время работы?
- Какими задачами буду заниматься после митинга?
После ответа на любой из этих вопросов, другие члены команды могут прокомментировать слова своего сотрудника. SCRUM-Master следит за тем, чтобы такие комментарии не затягивались и не переходили в споры. В таких случаях обсуждение некоторого вопроса SCRUM-Master откладывает на удобное для заинтересованных лиц время.
Если вы еще не проводите SCRUM-митинги внутри своей команды, вот очевидный список преимуществ этого подхода:
- За очень короткий промежуток времени project manager и все члены команды могут оценить статус проекта.
- Все возникшие проблемы решаются очень быстро так как доносятся до всех участников проекта (среди которых потенциально есть компетентные в данном вопросе люди).
- Сотрудники учатся слушать других, понимать их, а также четко выражать свои собственные мысли.
- Участники проекта учатся ставить перед собой реальные задачи и отвечать за статус их выполнения.
Мне, конечно, еще далековато до SCRUM-мастера и тем более до Project-менеджера, тем не менее, хочу поделиться некоторыми своими наблюдениями:
- Существуют проблемы, требующие немедленного решения. Такие проблемы нужно решать сразу, даже если митинг из-за этого может немного затянуться.
- Не смотря на это, SCRUM-мастер должен понимать, что длительные конфликтные обсуждения чаще всего заканчиваются компромиссом (а не консенсусом, как должно быть в идеале).
- Команды больше 7-9 человек желательно разбивать на группы, у каждой из которых есть свой SCRUM-Master. Пример: проведя параллельно совещания для тестировщиков и разработчиков можно сэкономить время и силы членов команды. После этого SCRUM-мастеры могут обсудить между собой возникшие проблемы и решить их с участием заинтересованных лиц.
- Бывают ситуации, когда человека лучше освободить от участия в митинге: если он очень сконцентрирован на решении некоторой задачи, на митинге он будет менее внимателен, да и после митинга ему будет труднее заново вникнуть в суть проблемы.
Очень надеюсь, что данная статья была вам интересна. Комментарии приветствуются.
Источник: http://www.javenue.info/post/59
SCRUM-митинг с самим собой
В этой заметке я расскажу ещё об одной технике, которую я добавил к своей обойме полезных и эффективных привычек. В предыдущей статье “Мозговой штурм с самим собой” я рассказал о том, как можно адаптировать и применять одну из эффективных “офисных” техник к своей повседневной жизни. Сегодня я расскажу об ещё одной практики, применяемой в офисных застенках и о том, как я адаптировал данную эффективную практику для своей повседневной жизни.
Для начала небольшое вступление, что бы стало понятно, о чём вообще идёт речь. Я работаю в индустрии разработки программного обеспечения – руковожу программными проектами. Проще говоря – руковожу группой аналитиков, разработчиков, тестировщиков, дизайнеров… И как менеджер программных проектов я следую (стараюсь следовать =) определённым методологиям, принятым в нашей отрасли. Одной из таких популярных на сегодняшней день методологий является методология SCRUM (обзор методологии можно прочитать здесь). Одним из обязательных процессов в данной методологии является обязательное проведение Daily Scrum Meeting – ежедневного SCRUM митинга (совещания команды проекта). О нём и пойдёт речь.
Итак, основная суть данного ежедневного совещания состоит в том, что бы в самом начале рабочего дня собрать всю команду проекта и не более, чем за 15 минут получить от каждого участника ответы на три вопроса: что было сделано вчера, что будет сделано сегодня, с какими проблемами столкнулись. Т.е. каждый человек за пару минут даёт ответы на эти вопросы, а ведущий встречи записывает все возникшие проблемы и вопросы, которые решаются за рамками данной встречи. Таким образом, такая ежедневная “летучка” позволяет членам команды эффективно обмениваться информацией, а менеджеру проекта держать руку на пульсе и вскрывать возникшие проблемы на начальном этапе их зарождения.
Используя данный подход в одном из своих “коротких” проектов я убедился в его эффективности (команда проекта небольшая) и решил попробовать применить тоже самое на себе. В статьях “Ты уверен, что эффективно планируешь своё время?” и “Планирование работы - “побочные” эффекты” я уже писал о том, что каждый вечер я планирую завтрашний день по принципу четырёх квадратов. Это вошло у меня в привычку. Т.е. каждый вечер в течении 10 минут я составляю список дел на завтра и ещё минут 5 посвящаю GTD-активностям. Теперь, дополнительно к этому, я сам себе явно задаю ещё три вышеупомянутых вопроса. Но, т.к. я “митингую” не утром, а вечером, то вопросы немного изменились: что было сделано за сегодня, что я буду делать завтра (на этот вопрос я уже отвечаю давно, составляя план на следующий день) и какие возникли проблемы с сегодняшними делами. В результате такого самоопроса у меня зачастую возникает масса задач и идей, которые тут же уходят в мой GTD-список, и к которым обращаюсь позже (но не забываю о них, как это часто бывает, когда что-то приходит на ум, но нигде не фиксируется).
Ничего нового в том, что я описал, нет – все эти три вопроса каждый человек задаёт себе с какой-то периодичностью. Но суть идеи в том, что бы этот период стал фиксированным (раз в день), а вопросы вполне конкретными и относящимися к предыдущим 24 часам, а не риторическими, типа “чего я достиг за свою жизнь” =)
Итак, попробуй вечером, после работы, на несколько минут сесть и спросить себя:
- Что я сделал за сегодня (в том числе и такого, что приблизило меня к своей мечте или цели).
- Что я сделаю завтра (для того, что бы не прожечь ещё один день своей жизни, занимаясь только рутиной).
- Какие у меня возникли проблемы (или новые задачи).
В результате такого экспресс анализа у тебя на выходе будет:
- Удовлетворение от осознания того, что сегодня ты ещё немного (или много) продвинулся в осуществлении своих целей. Либо осознание того, что день был потерян и что надо что-то менять в этой связи.
- Список дел на завтра (или, если ты проповедуешь чистый GTD, то обновление общего списка дел).
- Список задач на ближайшее время, к которому ты вернёшься и которые ты уже не забудешь.
Идея о ежедневном анализе своей активности и планирования дел на следующий день, не нова и описана в различных источниках. Так что т.н. ежедневный SCRUM-митинг с самим собой – ещё одно воплощение этой идеи, достаточно простое, что бы начать применять его уже сегодня и достаточно эффективное, что бы начать получать результаты от его проведения уже завтра =)
Постоянный адрес статьи: http://www.agoge.ru/2008/03/17/scrum/
Автор: Алексей Павлов
