Что будет предоставлено в инкременте по завершении предстоящего спринта?
Какая работа необходима, чтобы достигнуть этого приращения?
Прогноз предположение, основанное на опыте, как много усилий по переводу требований в бэклоге продукта может быть преобразовано в инкремент. Прогноз не является гарантией.
Что будет предоставлено в инкременте по завершении предстоящего спринта?
Какая работа необходима, чтобы достигнуть этого приращения?
Прогноз предположение, основанное на опыте, как много усилий по переводу требований в бэклоге продукта может быть преобразовано в инкремент. Прогноз не является гарантией.
Прогнозная линия проекция скорости во времени, чтобы предсказать, что может произойти, если все в будущем останется подобным тому, что было в прошлом.
Прозрачность природа инкремента как завершенного фрагмента функциональных возможностей, который мы можем использовать для наших целей и определить наш прогресс в направлении видения или цели.
Продуктивность количество единиц бизнес-функционала, которая разработана за определенное количество денег (например, на 100 тысяч долларов инвестиций). Продуктивность также называют скоростью.
Разработчик программного обеспечения сотрудник, связанный с аспектами процесса разработки программного обеспечения. Его работа включает в себя исследование, создание дизайна, разработку и тестирование программного обеспечения.
Ретроспектива спринта возможность для Scrum-команды проверить себя и создать план для улучшений, которые будут предприняты в следующем спринте. Ретроспектива спринта происходит после обзора спринта и перед следующим планированием спринта. Это трехчасовая встреча для спринта продолжительностью один месяц. Для более коротких спринтов время пропорционально уменьшается.
Самоорганизация процесс, при котором структура, или конфигурация, появляется в системе без центрального управления или внешних элементов, диктующих ее при помощи планирования.
Скорость мера измерения количества бизнес-функционала, который создается в течение определенного периода или на единицу денежных средств.
Спринт сердце Scrum-процесса, ограниченный промежуток времени, протяженностью один месяц или меньше, в течение которого производится «законченный», пригодный к использованию и потенциально готовый к выпуску инкремент продукта. Спринты складываются в последовательные периоды на протяжении всего процесса разработки. Новый спринт начинается непосредственно после завершения предыдущего.
Требования уникальные, документально описанные физические и функциональные качества, которые должны иметь конкретный продукт или услуга. Это формулировка, определяющая необходимые атрибуты, производительность, характеристики или качество системы, которые имеют ценность или полезность для пользователя.
Цель спринта дает команде разработки некоторую гибкость касательно функциональных возможностей, выполняемых в пределах спринта. Во время работы команда разработки держит эту цель в голове и, для того чтобы ее достичь, реализует функциональные возможности и технологии. Если работа оказывается отличной от ожиданий команды разработки, ее члены взаимодействуют с владельцем продукта, внося изменения в бэклог в течение спринта.
Функциональная точка единица измерения для выражения количества бизнес-функционала, которую информационная система предоставляет пользователю. Стоимость (в долларах или часах) одной единицы вычисляется по предыдущим проектам.
Эмерджентность путь, которым сложные системы и структуры возникают из множества относительно простых взаимодействий. Эмерджентность занимает центральное место в теории интегративных уровней и комплексных систем.
Эмпирический полученный с помощью наблюдения или эксперимента.
Приложение 2. Scrum-гайд
ИСЧЕРПЫВАЮЩЕЕ РУКОВОДСТВО ПО SCRUM. ПРАВИЛА ИГРЫ
Разработаны и поддерживаются Кеном Швабером и Джеффом Сазерлендом
Статья I. Цель Scrum-гайда
Scrum это фреймворк для создания и поддержки функционально сложных продуктов. Данное руководство содержит определение Scrum, состоящее из описания ролей, событий, Scrum-артефактов, а также правил, связывающих их вместе. Кен Швабер и Джефф Сазерленд разработали Scrum и представили Scrum-гайд.
Статья II. Общее представление о Scrum
Scrum (сущ.) фреймворк, в рамках которого люди могут решать сложные адаптивные проблемы и в то же время продуктивно и креативно поставлять продукты наивысшей возможной ценности.
Статья II. Общее представление о Scrum
Scrum (сущ.) фреймворк, в рамках которого люди могут решать сложные адаптивные проблемы и в то же время продуктивно и креативно поставлять продукты наивысшей возможной ценности.
Scrum обладает следующими характеристиками:
легковесен;
прост в понимании;
чрезвычайно труден в освоении.
Scrum используется для управления процессами разработки сложных продуктов с начала 1990-х годов. Scrum это не процес или техника создания продуктов; скорее это фреймворк, в рамках которого вы можете применять разнообразные процессы и технические приемы. Scrum показывает относительную эффективность вашего управления продуктом и практических методов разработки; при помощи Scrum вы можете их улучшить.
Раздел 2.01. Фреймворк Scrum
Фреймворк Scrum состоит из Scrum-команд и связанных с ними ролей, мероприятий, артефактов и правил. Каждый элемент фреймворка служит определенной цели и является ключевым для успеха и использования Scrum.
Существуют различные стратегии использования фреймворка Scrum, их описание выходит за пределы данного документа.
Правила Scrum объединяют мероприятия, роли и артефакты, регулируя отношения и взаимодействия между ними. Правила Scrum описаны в данном документе.
Статья III. Теория Scrum
Scrum основывается на теории управления эмпирическими процессами, или эмпиризме. Эмпиризм утверждает, что знание приходит с опытом и решения принимаются на основании того, что известно. Scrum использует итеративно-инкрементальный подход для оптимизации прогнозируемости и управления рисками.
Три столпа, на которых держится каждое применение эмпирического процесса управления: прозрачность, инспекция и адаптация.
А. Прозрачность. Значимые аспекты процесса должны быть видимы тем, кто отвечает за его результат. Прозрачность требует, чтобы эти аспекты определялись общими стандартами. Все наблюдатели должны разделять одно и то же понимание видимого.
Примеры:
общая терминология, относящаяся к процессу, должна использоваться всеми его участниками;
общее определение «законченности» (см. статью VIII «Определение законченности») должно разделяться и теми, кто производит работу, и теми, кто принимает продукт этой работы.
Б. Инспекция. Участники Scrum-процесса должны часто инспектировать Scrum-артефакты и динамику движения к цели для своевременного выявления нежелательных отклонений. Однако инспектирование не должно быть настолько частым, чтобы мешать работе. Проверки приносят наибольшую пользу, если усердно выполняются квалифицированными инспекторами во время работы.
В. Адаптация. Если по результатам проверки инспектор делает заключение, что один или более аспектов процесса отклонились от допустимых пределов и производимый продукт будет неприемлемым, инспектор должен внести изменения либо в процесс, либо в рабочие материалы. Изменения должны вноситься как можно раньше для уменьшения дальнейшего отклонения от нормы.
Scrum предписывает четыре формальные возможности для инспекции и адаптации, описанные в статье VI «События Scrum»:
планирование спринта;
Scrum-митинг;
обзор спринта;
ретроспектива спринта.
Статья IV. Scrum
Scrum это фреймворк, структурированный для поддержки разработки сложных продуктов. Scrum состоит из Scrum-команд и с ними связанных ролей, событий, артефактов и правил. Каждый компонент в пределах фреймворка служит специфической цели и необходим для успешного использования Scrum.
Статья V. Scrum-команда
Scrum-команда состоит из владельца продукта, команды разработки и Scrum-мастера. Scrum-команды самоорганизующиеся и кросс-функциональные.
Самоорганизующиеся команды сами выбирают лучший способ выполнения работы, а не ждут указаний от тех, не входит в состав команды. Кросс-функциональные команды имеют все необходимые навыки, чтобы выполнять работу и не зависеть ни от кого извне. Командная модель Scrum создана для оптимизации гибкости, креативности и продуктивности.
Scrum-команды предоставляют продукты итеративно и инкрементально, максимально увеличивая возможности для обратной связи. Инкрементальные поставки «законченного» продукта гарантируют, что потенциально пригодная рабочая версия продукта всегда доступна.
Раздел 5.01. Владелец продукта
Раздел 5.01. Владелец продукта
Владелец продукта отвечает за достижение максимальной ценности продукта и работы, выполняемой командой разработки. Способы достижения этой цели могут широко отличаться среди различных организаций, Scrum-команд и отдельных людей.
Владелец продукта единственный человек в команде, отвечающий за бэклог продукта. Управление бэклогом продукта включает в себя:
четкое описание пунктов бэклога;
упорядочивание его пунктов для лучшего достижения целей и поручений;
обеспечение ценности работы, выполняемой командой разработки;
обеспечение видимости, прозрачности и понятности бэклога продукта для всех, а также отображение тех требований, над которыми Scrum-команде предстоит работать в ближайшее время;
достижение понимания командой разработки на необходимом уровне требований бэклога продукта.
Владелец продукта может либо сам выполнять вышеперечисленные задачи, либо делегировать их выполнение членам команды разработки. Однако ответственным за это остается именно он.
Владелец продукта один человек, а не группа людей. Владелец продукта может представлять интересы группы людей в бэклоге продукта, но желающие изменить приоритеты требований должны в первую очередь убедить в этом именно его.
Для успешного выполнения владельцем продукта своих обязанностей все в организации должны уважать его решения. Все решения владельца продукта видны через содержимое и порядок элементов бэклога продукта. Никому не позволено давать задание команде разработки работать над другим набором требований, а команде разработки запрещается действовать по указанию кого-либо другого.