Сергей Зыков - Основы проектирования корпоративных систем

Рис. 5.6.Модель команды MSF

Основные принципы организации проектной команды в рамках подхода MSF состоят в том, что прежде всего команда является равноправной в определенном смысле, т. е. каждая роль имеет достаточно жестко ограниченную область ответственности и в рамках этой области имеет определенные полномочия. Но если речь идет о качестве продукта в целом, то поощряется открытое взаимодействие всей проектной команды, и о качестве проекта может высказываться каждый, команда несет ответственность за результат. Поощряется открытая коммуникация, для каждой роли существуют четкие метрики контроля качества с учетом той области, которую она занимает в проекте. По сути, продвижение по проекту представляет собой учет и сбалансированный анализ вклада каждого участника в результирующее решение. Для того чтобы обеспечить аккуратный, взвешенный жизненный цикл реализации, предотвратить и скомпенсировать негативные последствия возникающих ошибок или несоответствий, необходимо учитывать все аспекты проектирования и реализации. Поэтому каждый член команды имеет равное право голоса, особенно в той области, за которую отвечает. Очень важным принципом является адаптивность, т. е. Microsoft Solution Framework не является жестко фиксированной и предполагает адаптацию команды к проекту по количеству людей, функциональным ролям, ограничениям, сферам взаимодействия и артефактам. Таким образом, проектная команда оказывается масштабируемой и может подразделяться на более мелкие проектные команды, динамически изменяя размеры. Это позволяет наладить эффективную коммуникацию при работе над программными продуктами.

Центральным понятием в схеме MSF является роль. Некоторые роли уже были описаны, когда речь шла о модели процессов. Каждая из ролей выполняет те или иные активности, которые организуются в последовательности действий, – рабочие потоки. При этом активность включает несколько задач: небольшие фрагменты, которые могут быть выполнены за определенные сроки и которые предполагают четко измеримые результаты на выходе. Каждая из активностей в итоге может вести к созданию продукта и требовать на вход частичный продукт для того, чтобы на выходе привести к созданию нового частичного продукта. Это похоже на объектно-ориентированный подход, когда осуществляется интеграция продукта, т. е. из небольших файлов собираются частичные крупные продукты и агрегируются в полномасштабный продукт. В ходе выполнения активностей создается большое количество документации. Она представляется в самых разных видах: таблицы, графики, диаграммы, инструкции в текстовом виде. Основные области знаний, исходя из которых создаются проектные роли, сводятся к архитектуре продукта, управлению продуктом и активностям, связанным с разработкой, тестированием, общением с пользователем, эксплуатацией.

На рис. 5.7 представлена матрица совместимости групп ролей, которая во многом отражает возможности масштабирования подхода Microsoft Solution Framework по программным продуктам с учетом их размера. Ряд ролей можно совмещать. Управление продуктом и управление проектом возможно совмещать, но не рекомендуется. Таким образом, в группе, которая ведет проект по подходу MSF, может быть небольшое количество людей, при этом ряд ролей может совмещаться. С другой стороны, если это крупный проект, то роли разделяются. Так же, как и RUP, подход MSF имеет в своей основе процессы, и их фазы достаточно близки. Если в RUP говорилось о стадии создания концепции, то здесь – о создании видения, абстрактного представления о том, каким должен быть продукт, какого рода задачу он должен решать, при этом процессная модель основана на итеративном уточнении функционала проекта с построением нескольких релизов, которые являются полномасштабными с точки зрения функционала продукта, артефактов (на каждом этапе, релизе мы продуцируем практически готовый продукт с точки зрения всех его артефактов, функциональность не является завершенной).

Рис. 5.7.Матрица совместимости ролей в подходе MSF

Итак, видение завершается определением границ, т. е. концептуальных проектных ограничений, которые описывают базовую функциональность программного продукта: какие задачи он должен решать и на какие он не должен распространяться, какие будут решены тактически в ходе дальнейших релизов, какие стоит стратегически оставить за рамками данного проекта в целом. После этого происходит планирование проекта и разработка. Между стадиями осуществляется контроль достижения целей по истечении каждой вехи и сопоставление документально полученных результатов с целями и требованиями. Как только завершено планирование, начинается разработка. И затем существует специфическая стадия для каждого релиза, которая отсутствует в RUP, – это стабилизация (рис. 5.8), так как Microsoft Solution Framework основана на модели синхронизации и стабилизации, т. е. существенной составляющей является стабилизация каждого релиза, и для достижения его устойчивой и надежной работы необходимо обеспечивать качество релиза согласно проектным метрикам.