1.1 Процессы командной разработки программного обеспечения MSF

1.1 Процессы командной разработки программного обеспечения MSF Microsoft Solutions Framework (MSF) является методологией разработки ПО, которая представляет собой обобщение лучших проектных практик, которые использовались командами разработчиков Microsoft. Данная методология описывает управление людьми и рабочими процессами при разработке ИТ-решений. ИТ-решение понимается как скоординированная поставка набора элементов (таких как программные средства, документация, обучение и сопровождение), необходимых для удовлетворения бизнес-потребности конкретного заказчика. Концепция управления жизненным циклом приложений, принятая разработчиками ПО, привела к тому, что методология MSF стала составной часть продукта Visual Studio Team System (VSTS), который реализовывал подход Microsoft в плане процесса управления жизненным циклом приложения - Application Lifecycle Management (ALM). В продукт VSTS вошли шаблоны процессов для реализации положений модели Capability Maturity Model Integration (CMMI) - MSF for CMMI и моделей гибкой разработки ПО - MSF for Agile и Scrum. Таким образом, VSTS являются инструментарием управления жизненным циклом приложений, который позволяет создавать программные системы различного назначения в командах, придерживающихся различных подходов к управлению процессами разработки ПО. Основными являются следующие принципы MSF: 1. Единое видение проекта, которое предполагает понимание всеми заинтересованными лицами целей и задач создания ПО. 2. Гибкость - готовность к переменам, что обеспечивает возможность уточнения и изменения требований в процессе разработки ПО, оперативного и быстрого реагирования на текущие изменения условий проекта при неизменной эффективности управленческой деятельности. 3. Концентрация на бизнес-приоритетах, что предполагает создание продукта с высоким потребительским качеством и формирование определенной выгоды или отдачи. Для организаций, как правило, это получение прибыли. 4. Поощрение свободного общения, что предполагает открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами. Универсальность модели MSF определяется тем, что благодаря своей гибкости и отсутствию жестко установленных связей и процедур она может быть применена при разработке различных программных приложений, которые могут использоваться в бизнесе и повседневной жизни. Модель MSF базируется на сочетании двух моделей жизненного цикла программных систем: каскадной и спиральной (см. рис. 1.1). В основе методологии MSF лежит итеративный интегрированный подход к созданию и внедрению решений, базирующийся на фазах и вехах. Итеративность подхода предусматривает поэтапное создание работоспособной программной системы с определенной функциональностью, отражающей требования к конечному продукту на данном этапе разработки. Каждый виток спирали состоит из идентичных фаз, на которых выполняются этапы работ по формированию концепции фазы, планированию, разработке, стабилизации и внедрению. Набор требований программной системы и соответствующих им задач, которые реализуются на заданном витке спирали, определяется менеджером проекта на основе ранжирования требований к системе. Каждый последующий виток спирали добавляет к программной системе функциональность, отражающую требования заказчика. Рисунок 1.1 - Модель жизненного цикла решения MSF Интеграция в рамках одного проекта процедур разработки и внедрения системы позволяет представлять заказчику различные промежуточные работоспособные версии программного продукта, оперативно вносить изменения, отражающие видение заказчиком функциональности и дизайна проектируемой системы, снизить риски проекта за счет раннего выявления проблем и возможности своевременного их устранения. Фазы проекта определяют последовательно решаемые задачи, а вехи (milestones) - ключевые точки проекта, характеризующие достижение какого-либо существенного результата. В MSF используются два вида вех: главные и промежуточные. Они имеют следующие характеристики: 1. Главные вехи служат точками перехода от одной фазы к другой и определяют изменения в текущих задачах ролевых кластеров проектной команды. В MSF главные вехи являются в достаточной степени универсальными для применения в любом ИТ проекте; 2. Промежуточные вехи показывают достижение определенного прогресса в исполнении фазы проекта и расчленяют большие сегменты работы на меньшие, обозримые и управляемые участки. Промежуточные вехи могут варьироваться в зависимости от характера проекта. Модель команд Главная особенность модели команды в MSF является то, что она не имеет официального лидера. Все отвечают за проект в равной степени, уровень заинтересованности каждого в результате очень высок, а коммуникации внутри группы четкие, ясные, дружественные и ответственные. Такое возможно при высоком уровне самосознания и заинтересованности каждого члена команды, а также при достаточно высоком уровне профессионализма. Одной из особенностей отношений внутри команды является высокая культура дисциплины обязательств: • готовность работников принимать на себя обязательства перед другими; • четкое определение тех обязательств, которые они на себя берут; • стремление прилагать должные усилия к выполнению своих обязательств; • готовность честно и незамедлительно информировать об угрозах выполнению своих обязательств. Ролевые кластеры MSF основаны на семи качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы и образуют ролевые кластеры (или просто роли) в проекте. Каждый кластер может включать одного или нескольких специалистов. Каждый ролевой кластер представляет уникальную точку зрения на проект, и в то же время никто из членов проектной группы в одиночку не в состоянии успешно представлять все возможные взгляды, отражающие качественно различные цели. В MSF следующие ролевые кластеры (табл. 1.1): Таблица 1.1 – Ролевые кластеры MSF Управление продуктом Основная задача кластера- обеспечить, чтобы заказчик остался довольным в результате выполнения проекта. Этот ролевой кластер в проекте представляет интересы заказчика. Он представляет бизнес-сторону проекта и обеспечивает его согласованность со стратегическими целями заказчика. Управление программой Кластер обеспечивает управленческие функции - отслеживание планов и их выполнение, ответственность за бюджет, ресурсы проекта, разрешение проблем и трудностей процесса, создание условий, при которых команда может работать эффективно, испытывая минимум бюрократических преград. Разработка Кластер обеспечивает разработку кода приложения. Тестирование Кластер отвечает за тестирование ПО. Удовлетворение потребителя Кластер решает задачи пользовательского дизайна приложения и обеспечения удобства эксплуатации ПО, обучение пользователей работе с ПО, создание пользовательской документации. Управление выпуском Кластер отвечает за внедрение проекта и его функционирование, берет на себя связь между разработкой решения, его внедрением и последующим сопровождением, обеспечивая информированность членов проектной группы о последствиях их решений. Архитектура Кластер отвечает за организацию и выполнение высокоуровневого проектирования решения, создание функциональной спецификации ПО и управление этой спецификацией в процессе разработки, определение рамок проекта и ключевых компромиссных решений. Изменения в задачах ролевых кластеров проектной команды происходят по мере смены фаз проекта. Переход от одной фазы к другой включает в себя также перенос основной ответственности от одних ролевых кластеров к другим, как показано в таблице 1.2. Таблица 1.2 - Распределение ответственности ролевых кластеров Веха Ведущие ролевые кластеры Концепция утверждена Управление продуктом Планы проекта утверждены Управление программой Разработка завершена Разработка, удовлетворение потребителя Готовность решения утверждена Тестирование, управление выпуском Внедрение завершено Управление выпуском Масштабирование команды MSF В зависимости от размера и сложности проекта модель команд MSF допускает масштабирование. Для небольших и несложных проектов один сотрудник может объединять несколько ролей. При этом некоторые роли нельзя объединять. В таблице 1.3 представлены рекомендации MSF относительно совмещения ролей в рамках одним членом команды. "+" означает, что совмещение возможно, "+-" - что совмещение возможно, но нежелательно, "-" означает, что совмещение не рекомендуется. В частности, нельзя совмещать разработку и тестирование, поскольку необходимо, чтобы у тестировщиков был сформирован свой, независимый взгляд на систему, базирующийся на изучении требований. Для больших команд (более 10 человек) модель проектной группы MSF предлагает разбиение на малые многопрофильные группы направлений. Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия, каждая из которых устроена на основе модели кластеров. Такие команды имеют четко определенную задачу и ответственны за все относящиеся к ней вопросы, начиная от проектирования и составления календарного графика. Кроме того, когда ролевому кластеру требуется много ресурсов, формируются так называемые функциональные группы, которые затем объединяются в ролевые кластеры. Они создаются в больших проектах, когда необходимо сгруппировать работников внутри ролевых кластеров по их областям компетенции. Часто функциональные группы имеют внутреннюю иерархическую структуру. Например, менеджеры программы могут быть подотчетны ведущим менеджерам программы, которые в свою очередь отчитываются перед главным менеджером программы. Подобные структуры могут также появляться внутри областей компетенций. Управление компромиссами  Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (функциональность). Эти три переменные образуют треугольник, показанный на рис. 1.2. Рисунок 1.2 – Треугольник компромиссов Таблица 1.3 – Рекомендации MSF относительно совмещения ролей в команде проекта Управление продуктом Управление программой Разработка Тестирование Удовлетворение потребителя Управление выпуском Архитектура Управление продуктом - - + + +- - Управление программой - - +- +- + + Разработка - - - - - + Тестирование + +- - + + +- Удовлетворение потребителя + +- - + +- +- Управление выпуском +- + - + +- + Архитектура - + + +- +- + После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне. В проектной практике может фиксироваться один из ресурсов, тогда в процессе проектирования системы измерению подлежат только два оставшихся ресурса. Данная ситуация задается матрицей компромиссов, которая приведена на рис. 2.3. Так, если фиксируются ресурсы, то время выполнения проекта согласовывается, а функциональные возможности подлежат изменению. Рисунок 1.3 - Матрица компромиссов 1.2 Гибкая методология разработки программного обеспечения  Гибкая методология разработки программного обеспечения ориентирована на использование итеративного подхода, при котором программный продукт создается постепенно, небольшими шагами, включающими реализацию определенного набора требований. При этом предполагается, что требования могут изменяться. Команды, использующие гибкие методологии, формируются из универсальных разработчиков, которые выполняют различные задачи в процессе создания программного продукта. При использовании гибких методологий минимизация рисков осуществляется путём сведения разработки к серии коротких циклов, называемых итерациями, продолжительностью 2 -3 недели. Итерация представляет собой набор задач, запланированных на выполнение в определенный период времени. В каждой итерации создается работоспособный вариант программной системы, в которой реализуются наиболее приоритетные (для данной итерации) требования заказчика. На каждой итерации выполняются все задачи, необходимые для создания работоспособного программного обеспечения: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что текущий программный продукт готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов требований к программному продукту, возможно, вносит коррективы в разработку системы. Принципы и значение гибкой разработки Для методологии гибкой разработки декларированы ключевые постулаты, позволяющие командам достигать высокой производительности: • люди и их взаимодействие; • доставка работающего программного обеспечения; • сотрудничество с заказчиком; • реакция на изменение. Люди и взаимодействие. Люди - важнейшая составная часть успеха. Отдельные члены команды и хорошие коммуникации важны для высокопроизводительных команд. Для содействия коммуникации гибкие методы предполагают частые обсуждения результатов работы и внесение изменений в решения. Обсуждения могут проводиться ежедневно длительностью несколько минут и позавершению каждой итерации с анализом результатов работ и ретроспективой. Для эффективных коммуникаций при проведении собраний участники команд должны придерживаться следующих ключевых правил поведения: • уважение мнения каждого участника команды; • быть правдивым при любом общении; • прозрачность всех данных, действий и решений; • уверенность, что каждый участник поддержит команду; • приверженность команде и ее целям. Для создания высокопроизводительных команд в гибких методологиях кроме эффективной команды и хороших коммуникаций необходим совершенный программный инструментарий. Работающее программное обеспечение важнее всеобъемлющей документации. Все гибкие методологии выделяют необходимость доставки заказчику небольших фрагментов работающего программного обеспечения через заданные интервалы. Программное обеспечение, как правило, должно пройти уровень модульного тестирования, тестирования на уровне системы. При этом объем документации должен быть минимальным. В процессе проектирования команда должна поддерживать в актуальном состоянии короткий документ, содержащий обоснования решения и описание структуры. Сотрудничество с заказчиком важнее формальных договоренностей по контракту. Чтобы проект успешно завершился, необходимо регулярное и частое общение с заказчиком. Заказчик должен регулярно участвовать в обсуждении принимаемых решений попрограммному обеспечению, высказывать свои пожелания и замечания. Вовлечение заказчика в процесс разработки программного обеспечения необходимо создания качественного продукта. Оперативное реагирование на изменения важнее следования плану. Способность реагирования на изменения во многом определяет успех программного проекта. В процессе создания программного продукта очень часто изменяются требования заказчика. Заказчики очень часто точно не знают, чего хотят, до тех пор, пока не увидят работающее программное обеспечение. Гибкие методологии ищут обратную связь от заказчиков в процессе создания программного продукта. Оперативное реагирование на изменения необходимо для создания продукта, который удовлетворит заказчика и обеспечит ценность для бизнеса. Постулаты гибкой разработки поддерживаются 12 принципами. В конкретных методологиях гибкой разработки определены процессы и правила, которые в большей или меньшей степени соответствуют этим принципам. Гибкие методологии создания программных продуктов основываются на следующих принципах: 1. Высшим приоритетом считать удовлетворение пожеланий заказчика посредством поставки полезного программного обеспечения в сжатые сроки с последующим непрерывным обновлением. Гибкие методики подразумевают быструю поставку начальной версии и частые обновления. Целью команды является поставка работоспособной версии с течение нескольких недель с момента начала проекта. В дальнейшем программные системы с постепенно расширяющейся функциональностью должны поставляться каждые несколько недель. Заказчик может начать промышленную эксплуатацию системы, если посчитает, она достаточно функциональна. Также заказчик может просто ознакомиться с текущей версией программного обеспечения, предоставить свой отзыв с замечаниями. 2. Не игнорировать изменение требований, пусть даже на поздних этапах разработки. Гибкие процессы позволяют учитывать изменения для обеспечения конкурентных преимуществ заказчика. Команды, использующие гибкие методики, стремятся сделать структуру программы качественной, с минимальным влиянием изменений на систему в целом. 3. Поставлять новые работающие версии ПО часто, с интервалом от одной недели до двух месяцев, отдавая предпочтение меньшим срокам. При этом ставится цель поставить программу, удовлетворяющую потребностям пользователя, с минимумом сопроводительной документации. 4. Заказчики и разработчики должны работать совместно на протяжении всего проекта. Считается, что для успешного проекта заказчики, разработчики и все заинтересованные лица должны общаться часто и по многу для целенаправленного совершенствования программного продукта. 5. Проекты должны воплощать в жизнь целеустремленные люди. Создавайте команде проекта нормальные условия работы, обеспечьте необходимую поддержку и верьте, что члены команды доведут дело до конца. 6. Самый эффективный и продуктивный метод передачи информации команде разработчиков и обмена мнениями внутри неё - разговор лицом к лицу. В гибких проектах основной способ коммуникации - простое человеческое общение. Письменные документы создаются и обновляются постепенно по мере разработки ПО и только в случае необходимости. 7. Работающая программа - основной показатель прогресса в проекте. О приближении гибкого проекта к завершению судят по тому, насколько имеющаяся в данный момент программа отвечает требованиям заказчика. 8. Гибкие процессы способствуют долгосрочной разработке. Заказчики, разработчики и пользователи должны быть в состоянии поддерживать неизменный темп сколь угодно долго. 9. Непрестанное внимание к техническому совершенству и качественному проектированию повышает отдачу от гибких технологий. Члены гибкой команды стремятся создавать качественный код, регулярно проводя рефакторинг. 10. Простота - искусство достигать большего, делая меньше. Члены команды решают текущие задачи максимально просто и качественно. Если в будущем возникнет какая-либо проблема, то в качественный код имеется возможность внести изменения без больших затрат. 11. Самые лучшие архитектуры, требования и проекты выдают самоорганизующиеся команды. В гибких командах задачи поручаются не отдельным членам, а команде в целом. Команда сама решает, как лучше всего реализовать требования заказчика. Члены команды совместно работают над всеми аспектами проекта. Каждому участнику разрешено вносить свой вклад в общее дело. Нет такого члена команды, который единолично отвечал бы за архитектуру, требования или тесты. 12. Команда должна регулярно задумываться над тем, как стать ещё более эффективной, а затем соответственно корректировать и подстраивать свое поведение. Гибкая команда постоянно корректирует свою организацию, правила, соглашения и взаимоотношения. Вышеприведенным принципам, в определенной степени, соответствуют ряд методологий разработки программного обеспечения (табл. 1.4): Таблица 1.4 – Рекомендации MSF относительно совмещения ролей в команде проекта Agile Modeling набор понятий, принципов и приёмов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения; Agile Unified Process(AUP) упрощенная версия IBM Rational Unified Process (RUP), которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений; Open UP это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как лёгкий и гибкий вариант RUP; Agile Data Method группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд; DSDM методика разработки динамических систем, основанная на концепции быстрой разработки приложений (Rapid Application Development, RAD). Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя; Extreme programming (XP) экстремальное программирование; Adaptive software development (ADD) адаптивная разработка программ; Feature driven development (FDD) разработка ориентированная на постепенное добавление функциональности; Getting Real итеративный подход без функциональных спецификаций, использующийся для веб-приложений; MSF fog Agile Software Development гибкая методология разработки ПО компании Microsoft; Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования, корректируя требования или внося тактические изменения. Следует отметить, что в чистом виде методологии гибкого программирования редко используются командами разработчиков. Как правило, успешные команды применяют полезные приемы и свойства нескольких процессов, подстраивая их под конкретное представление команды о гибкости процесса разработки.