Agile — Primer

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

Роли в Agile

Скрам Мастер

Scrum Master — лидер команды и помощник, который помогает членам команды следовать гибким методам, чтобы они могли выполнять свои обязательства. Обязанности мастера схватки следующие:

• Чтобы обеспечить тесное сотрудничество между всеми ролями и функциями.

• Убрать любые блоки.

• Чтобы защитить команду от любых помех.

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

• Чтобы обеспечить правильное использование процессов Agile Inspect & Adapt, что включает

  • Ежедневные приемы,
  • Запланированные встречи,
  • Демонстрация,
  • Обзор,
  • Ретроспективные встречи и
  • Чтобы облегчить встречи команды и процесс принятия решений.

Чтобы обеспечить тесное сотрудничество между всеми ролями и функциями.

Убрать любые блоки.

Чтобы защитить команду от любых помех.

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

Чтобы обеспечить правильное использование процессов Agile Inspect & Adapt, что включает

Владелец продукта

Владелец продукта — это тот, кто управляет продуктом с точки зрения бизнеса. Обязанности или владелец продукта следующие:

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

Межфункциональная команда

Каждая гибкая команда должна быть самодостаточной командой с 5-9 членами команды и средним опытом работы от 6 до 10 лет. Как правило, гибкая команда состоит из 3-4 разработчиков, 1 тестировщика, 1 технического специалиста, 1 владельца продукта и 1 мастера разработки.

Владелец продукта и Scrum master считаются частью Team Interface, тогда как другие участники являются частью Technical Interface.

Как Agile Team планирует свою работу?

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

точка

Точка определяет, сколько команда может совершить. Точка обычно относится к 8 часам. Каждая история оценивается в баллах.

Вместимость

Потенциал определяет, сколько человек может совершить. Вместимость оценивается в часах.

Что такое история пользователя?

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

• Как <Роль пользователя> я хочу <Функциональность>, чтобы <Business Value>
• Для того, чтобы <Business value> как <User Role>, я хочу <Functionality>

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

Взаимосвязь пользовательских историй и задач

• Пользовательская история рассказывает о том, что должно быть сделано. Он определяет, что нужно пользователю.
• Задача говорит о том, как это сделать. Он определяет, как должна быть реализована функциональность.
• Истории реализуются заданиями. Каждая история представляет собой сборник задач.
• Пользовательская история делится на задачи, когда она планируется в текущей итерации.
• Задачи оцениваются в часах, обычно от 2 до 12 часов.
• Истории проверяются с использованием приемочных тестов.

Когда история закончена

Команда решает, что значит сделать . Критерии могут быть —

• Все задачи (разработка, тестирование) выполнены.
• Все приемочные испытания проводятся и пройдены.
• Дефект не открыт.
• Владелец продукта принял историю.
• Доставляется конечному пользователю.

Что такое критерии приемки?

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

Как определяются требования?

Требования определены как

• История пользователя,
• С критериями приемки и
• Задачи для реализации истории.

Agile — Манифест

В феврале 2001 года на курорте Snowbird в штате Юта 17 разработчиков программного обеспечения встретились, чтобы обсудить упрощенные методы разработки. Результатом их встречи был следующий Agile Manifesto для разработки программного обеспечения —

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

• Люди и взаимодействия по процессам и инструментам
• Рабочее программное обеспечение над всеобъемлющей документацией
• Сотрудничество с клиентом в рамках переговоров по контракту
• Реагирование на изменения После плана

То есть, хотя в элементах справа есть ценность, мы слева оцениваем элементы больше.

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

То есть, хотя в элементах справа есть ценность, мы слева оцениваем элементы больше.

Двенадцать принципов гибкого манифеста

• Удовлетворенность клиентов — Наивысший приоритет отдается удовлетворению потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.

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

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

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

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

• Разговор лицом к лицу. Разговор лицом к лицу является наиболее эффективным и действенным способом передачи информации в команду разработчиков и внутри нее.

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

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

• Мониторинг — Регулярное внимание уделяйте техническому совершенству и хорошему дизайну для повышения маневренности.

• Простота. Сохраняйте простоту и используйте простые термины, чтобы измерить работу, которая еще не завершена.

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

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

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

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

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

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

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

Разговор лицом к лицу. Разговор лицом к лицу является наиболее эффективным и действенным способом передачи информации в команду разработчиков и внутри нее.

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

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

Мониторинг — Регулярное внимание уделяйте техническому совершенству и хорошему дизайну для повышения маневренности.

Простота. Сохраняйте простоту и используйте простые термины, чтобы измерить работу, которая еще не завершена.

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

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

Agile — Характеристики

Итеративный / инкрементный и готовый к развитию

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

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

Личное общение

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

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

Обратная связь

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

Agile — ежедневная работа

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

Что такое ежедневный прием?

• Ежедневное выступление — это ежедневное статусное собрание всех членов команды, которое проводится примерно 15 минут.

• Каждый участник должен ответить на три важных вопроса —

  • Что я сделал вчера?
  • Что я буду делать сегодня?
  • Любое препятствие, с которым я сталкиваюсь … / Я заблокирован из-за …

• Ежедневные встречи для обновления статуса, а не для обсуждения. Для обсуждения члены команды должны запланировать еще одну встречу в другое время.

• Участники обычно стоят вместо того, чтобы сидеть, чтобы встреча закончилась быстро.

Ежедневное выступление — это ежедневное статусное собрание всех членов команды, которое проводится примерно 15 минут.

Каждый участник должен ответить на три важных вопроса —

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

Участники обычно стоят вместо того, чтобы сидеть, чтобы встреча закончилась быстро.

Почему встать важно?

Преимущества ежедневной работы в Agile заключаются в следующем:

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

Кто посещает стенд?

• Скрам-мастер, владелец продукта и команда доставки должны присутствовать на стоянке ежедневно.

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

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

Скрам-мастер, владелец продукта и команда доставки должны присутствовать на стоянке ежедневно.

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

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

Географически распределенные команды

Замедление может быть сделано несколькими способами, если члены гибкой команды работают из разных часовых поясов —

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

• Создайте отдельную стойку для каждой группы, обновите статус стойки с помощью таких инструментов, как Rally, SharePoint, Wikis и т. Д.

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

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

Создайте отдельную стойку для каждой группы, обновите статус стойки с помощью таких инструментов, как Rally, SharePoint, Wikis и т. Д.

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

Agile — определение готово

Определение done для User Story, Iteration и Release приведено ниже.

История пользователя

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

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

итерация

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

• Резервное копирование продукта завершено.
• Производительность была проверена.
• Пользовательские истории были приняты или перенесены на следующую итерацию.
• Дефекты были исправлены или перенесены на следующую итерацию.

Релиз

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

• Система прошла стресс-тестирование.
• Производительность настроена.
• Проверка безопасности проводится.
• План аварийного восстановления проверен.

Agile — Планирование релиза

Целью планирования выпуска является создание плана доставки приращения к продукту. Это делается через каждые 2-3 месяца.

Кто участвует?

• Scrum Master — Scrum Master выступает в качестве посредника для гибкой команды доставки.

• Владелец продукта — владелец продукта представляет общий вид журнала ожидания продукта.

• Agile Team — Agile команда доставки предоставляет понимание технических возможностей или любых зависимостей.

• Заинтересованные стороны. Заинтересованные стороны, такие как клиенты, руководители программ, эксперты в данной области, выступают в качестве консультантов при принятии решений относительно планирования выпуска.

Scrum Master — Scrum Master выступает в качестве посредника для гибкой команды доставки.

Владелец продукта — владелец продукта представляет общий вид журнала ожидания продукта.

Agile Team — Agile команда доставки предоставляет понимание технических возможностей или любых зависимостей.

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

Предпосылки планирования

Предпосылки планирования выпуска следующие:

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

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

• Видение высокого уровня

• Цель рынка и бизнеса

• Подтверждение, нужны ли новые позиции в бэклоге продукта

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

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

Видение высокого уровня

Цель рынка и бизнеса

Подтверждение, нужны ли новые позиции в бэклоге продукта

Необходимые материалы

Список материалов, необходимых для планирования выпуска, следующий:

• Опубликованная повестка дня, цель
• Флипчарты, доски, маркеры
• Проектор, способ поделиться компьютерами, имеющими данные / инструменты, необходимые во время совещания по планированию
• Данные планирования

Данные планирования

Список данных, необходимых для планирования выпуска, выглядит следующим образом:

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

Выход

Результатом планирования релиза может быть следующее:

• План выпуска
• обязательство
• Проблемы, проблемы, зависимости и предположения, которые должны контролироваться
• Предложения по улучшению планов будущих выпусков

Повестка дня

Повестка дня планирования выпуска может быть —

• Церемония открытия — приветственное сообщение, цель и повестка дня обзора, инструменты организации и знакомство с бизнес-спонсорами.

• Product Vision, Roadmap — Показать большое изображение продукта.

• Просмотрите предыдущие выпуски — Обсуждение любого вопроса, который может повлиять на план.

• Название релиза / тема — Проверьте текущее состояние тем дорожной карты и внесите необходимые изменения, если таковые имеются.

• Скорость — отображение скорости для текущего и предыдущих выпусков.

• График выпуска — просмотрите ключевые этапы и определите временные рамки для выпуска и итерации в выпуске.

• Проблемы и проблемы — Проверьте любые проблемы или проблемы и запишите их.

• Просмотрите и обновите определение «Готово». Просмотрите определение « выполнено» и внесите соответствующие изменения в зависимости от технологии, навыков или изменений в членах команды с момента последней итерации / выпуска.

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

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

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

• Сопоставьте истории с итерациями. Команда доставки и владелец продукта перемещают истории / дефекты в итерациях в зависимости от размера и скорости. Скрам мастер облегчает сотрудничество.

• Новые проблемы или проблемы — Проверьте любые новые проблемы на основе предыдущего опыта и запишите то же самое.

• Зависимости и предположения — Проверьте все зависимости / предположения, запланированные во время планирования выпуска.

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

• Планирование коммуникаций и логистики — Просмотр / обновление планирования коммуникаций и логистики для выпуска.

• Парковка — Процесс парковки означает, что все элементы должны быть решены или заданы как элементы действий.

• Распределить элементы действий и планы действий — Распределить элементы действий среди их владельцев, обработать план действий.

• Ретроспектива — Запрашивайте отзывы участников, чтобы встреча прошла успешно.

• Закрыть — отпраздновать успех.

Церемония открытия — приветственное сообщение, цель и повестка дня обзора, инструменты организации и знакомство с бизнес-спонсорами.

Product Vision, Roadmap — Показать большое изображение продукта.

Просмотрите предыдущие выпуски — Обсуждение любого вопроса, который может повлиять на план.

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

Скорость — отображение скорости для текущего и предыдущих выпусков.

График выпуска — просмотрите ключевые этапы и определите временные рамки для выпуска и итерации в выпуске.

Проблемы и проблемы — Проверьте любые проблемы или проблемы и запишите их.

Просмотрите и обновите определение «Готово». Просмотрите определение « выполнено» и внесите соответствующие изменения в зависимости от технологии, навыков или изменений в членах команды с момента последней итерации / выпуска.

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

Определить значения размеров — если скорость неизвестна, запланируйте значения размеров, которые будут использоваться при планировании выпуска.

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

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

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

Зависимости и предположения — Проверьте все зависимости / предположения, запланированные во время планирования выпуска.

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

Планирование коммуникаций и логистики — Просмотр / обновление планирования коммуникаций и логистики для выпуска.

Парковка — Процесс парковки означает, что все элементы должны быть решены или заданы как элементы действий.

Распределить элементы действий и планы действий — Распределить элементы действий среди их владельцев, обработать план действий.

Ретроспектива — Запрашивайте отзывы участников, чтобы встреча прошла успешно.

Закрыть — отпраздновать успех.

Agile — планирование итерации

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

Кто участвует?

• Scrum Master — Scrum Master выступает в качестве посредника для гибкой команды доставки.

• Владелец продукта — Владелец продукта имеет дело с подробным просмотром журнала ожидания продукта и критериями его приемлемости.

• Agile Team — Agile Delivery определяет свои задачи и устанавливает оценки усилий, необходимых для выполнения обязательства.

Scrum Master — Scrum Master выступает в качестве посредника для гибкой команды доставки.

Владелец продукта — Владелец продукта имеет дело с подробным просмотром журнала ожидания продукта и критериями его приемлемости.

Agile Team — Agile Delivery определяет свои задачи и устанавливает оценки усилий, необходимых для выполнения обязательства.

Предпосылки планирования

• Элементы в бэклоге продукта имеют размеры и имеют относительную историю.
• Ранжирование было присвоено элементам портфолио владельцем продукта.
• Критерии принятия были четко определены для каждой позиции портфеля.

Процесс планирования

Ниже приведены этапы планирования итераций:

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

Расчет скорости

Гибкая команда вычисляет скорость на основе прошлых итераций. Скорость — это среднее количество единиц, необходимое для завершения пользовательских историй в итерации. Например, если команда набрала 12, 14, 10 сюжетных очков в каждой итерации за последние три итерации, команда может принять 12 в качестве скорости для следующей итерации.

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

Объем задачи

Способность команды определяется следующими тремя фактами:

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

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

5 × 8 × 10 = 400 часов

Планирование шагов

• Владелец продукта описывает самую высокую позицию в списке продуктов.
• Команда описывает задачи, необходимые для завершения предмета.
• Члены команды владеют задачами.
• Члены команды оценивают время для завершения каждого задания.
• Эти шаги повторяются для всех элементов в итерации.
• Если какое-либо лицо перегружено заданиями, то его / ее задание распределяется среди других членов команды.

Agile — Журнал ожидания продукта

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

Почему продуктовый бэклог важен?

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

Характеристики незавершенного производства

• У каждого продукта должно быть одно отставание, которое может иметь набор от больших до очень больших функций.

• Несколько бригад могут работать над одним продуктом.

• Ранжирование функций осуществляется на основе стоимости бизнеса, технической ценности, управления рисками или стратегической пригодности.

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

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

Несколько бригад могут работать над одним продуктом.

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

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

Agile — Полезные условия

Критерии приемки

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

Отставание Уход

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

Вместимость

Это объем работы, который команда может выполнить за одну итерацию.

Особенность

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

итерация

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

инкремент

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

Владелец продукта

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

Резерв продукта

Набор функциональных и нефункциональных требований к продукту.

Элементы журнала невыполненных работ

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

Точки

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

Релиз

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

требование

Спецификация программного продукта для удовлетворения заявленного контракта или функциональности. Пользовательские истории и элементы портфолио являются типами требований.

Очки истории

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

спринт

То же, что итерация.

Timebox

Фиксированная продолжительность времени, в течение которого должен быть разработан результат. Обычно, наряду с фиксированием даты начала и окончания временного ящика, количество ресурсов также является фиксированным.

задача

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

История пользователя

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

Скорость

Мера для взвешивания принятой работы в итерации или временном интервале. Обычно это сумма баллов, принятых в итерации.