Scrum в студии:
Daily Meetings
Бонус: кто круче — Product Owner vs Scrum Master
Прошла ровно неделя с того дня, как мы запустили третий спринт.
Напомню, наша задача была — интегрировать проект с социальными сетями, добавить рейтинги пользователей, сделать проект масштабируемым на несколько географически удаленных серверов.
В процессе работы задача немного мутировала и мы реализовали не только масштабирование по серверам, но и p2p-соединения для раздачи контента (скоро ждите про это отдельный пост, со сравнением производительности).
Итак, каждый день, ровно в 10:00 мы собирались у одного и того же компьютера, и обсуждали наш прогресс по проекту.
Напомню, наша задача была — интегрировать проект с социальными сетями, добавить рейтинги пользователей, сделать проект масштабируемым на несколько географически удаленных серверов.
В процессе работы задача немного мутировала и мы реализовали не только масштабирование по серверам, но и p2p-соединения для раздачи контента (скоро ждите про это отдельный пост, со сравнением производительности).
Итак, каждый день, ровно в 10:00 мы собирались у одного и того же компьютера, и обсуждали наш прогресс по проекту.
Глобальная доска задач
В классическом скраме ежедневные митинги (Daily meetings, стендап (Standup Meeting)) проводит специально обученный человек — Cкрам-мастер (Scrum Master).
Cкрам-мастер — это член команды (грубо говоря, программист). Его задача — помочь команде стать самоуправляемой (чтоб работала без внешних пинков). Cкрам-мастер следит за соблюдением методик скрам, а так же за тем, чтобы команда выполняла принятые ей же решения. В случае возникновения проблем в процессе разработки, он помогает команде их решить (например, просит менеджера проекта устранить излишнюю бюрократию ;-))
На ежедневном митинге скрам-мастер задает членам команды три вопроса:
Cкрам-мастер — это член команды (грубо говоря, программист). Его задача — помочь команде стать самоуправляемой (чтоб работала без внешних пинков). Cкрам-мастер следит за соблюдением методик скрам, а так же за тем, чтобы команда выполняла принятые ей же решения. В случае возникновения проблем в процессе разработки, он помогает команде их решить (например, просит менеджера проекта устранить излишнюю бюрократию ;-))
На ежедневном митинге скрам-мастер задает членам команды три вопроса:
- Что было сделано за вчера?
- Что будет сделано сегодня?
- Какие были проблемы?
Каждый член команды отвечает на эти вопросы. Скрам-мастер следит за тем, чтобы не было дискуссий (но не подавляет их, а выносит на отдельные обсуждения, после Standup meeting). Продолжительность Standup meetings у нас — 5−9 минут.
Итак, отвечая на первый вопрос «Что было сделано за вчера», мне очень важно понять, какие изменения произошли в системе (что добавилось, на что могли повлиять изменения). Поэтому принять ответы типа «Я сделал задачи 32, 134, 372» — я не могу, из них ничего непонятно. Нужно рассказывать именно про изменения в системе, а команда уже запросто обнаружит, какие проблемы это могло создать. (Хорошим ответом будет, например: «Вчера я удалил user_id из таблицы users, так как он не использовался в коде» — сразу понятно, кого бить, и за что :-D)
Второй вопрос требует, чтобы перед Standup meeting каждый посмотрел свой список задач, и выбрал самые приоритетные. Это избавит от необходимости назначать задачи на митинге и сэкономит огромное количество времени (на митинге время течет гораздо быстрее: если 4 человека проводят митинг в течении 15 минут — улетает час рабочего времени. За две недели набегает целый рабочий день. Оправданы ли такие расходы?)
Третий вопрос направлен на выявление потенциальных проблем в будущем и обмен опытом. Тут очень важно не превращать StandUp meeting в технические совещания. Однако все высказанные командой опасения и проблемы должны быть обязательно разобраны и решены, но уже после. Если начинается какая-то техническая перепалка или спор, скрам-мастер должен его прекратить и довести до конца Standup meeting, а позднее вернуться к обсуждению проблемы.
У нас в студии Scrum Master и Product Owner — одно лицо: менеджер проекта. Это отклонение от классической методологии, поэтому возникает ряд сложностей. Scrum Master и Product Owner, не смотря на то, что хотят добиться одного и того же результата, действуют иногда по разные стороны баррикад.
Product Owner отстаивает в первую очередь интересы пользователя, и, соответственно, заинтересован в более оптимистичных оценках, минимизации времени на исследования, разработке фич (а не полировке кода).
Scrum Master, напротив, отстаивает интересы команды, увеличение временных буферов на разработку, «полировку» кода проекта. Лично для меня всегда было, и остается самым сложным в совмещении этих ролей — не давить на команду в момент принятия решений.
Приверженцы scrum-а могут сказать, что совмещение роли Scrum Master и Product Owner — грубое нарушение правил. Тем не менее, гуру scrum, Асхат Уразбаев отмечает подобную тенденцию:
Итак, отвечая на первый вопрос «Что было сделано за вчера», мне очень важно понять, какие изменения произошли в системе (что добавилось, на что могли повлиять изменения). Поэтому принять ответы типа «Я сделал задачи 32, 134, 372» — я не могу, из них ничего непонятно. Нужно рассказывать именно про изменения в системе, а команда уже запросто обнаружит, какие проблемы это могло создать. (Хорошим ответом будет, например: «Вчера я удалил user_id из таблицы users, так как он не использовался в коде» — сразу понятно, кого бить, и за что :-D)
Второй вопрос требует, чтобы перед Standup meeting каждый посмотрел свой список задач, и выбрал самые приоритетные. Это избавит от необходимости назначать задачи на митинге и сэкономит огромное количество времени (на митинге время течет гораздо быстрее: если 4 человека проводят митинг в течении 15 минут — улетает час рабочего времени. За две недели набегает целый рабочий день. Оправданы ли такие расходы?)
Третий вопрос направлен на выявление потенциальных проблем в будущем и обмен опытом. Тут очень важно не превращать StandUp meeting в технические совещания. Однако все высказанные командой опасения и проблемы должны быть обязательно разобраны и решены, но уже после. Если начинается какая-то техническая перепалка или спор, скрам-мастер должен его прекратить и довести до конца Standup meeting, а позднее вернуться к обсуждению проблемы.
У нас в студии Scrum Master и Product Owner — одно лицо: менеджер проекта. Это отклонение от классической методологии, поэтому возникает ряд сложностей. Scrum Master и Product Owner, не смотря на то, что хотят добиться одного и того же результата, действуют иногда по разные стороны баррикад.
Product Owner отстаивает в первую очередь интересы пользователя, и, соответственно, заинтересован в более оптимистичных оценках, минимизации времени на исследования, разработке фич (а не полировке кода).
Scrum Master, напротив, отстаивает интересы команды, увеличение временных буферов на разработку, «полировку» кода проекта. Лично для меня всегда было, и остается самым сложным в совмещении этих ролей — не давить на команду в момент принятия решений.
Приверженцы scrum-а могут сказать, что совмещение роли Scrum Master и Product Owner — грубое нарушение правил. Тем не менее, гуру scrum, Асхат Уразбаев отмечает подобную тенденцию:
Асхат Уразбаев
Гуру scrum
— На заре туманной юности я был твердо убежден, что менеджер проекта не может быть скрам-мастером. Сейчас у меня появились сомнения. Надо сказать, что основания у меня были. Некоторые происходившие у меня на глазах превращения менеджеров проектов в скрам-мастеров оканчивались печально. Стендапы превращались в отчетные мероприятия, ретроспективы проводились менеджером сольно, причем он еще и имел наглость упрекать команду в пассивности. В общем, чего я вам рассказываю ;-)
Очень часто последнее время наблюдаю такую картину:
Есть менеджер проекта — который вроде как формально Product Owner. В команде есть Scrum Master. В общем, все по науке. Только скрам-мастер выполняет свои функции номинально. А вот менеджер проекта действительно вкладывается в то, чтобы сделать команду эффективной. Он задает правильные вопросы на ретроспективе, его советы команде наиболее дельные, он решает все внешние зависимости и устраняет препятствия.
Самое интересно, что и Product Owner из него тоже в общем-то нетипичный. Он старательно дистанцируется от самостоятельного принятия решений. Чаще всего он старается собрать всех заказчиков в группу и проводит встречу, заказчики коллективно договариваются о приоритетах и требованиях. Как правило, он устанавливает некоторую каденцию общения (уж простите термин, не удержался) — например, назначает еженедельные встречи.
Забавно, но он точно также вкладывается в то, чтобы команда заказчиков стала эффективной, как и в команду разработчиков. Если отбросить тонкости, то он становится скрам-мастером команды заказчиков и команды разработчиков, формально таковым не являясь. Такая схема на практике часто является очень эффективной.
Очень часто последнее время наблюдаю такую картину:
Есть менеджер проекта — который вроде как формально Product Owner. В команде есть Scrum Master. В общем, все по науке. Только скрам-мастер выполняет свои функции номинально. А вот менеджер проекта действительно вкладывается в то, чтобы сделать команду эффективной. Он задает правильные вопросы на ретроспективе, его советы команде наиболее дельные, он решает все внешние зависимости и устраняет препятствия.
Самое интересно, что и Product Owner из него тоже в общем-то нетипичный. Он старательно дистанцируется от самостоятельного принятия решений. Чаще всего он старается собрать всех заказчиков в группу и проводит встречу, заказчики коллективно договариваются о приоритетах и требованиях. Как правило, он устанавливает некоторую каденцию общения (уж простите термин, не удержался) — например, назначает еженедельные встречи.
Забавно, но он точно также вкладывается в то, чтобы команда заказчиков стала эффективной, как и в команду разработчиков. Если отбросить тонкости, то он становится скрам-мастером команды заказчиков и команды разработчиков, формально таковым не являясь. Такая схема на практике часто является очень эффективной.
В следующий раз я расскажу, как и зачем у нас проводятся ретроспективы. Мы очень долго использовали элементы scrum, не проводя ретроспектив вообще, но в какой-то момент стало понятно, что какие-то вещи остались невысказанными, и нет ощущения законченности проекта. Попробовали — понравилось (мотивирует и ставит жирную точку под хорошо выполненной работой ;-)