Методологии реализующие принципы Agile

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

  OpenUP — это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как лёгкий и гибкий вариант RUP.

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

Преимущества

• Быстрая и постоянная обратная связь команды разработчиков с заказчиком
• Гибкий график реализации функциональности
• Акцент на эргономичность ИТ-системы
• Отсутствие затрат на формализацию процессов и документации
• Возможность остановки проекта без ущерба для осуществленных вложений в разработку ИТ-системы

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

Основные принципы

• Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты
• Работающая программа более важна, чем исчерпывающая документация
• Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта
• Отработка изменений более важна, чем следование планам
• Разработка через тестирование
• быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими.
• Парное программирование
• Открытое рабочее пространство
• Изменение правил по необходимости
• Непрерывная интеграция.
• Рефакторинг.
• Метафора системы вместо архитектуры.
• Каждый член команды несёт ответственность за весь исходный код.
• Стандарт программирования – набор правил, которому должен следовать каждый член команды.
• Сверхурочная работа – признак больших проблем в проекте.
• Использование кода как средства коммуникации.

Схема потока работ в XP

 

Методология Scrum.

Scrum

Скрам Мастер (Scrum Master)

Отвечает за результат.

Интерфейс между менеджментом и командой.

Не раздает задачи.

Участвует в митингах в качестве фасилитатора

Отвечает за соблюдение практик и процесса в команде

Отслеживает прогресс команды при помощи Sprint Backlog.

ScrumMaster может также помогать Product Owner создавать Backlog для команды.

Product Owner

Отвечает за разработку продукта, принятие окончательных решений

Управляет ожиданиями заказчиков и всех заинтересованных лиц

Координирует и приоритизирует Product backlog

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

Отвечает за приемку кода в конце каждой итерации

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

Команда (Team)

Берет на себя обязательства по выполнению объема работ на спринт.

В Scrum вклад отдельных членов проектной команды не оценивается.

Типичные размер команды – 7 плюс минус 2.

Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды.

По окончанию Sprint дола быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели).

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи, которые должны быть выполнены в текущем спринте.

Каждый день производится Daily Scrum: каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?».

По окончанию Sprint'а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность команды в прошедшем Sprint'е, спрогнозировать ожидаемую эффективность в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.

Методология KANBAN.

Канбан

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

Основные принципы

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