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

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

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

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

тренинг
Алексей Кривицкий  

Это официальный интенсивный сертификационный класс от ScrumAlliance. Курс читает Алексей Кривицкий - Certified Scrum Trainer, разработчик, скрам-мастер и практикующий agile-коуч с 2008 года.

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

Этот сертифицированный онлайн-курс раскроет перед вам мир масштабной продуктовой разработки на 5, 10 или 11...

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

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

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

Что такое Канбан-система и зачем там доска?

Слышали ли вы про Канбан? Почти наверняка вам попадались высказывания, что Kanban помогает навести порядок, сделать работу предсказуемой, уменьшить время выполнения задач. Но за счёт чего? Просто из-за того, что мы лепим стикеры на доску?

Звучит не очень реалистично и я с вами согласен. …

Зачем нужна сертификация специалистам, которые работают в Agile?

На связи Дмитрий Незабытовский. Я аккредитированный и действующий ICAgile Instructor и Advanced Certified ScrumMaster® (A-CSM) от Scrum Alliance. Практикующий ScrumMaster в продуктовой компании Terrasoft (Creatio).
В этой статье хочу поделиться с вами треками развития Agile специалистов начиная …

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

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

+380 93 4974661
hello@scrum.ua

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

+380 95 7402380
hello@scrum.ua

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

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

Политика конфиденциальности