В дополнение к стандартному формату и полным элементам, хорошая пользовательская история также должна следовать принципам INVEST : 1. Я зависим; 2. Не подлежит обсуждению; 3. ценный ; 4. Оценить ; 5. Малый торговый центр; 6. Тестируемый .
1. Независимость . Важно сделать одну пользовательскую историю как можно более независимой от других пользовательских историй. Поддержание независимости между пользовательскими историями не только облегчает расстановку приоритетов и согласование, упрощает планирование релизов и итераций, облегчает независимое понимание, отслеживание, реализацию, тестирование и частую поставку, но также делает область оценки размера пользовательской истории более четкой и, следовательно, погрешность оценки. меньше.
2. Оборотный — содержание пользовательской истории может быть предметом переговоров; пользовательская история не является контрактом. Пользовательская история — это просто краткое описание пользовательской истории без особых подробностей; конкретные детали производятся на этапе коммуникации. Пользовательская история со слишком большим количеством деталей на самом деле ограничивает пользователя, идеи команды и общение.
3. Ценность . Каждая история должна быть ценна для клиента (будь то пользователь, покупатель или сотрудник компании). Пользовательские истории ценны для конечного пользователя, поэтому они должны быть написаны с точки зрения пользователя, описывая ФУНКЦИЮ, а не ЗАДАЧУ.
Эта функция облегчает переход от традиционного стиля работы, основанного на директивах, к самостоятельному, ориентированному на ценность стилю работы для разработчиков и тестировщиков, чтобы каждый в команде знал ценность работы, которую они выполняют каждый день.
4. Оцениваемый (может быть оценен) – Очень важной частью планерки является оценка сторис. На самом деле это грубая оценка пользовательской истории, которая должна быть разработана, чтобы команда могла знать сложность (рабочая нагрузка) этой пользовательской истории.
Основное внимание уделяется тому, может ли пользовательская история быть завершена в текущей итерации в соответствии с условиями приема этой пользовательской истории и DoD (критериями завершения), определенными командой, и если она не может быть завершена, указывается причина и ЗП. решает, следует ли разделить или изменить пользовательскую историю.
Проблемы, из-за которых разработчикам сложно оценить историю, возникают из-за недостаточного знания предметной области (в этом случае требуется больше общения) или из-за того, что история слишком велика (в этом случае ее нужно разрезать на более мелкие части).
5. Небольшой . Хорошая история должна быть как можно короче с точки зрения рабочей нагрузки, желательно не более 10 идеальных людей в день, по крайней мере, чтобы гарантировать, что она будет завершена за одну итерацию. Чем больше пользовательская история, тем больше риск при планировании, оценке рабочей нагрузки и т. д.
6. Testable (тестируемая) — пользовательская история должна быть тестируемой, чтобы подтвердить, что она может быть завершена. Если пользовательскую историю нельзя протестировать, вы не можете знать, когда она будет завершена. Пример нетестируемой пользовательской истории: программное обеспечение должно быть простым в использовании.
Три рекомендации
Пользовательская история — это, по сути, хорошая пользовательская история, если следовать принципам INVEST. Затем мы сосредоточимся на трех рекомендациях, которые помогут лучше соблюдать принципы при создании пользовательских историй.
Три рекомендации: один пользователь, полное значение и отсутствие зависимости.
1. Один тип пользователей. Включите только один тип пользователей, так как несколько пользователей часто имеют нюансы. Обычно это типичный пользователь, часто с какой-то общей потребностью.
2. Полная ценность . Предоставьте клиенту полную ценность. Полная история пользователя означает, что когда эта история завершена, пользователь может достичь четкой и значимой цели.
3. Независимость . Три общих типа зависимостей: перекрытие, последовательность и включение.
В целом следует избегать дублирования функциональных точек между историями; последовательные отношения являются реальностью и в большинстве случаев могут быть разрешены теми или иными средствами; и отношения включения полезны для сложных систем, с последствиями для планирования выпусков и планов итераций, которые требуют внимания.
Перекрывающиеся зависимости
Перекрывающиеся зависимости — это форма зависимостей, которая вызывает больше всего проблем, особенно когда несколько пользовательских историй содержат несколько разных перекрывающихся частей. Трудно найти набор пользовательских историй, которые могут представлять собой набор функций для этого минимально жизнеспособного продукта, который должен содержать и содержать функции, необходимые только один раз.
Решение
Выделите перекрывающиеся части как отдельные пользовательские истории.
Рациональное разделение пользовательских историй и сохранение совпадений только в одной из наиболее связных пользовательских историй.
Используйте модель разработки Scrum.
Последовательные зависимости
Последовательная зависимость означает, что для того, чтобы пользовательская история была завершена, перед ней должна быть завершена одна или несколько других пользовательских историй. Последовательные зависимости обычно безвредны, и есть способы смягчить такие зависимости.
С точки зрения гибкой разработки вся система постепенно развивается от начального минимально жизнеспособного продукта до надежного продукта, причем каждый последующий шаг основывается на предыдущих.
Но с другой точки зрения, ненужные последовательные зависимости усложняют ранжирование и расстановку приоритетов, что, в свою очередь, влияет на разработку планов выпуска и итераций и затрудняет оценку размера пользовательских историй.
Решение
Делайте пользовательские истории в рамках итерации настолько свободными от внутренних зависимостей, насколько это возможно.
Сохранение только односторонних зависимостей между итерациями с односторонними временными зависимостями от историй в более поздних итерациях к историям в более ранних итерациях (прямые зависимости).
Выделение основных зависимостей как отдельных историй и отказ от смешивания зависимых и независимых требований в одной истории.
Включение зависимостей
Содержащиеся зависимости относятся к использованию иерархического управления при организации пользовательских историй, например, к обычному двухуровневому управлению функциональными историями, когда функция содержит несколько пользовательских историй, таким образом образуя замкнутую зависимость функции от подчиненных ей историй.
Решение
Уровень пользовательской истории используется для планирования итераций, избегая грубого планирования итераций с уровнем функций, который можно использовать для планирования выпуска.
Уровень функций также может быть разделен до уровня минимальной рыночной функции, а содержащиеся в нем пользовательские истории могут быть отдельно сгруппированы во вновь разделенные функции.
В соответствии с концепцией минимально жизнеспособного продукта функция реализуется в нескольких итерациях нескольких пользовательских историй, каждая из которых может привести к потенциальному результату или обеспечить внутреннюю или внешнюю обратную связь.
использованная литература
Русский
English
简体中文
繁體中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands