Скрам

Проведя вместе со своими менеджерами детальное исследование и узнав, что применяемый в скраме итеративно-инкрементальный подход поможет обеспечить равномерный прогресс и регулярные поставки на протяжении всего цикла создания релиза, Хэл решил попробовать скрам. Я встретился с ним и его менеджерами, чтобы обсудить начало работы: определение бэклога продукта для релиза, организацию кросс-функциональных скрам-команд и распределение между ними работы. Формирование команд – непростая задача. Мы учли командную динамику, характеры сотрудников, знания предметной области и связи между функциональными блоками. Мы хотели, чтобы участники команд ладили как можно лучше, обладали всеми знаниями и навыками, необходимыми для выполнения работы, и не зависели от прогресса других команд. Как бы нам ни хотелось, мы не смогли избежать назначения людей с ключевыми знаниями предметных или технических областей в несколько команд. Один сотрудник был назначен сразу в четыре разные команды. Такой результат был далек от идеала, однако мы не желали тратить все шесть месяцев на планирование релиза и поэтому решили двигаться дальше.

Я обсудил с Хэлом и его менеджерами несколько самых важных вещей, которые мы могли сделать для оптимизации производительности команд. Я порекомендовал убрать перегородки между рабочими местами, создав объединенные пространства для команд. Хэл решил отложить это предложение, потому что перегородки были построены совсем недавно. Я также порекомендовал ликвидировать все артефакты разработки, например проектные документы, которые существовали только для поддержки водопадного процесса. Скрам полагается на быстрое личное общение лицом к лицу и совместную работу. Перегородки и ненужные артефакты способствуют изоляции и недопониманию.

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

Некоторые команды сомневались, что их группировка была адекватной задачам. Им казалось, что в команде недостаточно тестировщиков или технических писателей для полноценного тестирования и написания всей документации. В ответ я объяснил им, что команда является кросс-функциональной: в ситуациях, когда все вкладываются в создание готового к поставке инкремента продукта, им не обязательно быть проектировщиками, чтобы проектировать, или тестировщиками, чтобы тестировать.

Разбираемся, кто же босс

Команды в Service1st встречались каждый день. Скрам-мастер нескольких команд Алисия решительно и профессионально организовывала ежедневные скрамы, помогая командам завершить их в течение 15 минут. Поскольку команды заранее договорились об этом формате, она гарантировала, чтобы каждый ответил на три вопроса:

1. Что я сделал с момента последнего ежедневного скрама, чтобы помочь команде достичь цели спринта?

2. Что я планирую сделать сегодня и до следующего ежедневного скрама, чтобы помочь команде достичь цели спринта?

3. Мешает ли что-то мне или команде достичь цели спринта?

Во время отпуска Алисии ее замещал другой скрам-мастер – Джордж. Ему понравилось, насколько гладко прошел ежедневный скрам, но тем не менее его не покидало чувство, будто что-то упущено. Через несколько дней он заметил, что почти не слышал просьб или предложений о помощи. Не было никаких комментариев, которые ему пришлось бы просить обсудить позже, чтобы успеть за 15 минут.

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

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

Извлеченные уроки