Как вы можете избежать требований при использовании итеративных гибких методов разработки, таких как SCRUM?


7

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

EDIT: Дополнительная информация: Мы настраиваем приложение COTS для нашего внутреннего использования. Наши «истории пользователей» состоят только в том, какую часть приложения мы будем настраивать в конкретном спринте, а также в каких системах мы будем интегрировать с внутренним. Интеграция с различными системами обычно работает очень хорошо, потому что мы можем сразу начать работать над этим. «Настройка экрана x» - это основные проблемы, потому что разработчики ничего не могут сделать. Мы должны подождать, пока мы не получим требования от BAS, прежде чем мы сможем действительно что-либо сделать.

EDIT: Больше понимания/путаница возможно: Интересно, если часть проблемы заключается в том, что экран, который в настоящее время настроены уже там, как это COTS продукт, который в настоящее время в значительной степени настроен. Люди предполагают, что рассказы пользователей должны быть похожими на «сделать экран, который делает X». Это уже сделано. Возможно, нет хорошего способа сделать пользовательские истории для этих требований ... возможно, это должен быть совершенно новый вопрос.

9

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


3

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

Update, чтобы ответить на questioneers Обновление

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

  0

Хммм ... проблема в том, что экран уже существует ... поэтому изменения идут по строкам «переместите это поле здесь» или «это поле должно быть рассчитано как XXXXXXX, а не как сейчас», , Наши требования к документам, которые мы получаем, в основном представляют собой большой список этих изменений для экрана. 23 сен. 082008-09-23 20:30:43

  0

Интересно. Моя первая мысль тогда была бы, почему бы не сделать каждую из тех статей истории albiet очень очень низкой истории сложности. Если это невозможно или просто пустая трата времени, я бы пошел с тем, что говорили другие люди, и попросить BAS собрать эти списки ранее в этом процессе. 23 сен. 082008-09-23 20:32:34

  0

В этом проблема. Существует большое отставание от BA, которое объединяет эти документы требований. Он воспитывается на каждом сеансе обзора спринта. Мы просим их сделать это раньше, но они работают безостановочно. 23 сен. 082008-09-23 20:41:07

  0

На стороне записки ... ваше имя по каким-то причинам казалось знакомым. Я думаю, что я решил, что вы дружите с Бен Ли, с которым я работал некоторое время в 2007 году. 23 сен. 082008-09-23 20:47:39

  0

Вы на 100% верны, он мой старый колледж. 24 сен. 082008-09-24 01:06:55

  0

haha ​​small world 24 сен. 082008-09-24 13:37:35


2

Похоже, что BAS могут не передавать вам истории пользователей для спринта в своевременно.

Я полагаю, что сеансов планирования спринтов нет, из того, что вы говорите.

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

Помимо коротких спринтов.

  0

Наш владелец бизнеса и мастер схватки придумали список вещей, которые мы делаем для спринта, а затем назначим, кто их делает. На наших плановых сессиях мы обычно просто предоставляем оценки, поэтому они не очень полезны. Раньше мы тоже добровольно работали над задачами планирования спринта ... no longer 23 сен. 082008-09-23 19:28:45


4

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

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

  2. Примите участие в переработке или сбое в сквоше. Это должно дать BAs когда-нибудь опередить кривую.

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

  0

Я начинаю задаваться вопросом, есть ли проблемы с нашими историями пользователей в том, что они слишком расплывчаты/установлены раньше времени. 23 сен. 082008-09-23 19:43:29


1

Ну, может быть, несколько вещей могут помочь - В процессе SCRUM существует концепция Product Owner wchich - Pig Role, это представляет клиента. Поэтому вы можете пригласить PLM или основного контакта клиента на собрание SCRUM. Это даст вашему покупателю некоторый бай-ин в ваш процесс и заставит их работать «с вами» по вашим целям. - Еженедельные сборки для клиента могут помочь. Итак, основная идея еженедельных капель - показать «прогресс» клиента. Так что если в течение нескольких недель нет прогресса, это должно поставить вопрос «почему?». и тогда вы сможете объяснить, что это связано с отсутствием требований к завершению.

Надеется, что это помогает


1

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


1

Ваши истории пользователей неполны. «Настроить экран X» - задача, она не описывает никаких требований или критериев завершения. Пользовательская история должна быть чем-то вроде «Разрешить Нэнси видеть связанные заказы на поставку для элемента в инвентаре». Затем сломайте это во время вашего спринта, над которым вы можете работать.

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


0

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

Вариант 1, Под SCRUM, вы должны иметь владелец продукта, который управляет вашим накопившимся продукт, который, как предполагается, содержат просьбы о возможностях программы. Если функция состоит из чего-то неопределенного типа «Настроить экран X», и вы решили добавить это к своему спринту, то задачи спринта должны быть конкретными, разложенными задачами, и я бы сказал, что одна из этих задач должна быть «Определить требования к экрану ИКС'.

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

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


0

Простой.

Позвольте себе думать вне строгих правил Scrum, и вернуться к своим худых корням: 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

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


0

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