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

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

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.

Экстремальное программирование

Одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Основные приёмы XP

  • Короткий цикл обратной связи (Fine-scale feedback)
    • Разработка через тестирование (Test-driven development)
    • Игра в планирование (Planning game)
    • Заказчик всегда рядом (Whole team, Onsite customer)
    • Парное программирование (Pair programming)
  • Непрерывный, а не пакетный процесс
    • Непрерывная интеграция (Continuous integration)
    • Рефакторинг (Design improvement, Refactoring)
    • Частые небольшие релизы (Small releases)
  • Понимание, разделяемое всеми
    • Простота (Simple design)
    • Метафора системы (System metaphor)
    • Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
    • Стандарт кодирования (Coding standard or Coding conventions)
  • Социальная защищённость программиста (Programmer welfare):
    • 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

DSDM

Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) — это главным образом методика разработки программного обеспечения, основанная на концепции быстрой разработки приложений (Rapid Application Development, RAD). В 2007 году DSDM стал основным подходом к управлению проектом и разработки приложений[источник не указан 635 дней].

Принципы

Существует 9 принципов, состоящих из 4 основных и 5 начальных точек.

  • Вовлечение пользователя — это основа ведения эффективного проекта, где разработчики делят с пользователями рабочее пространство и поэтому принимаемые решения будут более точными.
  • Команда должна быть уполномочена принимать важные для проекта решения без согласования с начальством.
  • Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше — это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается на последующей.
  • Главный критерий — как можно более быстрая поставка программного обеспечения, которое удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет потребностям рынка, менее важна, чем решение критических проблем в функционале продукта.
  • Разработка — итеративная и инкрементная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения.
  • Любые изменения во время разработки — обратимы.
  • Требования устанавливаются на высоком уровне прежде, чем начнётся проект.
  • Тестирование интегрировано в жизненный цикл разработки.
  • Взаимодействие и сотрудничество между всеми участниками необходимо для его эффективности.

Scrum

Scrum (от англ. scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.

FDD

Feature driven development (FDD, функционально-ориентированная разработка) — итеративная методология разработки программного обеспечения, одна из гибких методологий разработки (agile). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Используемое в FDD понятие функции или свойства (англ. feature) системы достаточно близко к понятию прецедента использования, используемому в RUP, существенное отличие — это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели». То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций.