Спринт ZERO: неочевидный, но необходимый

Аналитика рынка

Спринт ZERO: неочевидный, но необходимый

24 января, 2020

“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 назвать подготовкой шеф-повара к приготовлению очередного кулинарного шедевра – подбор рецепта, ингредиентов, подготовка необходимого кухонного оборудования – обязательная часть процессаПрекрасное блюдо может получиться и экспромтом, но потребует куда больше времени, сил и нервов. 

А что говорит руководство по Скраму? 

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

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

Три года назад у меня был проект по разработке приложения для колл-центра крупной зарубежной компании. Заказчик настаивал на классическом Скраметоропил и со сроками – ведь всем известно, что при Скраме реализация продукта происходит быстро и продуктивно. Согласно всем канонам, на первом спринте мы создали MVP и нарисовали архитектуру. Времени продумать ее, конечно же, не хватало, заказчик посчитал, что и так отлично и не хотел ничего слышать о выделении времени на ее проработкуведь его больше интересует функционал, нужно реализовать еще очень много и, желательно, вчера! Через шесть месяцев упорной и продуктивной работы мы столкнулись с реальными трудностями  система работала медленно, часть запланированных функций работали с ошибками и не так, как ожидалосьдругую часть было очень затруднительно реализовать, команда теряла мотивацию, спринты превратились в пытку для всех участников. А все потому, что наспех сделанная архитектура не отвечала требованиям продуктаВ итоге нам удалось убедить заказчика потратить дополнительное время (и деньги) на пересмотр архитектуры и переделку системы. Проект был сдан с опозданием на два месяцаклиенту это обошлось в дополнительные расходы, а отношения в команде и с заказчиком были на пике эмоциональной напряженности и раздражения. После такого опыта поневоле задумаешься о том, что Waterfall определенно предпочтительнее Agile. 

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

Руководство по Скраму, кстати, не запрещает проводить любые подготовительные работы, и назвать их можно как угодно, так почему бы не использовать термин «спринт 0», особенно, когда все люди в проекте понимают, что это, и зачем он нужен. 

Всегда ли нужен спринт 0? 

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

  • Архитектура приложения плохо описана, технические требования и/или риски оценены с большими допускамитребуется дополнительное исследование технологий; 
  • Первоначальное ядро команды требуется быстро расширить и ввести новых инженеров в курс проекта; 
  • Отсутствует проектное оборудование, не настроены средства CI/CD, не установлены программы для работы над проектом и т. д. 

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

Подводя итоги, спринт 0 можно рассматривать как концентрат предпроектной подготовки, который позволяет заказчику и подрядчику актуализировать бизнес требования, получить более четкое планирование проекта – сроковбюджетаобъема работ, а также минимизировать рискии, в целом, получить более качественный продукт. Не стоит вслепую следовать любой методологии, какой бы привлекательной она ни была. Каждый проект, продукт и заказчик по-своему индивидуален и, будучи таковым, требует индивидуального подхода.

Михаил Чкалов, менеджер проектов, Аурига

Похожие новости

Новости

Auriga вошла в список лучших IoT-компаний по версии Clutch

Auriga вошла в список лучших IoT-компаний по версии Clutch

Auriga, одна из ведущих компаний-разработчиков программного обеспечения на заказ, вошла в список лучших поставщиков IoT-решений по версии Clutch, независимой рейтинговой платформы для B2B-рынка. Рейтинг составлен

Auriga вошла в Топ-100 компаний-разработчиков ПО

Auriga была включена в рейтинг ста лучших в мире компаний-разработчиков программного обеспечения на заказ, опубликованный на бизнес-платформе The Manifest. Цель рейтинга – помочь заказчикам найти надежных партнеров...

Заказчик оценил проактивный подход Auriga в разработке ПО

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

Признанный лидер услуг по разработке ПО:
управление командами и проектами;
разработка новых продуктов, сопровождение, тестирование