Code Quality == Agile Quality | Agile тренинги, обучение и сертификации Scrum, Kanban, DevOps в Scrum Украина
The article is displayed in the original language.

Code Quality == Agile Quality

Все мы знаем, что согласно с 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) процессе?

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

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

Recommended events

Misha Glushchenko  

The Kanban System Design (Kanban Management Professional 1) lays the foundation for the Kanban method, teaching you the principles, practices, and processes. This two-day course is certified by Kanban University and has been compiled by experts and Kanban leaders, including David J. Anderson and Mike Barrows.

Evgeniy Labunskiy  

Systems thinking is one of the basic skills that will be useful to everyone working at the team level, middle managers, transformation leaders, innovators and business stakeholders.

Evgeniy Labunskiy, Maxim Tkachuk  

Mitap for Product Owners, Project Managers, Marketing, Des Lead by Maxim Tkachuk and Eugene Labunsky. Going beyond design thinking!

Recommended articles

Новый год 2020 — уже в пути!

Дорогие друзья — клиенты, коллеги!

Время подводить итоги-2019 и готовиться к новому, 2020 году. Мы потрудились на славу: проводили Agile и LeSS-трансформации в крупнейших украинских и зарубежных компаниях, организационный коучинг и коучинг продуктовых команд, тренинги и обучение сотрудников, …

Приветствуем нашего нового клиента - Київстар

Хорошие новости перед Новым Годом! Начинаем работать с гигантом телеком рынка Украины - компанией Київстар! Компания является частью группы Veon, по итогам 2016 года «Киевстар» стал одной из 29 украинских компаний, которые, по версии американской консалтинговой группы Deloitte, попали в рейтинг …

Приветствуем нашего нового клиента - PandaDoc

У нас прекрасные новости! Мы начинаем работать с PandaDoc, одним из самых известных стартапов в Беларуси. Они разрабатывают Software as a Service, который упрощает клиентам процесс создания, отправки и отслеживания Sales документов.

PandaDoc очень известна своей сильнейшей корпоративной …

We are active on social networks and want to communicate. Add to our facebook page and join our communities.

For coaching and corporate programs:
+380 63 810-72-25 Eugene
hello@scrum.ua

For public classes, registrations, accounts:
095 014-5900 Tatyana
backoffice@scrum.ua

For all phone numbers - voice, sms, viber, whatsapp.

©2017 - 2020 Scrum Ukraine. All rights reserved.