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

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) процессе?

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

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

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

тренинг
Евгений Лабунский  

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

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

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

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

Этот сертифицированный онлайн-курс раскроет перед вам мир масштабной продуктовой разработки на 5, 10 или 110 команд. В таких масштабах перед лидерами и Скрам-мастерами организаций встаёт очень много вопросов

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

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

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

Как работает оценивание задач в Kanban на практике?

Существует ли оценивание задач? Как команда может делать прогноз о завершении проекта? Можно ли заказчикам рассчитывать на поставку фичи к нужной дате? На подобные вопросы попробую ответить в этой статье.

Advanced Certified Scrum Master

Углублённая 6-недельная программа развития и поддержки Скрам Мастеров с сертификацией

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

По вопросам коучинга и корпоративных программ:
+380 67 6783099 офис
+380 63 8107225 Евгений
hello@scrum.ua

По вопросам публичных классов, регистраций, счетов:
+380 67 6783099 офис
+380 93 4974661 Катерина
backoffice@scrum.ua

По всем номерам телефонов - голос, sms, viber, whatsapp.

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