В гибких пользовательских историях / пользовательских историях толпы, сколько деталь достаточно? [закрытый]

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

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

Как клиент, я хочу расплачиваться кредитная карта ...

Тест с Visa, MasterCard

Кстати, ваши истории кажутся немного странными. Они должны быть ориентированы на клиента / особенности.

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

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

Подробное описание историй на самом деле является частью работы владельца продукта (PO). Это должно происходить во время первой части собрания по планированию спринта, где ЗП объясняет каждую историю команде, перед планированием покера и / или в любое время, если требуются какие-либо разъяснения. Другими словами, не стесняйтесь спрашивать подробности у ЗП (и спрашивайте у ЗП также критерии приемки). А если есть слишком много неопределенности, поставьте перед историей большую оценку и объясните, почему вы не можете сделать «лучшую» оценку.

Мне кажется, что ваш ЗП / заказчик / заинтересованные стороны не очень активно участвуют, и это большое, очень БОЛЬШОЕ препятствие. Ваш ScrumMaster должен позаботиться об этом, волшебного решения не существует.

не стесняйтесь спрашивать у ЗП подробности (а также спрашивайте у ЗП критерии приемки). А если есть слишком много неопределенности, поставьте перед историей большую оценку и объясните, почему вы не можете сделать «лучшую» оценку.

Мне кажется, что ваш ЗП / клиент / заинтересованные стороны не очень активно участвуют, и это большое, очень БОЛЬШОЕ препятствие. Ваш ScrumMaster должен позаботиться об этом, волшебного решения не существует.

не стесняйтесь спрашивать у ЗП подробности (а также спрашивайте у ЗП критерии приемки). А если есть слишком много неопределенности, поставьте перед историей большую оценку и объясните, почему вы не можете сделать «лучшую» оценку.

Мне кажется, что ваш ЗП / клиент / заинтересованные стороны не очень активно участвуют, и это большое, очень БОЛЬШОЕ препятствие. Ваш ScrumMaster должен позаботиться об этом, волшебного решения не существует.

Элементы невыполненной работы Scrum / Истории пользователей не должны быть очень конкретными, чтобы быть добавленными в Бэклог.

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

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

Преждевременные подробности - это трата .

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

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

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

Для начала вам может потребоваться больше деталей в определении вашей истории, если

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

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

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

Вопросы, с которыми я бы сразу вернулся к заказу на покупку, следующие: Какова логика рабочего процесса XXX? Какие есть варианты на каждом этапе? Какие (если есть) действия регистрируются? Какие электронные письма / уведомления отправляются? Как? кому?

Если владелец продукта не может сформулировать продукт и рассказывает Scrum-мастеру, как работает Agile, возможно, ему нужно «обучение».

Попробуйте создать пустой экран и спросите его, чего не хватает.