Ение на команды Фазы проекта
 Скачать 41.05 Kb.
|
|
Содержание Введение Принципы DSDM Роли Разделение на команды Фазы проекта Заключение. Список литературы. Метод разработки динамических систем (DSDM) создана в 1994 году консорциумом из 17 британских компаний. На данный момент членами консорциума DSDM являются тысячи компаний по всему миру. Фреймворк методологии DSDM включает в себя большую часть современного знания об управлении проектами. Изначально методология DSDM была предназначена исключительно для проектов по разработке программного обеспечения, однако в настоящий момент DSDM используется и в других отраслях. Основными достоинствами фреймворка DSDM являются простота, расширяемость и доказанная высокая эффективность. При этом важно отметить, что, как и многие другие гибкие методологии, фреймворк DSDM не предназначен для управления любыми типами проектов. Основным недостатком методологии DSDM является относительно высокий барьер входа. Внедрение фреймворка DSDM не является быстрой и дешевой процедурой. Более того, внедрение DSDM может потребовать значительных изменений в культуре организации. Методология DSDM позиционируется как наиболее зрелая методология гибкой разработки программного обеспечения. Многие другие гибкие методологии сфокусированы на программировании, в то время как методология DSDM сфокусирована на организации процесса производства программного обеспечения. В этом смысле методология DSDM имеет много общих черт с методологией Scrum. 1. Принципы DSDM Перечисленные ниже принципы являются неотъемлемой частью фреймворка DSDM. Нарушение любого из этих принципов является нарушением философии DSDM и может привести к значительному росту рисков. Активное вовлечение пользователей в процесс разработки Данный принцип является наиболее важным в методологии DSDM, поскольку вовлечение пользователей в процесс разработки значительно сокращает количество ошибок в проектных решениях, что в свою очередь значительно сокращает совокупную стоимость проекта. Вместо работы с большой аудиторией пользователей, DSDM предлагает непрерывно взаимодействовать с небольшой, специально отобранной группой пользователей. Команда разработчиков может принимать решения Бюрократические препоны, такие как обязательное согласование даже мелких и рутинных решений, могут значительно затруднить продвижение проекта. Фреймворк DSDM приветствует сокращение издержек подобного рода. Одной из мер сокращения бюрократических издержек является частичная передача членам команды права принимать решения в следующих областях: • выбор функциональности на текущую итерацию; • назначение приоритетов требованиям; • любые технические детали реализации. Частая поставка результатов Частый выпуск версий гарантирует, что все ошибки будут обнаружены быстро. Чем раньше обнаружена ошибка, тем проще ее исправить. Этот принцип относится как к выпуску работоспособных версий, так и к поставке документов содержащих анализ требований, модели данных и т.п. Критерием приемлемости результатов является их соответствие бизнесу Основной целью проекта, в соответствии с методологией DSDM, является как можно более быстрая поставка программного обеспечения, способного удовлетворять потребности бизнеса. При этом методология DSDM не призывает изготавливать программное обеспечение «на коленках». Данная методология призывает сначала удовлетворить потребности бизнеса, а потом уже выполнить такие обязательные действия как, например, рефакторинг. Итеративная и инкрементальная разработка Для того, чтобы сложность управления проектом всегда оставалась на приемлемом уровне, проект разбивается на несколько итераций. В течение каждой итерации в продукт добавляется новая функциональность, до тех пор, пока потребности бизнеса не будут полностью удовлетворены. Этот принцип требует признания того факта, что любое программный продукт будет изменяться в будущем. Этот принцип может быть принят в самом начале проекта. То есть список требований к проекту тоже строиться итеративно и может изменяться. Причем чем меньше итерации, тем проще реагировать на изменения. Любые действия могут быть отменены Любое действие, выполненное в процессе разработки, может быть отменено в будущем. Разработчики часто не любят откатывать изменения, сделанные в продукте, потому что боятся потерять результаты сделанной работы. Однако методология DSDM пропагандирует разработку маленькими шагами, что гарантирует, в худшем случае, незначительность потери. Стабильность высокоуровневых требований Чрезмерная свобода в изменении требований может значительно увеличить риски. Для ограничения возможностей изменения требований в процессе разработки, методология DSDM предлагает заморозить основные высокоуровневые требования к продукту. Набор основных высокоуровневых требований к продукту выбирается и согласуется на ранних стадиях проекта. Тестирование выполняется постоянно и непрерывно Многие традиционные методологии разработки программного обеспечения откладывают тестирование на поздние стадии жизненного цикла проекта. Методология DSDM призывает начать тестирование как можно раньше. Вплоть до тестирования проектных документов на специальных семинарах с заинтересованными лицами. Взаимодействие и кооперация Методология DSDM поощряет взаимодействие между техническим персоналом и менеджментом. Взаимодействие и кооперация между всеми заинтересованными лицами являются одними из основных факторов успеха проекта. 2. Роли Методология DSDM определяет набор стандартных ролей. Каждая роль имеет свою собственную зону ответственности. Каждому члену команды сопоставляется одна из ролей. Ниже перечислены основные роли, определяемые методологи Менеджер проекта Менеджер проекта (Project Manager) обеспечивает общее руководство проектом. Провидец Провидец (Visionary) является движущей силой проекта. Провидец следит за соответствием проекта коммерческим целям и задачам. Провидцем часто является топ-менеджер, который инициировал проект. Данная роль предполагает возможность частичной занятости. Чемпион проекта Чемпион проекта (Project Champion или Executive Sponsor) обладает возможностями и обязанностями по распоряжению ресурсами и фондами, которые необходимы данному проекту. Чемпион проекта несет ответственность за принятие любых решений, связанных с проектом. Данная роль предполагает возможность частичной занятости. Лидер команды Лидер команды (Team Leader) руководит командой разработчиков и обеспечивает эффективность ее работы. Технический координатор Технический координатор (Technical Co-ordinator) отвечает за разработку архитектуры продукта. Технический координатор также отвечает общее техническое состояние проекта. Разработчик Разработчик (Developer) участвует в анализе требований, моделировании и проектировании. Очевидно, что основной обязанностью разработчика является программирование. Тестировщик Тестировщик (Tester) отвечает техническое тестирование продукта. Представительный пользователь Представительный пользователь (Ambassador User) представляет пользователей продукта. Представительный пользователь отвечает за то, чтобы разработчики вовремя получали обратную связь со стороны пользователей. Пользователь-консультант Пользователем-консультантом (Advisor User) может быть любой пользователь, представляющий значительную точку зрения на продукт. Пользователь-консультант привносит в проект знание по некоторому аспекту использования разрабатываемого продукта. Данная роль предполагает возможность частичной занятости. Секретарь Секретарь (Scribe) отвечает за протоколирование всех соглашений и решений, принятых во время семинаров. Посредник Посредник (Facilitator) отвечает за проведение семинаров. Посредник также отвечает за эффективность коммуникации между всеми членами команды. 3. Разделение на команды Методология DSDM рекомендует создавать команды небольшого размера, до шести человек (без учета руководящих персон вроде провидца и чемпиона проекта). При этом над одним проектом может работать несколько команд. Известны примеры проектов, выполненных по методологии DSDM, в которых участвовало до 150 человек. Команды могут отвечать как за реализацию некоторого набора функциональности (например, отдельная команда может отвечать за реализацию системы базы данных), так и за некоторые виды деятельности (например, в проекте могут быть две команды, отвечающие за разработку, и одна команда, отвечающая за тестирование). На рис. 15 приведена типичная структура команды разработчиков (участники проекта, имеющие полную занятость, изображены в закрашенных прямоугольниках).  Рис. 1. Типичная структура команды в DSDM 4. Фазы проекта Процесс разработки в методологии DSDM состоит из семи основных фаз. Каждая фаза имеет свои ключевые задачи и при этом может включать дополнительные задачи (особенно в случаях, когда DSDM комбинируется с другими методологиями). Методология DSDM также не специфицирует какие технические задачи должны выполняться на каждой итерации, что позволяет адаптировать DSDM к разным проектам и организациям. Ход типичного проекта по методологии DSDM изображен на рис. 1. Пред-проект Фаза пред-проекта (Pre-Project) включает в себя обсуждение возможных проектов. На этой стадии предпринимается решение о реализации проекта вообще. Изучение выполнимости проекта На фазе изучения выполнимости проекта (The Feasibility Study) анализируется возможность выполнения проекта. Исследуются возможности реализации программной системы, которая способна удовлетворить потребности бизнеса. На стадии изучения выполнимости проекта принимается решение, что проект можно реализовать (с учетом текущих ограничений времени и ресурсов). Изучение бизнес-процессов На фазе изучения бизнес-процессов (The Business Study) исследуются коммерческие аспекты проекта: • имеет ли проект коммерческую ценность? • каков будет состав участников проекта? • каков общий план реализации проекта? • какие технологии будут использоваться? Итерация разработки функциональной модели Во время итерации разработки функциональной модели (Functional Model Iteration) разрабатывается и анализируется функциональный прототип системы. Функциональный прототип показывает, какими функциями должна обладать система и как она должна их выполнять. Функциональный прототип позволяет ответить на следующие вопросы: • насколько удобно будет пользоваться готовой системой? • будет ли готовая система обладать необходимым уровнем производительности? • каков наилучший путь реализации готовой системы? Проект может включать в себя несколько итераций разработки функциональной модели. Итерация разработки Во время итерации разработки (Design and Build Iteration) продукт проектируется и разрабатывается. Причем разработка сразу ведется на должном уровне качества. Обычный проект содержит несколько итераций разработки. Заключение Принципы методологии DSDM хорошо сочетаются с основными принципами манифеста гибких технологий разработки программного обеспечения. В методологии DSDM высоко ценится индивидуальность всех заинтересованных сторон. Создание работающего программного обеспечение, способного удовлетворять потребности бизнеса, является в методологии DSDM основным критерием успеха проекта. Сотрудничество и кооперация всех заинтересованных сторон является в методологии DSDM одним из ключевых способов достижения успеха в проекте. Методология DSDM также изначально предполагает возможность изменения требований к продукту на любой стадии проекта. Поэтому методология DSDM, несмотря на некоторую формальность предлагаемого процесса разработки, полностью соответствует основным принципам гибких технологий разработки программного обеспечения. Более того, методология DSDM предполагает тесную интеграцию с другими гибкими методологиями. Например, методология экстремального программирования может быть тесно интегрирована с методологией DSDM в рамках одного проекта. В результате чего появляется возможность использовать все основные преимущества экстремального программирования в области проектирования и реализации системы совместно с основными преимуществами методологии DSDM в области управления требованиями и проектом в целом. Список литературы https://ru.qaz.wiki/wiki/Dynamic_systems_development_method история DSDM. https://personalimage.ru/articles/facilitation/ispolzovanie-metoda-agile-pri-rabote-s-komandoy/ использование Agile. https://www.netinbag.com/ru/business/what-is-a-dynamic-systems-development-method.html понятие DSDM. https://app.diagrams.net/ рисовать диаграмму DSDM. https://www.science-education.ru/ru/article/view?id=8605 основные принципы. |