Пользовательские истории часто поначалу преднамеренно расплывчаты, если работа над историей не начнется в течение нескольких будущих спринтов. Agile-команды поняли, что добавлять детали в историю заблаговременно нецелесообразно. Но в жизни любой пользовательской истории наступает время, когда нужно добавлять детали. И есть два способа, которыми команда может добавить детали в пользовательскую историю: разделить ее или добавить критерии приемки (Acceptance criteria). Рассмотрим подробнее оба метода.
Подход 1: Разделите историю
Первый подход к добавлению деталей состоит в том, чтобы разделить историю на несколько подисторий. Когда вы создаете несколько небольших историй, у вас будет больше деталей просто как побочный эффект от того, что вы написали больше. В качестве примера предположим, что вы хотите разрешить людям входить в новый продукт, используя свои учетные записи в социальных сетях. Вы можете начать с написания истории, в которой не будет ничего, кроме этого:
Как пользователь, я могу войти в систему через свою учетную запись в социальной сети.
Если команда не будет реализовывать эту историю в течение ближайших спринтов, этой истории, скорее всего, вполне достаточно. Однако по мере приближения момента, когда команда начнет работать над этой историей, необходимы дополнительные детали. Как минимум, команда захочет знать, какие учетные записи социальных сетей можно использовать для входа в новый продукт. Это может привести к замене исходной истории дополнительными историями, такими как:
Как пользователь, я могу войти в систему через свою учетную запись Facebook.
Как пользователь, я могу войти в систему через свою учетную запись LinkedIn.
Как пользователь, я могу войти в систему через свою учетную запись Twitter.
Написав эти подистории, владелец продукта предоставил команде дополнительную информацию о том, какие учетные записи в социальных сетях необходимо поддерживать.
Подход 2: добавьте критерии приемки
Второй способ добавления деталей в историю — добавить примечания о том, что должна делать история, чтобы владелец продукта (Product owner) принял ее как готовую к разработке. Мы назвваем это Критерии приемки (Acceptance criteria).
При работе с физическими карточками (когда истории пишутся на бумажных карточках-стикерах) критерии приемки чаще всего добавляются на оборотную сторону карточки. В любом приличном программном инструменте для управления бэклогом продукта (Jira или любой другой инструмент) будет место для добавления критериев приемки, даже если это просто примечания, прикрепленные к истории.
В случае входа через социальные сети у нас будет следующая история и критерии приемки:
Как пользователь, я могу войти через учетную запись в социальной сети.
Критерии приемки:
Можно войти через Facebook
Можно войти через LinkedIn
Можно войти через Twitter
Из этих двух примеров вы можете увидеть, как создание дополнительных историй или добавление критериев приемки приводит к предоставлению более подробной информации.
Таким образом, любой подход может работать для добавления деталей по мере того, как история продвигается к вершине бэклога продукта. Но эти два подхода предлагают уникальные преимущества, поэтому давайте посмотрим, как вы можете решить, какой подход лучше всего подходит в различных обстоятельствах.
Выбор между подходами
Итак, как вы выбираете между добавлением деталей, разбивая первоначальную историю на подистории, а не добавляя критерии приемки?
Когда вы должны разделить историю
Есть две причины для создания подисторий.
Во-первых, исходная история слишком велика, чтобы ее можно было легко вписать в итерацию, особенно после добавления ее критериев приемки.
Когда история большая, ее нужно разделить, чтобы команда могла завершить ее часть за один спринт. Если историю все равно нужно разделить, не утруждайте себя добавлением к ней критериев приемки, просто разделите.
Наиболее вероятно, что команда разделила бы историю в нашем примере входа в систему через аккаунт в социальных сетях. Если поддержка входа через Facebook, LinkedIn и Twitter делает историю слишком большой, чтобы ее можно было легко уместить в один спринт, команде лучше разделить ее по этим границам.
Во-вторых, разность приоритетов - это вторая причина писать подистории.
Предположим, что в случае входа через социальные сети владелец продукта сказал, что вход через LinkedIn имеет гораздо более высокий приоритет, чем вход через Facebook или Twitter. В этом случае, мы бы не хотели, чтобы одна история перечисляла все три социальные сети в качестве критериев приемки. Вместо этого у нас была бы одна история о входе в систему через LinkedIn и одна или две истории о Facebook и Twitter, в зависимости от того, была ли поддержка каждой из них равнозначной.
Когда вы должны добавить критерии приемки
Лучше добавить критерии приемки, когда выполняются следующие условия:
Добавление критериев приемки к истории не делает ее слишком большой для команды (т.е. команда успеет сделать ее за 1 спринт), И
Критерии приемки имеют примерно одинаковый приоритет.
В качестве примера рассмотрим эту историю о надежности пароля:
Как пользователь, я должен ввести надежный пароль при создании своей учетной записи.
Требования для этой истории: чтобы пароль состоял из 8 или более символов, содержал как минимум одну цифру, одну заглавную букву, одну строчную букву и один символ. Разбивка каждой из этих потребностей на отдельные истории привела бы к слишком маленьким историям, таким как:
Как пользователь, я должен ввести пароль длиной не менее 8 символов.
Как пользователь, я должен ввести пароль, состоящий как минимум из 1 цифры.
Как пользователь, я должен ввести пароль, содержащий как минимум 1 заглавную букву.
Как пользователь, я должен ввести пароль, содержащий как минимум 1 строчную букву.
Как пользователь, я должен ввести пароль, состоящий как минимум из 1 специального символа.
Выполнение всех этих проверок не займет у команды много времени на кодирование и тестирование. И мы можем предположить, что каждая проверка имеет примерно одинаковый приоритет. То есть мы не хотим пропускать требование по заглавной букве и возвращаться к нему через месяц, потому что это будет долго реализовываться. Да, и по отдельности, истории звучат довольно абсурдно, не так ли?
Вместо этого требование надежного пароля было бы лучше оформить в виде отдельной истории с добавлением критериев приемки для конкретных проверок:
Как пользователь, я должен ввести надежный пароль при создании своей учетной записи.
Критерии приемки:
Пароль должен содержать:
Не менее 8 символов
Хотя-бы 1 цифру
Хотя-бы 1 заглавную букву
Хотя-бы 1 строчную букву
Не менее 1 специального символа
Вы будете использовать обе эти техники
Хорошая agile-команда будет использовать оба метода для добавления деталей в свои пользовательские истории. Они будут разделять историю, когда оригинальная история слишком большая или когда ее подистории будут иметь разные приоритеты. Они возьмут небольшие истории и добавят детали в виде критериев приемки. Ни один из подходов не является более ценным, чем другой, и необходимо иметь каждый из них в своем наборе инструментов.
