Управление ИТ-проектами с использованием DSDM Agile Project Framework
© Dynamic Systems Development Method Limited 2014
В первой части мы начали подбирать подходящий инструмент для разработки программного продукта в проекте под управлением PRINCE2® и даже сформулировали для этого высокоуровневые требования. DSDM Agile Project Framework выбран в качестве примера не зря. Во-первых, это детально проработанный подход с развитой ролевой моделью (чего явно не хватает в Scrum), а, во-вторых, в нём уделяется достаточное внимание взаимодействию между уровнями управления (что вообще редкость). То есть, половина наших требований с ходу выполняется, посмотрим, что там с остальными.
Необходимо сразу предупредить, что DSDM – это настоящий, классический Agile. Не нужно даже пытаться использовать его просто потому, что это внезапно стало модно, или руководство требует срочно внедрить "передовые практики" разработки. Понятно, такое бывает нередко, но тогда лучше рассмотреть менее формализованную технику, чтобы ваш очередной «fragile agile» [1] смотрелся не так вызывающе.
Подход Agile, как и любая другая методология разработки программного обеспечения, имеет более-менее формальные критерии применения, из которых особенно важны два:
Да, именно в такой последовательности. Если заказчик НЕ ГОТОВ взаимодействовать, то об это разобьется agile любой твёрдости, несмотря на глубину проработки методики, квалификацию менеджеров, таланты разработчиков, удобство коворкинга и даже тимбилдинг на тропических островах. Примеров этому масса, некоторые широко известны, но не будем сейчас о грустном.
С требованиями всё еще проще, если разработчик в состоянии вытащить из заказчика все требования, формализовать их в виде технического задания и сдать готовый продукт, по утвержденной ПМИ (программа и методика испытаний), то нет вообще никакого смысла отступать от классической каскадной (Waterfall) модели, пусть даже реализованной в рамках устаревшего ГОСТ 19.301-79.
Если эти два критерия выполняются (быстрый старт и быстрые результаты – это бонусы, которых может и не быть), то можно начинать смотреть в сторону гибких подходов, среди которых DSDM не без оснований считается одним из наиболее глубоко проработанных. Кроме того, Agile Manifesto был подписан в 2001 году последователями следующих методов: Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature driven development, Pragmatic Programming, то есть, авторы DSDM стояли у истоков базовых принципов гибкой разработки.
Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) основан на концепции быстрой разработки приложений (Rapid Application Development, RAD). Особенностью DSDM является итеративный и инкрементный подход, который предполагает активное и продолжительное участие в процессе будущих пользователей. Основная цель в данном случае – сдать готовый проект вовремя и уложиться в бюджет, постоянно управляя изменениями требований во время разработки. Отличие DSDM от традиционных моделей (Waterfall, V-model etc.) схематически показано на рисунке ниже.
© Dynamic Systems Development Method Limited 2014
В отличие от традиционных моделей, DSDM фиксирует время и затраты проекта за счет управления его охватом, что характерно, без ущерба для качества продукта. Выглядит красиво, но, естественно, сразу возникают сомнения, за счет каких интересных инструментов этого можно достичь. Легко догадаться, что дело в очень развитой модели управления требованиями, хотя бы потому, что объектов для управления остаётся не так уж много.
Здесь и далее мы будем рассматривать текущую редакцию метода под названием The DSDM Agile Project Framework (2014 Onwards).
Для управления проектом на уровне команды DSDM Agile Project Framework предлагает следующие техники, позволяющие регулировать объём работ в проекте путем грамотного управления требованиями и их реализацией:
Наибольшую важность представляют первые две, поэтому остановимся именно на них. В проекте под управлением DSDM, где сроки жёстко зафиксированы, необходимо быстро и правильно оценивать приоритет (относительную важность) работ. А поскольку подход итеративный, такая оценка должна выполняться регулярно, по мере продвижения проекта и внесения в него изменений. MoSCoW – это инструмент для понимания важности и эффективного управления требованиями, а буквы означают следующее:
Требования Must строго обязательны для продукта или его очередного инкремента. Требования Should также критичны, но они могут быть исключены из текущего инкремента продукта по объективным причинам. Требования Could не считаются критичными, но могут увеличить пользовательскую удовлетворенность. Требования Won’t наименее критичны для продукта, они могут считаться интересными и перспективными для будущих инкрементов. Объектами приоритизации также могут быть задачи, продукты (артефакты), критерии приемки и тесты, но чаще всего это требования и пользовательские истории (User Stories).
MoSCoW хорошо работает в проектах, преодолевая проблемы, свойственные другим способам. Например, использование приоритетов типа «высокий», «средний» или «низкий» сложнее, поскольку их необходимо конкретизировать, а это не всегда легко. Простые числовые значения (1,2,3, 4 и т.д.) менее эффективны по отношению к требованиями с аналогичной важностью и провоцируют продолжительные дискуссии о месте каждого элемента.
© Dynamic Systems Development Method Limited 2014
Конечно, приоритизация требований не выглядит чем-то уникальным, но в DSDM решения по отказу от реализации требований, имеющих критичность, отличную от Must, принимает команда разработчиков. Это достигается за счёт проработанной ролевой модели и эффективного разделения уровней управления проектом, которые свойственны и DSDM, и PRINCE2®.
Название второй важнейшей техники DSDM – Timeboxing – адекватно перевести на русский язык невозможно (дословно это означает упаковку определенных временных интервалов в коробки), поэтому попробуем понять общий смысл. DSDM определяет Timebox как фиксированный временной интервал, в конце которого достигается определенная цель (Objective). Эта техника даёт возможность команде разработчиков сконцентрировать усилия на достижении чего-то законченного и значимого, а не просто сильно напрячься и устать в процессе работы.
Поскольку в каждый Timebox включаются требования, ранее приоритизированные с помощью техники MoSCoW, в ходе его реализации команда создает очередной инкремент продукта, имеющий заранее определенную и легко измеримую ценность для заказчика. Часто такой инкремент называется прототипом. DSDM также даёт конкретные рекомендации относительно доли требований каждого приоритета в рамках Timebox. Например, доля требований Must не должна превышать 60% от объёма работ, что даёт возможность команде управлять охватом проекта, не ставя под угрозу сроки и бюджет.
Автор статьи: Игорь Соглаев
[1] Так в DSDM называют ситуации, когда в попытке уменьшить давление бюрократии путем непродуманного внедрения гибких подходов, организации переходят в другую крайность, которая характеризуется плохой дисциплиной, малым количеством документации и общим ощущением хаоса.