Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Современные парадигмы разработки ПО всегда являются итерационными. В методологии Scrum такими итерациями являются спринты, в классической версии Scrum каждый спринт начинается с планирования и завершается демо, ретроспективой и «инженерным» днем. Оценка успешности каждого спринта – это довольно субъективная вещь, формализация которой важна и может быть реализована с помощью следующих стандартных действий:
Определить достижение целей спринта;
Оценить краткосрочное влияние разработки ПО на удовлетворённость заказчиков и пользователей в развитии продуктов;
Провести формализацию и учет параметров спринтов.
Определять для каждого спринта собственные цели несложно: необходимо сопрягать довольно точно измеряемые и формулируемые сущности:
Бизнес-цели разрабатываемых продуктов;
Приоритет функциональных и нефункциональных требований в беклогах различного уровня;
Логическую очередность этапов развития софтверных проектов.
Идеальная формулировка целей спринта должна быть в формате SMART, где буква «M» означает Measurable – т.е. измеримость цели. Такая измеримость довольно часто выражена в цифрах, а удачной формулировкой цели спринта может быть следующая: «Достигнуть максимального времени завершения каждой транзакции в системе для пользователей в любой роли менее 1 секунды вне зависимости от времени суток». Данная цель вполне конкретна, уместна и измерима, а срок ее достижения понятен – продолжительность спринта. Обычно спринт имеет 1-2 основные цели, если, конечно, речь не идет о разработке сложных экосистем в форматах Scrum of Scrum и Scaled Agile Framework.
Оценка краткосрочного влияния разработки ПО на удовлетворённость бизнес-заказчиков и пользователей тоже определить довольно легко: от субъективных оценок Product Manager до пользовательских фокус-групп и бета-тестирований. В данном случае краткосрочного такого влияния компенсирует математическую неточность методов оценки удовлетворенности пользователей и бизнес-заказчиков. Основное правило одно: постоянно собирать формализованную обратную связь на всех уровнях и анализировать ее в разрезе производственных проблем, выявляемых в спринте и подробно обсуждаемых на ретроспективах.
Самым сложным и обладающим наибольшим потенциалом в повышении успешности спринтов в разработке по Scrum является формализация параметров этих спринтов и планомерная работа по их улучшению. В основе такой формализации лежат ключевые причины, почему scrum вообще был внедрен в организации. Отбрасывая комичные причины внедрения Scrum вроде «а мы только так и умеем» и «модно, стильно, молодежно», следует рассмотреть наиболее типичные в российской практике:
Необходимо ускорить и формализовать разработку;
Необходимо приспособиться к быстро меняющимся требованиям и к реалиям бизнеса (классический случай для развития стартапов и всяких форексов);
Наши бизнес-заказчики, пользователи и разработчики должны стать ближе друг к другу (и использовать полученный синергетический эффект в развитии бизнеса).
Очевидно, что формализация параметров спринта в каждом случае довольна специфична и тесно связана с параметрами, обуславливающими эти причины: скорость поставки задач, историй, эпиков в продуктивную среду, актуальность создаваемого функционала, широкие возможности кросс-функциональности сотрудников и скорость управления рисками своевременных изменений в продуктах, включая реакцию на форс-мажорные ситуации.
В данной статье предложено сгруппировать такие формализованные параметры спринтов и рекомендовать их применения сразу целыми группами в соответствии с бизнес-потребностями софтверной компании и причинами внедрения Scrum. При этом, безусловного уважения заслуживает не «слепое» следование данной рекомендации, а их «гибкая адаптация» в духе ценностей Agile в каждой команде.
№ | Причина \ бизнес-потребность | Параметры в данной группе |
1 | Ускорение и формализация разработки | 1) Отклонения реального списания поинтов от «идеальной траектории» на диаграмме сгорания в ключевых точках спринта; 2) Вектор ускорения работы каждой команды (при стабильности ее состава) в списанных поинтах или завершенных историях; 3) Вектор роста капасити команды на стадии планирования (при стабильности ее состава) в поинтах или историях; 4) Вектор исчезновения историй и тасков, которые были внесены в спринт, но не реализованы в силу слабой формализации и неясности требований; |
2 | Быстрое приспособление к меняющимся требованиям | 1) Вектор исчезновения историй и тасков, которые были внесены в спринт, но не реализованы в силу потери актуальности; 2) Количество тасков с наивысшим приоритетом, реализованных в спринте при общем сохранении принципа Парето в расстановке приоритетов; 3) Постоянный баланс между количеством тасков и историй по трем категориям: А) «срочных» с высоких приоритетом, Б) технических и инфраструктурных (включая QA и CI\CD), В) выводимых в продуктивную среду на срок более полугода; |
3 | Сближение заказчиков, пользователей, разработчиков в развитии бизнеса компании | 1) Вектор роста количества продуктовых гипотез, прошедших все стадии разработки и находящихся в промышленной эксплуатации; 2) Вектор исчезновения историй и тасков, которые были удалены из промышленной эксплуатации из-за негативного фидбека пользователей; 3) Рост капасити команды в поинтах и тасках; 4) Постоянный баланс между количеством тасков и историй по трем категориям: А) «срочных» с высоких приоритетом, Б) технических и инфраструктурных (включая QA и CI\CD), В) выводимых в продуктивную среду на срок более полугода; |
Рассмотрим некоторые примеры из практики консультантов SSC, иллюстрирующие применение формализованных параметров спринтов в разработки ПО и их влияние на бизнес-параметры в развитии софтверных продуктов. Один из самых редких, но потенциально эффективных параметров спринта – это максимальные отклонения реального списания поинтов от «идеальной» диаграммы сгорания. Конечно, следует сразу условиться: полное следование «идеальной» траектории – это вредная утопия, отказ от следования ей – низкий уровень управленческой зрелости команды разработки. Важным является учет и анализ причин максимальных отклонений в ключевых точках. Так, например, в проекте внедрения Scrum методологии в российско-китайской IT-компании в 2018 году в практике одного из консультантов SSC такие отклонения считались по 7 спринтам в двух ключевых точках: по завершению каждого спринта и в середине его календарного срока. Отклонения считались в процентах (составили от 2 до 43%) и позволили сделать бесценные выводы как о скорости внедрения Scrum, так и о потенциале команд и оптимальной скорости разработки. Именно анализ данного параметра позволил сформировать индивидуальные капасити команд и тим лидов, скорректировать этап планирования тасков, внести эффективные изменения в процесс стабилизации качества функционала, вводимого в эксплуатацию.
Другой пример эффективного использования параметров в спринте описывается из практики испанской софтверной компании SlavaSoft. На протяжении трех лет развития мобильного продукта для профессионалов настольного тенниса в парадигме разработки Scrum отслеживались и анализировались все параметры из третьей группы приведенной выше таблицы:
Рост закрепленных в промышленной эксплуатации продуктовых гипотез приблизился к 90%;
Были практически искоренены обратные откаты в функциональности из-за негативного фидбека конечных пользователей – тренеров и профессиональных игроков в настольный теннис;
В течение первого года наблюдался значительный рост капасити команды;
Определенный баланс по типу реализуемых в спринтах тасок сохранялся, не позволяя наращивать технический долг.
Бизнес-заказчики данного мобильного продукта отмечали высокий уровень сближения команды разработки с конечными пользователями, что безусловно шло на пользу развитию продукта и бизнеса SlavaSoft.
Таким образом, потенциал формализованных параметров спринтов реален, а анализ и управление такими параметрами являются практическим инструментом повышения качества разработки ПО и достижения поставленных целей. Безусловно, внедрение таких параметров – это процесс, требующий профессиональных навыков, внимания к деталям и адаптации к конкретным командам и их задачам. Вместе с этим опыт консалтинговой компании SSC показывает, что получаемые преимущества для команд разработки ПО с легкостью окупают все затраченное время и усилия.
