Информатизация бизнеса. Управление рисками. С. М. Авдошин

в гибких (Scrum, Crystal, Open Source, ASD) очевидно прослеживается меньшая ориентация на документацию, что выражается в меньшем ее объеме для каждой конкретной задачи. Легкие методологии дают возможность обрабатывать большие объемы информации, относящиеся к проекту, в процессе неформального, непосредственного, личного общения, а не с помощью документации. При этом отсутствие документации может быть ограничением использования методологии в государственных учреждениях или организациях, требующих высокой степени формализации и документирования. Поскольку практически все гибкие методологии ориентированы на максимально неформальный подход к разработке, зачастую возможны спорные вопросы при реализации тех или иных изменений, расстановке приоритетов.

      При этом легкие методологии также отличаются друг от друга – Crystal призывает совмещать производительность и толерантность, в отличие от ХР, где продуктивность возрастает как раз за счет уменьшения толерантности. Методология «Adaptive Software Development» разработана специально для крайне нестабильных ситуаций в разработках, когда требования, проектирование и невозможно короткие сроки являются функциями друг друга и постоянно меняются (так зачастую происходит в веб-разработках). Scrum характерен активным воздействием внешних лиц по отношению к рабочей группе, при этом у заказчика сохраняется максимальный приоритет. Заказчик продукта сам решает, как оформить бэклог продукта, выбирает требования для следующей итерации. При этом несоблюдение базовых принципов, заложенных в Scrum, таких как самонаправляемые команды, обязательная расстановка приоритетов или еженедельные обновления, может привести к срыву проекта.

      2.4. Риски в жизненном цикле программного обеспечения

      Анализ методологий в области разработки ПО и опыт менеджеров ИТ-проектов подсказывает, что для эффективной реализации ИТ-проектов обязателен анализ жизненного цикла.

      Под жизненным циклом ПО понимается непрерывный процесс, который начинается с принятия решения о необходимости создания ПО и заканчивается при полном изъятии его из эксплуатации.

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

      Риски возникают на протяжении всего жизненного цикла проекта, это требует