INVEST опыт из реальных проектов

Сегодня хотелось бы поговорить о практическом применении известного большинству принципа invest, который широко применяется аналитиками и Product owner в процессе разработки ПО.

Согласно Wikipedia аббревиатура invest была разработана в 2003 году Биллом Уэйком как напоминание о том, какой должна быть хорошая пользовательская история. На данный момент этот подход стал стандартом де-факто и активно применяется в проектах идущих с применением SCRUM, Kanban и XP.

В последние годы мне доводилось проводить много собеседований на позицию аналитика, и практически на каждом собеседовании я задавал вопрос про invest. И вот что интересно, абсолютное большинство знает как расшифровывается данная аббревиатура, но мало кто может действительно четко и с полным пониманием ответить на вопрос, так что же на практике означает каждая буква данной аббревиатуры, и как вот это все применить на реальном проекте?

И что важнее, очень часто на проектах я вижу User Story которые и рядом не соответствуют данному принципу, хотя написавший их аналитик вроде бы знаком с invest и может пояснить каждую букву.

Хочу сразу отметить, что я не претендую на какую-то финальную истину, и более того, многое из того что я написал в этой статье противоречит классическому пониманию User Story в SCRUM. Однако по моему опыту, и опыту ряда моих коллег, все нижеописанное очень важно для практической работы на современных проектах, более 90% которых не идут по классическому SCRUM.

Начнем с классики:

Но что это значит в реальной жизни? Давайте разбираться.

Чаще всего Independent понимается в том смысле, что истории должны разрабатываться таким образом, чтобы была возможность имплементировать их в любом порядке.

Я видел такое понимание даже в курсах от известных обучающих центров.

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

Давайте представим себе следующую историю:

В процессе работы над задачей аналитик понимает, что части данных, которые хочет увидеть Руководитель отдела продаж, даже нету в системе! А для сбора и обработки некоторых из них нужно еще и внедрить (или доработать) пару небольших процессов или интеграций. И вот наша Стори уже стала эпиком, состоящим из нескольких историй. Объем такой задачи может легко превысить и пару месяцев, но при этом промежуточные задачи могут и не составлять большой ценности для бизнеса сами по себе.

Так же как и оценка сотрудников по отдельным показателям большой ценности не несет, нужен именно цельный отчет!

Таким образом мы либо вынуждены нарушить принцип Small и создать одну большую историю, либо же нарушить принцип Independent (а заодно и Valuable), создав цепочку историй, имплементировать которые надо в определенном порядке — ведь отрисованный отчет без данных просто не будет иметь смысла!

Так что же делать? На мой взгляд правильнее будет переформулировать для себя принцип Independent, иначе его придётся нарушать в каждом проекте.

(Independent) Независимая история — это такая история, которая может быть принята QA независимо от остальных.

Вот такая формулировка уже действительно имеет смысл и несет существенную пользу. При этом, цепочки задач и блокировки одних задач другими имеют реальный физический смысл и не противоречат данному принципу.

История должна быть обсуждаемой и тестируемой...

Обсуждаемой, значит отражать суть, а не детали + не содержать конкретных деталей реализации, которые и можно обсудить.

Тестируемой, значит быть достаточно конкретной для тестирования.

Думаю противоречие здесь достаточно очевидно.

Конечно же требование Negotiable происходит из классического понимания SCRUM, в котором представитель бизнеса сидит за соседним столом с разработчиками, а разработчики взаимозаменяемы, высоко квалифицированы, мотивированны и отлично знакомы со всем продуктом... Но в мире распределенных команд и удаленной работы, давно ли вы работали на таком проекте? Здесь сразу вспоминается сферический конь в вакууме...

Поэтому я предлагаю немного другую формулировку:

(Negotiable) Обсуждаемая история - это такая история, которая ДОЛЖНА быть обсуждена командой перед финализацией ее описания системным аналитиком и взятием ее в работу.

(Testable) Тестируемая история - история с четко прописанными критериями приемки, которые однозначно и одинаково понимаются как представителями бизнеса, так и QA, который только что пришел на проект и вообще ничего не понимает в предметной области.

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

• Либо аналитиком, который ее описал
• Либо разработчиком, который ее имплементировал.

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

И безусловно задача должна быть максимально четко и конкретно описана перед взятием ее в работу, чтобы ни у кого не осталось сомнений и недопониманий о том, как она должна быть реализована. Это важно не только для реализации задачи в конкретном спринте, но и для будущих поколений, которые в противном случае не всегда смогут отличить баг от фичи.

Кстати, хорошее описание критериев приемки встречается очень редко, но наверное не входит в рамки данной статьи, которая и так получилась слишком длинной.

Отмечу только, что я крайне рекомендую использовать Gherkin. Лично я всегда использую следующий простой шаблон:

Ну и в рамках Nextleap у нас есть рекомендация (и даже отдельный статус на доске в Jira) всегда согласовывать задачу с QA перед взятием ее в работу, поскольку QA и аналитики обычно мыслят немного по-разному и хорошему QA почти всегда найдется что добавить к критериям приемки, каким бы опытным и педантичным не был аналитик. Чаще всего это касается каких-нибудь side-case.

User story должна быть ценной для клиентов, бизнеса, кого-нибудь из стейкхолдеров. Здесь хотелось бы вспомнить о часто обсуждаемом феномене, заключающемся в том, что на проектах частенько возникают пользовательские требования, которые вроде бы и ценны для кого-то из стейкхолдеров, но при этом не очень-то приближают проектную команду к достижению задокументированных бизнес-целей или же раздувают согласованный scope проекта.

Говорят, что одним из основных качеств Product owner является умение сказать "Нет". Но в мире где далеко не каждый Product owner не то что не проходил сертификацию по SCRUM, но иногда даже и не читал ни одной статьи на эту тему, учиться говорить "Нет" приходится бизнес-аналитикам. А это ведь вдвойне сложно - говорить "Нет" Product owner клиента.

Поэтому я бы сразу предложил зафиксировать в паспорте проекта или в Definition of Ready следующую формулировку:

(Valuable) Ценная история - это такая история, которая напрямую ведет к достижению одной из задокументированных в паспорте проекта (или в Vision and Scope) бизнес-целей.

Иначе такую историю надо бы исключить. И бизнес-аналитику будет гораздо проще сказать "Нет", когда в проектной документации уже задокументирована и согласована такая формулировка.

Ну или можно еще добавить соответствующую бизнес-цель, что обычно является серьезным изменением и требует отчасти вернуться к самому началу и проработать эту бизнес-цель отдельно. Ведь никто не идеален, и я не раз видел проекты, в которых часть бизнес-целей было пропущено на начальных этапах.

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

Надеюсь что данная статья будет полезна как новичкам, так и опытным специалистам. От последних жду конструктивной критики и обсуждения).