Про velocity команды, паровоз и ошибки

Скорость команды - штука, определенно, полезная. Но регулярные встречи (в рамках своей профессиональной деятельности) с различными антипаттернами использования данного инструмента подтолкнули на написание данного материала.

Итак.

Чтобы объяснить принцип работы velocity команды, расскажу вам одну историю из своего прошлого.

Будучи молодым и горячим, отправился я осваивать севера. Надо сказать, в ту пору таких как я были десятки, если не сотни. Силы и рвения хоть отбавляй, а вот опыта катастрофически не хватало.

Да еще и с пересменкой в тот год случилась какая-то накладка, вот и вышло, что почти все в нашей транспортной бригаде оказались молодыми да зелёными.

Но, собственно, к сути.

Был у нас локомотив, и поручение перевезти от места добычи до городской ТЭЦ 50 тысяч тонн угля. В пункте назначения вагоны нужно было разгрузить и вернуть на исходную точку, чтобы загрузить по-новой. Согласно утверждённому расписанию движения, отправка состава была запланирована раз в сутки.

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

Но нужно было собираться в первый рейс, и всей бригадой мы решили прицепить 35 вагонов.

Наполненный углем и оптимизмом, состав бодро отправился в пункт назначения, однако уже на ближайшей узловой станции руководство распорядилось прицепить еще 5 вагонов с оборудованием.

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

Возвращение состава с семью неразгруженными вагонами весьма озадачил всю бригаду. И на то были причины. Руководство требовало назвать сроки полного вывоза всего угля, чтобы учитывать данную информацию при составлении планов на следующий отчетный период. Но отправленный состав с 35 вагонами вернулся с 7 неразгружеными обратно.

Пока это не было похоже на предсказуемый результат.

Усложняло ситуацию и то, что руководство не могло дать однозначный ответ о том, будут ли добавлены дополнительные вагоны на узловой станции в следующем рейсе - оборудование на ТЭЦ ломалось вне какого-либо расписания.

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

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

Подвели промежуточный итог: с учётом вернувшихся неразгруженных вагонов, за первый рейс вывезли 28 вагонов, за второй - 27 (хотя исходно цепляли к локомотиву по 35 и 30 вагонов соответственно). Вывод напрашивался сам собой - примерно с этим количеством и отправлять состав.

Третий состав, ушедший с 27 вагонами, на узловой станции был неоднозначно воспринят представителями руководства. Кое-кому такой состав показался уж слишком коротким.

В этот раз, дополнительных вагонов к нашему составу прицепили всего 5 штук (как в первый рейс).

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

Четвёртый рейс отправлялся с тем же количеством вагонов - 27. Из-за прицепленных на узловой станции дополнительных 6 вагонов, один вернулся не разгруженным. Но по сравнению с прошлыми рейсами, это выглядело как сущие пустяки. После пятого и шестого рейсов было принято решение снизить количество исходных вагонов до 26 - именно это количество позволяло оптимальным образом сбалансировать разгрузку состава с учётом добавляемых вагонов на узловой станции.

После шестого рейса мы смогли назвать руководству дату планируемого завершения работ - нужно было еще 33 рейса (исходя из остатков угля и количества вывозимых вагонов за один рейс). Их это полностью устроило.

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

Конечно, всё описанное было метафорой.

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

Именно поэтому, правильное планирование выполняет сразу несколько задач.

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

На стратегическом - планирование с применением velocity позволяет иметь представление о том, сколько итераций потребуется для закрытия обозначенного объема задач (например, в рамках следующего релиза). И владение данной информации порой сильно сильно важнее прогноза на ближайшую итерацию.

Для определения скорости команды достаточно сделать всего две вещи: оценить задачи, и посчитать сумму оценок тех задач, которые были исходно запланированы, и закрыты в течение итерации (спринта). Закрытие задачи из незапланированно добавленных в расчёт не берём. И это очень важный аспект - скорость команды нужна не для того, чтобы оценить сколько команда сделала, а сколько она сможет сделать.

Несмотря на кажущуюся простоту вычислений, инструмент velocity сам по себе довольно капризен в плане исходный данных, на основании которых он рассчитывается.

И если для определения скорости команды достаточно сделать всего две вещи, то причин для искажения значений может быть несколько:

• Использование итераций разной длины. В таком случае, мы фактически собираем информацию с разных (непостоянных) данных. Погрешность стратегического планирования (на несколько итераций вперёд) напрямую зависит от чистоты собранных ранее данных;
• Изменение оценок задач во время итерации (спринта). Ошибаться при оценке - это нормально. Поэтому примите как данность - при большом количестве задач существующая погрешность будет компенсирована сама собой, т.к. ошибки совершаются в обе стороны (т.е. как переоценка, так и недооценка). И, как известно, лучшее враг хорошего - занимаясь переоценкой во время работы над задачей, команда, во-первых, тратит на это драгоценные ресурсы (пусть и небольшие), во-вторых, не добавляет прозрачности к будущему планированию;
  
• Отсутствие переоценки незавершенных задач. Порой задача переезжает в следующий спринт, и, очевидно, требует гораздо меньше ресурсов на закрытие, чем предполагалось изначально (ведь часть работ уже проведена). Но порой команды на планировании не меняют оценку на адекватную, и в момент закрытия задачи, в зачёт velocity идут затраченные ресурсы прошлого спринта (или даже нескольких спринтов). Очевидно, что в следующей итерации команда не будет располагать такими мощностями, чтобы закрыть аналогичный объём задач;
  
• Зачёт в velocity части незавершенных задач. «Да, мы не сделали эту задачу в 100 единиц. Но, кажется, мы сделали от неё примерно 70». Данный подход, возведённый в абсолют позволяет создать ситуацию, когда у команды замечательный velocity и ни одной закрытой задачи. Но, так как главной целью использования скорости команды является предсказуемость, сама предсказуемость в данном случае давно вышла из чата;
  
• Оценка только определенного типа задач. «Чёрная бухгалтерия», увы, встречается и в разработке. Однако, оценить на планировании две из трёх задач - всё равно, что не оценить ни одной. Команда опять получит «грязные» данные, которые не добавят прозрачности и предсказуемости.
  

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

Возможно, дочитав до этих строк, вы уже сами готовы были озвучить эту фразу. «У тебя там условные вагоны - явно стори-пойнты заморские имеешь ввиду, но у нас “майки” и “попугаи” отродясь не работали, про человеко-часы есть что-то новое?»

Что ж, не беда - механика и с часами работает абсолютно так же.

Правда, список ошибок расширяется еще на пару пунктов:

• Планирование времени под баги (срочные задачи и пр.). Просто излишняя активность. Помните историю про вагоны? Фокус бригады был в первую очередь на количество вагонов, которые гарантировано будут разгружены за рейс и не вернутся обратно на станцию. Понятие резерва в velocity просто не существует;
  
• Добавление к оценке еще +30% времени. Конечно, дополнительный «успокоительный буфер» может быть любого размера, но, опять же, не несёт практической пользы. По моим наблюдениям, в ста процентах случаев появление данной договоренности является одной из предпосылок к тому, чтобы команда перешла от абсолютных оценок к относительным. Ведь в этот момент становится понятно, что оценённая задача в 8 часов не будет сделана за восьмичасовой рабочий день, и вместо добавления часов к оценке, правильней было бы считать задачу оценённой в 8 условных единиц. А за сколько она будет сделана - покажет статистика.
  

Velocity - лишь один из множества инструментов, помогающих повысить прозрачность и предсказуемость в работе команды.

При этом, инструмент весьма непростой в освоении, недешёвый в обслуживании и тонкий в настройке. И в то же время, успешный навык использования velocity ставит команду на принципиально новый уровень развития и профессионализма.