Роли участников команды в гибких проектах

Что, если применить Scrum в реальном проекте системной интеграции?

Роли руководителей проектов (PM), руководителей разработки (PL), аналитиков-планировщиков, разработчиков и заказчиков — и как проводить спринты

В предыдущей статье мы рассмотрели такие понятия, как Scrum, эмпирический подход и парная работа, а также 12 принципов Agile.

Как же применить Agile в реальном проекте системной интеграции?

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

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

Поэтому практичный подход — не отказываться полностью от структуры существующего проекта системной интеграции, а встроить в неё сильные стороны Scrum.

В этой статье мы рассмотрим гипотетический проект системной интеграции и на практике разберём, как применить Scrum.

1. Создадим гипотетический проект системной интеграции

Предположим, например, что компания заказала следующий проект.

Название проекта: Внедрение системы управления клиентами нового поколения

Проект рассчитан на шесть месяцев.

Основные функции:

• Вход в систему

• Управление пользователями

• Управление информацией о клиентах

• Управление товарами

• Управление заказами

• Платежи

• Статистика и отчёты

• Система для администраторов

• Интеграция с внешними системами

В традиционном проекте системной интеграции этапы могут выглядеть примерно так:

Анализ → Проектирование → Разработка → Тестирование → Запуск

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

Например, можно проводить спринты продолжительностью две недели.

2. Сначала определим роли в проекте

В Scrum есть три основные роли: Product Owner (владелец продукта), Scrum Master и Developers (разработчики).

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

Поэтому нужно соотнести роли Scrum с уже существующими ролями в проектах системной интеграции так, чтобы это подходило вашей команде.

Например, роли можно распределить следующим образом.

Традиционная роль в проекте системной интеграции	Роль с точки зрения Scrum
Представитель бизнеса со стороны заказчика	Роль Product Owner
PM	Общее управление проектом и координация
PL	Руководство командой разработки и принятие технических решений
Аналитик-планировщик	Упорядочивание требований и поддержка управления бэклогом
Разработчик	Разработчики
QA	Обеспечение качества и тестирование
Scrum Master	Эту роль может выполнять PM или отдельный ответственный сотрудник

Здесь важно, что должности и роли в Scrum не обязательно должны соответствовать друг другу один к одному.

3. Кто должен быть владельцем продукта?

Это один из самых сложных аспектов SI-проекта. Владелец продукта — это не просто человек, который передаёт требования.

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

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

Например, эту роль может взять на себя кто-нибудь из руководителей команды по работе с клиентамисо стороны клиента.

Когда команда разработки спрашивает: «Что нам разработать в первую очередь — функцию A или функцию B?»

владелец продукта должен уметь расставлять приоритеты, например: «Функция A необходима для нашей работы в этом месяце, поэтому, пожалуйста, разработайте её в первую очередь».

4. Создайте бэклог

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

Например:

Бэклог продукта

1. Вход в систему

2. Регистрация

3. Управление пользователями

4. Регистрация клиента

5. Просмотр клиента

6. Редактирование клиента

7. Регистрация товара

8. Просмотр товара

9. Создание заказа

10. Просмотр заказа

11. Оплата

12. Статистика

13. Функции администратора

14. Интеграция с внешними системами

Здесь главное — приоритеты. Не все функции одинаково важны.

Например, если клиент говорит: «Экран статистики тоже важен, но регистрация и просмотр данных клиентов — самые срочные задачи», повысьте приоритет регистрации и просмотра данных клиентов.

5. Проведите планирование спринта

Теперь начнём первый спринт. Предположим, что его длительность составляет две недели.

Для первого спринта команда разработки выбирает следующие функции:

Спринт 1

• Вход в систему

• Регистрация

• Основная информация о пользователе

• Основная структура экранов

Важно отметить, что PM не назначает задачи разработчикам единолично; вместо этого команда сама определяет, какой объём работы она может выполнить за спринт.

Например, PL определяет: «За этот спринт мы должны успеть выполнить вот столько», а команда разработки формирует бэклог спринта.

6. Выполняйте разработку в течение спринта

После начала спринта команда разработки приступает к разработке выбранных функций.

Например

День 1

Настройте среду разработки и базу данных

Дни 2–3

Разработайте API для входа

Дни 4–5

Разработайте экран входа

День 6

Разработайте функцию регистрации

Дни 7–8

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

День 9

Интеграция

День 10

Тестирование и доработки

Можно действовать таким образом.

Важно не просто писать код.

К концу спринта у вас должна быть функция, которая действительно работает.

7. Ежедневный скрам — это не «отчёт о статусе»

Каждый день проводите короткий ежедневный скрам продолжительностью около 10–15 минут.

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

Например, вместо того чтобы разработчик A говорил: «Я разрабатываю функцию входа»,

гораздо важнее сообщить: «API для входа готово, но возникла проблема с интеграцией с внешним сервером аутентификации. Если мы не сможем её решить, это может повлиять на достижение цели спринта».

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

8. Используйте парную работу для сложных функций

Не обязательно работать вдвоём над каждой задачей разработки.

Однако для важных функций можно использовать парную работу.

Например, предположим, что вы разрабатываете функцию оплаты.

Вместо того чтобы разработчик A работал над ней в одиночку,

A + B

работают вместе над проектированием и разработкой.

Один пишет код, а другой одновременно проверяет его. Преимущество такого подхода не ограничивается уменьшением количества ошибок.

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

Например, даже если A уйдёт в отпуск, B сможет разобраться в коде и решать возникающие проблемы.

Особенно эффективно выборочно применять такой подход для следующих функций:

• Платежи

• Безопасность

• Ключевая бизнес-логика

• Сложные SQL-запросы

• Обработка больших объёмов данных

• Интеграция с внешними системами

• Общие модули

9. Покажите заказчикам работающую систему на обзоре спринта

Через две недели спринт заканчивается. На этом этапе важен обзор спринта.

Вместо того чтобы команде разработки показывать документы и объяснять: «Функция входа готова»,

лучше продемонстрировать работающую систему.

Например, предложите представителю заказчика самостоятельно её опробовать:

Зарегистрироваться → Войти → Просмотреть информацию об участнике → Изменить информацию об участнике

Он пробует систему.

В процессе заказчик может сказать: «Мне кажется, это поле не нужно при регистрации».

Или можно сказать: «Наши сотрудники часто используют его именно так, а не через этот экран».

Именно это в Agile называют обратной связью.

10. Что, если требования заказчика изменятся?

Именно здесь становится очевидна разница между традиционным подходом SI и подходом Agile.

Допустим, заказчик просит: «Мы хотели бы изменить макет экрана регистрации».

В традиционном проекте первой может возникнуть проблема: «Требования изменились, и это повлияет на сроки и стоимость».

В Agile сначала зарегистрируйте запрос на изменение в Бэклоге.

Затем Владелец продукта определяет его приоритет.

Например,

запрос на изменение A

Изменить экран регистрации

существующее требование B

функция статистики для администратора,

Владелец продукта может решить, что «изменение экрана регистрации важнее».

Затем в следующем Спринте команда может сначала разработать A и снизить приоритет B.

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

Быть гибкими не значит игнорировать реалии договоров и затрат.

11. Проведите ретроспективу Спринта

После обзора Спринта команда проводит внутреннюю ретроспективу.

Вопросы просты:

Что прошло хорошо?

Например:

Взаимодействие между разработчиками улучшилось.

Что прошло не очень хорошо?

Разработка задержалась, потому что спецификации API были окончательно утверждены с опозданием.

Что нужно изменить в следующем Спринте?

Окончательно утвердить спецификации API до начала Спринта.

Важно внедрить хотя бы одно конкретное улучшение в следующем Спринте.

Если каждая ретроспектива заканчивается словами «В следующий раз постараемся лучше», то Agile теряет смысл.

12. Примените полученные знания во втором Спринте

Во время первого Спринта команда многому учится.

Например:

• Тестирование заняло больше времени, чем ожидалось.

• Требования заказчика отличались от документации.

• Одному разработчику назначили слишком много работы.

• Интеграция с внешними системами заняла много времени.

Команда применяет полученные уроки во втором Спринте.

Это называется эмпиризмом.

Вместо того чтобы с самого начала составлять идеальный план,

попробуйте → оцените результаты → скорректируйте следующий план

.

13. Как управлять шестимесячным проектом?

Например, если в шестимесячном проекте используются двухнедельные спринты, можно провести около 12 спринтов.

В начале проекта

Спринт 0

Среда разработки, архитектура и базовый дизайн

Спринты 1–3

Управление участниками и клиентами

Спринты 4–6

Товары и заказы

Спринты 7–9

Платежи и внешние системы

Спринты 10–11

Статистика и функции администратора

Спринт 12

Интеграционное тестирование и стабилизация

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

14. Роль PM становится ещё важнее

Некоторые считают, что внедрение Agile устраняет необходимость в роли PM.

На самом деле всё наоборот.

В проекте по системной интеграции PM должен управлять

общим графиком + контрактами + затратами + заказчиками + организацией + рисками

...

Особенно в Agile-среде вместо вопроса «Почему всё пошло не по плану?»

нужно определить: «Как с учётом текущей ситуации достичь целей проекта?»

Иными словами, PM не просто управляет графиком, аотвечает за принятие решений в рамках всего проекта и согласование действий заинтересованных сторонв рамках своей роли.

15. PL отвечает за техническое направление команды разработки

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

Особенно в Agile-среде ему необходимо управлять

• техническими решениями

• архитектурой

• качеством кода

• техническими рисками

• взаимодействием между разработчиками

• техническим долгом

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

16. Меняется и роль планировщика

В Agile-проекте роль планировщика может измениться: вместо того чтобы заранее создавать безупречные макеты всех экранов и передавать их разработчикам, он может выполнять другие задачи.

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

Например,

широкое требование «Пожалуйста, создайте систему управления клиентами» можно разбить на такие задачи:

• Зарегистрировать клиента

• Просмотреть список клиентов

• Просмотреть сведения о клиенте

• Изменить данные клиента

• Удалить клиента

• Найти клиентов

• История клиента

Разбейте их на небольшие функции и определите приоритет каждой из них.

17. Меняется и роль разработчика

В традиционной SI разработчики могут легко подумать: «Это экран, за который я отвечаю».

Но в Agile

«Какой цели команда должна достичь в этом спринте?»— именно такой вопрос им следует задавать.

Поэтому необходимо сотрудничество, которое немного выходит за рамки обязанностей каждого разработчика.

Ответственность разработчика за проект не заканчивается только потому, что назначенная ему работа выполнена;

он также может поддержать работу другого разработчика или помочь с тестированием.

Это способ работы, при котором команда важнее отдельного человека.

18. Три главных условия применения Agile в SI

Если бы мне пришлось применять Agile в реальном SI-проекте, я считаю, что наиболее важны были бы следующие три вещи.

Первое: показывайте реальные результаты короткими циклами

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

Анализ → Разработка → Проверка → Обратная связь

Цель — сделать этот цикл как можно короче.

Второе: вовлекайте заказчика в проект

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

Заказчику необходимо постоянно

проводить проверку → использовать → давать обратную связь → определять приоритеты

на протяжении всего проекта.

Третье: внедряйте реальные изменения по итогам ретроспектив

Главное в Agile — не повторение спринтов.

Важно, чтобы команда постоянно совершенствовалась, повторяя спринты.

Поэтому улучшения, выявленные на ретроспективе, действительно следует внедрять в следующем спринте.

Заключение

Применение Agile в SI-проекте не означает, что нужно отказаться от всего, что связано с существующими практиками управления проектами, результатами работ, контрактами и планированием графика.

Практичнее сохранить сильные стороны существующих SI-проектов и объединить их с преимуществами Agile.

Например:

PM

→ Управляет общим графиком проекта, расходами, контрактами и рисками

Владелец продукта

→ Определяет требования и приоритеты заказчика

PL

→ Задаёт техническое направление и управляет командой разработки

Планировщик

→ Разбивает требования на небольшие единицы разработки

Разработчик

→ Сотрудничает с командой для достижения цели спринта

Заказчик

→ Проверяет фактические результаты работ и постоянно предоставляет обратную связь

И весь этот процесс повторяется в следующем цикле.

Бэклог

↓

Планирование спринта

↓

Разработка

↓

Ежедневный Scrum

↓

Работающее ПО

↓

Обзор спринта

↓

Обратная связь от заказчика

↓

Ретроспектива

↓

Улучшение

↓

Следующий спринт

В конечном счёте суть Agile

не в том, чтобы «с самого начала создать идеальный план»,
а в том, чтобы «быстро действовать, учиться на реальных результатах и постоянно совершенствоваться»Вот в чём суть.

Этот подход особенно ценен в SI-проектах, где многое меняется и задействовано множество заинтересованных сторон со сложными интересами.

Luke