Как управление требованиями работает в долгосрочной перспективе с Agile проектами?

Управление требованиями в краткосрочной перспективе для Agile проектов кажется мне решенной проблемой.

С точки зрения Scrum новые требования или изменения существующих требований доставляются через пользовательские истории. А пользовательские истории, сгруппированные под Epic или Feature, облегчают выполнение более сложных и сложных требований.

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

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

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

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

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

Если первоначальная команда знала, что это произойдет (например, это характер бизнеса), то какие меры они могли бы принять, чтобы помочь последующим командам?

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

Итак, что можно сделать, чтобы помочь последующим командам понять состояние проекта, в том числе, почему и как он туда попал?

По моему опыту, следующие вещи не работают:

• Очистка журнала ожидания для удаления или обновления предыдущих пользовательских историй, чтобы журнал можно было прочитать как документ с требованиями.
• Документация Спринты, где членам команды поручено документировать текущее состояние системы.
• Документация через поведенческие тесты . Этот подход - единственный, который я видел, приблизился к работе. К сожалению, тесты кодированного поведения являются жертвами проблемы именования. Хотя тесты могут правильно документировать систему, заставить колеблющуюся команду разработчиков писать свои тесты, следуя той же терминологии, формулировке и стилю домена, практически невозможно.

Итак, еще раз:

Как управлять требованиями Agile проекта в долгосрочной перспективе?

Мне кажется, что это невысказанный слон в комнате с гибкими проектами: как вы можете предотвратить превращение их в хаос?

Давайте посмотрим на Agile Manifesto на мгновение. Проворные желания:

1. Ранняя и непрерывная доставка
2. Принимая меняющиеся требования
3. Поставка рабочего программного обеспечения часто
4. Разработчики и заинтересованные стороны работают вместе ежедневно
5. Создание проектов вокруг мотивированных людей, предоставление им среды и поддержки, в которой они нуждаются, и доверие к ним для выполнения работы
6. Личная беседа как основной способ общения
7. Рабочее программное обеспечение как основной показатель прогресса
8. Устойчивое развитие
9. Постоянное внимание к техническому совершенству и хорошему дизайну
10. Простота - максимизация работы, которую вам не нужно делать
11. На регулярной основе команда размышляет о том, как стать более эффективным, затем настраивает и корректирует свое поведение соответственно

Я выделил последние четыре. Почему? Потому что именно они будут препятствовать разрушению проекта под собственным весом.

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

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

И именно он поддерживает документ с основными требованиями.

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

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

С личной точки зрения, я работаю с небольшой командой из примерно десятка разработчиков. В любой момент мы можем работать над тремя программными проектами одновременно, в диапазоне от нескольких тысяч строк кода до более чем 100 000. Наш клиент думает, что они кролик, но на самом деле они лошадь. Заказчик занимается, но не ежедневно.

Безусловно, наша самая слабая область - это сбор конкретных, проверяемых, измеримых требований и управление ожиданиями клиентов относительно масштабов проекта. Но мы работаем над этим.

Вопрос не совсем ясен, но, похоже, вы обеспокоены отслеживаемостью требований . По моему опыту, в Agile теряется идея, что бизнес-требования - это то, что клиент хочет, чтобы система делала, а пользовательские истории - это действительно функциональные требования, которые определяют работу системы. «Как пользователь, я хочу быть в состоянии X.» Но это сделано для удовлетворения требования, которое может быть потеряно в пользовательской истории.

В моем опыте хорошо работает связь бизнес-требований и пользовательских историй в обоих направлениях. BR # 1 может быть реализован в историях A и B. История C может охватывать BR # 2 и # 3. Поместите это в свой трекер проекта, электронную таблицу, все, что вы используете.

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

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

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

каждая история пользователя / требование / исправление имеет номер билета, и каждое изменение исходного кода связано с номером билета в поле sourcecontrol-comment-field.

sourcecontrol-checkin-s (svn) автоматически обновляет базовый ответ, чтобы в билете была ссылка на все sourceconrtol-changesets.

Если модуль / функция недавно реализован, в исходном коде также есть номера билетов.

В тикет-системе (redmine) тикеты связаны между собой как (дубликат, ошибка, уточнение, ....)

так что вы можете следить за билетами и видеть изменения требований с течением времени.

Пример: мне нужно что-то изменить в "orderConfirmation-Web-page". В исходном коде страницы я вижу комментарий: 'создан для "# 4711", поэтому я могу связать свой новый билет со старым билетом "4711" или одним из его преемников.

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

Хотя в этом нет ничего нового.

Если вы используете более масштабную версию Agile (например, SAFe ), у вас будут другие резервы, которые не являются отставанием реализации. В основном это выглядит так:

1. Портфолио Backlog (Стратегическое планирование эпосов и бюджетов)
2. Журнал программы / релиза (особенности и эпосы)
3. Журнал проекта / команды (истории, спайки, ошибки)

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

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