Эволюционный дизайн

Предлагаем вашему вниманию перевод блог-поста Джошуа Кириевски

Что можно считать самой ценной практикой аджайла?

Определенно, эволюционный дизайн.

Именно эта практика лучше других позволяет управлять рисками при разработке программного обеспечения.

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

Почему же тогда не так много людей пользуются эволюционным дизайном?

Возможно, так происходит потому, что они не понимают его сути и ценности?

Пришло время изменить это.

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

Примитивное целое — это полностью собранная, но не доработанная до конца версия целого [продукта].

Присутствуют все основные части, но они примитивные.

Примитивное целое не обладает всеми качествами законченного [продукта], но когда-то оно достигнет этого состояния.

И, хотя вы можете представить себе изумительный готовый продукт или фичу, начинать нужно с примитивной версии.

Давайте посмотрим, как гитара на изображении ниже из примитивного целого превращается в законченный инструмент.

Подождите, разве на первой картинке гитара?!

У нее только две струны, нет ни колков, ни ладов, ни порожков, и даже звукового отверстия нет!

Именно это нам и нужно: примитивная отправная точка, недоработанное целое (а не куча отдельных деталей для гитары), которое эволюционирует в зависимости от потребностей, приоритетов, рисков и фидбека.

Потребуется определенный навык, чтобы увидеть в описании полностью функционирующей фичи или продукта примитивное целое.

Создавая примитивное целое для фичи или продукта, нужно уметь говорить «нет».

Допустим, мы разрабатываем систему для расчета заработной платы. В ранних итерациях в ней не будет учета выплат по больничным, отпускам и отгулам, а также федеральных или местных налогов.

В первой версии плагина мы будем использовать старый стек технологий, без новых языков программирования, без новой модели потоковой передачи событий и без обновления до новейших протокола WebSockets (что потребует в дальнейшем доработки и тестирования огромного количества “боевой” инфраструктуры).

Если вы говорите «нет» каким-то характеристикам на ранних этапах, это не значит, что вы создаете ерунду.

Результаты первых итераций — это не конечная версия.

Вы поставляете продукт тогда, когда вы будете готовы его поставить.

Создание примитивного целого на ранних этапах помогает нам управлять рисками при взаимодействии и интеграции.

Почему это важно?

Потому что разработка программного обеспечения часто сопряжена с такими рисками.

Я видел опытных разработчиков, которые создавали сложные, хорошо продуманные части целого, не интегрируя их в рабочие решения, что приводило к проблемам интеграции впоследствии и задерживало поставку на недели.

Я видел узкоспециализированные команды по управлению продуктом, фронтенд-команды, команды БД, бэкенд-команды, QA-, UX-команды и т. д., которые сталкивались с серьезными проблемами координации и интеграции просто потому, что они управляли только своими компонентными бэклогами и не организовывались для развития разработки чего-либо вместе.

Кросс-функциональная команда или группа команд, в которых представлены все специальности, необходимые для планирования и разработки продукта, менее подвержены таким рискам.

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

Лучше осуществлять интеграцию и совместно работать над продуктом или фичей так часто, как это возможно. Существует соответствующая аджайл-практика, которая называется «непрерывная интеграция».

Представьте, что у вас есть пять команд, которые совместно работают над одним продуктом.

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

И все пять команд должны осуществлять непрерывную интеграцию для того, чтобы создать работающее примитивное целое.

Чем дольше вы откладываете интеграцию результатов работы каждой из команд, тем более болезненно она будет проходить.

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

Десять лет назад, мы с коллегами всего за месяц помогли группе из 500 человек, разделенных на 30 команд, работающих над набором приложений для контроля рабочего времени, интегрировать их работу всего через месяц после начала разработки.

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

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

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

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

Представьте, что открываете несколько совершенно новых зданий на территории университета, но вы не прокладываете к ним дорожки.

В 1970-х Кристофер Александр и его команда поступили таким образом в Университете штата Орегон.

Студенты и преподаватели, приступив к занятиям в новых зданиях, конечно же протоптали новые тропинки так, как им было удобно.

Архитекторы увидели, где именно появляются тропинки и смогли спокойно их замостить.

Такой подход — противоположность предварительного планирования.

Если на ранних этапах вы даете клиентам доступ к продукту или фиче, это позволяет понять их потребности быстрее.

Недавно мы выпустили бета-версию плагина для нескольких клиентов.

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

После быстрого выпуска плагина мы узнали, что его невозможно использовать без поддержки прокси.

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

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

Как я писал в начале, это самая ценная аджайл-практика.

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

Она помогает понять, что нужно нашим пользователям.

Почему же этой практикой не пользуются аджайл-команды и организации, которые я посещаю по всему миру?

Не потому ли, что популярные фреймворки (например, Скрам) не упоминают ее явно?

Или, может быть, потому что Аджайл Манифест слишком неявно на нее указывает?

Или потому что ее сложно внедрить, поскольку это требует слишком значительных организационных изменений?

Мне было бы интересно узнать, что думаете вы.

Действительно ли эволюционный дизайн — это самая ценная практика аджайла?

И почему она так слабо распространена в отрасли?

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

Спасибо Alex Freire, Tim Ottinger и Woody Zuill за ревью и предложения по тексту.

Большое спасибо Артёму Кротову за ревью перевода.

Также рекомендуем ознакомиться с разделом Архитектура и Проектирование на сайте less.works