Standup-meeting

Standup'ы одна из основных частей «гибких» методологий, описано практически во всех книжках по гибким методикам, и, я считаю, обязательная вещь для команд от 2 до 15 человек, какую бы методику производства софта они не исповедовали. Наверное, все понимают, что коммуникации при разработке софта очень важны, их всегда мало, так вот стендапы отлично увеличивают объем общения в команде, и вообще приносят очень сильный прирост производительности.
И это, кстати, отлично приживается и без использования прочих методик из этой же серии, вроде парного программирования, карточек с пользовательскими историями, и пр.
Хочу заметить, что я говорю это исходя из собственного опыта, а не прочтения статей и книг.

Под катом более-менее подробной описание сути этого подхода, в вопросах и ответах.

Что такое standup?

Это короткая ежедневная встреча, на которой обсуждается прогресс и текущие работы. Это основа коммуникаций в компании, передачи информации между участниками, организации в команде. Можно назвать это мини отчетом/историей дел и мини планированием.

Для чего standup не подходит?

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

Какова цель таких встреч?

  • Повысить информированность о текущем прогрессе и задачах.
  • Скорректировать и направить деятельность команды в единое русло.
  • Выставить приоритеты и сфокусироваться на работе, до следующего стендапа.
  • Увидеть текущие проблемы вовремя, а также дает возможность помочь с решением, т.к. становится известно, у кого какая проблема возникнет, и кто способен помочь.
  • Улучшить командный дух и коммуникацию в команде

Что происходит во время таких встреч?

Вся команда собирается в договоренное время, один раз в день в определенном месте. Люди встают по кругу или лицом к доске с задачами и планами.

По кругу каждый из участников отвечает на следующие 3 вопроса:

  1. Что я сделал с последнего собрания?
  2. Что я буду делать сегодня?
  3. Какие сложности нужно будет решить?

Карточки с задачами помогают ему и слушателям понять задачи. Можно также сообщать еще что-либо помимо этого, если это важно всем присутствующим.

Кто должен присутствовать?

Присутствовать должны лишь люди участвующие в разработке текущей итерации, это разработчики, тестеры, люди, отвечающие за итерацию.

Нужны ли какието временные рамки?

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

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

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

Когда проводить встречу?

Есть 3 варианта:

  1. Сразу с утра, перед работой
  2. В середине дня, после или перед обедом
  3. В конце дня

Первое отлично работает, когда вся команда собирается в одно время с утра, без опозданий. Стендап начинает рабочий день, помогает запланировать сегодняшние дела, сфокусироваться на задачах, распределить приоритеты. Мне так кажется это самый идеальный вариант, с утра обычно с трудом начинается сама работа, всегда есть куча задач, за которые просто страшно браться, и не хочется все это планировать. А вот обсудив в компании, все становится на свои места и, легко и непринужденно, «утро» превращается в рабочий день.
Также начальник узнает о текущих задачах и проблемах, которые будут в течении дня.

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

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

Должен ли standup быть запланирован на определенное время?

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

И не надо ждать опоздавших, встреча она для команды, а не для отдельных опаздывающих личностей!

Нужен ли кто-то, кто инициирует эти встречи?

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

Кто отвечает за то, чтобы эти встречи работали?

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

Могут ли некоторые члены команды не посещать эти встречи?

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

Являются ли стендапы аналогом остальных формальных встреч?

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

Вообще, если думать о стендапе как об «ответе на три вопроса», то мы недалеко уходим от простого отчета перед начальством. В таком случае «ответ» и «вопрос» ассоциируются с допросом, а не с общением.
А стендап не должен выглядеть как отчет перед начальством. Это должно быть ответами на вопросы как в обычной беседе, т.е. просто собрались командой, обсудили положение дел и вернулись к самой работе.

Для чего нужен мячик, или какой либо иной указатель при общении?

Указателем/маркером/пр. может быть небольшой резиновый мячик, или другой предмет, который передается друг другу, чтобы показывать статус держащего. Только тот, у кого этот предмет, говорит в это время. Это помогает не уходить далеко при длинных разговорах, хотя в таких случаях, когда с кем-то может начаться длительная дискуссия, можно передать ему мячик, но лучше договорится обсудить это после собрания, т.к. здесь нужно лишь общее обсуждение, а не решений конкретных задач.

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

Могу ли я говорить если у меня нет мячика? Это будет нормально, если я кого-то прерву?

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

Как детально углубляться в задачи?

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

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

Весь предыдущий день я был в паре с другим разработчиком. Должен ли я повторять за ним?

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

Если какие-то требования для ведения стендапа?

  • Члены команды должны свободно себя чувствовать во время общения
  • Все члены команды должны иметь возможность беседовать друг с другом, поэтому у распределенных команд с этим есть небольшая проблема
  • Доска с задачами и планом очень полезна для таких собраний, но не является совсем обязательной частью
  • Для стендап митинга также вовсе не обязательно соблюдать прочие «гибкие» методики разработки

Можем ли мы проводить более одного стендапа в день?

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

Может ли стендап быть распределенным?

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

Стоит ли делать какие-то заметки во время стендапа?

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

Нужно ли как-то подготавливаться к собранию?

Стендапы проходят у доски с текущими задачами и графиком работ. И будет полезным перед собранием приводить все это в порядок, относительно текущего состояния дел.
Если команда работает с небольшими задачами, на 4-8 часов, тогда участники смогут просто указывать на сами задачи, не тратя время на описание самой задачи.
В начале, когда команда или отдельные участники начинают практиковать стендапы, будет полезно собраться за несколько минут и продумать свои ответы на «3 вопроса». Это поможет в дальнейшем четче и быстрее рассказать о них на самом собрании. После небольшой практики от этого можно отказаться.

Нужно ли обновлять список текущих задач (на доске) и планы во время собрания?

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

Надо ли определяться с партнерами для парного программирования во время стендапа?

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

Заменяет ли стендап полноценное собрание?

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

Нужно ли вести какой-то учет присутствующих? Что если кто-то пропустил?

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

Вольный перевод статьи Naresh Jain: FAQs on Standup, с некоторыми личными дополнениями.

  • http:// Стас

    Что-то я не ощутил всей прелести. А какой смысл Васе выслушивать, что сделали и собираются делать Саша, Петя и Коля?

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

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

  • http:// igor

    Если по прихоти начальства то это уже не то, как там сказано, это команда должна делать сама.

    Если «мекая и бекая», то значит есть проблемы в проекте, иначе почему же человеку сложно сказать чем он занимался и чем планирует? Значит он не знает четко что делает, занимается чем придется, без всяких планов, задач и приоритетов.

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

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

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

  • http:// Стас

    Очень просто. Планированием по проекту занимаются не члены команды, а тимлид, как правило. Идет постановка задач разработчикам в Багзилле, по ходу выполнения задач разработчики оставляют вопросы и комментарии в баге, по выполнению баг закрывается. Бывает и так, что разработчику предоставляется проект, который он сам должен распланировать и выполнить. Тогда он просто сам себе создает задачи(баги) и работает над ними.

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

    Код коммитится в репозиторий Subversion, так что у всех разработчиков всегда на руках свежая копия проекта.

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

    При этом некоторых членов команды я могу месяцами не видеть лично, а некоторых даже (!) не знать в лицо.

    Плюсы нашей системы учета и коммуникаций по сравнению со standup meetingами:

    — сохраняется возможность работы по гибкому графику, нет необходимости, чтобы время работы обязательно где-то пересекалось, один человек может работать ночью, другой днем;

    — никаких проблем с разделенными/удаленными разработками. люди могут находиться вообще в разных точках планеты Земля, и при этом эффективность коммуникации не страдает.

    Я, когда уезжал в отпуск, взял с собой ноутбук, и имел возможность полностью отслеживать прогресс по всем проектам;

    — не каждый разработчик обладает хорошими навыками быстро и лаконично рассказать про то, чем он занимается и чем займется. если он будет мекать, бекать, то вот ты уже по дефолту сочтешь, что он протирает штаны и толком не работает. а может, он просто застенчивый и некоммуникабельный.

    — весь ход работы над проектом от самого начала до релиза последней версии полностью документируется, и даже через два года можно легко восстановить всю картину. На standup-meetingsах все обсуждается устно и кратко. В одно ухо влетит, в другое вылетит.

    — еще нюанс предыдущего преимущества. Если коммуникации идут устно, то у разработчика потом есть возможность что-то забыть, недослышать, недопонять. Потом на разборе полетов спрашиваешь — почему вот это не сделано? Ответы: «а ты разве говорил это сделать?» «а я забыл». А если четко поставлена задача в Багзилле, то уже не отвертеться. 🙂 Именно поэтому даже если я ставлю кому-то задачу устно, всегда дублирую задачу в багзилле.

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

    — ну и наконец, коммуникации происходят только тогда, когда они действительно нужны, и только между заинтересованными людьми.

    Более подробно почитать про нашу систему учета можно на www.itworktimer.com

  • http:// igor

    Не не, ты не понял немного суть стендапа... Прочитай текст еще раз 🙂

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