Организация работ по управлению требованиями

Управление требованиями и приемы этой работы, представленные выше, являются главными условиями успешного развития большинства сложных проектов, поскольку именно это обеспечивает возможность пост­роения системы, реально удовлетворяющей потребности пользователей с учетом внешних обстоятельств разработки (надежность заказчика, рыноч­ная конъюнктура и др.). Однако большинство рекомендаций, которые можно дать для организации этих работ, принадлежат конкретным методо­логиям. Наиболее регламентировано подходят к вопросу монументаль­ные методологии, ставящие критерии отслеживания процесса развития проекта на первое место [18]. Противоположная позиция у методологии экстремального программирования, провозгласившей «путешествие на­легке» (все, что не относится к решению задач проекта в их текущем виде­нии, не требуется учитывать, а тем более специально разрабатывать), со­трудничество с заказчиком как с членом команды (он отвечает за актуаль­ность решаемых при производстве релизов задач), а также ряд специальных методик, делающих классический анализ требований избыточным [3].

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

• для каждого отвергаемого требования составляется мотивирован­ное заключение о том, почему оно не принимается (невозможно удовлетворить, нецелесообразно принимать, поскольку желаемое достижимо иным путем, запланировано в качестве перспективы, может быть принято при изменении финансовых и календарных планов и др.). Это заключение согласовывается с автором требова­ния и с заказчиком;

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

• приоритетность требования;

• сложность рабочих продуктов и зависимостей рабочих продук­тов от требования;

• простые требования, зависимости которых незначительны и кото­рые решено учитывать в рамках текущей итерации, реализуются непосредственно в момент утверждения;

• сложные требования откладываются до завершения конструктор­ских работ данной итерации, которое рассматривается как начало работ по учету комплекса предъявленных требований;

• требования, откладываемые до последующих итераций, реализу­ются согласно общему плану проекта, который корректируется с учетом решения о реализации этих требований;

• учитывается, что ранее принятое требование может оказаться от­вергнутым вследствие принятия нового требования (новых требо­ваний), а потому для такого требования необходимо подготовить заключение об отказе от реализации. Это решение согласовывает­ся с автором требования и с заказчиком;

• изменения планов и объемов работ, возникающие и/или планиру­емые в связи с управлением изменениями требований, всегда сог­ласуются с заказчиком.