Как Вы стараетесь не ожидать требований при использовании повторяющихся методов гибкой разработки как ТОЛПА? [закрытый]

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

Если я понимаю Вашу ситуацию правильно, BAS те отставание. Существует две вещи, которые Вы могли попробовать.

1. Попробуйте или маленькие спринты или меньшие блоки требования. Так или иначе работа для BAS должна быть более краткой и managable.

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

Если, однако, проблема состоит в том, что BAS должен видеть предыдущие требования в "дикой природе" прежде, чем сделать больше требований, у Вас есть намного большие проблемы.:)

В предыдущем положении мы управляли этим путем просьбы, чтобы наши корпоративные клиенты были неделей вперед или около этого. Уверенный это повреждается от некоторых строгих интерпретаций гибких, но это сделало вещи настолько легче. У нас были бы и тестирование и бизнес, отделывающийся от недели или 2 от разработки поэтому, когда разработчики работали над повторением, 2 тестирования работают над тем, что вышло из IT1, и бизнес находится на IT3. Приоритет всегда отдавался активной разработке поэтому иногда, это сломалось, если история была особенно гибка (т.е. бизнес должен был провести много времени, пересмотрев вещи середина повторения), но в целом это работало хорошо.

Обновление для ответа на Обновление корреспондентов

Это кажется мне, они действительно не стоят самостоятельно как истории затем, и возможно команда BA должна переоценить, как они пишут истории. Я подразумеваю, что Вы не можете reall "говорить, что рассказ" с настраивает X экранов. В теории история должна быть чем-то как, "Когда пользователь переходит к экрану X, они должны смочь изменить (и сохранить) floozit"

Кажется, что BAS не может вручать Вам Ваши пользовательские истории для спринта своевременно.

Я беру его, что нет никаких сессий планирования спринта от того, что Вы говорите.

Учитывая, что один из больших принципов Толпы - то, что группа разработчиков берет на себя ответственность за то, что они продолжат работать на спринт, она кажется, что это не является слишком гибким мне! (-:

Кроме наличия коротких спринтов, который является.

"пользовательская история" является заполнителем для будущего разговора, поэтому доберитесь перед клиентом и спросите их; если это - задание BA, зажгите огонь ;-)

Ну, несколько вещей могли бы помочь - В процессе ТОЛПЫ, существует понятие о Владельце продукта wchich, Роль Свиньи, это представляет клиента. Таким образом, можно пригласить PLM или основной контакт клиента на встречу ТОЛПЫ. Это даст некоторое закрытие сделки Вашего клиента в Ваш процесс и заставит их работать "с" Вами на Ваших целях - Еженедельно создает клиенту, мог бы помочь. Так, основная идея о еженедельных отбрасываниях состоит в том, чтобы показать клиенту "прогресс". Таким образом, если в течение нескольких недель нет никакого прогресса, это должно поднять вопрос "почему?" и затем необходимо смочь объяснить, что это из-за отсутствия завершения требований.

Надеюсь, это поможет

Ваши пользовательские истории являются неполными. 'Экран Customize X' является задачей, он не описывает требований или критериев завершения. Пользовательская история должна быть, что-то как 'Позволяет Nancy видеть связанные заказы на покупку для объекта в материально-технических ресурсах'. Затем разломайте это на задачи во время Вашего спринта, что можно продолжить работать.

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

Я вижу несколько способов обработать это:

Опция 1, Под ТОЛПОЙ, у Вас должен быть Владелец продукта, который управляет Вашим отставанием продукта, которое, как предполагается, содержит запросы на функции программного обеспечения. Если функция состоит из чего-то неопределенного как 'Экран X Customize', и Вы решаете добавить, что к Вашему спринту, то задачами спринта должны быть конкретные, анализируемые задачи, и я сказал бы, что одна из тех задач должна быть, 'Определяют требования для экрана X'.

Во время ежедневной ТОЛПЫ, когда Вы задаете свои три вопроса каждого члена команды, разработчик, у которого есть та экранная задача модификации, скажет, что "я заблокирован, ожидая требований от BA". и Ваше ведущее устройство толпы делает то, что они могут для получения того прохождения.

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

Легкий.

Позвольте себе думать за пределами строгих правил Толпы и возвращаться к Вашим минимизированным корням: http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/ http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/ http://www.infoq.com/articles/hiranabe-lean-agile-kanban

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