Является ли документация историей пользователя? [закрыто]

Нам нужно сделать некоторую пользовательскую документацию для продукта, над которым мы работали последние несколько спринтов. Сейчас мы начинаем новый проект в следующем спринте, а ПО создает документацию для продукта, который ранее был историей пользователя для этого спринта.

Мне просто интересно ваше мнение об этом подходе. Лично я не согласен с тем, что документация - это история пользователя в Scrum, потому что она не производит никакого кода.

РЕДАКТИРОВАТЬ: Спасибо за ваше мнение, ребята. У меня в глубине души было то, что спринт должен был реализовать инкремент работающего программного обеспечения, но ваши взгляды изменили мою точку зрения. Спасибо за все ваши ответы.

«Как пользователю X, мне нужно знать, как работает X», мне кажется, это легитимная пользовательская история. Это может привести к письменной документации или онлайн-помощи.

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

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

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

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

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

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

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

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

Чтобы конкретно ответить на ваш вопрос, я бы спросил, считает ли команда, что документация является частью «Определения выполненного», или нет.

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

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