Основные пять рисков проектов разработки программного обеспечения

Управление рисками (точнее, избегание рисков) является критической темой, но зачастую ею пренебрегают и опускают. Одной из немногих полезных и интересных книг на данную тему является книга "Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения", написанная Томом ДеМарко и Тимоти Листером. Данная статья предоставляет краткое описание пяти основных рисков проектов по разработке ПО, обсуждаемых в книге.

Притом , что книга не фокусируется на гибкой методологии разработки (Agile), стоит отметить, что основные пять определенных рисков, сопровождающих проекты по разработке ПО, в данной  книге имеют решения, корни которых находятся именно в гибкой методологии. ДеМарко и Листер описывают следующие пять основных рисков и стратегий, позволяющих их избежать:

Риск 1: ошибки, присущие расписанию  

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

Решение из книги: все больше вовлекайте команду в процесс планирования и оценки. Получите отзывы на ранней стадии и обсудите возможные ошибки и нестыковки лично с заказчиком.

Гибкий метод: в проектах, использующих гибкую методологию, команда активно вовлечена в планирование  и оценку посредством таких действий, как  экстремальное программирование (Extreme Programming, XP) и семинары Wideband Delphi. Работая в коротких этапах, скорость работы команды резко увеличивается, и это явно видно всем участникам проекта, кто  на данный момент более вовлечен в проект. Вкратце, настоящий прогресс сложно скрыть от владельцев.

Риск 2: появление новых требований

Описание: по ходу продвижения проекта появляются все новые требования, которые могут нарушить все сроки и оценки.

Решение из книги: постоянное вовлечение клиентов и разработчиков.

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

Риск 3: смена сотрудников

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

Решение из книги: высокий уровень сотрудничества и обмена информацией в команде.

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

Риск 4: декомпозиция спецификации

Описание: при старте процесса кодирования и интеграции становится ясно, что спецификация неполная и содержит конфликтные требования.

Решение из книги: наймите преданного менеджера по продукции для осуществления критических договоров и решений.

Гибкий метод: проекты с гибкой методологией используют опытных пользователей, экспертов в области или посредника клиентов в качестве менеджера по продукции. Идея заключается в том, что кто-то (или некая группа) должен быть готов отвечать на вопросы и осуществлять решения в проектах. Традиционные проекты страдают от декомпозиции специификации, когда никто не исполняет такую роль, и появляются конфликтующие предположения и решения. Проекты должны обладать некой ролью владельца проекта в составе команды для обеспечения своевременного принятия решений.

Риск 5: низкая продуктивность

Описание:наличие впереди длительных сроков приводит к тому, что на ранних стадиях зачастую отсутствует  чувство срочности в работе, а это  в результате дает в начале проекта  потерю времени, которое уже нельзя вернуть .

Решение из книги : короткие итерации, нужные люди в команде, лидерство и развитие команды.

Гибкий метод:гибкие методы осознают присутствие закона Паркинсона и синдром студента в проектах. Закон Паркинсона гласит о том, что работа удлиняется, заполняя доступные рамки времени, а синдром студента говорит о том, что имея срок, люди зачастую ничего не делают до того момента, как этот срок будет близок. Применяя короткие итерации, работа разделяется  на множество этапов (обычно 1-4 недели) и  всегда существует чувство срочности. Гибкая методология не концентрируется на нужном персонале и развитии команды, но это основа роли лидера и применяется как в гибкой, так и в  традиционной методологиях.

Заметка по гибкой методологии

Вас не должно удивлять то, что техники в данной методологии помогают справиться со всеми пятью основными рисками. Они были созданы как раз для блага разработки программного обеспечения. Учитывая то, что данные проблемы постоянно возникают в проектах по разработке ПО, очевидно, что они должны быть включены в гибкие методы.

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

Mike Griffiths