Роберт Мартин - Чистый Agile. Основы гибкости

Методологии и методы — как дополнительное колесико в детском велосипеде: они хороши поначалу. Как и в случае с ребенком, который учится кататься на велосипеде, такие колесики помогут научиться безопасно и легко кататься. Когда ребенок становится увереннее, мы поднимаем колесики, чтобы он мог потренироваться держать равновесие. Потом убираем одно из дополнительных колесиков. А за ним и другое.

Теперь ребенок может кататься без посторонней помощи. Но если мы слишком сильно сосредоточимся на важности тренировочных колес и не будем их долго убирать, ребенок привыкнет к ним и не захочет без них кататься. Чрезмерное внимание к методологии или набору методов отвлекает команды и организации от их действительных целей. Цель — научить ребенка ездить на велосипеде, а не внедрить тренировочные колеса.

Джим Хайсмит в своей книге Agile Project Management: Creating Innovative Products пишет: «Принципы без методов — ноль без палочки, в то время как методы без принципов, как правило, заучивают механически, без лишних раздумий. Принципы направляют методы. Методы воплощают принципы. Они идут рука об руку» [70] Highsmith J. Agile Project Management: Creating Innovative Products, 2nd ed. Boston, Massachusetts: Addison-Wesley, 2009. P. 85. . Хотя методологии и методы являются средством для достижения цели, мы не должны преуменьшать их важность. Профессионалов определяют по тому, как они работают. Мы не можем заявлять, что у нас есть какие-то принципы и ценности, если наши методы работы не согласуются с ними.

Хорошие специалисты могут точно сказать, как будут вести работу при тех или иных обстоятельствах. Они владеют широким набором методов и могут их применять в зависимости от потребностей.

В мастерстве разработки нет методов. Скорее оно способствует вечному поиску лучших методов и способов работы. Хорошие методы хороши до тех пор, пока мы не обнаружим новые, которые придут им на замену. Закрепление определенных методов за мастерством разработки ПО ослабило бы это мастерство с появлением новых методов. Но это не значит, что международное сообщество мастеров разработки не советует применять никакие методы. Наоборот, со времени создания в 2008 году и по сей день сообщество признает экстремальное программирование лучшим набором методов Agile для разработки ПО.

Разработка через тестирование, рефакторинг, простота проектирования, непрерывная интеграция и парное программирование высоко ценятся в сообществе мастеров разработки ПО, но это методы экстремального программирования, а не мастеров. И есть не только эти методы. Сообщество мастеров также одобряет принципы чистого кода и SOLID. Оно одобряет небольшие внесения изменений, небольшие частые релизы и непрерывную доставку. Оно одобряет модульность в проектировании ПО и автоматизацию, которая избавит от ручной и однообразной работы. И одобряет любые методы, которые повышают производительность, снижают риски и помогают произвести полезное, надежное и гибкое программное обеспечение.

Мастерство разработки ПО — это не только технические методы, инжиниринг и самосовершенствование. Это также профессионализм и помощь клиентам в достижении их деловых целей. И это как раз та область, где Agile, бережливое производство (Lean) и мастерство разработки прекрасно сочетаются. У всех трех концепций схожие цели, но они рассматривают проблему с разных, но одинаково важных точек зрения, которые друг друга дополняют.

Распространенная ошибка в сообществах Agile и мастеров разработки ПО в том, что они больше внимания уделяют методам, а не ценностям, которые лежат в основе этих методов. Возьмем, к примеру, разработку через тестирование. Один из наиболее частых вопросов, которые задаются в сообществах мастеров разработки ПО: «Как убедить моего руководителя/коллегу/команду применять разработку через тестирование?» Так вопрос ставить нельзя. Проблема здесь в том, что мы скорее предлагаем решение, чем принимаем проблему. Никто не станет работать по-другому, если не показать им ценности.

Вместо того чтобы силком тянуть к разработке через тестирование, можно найти согласие в том, что полезно будет сократить общее время тестирования программы. Сколько времени сегодня занимает тестирование? Два часа? Два дня? Две недели? Сколько людей этим занимается?

А что, если сократить время до 20 минут? Двух минут? Или даже 2 секунд? А что, если бы могли проводить его в любое время нажатием на кнопку? Даст ли это нам хорошую отдачу от вложений? Станет ли наша жизнь от этого легче? Сможем ли мы выпускать надежное ПО быстрее?

Если мы соглашаемся в том, что ответ будет «да», то можно уже говорить о методах, которые помогут нам достичь наших целей. Разработка через тестирование станет в этом случае естественным выбором. Тех, кому не нравится разработка через тестирование, мы спросим, какой метод они предпочитают. Какой метод, который позволит достичь поставленных целей с тем же или лучшим успехом, они смогут предложить?

При обсуждении методов необходимо в первую очередь договориться о целях. Единственное, чего не нужно допускать, — отказ от метода без предложения лучшей альтернативы.

Обсуждение методов должно проходить на нужном уровне с компетентными людьми. Если мы хотим применять методы, которые улучшат сотрудничество в деловой и технологической областях, нам нужно вовлечь в обсуждение представителей этих областей. Если разработчики обсуждают методы, которые им понадобятся для улучшения процесса создания ПО, тогда не следует приглашать к обсуждению посторонних. Представителей бизнеса стоит привлекать, только если изменения значительно коснутся стоимости или длительности проекта.

Существует разница между сменой монолитной архитектуры на микросервисную и разработкой через тестирование. Первое весьма значительно повлияет на стоимость и длительность проекта, последнее же не повлияет, пока разработчики не столкнутся с проблемами в области технического мастерства. Бизнесу не должно быть важно, автоматизируют ли разработчики свои тесты или нет. Это должно быть даже менее важно, чем то, написаны автоматизированные тесты до или после написания готового кода. Бизнесу лучше позаботиться о том, чтобы время от возникновения деловых идей до выхода программного обеспечения в производство постепенно уменьшалось. Сокращение количества средств и времени, потраченного на доработку (ошибки, ручная работа, такая как тестирование, развертывание и мониторинг производства), также является задачей бизнеса, в решении которой должны помогать команды разработчиков. Снижение затрат на эксперименты — тоже задача бизнеса. Эксперименты стоят очень дорого, когда ПО не является модульным и легко тестируемым. Представители бизнеса и разработчики могут вести разговоры о деловых ценностях, но не о технических методах.