Microsoft solution framework достоинства и недостатки
Существует две основные модели организации коллектива при разработке ПО:
1) иерархическая модель
2) модель группы
Иерархическая модель организации определяет начальников и подчиненных. Однако, если в современных производственных средах один менеджер проекта отвечает за все тонкости разработки и принимает все важные решения, возникает множество проблем, ведущих к провалу проекта.
Недостатки иерархической модели:
· невозможность учесть все особенности проекта;
· отсутствие полноценной связи между всеми участниками проекта, так как вся информация идет в одном направлении -- вверх по иерархии, к главному менеджеру;
· трудность освоения новых технологий, необходимых при создании кроссплатформенных приложений;
· сложность расстановки приоритетов.
Кроме того, опыта одного человека чаще всего недостаточно для быстрого решения задачи и для интеграции приложения в существующую инфраструктуру.
Поэтому для анализа современных решений необходимо использовать модель (рис. 1), представляющую собой иерархию уровней управления процессом разработки ПО [1].
Рис. 1. Иерархия уровней управления процессом разработки ПО
В организациях, построенных на основе иерархической модели, затруднен обмен информацией -- в этой модели он, по определению, осуществляется через посредников. Дабы сгладить недостатки иерархической модели, в проектной группе предусматривается распределение обязанностей руководителя между членами коллектива. При этом за проект отвечает не один человек, а все члены группы -- каждый за свой участок.
Модель группы не определяет структуру коллектива с точки зрения отдела кадров. В такую разностороннюю группу привлечены ресурсы из разных отделов организации. Задача модели проектной группы -- определить цели проекта и распределить обязанности. Руководители каждого направления с помощью выделенных им ресурсов выполняют возложенную на них часть работы. Обязанности ролей определяются работой над проектом, а не деятельностью «штатной единицы». При этом руководители направлений выполняют свои обычные функции: составляют график выплаты премий, распределяют отпуска и контролируют эффективность работы сотрудников. Начальник может оценить степень участия и эффективность работы сотрудников в проектной группе, но это -- прерогатива менеджера, а не проектной группы.
Далее в курсовой работе поочередно будут рассмотрены современные модели проектных групп: Microsoft Solutions Framework (MSF), Rational Unified Process (RUP) и Extreme Programming (XP).
Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь [2].
Microsoft Solutions Framework представляет собой хорошо сбалансированный набор методик организации процесса разработки, который может быть адаптирован под потребности практически любого коллектива разработчиков. MSF содержит не только рекомендации общего характера, но и предлагает адаптируемую модель коллектива разработчиков, определяющую взаимоотношения внутри коллектива, гибкую модель проектного планирования, основанного на управлении проектными группами, а также набор методик для оценки рисков.
MSF предлагает использовать в процессе создания и функционирования проектной группы ряд принципов, концепций и методик:
Основные принципы:
· распределение ответственности при фиксации отчетности - все члены команды отвечают за успех проекта; они разделяют честь и славу в случае положительного результата и должны совершенствовать свой профессиональный уровень, работая над уроками менее удачных проектов;
· наделение членов команды необходимым для работы уровнем полномочий;
· концентрация на бизнес-приоритетах - необходимость принятия решений проектной группой на основе полного понимания бизнеса заказчика и при активном его участии в реализации проекта;
· единое видение проекта, формирующего целостный подход проектной группы к разработке IT-решения;
· гибкость, переменчивость - присутствие всех командных ролей и их вовлеченность в процесс принятия решений, обусловленных происходящими переменами;
· поощрение свободного общения - открытый и честный обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами вне ее;
Ключевые принципы:
· команда соратников - равноправное положение каждой из ролей в команде;
· сфокусированность на нуждах заказчика - обязательное понимание его бизнес-задач и стремление к их решению со стороны команды;
· нацеленность на конечный результат;
· установка на отсутствие дефектов;
· стремление к самосовершенствованию;
· создание заинтересованности и высокого морального духа команды;
Испытанные методики:
· создание малых многопрофильных проектных групп - большая оперативность действий в сравнении с крупными коллективами;
· коллективная работа - меньше препятствий для эффективного обмена информацией;
· всеобщее участие в проектировании [2].
Сегодня основные принципы и концепции модели проектной группы MSF во многом еще являются чуждыми большинству IT - компаниям, поскольку здесь разрушаются некоторые стереотипы (например, диктаторские полномочия и соответствующая ответственность менеджера проекта) и предлагается несколько непривычная структура проектной группы. Тем не менее, с каждым годом увеличивается число компаний, осознавших достоинства данной модели и ее преимущества перед другими.
Внедрение модели проектной группы MSF уже помогло компании Damgaard выпустить в срок новую систему управления предприятием АХАРТА, используемого более чем в 20 странах мира, компании Navision - увеличить штат разработчиков в несколько раз без дополнительных затрат на обучение, группе разработчиков из Unitied Airline - создать крупнейшую в мире систему резервирования авиабилетов в срок и без перерасхода выделенного бюджета.
Внедрение модели MSF необходимо для любой растущей компании. В частности Damgaard и Navision внедрили MSF Team model именно в тот момент, когда начался интенсивный рост численности разработчиков. В соответствии с данной модель были четко определены обязанности каждого члена команды.
Стремясь достичь максимальной отдачи от IT-проектов, Майкрософт выпустил в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Все это представлено в виде двух связанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF).
Технология разработки решений по проектированию и реализации информационных технологий - Microsoft Solution Framework (MSF) содержит в себе набор моделей и четко определенных этапов, которые можно рассматривать и как рекомендации, и как руководство по планированию, ведению и управлению проектами создания информационных систем. Эти модели - результат интеграции в единую систему наиболее успешных и многократно примененных практик, выявленных в процессе анализа опыта по разработке программных продуктов, накопленного фирмой Microsoft, ее заказчиками и партнерами.
Перед многими компаниями стоит задача так организовать управление проектами, чтобы программные продукты были неизменно высокого качества, и всегда появлялись в срок и в рамках бюджета. Методология создания программных решений Microsoft Solutions Framework (MSF) опирается на практический опыт корпорации Майкрософт и описывает управление людьми и рабочими процессами в процессе разработки решения под бизнес-требования заказчика.
Microsoft Solutions Framework представляет собой согласованный набор концепций, моделей и правил.
Модель процессов MSF. В модели процессов приводится общее описание организации работ над проектом по разработке и внедрению ИТ-решений.Предлагаемая схема достаточно гибка и может применяться к самым разным проектам в области информационных технологий. В версии 3 концепция была расширена и теперь охватывает практически весь цикл создания решений — начиная с их обсуждения и заканчивая внедрением. Такой подход поможет разработчикам сосредоточиться на решении проблем заказчика, так как реальная отдача (business value) появляется только после того, когда решение внедрено и работает.
Модель проектной группыMSF. В модели проектной группы описывается подход Microsoft по организации труда исполнителей с целью обеспечить успешное выполнение проекта. В модели определяются роли исполнителей, функции, области ответственности и принципы управления, которые помогают каждому из участников проекта выполнять задачи, которые ставятся перед ними по мере выполнения проекта.
Дисциплина управления рисками MSF. Управление рисками — это одна из основных дисциплин в Microsoft Solution Framework. В методологии MSF с самого начала учитывается, что IT-проекты могут изменяться в процессе реализации, что вносит дополнительную неопределенность. В дисциплине управления рисками MSF предлагается упреждающий подход к управлению рисками, их постоянная оценка и учет при принятии решений.
Дисциплина управления проектами MSF. Управление проектами в MSF построено с учетом работы распределенных проектных групп. Таким образом, предлагаемые механизмы учета обладают большей гибкостью и лучше масштабируются при переходе от малых проектов к большим. В статье описываются принципы управления распределенными проектами и место, которое управление проектом занимает в концепции MSF.
Дисциплина управления подготовкой MSF. Управление подготовкой — еще одна ключевая концепция в MSF. В статье представлено описание принципов учета и управления знаниями, навыками и способностями, которые необходимы для успешного планирования, реализации и управленияИТ-проектами.
Одно из ключевых свойств MSF — возможность коллективного обсуждения в терминах вышеозначенных моделей различных высокоуровневых аспектов проекта, включая концепцию, архитектуру и распределение обязанностей. Другой ключевой аспект — связанность проектной группы и проекта: проект заканчивают те же люди, что и начинают (в противовес другому подходу, при котором над проектом работают несколько групп, каждая из которых, выполнив свой узкоспециализированный кусочек работы, передает проект другой группе, и так вплоть до его завершения). Таким образом, группа, работающая над проектом, обладает всеми навыками, необходимыми для принятий решений, ведущих к его завершению. Развитие же самого проекта рассматривается как последовательное прохождение вех (milestones), позволяющих проектной группе соизмерять степень соответствия первоначального замысла и актуального проекта.
Microsoft все время оценивает свои собственные методологии по ведению проектов, а также отзывы использующих MSF. Анализ этой информации приводит к расширению существующих моделей MSF и включению новых, что делает MSF динамической, постоянно развивающейся и улучшающейся системой.
5.4.1. Управление рисками в MSF for Agile Software Development[1]
Дисциплина управления рисками MSF возводит процесс управления рисками в ранг стратегической задачи, затрагивающей все фазы проекта. В рамках MSF управление рисками – это процесс выявления, анализа и превентивной работы над рисками в целях избежания их превращения в проблемы, приносящие ущерб или иной вред.
В ходе всего проекта команда должна уделять внимание дисциплине управления рисками. Основные ее характеристики:
§ она всеобъемлюща и принимает во внимание все составляющие проекта: людей, бизнес-процессы, технологические элементы и т.д.;
§ она включает в себя пошаговый, систематический и воспроизводимый процесс управления рисками проекта;
§ ее использование непрерывно на протяжении всего жизненного цикла проекта;
§ она превентивна и не исходит из идеологии действия по факту случившегося.
§ она вовлекает всю проектную группу в непрерывное извлечение уроков из полученного опыта.
Microsoft Solutions Framework (MSF) - это методология ведения проектов и разработки решений, базирующаяся на принципах работы над продуктами самой фирмы Microsoft, и предназначенная для использования в организациях, нуждающихся в концептуальной схеме для построения современных решений [35].
Microsoft Solutions Framework является схемой для принятия решений по планированию и реализации новых технологий в организациях. MSF включает обучение, информацию, рекомендации и инструменты для идентификации и структуризации информационных потоков бизнес-процессов и всей информационной инфраструктуры новых технологий.
Microsoft Solutions Framework представляет собой хорошо сбалансированный набор методик организации процесса разработки, который может быть адаптирован под потребности практически любого коллектива разработчиков. MSF содержит не только рекомендации общего характера, но и предлагает адаптируемую модель коллектива разработчиков, определяющую взаимоотношения внутри коллектива, гибкую модель проектного планирования, основанного на управлении проектными группами, а также набор методик для оценки рисков.
В момент подготовки данного учебного курса последней версией MSF была 3.1, при этом существовали документы, относящиеся к версии 4.0 beta.
MSF состоит из двух моделей:
· модель проектной группы;
и трех дисциплин:
В MSF нет роли «менеджер проекта» и иерархии руководства, управление разработкой распределено между руководителями отдельных проектных групп внутри коллектива, выполняющих следующие задачи:
Жизненный цикл процессов в MSF сочетает водопадную и спиральную модели разработки: проект реализуется поэтапно, с наличием соответствующих контрольных точек, а сама последовательность этапов может повторяться по спирали (Рис. 4).
Рис. 4 Жизненный цикл в MSF
При таком подходе от водопадной модели берется простота планирования, от классической спиральной – легкость модификаций. При этом благодаря промежуточным контрольным точкам и обратной спирали верификации облегчается взаимодействие с заказчиком.
При управлении проектом четко ставится цель, которую необходимо достичь в результате и учитываются ограничения, накладываемые на проект. Все виды ограничений могут быть отнесены к одному из трех видов: ограничения ресурсов, ограничения времени и ограничения возможностей. Эти три вида ограничений и приоритетность задач по их преодолению образую треугольник приоритетов в MSF (Рис. 5).
Рис. 5 Треугольник приоритетов в MSF
Треугольник приоритетов является основой для матрицы компромиссов – заранее утвержденных представлений о том, какие аспекты процесса разработки будут четко заданы, а какие будут согласовываться или приниматься как есть.
Microsoft выпустила среду разработки, в полной мере поддерживающей основные идеи MSF – Microsoft Visual Studio 2005 Team Edition. Это первый программный комплекс, представляющий собой не среду разработки для индивидуальных членов коллектива, а комплексное средство поддержки коллективной работы.
В состав Visual Studio Team Edition входит специальная редакция для тестировщиков – Team Edition for Software Testers (Рис. 6). Материалы семинарских занятий по данному курсу ориентированы на эту среду разработки, в то время как лекционные материалы ориентированы на изложение общих принципов и методик тестирования.
Основные особенности MSF, RUP и XP можно свести в небольшую таблицу (Таблица 2) [9]. По ней можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании Rational. Сопровождение разработки системы и самой системы регламентируется самой методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства.
Extreme Programming хорошо подходит для проектных групп малого размера и для небольших систем с часто изменяемыми требованиями. Основная проблема XP - сопровождаемость. В случае текучки кадров в коллективе разработчиков значительная часть проектной информации может быть утеряна из-за практически отсутствующей документации.
Таблица 2. Технологии MSF, RUP и XP
Допустимые технологии и инструменты
Удобство модификации и сопровождения
Rational Unified Process
UML и продукты Rational
Microsoft Solutions Framework
Сложно (зависимость от конкретных участников коллектива)
Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков.
MSF сходна с RUP, также включает четыре фазы: анализ, проектирование, разработку, стабилизацию. Она является итерационной, предполагает использование объектно - ориентированного моделирования. MSF по сравнению с RUP в большей степени ориентирована на разработку бизнес - приложений.
MSF - это гибкая и достаточно легковесная методология, построенная на итеративной модели разработки. Привлекательной особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нетрадиционные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.
Как и в случае с RUP, в MSF очевидно стремление к универсальности, которое неизбежно приводит к огрублению ситуации в конкретных случаях и к необходимости словесного дополнения схемы. Недостатки моделей, основанных на раскручивающейся спирали, присущи ей в полной мере: невозможность отслеживания временных соотношений между сроками выполнения работ, трудности дополнения специфичных этапов. К тому же ориентация на всеобщность лишает модель и тех преимуществ, которые демонстрирует модель, снабженная конкретным механизмом интерпретации.
Преимуществами XP являются:
· простота в использовании, адаптации, обучении;
· устойчивость к внешним факторам, таким как текучесть кадров, нехватка денег, внезапное завершение финансирования;
· учёт изменчивости требований и кардинального пересмотра всей системы;
· равномерная загруженность всех членов коллектива;
· быстрое включение в работу новичков с минимальным уровнем риска;
· эффективный контроль работоспособности разрабатываемых систем;
· увеличение производительности разработчиков;
· предоставление дополнительных благ членам коллектива;
· естественный профотбор членов команды;
· низкая степень бюрократизма;
· широкая известность и популярность.
От других известных методологий разработки его также отличает простота, низкая стоимость внедрения и общедоступность. По сравнению с известным процессом разработки Rational Unified Process (RUP), время интенсивного внедрения его в несколько раз меньше. Если внедрение RUP может занять от полугода до двух лет, то внедрение XP может быть выполнено в течение одного-двух месяцев. При этом сама технология RUP стоит около 600$. И это не считая сопутствующих программ, обучающего материала и повышенного требования к персоналу.
Одним из важнейших факторов на пути к выпуску успешного программного обеспечения является минимальная инерционность группы разработчиков. Или другими словами, насколько быстро они могут среагировать на изменившиеся требования к системе, не меняя при этом распорядка дня. Проанализируем порядок действий при изменении требования с точки зрения XP и RUP.
Заказчик должен подготовить документы, необходимые для внесения изменения и предоставить руководителю группы разработчиков на рассмотрение. При этом язык изложения требования должен быть строго формализованным, например Диаграмма прецедентов (Use-case diagram). После первоначального рассмотрения передать запрос менеджерам, которые в свою очередь передадут его аналитикам.
Аналитики построят высокоуровневые модели, проведут подсчёт сложности, количество человеко-часов, необходимых на доработку, и предоставят информацию менеджерам.
Менеджеры после очередного согласования с начальством и заказчиком распределят, в принудительном порядке, работу между программистами и тестировщиками.
Программисты должны будут включить в свой процесс дополнительные шаблоны и задокументировать их, построить соответствующие модели, изменить существующие.
Тестирование моделей.
Отдел тестирования должен внести соответствующие изменения в тест-план. После подготовки всех необходимых документов, программисты приступают к кодированию, при этом отсутствие любого члена команды грозит срывом сроков сдачи. Этот этап является самым непродолжительным, примерно 10% от всего времени на изменение.
Уточнение моделей. Тестирование изменившейся части. Тестирование системы в целом
Заказчик тесно общается с разработчиками и знает, что изменения могут быть внесены достаточно просто. Поэтому он не боится предлагать внести изменения, когда это действительно необходимо. Он формирует запрос на изменение в виде истории пользователя (User story), на понятном человеческом языке.
Эта история передаётся на всеобщее обсуждение разработчиков, которые её формализуют, делают предварительную оценку времени, необходимого для выполнения. Заказчик устанавливает её приоритетность.
Вместе с заказчиком корректируется список историй для выполнения в рамках текущей итерации.
Один из программистов (или пара) берёт на себя ответственность за выполнение данной истории и приступает к работе. Это может быть не тот человек, который разрабатывал эту область ранее, за счёт коллективного владения кодом.
С помощью заказчика определяются критерии работоспособности программного исполнения истории, и пишется автоматический приёмочный тест.
Программист разбивает историю на задачи и пишет для каждой модульные тесты (Unit test).
Программист кодирует каждую задачу и добивается выполнения всех тестов. Далее идёт проверка работоспособности истории с помощью приёмочных тестов. При этом работоспособность всей системы контролируется автоматически посредством ранее написанных тестов [10].
Так, при работе по XP основное внимание сосредоточенно вокруг заказчика и разработчика. Это позволяет избежать неточностей понимания и постановки задачи. Мелочи и неточности, а также несвоевременно внесённые изменения, в совокупности, представляют почву для провала проекта. Программист уверен в своих действиях и работоспособности системы за счёт постоянной обратной связи с системой (автоматические тесты) и с заказчиком (быстрые релизы). Минимизироавнное число сопутствующих документов позволяет не только съэкономить время, но и сократить штат задействованных специалистов.
Ролей в XP также не так много, и здесь нет ограничений на совместимость их в рамках одного человека. Так, если следовать учению Microsoft Solution Framework (MSF), то программист не может быть одновременно менеджером, тестировщиком или техническим писателем. Хотя опыт показывает обратное, что, в свою очередь, является оправданной и довольно успешной практикой. В экстремальном программировании это даже приветствуется. Так, например, опытный программист может достойно совмещать, помимо своих основных обязанностей, роль тренера, наблюдателя и менеджера. Да, действительно, в Microsoft произвели ряд дорогостоящих исследований, которые показали определённую несовместимость ролей. Разработчики же экстремального программирования, глядя глубоко в корень, постарались устранить причину этой несовместимости. Это стало возможным за счёт усиления обратных связей, неявного автоматизированного и мануального контроля.
Есть также определённые условия, при которых достигается максимальная эффективность использования XP. Они включают следующие: группа разработчиков от двух до десяти человек, проект на срок до полугода и присутствие заказчика на месте разработки. Но это не является требованием. Большинством методик и принципов XP могут пользоваться и единичные программисты.
Читайте также: