Пример диаграммы выгорания показан на рисунке 3.2 . На рисунке рекомендации представляют идеальный сценарий, когда ваши оценки со временем сгорают; остальные значения представляют фактическое количество задач, которые не закрыты на текущей временной шкале.
Рисунок 3.2.Пример диаграммы выгорания

Burn down очень популярен, но его ценность ограничена из-за эмпирического характера гибкой разработки. У вас никогда не будет гладкой кривой, и хотя она используется в качестве ориентира, ее ценность завышена. Настолько, что многие Scrum-коучи осуждают использование диаграммы выгорания, и ее использование в agile-командах начинает уменьшаться. Хотя он дает представление о том, где вы выступаете против своих обязательств в течение определенного периода времени, само по себе выгорание не может дать вам всей истории.

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

Скорость можно рассчитать, построив график суммы, которую вы оценили, по сравнению с суммой, которую вы фактически сделали. В конечном итоге Velocity подразумевает несколько вещей о вашей команде:

• Насколько хорошо ваша команда оценивает работу
• Насколько последовательно ваша команда выполняет работу
• Насколько последовательно ваша команда может брать на себя обязательства и выполнять их

Несмотря на то, что скорость является основной метрикой Agile, ее относительная природа затрудняет точное определение того, где действительно есть проблемы. Если скорость непостоянна, может возникнуть ряд проблем, таких как:

• Ваша команда плохо справляется с оценкой.
• У вашей команды проблемы с обязательствами.
• Объем может измениться в середине цикла разработки.
• Вы можете столкнуться с неприятным техническим долгом.

Ключевой показатель скорости, с которым мы будем работать, — это оценки, которые ваша команда ставит перед своими задачами. Мы углубимся в оценки позже в этой главе и разберем их по другим точкам данных в главе 7 .

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

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

Время выполнения
Время выполнения — это количество времени между запуском задачи и ее завершением. Команды, практикующие Канбан, сосредотачиваются на пропускной способности, и в результате они обычно уделяют большое внимание времени выполнения заказа; чем быстрее они могут перемещать задачи по каналам, тем большей пропускной способности они могут достичь. Некоторые Scrum-команды используют не только скорость, но и время выполнения заказа, потому что эти две метрики говорят о разных вещах; скорость говорит вам, сколько ваша команда может сделать по отношению к тому, что, по их мнению, они могут сделать, а время выполнения говорит вам, сколько времени требуется, чтобы добиться цели.
Проблема только с временем выполнения заказа заключается в том, что часто команды не обращают пристального внимания на то, что его составляет. Время выполнения включает в себя создание задачи, ее определение, работу над ней, ее тестирование и выпуск. Если вы не можете его разложить, то трудно понять, как его улучшить. Мы рассмотрим декомпозицию времени выполнения заказа в последующих главах.
Для команд, которые просто получают небольшие заявки и проталкивают их через систему, время выполнения заказа является хорошим индикатором того, насколько эффективной может быть команда. Но если у вас есть команда, которая владеет продуктом, который они создают, и отвечает за разработку этого продукта, у вас обычно нет такого простого механизма доставки. На самом деле, с учетом уровня автоматизации вы даже можете утверждать, что если ваши задачи настолько малы, что вам не нужно их оценивать, то, возможно, вам не нужен человек для их выполнения.
Время выполнения становится очень ценным показателем, если вы практикуете CD и можете измерить все части вашего процесса доставки, чтобы найти эффективность. Это отличный высокоуровневый показатель эффективности всего процесса, которому следует ваша команда.

3.1.5.Количество ошибок
Ошибки представляют собой несоответствия в вашем программном обеспечении. У разных команд будут разные определения того, что такое ошибка, начиная от вариации спецификации вашего приложения и заканчивая неожиданным поведением, которое замечают после завершения разработки.
Ошибки будут появляться в разное время в зависимости от того, как ваша команда работает вместе. Например, команда со встроенными инженерами по качеству может не генерировать ошибки до того, как функция будет завершена, потому что они работают бок о бок с инженерами по функциям и решают потенциальные проблемы до того, как они будут опубликованы. Команда с офшорной командой QA в конечном итоге будет генерировать заявки на ошибки, потому что тестирование идет в шахматном порядке с разработкой функций.
На рис. 3.5 показаны две разные диаграммы, на которых отслеживаются ошибки во времени. Поскольку ошибки представляют собой то, что вы не хотите, чтобы ваше программное обеспечение выполняло, команды стремятся к низкому количеству ошибок как к показателю хорошего качества программного обеспечения.
Рисунок 3.5.Две диаграммы, показывающие количество ошибок и момент их обнаружения.

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

Четко определите, когда задачи будут выполнены
Done означает, что задача выполнена. Несмотря на кажущееся простое определение, сделаноБизнесу и agile-команде может быть непросто разобраться и договориться. Поскольку данные в вашей PTS связывают время с задачами, критерии завершения задач являются ключевыми, поскольку они определяют время окончания задачи. Часто завершение означает, что рассматриваемая задача готова к развертыванию для ваших потребителей. Если вы группируете множество изменений в развертывания и имеете отдельный процесс доставки кода, то измерение времени, необходимого для подготовки к циклу развертывания, имеет смысл. Если вы переходите к модели, в которой вы постоянно развертываете изменения для своих потребителей, лучше классифицировать задачи как выполненные после их развертывания. Какими бы ни были ваши методологии развертывания, вот некоторые моменты, которые следует учитывать при определении выполнения задач вашей команды:

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

Как только задача отмечена как выполненная, она становится историей, и любая дополнительная работа должна стать новой задачей. Часто возникает соблазн повторно открыть задачи после их завершения, если изменились требования или обнаружена ошибка в другом цикле разработки. Гораздо лучше оставить задачу выполненной и открыть другую задачу или исправить ошибку. Если у тебя естьхорошее соглашение о том, что значит быть выполненным, и задача соответствует этим критериям, на самом деле нет веских причин отменять ее.

Если у вас нет четкого соглашения о том, что значит выполнять ваши задачи, и ваша команда не отмечает задачи как выполненные согласованным образом, вы не сможете доверять большинству своих данных. Это связано с тем, что многое из того, что вы хотите узнать от своего PTS, сосредоточено на том, сколько времени требуется для выполнения задач, а не на то, сколько времени, по вашему мнению, они должны были занять. Если у вас нет точного способа определить, когда что-то завершено, трудно с уверенностью сказать, сколько времени на самом деле занимают задачи.

Вы можете сказать, что ваш критерий завершения не совсем точно определен, когда вы начинаете видеть необычные всплески объема и движения назад, как показано на рисунке 3.9 .

Это происходит по одной из следующих причин:

• Выполненные задачи возвращаются обратно в рабочий поток.
• Задачи не проверяются и отправляются обратно команде разработчиков для дальнейшей работы.

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

Четко определите, когда задачи выполнены хорошо
Хорошо и плохоявляются воплощением относительных терминов. Каждая команда имеет свое представление о том, что, по их мнению, хорошо, исходя из их истории, продукта, над которым они работают, того, как они внедряют Agile, и мнений ее членов. Просмотрите свой список выполненных задач и начните отмечать свои карточки как хорошие, плохие или промежуточные. Как неоднократно демонстрировалось, разные шаблоны означают разные вещи в зависимости от команды; абсолютных паттернов просто не существует в относительном мире. Помечая карточки в зависимости от того, насколько хорошо, по вашему мнению, работал процесс, а также добавляя другие теги, описывающие задачу, вы можете определить закономерности, влияющие на производительность команды. Как вы увидите, когда начнете работать со своими данными, теги станут метаданными вашей работы;
Это напрямую относится к разделу 3.2.2 , когда мы говорили о пометке задач и работе с этими данными позже. Если вы сопоставите задачи как хорошие или плохие и отследите их по объему, вы получите довольно хороший показатель того, насколько счастлива ваша команда. В данном случае «хорошо» означает, что задача выполнена хорошо, проблем с ней не возникло, и все довольны ее выполнением. Плохоозначало бы, что команда по какой-то причине недовольна задачей; примерами могут быть то, что они были недовольны тем, как были написаны требования, была другая проблема, которая усложняла выполнение этой задачи, или оценка была далекой. В других средах для этого можно использовать календарь Нико-нико, где каждый день члены команды помещают на стену смайлик, изображающий, насколько они счастливы. Определение того, насколько вы удовлетворены выполнением отдельных задач, — это гораздо более простой и тонкий способ выяснить, как команда относится к тому, над чем они работают. Это также может помочь вам получить представление о тенденциях ваших оценок. Как мы упоминали ранее, плоские оценки могут радовать менеджеров проектов, но это не значит, что в команде все идет хорошо.На рис. 3.10 показан пример команды, которая уравнивает оценки и завершение, а также помечает карточки как «счастливые» или «грустные» в зависимости от того, насколько хорошо, по мнению разработчика, это было сделано.
Рисунок 3.10.Оценки и завершение сопоставлены с тем, как разработчик думал, что карта была завершена.

3.3.1.Объем задачи
Данные, которые мы нанесли на карту в этой главе, представляют собой объем предполагаемых усилий, выполненных с течением времени. Измерение оценок — хорошее место для начала, потому что это уже обычная практика в agile-командах и обеспечивает знакомую отправную точку.
Объем — это количество задач, которые выполняет ваша команда. Это немного отличается от измерения оценок, когда вы оцениваете объем предполагаемых усилий независимо от количества выполненных задач. Отслеживание объема добавляет немного больше глубины к оценкам и ошибкам, поскольку помогает определить несколько ключевых элементов:

• Насколько велики ваши задачи?
• Каково соотношение новой работы с исправлением вещей и пересмотром старой работы?
• Поступают ли задачи извне процесса приема?

Дельта между оценкой и фактическим временем является ценным показателем, поскольку он показывает вам несколько потенциальных вещей:

• Насколько хорошо ваша команда понимает продукт, над которым работает
• Насколько хорошо команда понимает требования
• Насколько хорошо написаны ваши требования
• Насколько технически зрела ваша команда

Добавление скорости к вашим оценкам покажет вам, сколько задач выполняется по сравнению с предполагаемыми усилиями, которые вы вкладываете в задачи. Между ними должна быть значительная разница, потому что каждая задача будет иметь оценку более 1 балла. Если ваша команда берет на себя 10 задач, каждая из которых оценивается в 3 балла, тогда ваш объем будет равен 10, а ваша цель по скорости — 30 (10 задач * 3 оценочных балла).
Когда вы замечаете, что дельта между объемом и оценкой сокращается, это обычно указывает на то, что что-то не так. Обычно это означает, что вы делаете много работы, которую не планировали. Если объем ваших задач равен 30, а ваша целевая оценка равна 30, то либо у вас есть 30 задач, все из которых оцениваются в 1 балл, либо в ваш рабочий поток проникают задачи, которые вы никогда не оценивали. Чтобы выяснить, откуда это берется, вам придется немного больше покопаться в ваших данных.