Текст книги "Scrum без ошибок"

Лайфхак 10. Структурируем пользовательские истории

Scrum не предписывает использовать какой-то определенный формат пользовательских требований, которые затем становятся элементами бэклога. Однако можно с уверенностью утверждать, что де-факто стандартом пользовательских историй стал формат, изложенный в основополагающей книге Майка Кона «Пользовательские истории»[41]41
  Кон М. Пользовательские истории. Гибкая разработка программного обеспечения. М.: Вильямс, 2018.


[Закрыть].

Рискну предположить, что все, кто сейчас держит в руках эту книгу, читали «Пользовательские истории» и/или работали с теперь уже повсеместно распространенным форматом:

«Как <роль / персонаж пользователя> … я хочу <что-то получить> … для того, чтобы <с такой-то целью>…»

Я не собираюсь торить эту лыжню заново и обсуждать преимущества пользовательских историй или способы разбиения больших историй на меньшие: об этом прекрасно пишет Майк Кон. Вам стоит ознакомиться с его книгой, если вы этого пока не сделали.

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

ДЕКОМПОЗИРУЕМ ИСТОРИИ

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

Майк Кон под эпиком понимает «пользовательскую историю, на разработку и тестирование которой вы потратите более одного или двух спринтов».

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

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

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

НАРЕЗАЕМ ЗАДАЧИ

Формулирование удобоисполнимых, готовых ко взятию в спринт пользовательских историй – только часть проблемы. Следующий этап – рассмотрение этих высокоприоритетных историй на планировании спринта (см. лайфхак 8), где они станут элементами бэклога спринта.

Бэклог спринта, как правило, формируется не только из подобных пользовательских историй, но и из их «дочек» (появившихся в процессе планирования), которые обычно можно отнести к категории задач. Это конкретизированные и детально описанные части истории, над которыми команда работает в спринте и которые отслеживает с помощью стикеров на доске с задачами (см. лайфхак 21). Я склоняюсь к тому, что на эти задачи должно уходить от 2 до 8 часов. Чуть дольше – и они становятся трудноуправляемыми.

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

Распространенная декомпозиция задач, которую я наблюдал (и использовал в прошлом), выглядит примерно так:

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

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

Задача 1. Дизайн функциональных тестов.

Задача 2. Создание тестовых данных.

Задача 3. Разработка базы данных.

Задача 4. Разработка бизнес-логики.

Задача 5. Разработка пользовательского интерфейса.

Задача 6. Разработка функционального автотестирования.

Эта декомпозиция выглядит логичной и убедительной и даже может отлично сработать. Но знаете, что она мне напоминает? Да, вы догадались – мини-водопад! Хотя эта мини-версия не так опасна, как водопадный подход на продуктовом уровне, она может доставить немало проблем.

Возьмем для примера задачи 3, 4 и 5. Очевидно, что владельцу продукта будет сложно оценить правильность исполнения требований, пока все три задачи не будут завершены. Просьба к владельцу продукта проверить изменения в схеме базы данных и связанных с ними хранимых процедурах (задача 3) не гарантирует, что мы убедимся в том, что разработка идет в верном направлении, – до тех пор, пока не будет затронут функционал пользователя.

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

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

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

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

Задача 1. Разработать функционал ввода логина и пароля (включая тест-дизайн и автоматизацию тестирования).

Задача 2. Разработать механизм аутентификации по электронной почте (включая тест-дизайн и автоматизацию тестирования).

Задача 3. Разработать посадочную страницу (включая тест-дизайн и автоматизацию тестирования).

Что я здесь сделал? Разбил историю на несколько относительно самостоятельных функций для конечного пользователя. Каждая из них включала небольшую часть работ с базой данных, бизнес-логику и пользовательский интерфейс (см. рис. 4.1). Так что мини-водопад стал безопасной струйкой, а циклы обратной связи теперь можно было измерять в часах, а не в днях!

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

Уверен, один или двое из вас, дочитав до этого места, подумают: «Минуточку! Если вам удалось разбить историю на небольшие функциональные части, почему бы тогда не выделить эти части в отдельные истории, а не в задачи?» Хороший вопрос! И к счастью, у меня есть ответ на него.

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

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

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

Технические истории и баги

Мне нравится простое и понятное определение технической истории из книги Хенрика Книберга Lean from the Trenches[42]42
  Kniberg H. Lean from the Trenches: Managing Large-Scale Projects with Kanban. Pragmatic Bookshelf, 2011.


[Закрыть]:

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

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

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

2. Как мы можем использовать стандартный формат пользовательских историй для технических историй?

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

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

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

КТО ПОСТОЯНЕН, ТОТ ВСЕГДА ПОЧТЕН И СЛАВЕН

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

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

Лайфхак 11. Определяем критерии готовности

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

Я не мастер на все руки, тем не менее справился с одним из моих домашних scrum-заданий (починить стол) и очень гордился собой. Я перенес свой стикер в колонку «Сделано» прямо на глазах у Кармен – красота! Не моргнув глазом она поспешила вернуть мой стикер обратно в столбец «В работе», сопроводив комментарием: «Починить стол – хорошая работа. Но твоя задача не соответствует моим критериям готовности – твои инструменты все еще лежат на столе». В этот момент я не только очень гордился собой (потому что жена, похоже, слушала мою непрекращающуюся болтовню про Scrum), но и укрепился в важном выводе. Когда взаимодействуют двое или больше людей, самое важное – согласовать ожидания. Scrum учитывает критическую важность этой максимы и предлагает в помощь жизненно важный концепт – критерии готовности.

НЕЧЕТКИЕ КРИТЕРИИ

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

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

Рис. 4.2. Выравнивание ожиданий с четким определением критериев готовности минимизирует двусмысленность

С ЧЕГО НАЧАТЬ

Самое важное, что нужно осознать, формулируя первые критерии готовности, – они не высечены в камне. Вам не нужно целую вечность обдумывать, какими они должны быть: критерии готовности могут эволюционировать со временем. Как и в остальных случаях, мы должны анализировать и корректировать критерии готовности. Как пишет Клинтон Кит[43]43
  Keith C. Agile Game Development with Scrum. Boston: Addison-Wesley, 2010.


[Закрыть], «команды расширяют стандартные критерии готовности, улучшая свои практики. Это позволяет им постоянно повышать свою эффективность».

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

РАЗНЫЕ УРОВНИ

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

Рис. 4.3. Критерии готовности могут отличаться на разных уровнях

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

Уровень задач (в качестве примера задача на программирование)

Критерии готовности на уровне задач включают следующие элементы:

• код прошел юнит-тесты;

• код прошел ревью кого-то из коллег (если не использовалось постоянное парное программирование), чтобы обеспечить соответствие стандартам написания кода;

• код прошел контроль в системе управления версиями с четкими комментариями, которые можно отслеживать;

• проверенный на входе код не ломает сборку (см. лайфхак 18);

• доска задач обновлена, и время, оставшееся на выполнение задачи, равно 0 (см. лайфхак 21).

Уровень пользовательской истории

В этой истории можно выделить две части.

Первая часть – критерии готовности описания требований пользовательской истории. Соблюдение этих критериев позволяет включить истории в спринт.

Вторая и более очевидная часть – критерии готовности, определяющие, когда история готова для релиза.

Критерии готовности описания требований пользовательской истории (см. рис. 4.4):

• пользовательская история была оценена (см. лайфхак 14);

• критерии приемки четко определены;

• пользовательская история была однозначно приоритизирована в продуктовом бэклоге;

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

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

Рис. 4.4. Когда пользовательская история готова, она может быть рассмотрена на планировании

Критерии готовности истории для релиза:

• автоматическое функциональное тестирование подтверждает, что новый функционал работает так, как и ожидалось, от начала и до конца;

• регрессионное тестирование подтвердило успешную интеграцию с другими функциями;

• все соответствующие сценарии сборки / развертывания были модифицированы и протестированы;

• окончательный работающий функционал был проверен и принят владельцем продукта;

• вся соответствующая документация для пользователей написана и проверена;

• если это необходимо, все переводы и другие вещи, связанные с местонахождением, интегрированы и проверены;

• пользовательскую историю команда показала всем стейкхолдерам на обзоре спринта.

Уровень релиза

Критерии готовности на уровне релиза включают следующие элементы:

• весь код, относящийся к релизу, был успешно загружен на «боевые» сервера[44]44
  Боевой сервер – сервер, на котором приложение исполняется для конечных пользователей. Прим. ред.


[Закрыть];

• релиз прошел smoke-тесты[45]45
  Smoke-тесты – минимальный набор тестов на явные ошибки, чтобы убедиться, что критически важные функции работают согласно ожиданиям. Прим. ред.


[Закрыть] (как ручные, так и автоматические) на «боевых», а не только на тестовых данных;

• сервисная служба и служба маркетинга потренировались работать с новым функционалом;

• финальный релиз был проверен и принят владельцем продукта.

СИСТЕМНЫЕ ТРЕБОВАНИЯ

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

Вот несколько примеров этих требований.

Масштабируемость. Возможность масштабирования до 20 000 пользователей, использующих продукт одновременно.

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

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

Безопасность. Необходимо пройти специальные тесты на безопасность и внешнее проникновение.

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

Совместимость. Должна присутствовать возможность синхронизации данных со всеми продуктами в одной группе.

КРИТЕРИИ ПРИЕМКИ ИЛИ КРИТЕРИИ ГОТОВНОСТИ?

Как только ваша команда познакомится с критериями готовности и форматом пользовательских историй, время от времени вы будете задаваться интересным вопросом: «Должно ли требование XYZ быть частью критериев приемки либо критериев готовности?» Ответ зависит от того, является ли это требование требованием для всех пользовательских историй либо лишь для небольшой подгруппы. Рассмотрим обратную совместимость. Если каждый новый функционал в продукте должен быть полностью совместим с предыдущей версией, тогда подобное нефункциональное требование должно стать частью критериев готовности. С другой стороны, если вы пришли к тому, что обратная совместимость необходима только для части функционала, тогда это требование должно быть добавлено в критерии приемки исключительно у этого функционала.

ТАК ЖЕ ПРОСТО, КАК ГОТОВИТЬ!

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

Это как добавлять соль во время готовки – вы всегда можете досолить еду, но, если вы пересолили, исправить это будет очень сложно.