Поэтому правильный подход – учитывать такую статистику на планировании и ранжировать задачи по желательности их исполнения. Для этого можно применять шкалу MoSCoW (Must – Should – Could – Would) или ее сокращенный вариант, и не ставить максимальное значение достаточному количеству задач. Кроме того, учитывая статистику, необходимо не заполнять весь бэклог крупными задачами, в нем должен быть достаточный буфер мелких задач. Конечно, планирование спринта обычно не является заключением какого-то принципиально нового контракта, речь обычно идет лишь о целях и объеме работ на спринт. Однако, в общем случае, стейкхолдерами проекта после любого спринта может быть принято решение о прекращении проекта.
Ценность и содержание работ.
Так же хочу еще раз обратить внимание на то, что выполнение состава работ, которым наполнена задача, вовсе не означает, что ценность получена. Начинали наполнение бэклога мы именно с ценности, которую выполнение задачи должно принести пользователям, клиентам или потребителям. Ценность – это решенная проблема или предоставленная возможность. По мере проработки бэклога мы придумали способ получить ценность, сначала – принципиальный, потом – детальный, потом реализовали это. Но при этом наш придуманный способ остается гипотезой, и требует экспериментальной проверки реальным потребителем. И может оказаться, что требуются какие-то дополнительные работы.
Мы думали, что пользователи смогут, увидев названия документов в результате поиска по базе, выбрать наиболее подходящий, а выяснилось, что для очень много запросов выдает совершенно однотипные списки названий, начинающихся с «Письмо Минфина от DD.MM.YY разъяснением по практике применения…», и выбрать совершенно невозможно. Мы думали, что пользователь сформирует список из 10—20 любимых песен для запуска по циклу в фоне, а оказалось, что у многих есть несколько списков для разных настроений, и любимое произведение в одном состоянии превращается нестерпимым в другом. Мы сделали специальную форму для оформления заказов с доставкой со склада на тренажеры прямо из магазинов, а оказалось, что сотрудники магазинов по-прежнему звонят в офис и резервируют товар по телефону, а только потом заполняют форму. Потому что боятся, что пока они будут оформлять заказ и подробности доставки, тот единственный тренажер уйдет по другому назначению, и не хотят, чтобы покупатель почувствовал тоже самое, что чувствуют многие из вас, когда после заполнения сведений о пассажирах при покупке билетов получают сообщение, что билеты уже проданы или подорожали…
То есть уже после реализации оказывается, что создание ценности требует дополнительных объемов работ. И на это тоже надо закладывать резервы при планировании. Но если у вас задачи похожие, то статистика позволит оценить качество, с которым команда превращает ценность в содержание работ, и требуемый размер буфера.
Отметим, что важно закладывать общий буфер, а не резерв на каждую задачу: дело в том, что имея по задаче оценку с резервом, разработчики всегда испытывают искушение повысить качество реализации, если они сделали задачу быстрее оценки. А если задача оказалось сложной – то превышают оценку. По этой же причине, кстати, детальные оценки на планировании спринта в человеко-часах хуже оценки в размерах или условных единицах.