ИНВЕСТ (мнемоника) - INVEST (mnemonic)

В Мнемоника INVEST за Гибкая разработка программного обеспечения проекты были созданы Биллом Уэйком[1] как напоминание о характеристиках качественного элемента бэклога продукта (обычно написанного на история пользователя формат, но не обязательно) или PBI для краткости. такие PBI могут использоваться в Scrum отставание, Канбан доска или XP проект.

ПисьмоСмыслОписание
яНезависимыйPBI должен быть самодостаточным, чтобы не было внутренней зависимости от другого PBI.
NДоговорнаяPBI не являются явными контрактами и должны оставлять место для обсуждения.
VЦенныйPBI должен приносить пользу заинтересованным сторонам.
EПриблизительныйВы всегда должны иметь возможность оценить размер PBI.
SМаленькийPBI не должны быть настолько большими, чтобы их невозможно было планировать / выполнять / расставлять приоритеты с определенной степенью точности.
ТПроверяемыйPBI или связанное с ним описание должны предоставлять необходимую информацию, чтобы сделать разработку тестов возможной.

Независимый

Одна из характеристик гибких методологий, таких как Scrum, Канбан или же XP это возможность перемещать PBI с учетом их относительного приоритета, например, без особых усилий. Если вы обнаружите, что PBI сильно зависимы, хорошей идеей может быть объединение их в один PBI.

Договорная

Единственное, что зафиксировано и высечено в гибком проекте, - это невыполненная итерационная работа (и даже в этом случае это «может быть уточнено и пересмотрено ... по мере того, как станет известно больше».[2]). Хотя PBI находится в бэклоге продукта, его можно переписать или даже выбросить, в зависимости от требований бизнеса, рынка, технических или любых других требований членов команды.

Ценный

Основное внимание здесь уделяется тому, чтобы предоставить заинтересованным сторонам реальную ценность проекта. Придумывание технических PBI, которые действительно интересно кодировать или разрабатывать, но не приносят никакой пользы заинтересованным сторонам, нарушает один из принципов Agile, который заключается в непрерывной поставке ценного программного обеспечения.[3]

Приблизительный

Если размер PBI невозможно оценить, он никогда не будет планироваться или назначаться; таким образом, он никогда не станет частью итерации. Таким образом, на самом деле нет никакого смысла хранить такого рода PBI в бэклоге продукта. В большинстве случаев оценка не может быть выполнена из-за отсутствия подтверждающей информации ни в самом описании истории, ни непосредственно от Владельца продукта (примечание к языку - «Оценка», поскольку «способность к оценке» является определением на американском английском. Британское определение «high esteem» может сбить с толку некоторых читателей. В некоторых версиях модели используется ссылка «Estimate -able», которая также не является определенной словарной статьей.)

Маленький

Постарайтесь, чтобы ваши размеры PBI, как правило, составляли несколько человеко-дней и самое большее несколько человеко-недель (хорошее практическое правило состоит в том, что любой отдельный элемент бэклога продукта не занимает более 50% итерации; например, один элемент не займет более 5 дней на 2-недельный / 10-дневный спринт). Все, что выходит за пределы этого диапазона, следует считать слишком большим, чтобы его можно было оценить с хорошей степенью уверенности - эти большие PBI можно назвать «эпиками», когда для доставки эпика потребуется более одной итерации, и его обязательно нужно будет разбить. на меньшие PBI, которые могут удобно поместиться в итерациях. Нет проблем в том, чтобы начать с эпических PBI, если они ломаются, когда приближается время поместить их в итерационный бэклог. Это реализует концепцию анализа Lean Just In Time.

Проверяемый

PBI следует считать СОВЕРШЕННЫМ, среди прочего, только если он был успешно протестирован. Если невозможно протестировать PBI из-за недостатка информации или доступа (см. «Оценка» выше), PBI не следует рассматривать как хороший кандидат для включения в итерационный Backlog. Это особенно актуально для команд, в которых TDD - Разработка через тестирование.

Смотрите также

внешняя ссылка

  1. Джефф Сазерленд с Блог
  2. https://agileforall.com/new-to-agile-invest-in-good-user-stories/
  3. https://www.agilealliance.org/glossary/invest

Рекомендации

  1. ^ Оригинальная статья Билла Уэйка: ИНВЕСТИРУЙТЕ в хорошие истории и умные задачи
  2. ^ Руководство по Scrum
  3. ^ Принципы Agile Manifesto