Как писать хорошие user stories: part 2

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

Хорошие практики

• Используйте истории как возможность начать общение с командой, пользователями и клиентами. История – это не спецификация, ее не должен писать аналитик в гордом одиночестве и она не заменяет диалога. Все ровным счетом наоборот: история – это суть обсуждений того, как пользователи взаимодействуют с продуктом.
• Написание пользовательских историй – это командная работа. Обязательно привлекайте к написанию пользовательских историй стейкхолдеров и реальных пользователей, не говоря уже об участниках команды.
• Работайте над декомпозицией ваших историй: начинайте с больших историй (эпиков) и дробите их на маленькие, детализированные истории.
• Не ленитесь писать критерии приемки. Как только у вас есть декомпозированные истории, обязательно займитесь ими, ведь критерии приемки помогают истории стать полноценной, и дают возможность легко тестировать соответствие готового продукта истории.
• Используйте бумажные карточки. Попытки записывать истории на страничке в вики или в JIRA прямо на встрече по планированию обречены на провал и убивают командную динамику. Бумажные карточки гораздо приятнее – они отрывают всех от ноутбуков, каждый может взять карточку, записать на ней идею и прикрепить к доске. К тому же карточки очень легко двигать по доске или столу, если вы решили что-то поменять.
• Вторая часть предыдущего совета – не прячьте ваши пользовательские истории в недра вашего интранета, на какую-нибудь грустную вики-страничку. Повесьте их на стену, так чтобы все могли их видеть.
• Не пытайтесь подогнать все требования под формат пользовательских историй. К примеру, идеи, относящиеся к пользовательскому интерфейсу и чистому дизайну лучше оставить в формате набросков и скетчей.

Сомнительные практики

• Слишком формальные/слишком детализированные задачи. Иногда владельцы продукта с самыми хорошими намерениями стремятся писать слишком детальные истории. Если на встрече по планированию итерации команда видит набор историй выглядящий как многотомная спецификация, то искушение предположить, что все детали отлично освещены и пропустить обсуждение, очень велико.
• Не пропускайте обсуждения. Истории для этого и обсуждаются на планировании итерации, чтобы вскрыть неясные моменты, уточнить все детали и получить полное представление о задаче. Если вы не обсудили их всей командой, вы рискуете начать двигаться в неверном направлении во время разработки.
• Перестаньте выдавать технические задачи за истории. Если вы пытаетесь втиснуть в формат истории технические задачи, то в конце итерации у вас точно не появится готовый кусочек продукта. Если технические задачи действительно нужны и у них есть ценность для каких-либо пользователей (в том числе и внутренних, в вашей команде), то смело оформляйте их в технические истории, но не составляйте всю итерацию из подобных задач, ведь у вас, вероятнее всего, есть и бизнес-клиенты.

по материалам: 2tickets2dublin.com.ua