Проекты гибкой разработки (agile) — Карл Вигерс и Джой Битти

Под гибкой разработкой (agile development) подразумевают набор методов разработки ПО, обеспечивающих постоянное сотрудничество между заинтересованными лицами и быстрый и частый выпуск функциональности небольшими порциями. Существует много разных типов гибкой разработки, вот лишь самые популярные:
— Scrum
— Extreme Programming
— Lean Software Development
— Feature-Driven Development
— Kanban
Термин «гибкая разработка» приобрел популярность с момента публикации «Manifesto for Agile Software Development» («Манифест гибкой разработки ПО»). Методы гибкой разработки основаны на интерактивных и инкрементальных подходах к разработке ПО, которые существуют уже много лет.
Методики гибкой разработки обладают разными характеристиками, но в основном в них предпочтение отдается адаптивному (иногда он называется «управляемым изменениями»), а не прогнозному (иногда он называется «плановым») подходу (Boehm и Turner, 2004; IIBA, 2009). В прогнозном подходе, таком как водопадная методика, пытаются минимизировать риски в проекте, выполняя значительный объем планирования и документирования до начала создания ПО. Менеджеры проектов и бизнес-аналитики обеспечивают, чтобы все заинтересованные лица четко понимали, что планируется выпустить, до начала разработки. Это работает, если с самого начала есть четкое понимание требований, а сами требования остаются практически неизменными на протяжении всего проекта. Адаптивные подходы, такие как методы гибкой разработки, призваны обеспечить приспособляемость к неизбежным изменениям, которые будут происходить в проектах. Они также хорошо работают в проектах с неточными или изменчивыми требованиями.

Гибкие требования?Термин «гибкие требования» не используется, потому что это подразумевало бы, что требования в проекте гибкой разработки чем-то отличаются от проектов других жизненных циклов. Разработчикам нужен одинаковый объем информации, чтобы правильно реализовывать нужную функциональность во всех проектах. Однако в обычных проектах и проектах гибкой разработки с требованиями работают по-разному, особенно в том, что касается глубины проработки, места требований в графике проекта, а также объема письменной документации требований. Используется термин «требования в проекте гибкой разработки».

Ограничения водопадной модели

Часто считают, что водопадный процесс разработки предусматривает линейную последовательность операций, в которой в команде проекта определяют (иногда излишне) требования, после чего создают дизайн, затем пишут код и, наконец, тестируют решение. Теоретически, у этого подхода есть ряд преимуществ. В команде могут обнаружить все недостатки требований к приложению и дизайну на ранних этапах, а не на стадиях разработки, тестирования или сопровождения, когда исправление ошибок обходится значительно дороже. Если требования верны с самого начала, легко определять бюджет и ресурсы, оценивать прогресс и точно определять дату завершения. Но в реальности разработка ПО редко бывает столь прямолинейной.
В очень немногих проектах применяется чистый последовательный водопадный подход. Даже в прогнозируемых проектах ожидается определенный объем изменений, и нужны механизмы для работы с ними. Всегда есть некоторое перекрытие и обратная связь между стадиями. Но в целом, в проектах водопадной разработки команда прикладывает значительные усилия к тому, чтобы как можно раньше «как положено» создать все требования. Помимо водопадной модели и модели гибкой разработки существует много других жизненных циклов разработки ПО. В них по-разному относятся к разработке полного набора требований на ранних этапах проекта (McConnell, 1996; Boehm и Turner, 2004). Основной отличительный признак всего спектра проектов — от фиксированных, прогнозируемых проектов и полностью неопределенных, адаптивных проектов — заключается во времени, которое проходит от создания требования до поставки основанного на этом требовании ПО клиенту.
В крупных водопадных проектах поставка продукта часто происходит с задержкой, в нем отсутствуют необходимые функции, а сам продукт не оправдывает пользовательских ожиданий. Водопадные проекты подвержены таким неудачам из-за многих слоев зависимостей в требованиях. В процессе длинного проекта заинтересованные лица часто меняют свои требования, процесс разработки стопорится из-за неспособности разработчиков эффективно реагировать на эти изменения. Реальность такова, что заинтересованные лица будут менять требования — потому что в начале проекта они не знают точно, что им нужно, потому что способны сформулировать свое видение, только увидев что-то, что точно не соответствует их видению и потому что иногда в процессе выполнения проекта их бизнес-потребности меняются.
Первую публикацию формальной водопадной модели (хотя и под другим именем) приписывают Уинстону Ройсу (Royce, 1970), но он представил ее в контексте описания подхода, который «рискован и чреват неудачами». Он точно определил проблему, с которой сегодня сталкиваются при реализации проектов: ошибки требований не обнаруживаются до начала тестирования, то есть до поздних стадий проекта. Далее Уинстон объяснил, что этапы проект в идеале должны выполняться в последовательности: требования, дизайн, кодирование и тестирование, но также он заметил, что в проектах действительно требуется перекрытие некоторых из этих фаз и итерации между ними. Он даже предложил в качестве эксперимента выполнять моделирование для создания прототипов требований и дизайна до начала полноценной разработки. Вместе с тем видоизмененная водопадная модель сегодня применяется во многих проектах, с переменным успехом.

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

Гибкий подход к разработке

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

Особенность гибкой разработки в применении к требованиям

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

Вовлечение клиентов

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

Подробнее о документации

Так как в водопадных проектах на этапе разработки программисты практически не общаются с клиентами, в требованиях должны подробно описываться поведение системы, связи между данными и ожидания в области удобства использования. Тесное сотрудничество клиентов с разработчиками в проектах гибкой разработки обычно означает, что требования могут документироваться менее подробно, чем в традиционных проектах. Бизнес-аналитики и другие ответственные за требования люди могут добиваться необходимой точности в процессе общения и документирования по мере необходимости (IIBA, 2013).
Некоторые считают, что в командах гибкой разработки не нужно писать требования. Это не совсем так — методы гибкой разработки должны способствовать созданию минимального объема документации, которое дает точные указания разработчикам и тестировщикам. Любая документация помимо той, что нужна разработчикам и тестировщикам (или необходима для выполнения требований законов и нормативных документов), представляет собой выполненную впустую работу. В некоторых пользовательских историях может предоставляться немного подробностей, а детально описывается только самая рискованная и важная функциональность, обычно в виде приемочных тестов.

Резерв проекта и расстановка приоритетов

Резерв (backlog) проекта гибкой разработки содержит список запросов на работу, которую должна выполнить команда (IIBA, 2013). Резервы проектов обычно состоят из пользовательских историй, но в некоторых командах их наполняют другими требованиями, бизнес-процессами и дефектами, которые нужно устранить. В каждом проекте должен быть лишь один резерв. Поэтому может потребоваться представлять в резерве дефекты, чтобы можно было определять их приоритеты в одном ряду с новыми пользовательскими историями. В некоторых командах дефекты переопределяют как новые пользовательские истории или варианты старых историй. Резервы могут реализовываться в виде карт историй или в специализированных инструментах. Пуристы от гибкой разработки настаивают на использовании карт, но они неудобны для работы в крупных проектах или в распределенных командах. На рынке доступны различные средства управления проектами гибкой разработки, в том числе для управления резервом.
Расстановка приоритетов в резерве выполняется регулярно — одни задачи выбираются на следующие итерации, а другие отбрасываются. Приоритеты, назначаемые элементам резерва, не фиксируются раз и навсегда и могут меняться в следующей итерации. Отслеживание связей между элементами резерва и бизнес-требованиями облегчает приоритизацию. Во всех проектах, и не только в тех, где применяется гибкая разработка, нужно управлять приоритетами задач, остающихся в резерве.

Планирование времени

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

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

Эпики, пользовательские истории и функции

Пользовательская история — это краткое утверждение, которое выражает потребность пользователя и служит исходной точной для общения с целью выяснения деталей. Пользовательские истории специально созданы для обслуживания потребностей «гибких» разработчиков. При изучении пользовательских требований вы вправе задействовать названия вариантов использования, функций или потоков процессов. Выбор формы для описания всех этих требований не важна — в этой главе мы в основном называем их пользовательскими историями, потому что именно они чаще всего используются в проектах гибкой разработки.
Объем пользовательской истории определяют так, чтобы ее реализация могла уложиться в одну итерацию. Майк Кон (Cohn, 2010) определяет эпику (epic) как пользовательскую историю, которая слишком велика для реализации в одной итерации. По этой причине эпики нужно разбивать на наборы более мелких историй. Иногда эпики такие большие, что их приходится разбивать на ряд более мелких эпик, каждая их которых в свою очередь разбивается на истории, пока не будут получены истории, которые можно с уверенностью оценить, реализовать и протестировать в одной итерации. Разбиение больших эпик сначала на более мелкие эпики, а затем на пользовательские истории часто называют декомпозицией истории (story decomposition) (IIBA, 2013).
Рисунок «Эпики могут разбиваться на более мелкие эпики, а затем — на пользовательские истории»:

Функция — это группа возможностей системы, которая представляет ценность для пользователя. В контексте проекта гибкой разработки функции могут распространяться на одну пользовательскую историю, несколько таких историй, отдельную эпику или даже на несколько эпик. Например, функция увеличения масштаба в фотокамере телефона может разрабатываться для реализации двух не связанных между собой пользовательских историй:
• Будучи матерью, я хочу иметь возможность делать на школьных мероприятиях снимки, на которых четко видна моя дочь, чтобы я могла делиться ими с дедушкой и бабушкой.
• Будучи орнитологом, я хочу иметь возможность на расстоянии получать четкие фотографии птиц, на которых их можно различать.
Определение историй самого нижнего уровня, соответствующих бизнес-требованиям, позволяет определять минимальный набор функциональности, который способна предоставить команда и который одновременно представляет определенную ценность для клиента. Этот принцип иногда называют принципом «минимальной поддающейся для продвижения на рынке функции» (minimal marketable feature, MMF), как описано Марком Денне и Джейн Клеланд-Хуанг (Denne и Cleland-Huang, 2003).

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

Расчет на неизбежные изменения

В организациях знают, что в проектах будут изменения. Даже бизнес-цели могут меняться. Самое важное для бизнес-аналитика — перестроиться и при возникновении изменений требования в проекте гибкой разработки говорить не что-то типа: «Минуточку, это выходит за рамки проекта» или «Для внедрения этого изменения нам нужно пройти определенный формальный процесс», а «Хорошо, давайте обсудим изменение». Это способствует привлечению клиента к созданию или изменению пользовательских историй и определению приоритетов всех запросов на изменение по отношению ко всему, что уже есть в резерве проекта. Как и во всех других проектах, в проектах гибкой разработки нужно с умом управлять изменениями, чтобы минимизировать их негативное влияние на проект, но нужно рассчитывать или даже стремиться к неизбежности изменений.
Понимание своей способности справиться с изменениями не означает, что нужно слепо игнорировать будущее и обращать внимание только на то, что известно в настоящий момент. По-прежнему важно заглядывать в будущее и смотреть, что может вас ожидать далее. Разработчики не обязательно создают дизайн, рассчитанный на все возможные будущие требования. Но имея возможность заглянуть чуть в будущее, они могут создать более расширяемую и надежную архитектуру или закладки в дизайне, облегчающие добавление новой функциональности.
К изменениям относится и удаление элементов из проекта. Удаление может выполняться по самым разным причинам, в числе которых:
• проблемы с реализацией не позволяют завершить элемент в текущий период времени;
• проблемы, обнаруженные владельцами продукта или тестировщиками, делают реализацию той или иной истории неприемлемой;
• необходимость замены менее важных элементов, запланированных на итерацию, более приоритетными.

Переход к гибкой разработке: что дальше?

Если вы бизнес-аналитик, не особо знакомый с методами гибкой разработки, не волнуйтесь: вы по-прежнему можете применять большинство привычных вам приемов. В конце концов и в традиционных проектах и в проектах гибкой разработки командам нужно понимать требования к создаваемым решениям.
Вот несколько советов по переходу к методике гибкой разработки:
• Определите свою роль в команде. В одних проектах гибкой разработки есть выделенный бизнес-аналитик, а в других задачи бизнес-аналитика выполняют другие люди. Поощряйте ориентацию членов команды на проект, а не на свои индивидуальные роли или должности (Gorman и Gottesdiener, 2011).
• Прочитайте одну из книг о роли владельца продукта в проекте гибкой разработки, чтобы получить хорошее представление о пользовательских историях, приемочных тестах, приоритизации резерва, а также узнать, почему работа бизнес-аналитика продолжается вплоть до конца проекта или выпуска. Можно порекомендовать книгу «Agile Product Management with Scrum» («Гибкое управление продуктом в рамках скрама») (Pichler, 2010).
• Выбрать из предлагаемых приемов те, что лучше всего подойдут вашей организации. Вспомните, какие приемы разработки уже хорошо себя зарекомендовали в вашей организации, и продолжайте их применять. Поговорите с людьми, выполняющими другие роли в команде, и определите, как их приемы работы применить в среде гибкой разработки.
• Сначала реализуйте один небольшой проект в качестве пилотного для обкатки методов гибкой разработки или внедрите несколько приемов гибкой разработки в свой следующий проект.
• Если вы решите реализовать гибридную модель, в которой применяется лишь часть приемов гибкой разработки, для начала выберите только приемы с низким риском, которые хорошо работают в любой методологии. Если вы новичок в гибкой разработке, пригласите опытного наставника на три-четыре итерации, чтобы помочь вам избежать искушения вернуться к привычным приемам работы.
• Не нужно быть пуристом от гибкой разработки только из принципа.

Спецификация требований в проектах гибкой разработки

В проектах гибкой разработки (agile) применяется ряд способов определения требований, которые отличаются от только что описанного метода.Во многих проектах гибкой разработки в процессе выявления требований используются пользовательские истории. Каждая такая история представляет собой формулировку потребности пользователя или функциональности, которая может быть полезной пользователю или покупателю системы. В проектах гибкой разработки команда может начать спецификацию, записав достаточно информации по каждой пользовательской истории, чтобы заинтересованные лица получили общее представление, о чем история, и смогли определить приоритеты историй друг относительно друга. Это также позволяет команде начать планировать назначение историй на конкретные итерации. Команда может собирать связанные истории в «минимально поддающуюся для продвижения на рынке функцию», которую нужно реализовать целиком к выпуску продукта, чтобы клиент мог получить от нее пользу.
Пользовательские истории накапливаются и приоритизируются в резерве продукта (product backlog), который меняется на протяжении всего проекта. Крупные истории, которые охватывают значительную функциональность и которые нельзя реализовать в одной итерации, разбиваются на более мелкие, которые назначаются конкретным итерациям.
Пользовательские истории можно записывать на чем-то простом, например на карточках каталога, а не в традиционном документе. Одни команды гибкой разработки сохраняют свои истории в средстве управления историями, другие после реализации их не сохраняют.
Когда команда приступает к очередной итерации, каждая история, назначенная на эту итерацию, уточняется и наполняется деталями в процессе обсуждения между владельцем продукта, людьми, выполняющими роль бизнес-аналитика, аналитиками, тестировщиками и пользователями. То есть спецификация подразумевает постепенное уточнение подробностей на правильном этапе проекта, что является хорошей практикой в любом проекте. Обычно эти подробности соответствуют тому, что мы называли функциональными требованиями в спецификации требований к ПО. Однако в проектах гибкой разработки эти подробности часто представляются в форме приемочных тестов, описывающих, как система должна вести себя при правильной реализации истории. Тесты истории проводятся во время итерации, в которой реализуется эта история, и в будущих итерациях в рамках регрессионного тестирования. Как и в любых других тестах, в них должны выполняться исключительные условия, а также ожидаемое поведение. Эти приемочные тесты могут записываться на карточках или регистрироваться в более постоянной форме, например в средстве тестирования. Тесты нужно автоматизировать, чтобы обеспечить быстрое и полное регрессионное тестирование. Если команда решит отказаться от исходных пользовательских историй, тогда приемочными тестами может быть постоянная документация требований, если они хранятся в специализированном средстве.
Аналогично нефункциональные требования могут записываться на карточках, но не как пользовательские истории, а как ограничения.
Альтернативный вариант — указывать нефункциональные требования, относящиеся к определенной пользовательской истории, в форме критериев приемки как демонстрацию достижения определенного атрибута качества.
Например, тесты безопасности могут демонстрировать, что только определенным пользователям разрешен доступ к функциональности, описанной в соответствующей пользовательской истории, а остальным пользователям доступ закрыт. Команде гибкой разработки не возбраняется применять другие методы представления знаний о требованиях, такие как модели анализа или словарь данных. Они должны выбрать метод представления, который привычен и уместен в их культуре и проект.
Выбор надлежащих форм спецификации требований к ПО — исключительная прерогатива команды проекта. Вспомните главную цель разработки требований — собрать согласованное понимание требований, качество которых достаточно, чтобы приступить к разработке следующей части продукта и продолжить работу при приемлемом уровне риска. «Надлежащий» уровень формальности и подробности документа требований зависит от многих факторов, в числе которых:
• объем оперативного неформального вербального и визуального общения между клиентами и разработчиками, который необходим для получения подробностей, необходимых для правильной реализации каждого пользовательского требования;
• предел, до которого неформальные методы общения могут обеспечить эффективную синхронизацию во времени и пространстве внутри команды;
• граница, до которой представляет ценность или необходимость сохранение знаний о требованиях для будущих улучшений, реинжиниринга приложения, проверки, аудита, проверки на соответствие нормативам, сертификации продукта или в соответствии с условиями контракта;
• граница, до которой приемочные тесты могут эффективно заменять описания ожидаемых возможностей и поведения системы;
• предел, до которого человеческая память может заменить письменное представление.

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

Управление требованиями в проектах гибкой разработки

В проектах гибкой разработки (agile) работа с изменениями ведется путем построения продукта в рамках серии итераций и управления динамическим резервом (backlog) продукта, то есть работы, которую нужно выполнить. Заинтересованные лица согласовывают истории, которые должны реализовываться в каждой итерации. Новые истории, добавляемые пользователями во время итерации, приоритизируются в совокупности с резервом проекта и назначаются на будущие итерации. Новые истории могут вытеснить низкоприоритетные истории, если команда не хочет менять график выпуска. Как и во всех других проектах, задача всегда заключается в работе над наиболее приоритетными историями, чтобы максимально быстро предоставить клиентам полезный продукт.
В некоторых командах, особенно в крупных или распределенных, используется средство управления проектом гибкой разработки для отслеживания состояния итерации и назначенных на нее историй. Истории и соответствующие им приемочные критерии и тесты можно все разместить в резерве продукта или средстве управления пользовательскими историями. Состояние истории можно отслеживать с использованием следующих статусов:
• In backlog (В резерве) — история пока не назначена на конкретную итерацию;
• Defined (Определена) — подробности истории обсуждены и поняты, и написаны приемочные тесты;
• In Progress (Разработка) — история в процессе реализации;
• Completed (Завершено) — история полностью реализована;
• Accepted (Принята) — пройдены приемочные тесты;
• Blocked (Блокирована) — разработчик не может продолжить разработку, пока не будут разрешены другие вопросы.

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

Остающиеся в конце итерации баллы историй в резерве отмечаются на графике. Эта общая цифра изменяется по мере завершения работы, лучшего понимания и переоценки текущих историй, добавления новых историй и удаления завершенной работы из резерва. Таким образом, график сгорания задач показывает общий объем остающейся работы на определенный момент времени, а не отслеживает число и состояние отдельных функциональных требований или функций (размер которых может быть разным). На рисунке «Пример графика сгорания задач в проекте гибкой разработки» показан график сгорания задач гипотетического проекта. Заметьте, что измеренный в баллах историй объем остающейся работы, на самом деле увеличился в итерациях 2, 3 и 5. Это говорит, что в резерв добавилось больше новой функциональности, чем было завершено или удалено в течение итерации. График сгорания задач помогает избежать синдрома «90 процентов», наглядно показывая объем остающейся, а не завершенной работы, которая не отражает неизбежное увеличение границ проекта. Наклон графика сгорания задач также отражает прогнозируемую конечную дату проекта — точку, когда резерв будет пуст.
Рисунок «Пример графика сгорания задач в проекте гибкой разработки»:

Литература

Карл Вигерс и Джой Битти — Разработка требований к программному обеспечению. Издание третье, дополненное. 2013 год.