После длительной паузы я бы хотел поделиться подходом, который мы применяем при быстрой разработке MVP или же просто на старте нового проекта для заказчиков, желающих ускорить свой бизнес с помощью аккуратных, планомерных и непрекращающихся нововведений с использованием программной автоматизации.
Я думаю, что многие delivery manager's согласятся, что картину, происходящую при реализации проектов в рамках ограниченного времени и бюджета, а также запроса на real business value от бизнеса, можно описать, как фигурное катание по кромке очень тонкого льда.
В нашей компании мы выработали следующие принципы, которые нам очень помогают:
- Scrum – хорошо, но DSMS Atern – лучше;
- Plan & only then act;
- Behaviour Driven Development;
- Deliver ASAP;
- Визуализация и документация лучше текста.
Начнем с самой любимой диаграммы, чтобы увидеть одни из важных принципов в Atern DSDM.
- Время реализации и стоимость зафиксированы.
- Качество превыше полнофункциональных возможностей системы.
Для обеспечения выдачи реально business value потребуется:
- Фокусироваться на нуждах бизнеса;
- Делать поставку во время;
- Максимально эффективно взаимодействовать;
- Никогда не идти на компромиссы по качеству.
Следующая диаграмма помогает соблюдать принцип Plan first & then act.
Сначала мы проверяем реализуемость/необходимость реализации всей конструкции целиком:
- уточняем нужды бизнеса;
- делаем замер business value, который будуе действительно нужен с вовлечением людей из бизнеса;
- делаем все в соответствии с методиками DSDM.
- согласовываем функционал и планы;
- создаем прототип, тестируем систему в целом;
- анализируем прототип совместно с бизнесом.
- согласование функциональности прототипа и сроков;
- создание прототипа для повседневного пользования, после анализ прототипа с бизнесом, сбор пользовательского мнения, тест логи.
- согласование функциональности с конечными пользователями;
- обучение пользователей системе;
- реализация системы;
- анализ рынка.
Time boxing
Достигаем главные цели – разрабатываем в сроки, бюджет, с высоким качеством.
MoSCoW
Методика приоретизации в соответствии со следующими приоритетами:
MUST – требование ДОЛЖНО удовлетворять бизнес-нуждам.
SHOULD – СЛЕДУЕТ ли выполнять это требование, если от него не зависит успех проекта.
COULD – НУЖНО ли оставить это требование, если оно не действует на деловую потребность проекта.
WON'T – МОЖНО ли отложить выполнение требования, если ещё есть время.
Прототипирование
Создаем прототипы, даем реальным пользователям, получаем фидбек и даем реально тестировать и щупать продукт заранее.
Тестирование
Тестируем всегда, после каждой итерации, только благодаря тестированию сможем получить высокое качество.
Моделирование
Мои постоянные читатели (если таковые имеются) помнят, что визуализация крайне необходима. Визуализируем все диаграммами для упрощения восприятия информации (см. статью
В завершение хочется упомянуть о принципе Behaviour Driven Development.
ВDD – это не Silver bullet, это ответвление TDD, но «тест» заменен на «должен», в итоге формируется мышление, ориентированное на проверку действительно необходимой функциональности. Сначала пишем тесты на проверку спецификации, далее уже реализуем программный код самой системы.
В итоге получается, что мы вплотную работаем с заказчиком, на всех стадиях подкрепляем работу прототипом, трудимся преследуя высокие стандарты качества и закрываем действительно необходимые бизнесу требования в соответствии с временными условиями, а также бюджетом.