Если вы хоть раз объясняли команде то, как работа итерациями позволяет регулярно поставлять новый и важный функционал, то наверняка не раз сталкивались с простым и резонным вопросом: “А что делать с архитектурой?”.

Про анти-паттерн BUFD (Big Up Front Design) можем не говорить. Долгая фаза создания “архитектуры” редко окупается полностью, и для бизнеса тяжело объяснить первые итерации, в которых не видно новых функций. Заказчик просто скажет: “Time to Market и всякое такое, а они мне тут какую-то архитектуру парят – вы что, разве не профессионалы”. Ну, или что-то в этом роде 🙂

Можно, конечно, использовать принцип YAGNI (You Ain’t Gonna Need It), т.е. не делать того, что не относится к функциям в разработке и развивать систему по чуть-чуть.  С другой стороны, как только наступит первый выпуск “в жизнь”, то отложенные решения могут вылезти боком в виде неучтенных проблем с производительностью и масштабируемостью. Опять же, если откладывать некоторые решения “на потом”, то мы автоматически увеличиваем цену разработки той функции, где это решение понадобится. Конечно, есть вероятность, что “пронесет”, хотя риск добавочной стоимости на поздних этапах проекта все равно велик.

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

Один из простых и надежных советов: делайте видимыми все виды работ. Это поможет вам своевременно принимать решения и отслеживать ситуацию целиком, без неожиданностей в конце проекта. Главный вопрос КАК?

Недавно на InfoQ была опубликована интересная статья “What Color is your Backlog?“, где рассказывается о работах канадского профессора Филипа Крухтена (Philippe Kruchten). Он предлагает простую технику раскрашивания в разные цвета элементов бэклога разного типа. Это позволит сделать видимым все виды работ и правильно расставить приоритеты.
Вам понадобятся всего четыре цвета:

• Зеленый – Features – Новые Функции, истории пользователя и  т.п.
• Желтый – Architectural infrastructure – Архитектурные Решения, которые поддерживают качество, надежность и иногда удешевляют разработку новых функций.
• Красный – Defects – Дефекты найденные и требующие дополнительного внимания.
• Черный – Technical Debt – Технический Долг, который накопился из-за “быстрых” решений

Теперь посмотрим на эти элементы внимательно: все они имеют “Цену Реализации“, т.е. время или пункты, которое нужно на них потратить. В тоже время, “Выгода” от реализации того или иного типа может быть как положительной (Новые Функции и Архитектурные Решения), так и отрицательной (Дефекты, Технический Долг). Если сделать любимую всеми диаграмму 2х2, то получится вот такая картина:

Как видите, просто и наглядно 🙂

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

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

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