Учебники

Гибкая методология

Что такое гибкая методология?

Методология AGILE — это практика, которая способствует непрерывной итерации разработки и тестирования в течение всего жизненного цикла разработки программного обеспечения проекта. Как разработка, так и тестирование выполняются одновременно, в отличие от модели Waterfall

Agile Model & Methodology: руководство для разработчиков и тестировщиков

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

  1. Индивидуальное и командное взаимодействие над процессами и инструментами
  2. Рабочее программное обеспечение над исчерпывающей документацией
  3. Сотрудничество с клиентом в рамках переговоров по контракту
  4. Реагирование на изменения после плана

В этом уроке по разработке программного обеспечения вы узнаете

Agile Vs Waterfall Метод

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

Проворная модель

Модель водопада

  • Agile метод предлагает поэтапный и итеративный подход к разработке программного обеспечения
  • Разработка программного обеспечения проходит последовательно от начальной точки до конечной точки.
  • Проворный процесс разбивается на отдельные модели, дизайнеры работают над
  • Процесс проектирования не разбит на отдельные модели
  • У клиента есть ранние и частые возможности взглянуть на продукт и принять решение и внести изменения в проект.
  • Клиент может увидеть товар только в конце проекта
  • Гибкая модель считается неструктурированной по сравнению с моделью водопада
  • Модель водопада более безопасна, потому что она ориентирована на план
  • Небольшие проекты могут быть реализованы очень быстро. Для крупных проектов сложно оценить время разработки.
  • Все виды проектов могут быть оценены и завершены.
  • Ошибка может быть исправлена ​​в середине проекта.
  • Только в конце тестируется весь продукт. Если обнаружена ошибка требования или необходимо внести какие-либо изменения, проект должен начаться с самого начала.
  • Процесс разработки является итеративным, и проект выполняется в короткие (2-4) недели итерации. Планирование очень меньше.
  • Процесс разработки поэтапный, а фаза намного больше, чем итерация. Каждый этап заканчивается подробным описанием следующего этапа.
  • Документация занимает меньше места, чем разработка программного обеспечения
  • Документация является главным приоритетом и может даже использоваться для обучения персонала и обновления программного обеспечения с другой командой
  • Каждая итерация имеет свою фазу тестирования. Это позволяет проводить регрессионное тестирование каждый раз, когда выпускаются новые функции или логика.
  • Только после этапа разработки этап тестирования выполняется, потому что отдельные части не являются полностью функциональными.
  • В гибком тестировании, когда итерация заканчивается, заказчику предоставляются отправляемые функции продукта. Новые функции можно использовать сразу после отправки. Это полезно, когда у вас есть хороший контакт с клиентами.
  • Все разработанные функции предоставляются сразу после длительного этапа внедрения.
  • Тестеры и разработчики работают вместе
  • Тестеры работают отдельно от разработчиков
  • В конце каждого спринта принимается пользователь
  • Принятие пользователем выполняется в конце проекта.
  • Это требует тесного общения с разработчиками и вместе анализировать требования и планирование
  • Разработчик не вовлекается в требования и процесс планирования. Обычно, задержки между тестами и кодированием

Гибкая методология

В гибком тестировании присутствуют различные методы , и они перечислены ниже:

Scrum

SCRUM — это метод быстрой разработки, который концентрируется именно на том, как управлять задачами в командной среде разработки. В основном, Scrum происходит от активности, которая происходит во время матча по регби. Scrum верит в расширение возможностей команды разработчиков и выступает за работу в небольших группах (скажем, от 7 до 9 человек). Он состоит из трех ролей, и их обязанности объясняются следующим образом:

  • Скрам Мастер
    • Мастер отвечает за настройку команды, спринтерские встречи и устраняет препятствия для прогресса
  • Владелец продукта
    • Владелец продукта создает бэклог продукта, расставляет приоритеты в бэклоге и отвечает за доставку функциональности на каждой итерации
  • Scrum Team
    • Команда управляет своей работой и организует работу для завершения спринта или цикла

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

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

Scrum Practices

Практики описаны подробно:

Ход выполнения методологии Scrum:

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

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

экстремальное программирование (XP)

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

Бизнес-требования собраны с точки зрения истории. Все эти истории хранятся в месте, называемом парковкой.

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

Этапы программирования eXtreme:

В методе Agile XP доступно 6 фаз, которые объясняются следующим образом:

планирование

Анализ

  • Захват историй на парковке
  • Расставьте приоритеты на парковке
  • Очистка историй для оценки
  • Определить итерацию SPAN (время)
  • Планирование ресурсов для команд разработчиков и QA

дизайн

  • Распределение задач
  • Подготовка тестового сценария к каждому заданию
  • Система автоматизации регрессии

выполнение

  • кодирование
  • Модульное тестирование
  • Выполнение сценариев ручного тестирования
  • Генерация отчета о дефектах
  • Преобразование ручного теста в автоматизированный регрессионный тест
  • Обзор средней итерации
  • Конец обзора итерации

Упаковка

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

закрытие

  • Пилот Старт
  • Подготовка
  • Запуск производства
  • SLA Гарантийное обеспечение
  • Обзор стратегии SOA
  • Поддержка производства

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

  • История картона
    • Это традиционный способ сбора всех историй на доске в виде заметок для отслеживания ежедневных действий с XP. Поскольку это ручное занятие требует больше усилий и времени, лучше перейти на онлайн-форму.
  • Онлайн раскадровка
    • Online tool Storyboard can be used to store the stories. Several teams can use it for different purposes.

Crystal Methodologies

Crystal Methodology is based on three concepts

  1. Chartering: Various activities involved in this phase are creating a development team, performing a preliminary feasibility analysis, developing an initial plan and fine-tuning the development methodology
  2. Cyclic delivery: The main development phase consists of two or more delivery cycles, during which the
    1. Team updates and refines the release plan
    2. Implements a subset of the requirements through one or more program test integrate iterations
    3. Integrated product is delivered to real users
    4. Review of the project plan and adopted development methodology
  3. Wrap Up: The activities performed in this phase are deployment into the user environment, post- deployment reviews and reflections are performed.

Dynamic Software Development Method (DSDM)

DSDM is a Rapid Application Development (RAD) approach to software development and provides an agile project delivery framework. The important aspect of DSDM is that the users are required to be involved actively, and the teams are given the power to make decisions. Frequent delivery of product becomes the active focus with DSDM. The techniques used in DSDM are

  1. Time Boxing
  2. MoSCoW Rules
  3. Prototyping

The DSDM project consists of 7 phases

  1. Pre-project
  2. Feasibility Study
  3. Business Study
  4. Functional Model Iteration
  5. Design and build Iteration
  6. Implementation
  7. Post-project

Feature Driven Development (FDD)

This method is focused around «designing & building» features. Unlike other agile methods, FDD describes very specific and short phases of work that has to be accomplished separately per feature. It includes domain walkthrough, design inspection, promote to build, code inspection and design. FDD develops product keeping following things in the target

  1. Domain object Modeling
  2. Development by feature
  3. Component/ Class Ownership
  4. Feature Teams
  5. Inspections
  6. Configuration Management
  7. Regular Builds
  8. Visibility of progress and results

Lean Software Development

Lean software development method is based on the principle «Just in time production». It aims at increasing speed of software development and decreasing cost. Lean development can be summarized in seven steps.

  1. Eliminating Waste
  2. Amplifying learning
  3. Отложить обязательство (принять решение как можно позже)
  4. Ранняя доставка
  5. Расширение возможностей команды
  6. Строительная целостность
  7. Оптимизировать весь

Kanban

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

Скрам против Канбан

Scrum

Kanban

  • В технике схватки тест должен быть разбит так, чтобы он мог быть выполнен в течение одного спринта
  • Никакого конкретного размера товара не предписано
  • Предписывает приоритетное отставание продукта
  • Расстановка приоритетов не обязательна
  • Scrum команда выполняет определенный объем работы для итерации
  • Обязательство не является обязательным
  • Таблица выписки выписывается
  • Никакого конкретного размера товара не предписано
  • Между каждым спринтом сбрасывается доска схваток
  • Канбан доска является постоянной. Ограничивает количество элементов в состоянии рабочего процесса
  • Он не может добавлять элементы в текущую итерацию
  • Он может добавлять предметы, когда есть возможность
  • WIP ограничен косвенно
  • WIP ограничен напрямую
  • Предписанные итерации
  • Timeboxed итерации необязательно

Agile метрики:

Метрики, которые можно собрать для эффективного использования Agile:

  • Drag Factor
    • Усилия в часах, которые не способствуют цели спринта
    • Коэффициент перетаскивания можно улучшить, сократив количество общих ресурсов, сократив объем незавершенной работы.
    • Новые оценки могут быть увеличены на процент коэффициента сопротивления -Новая оценка = (Старая оценка + коэффициент сопротивления)
  • Скорость
    • Количество невыполненных заданий (пользовательских историй), преобразованных в отправляемую функциональность спринта
  • Количество юнит-тестов добавлено
  • Интервал времени, необходимый для завершения ежедневной сборки
  • Ошибки, обнаруженные в итерации или в предыдущих итерациях
  • Утечка производственных дефектов