ХР дает ясный ответ на этот вопрос – применять инкрементальное (пошаговое) проектирование. Когда команда создает простые компоненты и каждый из них выполняет что-то одно, это позволяет комбинировать их множеством различных способов. Рефакторинг и разработка через тестирование помогают поддерживать эти компоненты в максимально независимом состоянии.

Иными словами, отделенные, независимые компоненты создают варианты.

При возникновении новой идеи или обнаружении нового требования, если компоненты крупные и между ними много зависимостей, то команда потратит большую часть своих усилий на разделение этого кода путем «стрельбы дробью». Но команда XP, использующая инкрементальную архитектуру, сохраняет свои варианты открытыми. Она добавит только минимальный код, который должен удовлетворять новым требованиям, проведет рефакторинг и продолжит использовать разработку через тестирование. Команда прибавит минимум зависимостей, что позволит ей в дальнейшем сохранить максимум открытых вариантов.

Так XP и scrum-команды практикуют вариантное мышление в том, как они планируют свою работу и проектируют ПО. Но есть ли что-то такое, что команда может сделать, чтобы явно создавать и применять варианты в своем проекте?

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

Допустим, в команде есть бизнес-проблема, которая имеет ряд возможных технических решений, – например, наша scrum-команда обнаружила во время спринта, что она не нуждается в DBA для внесения изменений в базу данных. Как быть, если команда не знает, какое решение лучше – объектно ориентированное или с использованием базы данных? Это очень распространенная ситуация в проектах разработки программного обеспечения. Часто неизвестно, какое из двух решений лучше, пока команда по крайней мере не начнет создавать оба.

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

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

Другой пример разработки на основе установок – регулярно используемое командами А/Б-тестирование. Такая практика часто встречается при создании пользовательских интерфейсов и улучшении работы пользователей, ее с большим успехом реализовывали в Amazon, Microsoft и других компаниях. При A/Б-тестировании команда создает два или более решения – например, два различных макета или варианта решения для веб-интерфейса (А– и Б-макеты). Команда будет случайным образом передавать A– либо Б-вариант бета-тестерам – или, в некоторых проектах, реальным пользователям – и контролировать результаты тестирования и показатели успеха. Компании неоднократно убеждались: хотя такой подход требует больше времени и усилий, чтобы создать два комплексных решения, он хорошо окупается в долгосрочной перспективе, поскольку появляется возможность провести сравнительные замеры и доказать, что одно из решений успешнее другого. Более того, зачастую менее удачное решение тоже приносит пользу, например функции, которые разработчики позднее включат в конечный продукт.

Эти примеры показывают, как команды применяют разработку на основе установок и вариантное мышление. Но важнее другое: они демонстрируют, как идеи, уже знакомые вам по Scrum и XP, дают основу для изучения Lean и бережливого мышления.

Ключевые моменты

Lean (или бережливое мышление) – это название образа мыслей. Подобно другим agile-методам, оно имеет свои ценности, помогающие понять и принять его.

Lean – мышление, а не методика, поэтому в нем не представлены практики, которые помогут выполнять проекты.

Есть ценности, общие для бережливого мышления и более широкого круга agile-решений: как можно более позднее принятие решений (или принятие решений в последний ответственный момент) и усиление обучения (при помощи обратной связи и итерации).

Lean-ценность «расширение прав и возможностей команды» очень похожа на scrum-ценность «сосредоточенность» и XP-ценность «энергичная работа».

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

Когда команда использует разработку на основе установок, она исследует более одного варианта решений за один раз и выбирает лучший – например, когда она выполняет А/Б-тестирование для проверки нескольких параметров пользовательского интерфейса на выборке пользователей, выбирает функции, работающие лучше всего.

Описание: команда, работающая над созданием приложения для камеры мобильного телефона в организации, купленной большой и многопрофильной интернет-компанией

Кэтрин – первый разработчик

Тимати – второй разработчик

Дэн – их руководитель

Акт I. И вот еще что…