Примеры критериев приемлемости для пользовательской истории
У меня есть следующий пример для пользовательской истории с критериями приемлемости.
Я хотел бы знать, разрешено ли мне описывать, как графический интерфейс должен быть изменен для поддержки новой функции.
Это мой пример:
История пользователя:
- Как администратор форума я буду объединять людей в группы, чтобы люди могли организоваться.
Критерии приемки:
- Создание группы лиц происходит ниже пула групп людей (пул групп людей - это объект, также визуально доступный в текущей системе программного обеспечения)
- Создание происходит с помощью контекстного меню пула персонгруппы. Ниже бассейна можно создавать новые группы.
- Группа лиц содержит: идентификатор группы лиц, описание, примечание
Может ли это быть правильным критерием приемлемости?
С наилучшими пожеланиями, Кай.
3 ответа
Хорошо, независимо от того, переносится ли этот вопрос, я решил оставить свое мнение.
Критерии приемки выбираются владельцем продукта простым и понятным образом. Это способ формализовать то, что Владелец продукта должен увидеть, чтобы иметь возможность подписать историю как "завершенную".
То, насколько подробно PO хочет внести в это, является продуктом стиля работы, знаний и т. Д. Многие PO имеют UX-обучение и хотели бы пойти так далеко, чтобы определить, как это должно выглядеть. Я думаю, что это нормально, пока это работает для вашей команды. Другие в основном являются экспертами по работе с клиентами и оставляют дизайн команде.
Лично я бы посоветовал командам формализовать столько, сколько можно подумать, глядя на историю, чтобы вы минимизировали количество противоречивых предположений между командой и ПО.
Однако, в конце концов, команде решать, принять ли историю в свой спринт. Они имеют полное право (во всяком случае, в Scrum) сказать, что AC слишком широки, чрезмерно предписаны, неосуществимы или слишком велики, чтобы их можно было пережевать за один спринт. Поэтому, как правило, между командой и ПО происходит много переговоров, прежде чем согласовывать AC для каждой истории.
Но, в конце концов, это звонок Владельца Продукта, поскольку именно она будет "принимать". В целом Scrum говорит, что задача Владельца продукта состоит в том, чтобы сказать, что создавать, и в работе команды сказать, как его построить (и на самом деле сделать это). Так что на самом деле это о том, какой тип ПО вы хотите быть.
Вы можете добавить приемочные тесты в свои пользовательские истории. Мой вопрос может дать вам некоторое представление о том, как другие подходят к спецификации пользовательских историй.
Я бы описал, как пользователь взаимодействует с пользовательским интерфейсом (то есть с UX) в соответствующем приемочном тесте, а не с критериями приемки. Критерии лучше подходят для проверки входных данных и других бизнес-правил, которые не нужно включать в приемочные тесты более высокого уровня.
По моему опыту, ответ Марка на деньги о пригодности AC, перечисленных OP. Тем не менее, хотя эти критерии приемлемы, я полагаю, что их недостаточно, чтобы уменьшить двусмысленность в отношении того, что ПО ожидает от продукта, когда история представляется для принятия.
В дополнение к перечисленным AC, которые описывают, как будет реализована история, я ожидаю увидеть AC, которые описывают, что будет делать продукт. Например, видны ли эти группы пользователям форума, а также администратору? Как вы определяете "подключиться"? Каковы детали бизнес-логики, связывающей пользователей и группы? Охватывает ли история как "сопоставление", так и "сопоставление" пользователей с группами, или они были разделены, чтобы держать историю в пределах спринтерского размера?