№10 Управление проектами. Гибкие методологии. Agile. Agile Unified Process (AUP). DSDM

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

Из диаграммы Гибких методологий управления мы видим все многообразие основных методологий управления. Сегодня мы поговорим о двух из них: Agile Unified Process (AUP) и DSDM. Разберем откуда появились данные методологии, когда применялись и их основные принципы.

Гибкий Унифицированный процесс (AUP)- упрощенная версия рационального унифицированного процесса, который разработал Скотт Амблер- канадский инженер-программист. В нем описывается простой и понятный подход разработки программного обеспечения бизнес-приложений с использованием гибких методов и концепций. AUP применяет гибкие методы; в их числе: разработка через тестирование, гибкое моделирование, гибкое управление изменениями и рефакторинг базы данных для повышения производительности.

В 2011 году всего лишь 1 процент всех используемых гибких методологий приходилось на AUP. Однако в 2012 году ей на смену пришла дисциплинированная гибкая поставка (DAD).

Эти этапы постоянно повторяются по мере продвижения проекта, и поэтому не существует «долгосрочного» взгляда, как во многих других методологиях.1) Начальная фаза:На начальном этапе нужно понять, какова ваша цель и чего вы хотите достичь с помощью проекта.Для того, чтобы проекты не сбивались с пути, начальная фаза обычно довольно короткая. Если начальный этап длится слишком долго, это может указывать на то, что в начале вашего проекта была чрезмерная предварительная спецификация.2) Этап проработки:На этапе проработки вы указываете все требования проекта.Это включает в себя проектирование, планирование и создание прототипа вашего проекта до начала какой-либо работы над ним. Здесь вы оцениваете риски, уточняете требования и планируете предполагаемые сроки и бюджет вашего проекта.3) Этап строительства или производства:Этап создания полностью посвящен построению системы, которая может работать в среде бета-клиентов. Во время строительства выполняются задачи, которые включают итеративное и поэтапное создание всего проекта, пока он не будет готов для своих первых пробных клиентов.На этапе строительства вы строите и тестируете продукт. Критерии этапа разработки заключаются в том, чтобы убедиться, что выпуск является стабильным и зрелым, а все заинтересованные стороны готовы к переходу в сообщество пользователей. Если есть какие-либо проблемы с этими критериями, это может отложить переходный этап.4) Переходная фаза:На этапе перехода вы передаете свой релиз производственной команде и пользователям.Цель этого этапа — убедиться, что все заинтересованные стороны готовы к проекту, и что есть хорошее понимание того, что именно было создано и как это можно использовать совместно.

Моделирование. Выработка понимания прикладной области проекта, устройства бизнеса организации, а также выработка приемлемых решений прикладных проблем, которые требуется разрешить в рамках проекта.
Реализация. Трансформация моделей в исполнимый код, его тестирование с использованием модульных текстов.
Тестирование. Объективная оценка качества продукта. Поиск дефектов, проверка корректности спроектированной системы, а также её соответствия требованиям.
Развертывание. Планирование процедуры развертывания системы, а также исполнение плана развертывания.
Управление конфигурациями. Разграничение доступа к артефактам проекта. Контроль всех изменений и версий артефактов проекта.
Управление проектом. Направление действий всех участников проекта. Управление рисками, руководство персоналом, координация заинтересованных лиц и внешних систем с целью поставки продукта с соблюдением временных и бюджетных ограничений.
Организация среды. Обеспечение доступности для членов команды проекта всех необходимых ресурсов, инструкций, стандартов, документов, аппаратных и программных инструментов.

Основное отличие AUP от RUP- наличие итерационного процесса реализации проекта.

1. Участники процесса знают, что делают. Как многим известно, сотрудники не любят детально погружаться во множество процессов. Вместо этого они предпочитают краткие инструкции и интерактивное обучение. Применяя AUP, ты получаешь высокоуровневое описание задачи, которое знакомит тебя с основным процессом. Также имеется более детальное описание для узкоспециализированных специалистов.

2. Простота. Все процессы описываются емко и сжато.

3. Гибкость. Соответствие принципам гибкой методологии и Agile- манифесту.

4. Фокусирование на высокоуровневой деятельности. Правильное описание бизнес-процессов без детального погружения в механики.

5. Гибкость выбора инструментов работы команды.

6. Адаптация для личных нужд.

Метод разработки динамических систем (Dynamic Systems Development Method, DSDM)

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

У методологии DSDM существует множество версий и обновлений. Самая последняя, то есть наиболее актуальная из них- DSDM Atern. Слово Atern сокращение от слова Arctic Tern, что в переводе с англ. Полярная крачка. Как вы уже догадались, такое название было использовано не просто так. Полярная крачка символизирует дух последней версии DSDM методологии, например, определение приоритетов и кооперирование.

DSDM- методика разработки ПО/ ведения проекта, основанная на концепции RAD (Rapid Application Development)- быстрая разработка приложений. DSDM- итеративный, инкрементный подход, который придает особое значение пользователю/потребителю конечного продукта.

Существует 9 принципов, состоящих из 4 основных и 5 начальных точек.

Вовлечение пользователя - это основа ведения эффективного проекта, где разработчики делят с пользователями рабочее пространство и поэтому принимаемые решения будут более точными.
Команда должна быть уполномочена принимать важные для проекта решения без согласования с начальством.
Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше - это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается на последующей.
Главный критерий - как можно более быстрая поставка программного обеспечения, которое удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет потребностям рынка, менее важна, чем решение критических проблем в функционале продукта.
Разработка - итеративная и инкрементальная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения.
Любые изменения во время разработки - обратимы.
Требования устанавливаются на высоком уровне прежде, чем начнётся проект.
Тестирование интегрировано в жизненный цикл разработки.
Взаимодействие и сотрудничество между всеми участниками необходимо для его эффективности.

DSDM применим, при выполнении некоторого числа действий.

1. Организация взаимодействия между проектной командой, будущими пользователями и высшим руководством.

2. Возможность декомпозиции этапов и задач проекта для применения итеративного подхода.

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

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

2. Проекты с повышенными требованиями. Если к проекту предъявляют повышенные требования, то абсолютно очевидно, что быстро данный проект реализовать не получится и такой проект не соответствует принципу 20/80. 20 процентов требований дают 80 процентов

Исполнительный спонсор/продюсер или по-другому Чемпион проекта. Очень важная роль. У него есть возможность и обязанность распоряжаться фондами и ресурсами. У этой роли также есть полное право принимать решения.

Провидец Это тот, кто запускает проект в работу и находит первые основные требования. У провидца самое точное понимание коммерческих целей системы и проекта.
Представительный пользователь Представляет пользователей в проекте. Отвечает за то, чтобы разработчики получали достаточное число отзывов пользователей во время процесса разработки.
Пользователь-консультант Может быть любой пользователь, который представляет важную точку зрения на проект и привносит в проект знание по некоторой стороне использования продукта.
Менеджер проекта Может быть из сообщества пользователей или из области информационных технологий. Обеспечивает общее руководство проектом.
Технический координатор Ответственный за разработку архитектуры системы и контролирует качество проекта.
Лидер команды Возглавляет команду разработки и обеспечивает её эффективную работу.
Разработчик Анализирует требования к системе и моделирует её. Это подразумевает написание кода и создание прототипов..
Тестировщик Проверяет исправность проекта с технической стороны, проводя тесты. Составляет комментарии и документацию.
Секретарь Отвечает за сбор и запись требований, соглашений и решений, принятых в каждой рабочей группе.
Посредник Управляет рабочими группами.
Другие роли Бизнес-архитектор, менеджер по качеству, специалист по системной интеграции и т.д.

Таким образом, мы начали разбор гибких методов управления проектами. Рассмотрели два из них: AUP, DSDM. Выяснили откуда они произошли, основные принципы каждого метода, определили проекты, где лучше их применять и рассмотрели основных участников данный моделей.

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

focusbuilding.ru

Комплексная поддержка строительства (Исполнительная документация, Юридические услуги, Финансово-экономические услуги, Дизайн)