История

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

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

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

Пользовательские истории (user story) описывают функциональность, используемую непосредственно конечным пользователем (клиентом, сотрудником или другой системой в инфраструктуре предприятия — прим.пер.). Вспомогательные истории (enabler story) позволяют увидеть работы, необходимые для обеспечения исследований, построения и развития архитектуры, создания и развития инфраструктуры и соответствия регуляторным и отраслевым требованиям.

Детали

SAFe описывает четырехуровневую иерархию артефактов, описывающих функциональное поведение системы: Эпики (Epic), Возможности (Capability), Функции (Feature) и Истории (Story) (Поскольку корректные переводы названий артефактов достаточно длинные и не прижились в профессиональном общении, в дальнейшем по тексту будем использовать английские варианты терминов). В совокупности эти артефакты используются для описания требуемого поведения решения (solution). Непосредственная работа по реализации решения определяется через истории (stories), которые составляют Бэклог команды (Team backlog). Некоторые истории возникают из бизнес фич (business features) и вспомогательных фич (enabler features) из Бэклога ARТа (ART Backlog), в то время как другие исходят из внутреннего контекста команды (Тут SAFe явно говорит, что в бэклоге команды могут присутствовать истории, не связанные с фичами из бэклога АРТа. Этот момент следует учитывать при планировании, поскольку такие локальные истории съедают емкость команды и могут привести к тому, что ожидания стейкхолдеров не сбудутся).

Каждая история — это небольшое, независимое (в том смысле, что его реализация не должна зависеть от реализации прочих вариантов поведения системы) поведение системы, которое может быть реализовано пошагово, и которое представляет некоторую ценность для пользователя или Решения (Обратите внимание. Явно указано, что реализация истории не должна обязательно приводить к доставке ценности для пользователя. Это может иметь ценность только внутри решения, не влияя никоим образом на поведение системы в целом). Это вертикальный срез функциональности, гарантирующий, что каждая итерация будет приносить новую ценность. Истории должны быть небольшими и должны завершаться за одну итерацию (см. Раздел о разделении историй).

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

Часто истории сначала записываются на каталожных карточках или на стикерах. Физическая природа карточки создает ощутимую связь между командой, историей и пользователем: она помогает вовлечь всю команду в написание истории. Наклейки имеют и другие преимущества: они помогают визуализировать работу, их можно легко разместить на стене или на столе, менять последовательность размещения и даже передать карточку другой команде при необходимости. Истории позволяют лучше понять объем работ и прогресс:

• «Вау, посмотрите на все эти истории, на которые мы собираемся подписаться» (объем работ)
• «Посмотрите на все истории, которые мы реализовали в этой итерации» (прогресс)

Хотя написать историю может любой, согласование их добавления в Бэклог команды и добавление их в базовый план системы является обязанностью Владельца продукта (Product Owner). Понятно, что бумажные стикеры плохо приспособлены для использования в масштабах крупного предприятия, поэтому истории часто быстро переносятся в инструменты Agile Lifecycle Management (ALM).

В SAFe, как описано ниже, есть два типа историй: пользовательские истории (user stories) и вспомогательные истории (enabler stories).

Источники появления историй

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

Пользовательские истории

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

Поскольку истории фокусируются на пользователе, как на выгодополучателе, а не на системе, пользовательские истории ориентированы на клиента и описывают ценность с точки зрения клиента. Поэтому рекомендуемой формой записи истории является «голос пользователя», а именно:

Как (пользователь в определенной роли), я хочу (выполнять определенные действия), чтобы (получить ценность)

Используя этот формат, команды ориентируются на понимание того, кто использует систему, что он с ней делает и почему он это делает. Регулярное применение формата «голоса пользователя» способствует повышению компетентности команды в предметной области, команда лучше понимает реальные бизнес-потребности своего пользователя (см. рис. 2).

Как описано в Дизайн Мышлении, персонажи описывают конкретные характеристики типичных представителей групп пользователей, которые помогают командам лучше понять своего конечного пользователя. Примерами персонажей для пассажира на рисунке 2 могут быть или искательница острых ощущений «Джейн», или робкий пассажир «Боб». Затем описания историй могут ссылаться на этих персонажей («Как Джейн, я хочу…»).

Хотя формат пользовательской истории типичен, не каждая система взаимодействует с конечным пользователем. Иногда «пользователь» — это устройство (например, принтер) или система (например, сервер транзакций). В этих случаях (Фактически мы говорим о том, что любой контракт взаимодействия между системами или системой и аппаратным обеспечением должен быть выражен в форме именно пользовательской истории) история может принять форму, показанную на рисунке 3.

Вспомогательные истории

Команды также разрабатывают новую архитектуру и инфраструктуру, необходимые для реализации новых пользовательских историй. В этом случае история не может напрямую касаться какого-либо конечного пользователя. Команды используют «вспомогательные истории» для обеспечения исследований, проработки архитектуры или формирования инфраструктуры. Как показано на рисунке 4, вспомогательные истории могут быть выражены техническим, а не ориентированным на пользователя языком (Стоит обратить внимание, что даже в этом виде описывается ожидаемый результат, а не просто работа, которую нужно сделать.).

Существует множество различных типов вспомогательных историй, в том числе:

• Рефакторинг и изучение путей реализации (Spikes, традиционно определяемые в XP)
• Создание или улучшение инфраструктуры разработки/развертывания
• Выполнение задач, требующих участия человека (например, индексирование миллиона веб-страниц).
• Создание необходимых конфигураций продукта или компонента для различных целей
• Проверка качества системы (например, тестирование производительности и поиск уязвимостей)

Вспомогательные истории демонстрируются (в рамках демонстрации системы (System Demo) — прим.пер.) так же, как и пользовательские истории, обычно путем демонстрации полученных знаний, найденных решений, созданных артефактов или пользовательского интерфейса, заглушек или макетов.

Написание хороших историй

Хорошие истории требуют нескольких точек зрения. В Agile команда целиком создает единое понимание того, что нужно создать, чтобы уменьшить количество переделок и увеличить производительность. Команды взаимодействуют используя Разработку, управляемую поведением (BDD), чтобы определить подробные приемочные тесты, которые окончательно определяют каждую историю.

Совместное написание истории гарантирует учет всех точек зрения, общее согласие относительно сценария истории и ожидаемых результатов, которые определены в описании истории, критериях приемки и приемочных тестах. Приемочные тесты написаны в терминах предметной области с использованием BDD. Затем тесты BDD автоматизируются и выполняются непрерывно для обеспечения Встроенного Качества (Built-In Quality). Тесты BDD написаны в связке с требованиями к системе (Здесь имеется в виду требования к системе уровня пользователя, если рассматривать стандартную иерархию требований) (историями) и, следовательно, могут использоваться в качестве окончательного описания поведения системы, заменяя стандартную документацию на систему (Подразумевается, что правильно написанные BDD тесты заменяют пользовательскую документацию, поскольку в них описано, что может делать в системе пользователь и какой результат он получит.).

Подход трех С: карточка, обсуждение, подтверждение

Рону Джеффрису, одному из создателей XP, приписывают создание подхода 3 °C:

• Карточка — фиксирует заявление о намерениях в рамках пользовательской истории с помощью каталожной карточки, стикера или специальной системы. Каталожные карточки обеспечивают физическую связь между командой и историей. Размер карточки физически ограничивает длину истории и преждевременные предположения о специфике поведения системы. Карточки также помогают команде «почувствовать» предстоящий объем работ, потому что одно дело — смотреть на десять строк в электронной таблице, и другое — держать десять карточек в руке.
• Обсуждение — представляет собой «обязательство диалога» об истории между командой, клиентом (или доверенным лицом клиента), PO (который может представлять клиента) и другими заинтересованными сторонами. Обсуждение необходимо для определения более подробного поведения, требуемого для реализации намерения. Обсуждение может породить дополнительную конкретику в виде критериев приемки (подтверждаемых ниже) или вложений в пользовательскую историю. Эти своевременные дискуссии создают общее понимание объемов работ, которое не может дать обычная документация. Спецификация на основе примеров заменяет подробную документацию. Обсуждения помогают выявить пробелы в пользовательских сценариях и нефункциональных требованиях. Обсуждение является частью всех этапы жизненного цикла истории:
  • Проработки бэклога (Backlog refinement)
  • Планирования (Planning)
  • Реализации (Implementation)
  • Демонстрации (Demo)
• Подтверждение. Критерии приемки предоставляют информацию, необходимую для понимания, что история реализована правильно и покрывает соответствующие функциональные и нефункциональные требования. На рисунке 5 приведен пример. Некоторые команды часто используют раздел подтверждения на карточке истории, чтобы записать то, что они будут демонстрировать.

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

Инвестиции в хорошие истории

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

Написание кода для осознанной цели не обязательно является самой сложной частью разработки программного обеспечения.

Наоборот, понимание реального назначения кода — это сложно. Поэтому вложение в хорошие пользовательские истории, пусть даже и в последний ответственный момент (здесь имеется в виду применяемая в agile-подходах стратегия принятия решения Last Responsible Moment (LRM). Он гласит, что критичные решения надо принимать в тот момент, когда стоимость непринятия решения станет выше, чем стоимость принятия. По-другому можно сказать, что тратить усилия по формированию историй можно до самого последнего момента, после которого уже нужно делать реализацию кровь из носу), — соответствующая трата ресурсов команды. Билл Уэйк придумал аббревиатуру INVEST (Leffingwell, 2011) для описания атрибутов хорошей пользовательской истории.

• I (Independent) — независимая (истории не зависят друг от друга и могут реализовываться в любом порядке)
• N (Negotiable) — обсуждаемая (история представляет гибкое заявление о намерениях, а не контракт)
• V (Valuable) — ценная для клиентов и бизнеса (предоставляет клиенту вертикальный срез функциональности, имеющий для него ценность)
• E (Estimable) — оцениваемая (история должна быть небольшой и возможной к обсуждению, чтобы ее можно было оценить с достаточной точностью)
• S (Small) — маленькой (история должна умещаться в одну итерацию)
• T (Testable) — тестируемая (история понятна в той мере, чтобы было ясно, как её проверить)

Правильное разделение историй

Более маленькие истории реализуются быстрее и с большим уровнем качества, поскольку небольшие элементы проходят сквозь любую систему быстрее, подвержены меньшим изменениям и меньшим рискам. Поэтому разбиение больших историй на более мелкие — обязательный навык для каждой Agile-команды. Это одновременно и искусство, и наука инкрементальной разработки. Agile Software Requirements описывает десять способов разделения историй. Ниже приводится краткое изложение этих методов:

• Шаги рабочего процесса
• Варианты бизнес-правил
• Основное усилие
• Простые/сложные
• Варианты данных
• Методы ввода данных
• Отложенные характеристики качества системы
• Операции (например, CRUD)
• Сценарии использования
• Выделение исследований

На рис. 6 показан пример разделения по сценариям использования.

Пояснения по правилам декомпозиции историй — от переводчика

Шаги рабочего процесса

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

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

История получается слишком большой для того, чтобы быть реализованной в один спринт. Поскольку источником появления истории являются регуляторные требования, которые гласят, что любое изменение инфраструктуры должно быть согласовано и задокументировано, то основная ценность истории — в существовании артефакта об изменении. Можно разделить историю на три:

Как релиз-менеджер, я хочу согласовать заявку на развертывание микросервиса, чтобы не нарушать регуляторных требований.

Как релиз-менеджер, я хочу, чтобы согласованная заявка на развёртывание микросервиса исполнялась автоматически после согласования, чтобы ускорить процесс развёртывания.

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

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

Варианты бизнес-правил

Бывают истории, которые содержат в себе сложные пути достижения результата. Например, мы хотим сформировать каталог товаров с возможностью фильтрации по нужным покупателю критериям.

Как покупатель, я хочу отфильтровать каталог товаров, чтобы получить подборку товаров только с интересующими меня характеристиками и параметрами.

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

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

В случае необходимости, мы можем разбить нашу пользовательскую историю на истории вида:

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

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

Основное усилие

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

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

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

Следовательно, мы можем выделить пользовательскую историю на несколько следующих:

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

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

Истории в данном случае не являются независимыми, но их связь понятна и прозрачна.

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

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

Простые/сложные

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

Как покупатель, я хочу отфильтровать каталог одежды, чтобы получить подборку одежды только нужного мне размера.

… нужного мне цвета.

… нужного мне типа.

Варианты данных

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

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

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

… я хочу найти заказ, сделанный покупателем, по дате заказа…

… я хочу найти заказ, сделанный покупателем, по фамилии заказчика…

Методы ввода данных

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

• даты вводятся как текст, без выпадающего календарика
• коды аэропортов или города вылета/назначения — без автозаполнения
• количество пассажиров — без выпадающего списка.

Как пользователь, я могу найти нужный мне рейс, используя простой ввод даты и городов отправления/назначения…

… я могу найти нужный мне рейс, используя календарь…

… я могу найти нужный мне рейс, используя автозаполнение для аэропортов отправления/назначения…

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

Отложенные характеристики качества системы

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

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

… я могу найти нужный мне рейс менее, чем за 60 секунд…

Операции

При описании сценариев использования аналитики используют слово «управлять». Данное слово подразумевает под собой набор операций по созданию, просмотру, изменению и удалению какого-либо элемента. Например, создаем функциональность по работе пользователя с заметками:

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

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

… я могу создать заметку…

… я могу просмотреть заметку…

… я могу изменить заметку…

… я могу удалить заметку…

Выделение исследований

Большая оценка истории может обосновываться не только сложностью реализации, но и высокими рисками вследствие непонимания способов ее реализации. Для этого мы делим историю на проведение исследовательской работы по способу реализации — это будет вспомогательная история (enabler story), и непосредственно реализацию — пользовательская история (user story). Еще раз просмотрите раздел про вспомогательные истории.

Следует помнить следующее! Не стоит делить историю по слоям архитектуры, по компонентам системы, по типам работ, которые нужно выполнить или по функциональным ролям. Это так называемое «горизонтальное» деление. Данный подход приводит к тому, что какой-то результат будет отложен во времени.

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

Оценка историй

Agile-команды используют для оценки своей работы сторипоинты и метод «покер планирования» (Leffingwell, 2011) (Cohn, 2004). Story Point — это особое число, которое представляет собой комбинацию следующих характеристик:

• Объем работ — сколько нам придется трудится, чтобы сделать это?
• Сложность — насколько это будет сложно сделать?
• Понимание — что известно о задаче, насколько мы ее понимаем?
• Неопределенность — что нам неизвестно?

Сторипоинты представляют собой относительную единицу, не привязанную к какой-либо конкретной единице измерения. Размер (объем усилий команды, затрачиваемый командой на реализацию истории) каждой истории оценивается относительно наименьшей истории, которой присваивается размер «единица». Для оценки применяется модифицированная последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100), отражающая присущую неопределенность в оценке, особенно в области больших чисел (например, 20, 40, 100).

Покер планирования

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

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

• Участвуют все члены команды
• Каждому участнику дается колода карт, содержащая модифицированную последовательность Фибоначчи.
• Владелец продукта (product owner) принимает участие, но не оценивает
• Скраммастер/Team Coach принимает участие, но не оценивает, если только он не совмещает роль с ролью разработчика
• Для каждого оцениваемого элемента бэклога PO читает описание истории
• Команда задает вопросы и получает ответы
• Каждый участник самостоятельно и в тайне от других выбирает карту со своей оценкой
• Все карты переворачиваются одновременно, чтобы избежать предвзятости и сделать все оценки видимыми
• Участник, давшие самую высокую и самую низкую оценки объясняют мотивы своего решения
• После обсуждения каждый участник дает повторную оценку
• Скорее всего оценки совпадут. В противном случае процесс повторяется.

Уместно провести несколько предварительных обсуждений архитектуры. Однако трата слишком большого количества времени на обсуждение архитектуры может оказаться напрасной тратой усилий. Настоящая ценность использования покера планирования заключается в том, чтобы добиться общего понимания объема истории. Это также весело!

Скорость команды (Velocity)

Скорость команды для итерации равна сумме сторипоинтов за все завершенные истории, соответствующие их критериям готовности (DoD). Чем дольше команда работает вместе, тем их средняя скорость (завершенные сторипоинты за итерацию) становится более надежной и предсказуемой. Более предсказуемая оценка скорости помогает в планировании и дает возможность ограничить незавершенную работу (WIP), поскольку команды не берут на себя больше историй, чем позволяет их историческая скорость. Эта метрика также позволяет оценить, сколько времени потребуется для доставки эпиков, фич, капабилити и вспомогательных элементов бэклога, которые также оценивать с использованием сторипоинтов.

Емкость команды (Capacity)

Емкость — это часть скорости команды (velocity), которая доступна для конкретной итерации. Отпуска, обучение и другие мероприятия могут сделать членов команды какое-то время недоступными для участия в достижении целей итерации. Это уменьшает максимальную возможную скорость этой команды для конкретной итерации. Например, команда со средней скоростью 40 сторипоинтов, уменьшит свою максимальную скорость до 36, если один участник команды уйдет в отпуск на неделю. Зная это заранее, команда при планировании итерации берет историй на 36 сторипоинтов. Это также помогает прогнозировать фактическую емкость команды для каждой итерации в PI во время PI-планирования, чтобы команда не переусердствовала при определении своих целей PI.

Исходный базовый уровень для оценки

В обычном Scrum оценка в сторипоинтах и скорость каждой команды — это проблема самой команды. При масштабировании производства становится проблематично предсказать размер в сторипоинтах более крупных эпиков и фич, если скорость команды сильно различается. Чтобы решить эту проблему, команды SAFe изначально калибруют исходный базовый уровень сторипоинта, где один сторипоинт определяется примерно одинаково для всех команд. Нет необходимости повторно калибровать оценку команды или ее скорость. Калибровка выполняется один раз при запуске новых Agile Release Trains.

Нормализация сторипоинтов, обеспечивающая достижение согласованного исходного уровня для историй и скорости, осуществляется следующим образом:

• Дайте каждому разработчику/тестировщику в команде восемь сторипоинтов на двухнедельную итерацию (по одному сторипоинту за каждый идеальный рабочий день, вычтя два дня на общие накладные расходы).
• Вычтите по одному сторипоинту за каждый день отпуска и выходной для каждого члена команды.
• Найдите небольшую историю, для которой на написание кода вы потратите полдня, и на тестирование и проверку — потратите полдня. Оцените эту историю в один сторипоинт.
• Оцените остальные истории относительно этой «единичной».

Пример: предположим, что команда состоит из шести человек, из которых трое — разработчики, двое — тестировщики и один PO, нет отпусков или праздников. Тогда предполагаемая начальная скорость = 5 × 8 сторипоинтов = 40 сторипоинтов за итерацию. (Примечание: может потребоваться небольшое снижение скорости, если один из разработчиков или тестировщиков исполняет роль Team Coach.)

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

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

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

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

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

Список литературы

• Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
• Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley,.
• Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.