Story mapping (англ. "карта историй") - техника визуального и физического представления последовательности действий, которые должны быть реализованы в разрабатываемом командой программном продукте.
Карта историй - это источник информации, используемый для визуализации требований к продукту в контексте использования его функциональности и их приоритетов. Story mapping помогает выполнить декомпозицию задачи с ее высокоуровневого представления до уровня конкретных задач, а выполненная декомпозиция обеспечивает эволюционное понимание цельного продукта, начиная с полного охвата всех потребностей и завершая погружением до детальных требований пользователей. Но обычно с погружением в детальные требования пользователей возникают самые большие проблемы.
Как правило, чем крупнее компания, тем более разветвленным и кросс-функциональным является автоматизируемый процесс. Соответственно и требование будет более высокоуровневым и комплексным. Для небольшой компании реализация небольшого требования занимает не более недели, а вот в крупных организациях разработка подобного требования займет не менее нескольких месяцев.
Причин, как у каждой проблемной ситуации в области разработки программного обеспечения, много. Из них следует выделить:
Выходов из подобной ситуации несколько. Основное решение, которое предлагает Scrum, - разрабатывать результат максимально быстро. Для этого и организована "спринтовая" модель поставки функциональности маленькими порциями, в соответствии с наиболее актуальными требованиями. А это возможно только в том случае, когда спроектирован общий каркас функциональности через декомпозицию требований.
(рис 8.1) Представление карты историй
Карта историй представляется в виде двух последовательностей зависящих друг от друга активностей. Таким образом, мы получаем матричный вид карты историй.
Она представляет собой последовательные стадии, выполняющиеся в автоматизируемом процессе/продукте. На самом верхнем уровне располагается наиболее верхнеуровневое представление стадий или компонентов разрабатываемого продукта. Далее, по мере снижения, каждый компонент раскладывается на составляющие, и так до самого низкоуровневого представления автоматизируемого продукта.
Процесс построения карты историй:
Карта историй содержит каркас из задач, представляющих собой "кирпичики", составляющие конечный продукт. Этот каркас покрывает крупный набор функций, реализуемых в соответствии с приоритетами пользователей.
Под каркасом находятся подробные требования, которые описывают конкретные функциональные части для выполнения задач. В Scrum, когда речь заходит о работе с требованиями, применяют определенную технику работы с ними, которая называется User Story (пользовательские истории).
В практике подготовки требований, которые в дальнейшем будут составлять каркас разрабатываемого программного продукта, в Scrum принято использовать один из стандартизированных подходов для их описания - Use Cases ("пользовательские истории").
В разработке программного обеспечения этот способ разработки и управления требованиями часто применяют для проектирования и описания взаимодействия пользователя и системы, поэтому название Use Case часто воспринимают как синоним требования человека-пользователя к решению определенной задачи в системе.
Пользовательские истории формулируются как одно или более предложений на "повседневном" языке пользователя. Они получаются относительно небольшие по объему, что удобно как для составления, так и для их обсуждения, приоритизации, планирования, оценки и дальнейшей работы с ними. Пользовательские истории получаются в виде алгоритма действий пользователя с реализуемым программным продуктом. Таким образом, каждый квадратик в Story Mapping можно представить в виде Use Case. Если владелец продукта отнесется к приоритизации пользовательских требований со всей необходимой серьезностью и значимостью, то Scrum-команда может сконцентрироваться на наиболее значимых и важных Use Case, что будет влиять на инкрементальность создаваемой информационной системы. Адекватная оценка трудоемкости историй позволяет планировать сроки ее реализации, тем самым управляя содержимым спринтов. Разработать оптимальную пользовательскую историю не так просто, нужен определенный навык, который позволит создать качественное описание требований пользователей к реализуемому программному продукту, но в награду за это получаются следующие преимущества:
Чем более компактный объем имеет пользовательская история, тем проще выполнять ее оценку. Это приводит к более верным оценкам сроков реализации программного продукта и к более понятному планированию выполняемых работ. При этом важно знать меру в уменьшении и дроблении Use cases. Если сделать их слишком много, то у вас получится огромный список задач в бэклоге продукта, и процесс управления ими и фиксации на карте историй усложнится.
Для пользователей требования, выраженные в виде пользовательских историй, являются основным инструментом влияния на разрабатываемый программный продукт. Пользовательские истории определяют формат, в котором у пользователей есть возможность отразить все те важные факторы, которые, по их мнению, должны быть учтены в процессе автоматизации.
Важно отдавать себе отчет в том, что пользовательские истории не обеспечивают полноту всех функциональных требований и имеют ряд недостатков:
Инженерия требований - важный этап в создании каждого программного продукта. Scrum - гибкая методология, в которой работе с требованиями отводится не центральное, но при этом значимое место. Функциональные обязанности по извлечению, разработке и управлению требованиями ложатся на всех членов команды, именно поэтому в процессе работы с ними задействованы такие артефакты, как карта историй и пользовательские истории, назначение которых - облегчить получение информации, необходимой для качественной реализации программного продукта.
После того как процесс работы с требованиями в Agile-методологиях стал более очевиден, упрощен и понятен в сравнении со стандартными, классическими подходами к созданию информационных систем, целесообразно обсудить техники, которые помогут облегчить процесс определения приоритетов отдельных задач для их последующего включения в спринты Scrum-команды.
На сегодня существует множество различных техник расстановки приоритетов. Лишь небольшая их часть может быть применена для приоритизации пользовательских историй как единицы инкремента для разрабатываемого продукта в Scrum.
Рассмотрим наиболее эффективные из них:
). При использовании этой матрицы по ее "частям" распределяются задачи в соответствии с их важностью и срочностью.
(рис 8.2) Матрица Эйзенхауэра
Принцип Эйзенхауэра - очень эффективная техника расстановки приоритетов. Но ее особенности больше направлены на расстановку приоритетов отдельного сотрудника, а не команды в целом.
Методика "АБВ". В соответствии с этой методикой задачи делятся на три категории: жизненно важное, важное, приятное. Эта методика является логическим (более "глубинным") продолжением принципа Эйзенхауэра.
Применение принципа Парето конкретизируется, если все задачи проанализировать в соответствии с их долей в итоговом результате и затем распределить по категориям важности. АБВ основывается на следующих трех закономерностях, подтвержденных опытом:
Неважные и несущественные задачи (категория "В") составляют 60% от общего числа задач. Они имеют незначительную долю - 15% в общей ценности всех задач.
Методику "АБВ" можно применять для оценки приоритетов задач, необходимых для разработки продукта, но для того, чтобы грамотно ее использовать, владелец продукта и команда должны иметь определенный опыт и навыки по расстановке приоритетов.
Метод MoSCoW (Oracle). Один из консультантов Oracle (Dai Clegg) предложил однозначный, логичный и понятный метод приоритизации требований для анализа и задач разработки программного обеспечения - MoSCoW. Этот метод используется при фиксированных сроках на реализацию функциональности, когда всё внимание должно быть обращено на самые приоритетные требования. Приоритизация задач методом MoSCoW позволяет сосредоточить фокус внимания как владельца продукта, так и Scrum-команды на задачах конкретного спринта.
Все имеющиеся задачи в бэклоге продукта следует сгруппировать в четыре приоритетные корзины по следующим правилам:
Рассмотренные нами техники позволяют выполнять адекватную оценку задач, включение которых необходимо для разработки качественного программного продукта.
После того как мы определились с "спринтовой" моделью организации работ в Scrum и разобрались с тем, как необходимо работать с требованиями и задачами, настало время рассмотреть еще один очень важный артефакт каждой Scrum-команды, цель которого - визуализировать состояния задач в Scrum. Речь идет о Scrum-доске.
Каждый рабочий день все члены команды собираются на 15-минутное daily, на котором они обмениваются информацией по состоянию текущих дел ("Что сделано с момента предыдущей встречи?", "Чем планирую заниматься сегодня?", "Какие есть препятствия?").
На доске команды развешены задачи, каждой из которых выделен бумажный стикер, на котором написано, в чем состоит суть задачи (рис 8.3).
(рис 8.3) Доска задач
Доска задач должна минимум делиться на три колонки:
На момент планирования задач, которые предстоит взять в спринт, все карточки помещаются в колонку "Запланировано". Каждый день, когда член команды берет в работу определенную задачу, он говорит: "Я начал работать над…" и перемещает карточку в столбец "In Progress". После того как задача выполнена, исполнитель говорит о том, что работа над задачей закончена, и карточка перемещается в соответствующую колонку "Завершено".
Использование доски задач полностью соответствует принципам прозрачности работ, которые являются одним из главных преимуществ Agile в сравнении с альтернативными подходами к разработке программного обеспечения. Участники daily каждый день собственными глазами видят, как идет прогресс в работе над тем или иным типом задачи. Они не только погружаются в значимые детали работ, но и получают ценный опыт. Неоспоримыми выгодами, которые получает команда от использования доски задач, являются:
Стоит сказать о том, что в начале своей деятельности каждая команда должна попробовать именно "материальную" доску, по которой каждый сможет перемещать свои задачи.
Во-первых, это приучает всех членов команды к определенной дисциплине. Каждый должен отчитаться за свои задачи и как именно над ними ведется работа.
Во-вторых, доска, которая постоянно висит на стене в одном месте, приучает всех относящихся к команде, что именно на ней можно увидеть актуальное состояние дел и задач.
В теории Agile-процессов работа с требованиями и их трансформация в пользовательские истории, карту процессов и набор отдельных задач - это автономный процесс, за который ответственен владелец продукта и выделенные бизнес пользователи.
На практике же этот процесс требует творчества, навыков и немало ресурсов. Задать высокий темп выполнения Scrum-процесса за счет прозрачности поставляемых для команды требований - кропотливый труд, известный как инженерия требований. Не обязательно, чтобы этой сферой заведовал определенный специалист, более того, в Scrum-команде этот функционал должен быть рассредоточен между всеми членами коллектива.
Инженерия требований представляет собой набор техник, методов и принципов, связанных друг с другом.
В последнее время стала распространенной точка зрения, что требования не играют значимой роли в гибких процессах разработки. На это можно возразить, что знание требований необходимо, чтобы привнести их суть в создаваемый продукт.
Ключевые моменты инженерии требований можно найти, сравнивая сходства в работе по управлению требованиями в традиционной и Agile-среде. Это ведет к осознанию, какие техники могут подойти конкретному типу процесса.
Основное заблуждение относительно управления требованиями заключается в том, что оно касается только надлежащего документирования. Конечная цель процесса сбора требований в том, чтобы облегчить и донести до всех заинтересованных общее понимание требований к создаваемому продукту. На практике подтверждено, что важно как минимум проговорить требования, чтобы убедиться, что все понимают их одинаково. Способы инженерии требований могут различаться при традиционном и гибком подходе, но конечная цель остается той же, и важно держать ее в уме, чтобы не запутаться, применяя конкретные технологии.
Техники сбора требований схожи при традиционной и гибкой работе, как можно увидеть на следующих примерах:
Если все требования будут указаны разом во всех необходимых для процесса разработки деталях, то это точно не Agile. Спринт содержит ограниченный набор требований, с которыми работает Scrum-команда. Каждый спринт синхронизирует понимание владельца процесса и команды о конечном результате, к которому должна стремиться команда. В Scrum спринт содержит только те задачи, реализация которых необходима в краткосрочной перспективе. Их детально рассматривают и реализуют командными усилиями. Это приводит к тому, что владельцу продукта быстро показывают результат и могут получить от него эффективную обратную связь, которая позволяет больше узнать о требованиях к продукту и оптимальным образом скорректировать рабочий процесс.
Техники гибких процессов разработки в отношении требований основаны на идее совместных усилий относительно набора необходимых требований, в отличие от классического подхода, при котором специальные сотрудники сразу разрабатывают исчерпывающее описание. Команды гибкой разработки предпочитают собирать требования способом, который поддерживает взаимодействие и подвижность.
Пользовательские истории, создаваемые на основе требований, разрабатываются таким образом, что главным в них выступает пользователь. При традиционном подходе главным субъектом является система. Кроме того, традиционный подход часто делит функциональные и нефункциональные требования, обычно разделяя их на разные главы спецификации. Это деление предназначено обеспечить полноту сбора требований. В гибком подходе и функциональные, и нефункциональные аспекты собираются вместе.
Это ведет к лучшему пониманию всеми вовлеченными сторонами, выявлению новых деталей.
После того как необходимые требования к продукту собраны, их необходимо зафиксировать и "взять на учет" для дальнейшей реализации. Для этого в Scrum есть артефакт, который называется бэклог продукта (Product Backlog, PB).
Бэклог продукта - это упорядоченный список задач, которые должны быть реализованы в конечном продукте.
PB никогда не является полным. В начале (сверху) - только первоначально известные и наиболее понятные требования. Бэклог постоянно обновляется по мере обновления самого продукта и окружающей его среды, поэтому PB "живет" вместе с продуктом. PB является динамическим, постоянно изменяющимся для соответствия требованиям продукта, его конкурентоспособности и пригодности. PB существует ровно до тех пор, пока существует и сам продукт:
Если бэклог продукта содержит полный список существующих задач, связанных с разработкой программного продукта, то в Scrum есть еще один артефакт, который содержит список задач, которые необходимо выполнить в спринте.
Бэклог спринта (Sprint Backlog SB) - это набор элементов Product Backlog, выбранных для выполнения в текущем спринте.
Бэклог спринта:
Бэклог спринта должен быть достаточно "глубоко" детализирован по сравнению с задачами в Product Backlog, чтобы прогресс работы над ним можно было видеть ежедневно, не уделяя дополнительное время сбору необходимых деталей.
Scrum-команда работает над бэклогом спринта на всем его протяжении, и он постоянно изменяется вместе с прогрессом команды.
Изменения происходят потому, что в процессе работы возникают всё новые и новые задачи, которые нужно выполнить для достижения конечного результата.
Если возникает необходимость в дополнительном объеме работы, то эти задачи добавляются в бэклог продукта и планируются к выполнению в следующих спринтах.
После того как они выполнены, оценки оставшегося объема работ обновляются.
Если некоторые задачи считаются уже неактуальными, то их удаляют.
Только Scrum-команда может изменять свой бэклог во время спринта. По решению команды и ее участников задачи могут добавляться или удаляться, но необходимо четко обосновать, почему это необходимо.
Цель команды Scrum в отдельно взятом спринте - предоставлять работающий инкремент продукта.
В составе бэклога спринта могут находиться совершенно разные задачи, но главное для команды - создание инкремента программного продукта. Отдельный инкремент может включать в себя недостаточно функциональности для принятия владельцем продукта решения о его вводе в эксплуатацию, но команда должна убедиться, что поставляемое ими качество достаточно для поставки и запуска его в продуктивную эксплуатацию.
Инкремент по своей сути - это продукт, который будет приносить бизнес-пользу (рис 8.4) в момент своей разработки после того, как результаты определенного спринта реализованы Scrum-командой и приняты заказчиком.
 |
 (рис 8.4) |
| Рис. 8.4. Наглядное изображение инкремента в строительстве | |
приведены две иллюстрации.
Первая (левая) иллюстрирует неинкрементальный процесс организации постройки дома. До тех пор, пока дом в целом не будет готов, в нем нельзя будет жить.
На второй (правая) продемонстрирован инкрементальный процесс строительства. После того как первый этаж будет готов, в доме можно начинать жить и при этом продолжать строительство второго этажа.
Цель спринта - сформировать, спланировать и разработать самодостаточный, готовый для применения продукт или его часть, которая будет дополнять уже имеющиеся разработки и повышать суммарную стоимость разрабатываемого программного продукта.
По окончании спринта инкремент должен быть пригодным к использованию и приносить реальную и ощутимую прибыль PO.
Архитектура системы или дорожная карта продукта могут быть построены таким образом, что поставить инкремент продукта в сроки спринта - это очень сложная задача, а порой - невыполнимая. Таким образом, мы должны вернуться к самой идее наполнения бэклога продукта однозначными и понятными задачами и пересмотреть имеющиеся требования в сторону итерационной и инкрементальной работы.
Инкрементальная модель разработки программного обеспечения является наиболее успешной и перспективной моделью создания и внедрения программных продуктов.
Scrum основывается на "итерационно-инкрементальной" разработке программных продуктов, которые будут с момента своего "зачатия" приносить компании прибыль. Шаг за шагом.
А для этого каждый отдельный реализуемый инкремент должен иметь определенную ценность сам по себе, при этом добавляя ценности к ранее реализованным инкрементам. В связи с этим работа с требованиями и как следствие с архитектурой создаваемого программного продукта трансформируется в процесс постоянного прототипирования решения по актуальным требованиям. В связи с этим повышается важность отдельных активностей самих по себе и их дальнейшей интеграции друг с другом.
С учетом обозначенных факторов повышается значимость проведения постоянного рефакторинга программного продукта по причине его постоянной изменчивости. При этом цель и направление работ должны быть четко определены, и задача Scrum-команды и владельца продукта - постоянно отслеживать тренд развития продукта.
Подобный принцип организации и управления работ получил ранее распространение в области разработки программного обеспечения и называется принципом прототипирования. Этот принцип наилучшим образом подходит к проектированию информационных систем, разрабатываемых в соответствии со Scrum.
В этой главе внимание было уделено тем атрибутам, которые выделяют Scrum в наиболее формализованный вид гибких методологий. Именно они позволяют говорить о том, что Scrum является самой понятной и эффективной методологией разработки программного обеспечения, внедрение которой является относительно несложным процессом.
Использование в операционной работе доски задач, бэклога продукта и спринта позволяет сделать прозрачным процесс работы над пользовательскими историями и картой задач, в конечном виде выражающей результат в виде готового к использованию инкремента продукта.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.