Для того, чтобы замерять продуктивность разработки, надо уметь планировать разрабоку с очень хорошим качеством.
Для того, чтобы планировать разработку - нужен техпроект или архитектурное описание, на основании которого можно оценить затраты ресурсов.
Для того, чтобы был достаточно проработанный техпроект, нужны соответствующие компетенции по техническому проектированию в отрасли. А их очень мало. Потому, что:
1. Научная база организации труда проектировщиков ПО - крайне хреново у нас оформлена. У нас нет методичек соответствующего уровня и качества. Этому явное подтверждение - куча споров о том "Какая нотация лучше". Вместо ссылок на исследования.
2. Это в т.ч. обусловленно требованием к срокам разработки и внедрения продуктов. Они меньше, чем требуется для проработки методической базы на научной основе и проработки самой научной основы. Методы проектирования - до сих пор сводятся к тому, что "- У вас должен быть кто-то гениальный, кто тащит разработку и принимает дешёвые и правильные решения".
Т.е. цепочка причин-следствий в итоге сводится к :
1. Если завтра не сделаем хоть что-то - всё пропало, поэтому некогда разрабатывать сегодня - внедряйте завтра.
2. Разработать нужно сегодня, поэтому проектировать некогда. Разрабатывайте
3. Проектировать сегодня некогда, значит некогда и разбираться в причинах неудач ИТ-проектов. Потому, что "Разрабатывайте сегодня, внедряйте завтра".
4. Исследовать причины провалов и методы улучшения качества труда в целом, даже в рамках отраслей - некогда. Потому, что "Разрабатывайте сегодня, внедряйте завтра".
Видимая мной мотивация за этим стоит следующая:
"Кто быстрее удовлетворяет текущие потребности клиента - зарабатывает больше. Кто больше зарабатывает - тот хороший. Поэтому доставка ценности клиенту должна занимать, включая проектирование и разработку - 0 времени."
При этом не важно насколько компетентен клиент в оценке того, что является для него ценностью. Чем менее компетентен клиент - тем больший объём услуг он может потенциально потребить. Поскольку для достижения целей менее компетентному требуется в среднем больше ресурсов, чем компетентному.
Следовательно причина в росте затрат на разработку и сопровождение - компетенция потребителя конечных услуг. Чем она выше - тем дальше потребитель может прогнозировать свои действия и следовательно запрашивать услуги ЗАРАНЕЕ. Чем более "заранее" потребитель может запросить услугу - тем больше временного ресурса на её проработку и повышение качества до достаточного уровня с точки зрения сратегии потребителя.
Увы... трудно возразить...
Хотя метрики - это ключевой аспект Agile, и игнорирование метрик часто приводит к тому, что целая индустрия называется венчурной, т.е. обладающей повышенным риском. Мне известно множество проектов, где стоимость изменения кода стала настолько высокой, что стала причиной финансового кризиса, причем, не всем проектам удалось этот кризис пережить, и они потонули. На два проекта из моей практики я был приглашен для вывода проекта из кризиса. Но, надо заметить, что на отечественном рынке ситуация существенно лучше, чем на заокеанском, по крайней мере, субъективно.
Практически все ведущие авторитеты в области архитектуры сходятся во мнении, что если архитектурой не заниматься, то стоимость изменения кода возрастает экспоненциально. В среднем, примерно через 2-4 года, разработка таких проектов становится нерентабельной, и наступает финансовый кризис. Но я видел проекты, доведенные до грани банкротства и за один год.
По поводу design payoff line - очень хорошо рассматривается в статье
https://martinfowler.com/articles/is-quality-worth-cost.htmlИ в
https://martinfowler.com/bliki/DesignStaminaHypothesis.html
