Атрибуты Scrum

8.1. Story mapping

Story mapping (англ. "карта историй") - техника визуального и физического представления последовательности действий, которые должны быть реализованы в разрабатываемом командой программном продукте.

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

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

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

• "Неделимость" требований. Миф о том, что только часть высокоуровневых требований можно поделить на несколько соподчиненных задач, родился во многом благодаря низкому доверию к специалистам в области разработки программного обеспечения. Особенно это касается процессов внедрения программных продуктов и "внешних" аутсорсинговых и консалтинговых компаний, которым выгодно "вбивать" этот миф в головы заказчиков и тем самым эксплуатировать это понимание для получения дополнительных контрактов на продолжение сотрудничества. На то, чтобы преодолеть подобный миф, направлена технология инкрементальной разработки. В ее ходе владелец процесса и Scrum-команда добиваются корректного разбиения высокоуровневой идеи на поэтапность выполняемых задач, каждая из которых приносит определенную ценность бизнес-заказчикам.
• Нежелание понимать значимые детали процесса разработки программного обеспечения. Заказчик, особенно если это топ-менеджер компании, как правило, не склонен погружаться в детали автоматизируемого процесса. Это понятно. У топ-менеджеров другие цели и задачи. Поэтому желательно, чтобы владельцем продукта был пользователь, который не только понимает автоматизируемый бизнес, но имеет навыки работы с информационными системами и понимание общих принципов их устройства и функционирования.
• Недоверие к области коммерческой разработки информационных систем. Область коммерческой разработки программного обеспечения - не новая область, и уже многие организации с ней сталкивались не единожды. Учитывая состояние в этой области, описанное в "Введение в Agile" , у многих пользователей накоплен определенный, как правило негативный, опыт взаимодействия с компаниями разработчиками программного обеспечения. Поэтому заказчики вынуждены говорить "сделайте всё и сразу" просто потому, что это единственный способ получить требуемые доработки в сложившихся условиях. Потому что если не попросят максимум и сейчас, то вряд ли получат это потом.

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

Рис. 8.1. Представление карты историй

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

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

Процесс построения карты историй:

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

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

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

8.2. Пользовательские истории (User story)

В практике подготовки требований, которые в дальнейшем будут составлять каркас разрабатываемого программного продукта, в Scrum принято использовать один из стандартизированных подходов для их описания - Use Cases ("пользовательские истории").

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

Пользовательские истории формулируются как одно или более предложений на "повседневном" языке пользователя. Они получаются относительно небольшие по объему, что удобно как для составления, так и для их обсуждения, приоритизации, планирования, оценки и дальнейшей работы с ними. Пользовательские истории получаются в виде алгоритма действий пользователя с реализуемым программным продуктом. Таким образом, каждый квадратик в Story Mapping можно представить в виде Use Case. Если владелец продукта отнесется к приоритизации пользовательских требований со всей необходимой серьезностью и значимостью, то Scrum-команда может сконцентрироваться на наиболее значимых и важных Use Case, что будет влиять на инкрементальность создаваемой информационной системы. Адекватная оценка трудоемкости историй позволяет планировать сроки ее реализации, тем самым управляя содержимым спринтов. Разработать оптимальную пользовательскую историю не так просто, нужен определенный навык, который позволит создать качественное описание требований пользователей к реализуемому программному продукту, но в награду за это получаются следующие преимущества:

• Краткость. Пользовательская история описывает небольшую часть бизнес-ценности, которую возможно реализовать за период спринта.
• "Незатратность" создания и сопровождения. За счет своей "компактности" пользовательские требования достаточно просто создать и сопровождать их изменения на всем протяжении жизненного цикла продукта.
• Вовлечение ключевых пользователей в процесс создания продукта. За счет своей доступности бизнес-требования смогут стать реальным "мостиком" между пользователями и Scrum-командой. Это позволит более адекватно управлять ожиданиями пользователей и вовлечь их на нужную степень погружения в процесс разработки продукта.
• Облегчают оценку заданий. Формат пользовательских историй способствует более точной оценке необходимых системных разработок/доработок.

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

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

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

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

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