Один из принципов гибкого подхода заключается в том, что вы должны измерять работающее программное обеспечение:
Рабочее программное обеспечение является основной мерой прогресса - 12 принципов Agile
Дело в том, что, хотя я могу измерить свое программное обеспечение с точки зрения количества сделанных историй, ошибок и уменьшения количества сообщений о дефектах, я застрял в том, как измерить ценность моего программного обеспечения.
Если я использую Майка Кона в качестве примера и помогаю SalesForce.com повысить на 500% ценность для своих клиентов по сравнению с предыдущим годом * - как мне измерить это увеличение? Как мне измерить, где я сейчас нахожусь?
Другими показателями, которые он использует, являются количество функций и количество функций на разработчика. Это то, что я мог бы решить, если бы мое отставание было в хорошем порядке, и истории были сокращены по «функциям», но мы только начинаем с Agile, поэтому мне нужен какой-то способ выяснить, какую ценность мы предлагаем сейчас затем используйте аналогичный показатель, скажем, за шесть месяцев, чтобы увидеть, увеличили ли мы наш результат.
Я слышал об измерении стоимости программного обеспечения с помощью увеличения дохода или увеличения степени удовлетворенности клиентов (как бы вы это измерили?), Но это увеличение может быть связано с чем-либо в компании (продажи, бухгалтерский учет, поддержка), а не с непосредственно к работе, которую выполняет мой отдел.
Итак, как вы оцениваете ценность вашего программного обеспечения и как вы начали?
* Успех с Agile - Майк Кон