Dynamic Systems Development Method (DSDM)

Привет!

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

Я думаю, что многие delivery manager's согласятся, что картину, происходящую при реализации проектов в рамках ограниченного времени и бюджета, а также запроса на real business value от бизнеса, можно описать, как фигурное катание по кромке очень тонкого льда.

В нашей компании мы выработали следующие принципы, которые нам очень помогают:

• Scrum – хорошо, но DSMS Atern – лучше;
• Plan & only then act;
• Behaviour Driven Development;
• Deliver ASAP;
• Визуализация и документация лучше текста.
  

За что мы любим DSDM Atern?

Начнем с самой любимой диаграммы, чтобы увидеть одни из важных принципов в Atern DSDM.

• Время реализации и стоимость зафиксированы.
• Качество превыше полнофункциональных возможностей системы.
  

Использование данных принципов дает возможность поставлять как можно быстрее надежный продукт, который может быть использован сразу же без каких-либо вопросов к качеству.
Для обеспечения выдачи реально business value потребуется:

• Фокусироваться на нуждах бизнеса;
• Делать поставку во время;
• Максимально эффективно взаимодействовать;
• Никогда не идти на компромиссы по качеству.
  

Данный подход, как показала наша практика, четко дает понять заказчику, что все идет, как и предполагалось. И что самое важное – у нас не возникало вопросов относительно согласовывания последующих этапов работ, не было никаких изысканий бюджета на решение проблем качества. Идеальная картина с тех долгом равной нулю прекрасна и Atern DSDM способствует данному состоянию проекта.

Следующая диаграмма помогает соблюдать принцип Plan first & then act.



Сначала мы проверяем реализуемость/необходимость реализации всей конструкции целиком:

• уточняем нужды бизнеса;
• делаем замер business value, который будуе действительно нужен с вовлечением людей из бизнеса;
• делаем все в соответствии с методиками DSDM.
  

Создаем высокоуровневую функциональную модель: действующий прототип и модели.

• согласовываем функционал и планы;
• создаем прототип, тестируем систему в целом;
• анализируем прототип совместно с бизнесом.
  

Далее уже занимаемся проектированием и разработкой:

• согласование функциональности прототипа и сроков;
• создание прототипа для повседневного пользования, после анализ прототипа с бизнесом, сбор пользовательского мнения, тест логи.
  

Заключительный этап реализации:

• согласование функциональности с конечными пользователями;
• обучение пользователей системе;
• реализация системы;
• анализ рынка.
  

Данные этапы работ позволяют упростить работу с Change Request’ами, произвести тестирование своевременно и поставить действительно необходимый продукт. Все это делается в соответствии с DSDM-методиками:

Time boxing
Достигаем главные цели – разрабатываем в сроки, бюджет, с высоким качеством.

MoSCoW
Методика приоретизации в соответствии со следующими приоритетами:
MUST – требование ДОЛЖНО удовлетворять бизнес-нуждам.
SHOULD – СЛЕДУЕТ ли выполнять это требование, если от него не зависит успех проекта.
COULD – НУЖНО ли оставить это требование, если оно не действует на деловую потребность проекта.
WON'T – МОЖНО ли отложить выполнение требования, если ещё есть время.

Прототипирование
Создаем прототипы, даем реальным пользователям, получаем фидбек и даем реально тестировать и щупать продукт заранее.

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

Моделирование
Мои постоянные читатели (если таковые имеются) помнят, что визуализация крайне необходима. Визуализируем все диаграммами для упрощения восприятия информации (см. статью про визуализацию в картинках).

В завершение хочется упомянуть о принципе Behaviour Driven Development.
ВDD – это не Silver bullet, это ответвление TDD, но «тест» заменен на «должен», в итоге формируется мышление, ориентированное на проверку действительно необходимой функциональности. Сначала пишем тесты на проверку спецификации, далее уже реализуем программный код самой системы.

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