` ` Code Quality == Agile Quality | Agile тренинги, обучение и сертификации Scrum, Kanban, DevOps в Scrum Украина
 
Статья отображается на оригинальном языке.

Code Quality == Agile Quality

08 дек 2019

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

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

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

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

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

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

Alt Text

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

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

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

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

Alt Text

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

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

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

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

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


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

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

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

Рекомендованные мероприятия

тренинг
Дмитрий Незабытовский  

Двухдневный курс по основам Agile и фреймворкам Scrum и Kanban. Курс сертификационный, по его окончанию участники получают именные сертификаты ICAgile Certified Professional - Agile Fundamentals (ICP).

вебинар
Алексей Кривицкий, Евгений Лабунский  

На этом вебинаре мы обсудим с Евгением цели, ответственности и круг задач Скрам-мастера для всей организации.

тренинг
Александра Баптизманская, Евгения Чумачкова  

Двухдневный углубленный класс посвященный фасилитации. Курс сертификационный, по его окончанию участники получают именные сертификаты ICAgile Certified Professional.

Рекомендованные статьи

Четыре столпа business agility (часть 2/2)

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

Модели организационного дизайна в эволюции менеджерского мышления

В этой статье, я хотел бы пояснить основные модели устройства software product development организаций и связать их эволюционными связями, показав во времени, как один орг дизайн перетекает в другой, и как и откуда в компаниях появляется нужда "трансформаций".

Мы активны в социальных сетях и хотим общаться. Добавляйтесь на нашу страничку в facebook и присоединяйтесь к нашим сообществам.

По вопросам коучинга и корпоративных программ:

+380 93 4974661
hello@scrum.ua

По вопросам публичных классов, регистраций, счетов:

+380 67 6783099
hello@scrum.ua

По всем номерам телефонов - голос и telegram.

©2017 - 2021 Scrum Ukraine. Все права защищены.