Из этой статьи вы узнаете об основных широко используемых методология разработки программного обеспечения типа Waterfall и Agile (Scrum, Kanban) и познакомитесь с их основными ролями, артефактами и процессами.
-
Системный аналитик. Краткий гайд по профессии. Часть 1. Основы взаимодействия систем.
-
Системный аналитик. Краткий гайд по профессии. Часть 2. Сбор, анализ и документирование требований.
-
Системный аналитик. Краткий гайд по профессии. Часть 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‑канале: Записки системного аналитика
ссылка на оригинал статьи https://habr.com/ru/articles/845032/
Добавить комментарий