Основы проектирования корпоративных систем

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

Как видно из рис. 5.6, в модели команды Microsoft Solution Framework можно выделить несколько областей знаний. Это управление программой, управление продуктом, область, связанная с пользовательским опытом, разработка или реализация, тестирование (тестирование должно происходить в сжатые сроки, достаточно часто и обеспечивать качество каждого релиза, поэтому предполагается использование программных средств и высококвалифицированных специалистов в этой области), опыт, который связан с изготовлением релизов и эксплуатацией, архитектурное проектирование.

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

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

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