Scrum-как получить лучший вклад от функциональной / коммерческой команды

Вы пробовали работать с вашим клиентом, чтобы определить / сформулировать приемочные тесты ?
Использование чего - то вроде Fit, чтобы придумать эти тесты, приведет к улучшению спецификаций, а также заставит клиента думать о том, что действительно требуется. Глазурь на торте составляет instant-doc-executable% в конце этого процесса.

Это, конечно, если ваши клиенты доступны и открыты для такого подхода. Дайте ему попробовать!

Если нет (и это, кажется, большинство - потому что это меньше работы) - календарь flash ' em-расписание встреч/телеконов каждую неделю, пока они не поют, как канарейки :) +1 к Дане

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

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

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

Я понимаю, что люди, которых вы называете функциональными людьми, действуют как владельцы продукта, верно?

Я думаю, что часть проблемы заключается в том, что нет никаких спецификаций или пользовательских историй как таковых. Лично я думаю, что они должны записывать какие - то требования-какие вещи они должны записывать и до какой сложности, учитывая его процесс agile?

На самом деле, без каких-либо спецификаций у вас, вероятно, нет приемочного теста для невыполненной работы itens. Вы должны попросить PO написать пользовательские истории, мне нравится "как тип пользователя -, я хочу-какую-то цель-так что-какая-то причина-." форма. Имейте в виду, что пользовательские истории должны быть INVEST - I зависимыми, N эгоистичными, V доступными для пользователей или клиентов, e стимулируемыми, S mall и T estable. Что является обязательным, так это иметь приемочные тесты, написанные вместе с историей, чтобы команда знала, что история должна быть в состоянии сделать, чтобы быть настроенной как сделано.

Помните, что по мере развития продукта ожидается, что у PO будут идеи, как он видит рабочий продукт. Это не плохо, на самом деле это одна из лучших вещей, которые вы можете получить через Agile. То, что вы должны обратить внимание, это то, что эти идеи mus будут включены в отставание продукта, и он должен быть приоритетным по th PO. И, если это необходимо и добавит ценность для клиента, идея должна быть спланирована, чтобы быть построена в следующем спринте.

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

Как вы можете оценить элемент невыполненной работы, если они недостаточно детализированы ?

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

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

Кроме того, убедитесь, что все члены функциональной команды и команды разработчиков говорят на одном языке, чтобы избежать недоразумений ; см. раздел вездесущий язык .

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

Участвуют ли они в стендап-встречах?

Вы можете предложить иметь представителя в каждом (или некоторых) из них, чтобы попросить их внести свой вклад до конца спринта

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

Я рекомендую книгу "практики разработчика agile" она полна предложений, как сделать команду scrum успешной. Он также дает хорошие советы, как привлечь владельца продукта/клиента к более активному участию и как получить весь процесс прокатки. Это стоит денег IMHO.

Я согласен, что вам нужны какие-то требования (истории пользователей или иначе).

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

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

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