Про ИТ-менеджмент

Постараемся сделать мир чуточку счастливее

Previous Entry Поделиться Next Entry
Actionable Agile Metrics for Predictability
anton_nix


Прочитал книгу, посоветованную Джонатаном. Почерпнул много полезного:

  • Что у закона Литтла, который очень любят исповедующие канбан, есть ряд допущений, без которых он не работает.

  • Что Cumulative Flow Diagram тоже не работает в ряде случаев.

  • Что Scatterplots, оказывается, очень-очень полезные.

  • Что есть такая штука Lean Forecasting, которая позволяет достаточно точно статистически оценивать дальнейшие работы по проекту. Без экспертных оценок. Без затрат времни на оценку. Вообще.

В особенности меня зацепили последние две штуки.

Scatterplot

Scatterplot - это диаграмма, которая показывает тупо фактические сроки завершения задач:



По горизонтали - дата завершения задачи. По вертикали - сколько эта задача делалась дней. Не человеко-дней, а именно дней, т.е. Cycle Time по-научному.

По этой диаграмме можно сказать, сколько задач мы закрывали за определенное кол-во времени. Соответственно, какую бы новую задачу нам не подкинули в будущем, всегда можно сказать, что наверное с 85% вероятностью мы сделаем эту задачу за 43 дня.

Но это работает только для одной задачи. А как предсказать, сколько времени займет пачка новых задач? Прикол в том, что средние здесь считать нельзя, т.к. распределение не нормальное, а примерно вот такое:



По горизонтали - Cycle Time завершения задач. По вертикали - фактическое кол-во задач, которые мы сделали за соответствующее время. Причем, автор утверждает, что у большинство проектов по разработке ПО имеют именно такое распределение.

Прогнозирование сроков

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

Я плох в статистике. Так что я для себя в итоге выработал следующий алгоритм. Буду очень рад если кто-то мне скажет, где я косяк и объяснит как правильно.

  1. Проверяем, что наш процесс стабилен. Т.е. это не старт проекта, когда мы только раскачиваемся. И не завершение.

  2. Берем статистику за прошлые 1-2 месяца (автор утверждает, что для правильного распределения не обязательно иметь большое кол-во задач).

  3. Рисуем распределение времени их завершения (гистограмму типа представленной выше).

  4. Считаем интеграл от этой гистограммы. Всмысле, не формулу считаем, а численно - просто складывая столбики с предыдущим.

  5. Потом запускаем N симуляций и считаем результат.

Симуляция - это просто эксперимент. Например, предстоит сделать ещё 50 задач. Берем на полученном интеграле 50 случайных точек по вертикальной оси и смотрим, какие выходят Cycle Time. Их складываем и получаем общий Cycle Time завершения этих 50 задач (конечно, если мы их будем делать последовательно - надо учесть, сколько у вас ресурсов работает над задачами).

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

Итого

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

В конце книги есть интересный пример, как это использовалось в одном из подразделений Siemens на реальном проекте.

Вообще, книга мне чем-то не понравилась - было ощущение, что в некоторых местах автор противорчечит сам себе. Но в целом дала очень полезные идеи на будущее, за что большое ей спасибо! Как попробую на практике, так сразу отпишу!

  • 1
А, да, можно и так. Просто я привык эти вещи называть Card Type, а не CoS. В вышеупомянутой книжке CoS дается определение, что это именно как признак указывающий порядок, в котором они должны проходить через систему.

  • 1
?

Log in