Microsoft Solutions Framework: философия создания IT-решений или голые амбиции лидера?

© Сергей Якимчук
менеджер по качеству Softline Company
© Журнал "IТ-менеджер" 2004, #4
© ЦитФорум 2004, #12

Введение

Корпорацию Майкрософт можно обвинять в чём угодно, но уж точно не в том, что её руководители не умеют вести бизнес и создавать продаваемые программные комплексы. Посредством пакета руководств MSF (Microsoft Solutions Framework) гигант IT индустрии решил поделиться опытом и накопленной информацией в области проектирования, разработки, внедрения и сопровождения IT -проектов. Словосочетание MSF я бы перевёл как «Подходы Майкрософт к созданию решений». База знаний MSF состоит из оригинальных моделей, методов и взглядов на такие области знаний как управление проектами, персоналом, планирование, анализ рисков и другие смежные дисциплины. Нельзя сказать, что MSF очередной чисто теоретический взгляд на управление. В руководствах по MSF кроме методов, моделей и концепций встречаются практические советы и приёмы, отнюдь не лишенные рациональности. Структурно пакет руководств MSF разделён на пять документов, так называемых «белых книг», каждый из которых охватывает определенную дисциплину или модель MSF : «Модель процессов MSF», «Модель проектной группы MSF», «Дисциплина управления проектами MSF», «Дисциплина управления рисками MSF» и «Дисциплина управления подготовкой MSF». Эта статья посвящена в большей степени первой книге «Модель процессов MSF», в которой будет рассмотрена модель жизненного цикла IT -проекта, а также базисные концепции и принципы методологии MSF.

Предметной областью рассматриваемой методологии является IT -проект (разработка ПО, внедрение/адаптация уже разработанных систем, разворачивание сетевой инфраструктуры или всё вышеперечисленное в комплексе). На мой взгляд, возможность применения данной технологии возникает в любом проекте, в котором задействовано более 4-6 человек. Итак, на чём же зиждется успех гиганта?

Базовые концепции и принципы модели процессов MSF

«Информационная работа – это работа мысли»
Билл Гейтс. «Бизнес со скоростью мысли»

Единое видение проекта

Любой коллективный труд, а тем более такой нетривиальный как разработка и внедрения программного обеспечения, имеет мало шансов на успех, если все участвующие стороны не представляют (или еще хуже не правильно представляют) конечной цели проекта, иначе говоря, не имеют единого видения (shared vision) проекта. Все заинтересованные лица и просто участники проекта должны чётко представлять конечный результат. Всем должна быть понятна цель проекта. Подход MSF не зря акцентирует внимание на этом, казалось бы, умозрительном принципе. На практике не всегда так просто обеспечить единое понимание целей и задач проекта. Зачастую эта единая цель вступает в противоречие с интересами некоторых участников проекта. Или эти участники видят выгоды только от одной подсистемы проекта, которая касается их непосредственно. Например, бывает очень тяжело на последних этапах проекта объяснить сотрудникам склада, зачем им вводить номер накладной на отпущенный товар. Им он не нужен. Зато он нужен бухгалтерии. Конфликт возникает, потому что кладовщики думали, что автоматизируют склад, а не предприятие в целом. Поэтому MSF выделяет в жизненном цикле проекта целую фазу для обеспечения единого видения проекта.

Управляйте компромиссами

Наверное, не было еще ни одного менеджера проекта, которому не приходилось бы бороться с разрастанием рамок проекта и, как следствие, с перерасходом средств и затягиванием сдачи. Настоящим искусством менеджера является элегантное нахождение компромисса между ресурсами проекта (людскими, финансовыми и пр.), календарным графиком (временем) и реализуемыми возможностями (рамками).

Треугольник компромиссов

Часто бывает очень полезно изобразить эту зависимость заказчику в виде треугольника компромиссов

После достижения утвержденного равновесия с заказчиком, т.е. на запрашиваемые возможности вы назвали и зафиксировали сроки и смету, любое изменение на одной из сторон треугольника влечет изменение на двух оставшихся. Такой подход служит удобным инструментом для нахождения компромиссов с заказчиком и поможет объяснить суть имеющихся ограничений. Иногда имеет смысл добавлять еще четвертое измерение – качество, за счёт которого можно сэкономить время и ресурсы при неизменных возможностях, хотя, на мой взгляд, это последнее на чём стоит экономить. Однако отечественные реалии диктуют свои законы и не редки случаи, когда важен сам факт внедрения и заниженная планка качества решения (quality bar) всех устраивает. В таких случаях участники проекта должны, по крайней мере, знать об этом, и этот факт должен найти адекватное отражение в проектной документации (например, отсутствие дизайнерского оформления интерфейса или ведения журнала операций пользователя в системе).

Матрица компромиссов

Для эффективного достижения компромиссов в течение всего жизненного цикла проекта, MSF рекомендует на начальных этапах зафиксировать приоритеты факторов проекта (ресурсы, время, возможности). На один из факторов влиять в течение проекта будет практически невозможно (Фиксируется), - другой будет обладать некоторым приоритетом при разрешении компромиссов (Согласовывается) и оставшийся будет принят в соответствии с первыми двумя (Принимается).

Зафиксировать приоритеты в проектной документации можно с помощью простых текстовых оборотов: «Зафиксировав ресурсы, мы согласовываем календарный график и принимаем результирующий объем функциональности решения» или «Зафиксировав объем функциональности решения, мы согласовываем затрачиваемые ресурсы и принимаем результирующие сроки» и т.п. В дальнейшем возврат к приоритетам может сильно помочь при нахождении компромисса внутри проектной группы (обращаю внимание на то, что представитель заказчика тоже является членом проектной группы).

Проявляйте гибкость – будьте готовы к переменам

В отличие от традиционной модели управления проектами, в которой подразумевается четкая формулировка требований на начальном этапе проекта и разработка на основании ТЗ, подход MSF основывается на принципе изменяющихся проектных условий. Проектная группа должна быть готова к переменам и методология MSF предоставляет эффективный инструментарий для адекватной и своевременной реакции на изменения в проектной среде.

Концентрация на бизнес-приоритетах

При создании любого решения необходимо сосредоточиться на той отдаче и выгоде, которую ожидает получить потребитель решения. Если проект нацелен на предприятие, то точкой концентрации будет бизнес-отдача (business - value). В отношении персональных программ, как, например, компьютерная игра, отдачу можно выразить в виде эмоционального удовлетворения потребителя. Можно сказать уверенно, что MSF не подходит для волонтёрских проектов, удовлетворяющих чьи-то амбиции или являющихся творческой отдушиной для разработчиков – творцов с рождения.

Поощряйте свободное общение

До сих пор большинство IT организаций ограничивает доступность к информации участников проекта исключительно необходимой для выполнения их работы или хотя бы пытается это делать, порождая недоверие внутри рабочей группы, но те, кому интересно всё равно узнают рано или поздно то, что им интересно. Методология MSF разрушает этот стереотип, поощряя свободное общение внутри проекта. Это заметно сокращает риск недопонимания, возникновения недоразумений и стимулирует максимальный вклад всех участников проекта в общее дело. Стоит заметить, что здесь не идет речь о финансовой или юридической информации, которая априори не может быть общедоступной. Зачастую разработчики не знают о проблемах возникающих у внедренцев, а тестирование не в курсе, что идет уже вторая неделя срыва сроков. Во избежание этого MSF предлагает проведение анализа хода работы над проектом в определённых временных точках, документирование результатов пройденных фаз проекта и обеспечение свободного общения в течение жизненного цикла проекта. Благодаря такому подходу обеспечивается выявление рисков всеми участниками проекта на ранних стадиях, что без сомнения вносит ощутимый вклад в успех решения.

Создавайте базовые версии

Под базовой версией в MSF подразумевается зафиксированное состояние любого проектного артефакта (а лучше всех одновременно) в том числе программный код, план проекта, руководства пользователя, настройки серверов и т.п. В последствии, имея базовые версии, вы сможете эффективно управлять изменениями, вернуться на шаг назад, если это необходимо и выполнять аналитику по завершению проекта.

MSF – симбиоз итеративного и фазового подхода

«Развитие, как бы повторяющее пройденные уже ступени,
но повторяющее их иначе, на более высокой базе
(“отрицание отрицания”), развитие, так сказать,
по спирали, а не по прямой линии; — развитие скачкообразное,
катастрофическое, революционное…»

Итеративный подход

Весь жизненный цикл проекта протекает в виде последовательности итераций выпуска версий. MSF рекомендует вкладывать в первую версию продукта только базовую функциональность и затем наращивать ее в следующих версиях. Для малых проектов иногда бывает достаточно одной итерации, однако все равно рекомендуется не упускать возможности версионирования т.к. это эффективный инструмент достижения успеха проекта.

Пересмотр функциональности, сетевых графиков работ, планов, спецификаций, требований и других проектных артефактов не прекращается до конца проекта и производится после каждой итерации. Такой подход позволяет планировать возможности для последующих версий, делать учёт опыта предыдущих циклов, обеспечивая гибкость и устойчивость к переменам требований. Таким образом, обеспечивается ведение «живой» документации, которая изменяется по мере эволюции проекта. В рамках одной итерации все документы (равно как и программный код) тоже развиваются итеративно. Например, план тестирования или концепция проекта (shared vision document) распространяется среди всех ролей проекта в виде «подходов» (approaches) еще до утверждения и затем итеративно эволюционируют благодаря обратной связи участников проекта до формы, подлежащей утверждению. Все изменения в уже принятые документы в рамках одной итерации (например, утверждённое ТЗ) вносятся посредством компромиссов проектной группы и согласно технологии управления изменениями, и часто имеет смысл отложить эти изменения до следующей версии, дабы не допускать разрастания рамок проекта и срыва сроков сдачи текущей версии. Создание базовой версии всех проектных документов на самых ранних этапах дает возможность всем членам проектной группы осмыслить свои задачи и цели проекта, а так же приступить к работе с минимальными задержками.

Методология MSF рекомендует делать текущие сборки программных компонент решения. Это особенно важно в сложных комплексах, где необходимо учитывать и тестировать совместимость компонент. Для этих целей Майкрософт при разработке своих продуктов выполняет ежедневные билды (daily builds). Разработка и тестирование ведутся практически одновременно, что увеличивает надежность результирующего кода. Для осуществления такого подхода к разработке необходимо вести управление конфигурациями проекта. Необходим строгий мониторинг и контроль версий программного кода, документации, аппаратных настроек и других артефактов проекта. Управление конфигурациями в свою очередь служит эффективным инструментом управления изменениями в проекте, которое регламентируют процесс внесения изменений в артефакты проекта от запроса на изменение, до включения его в базовую версию. Вот основные рекомендации MSF для выпуска версий решения:

• Создавая планы, предусматривайте версионирование.
• Прежде всего, поставляйте базовую функциональность.
• Выбирайте приоритеты, учитывая риски.
• Осуществляйте частые итерации разработки.
• Институцируйте процедуры контроля изменений в проекте.
• Не создавайте новых версий, если они не увеличивают ценность решения.

Подход, основанный на фазах и вехах

Что может быть ближе отечественной АСУшной душе, чем такой подход. Десятилетиями наши системы внедрялись поэтапно. Поковыряли ложкой в тарелке, что-то подправили, подмазали – совещание. Не годиться – на доработку. Подправили – совещание. После пятой фрикции (в лучшем случае) с горем пополам закрыли этап. И так далее. Нет-нет, мы не будем возвращаться в ностальгическое прошлое. Майкрософт не предлагает то же самое, только с перламутровыми пуговицами. В рамках одной итерации, жизненный цикл выпуска версии разбивается на пять фаз (выработка концепции (единого видения), планирование, разработка, стабилизация (тестирование), внедрение). Каждая фаза цикла заканчивается главной вехой (контрольной точкой). Соответственно главные вехи будут иметь названия: концепция продукта утверждена, планы продукта утверждены, разработка завершена, готовность решения утверждена, внедрение завершено. Веха является точкой синхронизации достигнутых результатов и ожиданий заказчика, а также анализа проектной среды. В решении о закрытии очередной фазы должны принимать участие ответственные представители всех ролевых кластеров (разработка, тестирование, внедрение, управление проектом и пр.).

В этой контрольной точке всплывают все противоречия и коллизии, возникшие за период фазы проекта. Хорошей практикой является не откладывание проблем до конца фазы, дабы не тратить время и нервы всех участников совещания в главной вехе (хотя на самом деле совещания может и не быть, а возможно просто рассылка и утверждение документов по электронной почте). В рамках фазы должны присутствовать промежуточные вехи, обозначивающие достигнутые промежуточные результаты. Например, на фазе разработки такими промежуточными вехами могут быть: билд n завершен, билд n +1 завершен и т.д. MSF дает определенные рекомендации (рассмотрены ниже) относительно промежуточных вех на каждой фазе, однако проектная команда может сформировать свои специфические для проекта и фазы промежуточные вехи.

Модель проектной группы MSF

Вот здесь начинается самое интересное и, на мой взгляд, новаторское в подходе MSF. Этой теме уделена целая «белая книга» из пакета руководств MSF и здесь мы рассмотрим только основные подходы к построению проектной группы. Существуют основные принципы и концепции модели проектной группы, которые во многом являются чуждыми большинству IT компаний. Здесь разрушаются некоторые стереотипы (например, диктаторские полномочия и соответствующая ответственность менеджера проекта) и предлагается несколько иная, более органичная структура организации рабочих групп. Подход, по меньшей мере, весьма интересен.

Проектная группа разделяется на шесть ролевых кластеров, соответствующих шести качественно различным задачам проекта.

• Управление продуктом
• Управление программой
• Разработка
• Тестирование
• Удовлетворение потребителя
• Управление выпуском

Между этими кластерами образовывается устойчивый баланс ответственности и полномочий, позволяющий команде эффективно функционировать. Как я уже упоминал, существуют основные принципы модели проектной группы.

• Распределяйте ответственности при фиксации отчетности
• Наделяйте соответствующими полномочиями ролевые кластеры.

Таким образом, все ролевые кластеры в команде равноправны . Однако иерархия отчётности при этом не нарушается, а остается прежней. Это путь к качественному продукту. Составление календарных планов работ осуществляется руководителем соответствующего ролевого кластера. Это побуждает к большей ответственности за свои сроки и обязательства, чем за те, которые на тебя спустили сверху. Каждый ролевой кластер принимает участие в принятии решений о завершении фаз проекта. Противоречия разрешаются методом компромиссов. Кроме того хорошей практикой является вход в состав группы представителей заказчика, что увеличивает заинтересованность и активное содействие внедрению со стороны заказчика. Кроме того, заказчик становится более информированным о ходе проекта т.к. информация по проекту между кластерами доступна членам команды. Например, если разрабатывается система автоматизации предприятия, хорошей, на мой взгляд, практикой будет назначить руководителем кластера Управление выпуском (по сути, это внедрение и материальное обеспечение внедрения) представителя заказчика, а исполнителями же внедрения - сотрудников компании-исполнителя. В случае успеха слава за удачу (речь идет не о финансовом поощрении) разделится поровну между всеми участниками проекта. А вот ответственность распределена в соответствии с ролевым кластером. Менеджер проекта (ролевой кластер Управление программой) будет отвечать, если проект не уложится в срок и в смету, разработка – если не выполнит разработку в названный ей же срок, тестирование – если в выпущенной версии будут возникать проблемы и т.д. Этап планирования не завершиться пока все ролевые кластеры не будут согласны с планом проекта. Это, конечно, несколько увеличит срок принятия решений, зато многократно уменьшит вероятность ошибочных решений. Что важнее решать вам – о управленец! Однако, по мнению Майкрософт, такой подход намного сильнее стимулирует творчество, ответственность, коммуникации и взаимопонимание в проектной группе, чем привычный нам, вид управления самодержца. Перечислю основные области ответственности ролевых кластеров.

Для малых проектов возможно совмещение ролевых кластеров, например Тестирование и Удовлетворение Потребителей. Однако MSF настоятельно рекомендует не объединять кластер Разработка, ни с каким из других потому же, почему нельзя отвлекать хирурга во время операции. И Управление Продуктом с Управлением Программой, потому что, как известно, единство и борьба противоположностей рождает качественное диалектическое развитие.

Рассмотрим каждую из фаз жизненного цикла проекта подробнее.

Фаза выработки концепции

Это первая фаза жизненного цикла проекта. Начинается она с формирования ядра проектной группы (если конечно это первая итерация продукта). Затем закладывается основа, фундамент, будущего решения на основе единого видения проекта (ничем не ограниченное представление о целях и задачах, стоящих перед проектной группой). После этого очерчиваются рамки (чётко описанные задачи, которые предстоит решить), однозначно описывающие то, что предстоит сделать в рамках проектных ограничений, и оцениваются риски. Нельзя смешивать эти два понятия, но и нельзя рассматривать одно в отрыве от другого. Если программист будет создавать продукт, не владея документом единого видения (shared vision document) только на основании описания рамок (scope document), он вероятнее всего не сможет создать то, что ожидает заказчик, ведь основные цели, представления и ожидания заказчика сконцентрированы именно в документе единого видения. Оба эти документа должны создаваться итеративно и тщательно, минимизируя дальнейшие отклонения от них.

Главной вехой этой фазы будет событие «Концепция утверждена». К этому моменту у заказчика и проектной группы уже сформированы устойчивые представления о задачах, функциональности и ограничениях проекта. К моменту этой вехи должны быть готовы следующие документы: общее описание и рамки проекта (vision \ scope document), документ оценки рисков, описание структуры проекта. Задачи проектной группы на этой фазе распределяются следующим образом:

MSF рекомендует обозначить следующие промежуточные вехи в течение фазы:

• Ядро проектной группы сформировано
• Черновой вариант концепции проекта составлен

Фаза планирования

Наступает важнейший этап разработки решения. Фаза планирования включает в себя подготовку проектной группой функциональной спецификации, разработку дизайнов, подготовку рабочих планов, оценку проектных затрат и сроков разработки различных составляющих проекта. Всё начинается с анализа и документирования проектных требований с разделением их на категории: бизнес-требования, потребительские требования, эксплуатационные требования и системные требования. Затем при создании функциональной спецификации нужно следить за соответствием (traceability) функциональности и существующих требований. Детализация требований происходит по известному всем аналитикам сценарию, прибегая к моделированию вариантов использования, (use - case modeling) и стори-боардингу (story-boarding), хотя у каждого опытного аналитика наверняка есть свой арсенал методов. Затем работа переходит в область проектирования (дизайна), где разрабатываются концептуальный, логический и физический дизайны, служащие уже инструментами для разработчиков. Результаты проектирования документируются в функциональную спецификацию, которая детально описывает вид и поведение всех составляющих решения. На основании спецификации работает команда разработчиков (с учётом синхронизации действий между собой), производится оценивание работ, достигается чёткое соглашение с заказчиком о том, что должно быть сделано. Как только создана спецификация, руководители ролевых кластеров смогут создать детальный план, относящийся к его роли. Примерами планов могут стать: план внедрения, план тестирования, план обучения, план мер безопасности и т.п. Затем проектная группа коллективно анализирует планы и выявляет зависимости между ними. Эти планы в последствии объединяются в сводный план проекта и сводный сетевой график работ. На этом же этапе создается также план управления рисками, к составлению которого есть смысл привлекать всех участвующих в проекте лиц.

Завершается этап вехой «Планы проекта утверждены», на момент которой уже существуют документы: функциональная спецификация, план управления рисками, сводный план и сводный календарный график работ.

Основные задачи проектной группы на фазе планирования:

MSF рекомендует создавать следующие промежуточные вехи:

• Верификация технологий
• Базовая версия функциональной спецификации создана
• Базовая версия сводного плана проекта создана
• Базовая версия сводного календарного графика работ создана
• Среды разработки и тестирования развернуты

Фаза разработки

Название фазы говорит само за себя. Однако не стоит думать, что все остальные ролевые кластеры проекта на этой фазе могут пить кофе. Все роли принимают активное и деятельно участие в тестировании, выявлении дефектов, анализе удовлетворения нужд заказчика и других задачах в соответствии со своим ролевым кластером. Равно как и сама разработка, очень редко заканчивается этой фазой (да и начинается тоже редко только с этого момента), обычно разработка продолжается и на фазе стабилизации и даже на фазе внедрения иногда приходится что-то править. К моменту завершения этой фазы разработка всех компонент завершена и решение готово к комплексному тестированию.

Задачи ролей во время этой фазы:

Рекомендуемые промежуточные вехи:

• Концепция подтверждена
• Билд n завершен, билд n +1 завершен…

Фаза стабилизации

На фазе стабилизации фокус смещается в область тестирования и документирования решения. А также создание пилотного внедрения. Результатами этой фазы являются: окончательный продукт (golden release), документация выпуска, материалы поддержки решения, результаты тестирования, проектная документация и анализ пройденной фазы.

Задачи проектной группы на этой фазе:

Фаза внедрения

Наконец-то. Если проект докатился до этой фазы, то можно считать, что треть пути пройдена... Это конечно шутка, так быть не должно, хотя так бывает довольно часто, особенно если были допущены ошибки на начальных этапах проекта. На этом этапе группа внедряет решение, стабилизирует его и, пробиваясь сквозь противоборство службы сопровождения и поддержки, таки передает решение им, получив одобрение заказчика. И, наконец, получает вожделенный акт. Однако согласно MSF и вопреки реалиям работа группы на этом не заканчивается. Группа работает над сбором метрик и анализом проекта, дабы бесценный опыт, полученный в результате проекта, не канул в дебрях короткой памяти человеческой.

Результатами фазы будут: информационные системы эксплуатации и поддержки, процедуры и процессы, базы знаний, отчёты, журналы протоколов, версии проектных документов, отчёт о завершении проекта, окончательные версии всех проектных документов, описание последующих шагов.

Задачи группы на фазе внедрения:

Не нужно также забывать, что после внедрения первой версии продукта, может последовать следующая итерация жизненного цикла.

Замечания

Существуют проекты, в которых может отсутствовать фаза внедрения или разработки (например, разработка игры, или адаптация 1С).

В первую очередь реализовуйте рискованные нововведения, минимизируя влияние риска на весь проект.

Деятельность каждой фазы не ограничивается ее рамками, как было уже сказано, разработка продолжается почти всегда.

Длительность фаз может быть совсем не одинакова, как изображено на картинках (суть это замечания взята с текста MSF, я бы в жизни не догадался его написать).

Резюме

Подытожим. Методология очень интересна, если не сказать больше. Ее можно использовать как эффективный инструмент, подходя к нему с творческой изобретательностью и осмысленностью. Нет, наверное, такой методологии управления, строгое соответствие которой, обеспечит успешность проекта. Не нужно воспринимать MSF как догму или панацею. Можно её адаптировать под свои нужды или использовать только фрагменты или концепции применимые в Вашем проекте.

Например, в качестве дополнительного фактора проекта при поиске компромисса (наравне с ресурсами, временем и возможностями) может выступать безопасность или можно добавить дополнительную промежуточную веху «Контроль безопасности» в конце каждой фазы проекта, если того, конечно, требует ваша проектная среда.

Удачных проектов!

Дополнительная информация

• Опубликована русская документация по MSF
• Управлять проектами станет проще
• Управление изменениями: неужели между качеством и скоростью разработки программного обеспечения всегда должен быть компромисс?
• Подробнее о продуктах Microsoft
• Курсы по продуктам Microsoft
• Обратиться в Interface Ltd. за дополнительной информацией/по вопросу приобретения продуктов
• Приобрести продукты Microsoft в Интернет-магазине ITshop.ru

За дополнительной информацией обращайтесь в компанию Interface Ltd.

Обсудить на форуме

INTERFACE Ltd. Телефон/Факс: +7 (495) 925-0049 Отправить E-Mail http://www.interface.ru

Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру