Полное понимание DSDM: основные принципы, области применения и успешные примеры. Как DSDM способствует эффективной агильной разработке.

Это метод создания и выпуска проектов по Agile. DSDM создали, чтобы облегчить разработку программного обеспечения и создание кода.

DSDM говорит о том, что при работе над проектом фиксируется его стоимость, качество и время. Функционал проекта может быть гибким и зависит от полезного действия продукта.

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

DSDM или метод динамической разработки систем — это метод реализации проектов по Agile. DSDM создали, чтобы облегчить разработку программного обеспечения и создание кода. Со временем метод пересмотрели и сделали универсальным: его можно использовать для разных проектов, не только для IT.

DSDM Agile Project Framework прописывает весь жизненный цикл проекта: с чего начинать, как управлять, какие принципы взять за основу, как вовлекать в работу над проектом пользователей или клиентов.

DSDM говорит о том, что при работе над проектом фиксируется его стоимость, качество и время. Функционал проекта может быть гибким и зависит от полезного действия.

Пример. Нужно запустить сайт для обучающих курсов по дизайну. Задача сайта — чтобы люди оставили свои контакты и так начали свой путь в воронке продаж. На них настроят рекламу, пришлют на емейл письма с советами по дизайну, менеджер позвонит и предложит скидку и так далее. В процессе работы стало понятно, что команда не успевает закончить проект в срок. Временем жертвовать нельзя, качеством тоже, да и стоимость проекта зафиксирована в договоре. Что делать? Выпускать сайт с ограниченным функционалом, чтобы он выполнял полезное действие по сбору контактов. Получить обратную связь по сайту, и остальные функции перенести на следующую итерацию или убрать совсем.

Чем DSDM отличается от традиционного подхода, например, Waterfall

Метод DSDM не работает если:

1. заказчик не готов активно участвовать в проекте, взаимодействовать с разработчиком;

2. известны все требования к проекту, понятно, каким должен быть результат.

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

Если есть неопределенность в требованиях к продукту и заказчик готов включиться в проект, то стоит смотреть в сторону DSDM.

• Пользователи или заказчик (или и те, и другие) участвуют в процесс разработки.
• Команда может самостоятельно принимать решения по проекту.
• Работа делится на спринты, после каждого спринта команда показывает результат или кусок готового продукта.
• Результат всегда должен быть в мире клиента или пользователя, он полезен бизнесу.
• Используют итеративный и инкрементный подход к разработке.
• Любые действия можно отменить, откатиться назад.
• Продукт постоянно и непрерывно тестируют, обратную связь используют для улучшения.

В классическом методе DSDM прописано, кто в команде за что отвечает.

Менеджер проекта руководит командой разработки, общается с заказчиком.

Провидец следит, чтобы задачи соответствовали целям бизнеса, исходили из полезного действия.

Чемпион распоряжается ресурсами проекта.

Лидер команды руководит разработчиками.

Технический координатор отвечает за архитектуру проекта.

Разработчик пишет код.

Тестировщик проверяет продукт на ошибки, баги и логику.

Проект. У компании заказывают проект для правительственной организации: базовое решение для электронных запросов и авторизации. Его нужно выполнить за 11 недель и с ограниченным бюджетом. Для работы над проектом компания решает использовать DSDM. Это позволило рассматривать проект как совместное предприятие, а не как проект, запрошенный бизнесом и «принадлежащий» IT. Это обсуждение помогло установить отличные рабочие отношения с самого начала.

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

Команда. Для членов команды разработали техническое задание, чтобы каждый четко понимал степень своих полномочий. Согласовали, как должны вести себя сотрудники при появлении серьезных проблем у проекта. Договорились, что команда разработчиков будет состоять из 6 человек, что они будут выделены на весь срок проекта. Также признали, что некоторые разработчики–специалисты будут разрабатывать модули в соответствии с определенными спецификациями, вне модели DSDM. Это не является стандартом DSDM, но этого требовала формальная структура организации.

Инкрементная поставка. Согласовали с заказчиком, что будет поставлен только один инкремент. Решили использовать итеративную разработку с интегрированным тестированием, чтобы уложиться в сжатые сроки.

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

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

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