Канбан. Альтернативный путь в Agile - читать онлайн книгу. Автор: Дэвид Андерсон cтр.№ 41

Рис. 12.2. Пример спектрального анализа времени выполнения

Рис. 12.3 Пример тенденции среднего времени выполнения

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

Рис. 12.4. Пример отчета, демонстрирующего среднее время выполнения и долю заданий, выполненных в срок

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

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

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

Разумеется, самый важный показатель – был ли элемент выпущен до дедлайна.

Точность оценки – это, в свою очередь, индикатор эффективности системы. Если известно, что оценки грешат неточностью, то команде придется раньше начинать работу над элементами с фиксированной датой, чтобы гарантированно успеть к сроку. Это нельзя считать оптимальным вариантом. Общую производительность с точки зрения ценности и пропускной способности можно улучшить, повысив качество оценки.

Пропускная способность измеряется в количестве элементов (или их ценности), реализованных за указанный период, например за один месяц. Пропускная способность представляется в виде тенденции, как показано на рис. 12.5. Цель состоит в ее постоянном увеличении. Пропускная способность близка к такому показателю agile-методологий, как «скорость». Он показывает, сколько пользовательских историй закончено за данный период (или сколько очков за пользовательскую историю набрано). Если вы не используете такие agile-техники, а занимаетесь обработкой других элементов – например, элементов функциональных требований, запросов изменений, пользовательских сценариев, – то считать можно и в них.

Рис. 12.5. Пример столбиковой диаграммы пропускной способности

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

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

Диаграмма проблем и блокированных рабочих элементов – это кумулятивная диаграмма потока, где отражены возникшие препятствия. Она объединена с графиком количества заблокированных незавершенных заданий (рис. 12.6). Эта диаграмма демонстрирует, насколько хорошо организация справляется с выявлением блокирующих проблем и их влияния, сообщением о них и борьбой за их устранение.

.

Рис. 12.6. Пример диаграммы проблем и заблокированных рабочих элементов

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

Хороший индикатор для бережливого производства, показывающий степень эффективности системы, – отношение времени выполнения ко времени контакта. В производстве время контакта – это время, которое сотрудник проводит непосредственно за работой. В области разработки ПО измерить этот показатель очень трудно. Однако в большинстве систем отслеживания можно выявить отношение времени, выделенного отдельному сотруднику, ко времени блокирования и нахождения в очереди. Таким образом, хотя сообщение об отношении времени выполнения к выделенному времени не дает точной картины эффективности системы, оно вполне может показывать, каков потенциал для улучшения (рис. 12.7).

Рис. 12.7. Пример отношения времени выполнения к выделенному времени

Пусть вас не пугает, что изначально отношение равняется, например, 10: 1. Я был на многих конференциях, где докладчики, представлявшие самые разные сферы деятельности – от строительства самолетов до проектирования медицинского оборудования, – сообщали о таких же показателях.