User Stories - Проблемы, которые не могут быть сделаны пользователями истории

Question

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

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

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

1. Его слишком большой (разработчику нечего показывать до конца 5 недель).
2. Это сложный алгоритм или абстрактная концепция (потребуется 5 недель для написания и ничего не показывать).

Этот вопрос заключается в получении советов, советов или предложений.

Я ищу подсказки, советы и рекомендации относительно того, как решать эти и подобные воспринимаемые проблемы (и многое другое, если вы можете думать о них).

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

Answer 1

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

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

Помните: точка итерации не должна обеспечивать полную функциональность, а лишь полезную и тестируемую функциональность.

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

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

Answer 2

Проблема с «алгоритмической спецификацией» является общей.

Многие люди предпочитают писать код и на самом деле не заботятся о том, кто этот пользователь или что они делают.

Я пытаюсь заставить их сосредоточиться, задавая эти вопросы.

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

Information-Decision-Action.

Мы пишем только программное обеспечение для подготовки информации для людей, чтобы принимать решения, чтобы они могли принять меры.

Если это не фокус, то истории выходят из-под контроля.

Answer 3

пользователей/разработчиков, которые обыкновение писать рассказы

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

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

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

Answer 4

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

Answer 5

Вот несколько ресурсов, которые я собрал в течение долгого времени и которые могут помочь:

• Patterns for Splitting User Stories
• Story Weight Reduction Toolkit
• Twenty Ways to Split Stories
• Ways to split user stories

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

Answer 6

В основном это обязанность и ответственность владельца продукта. И могут быть любые требования/задачи, которые нельзя разделить на User Stories. Я нашел много таких обсуждений на SCrum Master Forums

Answer 7

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

проверка это блок-схема .. может быть помощь: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf