Гибкое управление проектами и продуктами

• проработать архитектуру на высоком уровне.

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

Пропасть между анализом и архитектурой

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

Диаграмма последовательности

Стратегия актуализации документации

Если рассматривать проектную документацию, в том числе требования, с позиций бережливого производства, то она является мудой – потерей при производстве (подробнее потери при производстве описаны в гл. 11). Аналогичный принцип действует и в гибких методологиях: прогресс измеряется не по документации, а по конечному продукту, который является ценностью для заказчика.

Фактически аналитик должен выбрать одну из трех стратегий актуализации требований.

Стратегии обновления требований

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

Наталья Лукьянчикова, аналитик

Если документация не обновляется полностью, с какого-то момента начинают накапливаться различия между моделью (требованиями) и кодом.

Рост количества различий между моделью и кодом

Роль аналитика в Scrum

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

Место аналитики в Scrum

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

Преимущества и недостатки

Роль аналитика в канбане

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

Столбец «Аналитика» для соответствующего состояния

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

Прототипы

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

Ксения Колосова, руководитель проектов

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

Различные варианты прототипов

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

Прототип для веб-страницы

В рамках Scrum прототипы рекомендуется делать к конкретным историям пользователей в сочетании с текстовым описанием и диаграммами.

Глава 9. Масштабирование Agile

Классическая Agile-команда состоит из немногих участников, обычно 7 ± 2 человека. Это максимальное количество людей, при котором возможно гибкое взаимодействие. При дальнейшем увеличении команды резко возрастают издержки на коммуникации (количество возможных коммуникаций находится в квадратной зависимости от количества участников коммуникации).

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

Организационные структуры

Организационная структура (оргструктура) – это способ упорядочить сотрудников организации для достижения ее целей. Прежде всего, оргструктура создается и поддерживается для:

• координации деятельности работников;

• обозначения границ ответственности.

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

Виды оргструктур. Кратко рассмотрим, какие организационные структуры существуют и какие мы можем использовать для масштабирования Scrum.

 Дивизионная оргструктура объединяет в дивизионы полный коллектив для разработки связанного семейства продуктов или организации работ по географическому признаку.

 Функциональная оргструктура объединяет в функциональные единицы (обычно отделы) сотрудников одной специальности.

 Командная (проектная) оргструктура объединяет в небольшую группу работников разных специальностей для реализации проекта.

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

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

Scrum-команда: состав

Команда в Scrum состоит из небольшого количества людей – от пяти до девяти человек, чтобы можно было осуществлять эффективные коммуникации. Один из членов команды становится скрам-мастером (SM), ответственным за процессы и социальный климат в команде.

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

Состав Scrum-команды

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

Масштабирование Scrum

Небольшие команды чаще показывают хорошие результаты, чем большие, поэтому необходимо по возможности вести разработку компактными командами. К сожалению, часто бывает, что объем проекта и сроки его реализации просто не позволяют вести разработку 5–9 людьми и приходится задействовать несколько команд.

Привлечение нескольких команд

Для организации разработки больших проектов или портфеля проектов необходимо масштабировать Scrum на следующий уровень. Со стороны команд разработки это выливается в проведение Scrum of Scrum.

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

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

1. Что было сделано с прошлого Scrum of Scrum?

2. Какие были проблемы?

3. Что будет сделано к следующему Scrum of Scrum?

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

Scrum of Scrum of Scrum

Следующим уровнем масштабирования является Scrum of Scrum of Scrum. Для осуществления этого проводится соответствующее мероприятие, на которое собираются менеджеры программ и топ-менеджер (обычно технический директор подразделения).

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

Scrum of Scrum of Scrum

Очень удобно использовать данное мероприятие для финального обсуждения и принятия производственных стандартов.