вторник, 23 ноября 2010 г. - www.msmirnov.ru

Статус-митинги

Несколько месяцев назад я изменил формат проведения наших статус-митингов.

Статус-митинги я провожу каждую пятницу в 16:30 на протяжении последних нескольких лет (уже не помню скольких, наверное лет 5-ти).

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

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

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

В завершении статус митинга я по прежнему озвучиваю план на следующую неделю для каждого члена команды.

Конечно, длительность статус-митинга благодаря изменениям увеличилась – раньше он занимал около 5-ти минут, теперь около 30-40-ка минут, в зависимости от ситуации.

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

Мой сайт - www.msmirnov.ru

22 комментария:

  1. Ну, шаг вперёд :)



    Осталось тебе начать проводить эти "митинги" ежедневно в начале рабочего дня, чтобы каждый член команды мог сказать, над чем работал вчера, что успел сделать из запланированного на вчера, что не успел, почему не успел, какие проблемы (если есть) и что планирует сделать на сегодня (а завтра расскажет о статусе) :)



    Тогда митинги снова будут занимать 5-10 минут (для того, чтобы не затягивалось, предлагается делать эти митинги "стоячими"), информация (самое главное - о затыках, которые выявляются просто сразу) будет поступать гораздо оперативнее, члены команд будут более информированы о работе друг друга.



    И вот так вот у тебя могут получиться нормальные стендап-митинги в том формате, который сейчас, пожалуй, доминирует в мире разработки софта :)))

    ОтветитьУдалить
  2. Кстати, в дотальфе же всё равно все чай пьют утром

    Вот он и готовый "общий сбор", собирать никого не надо

    ОтветитьУдалить
  3. Не, чай - неудачное время - слишком расслабленная атмосфера.

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



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



    Это называется "Ретроспектива".



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



    А вообще забавно смотреть на движение в направлении agile.

    ОтветитьУдалить
  5. А, ну и фактически исполнитель задания становится известным в начале дня, а не в начале недели, ну и задачи (за редким исключением) ограничиваются рабочим днем.



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

    ОтветитьУдалить
  6. На счет девочки не понял - как ей замужество помещало работать над проектом?

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

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



    Ну и я был в роли наблюдателя.

    ОтветитьУдалить
  8. про чай:

    они все равно там сидят и болтают

    и точно также будут болтать, но зато о том, о чем нужно :)

    и чай пить это никому не помешает



    причем, насколько я помню, чай длится 30-40 минут

    для стэндапа, я думаю, хватит 15-20



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



    >слишком расслабленная атмосфера

    фишка в том, что стэндап это ж не презентация клиенту



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

    ОтветитьУдалить
  9. > ну в скруме это в начале итерации, когда распределяются задачи



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

    ОтветитьУдалить
  10. Про "девочку" - это пережитки подхода, когда конкретная задача "назначается" на конкретного человека, что есть булшит в 90% случаев или более. В случае, когда все задачи в начале итерации "назначаются" на (под)команду такое невозможно.
    А заболеть, уйти в отпуск, выйти замуж и умереть можно и вдруг. Ситуации разные бывают.

    ОтветитьУдалить
  11. Ну я как раз был наблюдателем в тот момент, и отметил для себя, что команда должна осознать на ретроспективе, что конкретных исполнителей задачи быть отныне не должно (до момента принятия задачи в работу).



    Ну а почему задачи назначаются на конкретных людей - вполне понятно. Просто потому что в этом случае задачу достаточно обозначить и совершенно не обязательно формулировать (исполнитель "понимает" о чем идет речь), и не надо определять "done-criteria". Как показывает практика, если что-то "подразумевается", то оно подразумевается двумя людьми (постановщиком и исполнителем) всегда по-разному. Ну и от "подразумевается" мы (все три наших команды) в конечном итоге отказались, и по каждой задаче идет "описание" её законченной фазы, кроме некоторых общих правил законченности задачи (фактически - протестировано на тестовом окружении). Чтобы её в работу её мог взять любой член команды, обладающий достаточными навыками.

    ОтветитьУдалить
  12. Pavel Hritonenko Классно. Мы делаем полное описание PBI (со сторибордами, картинками из Бальзамика и т.д.), а вот описаний конкретных тасков-SBI, которые создаются на основе этих сторибордов, не существует, к сожалению, сколько я ни бился :(

    ОтветитьУдалить
  13. Ну SBT у нас тоже часто не полностью описаны (хотя результат выполнения явно понятен всем членам команды). Да и часто PBI соответствует ровно одному SBT.



    Ну и product owner постоянно борется за подробное описание задачи (хотя это его не касается, в принципе).

    ОтветитьУдалить
  14. Должен сообщить, что по истечении времени идея не прижилась...

    Постепенно статус-митинги вернулись к своему обычному формату.

    ОтветитьУдалить
  15. Не, у нас тоже не прижились "общие стэндапы", которые мы проводили на весь отдел. Причина банальная: народу слишком много, и в итоге это занимало от 20 в самом лучшем случае, до 40 минут. Стоя... И многим было неинтересно, чем занимаются другие, т.к. модули системы очень разные.

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

    Скрам - это фреймворк, под каждый конкретный случай его можно и нужно крутить.

    ОтветитьУдалить
  16. Ну вот сразу фэйл :)

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

    Так что постепенно все вернулось на круги своя.

    ОтветитьУдалить
  17. Зато общие (на 17 человек) очень хорошо получаются ретроспективы. И еще презентации каждой командой сделанного функционала, с приглашением всех желающих "зрителей", тоже отлично проходят. Рекомендую!

    ОтветитьУдалить
  18. Ну тем не менее, для "стендапов" есть некоторые правила, и некоторые принципы, для которых они вообще проводятся.

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

    2. Задачи на команду не должны ставиться больше чем на один рабочий день (бывают, конечно же, исключения), чтобы не была нормальной ситуация, когда человек не получает фидбека от команды (не должно быть "я сегодня делаю тоже самое, что и вчера"). У нас задачи 4-6 часов, вот пара задач на 8 и 12 часов в эту итерацию. Очевидно, что если задачи ставятся на несколько дней, то смысла в ежедневных стендапах нет.

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

    4. Ограничивайте время стендапа. Если не укладываетесь - просто прекращайте его.

    5. На стендапе PO/SM видят прогресс команды (Sprint Burndown Chart) и могут предпринять какие-то действия, чтобы вернуть прогресс выполнения итерации в нормальное русло.

    А ну и скрам не предполагает больших команд. 3-7 человек, идеально, наверное - 5 человек в команде. Далее идет скэйлинг в сторону scrum of scrums (проводится митинги в командах, а затем митинг для синхронизации действий проводят уполномоченные представители команд).

    ОтветитьУдалить
  19. Митинги подобные имеет смысл проводить:
    а) чаще;
    б) в рамках команды, а не "собрал всех программистов компании";
    в) смысл не в том, чтобы отчитаться перед начальником, а в том, чтобы кратенько рассказать остальным о том, над чем ты сейчас работаешь или планируегь заняться, какие и в чём проблемы. Чтобы команда знала как у неё дела. И уж точно не для того, чтобы Начальник назначил Задачу. В принципе, присутствие Начальника на таких митингах и не обязательно, членов команды достаточно. Просто присутствие лица, способного устранить проблему, находящуюся вне круга влияния команды облегчает процесс. Когда проблема есть :)

    Это позволяет сократить время митинга до 2-5 минут в команде на 5 человек и увеличить полезность немерено.
    Смысл просто в другом у таких митингов. А без понимания смысла всегда будет фейл бездумной апликации :)

    ОтветитьУдалить
  20. Конкретно про свою ситуацию могу сказать, что попытка внедрить митинги в новом формате делалась без какой-либо оглядки на Scrum. Она не была частью процесса его внедрения, которое, в общем-то, и не планировалось.

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

    Однако, толку от такой формы оказалось не много.

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

    ОтветитьУдалить
  21. А я и не говорил о скраме или любой конкретной методологии. Я говорил о работе команды как команды и обмене информацией как раз. Это крайне важно. //Алексей из аэропорта.

    ОтветитьУдалить