Изменение культуры работы

Купить инструментальное средство легко; изменить культуру и организацию работы, чтобы принять это средство и извлечь из него максимальную пользу, гораздо сложнее. Большинство организаций уже привыкли (и чувствуют себя при этом весьма комфортно!) хранить требований в форматах текстовых редакторов. Для перехода к оперативным приемам работы с требованиями необходим новый образ мышления. Инструментальное средство открывает доступ к требованиям в базе данных любому участнику проекта, имеющему соответствующие разрешения. Некоторые воспринимают это как уменьшение контроля над требованиями, которым они раньше обладали, над процессом создания требований или над тем и другим. Другие предпочитают не показывать миру неполные или несовершенные спецификации требований к ПО, ведь содержание базы данных доступно всем. Скрывая требования до того, как они «готовы», вы упустите возможность показать их многим потенциальным критикам — а это отличный способ выявления возможных проблем.

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

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

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

· не пытайтесь вносить требования непосредственно в инструментальное средство, когда только начинаете проводить семинары для выявления требований. Однако, по мере того как требования начнут обретать устойчивые формы, хранение их в программе откроет доступ к ним участникам семинаров для уточнения;

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

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

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

· используйте деловую, а не ИТ-терминологию, определяя новые поля данных или атрибуты требований;

· не определяйте связей трассирования, пока требования не обретут устойчивые формы. В противном случае вам придется исправлять массу связей по мере изменения требований;

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

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

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