Какого цвета ваш баклог?
| September 20, 2011 | Posted by admin under Практики, Статьи |
Shane Hastie – agile coach , тренер и консультант, работающий для Software Education в Австралии и Новой Зеландии.
http://www.infoq.com/news/2010/05/what-color-backlog .
На недавней конференции SDC (Сидней и Веллингтон), Филипп Крюхтен прочел доклад “Какого цвета ваш баклог?”. В докладе говорится о необходимости сфокусироваться на архитектурно значимых аспектах программного обеспечения в Agile проектах, наряду с поставкой функциональных компонентов системы.
Крюхтен утверждает, что Agile фокусируется на принципе YAGNI (You Ain’t Gonna Need It – Вам это не понадобится), проводя рефакторинг и откладывая решения “до последнего ответственного момента”. В результате возникает риск отложить важные решения слишком далеко. В любом проекте есть ряд ключевых решений, которые необходимо принять рано, чтобы заложить основу для текущей работы. Для таких решений “последний” ответственный момент фактически очень близок к началу проекта.
Ключевые решения определяют архитектуру разрабатываемой системы. Плохое решение или отсутствие решения вообще может привести к тому, что разрабатываемая система не сможет адаптироваться к меняющимся потребностям бизнеса. Основные решения по архитектуре системы необходимо сделать в начале процесса разработки.
Крюхтен утверждает, что многие Agile проекты фокусируются на функциональных потребностях (выраженных в виде User Stories) и пренебрегают архитектурными аспектами с безответственным – “мы можем пересмотреть это позже” – отношением. Очень часто “позже” перерастает в “уже слишком поздно”.
Он приводит пример финансовой системы, для которой использован Agile.
Он не рекомендует возврат к большому этапу дизайна в начале построения системы. Крюхтен предлагает обратить пристальное внимание на ключевые аспекты качества системы и учитывать архитектуру системы наряду с ее функциональностью.Архитектура зависит от нефункциональных требований и требований к качеству продукта: производительности, надежности, мощности, удобству обслуживания, безопасности, удобству использования и тестируемости.Эти требования должны быть определены с самого начала, а не переработаны в впоследствии.
Он признает важность демонстрировать прогресс – мы не хотим, чтобы первые несколько итераций команда разработчиков упорно трудилась только над невидимой пользователю внутренней структурой. Крюхтен предлагает внести архитектурные требования в план релиза продукта. Мы продемонстрирум прогресс и через рост функциональности, и в удовлетворении требований по качеству системы. Так, например, результатом первой итерации может быть только один экран ввода. Зато нагрузочное тестирование покажет, что этот компонент системы будет справляться с ожидаемым количеством запросов в реальной среде.
Он предлагает технику, которая сделает работу прозрачной и покажет, что архитектурные потребности учтены и приоритезированы наряду с видимой функциональностью. Крюхтен предлагает применить концепцию цветового кодирования к элементам в баклоге продукта.
Он предлагает использовать четыре цвета для работы с баклогом:
- Зеленый – функциональные пользоваельские истории (User Stories)
- Желтый – архитектурная инфраструктура, которая поддерживает требования к качеству
- Красный – дефекты, которые выявлены и должны быть исправлены
- Черный – технический долг, который нарастает по мере построения продукта -отложенные ключевые решения или плохо сделанная работа
Рис: Цвета в баклоге
Обратите внимание на два измерения – положительное значение против отрицательного, и видимые функции против невидимых.
Зеленые компоненты – это видимые фичи, наиболее часто встречающиеся в баклоге – пользовательские истории. Они будут видны пользователям конечного продукта.
Желтые кусочки работы невидимы для пользователей, но они имеют большую ценность для всего продукта. Это работа по таким областям как:
- Архитектура
- Инфраструктура
- Общие элементы
- Библиотеки
- Платформы
- Создание reusable компонентов
Желтые элементы (ценная, но невидимая работа) должны быть явно прописаны в баклоге продукта и планах релизов. Их нужно приоритезировать так же, как и видимые фичи.
Красные части (видимые дефекты) добавляются по мере разработки продукта. В идеальном мире будет очень мало красных элементов, но наивно полагать, что их не будет совсем.
Черные элементы (технический долг) появляются когда желтые элементы игнорируются. Технический долг может также быть итогом предыдущих работ для проектов на уже существующей кодовой базе.
При построении первоначального плана релиза важно учитывать как зеленые, так и желтые элементы. Узкая направленность на видимых фичах может привести к появлению замечательно выглядящего, но плохо масштабируемого или небезопасного продукта. Вместе с тем, упор только на желтые элементы возвращает нас к BDUF ( big up front design – большой первоначальный дизайн) и задерживает поставку полезной видимой функциональности, что в конечном счете может привести к потере заказчика.
Крюхтен предлагает строить план релиза, который как “молния-застежка” объединяет функциональные и архитектурные компоненты.
Рис: Планируйте ваши релизы, чтобы они объединяли видимые и невидимые элементы как “молния-застежка”
Красные и черные элементы (видимые дефекты и технический долг) не будут появляться в плане релиза, но они сильно влияют на скорость (Velocity) выполнения проекта.
Дефекты, по мере возможности, исправляются как только они обнаружены. Неисправленные дефекты “гноятся” (так в тексте – прим. переводчика). Позднее обращение к дефектам затрудняет их исправление. После нескольких итераций команда поймет, с какой скоростью появляются дефекты и сможет отрегулировать планируемую скорость (Velocity), чтобы дефекты исправлялись как можно раньше.
При планировании работы нужно учитывать существующий технический долг. Унаследованный код системы скорее всего имеет скрытые дефекты. Его труднее рефакторить. Поэтому, опять же, скорость поставки новой функциональности будет снижена из-за качества старого кода.
При создании нового продукта нет первоначального технического долга, но есть риск его возникновения. Отсрочка исправления дефектов, игнорирование желтых элементов, откладывание ключевых решений до “последнего ответственного момента” – все это приводит к накоплению технического долга и снижению скорости поставки.
Важно сделать дефекты и технический долг видимыми для проектной команды. Отсюда следует концепция цветового кодирования баклога. В баклоге появляются новые истории, соответствующие дефектам и предстоящей работе по “оплате” технического долга.
Крюхтен настоятельно рекомендует отмечать цветом, является ли эта работа новой фичей, архитектурным компонентом, дефектом или техническим долгом.
Выделяя цвета в баклоге и делая все четыре аспекта разработки продукта отчетливо видимыми можно достичь более реалистичного планирования и отслеживания проекта.
Какие цвета в вашем баклоге и какие методы вы используете, чтобы сделать всю работу видимой?
-
Guest
