Толпа и требования [закрываются]

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

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

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

То, что я делаю, - это сочетание того и другого. У меня есть документ с требованиями, и в большинстве моих историй схваток в заметках есть что-то, что связывает эту историю с одним или несколькими элементами требований. Это так же просто, как "См. FR-042 и FR-45" (например, функциональные требования FR)

В этот вопрос будет добавлено множество хороших идей. Мой личный опыт научил меня, что:

1 ~ Рабочий продукт сам по себе является формой документации: если предположить, что продукт принят, то спросить, что он должен делать при определенных условиях, равносилен вопросу о том, что он на самом деле делает в этих условиях - авторизуйтесь и попробуйте получить ответ.

2 ~ Тесты, будь то ручные или автоматические (или смешанные), являются формой документации. Конечно, модульные тесты могут быть слишком далеки от языка предметной области, на котором говорят менее технически подкованные члены команды (например, «бизнес-эксперты» или клиенты). Приемочные испытания могут быть ближе к своего рода «золотой середине». Определенно, тесты в стиле BDD, кажется, имеют наилучшие шансы создать вездесущий язык, понятный каждому (см. В этой связи Гойко «Преодоление коммуникационного разрыва» ). Тем не менее, все эти формы тестов представляют собой форму документации, которая может использоваться для определения того, что должен делать продукт.

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

4 ~ В идеальном мире нам, вероятно, не нужно было бы документировать требования, кроме как в форме рабочего кода (который в Башне из слоновой кости также не требует пояснений) и тестов (в основном для регрессионного тестирования и -на периферии- для стимулирования разработки новых функций). Таким образом, вопрос документации требований - это вопрос о том, чем отличается Perfect World / Ivory Tower от Real World / Trenches. Ответ, конечно же, в каждом конкретном случае разный, в зависимости от проекта и команды. Например, мы могли бы сказать: «Все требования должны быть сохранены в этой вики и поддерживаться с особой тщательностью и т. Д. И т. Д.», Но если команда не знакома и не знакома с вики, это не сработает.

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

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

• PDF-документ
• Доски объявлений
• ] Wiki
• Wiki + Автоматические приемочные тесты (читай: FitNesse)
• Модульные тесты
• Ручные планы тестирования
• Истории пользователей, диаграммы вариантов использования (читай: модели Enterprise Architect)
• Доски в офисе
• Электронная почта
• Примечания для заметок

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

HTH, спасибо за наводящий на размышления вопрос!

Scrum говорит, что вы должны документировать то, что вам нужно, когда вам это нужно; он не говорит, что у вас не должно быть документов.

Поэтому если документ требуется либо готовому продукту (например, справочная документация), либо для производства готового продукта (например, документация по требованиям), то в беклоге продукта должна быть задача/история пользователя по документированию.

Затем для этой задачи должен быть установлен соответствующий приоритет.

Для документации ключевым моментом является следующее:

• Документируйте только то, что вам нужно, только когда вам это нужно.

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

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

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

Вы не можете просто создавать пользовательские истории {{ 1}} так или иначе функциональность программы должна быть задокументирована. Получится ли у вас спецификационный документ с помощью схватки? Если да, то вы в конечном итоге назначаете время для этого в задаче?

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

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

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

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

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

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

В этих случаях мы следовали следующим рекомендациям:

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

По моему опыту, это упрощает написание документов и позволяет проводить какой-то тест (вы просите кого-нибудь, обычно PO, прочитать документ и сказать, нормально ли это с учетом поставленной цели).