О работе с требованиями и документами

Наконец-то завершил написание статьи об опыте работы с требованиями и документами в системе управления проектами "Девпром" на примере одного проекта. Прочитать полностью статью вы сможете по ссылке ниже.

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

Мы практикуем фиксацию требований следующими способами: 

• В пожелании. 
• В задаче. 
• В модуле управления требованиями. 
• В Microsoft Word. 

Ниже рассмотрим подробнее каждый из способов.

Пожелание: фиксация исходных неформализованных требований

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

Задача: быстрая формализация требований

Если решено, что пожелание Заказчика не требует создания отдельной спецификации, постановка фиксируется прямо в задаче разработки. Ранее постановка размещалась в первом комментарие к задаче, но такой подход оказался не очень удобным ввиду разрастающегося со временем хаоса. Мы пришли к выводу, что отдельное поле для задачи будет намного удобнее, поэтому для сущности «задача» был добавлен дополнительный атрибут — текстовое поле «Подробное описание» с поддержкой форматирования (см. рисунок ниже). В комментариях теперь обсуждаются проблемы и важные моменты по задаче. При необходимости можно передать коллеге ссылку на определенный раздел дерева комментариев.

Модуль управления требованиями: создание документов требований

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

Этим инструментом может быть как система управления требованиями (в нашем случае — модуль разработки требований Девпром), так и привычный MS Word или иной текстовый редактор. Единственное требование — чтобы итоговый результат работы был зафиксирован в Девпроме и связан с проектными артефактами. В первом случае расскажем о нашем опыте использования модуля разработки требований.

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

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

К варианту создания документа в модуле управления требованиями Девпрома предъявляются такие требования:

• Структура документа требований должна соответствовать базовой структуре, определенной в шаблоне.
• Готовый документ должен быть связан с проектными артефактами, т.е. они должны ссылаться на документ требований R-NNNN.

MS Word: создание документов требований

Во втором случае инструментом разработки требований может быть стандартный инструмент аналитика — старый добрый MS Word (или другой текстовый редактор). К этому варианту создания документа требований предъявляются такие требования:

• Структура документа должна соответствовать базовой структуре, определенной в шаблоне документа требований в Девпроме.
• Готовый документ должен быть связан с проектными артефактами одним из способов:
• Приложен в виде файла к задаче анализа, в рамках которой выполняется разработка документа. Далее можно связать задачу разработки с задачей анализа — так документ будет располагаться только в едином месте. Самый простой способ.
• Связан с другими проектными артефактами (пожеланиями, задачами, тест-кейсами и т.п.). Приоритетный способ, также обеспечивающий единое место хранения актуального документа. Заранее в разделе «Анализ и проектирование» создается артефакт требования (R-NNNN), после чего он связывается с другими проектными артефактами и к нему прикладывается готовый документ одним из способов:
• В виде файла.
• Импортированием контента документа из MS Word помощью специального плагина для MS Word.
• В виде ссылки на документ на внешнем файловом хранилище согласованных документов (если такое хранилище используется).

Вообще с MS Word приходится работать в любом случае, так как это стандарт по умолчанию для внешних документов, поставляемых заказчикам. В связи с этим у нас принято такое разделение:

• Внутренняя проектная документация. Используется проектной командой. Разрабатывается и хранится исключительно в системе Девпром (модуль базы знаний, блог, раздел управления требованиями, раздел управления справочной документацией).
• Внешняя документация. Поставляется заказчику на согласование, утверждение. Итоговая актуальная версия документа хранится в файловом хранилище. Документ может готовиться как в MS Word, так и в Девпроме, однако:
• Если документ разрабатывается изначально в Девпроме, далее для поставки заказчикам он экспортируется с помощью плагина MS Word. Причем, заранее можно подготовить собственный шаблон оформления документа.
• Если документ готовится изначально в MS Word, далее он должен быть связан с проектными артефактами способами, указанными выше.

Общий сценарий работы аналитика с требованиями и документами

Предусловие. Единоразово создается/корректируется существующий рабочий процесс задачи/пожелания. Руководителем или самим аналитиком создается задача с типом «Анализ». Эта задача связывается с проектными артефактами (пожеланиями, задачами разработки, тестирования и т.п.).

Основной поток:

1. Аналитик берет задачу в работу, устанавливая ей статус «В работе».
2. Аналитик в модуле управления требованиями создает документ требований (R-NNNN) и связывает его с проектными артефактами, к которым относится документ (обязательно — с последующей задачей разработки). Документу также устанавливается статус «В работе».
3. Аналитик работает над требованием в рамках взятой задачи.
4. По завершению работы документ отправляется на согласование (либо заказчику, либо руководителю). Статус документа — «Согласование». Задача анализа остается в статусе «В работе» до завершения согласования.
5. Документ согласован. Ему присваивается статус «Согласовано». Задача анализа закрывается и ей присваивается статус «Завершена».

Постусловие. Хранение и актуализация документов, согласованных заказчиками, выполняется на внешнем хранилище. Если документ уже не используется, ему в Девпроме присваивается статус «В архиве».

Альтернативный поток:

2.1 Если аналитик создает требования изначально в MS Word, далее он связывает документ с проектными артефактами способами, описанными в статье выше (в виде файла, импортированием, вставкой ссылки на внешнее хранилище). Далее процесс следует с п. 3 основного потока.

2.2 Если задача анализа не требует разработки отдельного документа, постановка на реализацию может быть составлена в описании задачи анализа и (лучше сделать так) продублирована в описание задачи разработки. При этом важно в описании задачи или в первом комментарие к ней отметить моменты, на которые стоит обратить особое внимание. После составления краткой постановки задаче анализа сразу назначается статус «Завершена».

Таким образом, описанный выше процесс разработки документов требований можно справедливо распространять и на разработку эксплуатационных документов. В Девпроме разработка документов выполняется в модуле «Документирование».

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

Оригинал статьи на сайте "Клуб ALM"