• Ответственность
Эксперт, как заинтересованная сторона, присутствует на обзоре спринта. Участвует в других событиях спринта и активно взаимодействует с командой.
Желательно, чтобы эксперт участвовал в коллективной работе всякий раз, когда требуется его или ее участие.
Вовлечение эксперта в работу проблематично, если эксперт находится снаружи границ команды. Это может стать фактором риска для спринта.
• Ограничение зависимости
Как правило, экспертная заинтересованная сторона очень занята и не может участвовать в работе нескольких команд одновременно. Вот несколько способов уменьшить связанные с этим риски.
✓ Создание команды, которая бы зависела от малого числа экспертов.
✓ Приглашение эксперта, в котором команда нуждается на регулярной основе.
✓ Предвосхитить этот момент и не начинать работу, не убедившись, что требуемый эксперт доступен.
✓ Научиться у эксперта, чтобы в дальнейшем обходиться без него.
Рисунок 3.9 – Даже очень хорошей команде иногда нужен эксперт
Команда будет стремиться общаться с другими заинтересованными сторонами (которые являются специалистами в определенной области) без особой необходимости, просто с целью получения новых знаний.
Участники могут пользоваться знаниями, которые получат в ходе общения с другими командами.
Это обмен информацией с конечными пользователями, встречи с коллегами, участие в конференциях, обучение и так далее.
3.7 Антипаттерны
Ситуация. Каждый участник команды сидит в своем углу и делает свою часть работы – они думают, что работать исключительно по своей специальности эффективнее.
Последствия. Нет сотрудничества. Не развит коллективный разум. Только один человек разбирается в технической части вопроса. Когда он недоступен, вся команда застревает.
Как сделать лучше? Организовать парную работу, чтобы избежать гиперспециализаций.
Для повышения устойчивости экосистемы необходимо сделать так, чтобы каждая функция могла выполняться несколькими людьми и чтобы каждый человек мог выполнять несколько функций.
Ситуация: человек толком не понимает, к какой команде он принадлежит. Он работает над несколькими проектами и думает, что на один проект приходится одна команда, на один проект – только один бэклог.
Последствия: заинтересованные стороны могут входить в несколько экосистем. Но участник принадлежит только к одной Scrum-команде! Иначе он быстро «сгорит».
Как сделать лучше? Сократить количество мульти-проектов. В краткосрочной перспективе сосредоточиться на одной команде и приоритизировать задачи в бэклоге.
Ситуация. Во время спринта команде потребовалась экспертиза. Но участники не проверили, доступен ли эксперт.
Последствия. Команда не успевает завершить работу к окончанию спринта. Ожидается много работы из-за отсутствия необходимых компетенций для продвижения вперед.
Как сделать лучше? Предвидеть, что экспертиза понадобится. Определить людей, у которых есть опыт и знания, и зону обмена. Можно пригласить их выпить пива и поиграть, к примеру, в настольный футбол.
Ситуация. Заинтересованные стороны не стремятся вносить свой вклад в общую цель. Они не приходят на обзоры спринтов, а если приходят, ищут только недостатки в работе. Конструктивной обратной связи нет.
Последствия. Разработчики под гнетом контроля, нет атмосферы доверия.
Как сделать лучше? Сблизить людей при помощи паттерна рабочих зон. Познакомить все заинтересованные стороны со Scrum. Объяснить их роль. Приглашать их на каждый обзор спринта. Праздновать успехи вместе.
Чтобы идти дальше
Книги
‣ Tobias Mayer, The People’s Scrum, 2013. Вдохновляющая книга о людях в Scrum, которая включает эссе, опубликованные Тобиасом Майером на странице его блога.
4
Роль Владельца продукта
Было время, когда я работал в компании по разработке программного обеспечения. Занимался маркетингом – ошибиться может каждый – для продукта, который сегодня уже не выпускается. Продукт включал в себя графический редактор, симулятор и генератор кода. Целью была разработка распределенных систем.