Agile: работа с новой пользовательской историей и ошибками для уже реализованной функции
В последние несколько итераций я всегда осознавал, что мы упустили детали пользовательской истории некоторых реализованных функций после того, как клиент начал использовать APP.
Например:
Исходное требование: "можете добавить товар в мини-корзину (... правила добавления товара)"
Исходная история пользователя: "можно добавить товар в мини-корзину (... обработка добавления товара)"
Фактически реализованная функция: "продукт может быть добавлен в мини-корзину как требования. Но он сбрасывает все критерии фильтра и обновляет страницу после добавления продукта"
Покупатель надеется, что это выглядит так: "продукт может быть добавлен в мини-корзину в соответствии с требованиями. Чтобы сохранить текущие критерии фильтра и обновить страницу после добавления продукта"
Эти требования были собраны нами. Эти пользовательские истории были написаны нашей аутсорсинговой командой.
Должен ли я считать, что это ошибка или история нового пользователя, или я просто должен заново открыть историю старого пользователя и отредактировать ее, чтобы учесть новый запрос? Что такое "лучшие практики", каковы плюсы и минусы каждого подхода?
Большое спасибо!
Насколько я понимаю, бизнес-требования всегда просты, пользовательские истории всегда маленькие и абстрактные. Иногда мы не могли понять вышеупомянутую проблему, пока разработчик не начал писать код, и разработчик не сказал нам. Это функциональный процесс и техническая проблема, которую необходимо представить разработчику на этапе разработки. так что я думаю, что это ошибка.
2 ответа
Пользовательская история намеренно проста и абстрактна. Причина в том, что это считается "приглашением к разговору". Это означает, что когда команда приближается к работе над историей, которую они обсуждают с Владельцем продукта, чтобы начать раскрывать детали истории. Это может произойти при уточнении отставания или как часть сеанса планирования спринта.
Идея состоит в том, чтобы иметь правильный уровень детализации истории в нужное время. Поэтому, когда разработчики начинают работать над историей, они уверены, что знают достаточно, чтобы выполнить работу так, как ее попросил Владелец продукта.
Если в пользовательской истории недостаточно подробностей, она не считается готовой для участия в спринте. Вот почему команда разработчиков и владелец продукта работают в тесном контакте, чтобы своевременно добавлять детали.
Даже если разработчик начал работать над историей, он часто будет разговаривать с владельцем продукта. Например, они могут макетировать добавление продукта в мини-корзину, показать его Владельцу продукта и проверить, соответствует ли оно их требованиям.
Этот процесс имеет решающее значение для Scrum. Если вы обнаружите, что истории должны быть переработаны, то это признак того, что процесс работает неправильно. Поговорите об этом в своих ретроспективах и постарайтесь решить, как лучше всего решить проблему.
Здесь я вижу проблему с тем, что мы называем "определением готовности" для истории, поэтому критерии, которые должна иметь история, чтобы ее можно было учитывать при планировании и выполнении (например, INVEST: https://en.wikipedia.org/wiki/INVEST_(mnemonic)). Я полагаю, что правильная проверка истории не была сделана. В совместных командах это не нужно, потому что цель истории - предложить разговор с владельцем продукта, но для оффшорной или аутсорсинговой разработки всегда полезно проверять определение готовности к истории.
в вашем конкретном случае я не был бы так обеспокоен методологией (ошибка или новая история), предполагая, что вы находитесь не в организации, сертифицированной по ISO, где вам нужно делать вещи точно так, как вы сказали, что вы будете делать их:), но больше о том, что самый быстрый способ предоставить обещанную ценность для клиента. если вы обнаружите ошибку, исправьте ее и внедрите исправление - это быстрый способ сделать клиента счастливым, просто сделайте это. позже внесите это в ретроспективу и перейдите к основной причине и устраните ее.