Софт за 30 дней. Как Scrum делает невозможное возможным

Рис. 6.4. Конечная базовая линия отражает бэклог продукта

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

The Standish Group оценила, что 50 % всех функций программного обеспечения очень редко или никогда не используются пользователями[4]. К примеру, 80 % пользователей применяют только 14 % функционала массивного сайта hp.com[5].

Таким образом, чтобы оптимизировать ценность, владелец продукта должен решить, когда остановить спринты, чтобы остановить дальнейшую разработку и не заполнять продукт функционалом с низкой ценностью. При использовании только этой тактики проекты могут занять лишь 40 % времени от того, что обычно затрачивается. Эта продуктивность остается за вами, просто нужно обращать внимание на ценность того, что вы разрабатываете.

Не игнорируйте сложности – всегда держите глаза открытыми

Мы знаем, что можем использовать Scrum для преодоления вызовов или для того, чтобы воспользоваться преимуществом появившейся возможности. Перед тем как начать первый спринт, мы часто хотим знать, как много времени займет проект и сколько он будет стоить. Мы можем получить начальную оценку, экстраполируя результаты первых нескольких спринтов. Например, мы разработали по 20 единиц функционала за два спринта и предполагаем, что система, как мы ее себе представляем, состоит из 220 единиц функционала. Нам остается создать еще 180 единиц. Со скоростью 20 единиц за спринт нам понадобится еще девять итераций. Если мы добавим или вычтем часть функционала во время разработки программного обеспечения, то разделим оставшуюся работу с учетом необходимого времени выпуска.

Конечно, нужно соблюдать крайнюю осторожность при экстраполяции фактов из прошлого для создания прогноза будущего. Экстраполяция – это процесс построения новых точек данных. Он похож на процесс интерполяции, при котором строятся новые точки между известными точками, но результаты экстраполяции менее значимы и подвержены большей неопределенности. Мы знаем, что разработка программного обеспечения – сложная задача. Мы можем экстраполировать, но должны постоянно проверять. В конце каждой итерации мы проверяем, где мы действительно находимся, а не где должны быть в соответствии с экстраполированными данными. Реальность – это более твердая основа, чем ожидания.

Проблема новых возможностей в том, что они новые. Пути их достижения, как правило, – либо создание чего-то нового, либо новое использование старого подхода. В любом случае всегда есть много новых вещей, которые нужно продумать, найти красивое решение, написать новое программное обеспечение либо перепрофилировать старое. Традиционно нас просят сначала обдумать, а потом уже начинать разработку. Это называется планирование требований, и результатом планирования становится документация продукта или документация маркетинговых требований. Проблема в том, что мы точно не знаем, чего хотим. Даже когда у нас есть четкие идеи, лучший подход обычно появляется во время разработки, потому что определение сложных проблем при планировании – задача трудная, чреватая ошибками и упущениями. С помощью Scrum мы планируем по мере продвижения, находя то, что нам нужно, в процессе работы над проектом. Предсказуемость появляется из своевременного принятия решений, основанных на реальных результатах. Хотя мы и планируем время и стоимость в начале проекта, но постоянно оцениваем его по мере продвижения вперед. В случае с традиционными проектами время и стоимость также прогнозируются в самом начале, но они не предоставляют эффективных данных для внесения изменений в планы до тех пор, пока как минимум 90 % работы не будет закончено.

Длина спринта

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

Рис. 6.5. Переменные, влияющие на длину спринта

Лучшая длина спринта для вашего проекта определяется после оценки следующего (рис. 6.5):

• перерасходы на короткие спринты;

• увеличение гибкости и контроля;

• длина спринта.

Спринт никогда не должен превышать один месяц.

Доводы в пользу более коротких спринтов

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