Учебники

Agile — Primer

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

Agile Vs Традиционный SDLC

Роли в 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 часов.
  • Истории проверяются с использованием приемочных тестов.

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

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

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

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

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

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

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

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