Конспект

YouTubeМетодологии и модели разработки ПО. Scrum, Kanban, Agile, Водопадная модель, V-model

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

Ключевые тезисы

  • Модель разработки описывает стадии жизненного цикла ПО от начала до конца.
  • Методология разработки — это набор правил, техник и принципов для управления разработкой, делающий процесс более эффективным.
  • Методологии (Scrum, Kanban) и модели (водопадная, V-модель) часто используются совместно.

Разница между моделью и методологией

  • Модель разработки ПО — описывает, какие стадии проходит ПО и что происходит на каждой из них (например, водопадная, V-модель, итеративная).
  • Методология разработки ПО — более обширный набор принципов и практик, определяющих способы выполнения каждого этапа. Сосредоточена на процессе в целом, включая управление проектом и коммуникацию.

Водопадная модель

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

Этапы модели:

  1. Сбор требований — определение того, что должна делать программа.
  2. Проектирование — решение, как всё будет устроено внутри.
  3. Кодирование — написание кода.
  4. Тестирование — проверка работы и исправление ошибок.
  5. Внедрение — запуск готовой программы.
  6. Поддержка — исправление сбоев и добавление новых функций.

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

Недостаток: Негибкость. При необходимости изменений в середине процесса приходится возвращаться на несколько этапов назад.

V-модель

Расширение водопадной модели, где процесс похож на букву V: вниз — разработка, вверх — тестирование.

Путь вниз (разработка):

  1. Сбор требований.
  2. Системное проектирование (взаимодействие частей системы).
  3. Архитектурное проектирование (разбиение на модули).
  4. Детальное проектирование (проработка модулей).
  5. Кодирование.

Путь вверх (тестирование):

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

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

Методология Kanban

Метод управления рабочим процессом с помощью визуализации на доске.

Как работает:

  • Рабочий процесс отображается на доске, разделённой на колонки (например, «Сделать», «В процессе», «Готово»).
  • Каждая задача — это карточка, которая перемещается по колонкам слева направо.
  • Можно устанавливать ограничения на количество задач в колонке «В процессе», чтобы не перегружать команду.

Плюсы:

  • Простота и наглядность.
  • Гибкость, легко менять процесс.
  • Фокус на завершении текущих задач.

Минусы:

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

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

Гибкая (Agile) методология для управления проектами и разработки ПО.

Роли в Scrum:

  • Владелец продукта (Product Owner) — определяет требования и приоритеты.
  • Scrum-мастер — помогает команде, устраняет препятствия (на практике эту роль часто выполняет техлид или владелец продукта).
  • Команда разработки — 3-9 человек (разработчики, дизайнер и др.), которые выполняют задачи.

Ключевые артефакты:

  • Product Backlog — общий список всех функций, улучшений и исправлений.
  • Sprint Backlog — список задач, выбранных для выполнения в текущем спринте.
  • Работающая версия продукта — инкремент функциональности, созданный за спринт.

Процесс в спринте (итерации, обычно 2 недели):

  1. Планирование спринта: Команда выбирает задачи из Product Backlog в Sprint Backlog. Задачи оцениваются в стори-поинтах (story points) — условных единицах сложности, а не во времени. Объём задач не должен превышать спринтовую мощность команды (например, 30 стори-поинтов за спринт).
  2. Scrum покер: Техника оценки задач. Каждый участник команды анонимно выбирает карту с числом (часто из последовательности Фибоначчи), отражающую сложность задачи. При большом разбросе оценок проводится обсуждение и повторное голосование до достижения консенсуса.
    • Цели: снижение ошибок в оценке, обмен опытом, улучшение командной коммуникации.
  3. Ежедневные стендапы (Daily Scrum): Краткие 15-минутные встречи для обсуждения: что сделано, что планируется, какие есть препятствия.
  4. Демонстрация результата: В конце спринта команда показывает выполненную работу и получает обратную связь.
  5. Ретроспектива: Анализ того, что прошло хорошо, что можно улучшить, и планирование улучшений на следующий спринт.