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

• Определить достижение целей спринта;

• Оценить краткосрочное влияние разработки ПО на удовлетворённость заказчиков и пользователей в развитии продуктов;

• Провести формализацию и учет параметров спринтов.

Определять для каждого спринта собственные цели несложно: необходимо сопрягать довольно точно измеряемые и формулируемые сущности:

1. Бизнес-цели разрабатываемых продуктов;

2. Приоритет функциональных и нефункциональных требований в беклогах различного уровня;

3. Логическую очередность этапов развития софтверных проектов.

Идеальная формулировка целей спринта должна быть в формате SMART, где буква «M» означает Measurable – т.е. измеримость цели. Такая измеримость довольно часто выражена в цифрах, а удачной формулировкой цели спринта может быть следующая: «Достигнуть максимального времени завершения каждой транзакции в системе для пользователей в любой роли менее 1 секунды вне зависимости от времени суток». Данная цель вполне конкретна, уместна и измерима, а срок ее достижения понятен – продолжительность спринта. Обычно спринт имеет 1-2 основные цели, если, конечно, речь не идет о разработке сложных экосистем в форматах Scrum of Scrum и Scaled Agile Framework.

Оценка краткосрочного влияния разработки ПО на удовлетворённость бизнес-заказчиков и пользователей тоже определить довольно легко: от субъективных оценок Product Manager до пользовательских фокус-групп и бета-тестирований. В данном случае краткосрочного такого влияния компенсирует математическую неточность методов оценки удовлетворенности пользователей и бизнес-заказчиков. Основное правило одно: постоянно собирать формализованную обратную связь на всех уровнях и анализировать ее в разрезе производственных проблем, выявляемых в спринте и подробно обсуждаемых на ретроспективах.

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

1. Необходимо ускорить и формализовать разработку;

2. Необходимо приспособиться к быстро меняющимся требованиям и к реалиям бизнеса (классический случай для развития стартапов и всяких форексов);

3. Наши бизнес-заказчики, пользователи и разработчики должны стать ближе друг к другу (и использовать полученный синергетический эффект в развитии бизнеса).

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

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

Рассмотрим некоторые примеры из практики консультантов SSC, иллюстрирующие применение формализованных параметров спринтов в разработки ПО и их влияние на бизнес-параметры в развитии софтверных продуктов.  Один из самых редких, но потенциально эффективных параметров спринта – это максимальные отклонения реального списания поинтов от «идеальной» диаграммы сгорания. Конечно, следует сразу условиться: полное следование «идеальной» траектории – это вредная утопия, отказ от следования ей – низкий уровень управленческой зрелости команды разработки. Важным является учет и анализ причин максимальных отклонений в ключевых точках. Так, например, в проекте внедрения Scrum методологии в российско-китайской IT-компании в 2018 году в практике одного из консультантов SSC такие отклонения считались по 7 спринтам в двух ключевых точках: по завершению каждого спринта и в середине его календарного срока. Отклонения считались в процентах (составили от 2 до 43%) и позволили сделать бесценные выводы как о скорости внедрения Scrum, так и о потенциале команд и оптимальной скорости разработки. Именно анализ данного параметра позволил сформировать индивидуальные капасити команд и тим лидов, скорректировать этап планирования тасков, внести эффективные изменения в процесс стабилизации качества функционала, вводимого в эксплуатацию.

Другой пример эффективного использования параметров в спринте описывается из практики испанской софтверной компании SlavaSoft. На протяжении трех лет развития мобильного продукта для профессионалов настольного тенниса в парадигме разработки Scrum отслеживались и анализировались все параметры из третьей группы приведенной выше таблицы:

• Рост закрепленных в промышленной эксплуатации продуктовых гипотез приблизился к 90%;

• Были практически искоренены обратные откаты в функциональности из-за негативного фидбека конечных пользователей – тренеров и профессиональных игроков в настольный теннис;

• В течение первого года наблюдался значительный рост капасити команды;

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

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

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