Модели разработки ПО vs Методологии разработки ПО
Модель разработки ПО описывает, какие стадии жизненного цикла проходит ПО от начала и до конца и что происходит на каждой из них.
Существует Водопадная модель, V-Модель, Итеративная модель, Спиральная модель и т д
Методология разработки ПО описывает набор методов по управлению разработкой: это правила, техники, принципы, которые делают разработку более эффективной.
То есть методология — это более обширный набор принципов и практик, который определяет способ выполнения каждого этапа разработки.
Самые популярные методологии, которые существуют — это Scrum и Kanban.
Важно отметить, что эти два понятия часто используются совместно и могут быть взаимозависимыми.
Водопадная модель (waterfall model)
Водопадная модель — это один из самых старых и простых способов разработки программного обеспечения.
В ней все похоже на водопад: вода падает сверху вниз, и на каждом этапе что-то происходит.
Требование
Сначала собирают требования, просто спрашивают, что должна делать программа, какие функции в ней должны быть.
Проектирование
Здесь уже решают, как все будет устроено внутри программы. Какие будут кнопки, какие функции они будут выполнять и так далее.
Кодирование
Программисты начинают писать код, который будет выполнять все эти задачи
Тестирование
Проверяют, работает ли все, как надо. Если есть ошибки, их исправляют.
Внедрение
Когда все готово и проверено, программу запускают или устанавливают там, где она будет использоваться.
Поддержка
Если в программе что-то сломается или понадобятся новые функции, их добавляют или исправляют.
Главное в этой модели — каждый этап идет строго один за другим, и начать следующий можно только тогда, когда предыдущий закончен. Тесть мы начинаем тестирование только на этапе тестирования. Это как строительство дома: сначала ложат фундамент, потом стены, потом крышу. Нельзя поставить крышу, если нет стен.
V-Модель
«V» модель — это расширение водопадной модели разработки программного обеспечения.
Она называется «V», потому что процесс разработки тут похож на букву V: сначала идём вниз по одной стороне — это разработка, потом вверх по другой — это тестирование.
Идем вниз по «V» (Разработка)
Собираем требования:
Понимаем, что должна делать программа.
Системное проектирование:
Решаем, как будут взаимодействовать разные части системы.
Архитектурное проектирование:
Разбиваем систему на модули или компоненты.
Детальное проектирование:
Прорабатываем, как каждый модуль будет работать.
Потом Кодирование:
Программисты пишут код для каждого модуля.
Теперь идем вверх по «V» (Тестирование)
Модульное тестирование:
Проверяем, работает ли каждый отдельный модуль правильно.
Интеграционное тестирование:
Смотрим, как модули работают вместе.
Системное тестирование:
Проверяем всю систему в целом.
Приемочное тестирование:
Убеждаемся, что программа делает то, что от неё требовалось изначально.
По сути, каждый этап тестирования связан с определенным этапом разработки. Перед тем как двигаться дальше, мы убеждаемся, что все предыдущие этапы выполнены правильно. Это делает «V» модель более строгой и организованной по сравнению с простой водопадной моделью. Простыми словами,»V» модель помогает не просто сделать программу, но и удостовериться, что она работает так, как нужно, на каждом этапе разработки.
KANBAN
Kanban — это метод управления рабочим процессом, который помогает легко видеть, над чем в данный момент работает команда, что уже готово, и что предстоит сделать.
Обычно всё это отображается на доске, которая разделена на колонки, каждая из которых представляет разный этап работы. Колонки могут быть названы совершенно по разному.
Каждая задача — это карточка, которую мы ставим в первую колонку.
Когда кто-то начинает работать над задачей, он переносит её карточку в колонку «В процессе» как правило
Когда задача выполнена, карточка передвигается в соответствующую колонку. Пример доски ниже:
Чтобы не перегрузить команду, можно установить ограничение на количество задач, которые могут быть в колонке «В процессе». Смысл в том, чтобы задачи постоянно двигались с лева направо, создавая непрерывный поток работы
Важно периодически смотреть на доску, анализировать, как идет работа, и при необходимости что-то менять.
Плюсы:
Простота и наглядность: всё видно на одной доске
Гибкость: легко менять процесс и адаптироваться.
Фокус на текущих задачах: команда сосредоточена на том, чтобы завершить начатое, а не браться за новое.
Минусы:
Канбан не всегда подходит для сложных проектов с зависимыми задачами.
Может создаться иллюзия производительности, если просто перекидывать карточки, не углубляясь в детали.
SCRUM
Scrum является формой гибкой Agile модели разработки и используется для управления проектами и разработки программного обеспечения.
Роли
- Product Owner, что в переводе владелец продукта и он отвечает за определение требований и приоритетов
- Скрам мастер это такой защитник команды разработки, помогает устранять препятствия, решать различные разногласия.
- Команда разработки, обычно 3-9 человек, которые выполняют задачи, у эту команду входит и qa
Артефакты
- Product Backlog: Список всех функций, улучшений и исправлений ошибок, которые должны быть реализованы.
- Sprint Backlog: Список задач, выбранных для выполнения в текущем спринте.
- Цель спринта: Допустим это работающая версия продукта, разрабатываемая в спринте, или работающая версия какой то небольшой функциональности.
Спринт
Планирование спринта (Sprint Planning): В начале каждого спринта команда и Product Owner собираются, чтобы определить задачи для следующего спринта. Задачи с скраме обычно представленные в виде «User Stories».
User Story в переводе обозначает, пользовательская история — это описание функциональной возможности простыми словами, составленное с точки зрения пользователя.
И оцениваем мы такие в задачи в так называемых стори поинтах.
Стори поинт — это условная единица, которая позволяет спрогнозировать объем трудозатрат на выполнение конкретной задачи и придать вес задачам в бэклоге. То есть это оценка не в часах, не в минутах а именно в сторипоинтах. Общее количество сторипоинтов для выбранных задач не должно превышать «спринтовую мощность» команды,
которая обычно рассчитывается на основе исторических данных о производительности.
Что это значит, к примеру на основе опыта, скрам команда выявила, что за 2 недельный спринт они выполняют 30 сторипоинтов, не больше.
И значит при планировании спринта им нужно набрать столько задач, чтобы у них вышло не больше 30 сторипоинтов на все задачи.
Scrum poker
Это интерактивная и часто веселая игра, которая помогает команде договориться о том, насколько трудоемкой или сложной является каждая задача. Это делается для более точного планирования времени и ресурсов.
Как это работает:
У каждого участника есть набор карт с числами. Эти числа обычно следуют определенной последовательности
(например, Фибоначчи: 1, 2, 3, 5, 8, 13, 21 и так далее). Владелец продукта или другой член команды описывает задачу,
которую нужно оценить. Команда обсуждает задачу, задает вопросы и выясняет детали. После обсуждения каждый член команды выбирает карту с числом, которое, по его мнению, отражает сложность задачи. Все показывают свои карты одновременно. Если оценки сильно различаются, проводится дополнительное обсуждение. Те, кто дал наибольшую и наименьшую оценку, объясняют свой выбор. Далее после обсуждения проводится новое голосование. Процесс повторяется, пока команда не придет к консенсусу.
Зачем вообще это нужно:
- Снижение риска ошибок в оценке: Когда все члены команды участвуют в оценке, вероятность учесть все факторы и трудности увеличивается.
- Обмен опытом: Младшие члены команды быстро учатся у более опытных, понимая, как они оценивают сложность задач.
- Командная работа: Это отличный способ улучшить коммуникацию внутри команды и узнать, как другие думают.
Планирование спринта может происходить довольно долго, оно может запросто идти пол дня иди даже весь рабочий день, если вдруг спринт не двух недельный, а скажем месячный. После того как запланировали спринт, у нас идут ежедневные созвоны (их называют Daily Stand-ups или Daily Scrum):
Это краткие ежедневные встречи (обычно 15 минут), на которых команда обсуждает, что было сделано, что планируется сделать и какие препятствия есть. В конце двух недельного спринта спринта команда демонстрирует выполненные задачи на внутренних демках компании и получает обратную связь.
И далее у нас идет завершающая часть спринта — это Ретроспектива спринта (Sprint Retrospective):
команда анализирует, что прошло хорошо, что можно улучшить, и планирует улучшения на следующий спринт, как правило это происходит по пятницам. И в понедельник на следующей неделе стартует следующий спринт с планированием и всеми последующими процессами.
И этот процесс повторяется до тех пор, пока продукт или система не будет завершена или не будет достигнута какая-то другая точка остановки.