Антихрупкость в IT - стр. 14

Результат работы нужно повесить у всех на виду. Если команда распределённая, то следует выложить Impact Mapping в общую базу знаний или повесить перед экраном, который видят все участники разработки. Главная цель – обеспечить видимость и достижимость задач, ведь мы опираемся на них при работе над проектом[18].

Даже когда все согласились с целями проекта и способами их достижения, заказчик может добавить в проект фичу, которая ему очень нравится – pet feature. Мы можем отфильтровать её через цели, показать, что эта фича никаким образом не приведёт нас к достижению целей.

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

Обратите внимание, что мы двигаемся через прилаживание новых требований. Все входящие задачи должны пройти проверку на соответствие целям и должны «зацепиться» за одну из веток Impact Map. Такой подход даёт возможность обсуждать идеи: участники могут попробовать добавить свою задачу, видят проблему или ошибку в формулировке или в месте, куда они хотели её добавить, пробуют переформулировать и раскрывают новые грани своей идеи. Именно это обеспечивает антихрупкость нашей системы, потому что какие бы неожиданные требования или изменения не пришли извне, мы знаем, как их обработать и приладить к текущему видению.

Какая колонка идёт последней на вашей Kanban-доске? Могу поспорить, что это Release, Deploy, Done или что-то в этом духе. Последней колонкой на доске должна стать – «Проверка достижения цели». Недостаточно просто залить фичу на сервер, нам нужно проверить, как эта фича повлияла на продвижение к цели.