Project tracking systems, test and build tools, source control, continuous integration, and other built-in parts of the software development lifecycle generate a wealth of data that can be used to track and improve the quality and performance of products, processes, and teams. Although the iterative nature of Agile development is perfect for data-driven continuous improvement, the collection, analysis, and application of meaningful metrics often fades in favor of subjective measures that offer less insight into the real challenges of making better software.
Agile Metrics in Action: Measuring and enhancing the performance of Agile teams is a practical book that shows how to take the data already being generated to make teams, processes, and products better. It points out which metrics to use to objectively measure performance and what data really counts, along with where to find it, how to get it, and how to analyze it. The book also shows how all team members can publish their own metrics through dashboards and radiators, taking charge of communicating performance and individual accountability. Along the way, it offers practical data analysis techniques, including a few emerging Big Data practices.
The iterative nature of agile development is perfect for experience-based, continuous improvement. Tracking systems, test and build tools, source control, continuous integration, and other built-in parts of a project lifecycle throw off a wealth of data you can use to improve your products, processes, and teams. The question is, how to do it? Agile Metrics in Action teaches you how. This practical book is a rich resource for an agile team that aims to use metrics to objectively measure performance. You'll learn how to gather the data that really count, along with how to effectively analyze and act upon the results. Along the way, you'll discover techniques all team members can use for better individual accountability and team performance.
Davis C. W. H. Agile metrics in action: how to measure and improve team performance / C. W. H. Davis, Shelter Island, NY: Manning, 2015. 246 c.Обзор
- очень практическая, прямо “бери-и-делай” книга
- три части: (1) проблематика и особенности измерений в Agile-проектах; (2) техники сбора и анализа данных; (3) создание метрик и их использование при работе с командой, процессами и ПО в целом.
- рассмотрены четыре источника данных: таск-трекер, системы контроля версий, CI/CD-пайплайны и экземпляры работающих в проде систем.
Есть ощущение, что к этой книге нужно будет обратиться за конкретикой и четкими инструкциями по сбору данных и выведению из них полезных метрик. Но перед этим нужно будет определиться с тем, какие именно метрики хочется собирать (для чего, с какой целью).
- Командам нужен предсказуемый и ритмичный процесс поставки ценности, позволяющий выводить потребительскую ценность на прод в любой момент.
- Командным процессам не хватает “измеримости”, добиться ее очень трудно, поэтому команды зачастую даже не задаются вопросами типа “стали ли мы лучше доставлять ценность?” или “улучшило ли это изменение наши процессы?”.
- Циклы обратной связи в Agile-командах будут в разы эффективнее, если будут опираться на объективные данные.
Измерение эффективности Agile-команды
Улучшения становятся возможны, когда мы используем новые знания о процессах команды в ее повседневной работе.
- речь идет о замыкании цикла обратной связи, использовании данных процесса для улучшения самого процесса.
- важна объективность, иначе мы будем получать неадекватные реальности результаты
Цикл обратной связи применительно к метрикам: (1) собрать данные, (2) задать новые вопросы, (3) изменить процессы на основе анализа данных.
Если честно, то цикл какой-то странный - вопросы задавать нужно после того, как данные собраны, это как-то нелогично. Неужели это рекомендация собрать все, что только можно, а потом думать, как это можно применить? Далее в книге несколько раз акцентируется внимание на том, что сбор данных должен быть максимально дешевым, поэтому собирать нужно только то, что реально используется для расчета метрик.
Метрики - это один из инструментов фасилитации общения и межролевого взаимодействия в команде.
Проблема: Принципы и формулировки Agile требуют значительного уточнения, чтобы стать полезной основой для объективного измерения. Примеры расплывчатых формулировок: “working software”, “measure only what matters”.
Принципы как основа дискуссий и обучения
Проблема:
Зачастую продукты создаются с использованием техник управления проектами, но agile- (продуктовый) и waterfall- (проектный) подходы плохо сочетаются.
- Продукт vs Проект - ложная, на мой взгляд дихотомия. Проект и продукт относятся к разным типам, поэтому противопоставлять их нельзя.
- Микропроекты в продуктовой разработке - эссе о том, что в современной продуктовой разработке масштаб проектов сильно сократился, но зато их стало много.
Проблема: Разношерстные данные без стандартизированных полей, форматов представления и расчетов. Следствие того, что на разных этапах цикла разработки и для соблюдения интересов разных проектных ролей используются разные неунифицированные инструменты.
Источники данных для метрик
- Трекер задач
- Как хорошо команда понимает продукт?
- Как быстро движется команда?
- Насколько постоянна скорость (какова ритмичность / предсказуемость) команды?
- Система контроля версий
- Как много изменений происходит в коде?
- Насколько хорошо сотрудничает команда разработки?
- Система сборки / деплоя
- Как часто изменения доставляются до потребителей?
- Как быстро изменение может быть доставлено?
- Мониторинг
- Как хорошо функционирует код?
- Насколько хорошо удовлетворяются потребности клиентов?
Данные из трекера задач
Качество таких данных всегда очень сильно зависит от четкости понимания жизненного цикла историй. Необходимо абсолютно четки и однозначно описывать этот жизненный цикл и определять условия перехода между статусами. Особенно важно Definition of Done - определение момента готовности задачи.
Оценки (estimates) приводят к:
- лучше (выше) предсказуемость работы;
- более глубокое понимание требований;
- более серьезные размышления о продукте;
- более высокая вовлеченность.
Данные, которые можно извлечь из трекера задач:
- сгорание (burn-down). Информация полезна в основном для операционного менеджмента внутри спринта. Актуально только при работе спринтами, для работы по канбан мало пригодно.
- скорость (velocity). Информация скорее о способности точно определить скоуп работы и выполнить обязательства. В какой-то степени это мера объективности команды, адекватности ее представления о реальности.
- суммарный поток (cumulative flow). Тут я не очень понял полезность информации
- время цикла. Сильно зависит от четкости определения жизненного цикла истории, если однозначно и единообразно декомпозировать цикл нельзя, то и проанализировать эти данные не получится.
- количество дефектов. Важна критичность дефекта, но она относительна для разных ролей. Четко делить дефекты на “баги с прода” (escaped bugs) и “баги из разработки” (found bugs).
Наиболее эффективный анализ можно проводить только на максимально богатом наборе данных. В общем случае минимально допустимый набор данных включает в себя следующие показатели:
- Данные о пользователях: - Кто создал и описал задачу? - Кто назначил ответственного? - Кто работал над задачей?
- Данные о времени: - Когда была создана задача? - Когда работы были завершены? - Какой была начальная оценка задачи?
Важные требования и замечания:
- Трекером должны пользоваться все. Желательно одинаковым образом.
- Нужно размечать задачи как можно большим объемом дополнительных данных. Использовать для этого метки, т.к. это самый легковесный способ добавить данные к задаче.
- Оценивать продолжительность работ над задачей. Возможно, тут нужно разделить оценки - истории в спринте оцениваются в стори-пойнтах, а конкретные задачи внутри истории - в часах.
- Четко определить Definition of Done. Лучше придерживаться очень простого набора правил. Тут же нужно бороться с соблазном переоткрывать задачи и двигать их назад по статусам. Готовая история становится историей :) любые дополнения и доработки должны быть оформлены в виде багов или новых историй. Если есть критерий готовности, то нет смысла переоткрывать задачи. Если задачи переоткрываются, то верить данным становится практически невозможно.
- Отслеживать хорошие и плохие задачи. Помечать соответствующими метками истории, работа над которыми спорилась, и истории, которые буксовали и всячески противились. С течением времени можно будет посмотреть на возникающие шаблоны и закономерности.
Ключевые метрики проектного управления
Четыре основные метрики:
- Оценки - предварительное восприятие усилий по реализации истории
- Объем - количество выполненных задач
- Дефекты - количество дефектов, обнаруженных и обработанных
- Рецидивизм - количество задач, идущих против жизненного цикла
Сравнение объема с оценками в динамике может показать, что в процесс попадают неоцененные незапланированные работы (если разница между оценкой и объемом начинает сокращаться).
С точки зрения дефектов важны два тренда: скорость создания дефектов и скорость исправления дефектов.