Методы и модели разработки ПО

• Что такое методологии разработки программного обеспечения

• Эволюция методологий разработки ПО

• Классические методологии разработки
    Водопадная модель (Waterfall)
    Итеративная модель
    Спиральная модель
    Рациональный унифицированный процесс (Rational Unified Process)
    Быстрая разработка (RAD)

• Гибкие и современные методологии
    Agile и его вариации: Scrum, Kanban, XP
    Бережливая разработка (Lean)
    Создание ПО на основе функций (Feature-Driven Development, FDD)
    DevOps и CI/CD
    Прототипирование (Prototype model)

• Преимущества и недостатки разных подходов

• Сравнение методологий разработки ПО

• Как выбрать методологию разработки для проекта

• Практика внедрения методологий в компании

• Ошибки при переходе и как их избежать

• Как сочетать несколько методологий (гибридные подходы)

• Будущее методологий разработки ПО

• Подведем итог

Методология разработки ПО — набор правил, этапов, ролей и задач для управления процессом создания информационной системы. Термин связан с понятием жизненного цикла программного обеспечения. Жизненный цикл описывает, что нужно сделать при создании системы (этапы от планирования до вывода из эксплуатации). Методология отвечает на вопрос, как это будет сделано.

Модели, описывающие этапы создания программного обеспечения, появились в 1950–1960-е гг. В конце 1950-х сформировалось представление о программе как иерархической структуре блоков кода. Разработка осуществляется пошагово, методом «сверху вниз».

ПО становилось сложнее: писать код было недостаточно. Нужно тестировать, доставлять, поддерживать. В 1970–1980-х возникли классические методологии с линейным процессом работы, разбитым на этапы, которые следуют друг за другом.

С начала 1990-х гг. развиваются гибкие подходы: экстремальное программирование, Канбан, фреймворк Scrum.

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

Последовательные (линейные) модели считаются базовыми, но идеалистическими. Пик их популярности пришелся на 1990–е годы. Жизненный цикл ПО делится на фазы, и выход из одной означает переход на следующую.

Каскад / каскадная (водопад / водопадная, последовательная модель) — линейный подход, при котором создание продукта подразумевает идущие друг за другом этапы:

• уточнение требований;

• проектирование;

• реализация;

• тестирование;

• интеграция;

• техподдержка.

Движение возможно только вперед — к следующему этапу. Назад возвращаться нельзя.

В чистом виде подход не используется активно и повсеместно. Причин несколько:

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

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

Каскадная модель формально закреплена в третьем издании «Свода знаний по управлению проектами» (PMBoK, Project Management Body of Knowledge). Стандарт разработан Институтом управления проектами PMI, содержит информацию о процессах, ролях, структурах, терминах в области проектного менеджмента. «Свод знаний» используется для подготовки и сертификации менеджеров по проектам (Project Management Professional / PMP от PMI).

Первые редакции «Свода знаний» подробно описывали только водопадную модель. Позже добавили гибкие Agile-методологии.

Итерационная методика (каскадная модель с обратными связями) — подход, когда разработка ведется в фазах (итерациях). Каждый цикл включает определенные этапы: планирование, написание кода, тестирование, корректировка. Модель подразумевает пути обратной связи: они позволяют вернуться к фазе, где были допущены ошибки и переработать ее. Внесенные изменения отразятся на более поздних фазах. Методику связывают с принципом Деминга — Шухарта «План — Реализация — Проверка — Изменения» (PDCA, plan-do-check-act).

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

Спираль (метамодель) — подход к разработке, сочетающий итеративность и этапность. Концепцию впервые описал инженер-программист Барри Боэм (Barry Boehm) в 1986 г.

Команда оценивает риски на старте. Затем рабочий процесс происходит в рамках итераций:

• постановки целей;

• оценки альтернативы, уточнения рисков;

• реализации (разработка и верификация);

• планирования следующего цикла.

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

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

Стадии в RUP-методологии отличаются от фаз каскадной модели:

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

2. Проектирование. Занимает до 2–3 итераций, в рамках которых создается основа архитектуры. Отличие от каскадной модели в том, что по результатам проектирования получают действующую систему с 20–30% реализации.

3. Построение. Состоит из 2–4 итераций, в рамках которых пишется большая часть исходного кода, а также создаются демопрототипы.

4. Внедрение. Подразумевает 1–3 итерации для бета-тестирования, обучения пользователей.

Методология ориентирована на архитектуру проекта.

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

Альтернативное название концепции — Rapid Application Building (RAB). Консультант по разработке Джеймс Мартин (James Martin) в 1991 г. описал четыре фазы:

1. Планирование. Обсуждение задач проекта, сложности, сроков.

2. Проектирование. Создание прототипов с нужными функциями. Для перехода к рабочим прототипам используют CASE-инструменты и JAD-техники.

3. Конструирование. Аналогом выступает стадия реализации в жизненном цикле программного обеспечения. На этой стадии разрабатывают продукт и выполняют системное тестирование.

4. Переключение. Внедрение, тестирование, обучение пользователей.

Гибкие (Agile) методологии и приемы созданы на основе 12 принципов и 4 ключевых идей манифеста разработки ПО. Документ опубликован в 2001 г., доступен на 50+ языках мира, в том числе на русском.

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

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

• экстремальное программирование;

• Канбан (Kanban);

• метод разработки динамических систем;

• гибкая методология Scrum с поэтапной разработкой спринтами;

• разработка на основе функциональности;

• методология чистой комнаты;

• разработка через поведение системы;

• итеративно-инкрементальный метод;

• методология адаптивной разработки;

• кристальная чистота;

• бережливая разработка.

Фреймворк гибкой разработки (Scrum) подразумевает работу спринтами (временными промежутками) по 2–4 недели. После завершения стадии проводят ретроспективу (встречу, на которой обсуждают результаты и планируют следующий этап).

Kanban — метод управления процессами, подразумевающий визуализацию целей, задач и прогресса. Команда разработчиков использует специальный инструмент — Kanban-доску. Она отображает этап, на котором находится задача (карточка): например, «Планируется», «В процессе» и «Готово».

Экстремальное программирование (Extreme Programming, XP) — гибкая методология, при которой стандартные приемы программирования используют по максимуму. Термин взят из математики, где экстремум (лат. extremum) функции — это крайние минимальные или максимальные значения. Автором методики считается разработчик Кент Бек (Kent Beck). Принципами экстремального программирования называют:

• переработка и улучшение (рефакторинг);

• непрерывная интеграция (CI);

• разработка через тестирование (TDD);

• коллективное владение кодом/паттернами и др.

Экстремальное программирование отличается от Kanban, Scrumban, Scrum и иных гибких методик тем, что ориентировано только на сферу разработки ПО и цифровых систем. Если практики и методы Канбана можно перенести в маркетинг, производство, менеджмент и иные сферы, то с XP так не получится. Экстремальное программирование изначально создавалось для сферы разработки, и его принципы сложно внедрить в других подразделениях организации (бухгалтерия, маркетинг и продажи, менеджмент).

Гибкий подход направлен на снижение потерь и повышение эффективности при минимальных затратах. Методика пришла из промышленности.

В 1990-е аналитики Мэри и Том Поппендик (Poppendieck) адаптировали концепцию для работы с программным обеспечением. Эксперты представили семь принципов бережливого производства для сферы программного обеспечения:

• оптимизация процесса;

• устранение потерь;

• ускорение доставки;

• создание целостности;

• задействование команды;

• углубление обучения;

• повышение качества.

Подход подразумевает использование в работе инструментов, среди которых Kanban-доски, всеобщий уход за оборудованием (TPM, Total Productive Maintenance), точно в срок (JIT, Just in Time).

Разработка, управляемая функциональностью — итеративная методика с фокусом на функциональность продукта, основанная на использовании лучших практик создания программного обеспечения. Среди них:

• единоличное владение классом или фрагментом кода;

• регулярные сборки приложения;

• разработка по функциональности/функциям;

• моделирование объектов предметной области;

• функциональные команды;

• инспекции;

• управление конфигурацией;

• отчетность/видимость результатов.

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

DevOps — культура и подход, объединяющие разработку (Dev) и эксплуатацию (Ops). Позже появился DevSecOps — методика непрерывной разработки с учетом требований безопасности.

В рамках DevOps существуют практики:

• инфраструктура как код (Infrastructure-as-Code, IaC);

• мониторинг и наблюдаемость;

• управление инцидентами и SRE-подход;

• непрерывная интеграция и поставка/доставка (CI/CD).

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

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

Плюсы классической модели:

• последовательное исполнение фаз;

• формирование привычки «определись, потом делай»;

• четкость и определенность этапов.

Минусы:

• отсутствие обратной связи;

• проблемы с запросами на изменение;

• отсутствие перекрытия между фазами.

Преимущества Agile-концепции:

• адаптивность, гибкость, быстрая реакция на изменение требований;

• прозрачность этапов и взаимоотношений в команде;

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

Минусы:

• усложнение адаптации и обучения новых сотрудников;

• фокус команды на мелких задачах (части функциональности), сложно увидеть всю архитектуру проекта;

• сложность управления бюджетом продукта;

• затраты на переход с классических моделей.

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

Чтобы найти систему для работы команды, стоит учитывать:

• Специфику проекта. Стартапам подходят гибкие методологии. Гибкие решения используют при разработке SaaS, веб- и мобильных приложений. Для разработки промышленных систем выбирают Lean или Six Sigma.

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

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

• Характер требований. Если они фиксированные и стабильные (не изменяются), подходят классические методологии. Когда условия неопределенные (изменчивые), лучше сработают гибкие методы.

Опыт крупных компаний показывает, что комплексная Agile-трансформация коллектива может занимать около полутора лет. Существуют фреймворки и платформенные решения, которые позволяют сократить и ускорить этот процесс. Например, инструменты в составе Platform V Works помогают упростить и ускорить внедрение гибких методологий в разработку – управлять сроками, ресурсами, ускорять цикл создания продуктов и оптимизировать ресурсы на разработку.. Также доступны отдельные компоненты (продукты) в рамках портфелей СберТеха: «Инструменты разработки», «Работа с данными», «Кибербезопасность» и другие.

Пошаговый план внедрения новой методологии

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

Цикл Деминга (PDCA-цикл) описывает такой процесс внедрения:

1. Plan (планирование).

2. Do (исполнение).

3. Check (проверка).

4. Act (корректировка).

Shu-Ha-Ri-подход (Сюхари) к освоению новой технологии подразумевает три стадии:

Этап 1. Shu — изучение.

Этап 2. Ha — адаптация под задачи бизнеса или условия рынка.

Этап 3. Ri — осознанное отступления от традиции (к примеру, переход со Scrum на Scrumban).

Сроки внедрения и конкретные шаги зависят от специфики проекта. В

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

• Отсутствие измеримой цели. Оценить эффективность внедрения методологии можно при помощи метрик, заданных на старте. Например, когда задача звучит как «Ускорить выпуск новых продуктов на 7%» или «Снизить совокупную стоимость владения на 10%».

• Попытка одномоментного перехода «с завтрашнего дня». Agile — это постепенное изменение (эволюция), а не революция. Важно определить процессы и этапы трансформации.

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

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

• Scrum + Kanban = Scrumban;

• Waterfall + Scrum = Scrumerfall (Water-Scrum-Fall);

• PRINCE2 + Agile = PRINCE2Agile.

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

Методы разработки программного обеспечения не существуют сами по себе, а взаимосвязаны с ИТ-рынком, технологическими инструментами, экономическими вызовами и требованиями бизнеса. По данным Gartner, среди трендов на ближайшее будущее — превентивная кибербезопасность (Preemptive Cybersecurity), геопатриация (Geopatriation) и внедрение ИИ.

Методики дополняются фазами безопасности и отчетности, а команды, использующие искусственный интеллект, переходят к гибким процессам с быстрой обратной связью. Внедрение ИИ приводит к появлению новых ролей: AI-инженер процессов или DevEx- / DeVX- / DX-менеджер.

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