66
После проведения подобной сессии определяются участники команды
по создания данного форума, которые двухдневный тренинг по SCRUM и
Agile, например, в Школе Бизнеса Диполь (они уже более 3-х лет проводят
подобные мероприятия и являются партнерами ООО «Ресурсный центр
«Академия КлассИнфо»). Также, на обучении определяется Scrum-мастер и
владелец продукт.
Для того, чтобы включить в команду специалистов, обладающих всеми
критическими компетенциями для достижения цели, можно рекомендовать
практику работы с командными компетенциями, такую как «Матрица
компетенции команды».
Для этого, необходимо сказать то, что в Agile-командах не принято
специализироваться участникам команды на определенных
профессиональных ролях. Существует такое понятие, как T-Skilled люди или
Общие специалисты.
Внутри членов команды не происходит деление на: дизайнеров,
сценаристов, переговорщиков и т.д., но это не значит, что каждый должен
заниматься каждым. Принципы выбора своих задач базируются на двух
вопросах: я в этом компетентен? Мне это нравится?
В рамках одной компетенции можно определить 3 уровня, а именно:
ученик (не умею самостоятельно, но учусь), ремесленник (умею сам), мастер
(умею сам, могу научить).
Для того, чтобы проанализировать компетенции команды можно
использовать матрицу. Происходит это в несколько шагов.
Выявление областей знаний, критичных для проектов (можно путем
мозгового штурма или фасилитацией); создание матрицы и определение
уровня каждой компетенции для
каждого участника; анализ составляющих командных компетенций,
планирование по их
67
развитию.
Пример матрицы на следующем рисунке.
Рисунок 5 Матрица компетенций команды
Еще одна важная деталь для внедрения Agile-методологии в управление
проектом – это помещение.
Помещение должно быть обособленным от других команд, но при этом
все члены команды должны работать в одном пространстве. В идеале формат
Open Space. Благо, это не помешает работе компании, так как подобное
помещение есть в аренде у ООО «Ресурсный центр «Академия КлассИнфо».
Также, в этом помещении необходимо сделать место для размещения
SCRUM-доски. Тут важно, чтобы у любого члена команды, партнера или
заказчика потенциально мог быть доступ к этой доске.
Для постоянной работы в Agile необходимо запастись стикерами,
клеем-аэрозолем, маркерами.
Также, в процесс внедрения Agile-команды будет
меняться организационная структура. Из линейно-функциональной
она станет проектной. Пример такой организационной стурктуры ниже.
68
Рисунок 6
Организационная структура
Вместе с организационной структурой могут поменяться и внутренние
регламенты, пропадет большое количество бюрократии, отношения с
заказчиком стоит выстраивать на прицепе «человек-человек», а не
«заказчикисполнитель». Следом за этим минимизируется количество
переделываемых документов и утверждение изменений. Контрольным
событием станет не утверждение новых изменений, а подведение итогов
спринта.
И так после того, как команда готова начинать свой первый забег
(спринт), следует провести планирование спринта. Тут собираются все
заинтересованные стороны: участники команды, скрам-мастер (он обычно и
проводит этот процесс), владелец продукта, представители заказчика и т.д..
Для начала команде необходимо разобраться с беклогами проекта и
пользовательскими историями.
Бэклог проекта – это такой артефакт Scrum, который содержит в себе
все фичи, функции, улучшения, исправления для будущей реализации в нашем
проекте. Это такой список пожеланий заказчика, который обладает
69
определенными особенностями. Он плоский, приоритезированный,
неоднородный, ценностно-ориентированный и живой.
Это означает, что каждый элемент такого списка, должен содержать в
себе описание этого пожелания заказчика, приоритет, то есть положение
бэклоге, оценку размера, то есть, насколько сложно будет команде его
реализовать в нашем проекте и оценку ценности, то есть, насколько данный
элемент ценен для нашего заказчика. Давайте посмотрим, что значит плоский
приоритезированный список. Это означает, что мы можем однозначно сказать,
какой элемент бэклога нам требуется реализовать вслед за текущим. Принцип
приоритезации выбирается очень простой. Сверху бэклога должны находиться
самые ценные элементы и при этом самые маленькие, то есть такие, которые
команда проекта может реализовать быстрее всего.
Неоднородный список означает, что он может включать в себя
элементы разного размера. Как правило, выделяют три типа элементов по
размеру. Это пользовательская история. Главное требование к таким
элементам одно. Команда разработки должна иметь возможность реализовать
его в продукте за один спринт. Следующий элемент, они чуть побольше
называются Ipic или по русски эпосами. Они уже не помещаются в один спринт
и большие наименее определенные пожелания заказчика называются темами.
Ценностноориентированный список означает, что каждый элемент бэклога
несет ценность для заказчика. Чтобы разобраться, что это означает,
необходимо обозначить такую практику, которая называется пользовательские
истории. Пользовательская история – это один из способов описания
элементов бэклога. Выглядит он, как сформулированные ожидания или
пожелания заказчика в проекте в следующем формате: пользователь какой-то
роли хочет выполнить определенные действие в нашем проекте, чтобы
получить какую-то ценность для себя.
70
В простейшем виде бэклог проекта можно ввести в обыкновенные
таблицы, например, в excel или в google docs. Но важно помнить, что бэклог -
это живой документ. То есть, он может меняться прямо по ходу разработки
проекта. Изменение требований к проектам по ходу реализации – это
абсолютно нормально и это позволяет в конечном итоге заказчику получить
более ценный результат.
После того, как определены пользовательские истории и бэклог,
необходимо спланировать работу Scrum-команды на текущий спринт.
Участвует в этом событии вся Scrum-команда, то есть, владелец продукта,
команда проекта и Scrum-мастер. Для проведения этого события требуется,
чтобы уже был подготовлен бэклог с элементами. А здесь надо отметить, что
все события в Scrum-е имеют так называемый тайм-бокс, то есть максимальное
ограничение по продолжительности. Планирование спринта ограничено
восемью часами для спринта длиной в один месяц. Планирование спринта
отвечает на два вопроса, что может быть реализовано в проекте в этом спринте
и как именно это будет реализовано. Встреча проходит следующим образом.
Вначале, команда проекта выбирает из подготовленного бэклога из самых
приоритетных его элементов те, которые по ее мнению могут быть
реализованы в текущем спринте. Как это понять? Какие именно она может
успеть сделать? В первом спринте она в буквальном смысле определяет это на
глаз по ощущениям, вот это мы успеваем, а вот это уже не успеем. В
последующих спринтах, она может опираться на метрику, которая называется
скорость команды. После того как команда проекта выбрала элементы,
которые она будет реализовывать в этом спринте. Вся Scrum-команда
формулирует цель спринта. Цель спринта – это такая бизнес-цель нашего
проекта, которая может быть достигнута благодаря реализации выбранных
элементов бэклога. Нужно помнить, что мы делаем функции в проекте не
просто так, а для того чтобы они принесли какую-то ценность нашим
71
пользователям (в данном случае, участникам форума) и, соответственно, эта
ценность может быть выражена в некоторых метриках.
После того, как выбранные элементы и выбрана цель спринта, команда
проекта разрабатывает план по достижению этой цели. Этот план можно
разрабатать путем декомпозиции выбранных элементов бэклога на задачи.
Тут рекомендовано использовать инструмент, который является
лучшей практикой дополняющий Scrum, которая называется Scrum-доска. В
буквальном смысле это физическая доска висящая на стене, на которой
размещаются стикеры. Эта доска может состоять из трех колонок, такая
таблица, еще не начато, в работе и готово. Соответственно, наши элементы,
которые команда отобрала для планирования размещаются в первой колонке,
которая называется «не начато». Затем происходит декомпозиция этих
элементов на задачи. Scrum-мастер берет первый элемент на доске, зачитывает
его и задает команде разработки вопрос: «что необходимо сделать, чтобы
переместить этот элемент бэклога в готово?»
Команда начинает разбивать его на задачи, которые размещаются на
доске на стикерах других цветов. Важно, чтобы задачи и элементы бэклога
отличались, например, цветом стикеров. Как только команда закончила
декомпозицию работ, то есть расписала все задачи поэтому элементы бэклога,
Scrum-мастер может задать уточняющий вопрос: "а нужно ли сделать что то
еще, чтобы переместить этот элемент бэклога в готово?". Команда может
вспомните что-то еще, что необходимо сделать
И так продолжается до тех пор, пока команда не ответит на этот вопрос
отрицательно, то есть скажет, что нет, это все, что нужно сделать, чтобы
реализовать эту пользовательскую историю.
После этого scrum-мастер переходит к следующему элементу бэклога и
так до тех пор, пока все элементы бэклога выбранные для реализации в этом
спринте не будут декомпозированы на задачи.
72
Важный момент, на планирование спринта, ни задачам, ни элементам
бэклога не назначаются и не выбираются ответственные из команды проекта,
потому что это препятствует коллаборации, то есть взаимодействию
участников проекта в течение спринта и поиску оптимальных решений по
реализации той или иной задачи. То, что получилось у команды, то есть
выбранные элементы бэклога, что мы сделаем в этом спринте и задачи, то есть
план, как мы именно это сделаем, называется бэклогом спринта и владеет
бэклогом спринта команда проекта.
То есть, это означает, что никто, кроме самой команды разработки не
может вносить изменения в этот бэклог, даже владелец продукта и кто бы то
ни было другой, например, руководитель компании, в которой работает
Scrumкоманда не может просто прийти к команде в середине спринта и как бы
впихнуть другую работу. Это важно, потому что, только таким образом можно
достичь максимальной эффективности и производительности команды
разработки в спринте.
Качественно проведенное планирование спринта позволяет команде
разработки в течение спринта полностью сосредоточиться на работе и достичь
своей максимальной производительности. Таким образом, результатом
планирования спринта, является цель спринта и бэклог спринта, состоящий из
выбранных для реализации элементов бэклога и плана по их реализации, то
есть задач.
После планирования работы в проекте, начинается его реализация. И
тут необходимо поддерживать ритуалы Scrum. Один из них – scrum-митинг.
Это 15-ти минутное ежедневное событие команды проекта, цель
которого скоординировать работу и выявить проблемы и препятствия, которые
стоят перед командой разработки на пути к достижению цели спринта.
Участвуют в этой встрече участники проекта, а Scrum-мастер помогает ее
проводить.
73
Важно, чтобы эта встреча проходила каждый день в одном и том же
месте, в одно и то же время. Как правило ее проводят возле Scrum-доски.
Рекомендуемый формат проведения такой – каждый участник отвечает на три
вопроса: «Что я сделал вчера на пути к достижению цели спринта?» При этом,
удобно сразу же отражать этот статус на Scrum-доске, то есть перемещать
стикеры с задачами из столбца «в работе» в столбец «готово». Второй вопрос,
на который отвечает каждый разработчик звучит так: «Что я сделаю сегодня
для того чтобы достичь цели спринта?» В этот момент разработчик
перемещает стикеры из столбца «не начато» в столбец «в работе». И третий,
не менее важный вопрос: «Какие я вижу препятствия и проблемы на пути
команды?» Что команда, например, не сможем достичь.
Важно понимать, что на ежедневном Scrum эти препятствия и
проблемы только обозначаются, а решаются они уже позже. В опытных
командах роль Scrum-мастера на ежедневном Scrum сводится только к тому,
чтобы убедиться что он состоялся и уложился в 15 минут. В начинающих
командах Scrum-мастер может помогать группе с помощью вот этих открытых
вопросов, то есть Scrum-мастер может их сам задавать. Важно помнить что
Scrum-мастер ни в коем случае не может раздавать задачи участникам проекта.
Неопытная команда обязательно будет стремиться затянуть
ежедневный Scrum. Важно научить команду укладываться в тайм-бокс 15
минут. Хорошей практикой является ставить таймер, прямо на 15 минут, и
заканчивать эту встречу, даже если команда не успела все обсудить.
После спринта наступает этап, как нужно посмотреть на то, как и что
было сделано. Этот этап называется – обзор спринта.
Это такая отчетная встреча Scrum-команды. Участвуют в этой встрече,
соответственно, заказчики, заинтересованные лица, вся команда, владелец
продукта, Scrum-мастер. Как правило, начинается эта встреча с открытия,
когда владелец продукта отчитывается о том, что Scrum-команде удалось
74
сделать за спринт. Хорошо в этот момент используется Scrum-доска, потому
что на ней виден статус того, что хотели сделать и что мы реально смогли
сделать. То есть то, что находится в колонке «готово». После этого,
происходит демонстрация готовых элементов проекта. Это очень важная
часть. С одной стороны она помогает воспитывать командную
ответственность в команде разработки, потому что к ней нужно готовиться и
хорошая практика является, когда каждый участник команды демонстрирует
свой вклад в проект. Также, демонстрация очень важна для получения
обратной связи от заказчика. В силу того, что цель этой встречи –это сбор
обратной связи, получение обратной связи, результатом этой встречи является
обновленный бэклог продукта куда эту обратную связь включает команда.
Ответственные, за то, что заказчики они реально приходили на эту встречу и
давали обратную связь является владелец продукта. Ведь, более качественная
обратная связь означает, что можно сделать более ценный проект в конечном
итоге.
После обзора спринта команде проекта необходимо произвести
ретроспективу (взгляд в прошлое) и понять, что им поможет ускорить
реализацию и разработку проекта, а также усилить коммуникацию внутри
команды и вне её.
Для этого можно предложить метод сфокусированной беседы ОРИП
(базовым методом технологии вовлечения ToP), который пришел из практик
фасилитации и модерации. Для этого команда может стикерами на плакатах
ответить и обсудить ответы на следующие вопросы:
- Что мы делали в этом спринте? (Объективный вопрос)
- Какие эмоции мы испытывали? (Рефлективный вопрос)
- Что для нас, как для команды, это значило? (Интерпретативный
вопрос)
75
- Какие новые правила помогут нам сделать работу лучше?
(Принятие решений)
Для определения изменений в модели поведения команды, в которой
внедрялся Agile было использовано анкетирование по эффективности
командных коммуникаций модели NASA до и после внедрения
Agileметодологии. В рамках исследования были анонимно заданы участникам
команды 8 вопросов, в которых использовались следующие показатели:
1) выражение аутентичной признательности
2) умение видеть и возвращаться к общим интересам
3) умение создавать и поддерживать атмосферу поддержки
4) соблюдение всех договорённостей
5) выражение реалистичного оптимизма при поиске решений
6) 100% приверженность результату
7) избегание жалоб и обвинений в процессе работы
8) ясность ролей, ответственности и полномочий участников
команды\проекта.
Вопросы методики можно увидеть в приложении 1.
Результаты данного исследования представлены в следующем
параграфе.
Хочется сказать, что спустя месяц кропотливый работы данные
рекомендации смогли быть реализованы в ООО «Ресурсный центр «Академия
КлассИнфо». Это было не простой путь, так как естественно сотрудники
компании были удивлены настолько отличной от предыдущей методологией
работы. Однако, предложенные изменения относительно проектного
управления были успешно применены в ООО «Ресурсный центр «Академия
КлассИнфо». И в будущем эти изменения будут внедрены во всю компанию и
изменят её организационную культуру, производительность и эффективность.