Как справиться с изменением критериев приемлемости для пользовательской истории?
Мне интересно узнать, как люди справляются с изменениями критериев приемлемости пользовательских историй на уровне процесса.
Пример:
Вы пишете историю пользователя с критериями приемлемости для функции XYZ. Эта пользовательская история была реализована в спринте версии 1.0. Некоторое время спустя для версии 1.2 владелец продукта хочет, чтобы критерии приемки были другими (например, 1 минута ожидания вместо 30 секунд).
Как вы справляетесь с этим изменением? Как это меняет статус вашей оригинальной пользовательской истории? Мы используем JIRA/JIRA Agile, и мне было бы интересно услышать, если вы, например, заново откроете свои закрытые пользовательские истории и поработаете над ними в новом Sprint.
Мы используем Confluence для написания спецификаций наших продуктов, а пользовательские истории в PS загружаются напрямую из JIRA через запрос. Если кто-то изменит критерии приемлемости исходной пользовательской истории и снова откроет ее, то как можно будет гарантировать, что спецификация продукта для версии 1.0 не изменится?
РЕДАКТИРОВАТЬ:
Мне нужно добавить еще немного информации о нашем процессе: каждая пользовательская история имеет, а также критерии приемлемости некоторые шаги, которые можно использовать для проверки этих критериев. Эти шаги используются для генерации протокола проверки / тестирования, который используется для проверки правильности всех характеристик продукта.
Теперь это означает, что изменение пользовательской истории напрямую повлияет даже на уже проверенные и подписанные спецификации продукта и протоколы испытаний, поскольку данные загружаются с помощью запроса jira. Я предполагаю, что это может быть неадекватный способ втянуть контент в Confluence, что-то более постоянное кажется целесообразным.
Даже если бы мы не использовали эти прямые / динамические запросы, вопрос остается в силе: как изменение требований / критериев приемлемости влияет на историю пользователей?
5 ответов
Спасибо всем за ваши ответы. С тех пор мы нашли способ, подходящий для нас, чтобы обрабатывать изменения в пользовательских историях.
В итоге мы получили следующие принципы / шаги:
- После выпуска версии программного обеспечения все пользовательские истории, являющиеся частью спецификации продукта для этого выпуска, больше не должны изменяться.
- Если критерии принятия пользовательской истории должны быть изменены после выпуска, запрос на изменение подается и связывается с историей
- Затем запрос на изменение обрабатывается - в ходе этого клонированная пользовательская история клонируется, адаптируется к измененным критериям приемлемости, а затем добавляется в спецификацию продукта для следующего выпуска, в то время как старая пользовательская история удаляется.
- Новая пользовательская история теперь может быть реализована во время спринта
Таким образом, у нас есть спецификация продукта для v1.0, которая содержит неизмененную пользовательскую историю, и спецификация продукта для v2.0, которая содержит обновленную пользовательскую историю.
Важным фактом является то, что через несколько лет вы можете подобрать спецификацию продукта для любой версии, проверить ее на соответствие критериям приемлемости и при этом получить ПРОХОД. Этого не произошло бы, если бы исходная пользовательская история была изменена.
Надеюсь, мне удалось объяснить это с достаточной ясностью. Пожалуйста, дайте мне знать, если мне нужно уточнить какие-либо части решения.
Я бы посчитал это новой пользовательской историей, например: "Как пользователь, я бы хотел, чтобы время ожидания увеличилось до 1 минуты по причинам, наиболее известным мне".
Поэтому после выпуска продукта Владелец продукта возвращается к вам и говорит, что ему хотелось бы:
1 минута ожидания вместо 30 секунд
Это может считаться проблемой; Это не ошибка, так как тайм-аут работает нормально, просто у них есть проблема с периодом. Следовательно, вы можете создать проблему, связать ее с исходной историей, а затем разбить ее на задачи для реализации этого изменения.
Тем не мение:
Как можно гарантировать, что спецификация продукта для версии 1.0 не изменится?
Если в исходной спецификации продукта указано время ожидания 30 секунд, но теперь вы изменили его на одну минуту, то от того, что спецификация была изменена, не уйдет. Создание проблемы и ее привязка к оригинальной истории означает, что вам не нужно редактировать оригинальную историю.
Я бы сказал, что ваша оригинальная история остается хорошей. Учитывая, что изменение тайм-аута имеет смысл, у вас есть явная необходимость изменить критерии приемлемости для вашей первоначальной истории. Это особенно верно, когда ваши тесты автоматизированы. Я бы создал новую историю:
Как я хочу изменить значение тайм-аута для манипулирования скобками
Написание этой новой истории чудесно сфокусирует ум на ценности, которую принесут эти изменения. Если это не добавляет никакой ценности, тогда не делайте этого.
Вы не можете изменить критерии приемлемости пользовательской истории, как только она будет завершена(да, см. Определение выполненной работы).
Если владелец продукта должен изменить критерии принятия пользовательской истории, он должен создать новую функцию / пользовательскую историю с "Критериями принятия".
Если изменение произошло в середине спринта, и существующие критерии принятия не будут иметь никакого смысла для проектирования, удалите пользовательскую историю из журнала заданий спринта и добавьте ее в новый(изменение не должно быть принято в середине спринта) спринта. с новыми / измененными критериями приемлемости.