Работая в Agile, команда проекта регулярно поставляет части программного обеспечения, описанные в User Stories. После каждого Спринта поставляется работающее программное обеспечение с добавлением некоторых дополнительных функций.
Преимущество и недостаток пользовательских историй в том, что они описывают завершенную функцию. Разработка кода для User Story имеет несколько подзадач, и проблема заключается в том, что некоторые задачи не могут быть выполнены в рамках Sprint, часто до конца проекта. К таким задачам относятся: интеграция со сторонним API, зависимость от внешней системы.
Например, проект веб-разработки:
WEB-122: «Как покупатель, я вижу экран подтверждения заказа, где я могу просмотреть заказанные товары, общую сумму, информацию о налогах. Я нажимаю кнопку «Оплатить сейчас», чтобы перейти на страницу SomeExtravagantPaymentService и завершить платеж»
Проблема: клиент ведет переговоры только с SomeExtravagantPaymentService и не может предоставить данные для входа. Кроме того, сервис не предоставляет бета-версию или песочницу для текстовых сообщений (в Европе это довольно распространено) - зависимость от стороннего API.
Например, проект строительства дома:
DWELL-234: «Я хочу, чтобы в подвале было электричество и лампочки, управляемые выключателем».
Проблема: даже если выключатели и лампочки установлены правильно, эта пользовательская история не может быть завершена и протестирована до тех пор, пока электрическая компания не подключит дом к линии электропередач, что может произойти на более поздних этапах разработки. Зависимость от внешней системы.
Проблема описанных пользовательских историй в том, что такие истории не могут быть закончены за несколько спринтов и будут тянуться от спринта к спринту. Клиент не получит готовый продукт после спринта. Как можно было бы управлять этой ситуацией?
Проблема описанных пользовательских историй в том, что такие истории не могут быть закончены за несколько спринтов и будут тянуться от спринта к спринту.
Вам нужно разбить свои истории дальше, используя модель INVEST . Пишите свои истории таким образом, чтобы каждая из них была самодостаточной и не зависела от других факторов или была минимальной.
Итак, вашу историю можно переписать так:
WEB-122a: «Как покупатель, я хочу разместить заказ, чтобы получить необходимые товары»
WEB-122b: «Как покупатель, я хочу просмотреть свой заказ, чтобы проверить заказанные товары, общую сумму, налоговую информацию»
WEB-122: «Как покупатель, я хочу оплатить свой заказ, чтобы мой заказ мог быть обработан (и доставлен мне)»
В идеале пользовательская история должна быть полностью поставлена за один спринт, она не должна затягиваться.
Я думаю, проблема в том, что вы не разобрали историю. Когда вы пишете рассказ, постарайтесь разбить ваши требования высокого уровня на минимально возможный уровень.
Пример в случае, который вы упомянули:
Как покупатель, я вижу экран подтверждения заказа, где я могу просмотреть заказанные товары, общую сумму, налоговую информацию. Я нажимаю кнопку «Оплатить сейчас», чтобы перейти на страницу SomeExtravagantPaymentService и завершить платеж.
История может быть разбита на более мелкие истории, такие как:
Так что в этом случае, как только вы закончите с экраном подтверждения, вы можете передать его своему клиенту. Вы можете перейти на страницу SomeExtravagantPaymentService после этого, как только ваш клиент подтвердит это. До этого он будет находиться в бэклоге продукта и не будет браться в спринт.
Таким образом, вы можете отслеживать свою историю и доставлять полные пользовательские истории своему клиенту в конце спринта, и вы можете избежать переноса задачи на следующий спринт.