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

Question

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

Проекты, над которыми я сейчас работаю, имеют несколько особых характеристик: заинтересованные стороны - ученые, команды разработчиков очень малы (2-3 FTE), общие сроки - короткие (3-9 месяцев), а заинтересованные стороны довольно гибкие. на окончательной форме продукта. (Они просят A, B и C, но получают A, X и Z - без проблем.) Обычно мы получаем регулярный, если ограниченный доступ к заинтересованным сторонам: скажем, 1 час в неделю.

Некоторые последствия вышеперечисленного:

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

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

В роли представителя PM/ клиента я выработал привычку предъявлять требования к сбору электронных таблиц (Google Docs) со следующими категориями:

• "Мы можем реализовать сейчас" (мы думаем, что понимаем это достаточно хорошо, и это определенно
• "Требуется больше деталей / покупки"
• "Низкий приоритет" (часто вещи, которые один пользователь упомянул однажды, но с тех пор мы не слышали)
• "Большие возможности, которые нужно обсуждать" (существенный новый набор функций, в частности, интеграция с чем-то другим. Часто это было бы неплохо, но мы просто не знаем, сможем ли мы сделать это вовремя - в этом случае мы не должны Начните.)

Проблемы, которые не решает моя "методология", и я хотел бы услышать предложения по следующим вопросам:

• Поймать любителей показов - выявлять требования, которые сильно ограничивают наш выбор платформы / технологии / решения /...
• Структурирование и планирование будущих сессий сбора требований, чтобы мы знали, как долго мы можем работать над определенным набором функций, прежде чем попадем в туман неопределенности.
• Знание, является ли что-то достаточно высоким приоритетом, чтобы оно определенно сделало сокращение (и если нет, не тратьте больше времени на его изучение)
• Управление наборами взаимозависимых функций
• Управление функциями, которые могут быть разработаны в разной степени (например, получить 80% выгоды за 30% стоимости - как мы узнаем, должны ли мы потратить остальные 70%?)
• Управление выборами (в одном случае, реализуем ли мы механизм аутентификации X или Y - нет большого преимущества в том и другом, но есть большая неопределенность вокруг обоих)
• Зависимости: часто бессмысленно начинать реализацию Y, пока мы не увидим, как пользователи реагируют на X.
• Связь между "требованиями" и "проблемами" в системе отслеживания проблем. Вы просто добавляете все в трекер и продолжаете обновлять проблемы по мере того, как вы узнаете о них больше, возможно, разделяя или объединяя их?

Итак - мне интересно услышать, как другие люди подходят к этим вопросам. Поиск "инструментов требований" не принес ничего полезного - просто набор корпоративных CASE-инструментов для настольных компьютеров.

Answer 1

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

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

Таким образом, переписывание требований в структурированном документе (слове) впоследствии кажется мне единственным решением.

Answer 2

По моему мнению, вам нужно больше взаимодействия с заинтересованными сторонами / бизнесом / клиентом, чтобы: 1. расставить приоритеты для функций и 2. создать план тестирования для UAT, чтобы вы знали, когда вы можете прекратить добавлять функции.

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