Проект. У компании заказывают проект для правительственной организации: базовое решение для электронных запросов и авторизации. Его нужно выполнить за 11 недель и с ограниченным бюджетом. Для работы над проектом компания решает использовать DSDM. Это позволило рассматривать проект как совместное предприятие, а не как проект, запрошенный бизнесом и «принадлежащий» IT. Это обсуждение помогло установить отличные рабочие отношения с самого начала.
Заказчик. На встрече с заказчиком согласовывают управление проектом, направление и общие сроки. Заказчик выделяет начальный бюджет для этапа исследования и определения. Дополнительное финансирование резервируют и для стадии разработки. Заказчик согласился уделить проекту значительное время, его количество согласовали. Также договорились, что встречи, семинары и пользовательские сессии будут внесены в календарь ответственных и будут неприкосновенны.
Команда. Для членов команды разработали техническое задание, чтобы каждый четко понимал степень своих полномочий. Согласовали, как должны вести себя сотрудники при появлении серьезных проблем у проекта. Договорились, что команда разработчиков будет состоять из 6 человек, что они будут выделены на весь срок проекта. Также признали, что некоторые разработчики–специалисты будут разрабатывать модули в соответствии с определенными спецификациями, вне модели DSDM. Это не является стандартом DSDM, но этого требовала формальная структура организации.
Инкрементная поставка. Согласовали с заказчиком, что будет поставлен только один инкремент. Решили использовать итеративную разработку с интегрированным тестированием, чтобы уложиться в сжатые сроки.
Прозрачность. Ввели ежедневные командные советы, регулярные показы и ретроспективы.
Фокус на потребностях бизнеса. Сразу договорились, что не обязательно выполнять все требования, но команда расставит приоритеты, что должно быть сделано. В итоге заказчик получит рабочее решение, которое отвечает всем его требованиям.
Выполнить в срок. Вся команда согласилась, что дата окончания работ священна и не подлежит обсуждению. Заказчик согласился, что будет использовать список приоритетных требований, чтобы выделить те, которые могут быть отменены без ущерба для конечного продукта. Все согласились сосредоточиться на базовом и простом решении и при необходимости найти обходные пути, чтобы уложиться в срок.