Все мы знаем, что согласно с Agile-манифестом "рабочий софт - это единственная метрика прогресса". И рабочий софт в широком смысле этого слова не только запускается на машине разработчика ("it works on my machine!"), а по-настоящему работает на благо пользователей и бизнес заказчиков. Тут спора нет.

И если мы согласны с этим, то выходит, что качество кода - это единственная главная метрика качества процесса (в софтверных продуктах).

"Doh! Это ж очевидно." - скажете вы. Да, но, что такое качество кода по своей сути?

Количество открытых дефектов? Качество code review (WTFs per minute)? Процент покрытия код автотестами? Цикломатическая сложность кода?

Косвенно - да, все эти метрики полезны. Но они не про саму суть.

Давайте представим себе две команды. Команда А получила 100 тысяч строк кода, которые до этого писались в пакистанском подвале студентами-гуманитариями, а команда Б сидит на 100 тысячах строк кода, которые были написаны внутри продуктовой компании за последние несколько лет людьми, которые называют себя "клин кодерами" и носят зелёные браслетики от дяди Боба aka Robert C. Martin.

В чём же отличие? Какая команда аджайльнее? От чего это зависит? И зависит ли это от кода?

Ответ читателю должен быть очевиден - отличие в динамике внесения изменений в код. Кто сможет быстрее изменить код - команда А и Б? Да так, чтобы вся система работала не хуже, чем раньше?

Очевидно команда Б тут на коне. И не потому что они "знают код". Нельзя знать 100 тыс строк кода. То есть дело тут не в tacit knowledge о коде, которого нет у команды А, которая унаследовала код.

Выходит, что качество кода - это функция от простоты-сложности внесения изменений в него? Йеп! Высокое качество кода определяется низкой стоимостью внесения изменений в него. Это самая прямая метрика качества кода.

И стоимость внесения изменений в код ествественно будет расти с увеличением codebase. Это закон природы, его не остановишь. Но на что можно влиять - так это на то, как быстро энтропия берёт вверх. И это в наших руках. Вернее в руках людей с зелёными браслетиками. Так как они слидят за чистотой кода и всячески снижают сложность и дороговизну процесса внесения изменений.

ОК, это всё понятно. Но как это всё связано с адаптивностью бизнеса? Уровнем аджальности? Качеством аджайл трансформаций в конце концов?

Как вы уже, наверное, догадались - команда Б обгонит команду А, не только в добавлении новой фичи к продукту, при этом не поломав продукт, но они также будут намного шустрее и проворнее в переделке продукта в согласии с новыми требованиями, вызванными, к примеру: а) изменениями рынка, б) сменой стратегии компании, в) вводом новой бизнес модели, г) переменой в ожиданиях пользователей и т.п.

Компания Б сможет быстрее адаптироваться к изменениям окружающей среды, измененяя свой продукт (код). Что позволит ей в свою очередь быстрее получать обратную связь о работоспособни этих изменений. Что в свою очередь сподвигнет её на ещё более частые изменения и эксперименты с кодом для тестирования новых стратегий, бизнес моделей, ожиданий пользователей...

А это и есть naked agile - аджайл в самой сути своего определения.

P.S. Сколько времени в среднем у вас уходит с момента изменения строки кода программистом до отработки этого кода на проде при вашем нормальном (не hot-fix) процессе?

Я лично считаю, что это лучшая метрика качества вашего процесса деплоймента. И она должна уменьшаться со временем.

Вы над этим работаете? Есть ли у вас есть в бэклоге работы по снижению времени деплоймента? Делаете ли вы что-то с этим каждый спринт?