SCRUM на Media проекте

Сегодня расскажу про одну из версий реализации SCRUM, в котором посчастливилось принять участие. Особенность в том, что сколько проектов столько и SCRUMoв и каждый не похож на другого, впрочем как и нет 2х одинаковых проектов. Текущий свой процесс мы выращиваем уже 2 года, постоянно что-то изменяя или адаптируясь ко внешним изменениям.

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

Начнём по порядку…

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

Планирование спринта

До сих пор остаётся непростой задачей. Изначально перед началом спринта проводили «Estimation meeting» командами разработчиков и тестировщиков (~20 человек), как положительный момент позволяло рассмотреть задачу с разных сторон. Однако не удавалось за 1 день дать оценку всем задачам, для многих из них появлялись вопросы, варианты реализации требовали время на обдумывание. Соответственно, из-за появившихся новых вопросов дать оценку всем задачам за день не получалось. Команда у нас распределённая, продакт-менеджер находится в Нью-Йорке, и из-за своей перегруженности не всегда может оперативно отвечать.

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

Sprint

В начале(2 года назад) разработчики и тестировщики были независимые команды, и общение велось достаточно формально посредством JIRA задач, что не ускоряло решение вопросов и поставку задач.

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

В то время всплыли проблемы:

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

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

Что изменили:

  1. Выделили отдельную среду (environment) для ежедневные билдов. На которую же и пересадили нашу группу QA. Теперь новая функциональность поступает в QA ежедневно. Сразу после этого запускаются UI тесты, которые проверяют основную функциональность. Делается это все в 6 утра. И к радости всех кто пришёл на работу на CC.NET dashboard можно увидеть как себя чувствует проект сегодня о-баг-отившись новой функциональностью.
  2. Ввели практику демонстрации задачи разработчиком для QA после ее завершения. Что позволяет обнаруживать проблемы уже на этом этапе.
  3. Когда пришли к тому, что разрабочики и тестировшики должны работать совместно, встала проблема синхронизации их времени. Не для кого не секрет, что увлечённый программист любит посидеть попозже и поспать подольше. А тестировщик спешит в самую рань обрадовать программиста к его приходу свежими багами на вчерашнюю фичу. Пришлось ввести штрафы за опоздания на утренний standup митинг. Мера неоднозначная, но похоже работает.
  4. Появился скрамбол это такой мячик который помогает проводит стэндап митинги. Без него были неловкие паузы, не понятно когда закончил говорить один оратор, и должен продолжать следующий. Все еще остаются проблемы с чётким / коротким описанием чем-кто занимается. Боремся с не информативными сообщениями типа «Вчера исправлял баги», «Сегодня буду делать задачи спринта»

Демо

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

Метрики

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

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

Прогресс

Для управления задачами используется JIRA. Пробовали использовать kanban board (реальную пробковую доску), для отслеживания прогресса задач, и возле нее проводили stand-ups. Наигравшись она была заброшена. И все ушли в виртуальность, похоже JIRA все-же наиболее удобный инструмент.

Релизы

Так как продукт уже несколько лет активно используется, одним из требований является 100% время доступности. Так что, выпуск продукта представляет собой отдельную сложную процедуру.

Хотя на сегодняшний день все возможные операции автоматизированы, выпуском занимается билд-мастер, и за «полётом» следит QA.

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

Так у нас появился «дежурный по билдам» — разработчик сопровождающий билд. Который оперативно реагирует на проблемы и занимается организацией их решения. Так же в его обязанности вменили анализ логов, поиск top 3 популярных ошибок и их исправление.

Выводы на сегодня

По моему нескромному мнению:

Чтобы делать успешный проект необходимо чётко определять процесс (будь то SCRUM или что-то другое) и следовать ему. И этот процесс сам на проекте не появится.

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

SCRUM не дает инструментов для долгосрочного планирования, в лучшем случае горизонт 1-2 спринта. Межпроектные и межкомандные зависимости теряются. Нужны дополнительные инструменты.

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

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

А у вас есть какие-то особенности организации работы по SCRUM?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *