Обзор

• В книге детально рассмотрены два инструмента визуализации и анализа данных о разработке: Cumulative Flow Diagrams (CFDs) и Cycle Time Scatterplots.
• Во введении сказано, что участники команды разработки должны перестать давать размытые и ненадежные оценки и начать делать точные предсказания. А команда менеджеров должна понимать, из чего складывается точность предсказания и обеспечивать соблюдение этих условий.
• Первая часть вводит понятие метрик потока, перечисляет их, поясняя, каким образом они описывают степень предсказуемости работы. Нужно понять, каково место этих метрик в общей картине, на каком уровне управления они могут быть использованы.
• Вторая часть посвящена CFD, объясняет, как вывести из них метрики и как проанализировать. Упоминается, что многие источники неправильно интерпретируют эти диаграммы, а некоторые инструменты их даже неправильно строят. Обещают научить исправлять эти ошибки.
• Третья часть - про Cycle Time Scatterplots, все то же самое
• Четвертая и пятая части - общий свод и разбор примера из реальной жизни (Siemens)

Выглядит так, что это полезная прикладная книга с инструкциями и необходимыми теоретическими обоснованиями. Мне нравится ее сфокусированность на более высокоуровневых (чем, скажем в Agile Metrics in Action) метриках потока, так как они более комплексные и информативные.

Конспект

Вопрос “Когда будет готово?” - по сути, единственный интересующий заказчика вопрос. Особенно, если учесть, что в большинстве случаев заказывается не готовый итоговый продукт, а какая-то его часть, и заказчику необходимо спланировать работы по созданию всего продукта целиком. Естественно, важно понимать, когда каждая из частей будет готова.

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

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

Главный враг потока - очереди, поэтому необходимо научиться видеть очереди и работать с ними.

Flow metrics - метрики потока- это разумное объяснение, так как обладает предсказательной способностью, и составляющие этого объяснения сложно или невозможно варьировать. А это означает, что мы должны принимать их всерьез и строить свою работу с учетом этих метрик и их интерпретации.

Несмотря на то, что подход к управлению потоком контринтуитивен.

Закон Литтла - важно, что предположения, лежащие в основе закона, могут (или должны) превратиться в политики, призванные повысить предсказуемость процесса.

Важно также, что для корректного функционирования и интерпретации закона Литтла, не нужно, чтобы единицы работы были одного или даже сопоставимого размера. Это так, потому что закон Литтла оперирует средними величинами, а также потому, что вариативность размера единицы работы - это не самая большая угроза предсказуемости (есть большой WIP, суровость нарушения предположений закона Литтла и т.п.)

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

Архитектура любого процеса - это всего лишь сумма политик (правил). То, насколько хорошо перформит система, это следствие качества политик и дисциплины их применения.

Cumulative Flow Diagrams

Свойства CFD:

1. Верхняя линия на такой диаграмме - это всегда сумма всех поступлений работы в систему нарастающим итогом. Нижняя линия - это всегда сумма всех выходов работы из системы нарастающим итогом.
2. Ни одна линия на такой диаграмме не может понижаться (т.к. это нарастающий итог).
3. Расстояние по вертикали между любыми двумя линиями на диаграмме - это WIP между этапами процесса, обозначенными этими линиями.
4. Расстояние по горизонтали между любыми двумя линиями - это приблизительное среднее время потока между соответствующими этапами процесса. Приблизительное - потому что рассчитано не по консистентному набору задач, т.е. задачи, которые вышли из процесса (на правой точке горизонтальной прямой), это не те же самые задачи, которые вошли в процесс.
5. Диаграмма показывает только то, что действительно произошло. Не имеет смысла проецировать данные диаграммы на будущее.
6. Наклон любой линии между любыми двумя точками показывает точный средний темп поступления работы на следующий за линией этап.

Вопросы к CFD:

• Совпадает ли темп поступления работы с темпом поставки?
• Раздуваются ли резко какие-то из полос, соответствующих этапам процесса?
• Исчезают ли некоторые полосы?
• Есть ли длинные периоды, когда линии становятся горизонтальными?
• Есть ли четко различимые большие и/или ритмичные “ступеньки” на диаграмме?
• Формирует ли диаграмма что-то вроде S-образной кривой?

Сохранение потока

Главная задача - обеспечить стабильность системы, а для этого необходимо выровнять темпы поступления и поставки работы. Это необходимо, т.к. стабильность системы - это одно из предусловий для использования Закон Литтла

Стремление к балансу темпов спроса и поставки - подробно рассматривается в The Book of TameFlow и Standing on Bits.

Второй инструмент для сохранения потока - это just-in-time расстановка приоритетов и принятие обязательств, это общее свойство pull-систем. Основной мотив - расстановка приоритетов в бэклоге по большей части - пустая трата времени, т.к. большая часть единиц работы в бэклоге не будет взята в работу в том виде, в котором существует прямо сейчас. Гораздо лучше будет определить приоритеты в момент, когда система сигнализирует о наличии достаточного ресурса для того, чтобы вытянуть новый элемент работы.

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

Долг по потоку

Если сравнить приблизительное среднее время потока (горизонтальная линия на CFD) с расчетным, то возможны три ситуации:

1. Приблизительное больше расчетного. Это долг по потоку, так как мы “протолкнули” часть работы сквозь систему с нарушением приоритетов. Это произошло за счет задержки работ по остальным работам. Такая ситуация вообще-то понижает точность расчета среднего времени потока и приводит к дестабилизации системы. Причины - наличие авральных работ, долгое время ожидание заблокированных работ или постоянное вытягивание более приоритетных работ, когда есть незавершенные работы в процессе.
2. Приблизительное меньше расчетного - мы выплачиваем долг по потоку, но это тоже не очень хорошо сказывается на средних оценках - они становятся искусственно завышены и таким образом “расширяют” доверительный интервал любых оценок продолжительности. Система тоже дестабилизируется.
3. Значения примерно равны. Идеальная ситуация, все работы протекают в соответствии со своими приоритетами.

Cycle time scatterplots

График, по оси X которого отложено календарное время, а по оси Y - Flow time. Каждая единица работы представлена точкой на графе, координата X у которой - это дата завершения работ, а координата Y - это количество дней (недель, месяцев и т.п.), за которое единица работы прошла по процессу.

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

Эти же данные можно отобразить в виде гистограммы и по мере накопления данных определить форму статистического распределения. Однако можно сразу предположить, что у большей части таких гистограмм будет наблюдаться высокий “горб” в левой части и длинный пологий “хвост” в правой.

Использование данных для прогнозирования

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

Разного рода “классы обслуживания” и создание особых правил для особых единиц работы обычно вредят предсказуемости. Крайний случай таких политик - это стандартный предсказуемый процесс для “особых” работ, но полная неопределенность для “стандартных”. И это - очень плохая ситуация.

Прогнозирование сроков окончания работ - это предоставление оценки, которая включает в себя диапазон дат и вероятность попасть в этот диапазон.

Почему нельзя пользоваться описанными ранее методами?

Закон Литтла не подходит для прогнозирования в этом смысле, потому что он, во-первых, дает детерминированную оценку, а во-вторых, оперирует средними, а не реальными величинами. Мы не знаем заранее, какие пререквизиты закона и насколько сильно будут нарушены в будущем, поэтому не можем полагаться на формулы закона. Средние величины бессмысленны, если мы не знаем распределения данных, на которых они посчитаны.

Проекции в будущее на CFD (особенно в виде прямых линий) тоже не очень помогают, потому что опять же построены на средних и не учитывают изменения вариабельности в будущем. CFD для проекта с нулевым WIP в начале и конце имеет S-образную форму, а такие формы плохо аппроксимируются прямыми. К тому же такой метод прогнозирования требует наличия на диаграмме полосы бэклога, а это нарушение правил CFD. Прогнозная точка (дата релиза) получается всего одна (а не диапазон), и мы ничего не знаем о вероятности попасть в эту точку.

Прогноз для одной единицы работы - это всего лишь данные о персентилях для всех завершенных работ такого же типа (SLA - Service Level Agreement).

Симуляция Монте-Карло

Для симуляции нужны данные из “здорового” потока - то есть от системы, которая не нарушает правил закона Литтла и не накапливает “долг по потоку”. Также модель симуляции должна в точности отражать политики вытягивания работы, действующие в системе.

План действий

1. Определить границы процесса и его этапов.
2. Определить, какие единицы работы внутри этих границ (процесса в целом) будут считаться WIP, по каким критериям это можно будет определить.
3. Проанализировать политики и выявить нарушения предположений закона Литтла.
4. Начать собирать данные (вручную или автоматически). Понять, что любые данные хороши настолько, насколько хороша культура и дисциплина работы с задачами.