Нам нужно сделать некоторую пользовательскую документацию для продукта, над которым мы работали последние несколько спринтов. Сейчас мы начинаем новый проект в следующем спринте, а ПО создает документацию для продукта, который ранее был историей пользователя для этого спринта.
Мне просто интересно ваше мнение об этом подходе. Лично я не согласен с тем, что документация - это история пользователя в Scrum, потому что она не производит никакого кода.
РЕДАКТИРОВАТЬ: Спасибо за ваше мнение, ребята. У меня в глубине души было то, что спринт должен был реализовать инкремент работающего программного обеспечения, но ваши взгляды изменили мою точку зрения. Спасибо за все ваши ответы.
scrum
user-story
ediblecode
источник
источник
Ответы:
«Как пользователю X, мне нужно знать, как работает X», мне кажется, это легитимная пользовательская история. Это может привести к письменной документации или онлайн-помощи.
Дело не просто в коде - оно отвечает требованиям пользователей.
источник
В идеале документация является частью каждой пользовательской истории и никогда не накапливается. Но в реальном мире этого часто не происходит. В этом случае вы должны создать пользовательскую историю, чтобы наверстать упущенное в документации.
Вы правы, он не производит никакого кода. Но он удовлетворяет требованиям пользователя и должен иметь приоритет перед другими требованиями пользователя.
Если это означает, что это никогда не будет сделано, потому что над этой и той функциональностью работают, то вам, вероятно, не нужна документация так сильно.
источник
Я согласен с оценкой документации pdr, если это касается требований, технической или проектной документации. В идеале это должно быть включено в работу спринта.
Документация по продукту, на мой взгляд, сильно отличается, так как это фактический результат, запрашиваемый пользователем, и напрямую обеспечивает ценность для пользователя. Это, конечно, следует понимать, что документация по продукту, по сути, является не технической задачей, а функциональной задачей и может или не может быть подходящей деятельностью для технического ресурса по проекту.
Я думаю, что это должна быть история пользователя, однако я считаю, что этим задачам должны быть назначены ресурсы проекта, которые имеют четкое понимание бизнес-требований, точки зрения пользователя и хорошие навыки технического письма. В идеале это должен быть бизнес-аналитик, если таковой имеется, или, возможно, тестер QA более высокого порядка с четким пониманием требований, пользовательских историй и хорошими техническими навыками письма. Это также может быть разработчик, однако документация по продукту, написанная разработчиками, имеет тенденцию быть не такой качественной или полезной, поскольку разработчики обычно слишком близки к техническим деталям.
источник
В нашей организации инструментальная команда, отвечающая за поддержание и совершенствование нашей системы непрерывной интеграции, использует Scrum, чтобы помочь им управлять своей работой. Они не пишут код, но тем не менее практикуют Scrum.
Чтобы конкретно ответить на ваш вопрос, я бы спросил, считает ли команда, что документация является частью «Определения выполненного», или нет.
Если группа считает, что документация является частью «определения выполненного», тогда нет необходимости в дополнительном материале, и материал не может быть принят, если документация не написана и не подтверждена.
Если команда считает, что документация не является частью «определения выполненного», я бы создал отдельную историю, чтобы владелец продукта мог управлять своей работой.
источник