Архитектура продукта
Ролевая группа выполняет следующие задачи:
формулирует спецификацию решения и разрабатывает его архитектуру;определяет структуру развертывания (внедрения) решения.
Что такое методология?
"Толковый словарь русского языка" С.И. Ожегова определяет понятие "Методология" как "Принципы и способы организации теоретической и практической деятельности. Совокупность методов, применяемых в какой-либо науке" [4.12].
Применительно к разработке программного обеспечения это определение можно переформулировать так: "Методология есть принципы и способы организации деятельности проектной группы для создания программного продукта".
Разберем формулировку на элементы, начиная с конца.
Во-первых, "программный продукт". С этим понятием мы познакомились еще на первой лекции. Именно продукт является конечной целью в любой методологии. Отметим также, что в последнее время вместо термина "программный продукт" все чаще используют термин "решение" ("solution"), а компании-разработчики вместо фразы "мы поставляем программные продукты" все чаще говорят "мы поставляем (готовые) решения".
Во-вторых, "проектная группа". Синонимами, которые и мы нередко будем использовать, являются "команда разработчиков" или просто "команда". В любом случае за этим скрывается коллектив людей, непосредственно занятых созданием "готового решения". Именно люди являются точкой приложения любой методологии, поскольку, как уже сказано, в организации деятельности людей и состоит основное назначение методологий.
Таким образом, в оставшейся части курса речь пойдет о "святой троице": проектная группа, программный продукт, методология.
произошло разделение методологии на
Важное нововведение состоит в том, что в MSF 4. 0 произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.
Все оставшееся время в течение курса мы будем работать в рамках первого направления. Что касается второго, то он предлагает в существенной степени формализованный подход к процессу разработки, чем-то сближающийся с RUP. В частности, помогает организациям работать на третьем уровне модели CMMI (Capability Maturity Model Integration4)). Если говорить кратко, MSF for CMMI Process Improvement - это строгий, документированный процесс, рассчитанный на большие команды и длительный процесс разработки, что предполагает больше верификации, больше планирования, процедуры утверждения, отслеживание потраченных ресурсов и т.д.
Формирование команды Модель проектной группы MSF for Agile Software Development
В этом разделе6) мы рассмотрим, наверное, самую главную из отличительных черт MSF в сравнении с другими методологиями - модель проектной группы и принципы, положенные в основу построения команды.
в отличие от предыдущих редакций
У MSF 4.0 в отличие от предыдущих редакций появилась инструментальная поддержка в среде разработки Microsoft Visual Studio 2005 Team System. Фактически среда Visual Studio 2005 может выступать теперь в качестве интегрирующего средства, из которого можно работать со всеми инструментами, обеспечивающими стадии процесса разработки от создания планов проекта до проведения различных видов тестирования, включая создание и выполнение тестовых сценариев.
Источники информации
Источники, в которых можно почерпнуть информацию о методологии MSF, можно разделить на три типа:
Основным источником, безусловно, являются белые книги (в настоящий момент доступные для версии MSF 3.0).
Немало сведений можно найти на сайте компании Microsoft, включая разделы портала TechNet (http://www.microsoft.com/rus/technet/default.mspx).
Кроме того, желающие могут прослушать курсы, связанные с MSF (например, [4.4, 4.5]).
Наконец, информация по последней версии MSF 4.0 может быть получена на http://msdn.microsoft.com/vstudio/teamsystem/msf.
К сожалению, с источниками информации по MSF 4.0 дела обстоят несколько хуже, чем по третьей версии. Наиболее полную информацию на данный момент можно получить на http://www.microsoft.com/msf.
Историческая справка
В 1993 году, стремясь достичь максимальной отдачи от IT-проектов, компания Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. 2) Эти знания базировались на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Microsoft и лучшем из того, что накопила на тот момент IT индустрия.
Вторая версия методологии датируется 1998 годом. Версия MSF 3.0 была представлена в 2001 году, а последняя - MSF 4.0 в 2005.
представляет собой эволюционное развитие предыдущей
MSF 4.03) представляет собой эволюционное развитие предыдущей версии методологии. Тем не менее, изменений внесено довольно много. В этом разделе мы обсудим основные.
Прежде всего, в новой редакции методологии делается упор на то, что MSF - это не просто набор рекомендаций, MSF - это образ мыслей (mindsets![4.15]
Рис. 4.1. "Образ мыслей" MSF 4.0. Источник: MSF for Agile Software Development Process Guidance
MSF предлагает стремиться к созданию культуры, которая бы помогала разработчикам успешно выполнять проекты. При этом под образом мыслей понимается набор ценностей, которые определяют, как мы интерпретируем ситуации и реагируем на них. Образ мыслей помогает членам команды принимать решения, приоритезировать работу, представлять свои роли в команде и взаимодействовать с другими участниками проекта.
Основные концепции методологии MSF
Теперь перейдем непосредственно к Microsoft Solutions Framework (MSF).1)
Приближение первое. MSF - методология разработки программного обеспечения от компании Microsoft, опирающаяся на практический опыт компании и описывающая управление людьми и управление процессами в ходе разработки решения. Взглянув на список программ, которые установлены на типовом персональном компьютере, нетрудно прийти к мысли, что практики, которые использовала Microsoft в своей работе, имеют под собой довольно весомые основания в виде множества выпущенных продуктов самой различной сложности, начиная от редактора Notepad и заканчивая операционными системами семейства Windows. В силу сказанного MSF не есть чисто теоретический взгляд на процесс разработки, напротив, методология предлагает не только концепции и модели, но и сугубо практические приемы и советы.
Приближение второе. MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в пяти документах, так называемых "белых книгах" ("whitepapers"), каждый из которых охватывает определенную дисциплину или модель MSF:
Модель процессов MSFМодель проектной группы MSFДисциплина управления проектами MSFДисциплина управления рисками MSFДисциплина управления подготовкой MSF
Модель проектной группы мы подробно обсудим далее в этой лекции, модели процессов посвятим половину следующей. Что касается дисциплин, то мы потратим некоторое время на знакомство с управлением рисками и весьма детально изучим управление проектами. Управление подготовкой останется за рамками нашего курса (интересующихся отсылаем к соответствующей белой книге, доступной, например, на http://www.microsoft.com/rus/msdn/msf/default.mspx).
Приближение третье. MSF предлагает несколько оригинальных идей, с которыми мы подробно будем знакомиться далее, а пока просто перечислим их:
Единое видение проектаТреугольник и матрица компромиссов"Проектная группа - команда равных"Управление рисками…
В качестве комментария. Конечно, MSF не единственная методология разработки программных продуктов. Широко известна, например, технология Rational Unified Process (RUP) (см., например, http://ru.wikipedia.org/wiki/RUP), имеющая инструментальную поддержку в виде различных программных систем, наиболее известная из которых - Rational Rose (http://www-306.ibm.com/software/rational/) и предлагающая весьма сильно формализованный подход к процессу разработки. До версии 3.0 включительно MSF существенно отличалась от RUP - во-первых, намного меньшей формализованностью, во-вторых, не просто отсутствием инструментов, а скорее отсутствием необходимости в таких инструментах. Идеология MSF предполагала, что концепции, которые MSF предлагает разработчикам, могут и должны быть адаптированы к требованиям конкретного проекта. В последней версии (4.0) идеология MSF претерпела некоторые изменения, но об этом дальше.
Основные положения MSF for Agile Software Development
MSF for Agile Software Development в определенной степени отражает тенденции последнего времени, связанные с появлением методологий, предлагающих максимально облегченный и гибкий подход к процессу разработки. Одним из примеров подобных методологий является Extreme Programming (XP5)).
Agile направление в MSF ориентируется на небольшие команды (5-6 человек), предполагает, что информация о разрабатываемом продукте не просто выясняется в процесе разработки, а может и будет изменяться по ходу. Таким образом, первая рабочая версия системы должна быть создана как можно раньше, а сам продукт фактически проявляется из прототипов путем повторения итераций в цикле разработки.
Методология MSF содержит весьма много элементов, в частности:
рекомендованные процессы создания IT-проектов; структуру итераций; роли членов команды; шаблоны документов (Excel, Word); шаблоны Microsoft Project; отчеты; портал проекта (шаблон сайта SharePoint).
MSF for Agile Software Development ориентирован на использование итеративной и эволюционной модели процесса разработки и основан на сценариях использования.
Основные принципы построения команды
Методология MSF считает, что успешная работа команды над проектом существенным образом зависит от ее структуры и распределения зон ответственности ролевых групп (более подробно о составе проектной группы далее) внутри команды. Построение команды в MSF соответствует ряду ключевых концепций (key concepts), часть которых кажутся самоочевидными, другие чем-то сродни "ноу-хау".
К самоочевидным можно отнести:
Концентрация на нуждах заказчика (customer-focused mindset) - главный приоритет любой хорошо работающей проектной группы. Означает обязательное понимание бизнес-задач заказчика и стремление к их решению со стороны команды. Не менее важным является активное участие заказчика в проектировании решения и получение его отзывов в ходе процесса разработки.Нацеленность на конечный результат (product mindset) - каждый участник проектной группы должен рассматривать собственную работу в качестве самостоятельного проекта или же вклада в какой-либо больший проект. Установка на конечный продукт означает, что получению конечного результата проекта уделяется больше внимания, чем процессу его достижения. Из этого не следует, что сам процесс может быть плох или непродуман - просто он существует для получения конечной цели, а не ради себя самого.Установка на отсутствие дефектов (zero-defect mindset) - это стремление к высочайшему уровню качества. Она означает, что цель команды - выполнение своей работы с максимально возможным качеством, в идеале таким образом, что если от команды потребуют поставить результат завтра, она будет способна поставить что-то работающее. В успешной команде каждый сотрудник чувствует ответственность за качество продукта. Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой.
Концепции, которые в определенном смысле можно отнести к "ноу-хау" методологии MSF:
"Проектная группа - команда равных" (teem of peers). Концепция означает равноправное положение каждой из ролей в команде. Чтобы достичь успеха в рамках команды равных, каждый из ее членов, независимо от роли, должен нести ответственность за качество продукта, понимать интересы заказчика и сущность решаемой бизнес-задачи.
В то же время, принятие решения методом консенсуса между ролями не тождественно принятию решения методом консенсуса между сотрудниками. Каждая ролевая группа требует определенной организационной иерархии для распределения работы и управления ее ресурсами.Стремление к самосовершенствованию (willingness to learn) - это приверженность идее неустанного саморазвития посредством накопления опыта и обмена знаниями. Оно позволяет членам проектной группы извлекать пользу из отрицательного опыта сделанных ошибок, равно как и воспроизводить успехи, используя проверенные методы работы других людей. По окончанию основных фаз проекта и по завершению проекта в целом предполагается проведение открытых обсуждений его состояния и доброжелательный, но объективный анализ.
К концепции команды равных в MSF тесно примыкает идея о том, что каждая ролевая группа имеет зону ответственности и защищает интересы заинтересованных лиц из этой зоны (более подробно об этом далее).
Модель проектной группы в MSF может масштабироваться в зависимости от числа участников.
Разработка
Ролевая группа выполняет следующие задачи:
определяет детали физического дизайна;оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна; разрабатывает или контролирует разработку элементов; подготавливает продукт к внедрению; консультирует команду по технологическим вопросам.
Рекомендации по возможному объединению ролей
Модель проектной группы в MSF может масштабироваться в зависимости от числа участников. Масштабирование модели проектной группы MSF for Agile Software Development на случай больших команд выходит за рамки нашего курса. Мы рассмотрим ситуацию, когда один человек может выполнять в проектной группе несколько ролей (небольшая команда, относительно несложный проект).
В этом случае MSF предлагает рекомендации по возможному объединению ролей. Рассмотрим их в виде таблицы.
| Нет | Да | Да | Не желательно | Не желательно | Не желательно |
| Нет | Нет | Нет | Да | Да | Не желательно |
| Да | Нет | Нет | Не желательно | Не желательно | Да |
| Да | Нет | Нет | Нет | Нет | Нет |
| Не желательно | Да | Не желательно | Нет | Да | Да |
| Не желательно | Да | Не желательно | Нет | Да | Не желательно |
| Не желательно | Не желательно | Да | Нет | Да | Не желательно |
Ролевые группы и роли
Методология MSF основана на постулате о качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждая из ее ролевых групп, определяемых моделью, ассоциирована с одной из целей и работает над ее достижением.
MSF for Agile Software Development выделяет 7 ролевых групп [4.15]:
Управление программой (program management)Архитектура продукта (architecture) Разработка (development) Тестирование (test) Управление выпуском (release operations) Удовлетворение потребителя (user experience) Управление продуктом (product management)
Рис. 5.2. Модель команды в MSF 4.0 - ролевые группы. Источник: MSF for Agile Software Development Process Guidance
и 6 ролей [4.15]:
менеджер проекта (project manager) - ролевая группа Управление программойархитектор (archrect) - ролевая группа Архитектураразработчик (developer) - ролевая группа Разработкатестер (tester) - ролевая группа Тестированиерелиз-менеджер (release manager) - ролевая группа Управление выпускомбизнес-аналитик (business analyst) - ролевые группы Управление продуктом и Удовлетворение потребителя
Рис. 4.3. Модель команды в MSF 4.0 - роли. Источник: MSF for Agile Software Development Process Guidance
Тестирование
Ролевая группа выполняет следующие задачи:
обеспечивает обнаружение всех дефектов;разрабатывает стратегию и планы тестирования;осуществляет тестирование.
Учебный пример Формирование команды
Применим полученные знания к сформулированному на предыдущей лекции учебному примеру "Система бронирования билетов для авиакомпании".
Пусть проектная группа состоит из 6 человек. Представим возможное распределение ролей, позволяющее выполнить поставленную в учебном примере задачу.
Несмотря на то, что модель проектной группы MSF выделяет ровно 6 ролей, идею о том, чтобы каждому участнику нашей команды выдать по одной роли и на этом успокоиться, следует оставить, как в корне неверную. При таком подходе, мы должны будем взвалить тяжесть разработки системы на одного человека, что, конечно же, не приведет к успеху. Отсюда очевидно, что разработчиков должно быть больше одного, а остальные роли придется совмещать. Как именно, сейчас обсудим.
Во-первых, следуя рекомендациям MSF по объединению ролей, дадим одному из разработчиков еще и роль архитектора.
Во-вторых, отбросим в сторону другую крайность - разработчиками не могут быть все. Отдельный участник команды должен заниматься тестированием. Ему же можно выдать "в нагрузку" роль бизнес-аналитика.
Незадействованными остались ролевые группы "Управление программой" и "Управление выпуском". Соответственно роли менеджер проекта и релиз-менеджер достаются еще одному участнику.
В итоге получаем следующее (возможное) распределение:
Участник 1 - менеджер проекта и релиз-менеджерУчастник 2 - архитектор и разработчикУчастник 3 - бизнес-аналитик и тестерУчастник 4 - разработчикУчастник 5 - разработчикУчастник 6 - разработчик
Удовлетворение потребителя
Ролевая группа выполняет следующие задачи:
представляет интересы потребителя в команде; организует работу с требованиями пользователя; определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта; определяет требования к системе помощи и её содержание; разрабатывает учебные материалы и осуществляет обучение пользователей.
Управление продуктом
Ролевая группа выполняет следующие задачи:
выступает в роли представителя заказчика; организует работу с требованиями заказчика; формирует ожидания заказчика; формирует общее видение и рамки проекта; определяет компромиссы между параметрами "возможности продукта / время / ресурсы"; организует маркетинг; разрабатывает, поддерживает и исполняет план коммуникаций.
Управление программой
Ролевая группа выполняет следующие задачи:
управляет процессом разработки с целью получения готового продукта в отведенные сроки; регулирует взаимоотношения и коммуникацию внутри проектной группы; следит за временным графиком проекта и готовит отчетность о его состоянии; разрабатывает, поддерживает и исполняет сводный план и календарный график проекта; организует управление рисками.
Управление выпуском
Ролевая группа выполняет следующие задачи:
представляет интересы отделов поставки и обслуживания продукта; организует снабжение проектной группы; организует внедрение продукта; вырабатывает компромиссы в управляемости и удобстве сопровождения продукта; организует сопровождение и инфраструктуру поставки.
Вспоминая предыдущую лекцию
Наша предыдущая лекция была посвящена визуальному моделированию в процессе анализа и проектирования и основам языка UML.
При этом сначала в качестве введения мы кратко повторили:
типовую схему решения задач с использованием вычислительной техники;основные положения алгоритмической и объектной декомпозиции;принципы объектного подхода к анализу и проектированию.
Далее мы обсудили, чем вызвана необходимость в визуальном моделировании программных систем и рассмотрели историю языка UML.
Затем была рассмотрена структура и основные понятия UML, представлена постановка учебной задачи, на которой далее будет иллюстрироваться изучаемый материал на протяжении всего курса ("Система бронирования билетов для авиакомпании").
Наконец, мы подробно осветили средства UML для:
визуального описания функциональной модели: актеры, варианты использования, диаграммы вариантов использования, диаграммы действия;описания структуры системы: классы, объекты и интерфейсы; пакеты, подсистемы и компоненты;описания отношений между элементами модели: зависимость, ассоциация, обобщение, реализация.
Задачи ролевых групп и взаимодействие с заинтересованными лицами
Для каждой ролевой группы, помимо зоны ответственности, определены заинтересованные стороны, как внутри, так и вне команды, с которыми группа должна взаимодействовать и чьи интересы представлять/отстаивать при принятии решений.
Зоны ответственности ролевых групп
Каждая ролевая группа в команде имеет зону ответственности (advocacy), в которой роль из этой группы имеет решающий голос.
Управление программой - отвечает за управление проектом, за то, что ожидания заинтересованных сторон будут верно поняты и проведены через проект.Архитектура продукта - отвечает за систему в целом, вырабатывает архитектуру решения, включая сервисы, технологии и стандарты, которые будут использованы в ходе работы над решением. Разработка - отвечает за проектирование и осуществление реализации. Тестирование - отвечает за качество решения с точки зрения заказчика и будущих пользователей. Управление выпуском - отвечает за гладкое внедрение решения в инфраструктуру заказчика. Удовлетворение потребителя - отвечает за понимание потребностей пользователей и их надлежащую реализацию в решении. Управление продуктом - представляет бизнес-сторону проекта и обеспечивает его согласованность со стратегическими целями заказчика (успешное получение бизнес-отдачи от внедрения разрабатываемого решения, которое в результате сможет получить заказчик).
Будьте готовы к внедрению сегодня
Работа проектной группы в идеале должна быть построена так, чтобы при возникновении такой потребности у заказчика текущее состояние разрабатываемого решения могло быть немедленно внедрено (естественно с той функциональностью, которая в данный момент реализована). Это означает, что итерации работы над проектом должны быть максимально короткими, и в каждый момент времени должна существовать текущая работоспособная версия решения. Такой подход дает возможность раннего обнаружения рисков, ошибок, пропущенных или недопонятых требований, дает возможность своевременно получать обратную реакцию от заказчика, а, значит, сокращает затраты.
Цикличность процесса разработки
На каждом уровне процесса создания решения MSF предполагает цикличность. Создание версии продукта - цикл из итераций. Итерация - цикл из ежедневно собираемых билдов. Билд - цикл изменений, вносимых в систему контроля версий[5.11].
Рис. 5.6. Циклы процесса разработки. Источник: MSF for Agile Software Development Process Guidance
Фазы и вехи процесса разработки
Модель MSF покрывает процесс создания решения с самого его начала и до момента окончательного внедрения. Весь процесс создания решения разбит на пять фаз. Каждая из них заканчивается главной вехой, результаты которой становятся видимыми за пределами проектной команды [5.1].
Рис. 5.7. Фазы и вехи модели процессов MSF. Источник: белая книга
Веха является точкой синхронизации достигнутых результатов и ожиданий заказчика, а также анализа проектной среды. В решении о закрытии очередной фазы должны принимать участие ответственные представители всех ролевых групп.
В рамках фазы обычно присутствуют промежуточные вехи, обозначающие достигнутые промежуточные результаты. MSF дает определенные рекомендации (будут рассмотрены при изучении соответствующих фаз) относительно промежуточных вех на каждой фазе, однако проектная команда может сформировать свои специфические для проекта и фазы промежуточные вех.
Матрица компромиссов проекта
Другое полезное средство управления проектными компромиссами - матрица компромиссов проекта (project tradeoff matrix).
Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях.
Возможный вариант такой матрицы представлен на рисунке.
Рис. 5.4. Матрица компромиссов (возможный вариант). Источник: белая книга
Матрица компромиссов [4.1] помогает обозначить проектное ограничение, воздействие на которое практически невозможно (колонка "Фиксируется"), фактор, являющийся в проекте приоритетным (колонка "Согласовывается"), и третий параметр, значение которого должно быть принято в соответствии с установленными значениями первых двух величин (колонка "Принимается").
Модель процессов MSF for Agile Software Development
Модель процессов MSF2) представляет общую методологию разработки и внедрения IT- решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral).
Рис. 5.2. Модели процесса (слева направо): каскадная, спиральная, MSF. Источник: белая книга
Процесс MSF ориентирован на "вехи" (milestones) - ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата.
Модель процессов MSF учитывает постоянные изменения проектных требований. Она исходит из того, что разработка решения должна состоять из коротких циклов, создающих поступательное движение от простейших версий решения к его окончательному виду.
Основные сведения о рисках
Прежде всего, определим, что такое "риск". Заглянем в "Толковый словарь русского языка" С.И. Ожегова. "Риск - 1. Возможность опасности, неудачи. 2. Действие наудачу в надежде на счастливый исход" [12]. Отметим, что понятие "риск" включает в себя два по сути противоположных толкования: одно со знаком минус, второе со знаком плюс.
Риск проекта (project risk) понимается в MSF именно в таком полном виде - как всякое событие или условие, которое может оказать как негативное, так и позитивное влияние на итоги проекта. Такое же расширенное понимание спекулятивного риска (speculative risk) присутствует, например, в финансовой индустрии, где решения в условиях неопределенности могут привести к получению прибыли точно так же, как и к убыткам. Указанное понимание противоположно понятию чистого риска (pure risk) в индустрии страхования, где неопределенности связываются только лишь с потенциальными убытками в будущем.
Важно отметить, что риски не есть проблемы. Проблемы - это нечто, имеющие место в настоящее время, в то время как риски относятся к будущему и носят вероятностный характер (могут и не состояться). Однако риски могут стать проблемами, если ими эффективно не управлять.
Цель управления рисками - максимизировать их положительное влияние (открывающиеся возможности), но при этом минимизировать связанные с ними негативные факторы (убытки).
Дисциплина управления рисками в MSF основана на убеждении, что такое управление должно выполняться превентивно; это часть формального и систематического процесса, трактующего усилия, затрачиваемые на управление рисками, с позитивной точки зрения.
Говоря о рисках, MSF выделяет несколько ключевых концепций:
Риск - неотъемлемая часть всякого проекта или процесса. Несмотря на то, что различные проекты могут быть связаны с большим или меньшим числом рисков, не существует ни одного проекта, полностью свободного от них. Цель состоит не в том, чтобы избежать рисков, а в том, чтобы предвосхищать потенциальные проблемы и заблаговременно готовиться к их решению, если они возникнут.Выявление рисков нужно всячески одобрять. Проектная группа должна смотреть на выявление рисков как на позитивную деятельность. Знание о существовании рисков - необходимое условие эффективной работы над ними. Следовательно, перспективы успеха проектной группы от проведения работы по выявлению рисков лишь увеличиваются.Оценка рисков должна вестись постоянно. Обстоятельства, в которых проектная группа работает над созданием решения, обладают постоянной изменчивостью, следовательно, команда должна регулярно проводить переоценку выявленных рисков и постоянно следить за появлением новых. Управление рисками должно быть интегрировано в общий жизненный цикл проекта.О положении дел в проекте нужно судить не по количеству рисков, связанных с его выполнением, а по степени проработанности процедуры их выявления, анализа и управления ими.
Планирование управления рисками
Во время проектных фаз выработки концепции и планирования (изучению этих фаз будет посвящена лекция 7) проектная группа должна разработать формальный документ, описывающий управление рисками в проекте. В этом документе должны быть даны ответы на целый ряд вопросов, из которых здесь мы рассмотрим основные.
Как будет реализовываться процесс управления рисками? Из каких шагов состоит этот процесс?Кто будет осуществлять действия по управлению рисками? Какие для этого требуются навыки/квалификация? Требуется ли дополнительное обучение?Как будут строиться планы управления рисками и планы мероприятий по смягчению возможных негативных последствий?Как деятельность по управлению рисками будет интегрирована в общий план проекта?Какие действия будут предпринимать отдельные члены проектной группы для управления рисками?Какие ресурсы доступны для управления рисками?Каковы временные ограничения в мероприятиях, связанных с управлением рисками?
Часть вопросов, которые также должны быть учтены, мы сознательно опустили - интересующихся отсылаем к соответствующей белой книге [5.2].
Поскольку риски являются неотъемлемой частью всех фаз всех проектов от начала и до конца, должны быть изначально выделены и должным образом распределены ресурсы, необходимые для эффективного управления рисками. Планирование управления рисками осуществляется проектной группой во время фаз выработки концепции и планирования, и результирующий план управления рисками должен определять конкретные действия, ответственность за которые возложена на определенных членов проектной группы. Эти задачи должны быть интегрированы в сводный план проекта (master project plan) и в сводный календарный график проекта (master project schedule).
Поощряйте свободный обмен информацией в проекте
Модель процессов MSF считает очень важным открытый обмен информацией как внутри команды, так и с ключевыми заинтересованными лицами. Свободный обмен информацией не только сокращает риск возникновения недоразумений, недопонимания и неоправданных затрат, но и обеспечивает максимальный вклад всех участников проектной группы в снижение существующей в проекте неопределенности. Естественно речь здесь не идет об информации финансовой или имеющей статус коммерческой или иной тайны.
Процесс управления рисками
Дисциплина управления рисками MSF отстаивает превентивное управление рисками, непрерывную оценку имеющихся рисков и интеграцию этих процессов в общую деятельность по принятию решений на протяжении всего жизненного цикла проекта или бизнес-процесса.
Процесс управления рисками MSF определяет шесть логических шагов, посредством которых проектная группа управляет текущими рисками, разрабатывает и исполняет стратегии управления рисками и извлекает уроки из своего опыта для использования на уровне всего предприятия.[5.2]
Рис. 5.1. Процесс управления рисками MSF. Источник: белая книга
Выявление рисков (risk identification) - этап, позволяющий членам проектной группы вынести на обсуждение всей команды факты наличия рисков. Выявление рисков является начальной стадией процесса управления ими. Оно должно быть осуществлено как можно раньше, и к нему необходимо постоянно возвращаться на протяжении всего жизненного цикла проекта.
Анализ рисков (risk analysis) - этап преобразования накопленных во время предыдущего шага оценок и данных в форму, позволяющую осуществить приоритезацию рисков. Приоритезация рисков (risk prioritization) позволяет проектной группе управлять наиболее важными из них, выделяя для этого необходимые ресурсы.
Планирование рисков (risk planning) выполняется исходя из информации, полученной на этапе их анализа, и имеет целью выработку стратегий, планов и конкретных шагов. Календарное планирование рисков (risk scheduling) интегрирует эти планы в повседневный процесс управления проектом, обеспечивая непрерывность управления рисками. Эта стадия напрямую увязывает планирование рисков с планированием проекта в целом.
Мониторинг рисков (risk tracking) выполняется для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов. Мониторингу должны быть подвергнуты сделанные оценки вероятности (probability) риска, его угрозы (impact), ожидаемая величина риска (exposure) и прочие факторы, способные повлиять на приоритет рисков. Наблюдению подвергаются также составленные планы, имеющиеся ресурсы и принятый календарный график.
Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения. Этот процесс также включает в себя инициирование изменений всего проекта (project change control requests), если изменения в состоянии рисков либо в соответствующих планах влияют на прогнозируемый объем работы, требуемые ресурсы или сроки.
Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта.
Необходимо отметить, что описанные этапы являются логическими шагами и не обязательно должны следовать друг за другом в строгом хронологическом порядке. Проектные группы могут циклически повторять шаги выявления-анализа-планирования по мере обнаружения дополнительных факторов, влияющих на проект.
Проявляйте гибкость - будьте готовы к изменениям
MSF основывается на принципе непрерывной изменяемости условий проекта при неизменной эффективности управленческой деятельности. Проектная группа должна быть готова к переменам, и методология MSF предоставляет эффективный инструментарий для адекватной и своевременной реакции на изменения в проектной среде.
Схема процесса разработки
Модели процессов описывают последовательность действий, осуществляемых в ходе реализации проекта. Можно сказать, что они задают тем самым жизненный цикл проекта. Спектр моделей, применяемых в настоящее время различными организациями, весьма широк. Среди них есть и модель процессов MSF, возникшая на основе используемого в компании Microsoft подхода к разработке программных приложений. В результате своего развития она объединила ряд наиболее эффективных принципов других известных моделей процессов, сформировав при этом единую базу для работы над проектами любых типов: ориентированных на фазы (phase-based), основанных на вехах/контрольных точках (milestone-driven) и итеративных (iterative).
Следите за качеством продукта
MSF настаивает на том, что каждый участник проектной группы должен ощущать ответственность за качество разрабатываемого решения. Она не может быть делегирована одним членом команды другому или же от одной ролевой группы другой. Несмотря на наличие в команде ролевых групп "Удовлетворение потребителя" и "Тестирование", прямая задача которых - следить за качеством решения и повышать его, все остальные ролевые группы также постоянно должны иметь в виду нужды конечного пользователя.
Создавайте "единое видение проекта"
Успех коллективной работы над проектом немыслим без наличия у членов проектной группы и заказчика единого видения (shared vision), т.е. четкого, и, самое главное, одинакового, понимания целей и задач проекта. Изначально понимание того, что должно быть достигнуто в ходе работы над проектом, у заказчика может (и нередко) не совпадать с пониманием проектной группы. Лишь наличие единого видения способно внести ясность и обеспечить движение всех заинтересованных в проекте сторон к общей цели.
Формирование единого видения и последующее следование ему являются столь важными, что модель процессов MSF выделяет для этой цели специальную фазу (фаза "Выработка концепции"), которая заканчивается соответствующей вехой.
Ставьте "вехи"
Каждая итерация, каждая фаза процесса создания решения должна заканчиваться некоторым зримым результатом, некоторой вехой (milestone). Наличие вех позволяет проектной группе и заказчику видеть движение проекта вперед.
Структурные единицы схемы
MSF for Agile Software Development поддерживает быструю итеративную разработку. Проектирование, разработка, тестирование выполняются в перекрывающих друг друга итерациях, каждая из которых фокусируется на реализации отдельных аспектов решения [5.11].
Рис. 5.5. Итерации процесса разработки. Источник: MSF for Agile Software Development Process Guidance
Короткие итерации позволяют свести к минимуму влияние ошибок в понимании и формулировании требований, дают быструю обратную реакцию о точности проектных планов.
Каждая итерация должна завершаться получением результата в виде стабильной части целого продукта.
Треугольник компромиссов
Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник компромиссов (tradeoff triangle) [5.1].
Рис. 5.3. Треугольник компромиссов. Источник: белая книга
После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.
Нахождение верного баланса между ресурсами, временем разработки и возможностями - ключевой момент в построении решения, должным образом отвечающего нуждам заказчика.
Учебный пример Выделение рисков
Вернемся к учебному примеру "Система бронирования билетов для авиакомпании".
Выделим некоторые возможные риски.
| 1 | Не успеем сдать проект во время | Из-за неправильной организации работ затратим больше времени, чем заявлено в контракте |
| 2 | Не хватит квалификации персонала | При создании продукта используется новая технология (JNL), персонал с ней не работал и может не разобраться |
| 3 | Один из членов команды заболеет | Команда не многочисленна и отсутствие одного из членов команды ведет задержке в работах |
| 4 | Заказчик изменит требования | В данный момент требования согласованы с заказчиком и утверждены, но в процессе работы заказчик может захотеть добавить в решение новую функциональность |
| 5 | Авария на подстанции, отключение электричества | Потеряем время, пока авария будет устраняться |
| 6 | Отключат доступ к Интернету | Ухудшится возможность быстрого получения необходимых сведений, пропадет электронная почта и другие средства коммуникации |
| 7 | Заказчик вовремя не оплатит счета | Задержка в покупке необходимого оборудования |
| 8 | Из-за необнаруженной вовремя ошибки система нанесет урон заказчику | На время устранения ошибки пассажиры не смогут заказывать билеты через систему. Потребуется "ручная" работа персонала. Компания потеряет возможных клиентов и часть прибыли |
| 9 | На стороне заказчика нет заявленной в требованиях аппаратуры | Не сможем адекватно развернуть систему |
| 10 | Не сможем подобрать необходимые кадры | Придется совмещать роли |
Мы выделили не так уж и много рисков, однако можно заметить, что они происходят из самых разных областей и связаны с людьми (риск №3), с процессами (риски №1, №8, №10), с технологиями (риск №2), с внешними условиями (риски №5, №6), с заказчиком (риски №4, №7, №9). Помимо представленных риски могут иметь и другие источники.
Далее MSF рекомендует для каждого риска представить формулировку - выражение на естественном языке причинно-следственной связи между реально существующим фактором проекта и потенциально возможным, еще не случившимся событием или ситуацией.
Первая часть формулировки риска называется условием (condition) и содержит описание существующего фактора или особенности проекта, которые, по мнению проектной группы, могут сделать результат проекта убыточным либо же сократить получаемую от проекта прибыль. Вторая часть формулировки риска называется (по)следствием (consequence). Она описывает ту нежелательную ситуацию, которой следует избежать.
В качестве примера представим формулировки некоторых выявленных выше рисков.
| Нехватка кадров | Один из членов команды заболеет | Функции заболевшего придется передать другому | Потери времени |
| Форс-мажор | Авария на подстанции, отключение электричества | Потеряем время, пока авария будет устраняться | После устранения аварии придется увеличить нагрузку, чтобы наверстать потери времени |
| Организация работы | Не сможем подобрать необходимые кадры | Участникам придется совмещать роли | Дополнительные трудозатраты, снижение качества продукта, увеличение времени разработки решения |
Управление компромиссами
В силу свойственной IT-проектам неопределенности и рискованности, одним из ключевых факторов их успеха являются эффективные компромиссные решения (trade-offs).
Управление рисками как составная часть жизненного цикла проекта
Процесс управления рисками в MSF тесно интегрирован с общим жизненным циклом проекта. Оценка рисков может быть начата даже на этапе выработки концепций, поскольку в этот момент проектная группа и заинтересованные стороны начинают формировать видение проекта, его границ и рамок. По результатам анализа и планирования рисков необходимые планы по предотвращению и смягчению последствий должны быть сразу включены в календарный график проекта и его сводный план.
В ходе выполнения проекта команда постоянно проводит мониторинг рисков, осуществляет необходимые корректирующие действия в соответствии с расписанием и планом проекта, и при наступлении связанных с триггерами рисков событий.
Действия по выявлению и анализу новых рисков могут проводиться по достижении вех (milestones) проекта (подробнее о вехах далее в этой лекции). Также в этот момент можно резюмировать извлеченные уроки.
По ходу проекта тип рисков, которым уделяется внимание, также должен изменяться. На ранних этапах доминируют риски связанные с бизнесом, рамками проекта, требованиями к конечному продукту и проектированием этого продукта. С течением времени начинают играть важную роль технологические риски, связанные с реализацией проекта. Затем внимание переходит к рискам поддержки и сопровождения. Для организации деятельности по выявлению рисков в моменты основных фазовых переходов полезно использовать контрольные перечни (checklists) и классификации рисков.
Управление рисками в MSF for Agile Software Development
Дисциплина управления рисками MSF1) возводит процесс управления рисками в ранг стратегической задачи, затрагивающей все фазы проекта. В рамках MSF управление рисками - это процесс выявления, анализа и превентивной работы над рисками в целях избежания их превращения в проблемы, приносящие ущерб или иной вред.
В ходе всего проекта команда должна уделять внимание дисциплине управления рисками. Основные ее характеристики:
она всеобъемлюща и принимает во внимание все составляющие проекта: людей, бизнес-процессы, технологические элементы и т.д.;она включает в себя пошаговый, систематический и воспроизводимый процесс управления рисками проекта;ее использование непрерывно на протяжении всего жизненного цикла проекта;она превентивна и не исходит из идеологии действия по факту случившегося.она вовлекает всю проектную группу в непрерывное извлечение уроков из полученного опыта.
Вспоминая предыдущую лекцию
Наша предыдущая лекция была посвящена введению в методологию Microsoft Solutions Framework. Мы обсудили, что такое методология вообще. Поговорили о том, чем является и чем не является MSF. В чем она схожа с другими методологиями и чем отличается от них. Перечислили и кратко охарактеризовали концепции MSF: модель процессов, управление проектом, модель проектной группы, управление рисками.
Далее мы дали краткую историческую справку по MSF и указали нововведения последней версии MSF 4.0.
Наконец, мы подробно остановились на модели проектной группы MSF и рассмотрели принципы формирования команды, роли и ролевые группы, которые выделяет MSF, их задачи и зоны ответственности.
Взаимодействуйте с "заказчиками"
MSF настаивает на непрерывном взаимодействии с заказчиком в ходе всей работы над проектом. Удовлетворенный заказчик - главный приоритет проектной группы. Понимание бизнес-отдач заказчика от проекта, потребностей его будущих пользователей требует максимальной полной вовлеченности заказчика в процесс создания решения.
