Это перевод статьи How to Make Reliable Probabilistic Forecasts Without Sizing Your Stories Into Even Pieces Сони Сидеровой.
От переводчика:
Соня Сидерова — увлечённая менеджер продукта и движущая сила Nave, аналитического инструмента для процессов, который работает с многими популярными системами учёта задач и помогает командам повысить скорость доставки благодаря принятию решений на основе данных. Её блог — это отличный источник знаний о Канбан методе, и я хочу сделать этот кладезь доступнее для русскоязычного сообщества. Это первый из запланированных переводов из блога.
Когда я рассказываю командам что можно давать прогнозы на основании данных о том как они поставляли свои задачи в прошлом, я очень часто слышу возражение, мол «Наши задачи слишком разные, у нас это не будет работать». Если команда сохраняет в задачах их размер в том или ином виде, можно показать статистику по разным размерам и наглядно показать, насколько его влияние несущественно. Если же такой информации не сохранилось, приходится ссылаться на чужой опыт и пускаться в пространные объяснения. И всё равно зачастую сомнения остаются.
Эта статья детально объясняет, почему размер задач не имеет значения. Возможно, кому-то она поможет развеять собственные сомнения или преодолеть сопротивление команды.
Разбивка историй на равные части — широко распространённая активность, которая часто считается необходимым условием для предоставления достоверных прогнозов на будущее. Концепция искусственного разделения рабочих элементов на равные части для получения точного прогноза поставок не имеет под собой оснований. На самом деле, изменение размера ваших историй не только совершенно не имеет отношения к прогнозированию, но и может оказать негативное влияние на цели, которые вы пытаетесь достичь.
Почему искусственно выравнивать истории по размеру — не самая лучшая идея
Давайте рассмотрим основные причины, почему не стоит пытаться разбивать ваши рабочие элементы на равные части.
Важность составления пользовательских историй, определяющих ценность для клиента
Каждая история должна представлять кусочек ценности для клиента. Естественным образом эти элементы будут разного размера и разной сложности. Искусственно обрезая пользовательские истории, мы теряем ключевую концепцию ценности, лежащую в их основе. Мера ценности замещается мерой времени. Потребительская ценность делится на временные единицы и, таким образом, становится бессмысленной для клиента.
Неестественное нарезание истории приводит к появлению ненужных зависимостей
Разбиение историй на равные части создает излишние зависимости и добавляет ненужную сложность. Если вы разбиваете единицы ценности на неестественные сегменты, между этими сегментами неизбежно возникнут зависимости.
Зависимости приводят к узким местам в рабочем процессе. Чем больше зависимостей вы внесете, тем сложнее будет эффективно управлять процессом.
Каждая история должна быть потенциально готова к поставке
Каждая разработанная пользовательская история должна порождать пригодные для поставки продуктовые инкременты.
Если нарезать ваши истории равными частями, они перестанут быть потенциально выпускаемыми и, следовательно, не смогут быть доставлены заказчику, если это потребуется.
Деление историй на части имеет смысл только тогда, когда мы делаем это с клиентской перспективы
Когда речь идет о дроблении ваших рабочих элементов на более мелкие части, эта цель всегда должна восприниматься с перспективы клиента, и в конечном итоге новые выпускаемые инкременты не будут получаться одинакового размера.
Должен быть четкий, разумный замысел, оправдывающий то, что вы берете большую пользовательскую историю и разбиваете ее объем на несколько частей, пригодных для выпуска. Если ваша пользовательская история не имеет смысла с точки зрения клиента и не дает четкого представления о цели, которую она должна достичь, вам лучше даже не начинать реализовывать ее. Она будет только нагромождаться на остальную незавершенную работу и застревать в рабочем процессе. Вместо этого потратьте время на тщательный анализ и извлеките из неё потенциально пригодную для поставки клиенту часть.
Самый эффективный подход, который вы можете использовать, это сокращение дистанции между вашими клиентами и вашей командой разработки. Вы должны работать совместно с вашим клиентом, чтобы четко определить, что и почему вы собираетесь реализовывать, и каждый в вашей команде должен понимать эти факторы. Это задача команды — решить, как именно это сделать. Используйте экспертизу и опыт каждого члена команды, чтобы провести мозговой штурм и придумать наиболее подходящий вариант решения проблемы вашего клиента.
Таким образом, вы все еще можете определить ваши новые истории с точки зрения ценности, и элементы все еще потенциально могут быть поставлены, без искусственного добавления зависимостей в вашу систему.
Разница между временем затраченных усилий и временем выполнения
Вам, вероятно, интересно, как можно делать прогнозы на будущее, не нарезая свои истории на элементы одного размера. Ответ прост — составление точных прогнозов доставки не имеет никакого отношения к размеру элементов.
Давайте вместе разберемся с математической задачей. Время выполнения вашей работы зависит от гораздо большего количества переменных, чем время, которое вашей команде необходимо для фактической работы над ней.
Время доставки не равно времени приложения усилий
Когда рабочий элемент попадает в ваш бэклог, он проводит некоторое время в вашем списке дел, прежде чем начинает выполняться. После начала работы он должен будет пройти все этапы вашего рабочего процесса. Учитывая, что ваша команда работает над несколькими элементами одновременно, вашему рабочему элементу придется подождать, пока люди, ответственные за каждый вид деятельности в рабочем процессе, смогут приступить к работе над ним. Более того, время ожидания вашего элемента будет увеличиваться в результате любой дополнительной работы, возникающей в это время, любых узких мест, любых внешних блокировок и любых обнаруженных дефектов, возникающих в процессе работы.
Негативное влияние времени ожидания
Мы в Nave проанализировали около 10 000 рабочих процессов и выяснили, что в среднем 70% времени работа просто простаивает и находится в состоянии ожидания. Причиной задержек является не производительность команды, а ее неспособность продвинуть работу по воронке из-за внутренних или внешних зависимостей.
На основании этого исследования мы пришли к выводу, что в условиях низкой эффективности потока разнообразие размеров рабочих элементов не влияет на время доставки. Повышение скорости доставки сводится к тому, насколько эффективно вы управляете своими рабочими процессами, поскольку это ключ к сокращению времени ожидания до оптимального уровня.
В среде с более высокой эффективностью потока вам придется уделять внимание тому, чтобы методы работы, навыки и опыт отдельных сотрудников были достаточно схожими, чтобы делать надежные прогнозы доставки. Размер ваших рабочих элементов не является критерием, влияющим на точность прогнозов.
Прогнозирование сроков поставки
Использование вероятностных прогнозов на основе данных о вашей прошлой деятельности является одним из наиболее надежных подходов к составлению прогнозов на будущее, поскольку при этом учитываются все факторы, определяющие время доставки, включая усилия, необходимые для завершения работы, а также время ожидания в вашей системе.
Мир вероятностного прогнозирования
Давайте рассмотрим подход, позволяющий делать надёжные прогнозы на будущее без дробления пользовательских историй на равные части. Хитрость заключается в том, чтобы проанализировать, что происходило в прошлом, и основывать свои прогнозы на исторических данных о производительности.
Для получения надёжного прогноза не обязательно разбивать истории на одинаковые по размеру части. Что вам нужно, так это четко классифицировать ваши элементы по их приоритету и убедиться, что они следуют требованиям правил процесса.
Ваша прошлая производительность отображается на гистограмме времени цикла. Эта диаграмма показывает частотное распределение времени выполнения задач в вашем рабочем процессе. Сила этой диаграммы в том, что она демонстрирует изменчивость вашей системы доставки.
Пунктирные вертикальные линии, протянувшиеся через весь график, называются перцентилями. Мы используем перцентили для установления соглашений об уровне обслуживания (Service Level Agreement, SLA) и определения вероятности выполнения различных обязательств.
Для того чтобы определить, является ли ваше распределение тонкохвостым или толстохвостым, просто разделите 98-й перцентиль на 50-й перцентиль. Если результат больше или равен 5,6, это означает, что ваше частотное распределение имеет толстый хвост. Если результат меньше 5,6 — это распределение с тонким хвостом.
Необходим дальнейший анализ, чтобы подтвердить распределение с тонким хвостом. Нужно рассчитать соотношение между 98-м перцентилем и модой. Если результат меньше 16, то это распределение с тонким хвостом.
Давайте проанализируем приведенную выше гистограмму времени цикла. Различные средние значения: мода, среднее и медиана — очень близки друг к другу: 1 день, 2 дня и 3 дня — а хвост достигает примерно 11 дней. Таким образом, соотношение между самым популярным значением и 98-м перцентилем составляет 5,5. 98-й перцентиль, деленный на значение моды, равен 11. Это распределение с тонким хвостом. Это означает, что в рабочем процессе этой команды низкий уровень изменчивости. Распределение с тонким хвостом говорит о хорошей предсказуемости и, следовательно, о меньших задержках (или их отсутствии).
Приоритет ваших рабочих элементов будет представлен классами обслуживания (Classes of Service, CoS). Вы должны отфильтровать данные по их классу обслуживания. К примеру, вполне вероятно, что 85-й перцентиль для стандартных задач имеет другое время цикла, чем 85-й перцентиль для ускоренных. Таким образом, вы можете обеспечить различные SLA для различных рабочих элементов, по которым вы берете на себя обязательства.
Теперь, глядя на гистограмму, мы можем сказать, что мы можем выполнить любой элемент с приоритетом Standard менее чем за 6 дней с 85% уверенностью и менее чем за 11 дней с 98% уверенностью.
Если вы посмотрите на распределение времени цикла этой команды для стандартных элементов, вы увидите, что время приложения усилий, отслеживаемое в активных состояниях рабочего процесса, составляет около 60% от их времени доставки. И даже несмотря на то, что их истории имеют разные размеры, они управляют стабильной системой и выполняют свои обязательства с высокой степенью уверенности.
Сложность точного прогнозирования доставки
Давайте теперь изучим приведенную ниже диаграмму распределения времени цикла, показывающую распределение для элементов со стандартным приоритетом.
Первая линия здесь указывает на 1 день. Это мода в данном распределении времени цикла, она представляет то, что происходит в наиболее типичном сценарии. Это означает, что если бы у вас было такое распределение и кто-то спросил вас, когда будет сделана работа, наиболее популярный ответ был бы — менее чем за день. 50-й перцентиль указывает на 9 дней. Таким образом, в половине случаев вы действительно выполнили работу менее чем за 9 дней.
Однако, средний показатель составляет 22 дня. Хвост распределения достигает 98 дней. Другими словами, самое длительное время, которое потребовалось для завершения тикета (без учета выбросов), примерно в 100 раз больше, чем типичное время в 1 день. И в 10 раз больше, чем 50-й перцентиль.
Это распределение с толстым хвостом. Распределение с толстым хвостом означает плохую предсказуемость и потенциально высокое влияние длительных задержек. Распределения с толстым хвостом хрупки. Если бы вас спросили: "Когда это будет сделано", и вы бы хотели действительно быть уверенным в своем ответе, ваш ответ должен был бы быть — менее 98 дней.
Если у вас распределение с толстым хвостом и вы поддерживаете нестабильную систему, любой подход к составлению прогнозов будет ненадежным.
Рассматривая распределение времени цикла для этой команды, мы видим, что время, проведенное их рабочими элементами в активном состоянии, составляет около 60%, из которых 45% — это время блокировки (красные участки на графике). Это означает, что их фактическое время работы составляет 15% от общего времени доставки.
Точность вашего вероятностного прогноза не зависит от размера ваших рабочих элементов. Она зависит от стабильности вашего рабочего процесса доставки.
В стабильной системе самым важным фактором будет приоритет элементов. Если ваша система оптимизирована для предсказуемости, и запущено несколько историй с разными размерами, они будут строго следовать своему порядку приоритетов. Маленькие элементы с низким приоритетом не смогут занять время у больших более сложных задач с более высоким приоритетом. Меньшие элементы должны будут ждать в рабочем процессе, пока более срочные элементы не будут завершены первыми.
Если ваша команда не может начать новую работу, поскольку достигнут лимит количества текущей работы (Work In Progress, WIP), им придется сотрудничать друг с другом и кооперироваться ("swarm") вокруг незавершенных задач, чтобы завершить их быстрее. Затем внимание переключается на препятствия в системе и их скорейшее устранение, чтобы обеспечить бесперебойный поток работы.
Оценка размера ваших историй — отличный способ завязать разговор о цели, которую должен достичь тот или иной рабочий элемент. Тем не менее, этот подход не имеет значения, когда речь идет о выполнении прогнозов на будущее. Формирование надежных обязательств и их выполнение тесно связаны с тем, насколько эффективно вы управляете потоком работ и, в конечном счете, насколько предсказуема ваша система.
Примечание переводчика: Конечно, если у вас в одном потоке работы и в одной метрике находятся и огромные инициативы, и задачки «на один зубок», давать по ним одинаково надёжные прогнозы не получится. Следовать принципу разбиения на возможно более мелкие, но по прежнему приносящие потребителю пользу, рабочие элементы полезно независимо от того, какой метод прогнозирования вы используете.
Также стоит помнить, что метрику времени производства имеет смысл рассматривать отдельно для разных типов задач и разных классов обслуживания.
Благодарю Милу Черкасову за редактуру перевода.
