Это перевод статьи Как делать надежные вероятностные прогнозы, не разбивая истории на четные части Соня Сидерова.
От переводчика: Соня Сидерова — страстный менеджер по продукту и движущая сила Nave, инструмента анализа процессов, который работает со многими популярными системами задач и помогает командам повысить скорость доставки за счет принятия решений на основе данных.
Ее блог — отличный источник знаний о методе Канбан, и я хочу сделать эту сокровищницу более доступной для русскоязычного сообщества.
Это первый из запланированных переводов блога.
Когда я говорю командам, что они могут делать прогнозы на основе данных о том, как они выполняли свои задачи в прошлом, я очень часто слышу возражение: «Наши задачи слишком разные, у нас это не сработает».
Если команда в том или ином виде сохраняет свой размер в задачах, можно показать статистику по разным размерам и наглядно показать, насколько незначительно ее влияние.
Если такая информация не сохранилась, приходится обращаться к чужому опыту и предаваться пространным объяснениям.
И все же сомнения часто остаются.
В этой статье подробно объясняется, почему размер задачи не имеет значения.
Возможно, это поможет кому-то развеять собственные сомнения или преодолеть сопротивление команды.
Разбиение историй на равные части — обычное занятие, которое часто считается необходимым условием для надежных предсказаний будущего.
Концепция искусственного разделения рабочих элементов на равные части для получения точного прогноза поставок не имеет под собой никаких оснований.
Фактически, изменение размера ваших историй не только совершенно не имеет отношения к прогнозированию, но также может оказать негативное влияние на цели, которых вы пытаетесь достичь.
Почему искусственно выравнивать истории по размеру — не лучшая идея
Давайте рассмотрим основные причины, по которым не следует пытаться разбить рабочие элементы на равные части.Важность написания пользовательских историй, определяющих ценность для клиентов Каждая история должна представлять собой часть ценность для клиента.
Естественно, эти элементы будут разного размера и разной сложности.
Искусственно сокращая пользовательские истории, мы теряем ключевую концепцию ценности, лежащую в их основе.
Мера стоимости заменяется мерой времени.
Ценность клиента делится на единицы времени и, таким образом, становится бессмысленной для клиента.
Неестественное вырезание истории приводит к ненужным зависимостям Разбиение историй на равные части создает ненужные зависимости и добавляет ненужную сложность.
Если вы разобьете единицы стоимости на неестественные сегменты, между этими сегментами неизбежно возникнут зависимости.
Зависимости приводят к узким местам рабочего процесса.
Чем больше зависимостей вы вводите, тем сложнее будет эффективно управлять процессом.
Каждая история должна быть потенциально готовой к отправке Каждая разработанная пользовательская история должна приводить к увеличению количества доставляемых продуктов.
Если вы разрежете свои истории на равные части, они больше не будут потенциально доступны для публикации и, следовательно, не смогут быть доставлены клиенту, если потребуется.
Разбор историй имеет смысл только тогда, когда мы делаем это с точки зрения клиента.
Когда дело доходит до разбиения рабочих элементов на более мелкие части, эту цель всегда следует рассматривать с точки зрения клиента, и в конечном итоге новые выпущенные приращения не будут иметь одинаковый размер.
Должен быть четкий, продуманный дизайн, который оправдывает создание большой пользовательской истории и разбиение ее объема на несколько готовых к выпуску частей.
Если ваша пользовательская история не имеет смысла с точки зрения клиента и не дает четкого представления о цели, которую она должна достичь, вам лучше даже не начинать ее реализовывать.
Это только накапливает остальную часть незавершенной работы и застревает в рабочем процессе.
Вместо этого потратьте время на его тщательный анализ и выделение потенциально полезной детали для доставки клиенту.
Самый эффективный подход, который вы можете использовать, — это сократить расстояние между вашими клиентами и вашей командой разработчиков.
Вы должны работать совместно со своим клиентом, чтобы четко определить, что и почему вы собираетесь реализовать, и каждый в вашей команде должен понимать эти факторы.
Это задача команды — решить, как именно это сделать.
Используйте знания и опыт каждого члена команды, чтобы найти наиболее подходящее решение проблемы вашего клиента.
Таким образом, вы по-прежнему можете определять свои новые истории с точки зрения ценности, и элементы потенциально могут быть доставлены без искусственного добавления зависимостей в вашу систему.
Разница между временем усилий и временем завершения
Вы, вероятно, задаетесь вопросом, как можно делать прогнозы о будущем, не разрезая свои истории на кусочки одинакового размера.Ответ прост - составление точных прогнозов доставки не имеет ничего общего с размером товара.
.
Давайте вместе решим математическую задачу.
Время выполнения вашей работы зависит от гораздо большего числа переменных, чем время, необходимое вашей команде для фактической работы над ней.
Время доставки не равно времени усилий Когда рабочий элемент попадает в ваш бэклог, он некоторое время находится в вашем списке дел, прежде чем начнет выполняться.
После запуска ему необходимо будет пройти все этапы вашего рабочего процесса.
Учитывая, что ваша команда работает над несколькими элементами одновременно, вашему рабочему элементу придется подождать, пока люди, ответственные за каждое действие в рабочем процессе, не смогут начать над ним работать.
Более того, время ожидания вашего товара будет увеличиваться в результате любых дополнительных работ, происходящих за это время, любых узких мест, любых внешних блокировок и любых обнаруженных дефектов, возникающих в процессе.
Негативное влияние времени ожидания Мы в Nave проанализировали около 10 000 рабочих процессов и обнаружили, что в среднем 70% времени работа просто простаивает и ждет .
Задержки вызваны не производительностью команды, а неспособностью команды перемещать работу по воронке из-за внутренних или внешних зависимостей.
На основании этого исследования мы пришли к выводу, что в условиях низкой эффективность потока Разнообразие размеров рабочих элементов не влияет на время доставки.
Увеличение скорости доставки зависит от того, насколько эффективно вы управляете своими рабочими процессами, поскольку это ключ к сокращению времени ожидания до оптимального уровня.
В условиях более высокой эффективности потоков вам придется обратить внимание на то, чтобы методы работы, навыки и опыт отдельных сотрудников были достаточно схожими, чтобы делать надежные прогнозы поставок.
Размер ваших рабочих элементов не является фактором, влияющим на точность ваших прогнозов.
Прогнозирование времени доставки Использование вероятностных прогнозов, основанных на прошлых данных о производительности, является одним из наиболее надежных подходов к составлению прогнозов на будущее, поскольку он учитывает все факторы, определяющие время доставки, включая усилия, необходимые для выполнения задания, а также время ожидания в вашей системе.
.
Мир вероятностного прогнозирования
Давайте рассмотрим подход, который позволяет нам делать надежные прогнозы о будущем, не разделяя пользовательские истории на равные части.Хитрость заключается в том, чтобы проанализировать то, что произошло в прошлом, и основывать свои прогнозы на исторических данных о производительности.
Чтобы получить достоверный прогноз, не обязательно разбивать истории на равные по размеру части.
Что вам нужно, так это четко классифицировать ваши объекты в соответствии с их приоритетом и гарантировать, что они соответствуют требованиям правил процесса.
Ваши прошлые результаты отображаются на гистограмме времени цикла.
На этой диаграмме показано распределение частоты выполнения задач в вашем рабочем процессе.
Сила этой диаграммы в том, что она демонстрирует изменчивость вашей системы доставки.
Пунктирные вертикальные линии, проходящие через весь график, называются процентилями.
Мы используем процентили для заключения соглашений об уровне обслуживания (SLA) и определения вероятности выполнения различных обязательств.
Чтобы определить, является ли ваше распределение «тонким» или «толстым», просто разделите 98-й процентиль на 50-й процентиль.
Если результат больше или равен 5,6, это означает, что у вашего частотного распределения есть «толстый хвост».
Если результат меньше 5,6, это распределение с тонким хвостом.
Для подтверждения распределения с тонким хвостом необходим дальнейший анализ.
Нам нужно вычислить связь между 98-м процентилем и модой.
Если результат меньше 16, то это распределение с тонким хвостом.
Давайте проанализируем приведенную выше гистограмму времени цикла.
Различные средства: мода, среднее и медиана — очень близко друг к другу: 1 день, 2 дня и 3 дня — и хвост достигает примерно 11 дней.
Таким образом, соотношение между самым популярным значением и 98-м процентилем составляет 5,5. 98-й процентиль, разделенный на значение режима, равен 11. Это распределение с тонким хвостом.
Это означает, что в рабочем процессе этой команды низкий уровень изменчивости.
Распределение с тонким хвостом указывает на хорошую предсказуемость и, следовательно, на меньшую задержку (или ее отсутствие).
Приоритет ваших рабочих элементов будет представлен классами обслуживания (CoS).
Вам следует фильтровать данные по классу обслуживания.
Например, вполне вероятно, что 85-й процентиль для стандартных задач имеет другое время цикла, чем 85-й процентиль для ускоренных задач.
Таким образом, вы можете предоставить разные соглашения об уровне обслуживания для разных рабочих элементов, которые вы выполняете.
Теперь, глядя на гистограмму, мы можем сказать, что можем выполнить любой элемент со стандартным приоритетом менее чем за 6 дней с достоверностью 85% и менее чем за 11 дней с достоверностью 98%.
Если вы посмотрите на распределение времени цикла этой команды для стандартных изделий, вы увидите, что время усилий, отслеживаемое в активных состояниях рабочего процесса, составляет около 60% времени их доставки.
И хотя их истории разного масштаба, они управляют стабильной системой и выполняют свои обязательства с высокой степенью уверенности.
Сложность точного прогнозирования поставок
Давайте теперь рассмотрим приведенную ниже диаграмму распределения времени цикла, показывающую распределение товаров со стандартным приоритетом.
Первая строка здесь обозначает 1 день.
Это режим в данном распределении времени цикла, который представляет собой то, что происходит в наиболее типичном сценарии.
Это означает, что если бы у вас было это распределение и кто-то спросил вас, когда работа будет завершена, наиболее популярный ответ был бы менее чем через день.
50-й процентиль указывает на 9 дней.
Таким образом, в половине случаев вы действительно выполнили работу менее чем за 9 дней.
Однако средний срок составляет 22 дня.
Хвост распределения достигает 98 дней.
Другими словами, максимальное время, необходимое для оформления заявки (без учета отклонений), примерно в 100 раз превышает типичное время в 1 день.
И в 10 раз больше, чем 50-й процентиль.
Это распределение с толстым хвостом.
Распределение с толстым хвостом означает плохую предсказуемость и потенциально сильное влияние длительных задержек.
Распределения с толстым хвостом хрупкие.
Если бы вас спросили: «Когда это будет сделано», и вы хотели бы быть уверены в своем ответе, ваш ответ должен был бы быть таким: — менее 98 дней .
Если у вас распределение с толстым хвостом и вы поддерживаете нестабильную систему, любой подход к прогнозированию будет ненадежным.
Глядя на распределение времени цикла для этой команды, мы видим, что время, в течение которого их рабочие элементы находятся в активном состоянии, составляет около 60%, из которых 45% — время блокировки (красные области на графике).
Это значит, что их фактическое время работы составляет 15% от общего времени доставки.
Точность вашего вероятностного прогноза не зависит от размера ваших рабочих элементов.
Это зависит от стабильности вашего рабочего процесса доставки.
В стабильной системе важнейшим фактором будет приоритет элементов.
Если ваша система оптимизирована для обеспечения предсказуемости и у вас есть несколько историй разного размера, они будут строго следовать своему приоритету.
Мелкие задачи с низким приоритетом не смогут отнимать время у более крупных и сложных задач с более высоким приоритетом.
Меньшим задачам придется подождать в рабочем процессе, пока сначала не будут выполнены более срочные задачи.
Если ваша команда не может начать новую работу, потому что достигла ограничение на объем текущей работы (Work In Progress, WIP), им придется сотрудничать друг с другом и «роиться» вокруг незавершенных задач, чтобы выполнить их быстрее.
Затем фокус смещается на препятствия в системе и их устранение как можно быстрее, чтобы обеспечить плавный ход работы.
Оценка размера ваших историй — отличный способ начать разговор о цели, которую должен достичь конкретный рабочий элемент. Однако этот подход не имеет значения, когда дело доходит до прогнозов на будущее.
Создание надежных обязательств и их соблюдение тесно связаны с тем, насколько эффективно вы управляете рабочим процессом и, в конечном счете, насколько предсказуемой является ваша система.
Примечание переводчика: Конечно, если у вас есть и огромные инициативы, и «одноразовые» задачи в одном рабочем процессе и в одной метрике, вы не сможете давать по ним одинаково достоверные прогнозы.
Следовать принципу разбиения рабочих элементов на как можно более мелкие, но при этом приносящие пользу клиенту, полезно независимо от того, какой метод прогнозирования вы используете.
Также стоит помнить, что метрику времени производства имеет смысл рассматривать отдельно для разных типов задач и разных классов обслуживания.
Благодарю Милу Черкасову за редактирование перевода.
Теги: #Управление разработкой #Управление проектами #agile #kanban #прогнозирование #прогнозирование #Оценка #оценка времени #вероятностное прогнозирование #совершенствование процессов
-
Скупые Строки Новостей
19 Oct, 24 -
Оцените Подписчика
19 Oct, 24 -
Новая Лампочка
19 Oct, 24
