Как сообщить об эффективности проекта разработки программного обеспечения?

Мне нравится Agile именно из-за этого — отслеживание и отчетность о производительности интуитивно понятны, детализированы, а также основаны на реальных результатах команды.

Немного фона:

в agile вы разбиваете проект на «истории», небольшие части работы, которые, если они будут реализованы независимо, будут иметь смысл для клиента. Например, для сайта PM.SE вы можете сказать: «Публикация вопроса (заголовок и содержание)» — это одна история; возможность редактирования (первоначальным автором) — это одна история; добавление тегов — это одна история; и так далее.

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

В типичном Agile/Scrum вы отслеживаете свою «скорость» (количество очков истории в день). Ваш «бэклог продукта» — это список всех историй за время существования продукта; в любой момент вы можете сказать: «У нас есть X пунктов историй, которые нужно сделать для этого проекта, из которых мы выполнили Y пунктов». Это ваше выступление.

Помимо стандартных гибких практик, вы можете делать забавные вещи, например:

• Бюджетирование (например, мы делаем только до 20-30 баллов за двухнедельную итерацию)
• Статистика (за последние 10 спринтов наша скорость постоянно росла с 30 до 40 баллов за спринт)
• Заработанная стоимость: лично мне очень нравится эта часть. Отслеживайте соотношение «ожидаемые баллы сегодня» и «фактические баллы, сделанные сегодня». Он говорит вам, если вы впереди или позади.
• Планирование продукта: у вас две недели восьминедельного проекта. Вы уже набрали 20 баллов (по 10 баллов в неделю); весь проект разбит на 160 сюжетных пунктов . У тебя никак не получится.

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

Лучшей метрикой для демонстрации прогресса проекта разработки программного обеспечения является работающее программное обеспечение . Допустим, вы еженедельно или ежемесячно отчитываетесь о статусе своих клиентов или спонсоров/заинтересованных сторон проекта. Вы можете сообщить, что 22 % указанных функций завершены (или, что более вероятно, 13 % функций завершены, еще 4 % запущены, а еще 5 % завершены на 50–90 %). Но что на самом деле означают эти цифры? На самом деле эти цифры почти ничего не значат для клиента. Даже для функции, которую вы считаете «готовой», у клиента могут быть другие ожидания, и тогда ваше «готово» — это нечто иное, чем «готово».

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

Хотя я совсем не возражаю против пепла, у меня несколько иной взгляд на наиболее ценные показатели, и я обычно сообщаю следующее:

• Время выполнения : также используется для прогнозирования, поскольку «ваше ожидание с этого момента составляет примерно N дней». Это среднее время в рабочих днях от заявки клиента до доставки для определенного класса обслуживания.
• Время цикла : То же самое, что и время цикла, но с другой отправной точкой для измерения. Это среднее время в рабочих днях от момента, когда команда принимает его как «готовый», до доставки для определенного класса обслуживания. Разница между временем лида и циклом заключается в том, сколько времени он тратит на то, чтобы оставаться в бэклоге, игнорируя его.
• Пропускная способность : сколько рабочих элементов в среднем доставляется за определенный период времени для данного класса обслуживания. По сути это скорость.

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

Что касается второй части вашего вопроса, это полностью зависит от контекста команды. Я не могу представить себе запуск распределенного или крупного проекта без какой-либо поддержки электронных инструментов, и лично добился хороших результатов как с отслеживанием рабочих элементов Rally, так и с Microsoft Team Foundation. Для небольших проектов требуется менее 5 минут, чтобы снимать их со стены карточек каждый день, что позволяет легко строить графики в Excel или на большом видном листе бумаги.

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

Мы собираем эти показатели с помощью созданного нами сайта http://www.programeter.com , чтобы отслеживать производительность и качество наших усилий по разработке продуктов.

Я бы немного не согласился с тезисом о том, что Agile исключителен тем, что полагается на отслеживание и отчетность по фактическим результатам команды.

Я могу представить, как не agile-команды сообщают о реальном прогрессе в работе, и я видел, как agile-команды сообщают о выдуманном (95% работы выполнено и 1 из 5 историй завершена во время проверки), все это вопрос правил и личной ответственности.

Что действительно может помочь в этой области, так это agile-концепция Definition of Done — кратко говоря, набор условий, которые должны быть выполнены, чтобы рассматривать часть работы как действительно, действительно завершенную, о которой можно немедленно сообщить и завершить. Я думаю, что это одна из самых важных вещей, которые необходимо определить перед началом любого измерения производительности. Только тогда есть шанс, что измерение будет объективным и информативным.