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

Введение: Хаос vs Система

Представьте, что вам нужно построить дом. Можно просто нанять рабочих, купить материалы и начать “от печки”. Скорее всего, получится криво, окна будут разного размера, а крыша провалится.

Методология разработки — это четкий план и свод правил, как именно команда будет строить этот “дом” (программный продукт). Это ответы на вопросы:

• Когда мы начнем программировать?
• Как часто мы показываем результат заказчику?
• Что делать, если заказчик передумал в середине процесса?

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

Каскадная модель (Waterfall) — “Все по порядку”

Это самая старая и прямолинейная методология. Пришла из строительства и производства.

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

Проект делится на последовательные фазы. Начинать следующую фазу нельзя, пока не закончена предыдущая. Если потребуются изменения где-то в середине проекта, после его начала, будет ооочень затратно вносить правки.

1. Анализ требований: Сидим с заказчиком, выясняем ДО КОПЕЙКИ, что ему нужно. Подписываем документ (ТЗ — техническое задание). Кровью и потом =).
2. Проектирование: Архитекторы рисуют чертежи всей системы целиком (описывают ADR, проектируют C4-диаграммы и тд).
3. Разработка (кодирование): Программисты пишут код. Ничего не меняем, все уже утверждено.
4. Тестирование: Ищем ошибки.
5. Внедрение и сопровождение: Отдаем готовый продукт заказчику.

Плюсы

• Все понятно: Есть толстый документ, где написано, что мы делаем.
• Стабильность: Вы точно знаете свою задачу на месяцы вперед.
• Предсказуемость: Легко назвать точную дату сдачи и бюджет (если требования не поменяются).

Минусы

• Гибрид слона и Мерседеса: Заказчик видит продукт только в самом конце. Если он думал, что хочет “Мерседес”, а на деле ему нужен был “трактор”, будет поздно. Переделывать — значит начинать все заново.
• Риски: Ошибка, заложенная на этапе анализа, “всплывет” только на этапе тестирования, когда потрачены все деньги.

Для СА: Ваша задача — написать идеальное ТЗ, предусмотреть все. Работа огромная и ответственная.

Гибкие методологии (Agile) — “Давайте итерациями”

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

Agile — это не одна методология, а целое семейство. Самые популярные — Scrum и Kanban.

Scrum — “Бежим спринтами”

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

Основные термины

• Спринт (Sprint): Это фиксированный отрезок времени (обычно 1-4 недели), за который команда делает кусочек работающего продукта. Спринты идут друг за другом без перерыва.
• Бэклог продукта (Product Backlog): Это список всех “хотелок” заказчика. Приоритетный список задач. Общий список.
• Бэклог спринта (Sprint Backlog): Те задачи из общего списка, которые команда ОБЯЗУЕТСЯ сделать за текущий спринт.
• User Story (Пользовательская история): Это задача, сформулированная языком пользователя. “Я как ученик хочу скачать конспект, чтобы учиться офлайн”. Аналитик помогает правильно формулировать эти истории.
• Инкремент: То, что получилось в конце спринта — работающая фича.

Роли в Scrum

• Владелец продукта (Product Owner): Голос заказчика внутри команды. Он решает, что важно делать сейчас, а что потом. Формирует бэклог.
• Scrum-мастер: Тренер команды. Следит, чтобы все соблюдали правила Scrum, помогает убирать препятствия. Не начальник, а скорее лидер в команде.
• Команда разработки: Те, кто делают продукт (аналитики, дизайнеры, программисты, тестировщики). Команда самоорганизуется и сама решает, КАК делать.

События (Встречи)

1. Планирование спринта: Команда берет задачи из верха бэклога (по приоритету) и решает: “Осилим ли мы это за 2 недели”.
2. Ежедневный дейлик (Daily): Встреча на 15-30 минут. Может проводиться как каждый день, так и по договоренностям внутри команды (например, по пн, ср, пт). Каждый говорит: “Что сделал вчера? Что будет делать сегодня? Что мне мешает, какие блокеры/проблемы?”
3. Обзор спринта (Review): В конце спринта команда показывает Владельцу продукта (и заказчику), что получилось. Демонстрация работающей фичи!
4. Ретроспектива: Самая важная встреча для улучшения. Команда обсуждает, что было хорошо в прошедшем спринте, а что надо изменить в процессах.

Для СА: Вы — полноценный член команды. Вы пишете User Stories (их могут писать как БА, так и РО, все зависит от компании/продукта/проекта), уточняете детали у заказчика (Владельца продукта/РО) прямо во время спринта, помогаете тестировщикам проверять, сделано ли все по требованиям.

Kanban — “Делаем дела, но не перегружаемся”

Kanban пришел с заводов Toyota. Представьте доску, разделенную на столбцы: “Надо сделать”, “В работе”, “На проверке”, “Готово”.

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

• Визуализация: Все задачи — это стикеры на доске. Видно, у кого завал, а кто свободен.
• Лимит незавершенной работы (WIP — Work in Progress): Главное правило. В столбце “В работе” может быть не больше 3-х задач. Пока не доделаешь старую, новую брать нельзя. Это помогает не распыляться и доводить дела до конца.

Чем отличается от Scrum

В Kanban нет спринтов. Задачи появляются постоянно, и поток задач непрерывен. Как только задача сделана, команда берет следующую из очереди.

Для СА: Удобно для команд поддержки или когда приходит много мелких, срочных, но разных задач. Ваша задача — четко формулировать требования по каждой входящей задаче, чтобы разработчик мог сразу взять ее в работу.

SAFe (Scaled Agile Framework) — “Agile для гигантов”

Scrum и Kanban отлично работают для одной команды (до 9 человек). А если у вас продукт делают 500 человек в разных странах? Начинается хаос.

SAFe — это набор знаний о том, как “масштабировать” Agile, то есть наладить взаимодействие между множеством Agile-команд, чтобы они не мешали, а помогали друг другу.

Ключевые понятия SAFe

• ART (Agile Release Train) — Поезд релиза: Это основная единица. Представьте поезд, в котором едут несколько вагонов (команд). Все вагоны привязаны к одному расписанию. ART — это команда команд (50-125 человек), которая движется к общей цели.
• PI (Program Increment) — Инкремент программы: Это как “супер-спринт” длиной 8-12 недель. В начале PI проводится большая встреча (PI Planning), куда собираются представители ВСЕХ команд, чтобы синхронизировать планы и понять, как их части продукта будут стыковаться друг с другом.

Для СА: В SAFe роль аналитика усложняется. Вам нужно договариваться не только со своим заказчиком, но и с аналитиками из смежных команд, чтобы “стыки” между модулями системы были описаны и понятны всем.

Сравнительная таблица: Waterfall vs Agile (Scrum)

Резюме для системного аналитика

Ваш подход к работе напрямую зависит от методологии:

1. Если у вас Waterfall: Пишите ТЗ. Подробно, с экранными формами, бизнес-процессами. Подписывайте и забывайте (до сдачи).
2. Если у вас Scrum: Живите спринтами. Пишите User Stories, участвуйте в ежедневных стендапах (чтобы слышать, какие вопросы возникают у разработчиков), на ревью смотрите, соответствует ли результат вашим ожиданиям, на ретроспективе предлагайте, как улучшить процесс написания требований.
3. Если у вас Kanban: Приводите в порядок поток задач. Дробите задачи так, чтобы они проходили через Kanban-доску максимально быстро.
4. Если у вас SAFe: Готовьтесь к планеркам PI. Ваша задача — синхронизировать свой бэклог с бэклогами других команд до начала большого инкремента.