Для обозначения того, что команде предстоит сделать, в Scrum и других методологиях разработки используется несколько разных терминов. У каждого из них есть свой смысл. Разные названия призваны облегчить понимание, но если не уточнить терминологию, возникает путаница. А любое недопонимание мешает прозрачности в работе и может привести к ошибкам.
Давайте вместе разберёмся, в чем заключаются отличия в смысле терминов и как это влияет на оценивание и планирование работы.
Что говорит Scrum Guide
Руководство Scrum Guide только обозначает необходимые рамки, но команда может адаптировать фреймворк под себя и добавлять новые элементы. Это помогает в работе, но в то же время создаёт сложности в трактовках терминов. Разные команды, и даже разные сайты и блоги, могут использовать одни и те же слова для описания разных сущностей. В наших реалиях усложняет ситуацию ещё и перевод терминов на русский.
В Scrum нет «историй», «эпиков» и других делений. В Scrum обозначены элементы бэклога продукта — PBI (Product Backlog Item).
Бэклог Продукта содержит <...> новые характеристики или новые функции продукта, требования, информацию о путях усовершенствования продукта и устранения дефектов. Каждый элемент Бэклога Продукта должен содержать описание, номер позиции в Бэклоге, оценку объема работы и ценность.
Именно они часто классифицируются как:
- эпики (Epics),
- истории (Stories),
- технические задачи (Technical Tasks),
- баги (Bugs) и т. д.
Таким образом, всё это PBI.
Идею использовать User Story (пользовательские истории) предложил Алистер Кокберн, один из авторов Agile Manifesto. В 2001 году Рон Джеффрис предложил формулу «3C» для создания историй, которая теперь часто используется для их записи, хотя это не обязательно.
Как «кто-то», я хочу «выполнить что-то», чтобы «прийти к такой-то цели».
Подробнее про истории читайте в статье «Что такое пользовательская история и как она помогает в разработке программ?»
Историю можно выполнить за спринт, то есть она занимает несколько дней. А сама история делится на таски — это короткие задачи, на разработку которых уходит не больше одного рабочего дня. На выполнение тасков отводятся часы.
Историю оценивают в очках историй, SP (Story Points) . Для этого используют последовательность Фибоначчи и технику покерного планирования. Более детализированные таски оцениваются уже в идеальных часах, чтобы учесть Capacity команды, то есть возможную ёмкость в часах.
Больший элемент, чем пользовательская история, — это эпик. Он состоит из нескольких историй.
Дело в том, что история не всегда самостоятельно доносит ценность продукту, и поэтому обязательно должна дополняться другими историями. В таком случае, чтобы работать одновременно, пользовательские истории объединяются в один эпик.
В книге «Essential Scrum» эпик определяется как «история пользователя, которая слишком велика, чтобы соответствовать менее чем одному спринту».
Epics используют для отражения крупных задач и широких требований. При работе над эпиком, он разбивается на несколько историй, которые дальше делятся на таски. Но история не будет считаться полностью готовой, пока не будут готовы другие истории из этого же эпика.
Реализация некоторых эпиков может занимать несколько месяцев. Их обычно оценивают по методу «Размер футболок»: каждому эпику присваивают значение XS, S, M, L, XL, XXL. Это помогает оценить задачу более абстрактно, например, по сумме предполагаемых затрат на разработку.
Темы или фичи
Темы синонимичны фичам (feature). Это группа связанных пользовательских историй. Объединение по темам — это способ указать, что истории имеют что-то общее, например, помогают реализовать одну и ту же функцию.
В темы могут объединены не только истории, но и эпики.
Некоторые программы для ведения бэклога используют термин «Эпик» как синоним «Темы». Кроме того, в фреймворке SAFe и Feature, и Epic имеют другое значение. В нём они означают реализацию ценности, идею на разном уровне портфеля.
Разница касается и способов оценки. Мы упомянули популярные техники, которые проверены многими разработчиками, но каждая команда выбирает свой удобный способ.
В любом случае, scrum-мастер должен адаптировать термины под те условия, в которых работает команда. Жёсткого требования нет, но главное — сохранять единообразие и помнить по разные варианты, чтобы понимать людей за пределами своей команды.