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

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

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

Теперь у нас есть некоторое понимание того, какие технические особенности будут у этого приложения: необходимо обеспечить постоянное хранение данных пользователя, реализовать переносимое решение и обеспечить возможноть локализации приложения без привлечения программистов. Нам важно аккуратно подойти к выбору платформы, библиотек и организации внутренней архитектуры приложения, чтобы реализовать эти требования заказчика. Скорее всего нужно использовать портируемую библиотеку, наверно хорошо бы использовать C++ или .Net для реализации приложения, видимо понадобится какая-то база данных для постоянного хранения данных пользователя, или можно будет обойтись обычными файлами? Все эти вопросы необходимо решать до начала разработки и они формируют базу технических рисков, которые необходимо оценить всей команде.

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

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

Допустим, что у нашей команды есть опыт разработки на .Net и на чистом C++, но нет опыта написания переносимых приложений, которые бы запускались одновременно на Windows и Linux. Чтобы снизить риск "Обеспечение переносимости приложения" мы хотим разработать прототипы приложения на Qt и на .Net и "пощупать" их работу, условия разработки и сопровождения для каждого их этих вариантов. Для этого создаем соответствующие пожелания и назначаем их на участников комадны. Команда оценивает рабочие прототипы и приходит к выводу, что лучше реализовывать приложение на .Net, тем самым исходный риск оценен и добавлен новый риск, связанный с недостаточным знанием возможностей использования баз данных на Linux. Риск потери данных пользователем снижается за счет проектирования внутренней архитектуры приложения таким образом, чтобы любые изменения данных пользователем автоматически сохранялись во временных файлах и восстанавливались при падении приложения.

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

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

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

Риски

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

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

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

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

Управление рисками в DEVPROM

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

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

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

Итак, прежде чем морщить нос от кажущейся сложности управления рисками, вспомните, все что вам нужно: DEVPROM, пожелания, тэги. Не рискуйте! :)