Scrum в интернет-агентстве/web-студии: взгляд изнутри

Я решил сделать небольшие репортажи, как у нас происходит работа по Scrum над проектами

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

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

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

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

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

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

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

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

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

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

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

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

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

[тут есть немного видео по хитрым способам оценки проектов, в том числе — про покер]

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

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

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

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

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

В следующий раз покажу, как у нас проходят Daily Meeting.