Записаться

8.1. Story mapping

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

Story mapping - инструмент, помогающий в осмыслении функциональности ПО и "правильном" проектировании способов его использования.

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

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

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

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

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

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

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

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

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

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

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

Story mapping - это архитектурное представление задач пользователя.

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

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

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

User Story ("пользовательская история") - это сценарная пошаговая техника описания взаимодействия двух или более участников, задействованных в автоматизации. С помощью User Story может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни. В общем случае с помощью User Story может описываться взаимодействие двух или большего количества участников, имеющее конкретную цель.

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

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

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

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

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

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

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

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

8.3. Определение приоритетов пользователей

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

На сегодня существует множество различных техник расстановки приоритетов. Лишь небольшая их часть может быть применена для приоритизации пользовательских историй как единицы инкремента для разрабатываемого продукта в Scrum.

Рассмотрим наиболее эффективные из них:

• Принцип Эйзенхауэра. Принцип, или, как еще называют в литературе, "матрица Эйзенхауэра" - техника тайм-менеджмента для определения приоритетов задач. Выглядит матрица как четыре квадрата, которые получаются при пересечении осей "Важно - не важно" по горизонтали и "Срочно - не срочно" по вертикали (рис. 8.2). При использовании этой матрицы по ее "частям" распределяются задачи в соответствии с их важностью и срочностью.

  1. Важные и срочные задачи. Это те задачи, которые важны, и выполнить их необходимо срочно. Без них все порушится, ничего работать не будет, и сделать их завтра - будет уже поздно.
  2. Важные, но не срочные задачи. Это те, которые срочными станут в скором времени. Успешные команды и сотрудники в первую очередь обращают свое внимание именно на этот тип задач, чтобы они постепенно не перешли в разряд "Важные и срочные задачи".
  3. Не важные, но срочные. Это тип задач, которые никак не приближают к достижению необходимого результата, которые надо делать, но исключительно для того, чтобы их делать.

     

     Рис. 8.2. Матрица Эйзенхауэра

  4. Не важные и не срочные. Эти задачи не важны, они не срочны, но именно их хочется делать. Это пожиратели времени, и от них необходимо избавляться.

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

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

• Методика "АБВ". В соответствии с этой методикой задачи делятся на три категории: жизненно важное, важное, приятное. Эта методика является логическим (более "глубинным") продолжением принципа Эйзенхауэра.

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

  • Самые критичные задачи (категория "А") составляют ~ 20% всех задач, которыми занят руководитель. Значимость этих задач, вклада в достижение конечного результата составляет ~ 60%.
  • Менее важные задачи (категория "Б") составляют ~ 20 % от общего числа. Их значимость - также 20% значимости задач и дел руководителя.

  • Неважные и несущественные задачи (категория "В") составляют 60% от общего числа задач. Они имеют незначительную долю - 15% в общей ценности всех задач.

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

• Метод MoSCoW (Oracle). Один из консультантов Oracle (Dai Clegg) предложил однозначный, логичный и понятный метод приоритизации требований для анализа и задач разработки программного обеспечения - MoSCoW. Этот метод используется при фиксированных сроках на реализацию функциональности, когда всё внимание должно быть обращено на самые приоритетные требования. Приоритизация задач методом MoSCoW позволяет сосредоточить фокус внимания как владельца продукта, так и Scrum-команды на задачах конкретного спринта.

  Все имеющиеся задачи в бэклоге продукта следует сгруппировать в четыре приоритетные корзины по следующим правилам:

  • M (must) - задачи должно быть реализованы в первую очередь, без них программный продукт не имеет смысла. От этих задач нельзя отказаться. В них заключен залог успеха. Задачи, отмеченные как must, должны быть включены в текущий спринт.
  • S (should) - следовало бы иметь, но можно отложить на более позднее время. Задачи этого типа также критичны для успеха разрабатываемого продукта, но не необходимы в ближайшее время. Такие задачи, как правило, имеют альтернативные пути решения.
  • C (could) - можно было бы иметь, но если нет возможности их разработать сейчас, то можно и отложить. Задачи этого типа менее критичны. Они обычно относятся к типу "хотелось бы иметь".
  • W (would) - в этот раз стоит отказаться от этих задач, но в следующий раз можно их сделать. Наименее критичные. Задачи данной категории не планируются к разработке в ближайшие спринты, но при будущих поставках их статус может быть пересмотрен.

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

8.4. Доска задач

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

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

На доске команды развешены задачи, каждой из которых выделен бумажный стикер, на котором написано, в чем состоит суть задачи (рис. 8.3).

Рис. 8.3. Доска задач

Доска задач должна минимум делиться на три колонки:

• запланировано (To Do);
• в работе (In Progress);
• завершено (Done).

На момент планирования задач, которые предстоит взять в спринт, все карточки помещаются в колонку "Запланировано". Каждый день, когда член команды берет в работу определенную задачу, он говорит: "Я начал работать над…" и перемещает карточку в столбец "In Progress". После того как задача выполнена, исполнитель говорит о том, что работа над задачей закончена, и карточка перемещается в соответствующую колонку "Завершено".

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

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

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

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

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

8.5. Бэклог продукта

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

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

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

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

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

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

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

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

• Задача --> Решение.
• Общее --> Частное.
• Учет влияния различных факторов --> Улучшение качества продукта.
• Прочее.

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

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

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

Это ведет к лучшему пониманию всеми вовлеченными сторонами, выявлению новых деталей.

После того как необходимые требования к продукту собраны, их необходимо зафиксировать и "взять на учет" для дальнейшей реализации. Для этого в Scrum есть артефакт, который называется бэклог продукта (Product Backlog, PB).

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

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

PB никогда не является полным. В начале (сверху) - только первоначально известные и наиболее понятные требования. Бэклог постоянно обновляется по мере обновления самого продукта и окружающей его среды, поэтому PB "живет" вместе с продуктом. PB является динамическим, постоянно изменяющимся для соответствия требованиям продукта, его конкурентоспособности и пригодности. PB существует ровно до тех пор, пока существует и сам продукт:

1. PB содержит все "фичи", функции, требования, усовершенствования и информацию по исправлению дефектов, то есть те данные, которые и определяют изменения, необходимые в следующих релизах продукта. Каждому элементу PB присваивается описание, порядковый номер, оценка объема работы и ценность.
2. Элементы бэклога продукта, расположенные сверху, должны быть более понятными и содержать больше деталей, чем те, которые расположены ниже. Более точные оценки даются требованиям, которые являются более четкими и содержат больше дополнительной информации.
3. Чем ниже находятся требования, тем меньше деталей. Бэклог спринта представляет собой репозиторий задач, реализация которых позволит инкрементально двигаться к достижению желаемого конечного результата от разработки конкретного программного продукта.

8.6. Бэклог спринта

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

Бэклог спринта (Sprint Backlog SB) - это набор элементов Product Backlog, выбранных для выполнения в текущем спринте.

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

Бэклог спринта:

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

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

Scrum-команда работает над бэклогом спринта на всем его протяжении, и он постоянно изменяется вместе с прогрессом команды.

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

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

После того как они выполнены, оценки оставшегося объема работ обновляются.

Если некоторые задачи считаются уже неактуальными, то их удаляют.

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

8.7. Инкремент продукта

Цель команды Scrum в отдельно взятом спринте - предоставлять работающий инкремент продукта.

Работающий "прирост" продукта (инкремент) - обязательный результат каждого спринта Scrum.

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

Инкремент по своей сути - это продукт, который будет приносить бизнес-пользу (рис. 8.4) в момент своей разработки после того, как результаты определенного спринта реализованы Scrum-командой и приняты заказчиком.

На рис. 8.4 приведены две иллюстрации.

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

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

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

По окончании спринта инкремент должен быть пригодным к использованию и приносить реальную и ощутимую прибыль PO.

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

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

8.8. Принцип прототипирования

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

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

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

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

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

8.9. Краткие выводы

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

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