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

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

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

Независимый

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

Возможен торг

Согласно методологии Agile, хотя PBI находится в бэклоге продукта, его можно переписать или даже отбросить в зависимости от бизнес-, рыночных, технических или любых других требований членов команды.

Однако, в частности, договороспособность связана со степенью, в которой разработчик имеет свободу обсуждать детали решения с бизнесом во время разработки. История не должна образовывать жесткий контракт с подробным описанием дизайна, а вместо этого должна рассказывать о бизнес-результатах, которых пользователь сможет достичь после реализации. Количество «пространства для маневра», которое аналитик оставляет разработчику в этом отношении, является мерой его договороспособности. Поэтому в очень обсуждаемой истории обычно стараются избегать детального проектирования пользовательского интерфейса, особенно в том, что касается заявления о ценности и критериев приемки. Истории не являются подробными спецификациями и не должны быть таковыми.

Ценный

Целью Agile-методологии является непрерывное предоставление ценного программного обеспечения, поэтому PBI должен приносить пользу заинтересованным сторонам. ^[2]

Иногда история сама по себе может не привести к созданию полноценной готовой к выпуску функции, и это может быть просто измеримым шагом на пути к этой цели. Тем не менее, история должна, по крайней мере, быть наглядной для заинтересованной стороны и показывать, что прогресс (т.е. что-то ценное) был достигнут. Например, было бы приемлемо, чтобы закодированный/текстовый ответ от центральной службы просто отображался в пользовательском интерфейсе пользователя (в виде текста), чтобы продемонстрировать, что данные были отправлены и приняты этой службой, и иметь лучшее представление. об этом ответе будет рассказано в другой истории. В этом смысле история была наглядной и имела определенную коммерческую ценность, хотя, возможно, и не являлась последней версией дизайна.

достойный

Первоначально Билл Уэйк полагал, что если размер PBI невозможно оценить, он никогда не будет планироваться или ставиться под задачу и, следовательно, никогда не станет частью итерации. По этой причине статьи PBI должны быть способны быть оценены в какой-то момент. Обратите внимание, что это не означает, что PBI действительно должен оцениваться во время первоначального создания PBI, а означает лишь то, что он описывает что-то, что можно оценить.

Впоследствии, с появлением INVEST, движение «Нет оценок» набрало обороты, отведя владельцев продукта от убеждения, что PBI должен быть оценен, чтобы его можно было планировать или ставить перед собой задачу. Многие специалисты по программному обеспечению берутся за работу, не оценивая затраченные на нее усилия, если предмет достаточно сужен по своему объему. ^[3] Билл Уэйк заявил, что, если бы он сегодня снова выбрал INVEST, он бы удалил «Оцениваемость» и вместо этого использовал бы букву «E», чтобы подчеркнуть один из аспектов критерия «V для ценности». ^[4]

Предупреждение: оцениваемость — это аспект ИНВЕСТИРОВАНИЯ, которым чаще всего злоупотребляют (то есть, большая часть энергии тратится на наименьшую ценность). Если бы я мог выбрать заново, у нас было бы «E = Внешний»; см. обсуждение в разделе «V — ценное».
— Билл Уэйк, https://xp123.com/articles/estimable-stories-in-the-invest-model/

«Оцениваемый» как «возможность быть оцененной» — это определение в американском английском. Чтобы избежать путаницы со значением слова «достойный уважения» в британском английском языке, в некоторых версиях модели используется ссылка «Оценить», которая также не является определенной словарной статьей. Аллен Голуб предложил принять значение британского английского языка, считая, что процесс оценки вреден для процесса разработки программного обеспечения. ^[5]

Маленький

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

Тестируемый

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

См. также

Ссылки

^ Оригинальная статья Билла Уэйка: ИНВЕСТИРУЙТЕ в хорошие истории и SMART-задачи.
^ Принципы, лежащие в основе Agile-манифеста
^ «Движение без оценок» .
^ «Достойные истории в модели INVEST - XP123» .
^ Штурм событий - Аллен Голуб (Holub Associates), Конференция по архитектуре программного обеспечения O'Reilly, 10–13 июня 2019 г.

Внешние ссылки

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

[1] Оригинальная статья Билла Уэйка: ИНВЕСТИРУЙТЕ в хорошие истории и SMART-задачи.

[2] Принципы, лежащие в основе Agile-манифеста

[3] «Движение без оценок» .

[4] «Достойные истории в модели INVEST - XP123» .

[5] Штурм событий - Аллен Голуб (Holub Associates), Конференция по архитектуре программного обеспечения O'Reilly, 10–13 июня 2019 г.

[1]

[2]

[3]

[4]

[5]