Управление рисками (точнее, избегание рисков) является критической темой, но зачастую ею пренебрегают и опускают. Одной из немногих полезных и интересных книг на данную тему является книга "Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения", написанная Томом ДеМарко и Тимоти Листером. Данная статья предоставляет краткое описание пяти основных рисков проектов по разработке ПО, обсуждаемых в книге.
Притом , что книга не фокусируется на гибкой методологии разработки (Agile), стоит отметить, что основные пять определенных рисков, сопровождающих проекты по разработке ПО, в данной книге имеют решения, корни которых находятся именно в гибкой методологии. ДеМарко и Листер описывают следующие пять основных рисков и стратегий, позволяющих их избежать:
Риск 1: ошибки, присущие расписанию
Описание: благодаря своей неощутимой природе и уникальности программного обеспечения, процесс разработки ПО сложно оценить и расписать.
Решение из книги: все больше вовлекайте команду в процесс планирования и оценки. Получите отзывы на ранней стадии и обсудите возможные ошибки и нестыковки лично с заказчиком.
Гибкий метод: в проектах, использующих гибкую методологию, команда активно вовлечена в планирование и оценку посредством таких действий, как экстремальное программирование (Extreme Programming, XP) и семинары Wideband Delphi. Работая в коротких этапах, скорость работы команды резко увеличивается, и это явно видно всем участникам проекта, кто на данный момент более вовлечен в проект. Вкратце, настоящий прогресс сложно скрыть от владельцев.
Риск 2: появление новых требований
Описание: по ходу продвижения проекта появляются все новые требования, которые могут нарушить все сроки и оценки.
Решение из книги: постоянное вовлечение клиентов и разработчиков.
Гибкий метод: в проектах, использующих гибкую методологию, регулярно планируются и обсуждаются все функции и сроки на границах каждого этапа. Изменения и требования в таких проектах принимаются как данность. Вместо простого использования методов подавления изменений, планируются сессии по установлению приоритетов, которые позволяют рационально выполнить все изменения. Невозможно протиснуть канат в игольное ушко, но вы уже осведомлены о существовании данной проблемы и у вас есть метод работы с изменениями, который можно использовать на ранних стадиях.
Риск 3: смена сотрудников
Описание: ключевые сотрудники могут покинуть проект, унося при этом с собой критическую информацию, что значительно откладывает и сносит проект с рельсов.
Решение из книги: высокий уровень сотрудничества и обмена информацией в команде.
Гибкий метод: техники обмена информацией в случае с гибкой методологией, такие как парное программирование, использование обобщенного кода и частые отчеты, каждодневно противостоят вероятности потери информации. При снижении фактора утери сотрудника многие члены команды обмениваются ключевой информацией, следовательно, риск, связанный с уходом ключевых сотрудников, низок. Также стоит учесть, что, работая в захватывающей, награждающей и кооперирующей среде, как в случае с проектами, основанными на гибкой методологии, люди реже хотят покидать проект.
Риск 4: декомпозиция спецификации
Описание: при старте процесса кодирования и интеграции становится ясно, что спецификация неполная и содержит конфликтные требования.
Решение из книги: наймите преданного менеджера по продукции для осуществления критических договоров и решений.
Гибкий метод: проекты с гибкой методологией используют опытных пользователей, экспертов в области или посредника клиентов в качестве менеджера по продукции. Идея заключается в том, что кто-то (или некая группа) должен быть готов отвечать на вопросы и осуществлять решения в проектах. Традиционные проекты страдают от декомпозиции специификации, когда никто не исполняет такую роль, и появляются конфликтующие предположения и решения. Проекты должны обладать некой ролью владельца проекта в составе команды для обеспечения своевременного принятия решений.
Риск 5: низкая продуктивность
Описание:наличие впереди длительных сроков приводит к тому, что на ранних стадиях зачастую отсутствует чувство срочности в работе, а это в результате дает в начале проекта потерю времени, которое уже нельзя вернуть .
Решение из книги : короткие итерации, нужные люди в команде, лидерство и развитие команды.
Гибкий метод:гибкие методы осознают присутствие закона Паркинсона и синдром студента в проектах. Закон Паркинсона гласит о том, что работа удлиняется, заполняя доступные рамки времени, а синдром студента говорит о том, что имея срок, люди зачастую ничего не делают до того момента, как этот срок будет близок. Применяя короткие итерации, работа разделяется на множество этапов (обычно 1-4 недели) и всегда существует чувство срочности. Гибкая методология не концентрируется на нужном персонале и развитии команды, но это основа роли лидера и применяется как в гибкой, так и в традиционной методологиях.
Заметка по гибкой методологии
Вас не должно удивлять то, что техники в данной методологии помогают справиться со всеми пятью основными рисками. Они были созданы как раз для блага разработки программного обеспечения. Учитывая то, что данные проблемы постоянно возникают в проектах по разработке ПО, очевидно, что они должны быть включены в гибкие методы.
Поэтому, пока управление рисками является скучной темой для многих, "вальс с медведями" содержит несколько полезных тем и данную книгу стоит прочитать руководителям проектов.
Mike Griffiths