Чистый Agile. Основы гибкости - [63]
Хорошие специалисты могут точно сказать, как будут вести работу при тех или иных обстоятельствах. Они владеют широким набором методов и могут их применять в зависимости от потребностей.
Есть ли в мастерстве разработки методы?
В мастерстве разработки нет методов. Скорее оно способствует вечному поиску лучших методов и способов работы. Хорошие методы хороши до тех пор, пока мы не обнаружим новые, которые придут им на замену. Закрепление определенных методов за мастерством разработки ПО ослабило бы это мастерство с появлением новых методов. Но это не значит, что международное сообщество мастеров разработки не советует применять никакие методы. Наоборот, со времени создания в 2008 году и по сей день сообщество признает экстремальное программирование лучшим набором методов Agile для разработки ПО.
Разработка через тестирование, рефакторинг, простота проектирования, непрерывная интеграция и парное программирование высоко ценятся в сообществе мастеров разработки ПО, но это методы экстремального программирования, а не мастеров. И есть не только эти методы. Сообщество мастеров также одобряет принципы чистого кода и SOLID. Оно одобряет небольшие внесения изменений, небольшие частые релизы и непрерывную доставку. Оно одобряет модульность в проектировании ПО и автоматизацию, которая избавит от ручной и однообразной работы. И одобряет любые методы, которые повышают производительность, снижают риски и помогают произвести полезное, надежное и гибкое программное обеспечение.
Мастерство разработки ПО — это не только технические методы, инжиниринг и самосовершенствование. Это также профессионализм и помощь клиентам в достижении их деловых целей. И это как раз та область, где Agile, бережливое производство (Lean) и мастерство разработки прекрасно сочетаются. У всех трех концепций схожие цели, но они рассматривают проблему с разных, но одинаково важных точек зрения, которые друг друга дополняют.
Сосредоточьтесь на ценностях, а не на методе
Распространенная ошибка в сообществах Agile и мастеров разработки ПО в том, что они больше внимания уделяют методам, а не ценностям, которые лежат в основе этих методов. Возьмем, к примеру, разработку через тестирование. Один из наиболее частых вопросов, которые задаются в сообществах мастеров разработки ПО: «Как убедить моего руководителя/коллегу/команду применять разработку через тестирование?» Так вопрос ставить нельзя. Проблема здесь в том, что мы скорее предлагаем решение, чем принимаем проблему. Никто не станет работать по-другому, если не показать им ценности.
Вместо того чтобы силком тянуть к разработке через тестирование, можно найти согласие в том, что полезно будет сократить общее время тестирования программы. Сколько времени сегодня занимает тестирование? Два часа? Два дня? Две недели? Сколько людей этим занимается?
А что, если сократить время до 20 минут? Двух минут? Или даже 2 секунд? А что, если бы могли проводить его в любое время нажатием на кнопку? Даст ли это нам хорошую отдачу от вложений? Станет ли наша жизнь от этого легче? Сможем ли мы выпускать надежное ПО быстрее?
Если мы соглашаемся в том, что ответ будет «да», то можно уже говорить о методах, которые помогут нам достичь наших целей. Разработка через тестирование станет в этом случае естественным выбором. Тех, кому не нравится разработка через тестирование, мы спросим, какой метод они предпочитают. Какой метод, который позволит достичь поставленных целей с тем же или лучшим успехом, они смогут предложить?
При обсуждении методов необходимо в первую очередь договориться о целях. Единственное, чего не нужно допускать, — отказ от метода без предложения лучшей альтернативы.
Обсуждение методов
Обсуждение методов должно проходить на нужном уровне с компетентными людьми. Если мы хотим применять методы, которые улучшат сотрудничество в деловой и технологической областях, нам нужно вовлечь в обсуждение представителей этих областей. Если разработчики обсуждают методы, которые им понадобятся для улучшения процесса создания ПО, тогда не следует приглашать к обсуждению посторонних. Представителей бизнеса стоит привлекать, только если изменения значительно коснутся стоимости или длительности проекта.
Существует разница между сменой монолитной архитектуры на микросервисную и разработкой через тестирование. Первое весьма значительно повлияет на стоимость и длительность проекта, последнее же не повлияет, пока разработчики не столкнутся с проблемами в области технического мастерства. Бизнесу не должно быть важно, автоматизируют ли разработчики свои тесты или нет. Это должно быть даже менее важно, чем то, написаны автоматизированные тесты до или после написания готового кода. Бизнесу лучше позаботиться о том, чтобы время от возникновения деловых идей до выхода программного обеспечения в производство постепенно уменьшалось. Сокращение количества средств и времени, потраченного на доработку (ошибки, ручная работа, такая как тестирование, развертывание и мониторинг производства), также является задачей бизнеса, в решении которой должны помогать команды разработчиков. Снижение затрат на эксперименты — тоже задача бизнеса. Эксперименты стоят очень дорого, когда ПО не является модульным и легко тестируемым. Представители бизнеса и разработчики могут вести разговоры о деловых ценностях, но не о технических методах.
