«The heart of Scrum is a Sprint, a time-box of one month or less during which a ‘Done’, useable, and potentially releasable product Increment is created».
«Спринт служит ядром скрама. Спринт — временной отрезок длительностью месяц или меньше, в течение которого создается «готовый», то есть пригодный к использованию и выпуску инкремент продукта».
«Исчерпывающее руководство по Скраму: Правила Игры» Кен Швабер и Джефф Сазерленд
Старт любого проекта, начинается с решения ряда стратегических вопросов – как будут построены коммуникации, как будет осуществляться управление проектом и рисками, в какие сроки будут реализовываться разные фазы проекта. И на все эти задачи существенное влияние оказывает наличие/отсутствие четко прописанных технических требований и проектной документации. Недостаток деталей в техзадании или неупорядоченная и недостаточно подробная документация, очевидно, приводят к тому, что затрудняется оценка трудозатрат, составление плана проекта, увеличивается время, затрачиваемое на коммуникации с заказчиком и инженерами в команде.
Задача провайдера услуг по разработке программного обеспечения сократить эти издержки для заказчика, наиболее эффективно организовать работу на проекте и снизить излишнюю вовлеченность клиента в проект. Наиболее частая проблема, с которой мы сталкиваемся: техническое задание обычно описывает только бизнес требования и мало говорит о том, как они должны быть реализованы, коммерческое предложение содержит мало технической информации и не учитывает все факторы, а архитектура плохо продумана и нуждается в доработке. Выглядит не очень радужно, но у нас есть решение, опробованное на многих заказчиках и отточенное на множестве различных проектов.
Спринт 0 – что это
Итак, в качестве решения вышеперечисленных проблем мы используем особый спринт, который назвали спринт 0, цель которого:
- сформировать ядро команды, распределить роли, организовать поездку ключевого инженера к клиенту для изучения продукта и требований на месте (потом он поделится полученной информацией с остальной командой и облегчит их ввод в проект);
- описать архитектуру и дизайн приложения (HLA и HLD), описать технические требования в деталях;
- сделать верхнеуровневые оценки основных компонентов системы, сформировать беклог продукта;
- развернуть CI/CD, подготовить оборудование, более четко определить требуемый стек технологий, подобрать «железо», установить программное обеспечение для работы над проектом и закупить необходимые лицензии.
Иными словами, спринт 0 назвать подготовкой шеф-повара к приготовлению очередного кулинарного шедевра – подбор рецепта, ингредиентов, подготовка необходимого кухонного оборудования — обязательная часть процесса. Прекрасное блюдо может получиться и экспромтом, но потребует куда больше времени, сил и нервов.
А что говорит руководство по Скраму?
Спринт 0 — это время, которое тратится на подготовку команды к работе над проектом. В нашей практике обычно это занимает около двух недель (в зависимости от сложности проекта, требований заказчика и некоторых других факторов). Согласно классическому определению спринта в Скраме — это токсичный спринт, который происходит от непонимания основ методологии и должен быть отброшен, так как не добавляет реальной ценности продукту. Все перечисленные процедуры должны быть сделаны во время планирования спринта.
Теория прекрасно объясняет, что и как должно быть, но что же мы имеем на практике? Приведу примеры из своего опыта.
Три года назад у меня был проект по разработке приложения для колл-центра крупной зарубежной компании. Заказчик настаивал на классическом Скраме, торопил и со сроками – ведь всем известно, что при Скраме реализация продукта происходит быстро и продуктивно. Согласно всем канонам, на первом спринте мы создали MVP и нарисовали архитектуру. Времени продумать ее, конечно же, не хватало, заказчик посчитал, что и так отлично и не хотел ничего слышать о выделении времени на ее проработку, ведь его больше интересует функционал, нужно реализовать еще очень много и, желательно, вчера! Через шесть месяцев упорной и продуктивной работы мы столкнулись с реальными трудностями – система работала медленно, часть запланированных функций работали с ошибками и не так, как ожидалось, другую часть было очень затруднительно реализовать, команда теряла мотивацию, спринты превратились в пытку для всех участников. А все потому, что наспех сделанная архитектура не отвечала требованиям продукта. В итоге нам удалось убедить заказчика потратить дополнительное время (и деньги) на пересмотр архитектуры и переделку системы. Проект был сдан с опозданием на два месяца, клиенту это обошлось в дополнительные расходы, а отношения в команде и с заказчиком были на пике эмоциональной напряженности и раздражения. После такого опыта поневоле задумаешься о том, что Waterfall определенно предпочтительнее Agile.
И другой пример, проект 2019 года по созданию симулятора медицинского прибора. Мы потратили две недели, чтобы команда разобралась, что в итоге нужно сделать, описала архитектуру и настроила все необходимое окружение. В результате получили план действий на полгода вперед, который, конечно, менялся на протяжении этого срока, но это было предсказуемо и понятно. Проект был сдан в срок с ожидаемым качеством. Заказчик остался полностью довольным организацией процесса и продолжает сотрудничество с Ауригой на других проектах.
Руководство по Скраму, кстати, не запрещает проводить любые подготовительные работы, и назвать их можно как угодно, так почему бы не использовать термин «спринт 0», особенно, когда все люди в проекте понимают, что это, и зачем он нужен.
Всегда ли нужен спринт 0?
Конечно, в моей практике, есть успешные проекты и без спринта 0. Получается, что можно работать и без него. Я постараюсь выделить признаки того, когда он точно необходим:
- Архитектура приложения плохо описана, технические требования и/или риски оценены с большими допусками, требуется дополнительное исследование технологий;
- Первоначальное ядро команды требуется быстро расширить и ввести новых инженеров в курс проекта;
- Отсутствует проектное оборудование, не настроены средства CI/CD, не установлены программы для работы над проектом и т. д.
Последний пункт менее критичен, чем два первых, но тоже по-своему очень важен, так как без этого невозможно заниматься работой непосредственно над проектом и приходится отвлекаться на сторонние задачи.
Подводя итоги, спринт 0 можно рассматривать как концентрат предпроектной подготовки, который позволяет заказчику и подрядчику актуализировать бизнес требования, получить более четкое планирование проекта – сроков, бюджета, объема работ, а также минимизировать риски, и, в целом, получить более качественный продукт. Не стоит вслепую следовать любой методологии, какой бы привлекательной она ни была. Каждый проект, продукт и заказчик по-своему индивидуален и, будучи таковым, требует индивидуального подхода.
