Из этой статьи вы узнаете об основных широко используемых методология разработки программного обеспечения типа Waterfall и Agile (Scrum, Kanban) и познакомитесь с их основными ролями, артефактами и процессами.

Системный аналитик. Краткий гайд по профессии. Часть 1. Основы взаимодействия систем.
Системный аналитик. Краткий гайд по профессии. Часть 2. Сбор, анализ и документирование требований.
Системный аналитик. Краткий гайд по профессии. Часть 3. Архитектура приложений и их масштабирование, CAP-теорема и изоляция транзакций.
Системный аналитик. Краткий гайд по профессии. Часть 4. Синхронные и асинхронные интеграции. REST, gRPC, Kafka, RabbitMQ, WebSocket.
Системный аналитик. Краткий гайд по профессии. Часть 5. Методологии разработки. Waterfall и Agile.

Данный текст является обзорной статьей и ориентирован на новичков в IT‑индустрии, предназначен для желающих познакомиться с профессией, узнать о ее содержании, основных принципах, практиках и инструментах, используемых в ней.

Проектный подход. Waterfall

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

Waterfall (водопад/каскадная модель) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

Как правило, водопадная модель применяется в командах, работающих в парадигме проектного подхода.

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

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

Минусы: Вместе с тем ее недостатками является отсутствие гибкости к изменениям, из‑за чего следуют высокие риски — возникновение ошибок на последних этапах может привести к срыву сроков или увеличению бюджета на разработку.

Гибкие методологии. Agile

Agile — это семейство гибких методологий управления проектами. К Agile относят основные фреймворки: Scrum, Kanban, Lean, LeSS, SAFe.

Суть Agile содержится в четырёх пунктах его манифеста:

Люди и их взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с клиентами важнее условий контракта.
Реагирование на изменения важнее следования плану.

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

Основными недостатками являются сложности планирования сроков разработки и бюджета.

Scrum

При Scrum продукт разрабатывается не разом, а по частям — каждая из них реализуется в рамках спринта.

Scrum Guide чётко описывает состав команды, который необходим для разработки продукта. У каждого участника — своя роль, каждый отвечает за свою часть работы, чтобы эффективно закрывать потребности бизнеса.

В Scrum‑команду входят: Product Owner (владелец продукта), Scrum Master (скрам‑мастер), Development team (команда разработки).

Product Owner — человек, который отвечает за продукт в целом. Он следит за тем, как будет развиваться продукт, расставляет приоритеты, следит за сроками, коммуницирует со стейкхолдерами.

Scrum Master — человек, который отвечает за соблюдение принципов Scrum в команде, помогает поддерживать рабочий процесс.

Development team — группа людей (как правило, до 10 человек), которая занимается разработкой продукта, например: дизайнеры, системные аналитики, разработчики и инженеры по тестированию.

Атрибуты команды, которая работает по Scrum:

Бэклог продукта — упорядоченный список задач, который ведет и обновляет Product Owner.
Инкремент продукта — законченная часть продукта, которая закрывает потребность пользователя.
Спринт — это временной интервал (как правило, две недели), в течение которого идёт разработка функционала продукта.
Бэклог спринта — упорядоченный список задач, которые запланированы на текущий спринт.
Доска разработки — визуальное отображение задач команды разработки в текущем спринте со статусами (как правило: Бэклог, В работе, Тестирование, Готово).

Scrum-команда регулярно участвует в нескольких активностях:

Работа с бэклогом продукта и планирование спринта — команде необходимо определиться с целью спринта и выбрать из бэклога продукта задачи, которые нужно взять на ближайший спринт. Перед этим, необходимо оценить все задачи и отсортировать их по приоритету. Самые важные нужно брать в первую очередь.
Дейли (daily — ежедневный) — в течение спринта команда собирается на ежедневные встречи — дейли. На этих встречах участники команды делятся результатами своей работы, рассказывают о проблемах, с которыми столкнулись.
Груминг (groom — причесывать) он же product backlog refinement (PBR, уточнение бэклога) — в течение спринта команда собирается и обсуждает существующие или вновь возникшие задачи.
Демонстрация (демо) — команда демонстрирует результаты своей работы пользователям или заказчикам. Так она получает обратную связь. (Обычно делается по окончании спринта, но зачастую в реальности — перед тем, как выводить какую‑либо функциональность на стадию тестирования).
Ретроспектива (ретро) — перед тем как начать новый спринт, команда проводит ретроспективу. Ретроспектива — это мероприятие, на котором вся команда обсуждает положительные и отрицательные моменты совместной работы во время предыдущего спринта.

В Scrum существуют два типа критериев к задачам:

Definition of Ready — критерий готовности задачи, чтобы ее можно было взять из бэклога в спринт, как правило это наличие описания задачи и ее зависимостей, определенный приоритет задачи и оцененная трудоемкость.
Definition of Done — список критериев, по которым команда определяет успешное выполнение задачи.

Kanban

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

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

Главным инструментов в работе Kanban команды является Kanban‑доска, состоящая из столбцов со статусами, как правило: To Do (планируется) — In Progress (в работе) — In QA (в тестировании) — Done (сделано).

В Kanban также можно следить за приоритетами задач, и использовать для этого шкалу:

Low (низкоприоритетная задача, как правило не оказывают влияния на продукт).
Medium (запланированные задачи, которые влияют на продукт).
High (влияющие на продукт задачи, которые необходимо сделать в первую очередь).
Blocker (влияющие на продукт задачи, блокирующие параллельно идущие или последующие работы).

Основное отличие Kanban от Scrum заключается в следующем:

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

Итак, в Agile‑команде рабочий процесс системного аналитика в большинстве случаев выглядит примерно так:

cобрали требования;
описали требования (бизнес‑требования, функциональные и нефункциональные требования);
согласовали с заинтересованными сторонами (стейкхолдерами);
спроектировали HLD (high‑level design);
обсудили с командой;
спроектировали LLD (solution‑архитектуру, интеграции);
обсудили с командой — декомпозировали задачи и оценили сроки;
передали в разработку — поучаствовали в тестировании и приемке результатов.

Матрица ответственности

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

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

Термин RACI является аббревиатурой:

R — Responsible (исполняет);
A — Accountable (отвечает);
C — Consult before doing (консультирует);
I — Inform after doing (информируется).

В каждой процедуре каждой роли должен быть присвоен тот или иной литер, при этом Accountable — должен быть только один, Responsible — должен быть в наличии по каждой процедуре, каждая процедура обязательно должна иметь Accountable и Responsible.

Из этой статьи вы узнали об основных широко используемых методология разработки программного обеспечения типа Waterfall и Agile (Scrum, Kanban) и познакомились с их основными ролями, артефактами и процессами.

Эта статья является заключительной в серии об основах профессии системного аналитика.

Надеюсь, что было полезно и вы смогли почерпнуть для себя что‑то новое, а может быть даже сделать выбор в сторону этой профессии.

Эту и другие статьи по системному анализу и IT‑архитектуре, вы сможете найти в моем небольшом уютном Telegram‑канале: Записки системного аналитика

Системный аналитик. Краткий гайд по профессии. Часть 5. Методологии разработки. Waterfall и Agile