Когда интерфейс имеет значение

Блог

SCRUM в веб-студии: взгляд изнутри

SCRUM в веб-студии: взгляд изнутри

Автор, 13.03.2012

 

Владимир Завертайлов, директор «Сибирикс»

Я решил сделать небольшой репортаж о том, как у нас происходит разработка. Не секрет, что мы используем Scrum при работе над более-менее крупными проектами.

Справка:

Scrum — создание программного продукта кросс-функциональной командой, разделённое на временные стадии (спринты), с учётом регулярно обновляемых и чётко расставленных приоритетов. Члены команды на протяжении спринта ежедневно устраивают обсуждения — «митинги». Ключевые в скрам-проекте люди — «владелец продукта», он же представитель заказчика, и скрам-мастер, который следит за соблюдением принципов Scrum и модерирует дискуссии. Каждый спринт, являющийся полноценным циклом работ от планирования до тестирования, теоретически выливается в очередную промежуточную ревизию продукта.

Вообще использование scrum для web-студий — довольно нетипичная тема. Но у нас он прижился. В первую очередь потому, что мы делаем технически сложные проекты, а работу (для ускорения процесса) организовали по командам. Конечно, добавляется ряд накладных расходов, но в целом команда из 2-х человек может сделать проект в 1,5—2,5 раза быстрее, чем программист в одиночку. А еще это сильно мотивирует.

Итак, что есть в scrum:

  1. Планирование спринта. Как правило, мы планируем работу команды (и бюджет) на ближайшие 1-4 недели. После завершения каждого спринта заказчик получает полностью оттестированный и рабочий проект с приростом функциональности. Плюсы подхода: можно очень гибко корректировать бюджет на большой проект, прямо по ходу работ + заказчик получает результат быстрее, чем это было бы при обычной разработке.
  2. Ежедневные митинги (Daily Meeting).
  3. Демонстрация проекта заказчику.
  4. Ретроспектива.

Есть там и еще кое-какие артефакты, но эти, пожалуй, основные.

Сегодня у нас как раз стартует третий спринт проекта.

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

Как идет планирование:

1. Вся проектная команда (в данном случае — два разработчика и руководитель проекта) собирается в одном помещении, у одного компьютера. Тестировщика и дизайнера не зовем, так как проект слишком технический, однако задачи на дизайн выставляем сразу по ходу планирования. Замечу, что у нас нет отдельного scrum-мастера. В нашем случае эту роль совмещает менеджер проекта (Product Owner).

2. Далее мы все вместе читаем ТЗ, пункт за пунктом. Каждый пункт переносим в виде тикетов (карточек), на нашу доску задач, чертовски похожую на канбан. Мы используем JIRA с плагином GreenHoper.

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

4. Далее мы выставляем оценки, используя Planning Poker карты.

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

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

Практика показала, что очень важно закладывать буферы времени, так как команда делает оценки довольно оптимистично. Заставлять команду работать без буферов — самоубийство. Во-первых, сроки все равно будут сорваны, а во-вторых — команда чертовки устанет. Размер буферов устанавливается экспериментально, на основе предыдущих итераций по этому проекту и этой командой.

7. Для оперативного обсуждения проекта мы создаем специальную группу в Skype, в которой присутствуют только разработчики, менеджер проекта и тестировщик. В названии группы — записываем время стендапа (когда у нас будут проходить Daily Meeting, о котором чуть позже). Можно даже прикрепить аватарку с проектом в группу, или картинку с дедлайном — очено наглядно ;). Плюс в том, что информацию можно получать довольно оперативно, и нет необходимости выдергивать людей из потока.

Фаза планирования итерации занимает по-разному, но обычно это около 5% от спринта (то есть на планирование двухнедельной работы нужно закладывать 4 часа времени команды).

Daily Meetings как элемент Scrum’а

Итак, каждый день, ровно в 10:00 мы собираемся у одного и того же компьютера и обсуждаем наш прогресс по проекту. Это и называется Daily Meeting (он же Standup meeting или просто «митинг»).

В классическом скраме ежедневные митинги проводит специально обученный человек — cкрам-мастер (Scrum Master).

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

На ежедневном митинге скрам-мастер задает членам команды три вопроса:

  • Что было сделано за вчера?
  • Что будет сделано сегодня?
  • Какие были проблемы?

Каждый член команды отвечает на эти вопросы. Скрам-мастер следит за тем, чтобы не было дискуссий (но не подавляет их, а выносит на отдельные обсуждения, после Standup meeting). Продолжительность Standup meetings у нас — 5-9 минут.

Итак, отвечая на первый вопрос «Что было сделано за вчера», мне очень важно понять, какие изменения произошли в системе (что добавилось, на что могли повлиять изменения). Поэтому принять ответы типа «Я сделал задачи 32, 134, 372» я не могу, из них ничего не понятно. Нужно рассказывать именно про изменения в системе, а команда уже запросто обнаружит, какие проблемы это могло создать. (Хорошим ответом будет, например: «Вчера я удалил user_id из таблицы users, так как он не использовался в коде» — сразу понятно, кого бить и за что :)).

Второй вопрос требует, чтобы перед 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, Асхат Уразбаев, отмечает подобную тенденцию:

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

Очень часто последнее время наблюдаю такую картину:

Есть менеджер проекта — который вроде как формально Product Owner. В команде есть Scrum Master. В общем, все по науке. Только скрам-мастер выполняет свои функции номинально. А вот менеджер проекта действительно вкладывается в то, чтобы сделать команду эффективной. Он задает правильные вопросы на ретроспективе, его советы команде наиболее дельные, он решает все внешние зависимости и устраняет препятствия.

Самое интересно, что и Product Owner из него тоже в общем-то нетипичный. Он старательно дистанцируется от самостоятельного принятия решений. Чаще всего он старается собрать всех заказчиков в группу и проводит встречу, заказчики коллективно договариваются о приоритетах и требованиях. Как правило, он устанавливает некоторую каденцию общения (уж простите термин, не удержался) — например, назначает еженедельные встречи.

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

[Product Owner превращается в Scrum Master? by Асхат Уразбаев]

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

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

 

P.S. 17 марта состоится семинар по методологиям разработки программного обеспечения, где автор статьи будет рассказывать о проведении ретроспектив. Подробности о семинаре в социальных сетях: VK (vkontakte) и facebook.

Информация по семинару доступна также по хэштегу #RBDseminar в VK и twitter.


 
назад Сергей Белоусов в гостях у РБД Семинар «Методологии разработки ПО»: фотки! вперед
blog comments powered by Disqus