from-waterfall-to-scrum-03

Я — менеджер проектов крупной ИТ-компании. Нас больше тысячи. В 2013 году наша команда запустила проект, целью которого явилась разработка пользовательского интерфейса создания и конфигурирования систем управления доступом в здания. Ядро системы было создано заказчиком. Наша проектная команда тогда состояла из двух фронт-енд разработчиков и менеджера проекта (меня). По необходимости мы также привлекали дизайнера и верстальщиков.

На первых порах требования как к системе в целом, так и к будущему интерфейсу, не были описаны аналитиками заказчика в полном объеме, что осложняло работу, при том, что мы работали по «водопаду». И тут первая неприятность: мы полностью зависели от сроков разработки и качества поставляемого API со стороны команды заказчика. К итогу первой фазы мы не достигли поставленных целей: из-за асинхронных действий двух команд (команды не видели общих целей и не чувствовали сплоченности) запланированный в рамках первой фазы функционал был готов не польностью, некоторые функции системы были реализованы не в полном объеме. Стало понятно, что дальше так нельзя, нужно было что-то менять и меняться самим.

На тот момент мы в компании уже давно использовали Agile-методологии: Scrum, Lean, Kanban. Вооружившись внутренними корпоративными наработками, мы сравнили процессы первой фазы с основными правилами и практиками гибкого подхода. Было решено работать по Scrum.

Начали с простого. Я пообщалась с продукт-менеджментом клиента, попросила детально приоритезировать требования и оставшиеся от первой фазы задачи. Из получившегося списка сформировали бэклог (product backlog): получили упорядоченный набор требований на целую фазу. Описание крупных фич я разбила на несколько юзер-стори (user story) (пользовательские истории — описание требований), которые согласовала с аналитиками клиента.

Scrum — это работа по итерациям не более одного месяца. Мы решили, что для нашего проекта идеальная длительность итерации — две недели. Краткосрочное планирование нашей работы  осуществлялось на срок «две недели и чуть-чуть дальше». В качестве отслеживающего инструмента мы использовали Jira Agile. Также у нас в кабинете была магнитная доска как фильтр задач. Если я хотела обратить внимание разработчиков на срочные (или важные для клиента) задачи, я пользовалась именно ей. Спринты объединялись в фазу. Одна фаза состояла из 10-20 спринтов (20-40 недель).

Мы решили, что планировать спринт, как и оценивать задачи, будет вся команда — разработчики, тестировщики, дизайнеры. Если следовать набору ролей в Scrum, в команде должен присутствовать выделенный Scrum-мастер. Но в реальности получилось так, что я, менеджер проекта, стала еще и Scrum-мастером, совместив эти роли.

Как же у нас происходило планирование спринта? Команда собиралась все вместе в большой переговорке. Я, как менеджер, презентовала объем работ, который, исходя из приоритетов продукт-менеджмента клиента, может быть реализован в данном спринте. Для того чтобы понять, «заходит ли» этот объем в спринт, мы его оценивали совместными усилиями. Для этого мы использовали метод покерного планирования (Poker Planning).

Каждая команда, использующая Poker Planning, по-своему трактует числовые значения карт: длительность (часы, дни) или относительные единицы сложности (story points). Мы оперировали story points, а именно сложностью реализации относительно эталонной задачи. Часто за одну story point принимают сложность реализации небольшой фичи, например, базовой формы авторизации (форма ввода логина и пароля) в приложении. Но так как story point — абстрактная величина, имеющая смысл только в рамках данного проекта, то и эталон (базовая задача в одной story point) для каждого проекта свой. Таким образом, для того, чтобы дать оценку задачи, необходимо определить, во сколько раз она сложнее базовой.

Далее нам необходимо было понять, сколько story points может поместиться в спринт. Обычно команды приходят к пониманию объема итерации методом проб и ошибок, на первых порах перебирая и недобирая задачи. Но зачастую к третьему-четвертому спринту планирование проходит эффективнее, а количество story points в них становится стабильным. Также мы определяли, сколько story points за один спринт может выполнить каждый разработчик, в зависимости от своего уровня (junior, middle, senior).

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

Для нашего проекта мы немного модифицировали классические подходы Scrum, так как изначально решили для себя, если правило мешает нам быть эффективными, мы от него отказываемся:

  1. Планирование – это первый день (понедельник) спринта, не более 2 часов.
  2. Daily standups + backlog grooming – ежедневные летучки, 20-30 минут.

Помимо обмена статусами работ (что делал, что собираюсь делать, какие трудности) мы добавляем причесывание бэклога задач последующих спринтов и/или разбор и назначение ответственных за исправление багов текущего спринта из перечня нераспределенных на доске задач. Основной упор чаще всего делается на груминг и «раскидывание» багов высокого приоритета на разработчиков (в том числе бэк-енд команды клиента) в рамках текущего спринта. Мы делаем это в первую очередь для того, чтобы оперативно исправлять критические ошибки, а также, чтобы избежать застоя пула «бесхозных» багов. В зависимости от активности QA и фазы спринта, речь может идти о 10-30 задачах ежедневно. Для того чтобы ускорить процесс планирования и не отвлекаться на болтовню, полезной практикой является проведение груминга бэклога будущих спринтов. Для этого я разрабатывала предварительный план на два-три спринта вперед. Когда освобождалось время на daily standups, команда оценивала две-три истории или задачи «про запас».

  1. Dev meeting – митинг разработчиков каждый второй понедельник спринта, не более одного часа. Цель – обсуждение технических особенностей реализуемого функционала. При необходимости привлекается менеджер и QA специалист. Например, когда мы разрабатывали стратегию автоматизированного тестирования (написание и поддержка e2e-кейсов, их автоматизация и прохождение всех стадий жизни кейса от написания до ревью и закрытия), привлекали всю команду.
  1. Demo/Retro спринта – последний день спринта, не более двух с половиной часов. Спринт закрывается демонстрацией реализованного функционала и обсуждением результатов прошедшего спринта (ретроспектива). Основная задача демо – повысить личную ответственность каждого разработчика за свою работу. Демонстрация делается на всю команду, 11 человек, что накладывает определенные обязательства за качество.

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

Сформулировать цель спринта не всегда просто. Она должна отражать потребности бизнеса, а не техническую задачу. Какие цели, к примеру, ставили перед собой мы: «подготовить версию для демонстрации на мероприятии», «отдать билд на тестирование QA-команде клиента», «устранить проблему немецкой локализации». Но это вовсе не означает, что в рамках спринта мы не стремимся закрывать все запланированные пользовательские истории и задачи. Наш definition of done (критерий готовности) для функциональной задачи (истории) был таким:

  • Готовый (оттестированный и стабилизированный) функционал;
  • Отсутствие багов высокого приоритета (major, critical, blocker);
  • Написанные unit-тесты (если требуется);
  • Написанная документация кода (если требуется);
  • Успешно пройденный code review (инспекция кода).

После закрытия каждого спринта QA-команда собирала статистику и оформляла ее в отчет (sprint report). Кроме количества и статуса багов и задач, нам был интересен процент регрессии, если проводился Acceptance Test – это наиболее слабые места приложения (в том числе API), тенденции качества. То есть это любая информация, которая поможет сделать выводы относительно нашей работы в спринте. Отчет рассылался на всю команду.

На основе sprint report я составляла отчет для команды клиента. Вся информация была им не нужна, лишь наиболее репрезентативные данные. Также в него входил план следующего спринта. Каждые две недели у нас проходит скайп-конференция «большой семерки»: я, наш тимлид и стейкхолдеры со стороны клиента (топ-менеджмент и техлиды). Мы обсуждали результаты прошедшего спринта (показывали статистику и демонстрировали ключевой функционал), а так же планы на следующий спринт.

Сегодня проект более чем успешен: первая версия web-приложения анонсирована на специализированной выставке в Лондоне в 2015, с тех пор мы выпустили несколько новых релизов. Система успешно внедрена и используется рядом крупных клиентов (более 200 устройств у каждого) в Великобритании и США.

Резюмируя, скажу, в Scrum важно чувствовать себя командой. На мой взгляд, это помогает сплотить даже самый интровертно-индивидуалистский коллектив. Будучи приверженцем методов положительной мотивации, я вместе с командой радуюсь хорошим результатам, передаю слова благодарности клиента, организовываю тим-билдинги. К нам часто приезжают представители команды заказчика, поэтому каждый день после работы мы все вместе выбираемся куда-нибудь на ужин. Решение нетривиальных задач совместными усилиями, да и, в принципе, любые совместные активности сближают.  «На работу как на праздник»? – да, почему бы и нет.  И каждый новый успешный этап проекта – уже маленькая радость. Если люди занимаются работой, которую они любят, это конструктивно сказывается на их продуктивности. Так же как и использование правильных инструментов, таких как Scrum, в чем мы убедились на практике.