Самое полное руководство по управлению требованиями и отслеживаемости
Статус требований и запрос на изменение
Содержание
Состояние требований
Чтобы оставаться в курсе проекта, отслеживайте каждое требование на протяжении всего его жизненного цикла. Вы даже можете назначить значение атрибута для хранения этой информации для дополнительной безопасности и точности. Этот тип отслеживания статуса поможет уменьшить распространенную дилемму с программными проектами — ложное заявление о том, что «девяносто процентов выполнено». Каждое требование должно иметь один из следующих статусов в любой заданный период времени:
- Выступал (кто-то энергично поддерживал)
- Процесс утверждения прошел успешно, и распределение было помещено в базовый план.
- После тщательной разработки, написания сценариев и тестирования кода мы его реализовали.
- После того как требование было пройдено и проверено, оно было проверено на предмет успешной интеграции в продукт.
- Это требование будет выполнено позднее.
- Вы решаете Удалить его, а не реализовывать.
- Уволен (концепция так и не получила зеленый свет)
Помимо вышеупомянутых вариантов статуса, могут быть рассмотрены и другие статусы. Некоторые могут выбрать статус «Просмотрено», чтобы проверить свои требования перед добавлением их в базовые конфигурации. В качестве альтернативы организации могут использовать «Доставлено заказчику» в качестве средства проверки того, что они выпустили требование в неизменном виде и правильно.
Если вы спросите о прогрессе разработчика, он может ответить, что для этого конкретного проекта есть 87 требований. 61 уже подтверждено, 9 находятся на месте, но еще ожидают проверки, а 17 еще предстоит завершить. Однако важно отметить, что не все эти запросы совпадают по размеру или влиянию на удовлетворенность клиентов; они также могут потребовать разного количества усилий. Как руководитель проекта, я не сомневался, что у нас есть точное представление о размере подсистемы и о том, насколько она близка к завершению. Это намного эффективнее, чем просто сказать: «Я сделал около девяноста процентов». Имея общую картину прогресса, я могу с уверенностью сказать «выглядит отлично!»
Запросы на изменение
Для успешного управления требованиями ваша организация должна следить за каждым добавлением, удалением и изменением требований. Это позволит вам отслеживать статус, а также последствия всех запросов на изменение. Вы также можете использовать эти данные, чтобы ответить на несколько вопросов, таких как:
- Сколько запросов на изменение было сделано в течение установленного периода времени?
- На сколько запросов были даны ответы, а сколько осталось нерешенными?
- Какова была доля одобренных запросов и какой процент был отклонен?
- В какой степени команда затратила энергию на выполнение каждой авторизованной модификации?
- Какова типичная продолжительность времени, в течение которого запросы остаются открытыми?
- В среднем, на сколько элементов (например, требований или артефактов) влияет каждый отправленный запрос на изменение?
Убедитесь, что вы отслеживаете любые изменения, внесенные в процессе разработки, после установки базового уровня для каждого выпуска. Помните, что один запрос на изменение может повлиять на многочисленные требования различных типов (ориентированные на пользователя, функциональные и нефункциональные). Чтобы оценить, сколько изменений было внесено за определенный период времени, разделите количество модификаций на общее количество требований до этого периода (как при определении базового уровня).
Мы не хотим полностью устранять изменчивость требований. В конце концов, часто есть законное оправдание для их изменения. Но в то же время мы должны убедиться, что наш проект может выдерживать изменения и по-прежнему выполнять свои обязательства. Приближение к завершению требует дополнительных затрат, если изменения вносятся часто; это затрудняет определение того, когда вы выпустите свой продукт в мир! По мере развития большинство проектов должно стать более устойчивым к изменениям; другими словами, скорость принятия изменений должна постепенно уменьшаться, пока не достигнет нуля, когда выпуск будет завершен. Итеративный подход дает командам множество возможностей для внесения улучшений в более поздние итерации, сохраняя при этом график каждого цикла.
Если ваша команда завалена запросами на изменение, есть вероятность, что процесс сбора информации не был всеобъемлющим, или идеи продолжают появляться по мере продвижения проекта. Таким образом, важно отслеживать, откуда эти изменения исходят от маркетинга, пользователей, продавцов, управленческих команд и т. д. Отслеживание этой информации поможет вам определить, кто и что требует внимания, чтобы свести к минимуму пропущенные требования и предотвратить недопонимание в будущем.
Когда запросы на изменение остаются нерешенными в течение длительного периода времени, это явный признак того, что ваш процесс управления изменениями требует некоторого внимания. Я лично был свидетелем одной организации, у которой были запросы на усовершенствование, которым уже несколько лет, но которые все еще находятся на рассмотрении. Чтобы заставить менеджера проекта расставить приоритеты в своих усилиях по наиболее важным элементам в невыполненной работе, эта команда должна назначить определенные открытые запросы в запланированные выпуски обслуживания и преобразовать другие долгосрочные отложенные изменения в отклоненные. Таким образом, им будет легче сначала решить то, что необходимо и срочно, прежде чем приступать к менее насущным вопросам.
Время и усилия
Чтобы обеспечить оптимальную производительность, мы настоятельно рекомендуем вам записывать количество времени, которое ваша команда тратит на задачи разработки требований. Это включает в себя разработку требований к качеству и управление изменениями, отслеживание прогресса, создание данных для отслеживания и другие действия, связанные с этим процессом.
Люди часто спрашивают меня, сколько времени и энергии следует уделять потребностям проекта. Этот ответ сильно зависит от размера, команды, организации, создающей его, и его цели. Отслеживание ваших усилий, вложенных в критические задачи для подобных проектов, может помочь вам лучше планировать будущие с точными оценками.
Если ваша команда ранее завершила проект и выделила 10% своего времени требованиям, поразмыслив, вы могли заметить, что качество этих требований можно было бы значительно улучшить. Если столкнется с другим подобным проектом, было бы мудро, если бы руководитель проекта приложил больше усилий для создания подробных спецификаций — должно хватить более десяти процентов от общего количества доступных ресурсов!
Когда вы собираете и анализируете данные, сравните усилия по разработке проекта с мерой размера продукта. Ваши задокументированные требования дадут представление о его общем размере. Чтобы быть более точным, вы можете сопоставить усилия для подсчета тестируемых отдельных спецификаций, точек использования или функциональных точек — всего, что пропорционально измерениям вашего продукта. Собирая данные о размере вашего продукта и отмечая связанные с этим усилия по внедрению, вы можете сформулировать точные оценки при подготовке к аналогичным будущим проектам.
Страх может остаться в умах многих; страх, что разработка программы измерения программного обеспечения отнимет драгоценное время у важных задач. Наоборот, внедрение эффективной и целенаправленной метрической системы не требует слишком много усилий или энергии. Все, что вам нужно сделать, это создать базовую инфраструктуру для сбора и анализа данных, а также побудить членов вашей команды регистрировать некоторые важные сведения о своей рабочей деятельности. Когда вы создаете культуру, основанную на метриках в вашей компании, удивительно, чему можно научиться с помощью этого метода!
Не забудьте поделиться этим постом!
