Вице-президент по разработке Хэл был недоволен водопадным процессом и в особенности спешкой в течение последних двух месяцев каждого цикла создания релиза. Ему казалось, что его подразделение разработки в течение первых четырех месяцев лишь думало о работе, а когда чувствовало давление приближающейся даты релиза, начинало в поте лица кодировать, тестировать и документировать днями, ночами и в выходные. В результате истощенный персонал был не готов полноценно работать над следующим релизом.
Проведя вместе со своими менеджерами детальное исследование и узнав, что применяемый в скраме итеративно-инкрементальный подход поможет обеспечить равномерный прогресс и регулярные поставки на протяжении всего цикла создания релиза, Хэл решил попробовать скрам. Я встретился с ним и его менеджерами, чтобы обсудить начало работы: определение бэклога продукта для релиза, организацию кросс-функциональных скрам-команд и распределение между ними работы. Формирование команд – непростая задача. Мы учли командную динамику, характеры сотрудников, знания предметной области и связи между функциональными блоками. Мы хотели, чтобы участники команд ладили как можно лучше, обладали всеми знаниями и навыками, необходимыми для выполнения работы, и не зависели от прогресса других команд. Как бы нам ни хотелось, мы не смогли избежать назначения людей с ключевыми знаниями предметных или технических областей в несколько команд. Один сотрудник был назначен сразу в четыре разные команды. Такой результат был далек от идеала, однако мы не желали тратить все шесть месяцев на планирование релиза и поэтому решили двигаться дальше.
Я обсудил с Хэлом и его менеджерами несколько самых важных вещей, которые мы могли сделать для оптимизации производительности команд. Я порекомендовал убрать перегородки между рабочими местами, создав объединенные пространства для команд. Хэл решил отложить это предложение, потому что перегородки были построены совсем недавно. Я также порекомендовал ликвидировать все артефакты разработки, например проектные документы, которые существовали только для поддержки водопадного процесса. Скрам полагается на быстрое личное общение лицом к лицу и совместную работу. Перегородки и ненужные артефакты способствуют изоляции и недопониманию.
Проводя тренинг скрам-мастеров для менеджеров Хэла, я подчеркнул, что скрам-мастера не имеют власти над командами разработчиков. Они обеспечивают соблюдение скрам-процесса и защиту потребностей участников команд разработки. Планирование первого спринта команд стало отправной точкой для использования скрама и будущего релиза. Команды начали и должны были закончить свои спринты одновременно, чтобы упростить общий обзор релиза. Во время этих первых планирований спринта мы обсудили различные правила скрама. В частности, подчеркнули, что команды являются самоуправляющимися, что на выполнение работы у них есть лишь один спринт (в нашем случае его длина была максимальной и составляла один месяц) и что результатом работы должны стать полностью разработанные функциональные блоки.
Некоторые команды сомневались, что их группировка была адекватной задачам. Им казалось, что в команде недостаточно тестировщиков или технических писателей для полноценного тестирования и написания всей документации. В ответ я объяснил им, что команда является кросс-функциональной: в ситуациях, когда все вкладываются в создание готового к поставке инкремента продукта, им не обязательно быть проектировщиками, чтобы проектировать, или тестировщиками, чтобы тестировать.
Разбираемся, кто же босс
Команды в Service1st встречались каждый день. Скрам-мастер нескольких команд Алисия решительно и профессионально организовывала ежедневные скрамы, помогая командам завершить их в течение 15 минут. Поскольку команды заранее договорились об этом формате, она гарантировала, чтобы каждый ответил на три вопроса:
1. Что я сделал с момента последнего ежедневного скрама, чтобы помочь команде достичь цели спринта?
2. Что я планирую сделать сегодня и до следующего ежедневного скрама, чтобы помочь команде достичь цели спринта?
3. Мешает ли что-то мне или команде достичь цели спринта?
Во время отпуска Алисии ее замещал другой скрам-мастер – Джордж. Ему понравилось, насколько гладко прошел ежедневный скрам, но тем не менее его не покидало чувство, будто что-то упущено. Через несколько дней он заметил, что почти не слышал просьб или предложений о помощи. Не было никаких комментариев, которые ему пришлось бы просить обсудить позже, чтобы успеть за 15 минут.
Немного понаблюдав, Джордж догадался, в чем причина. Сообщая о прогрессе, участники команды разработки смотрели на Джорджа, а не на других участников. Они делали это, потому что отчитывались Джорджу, в котором видели своего менеджера проекта. Несмотря на уверения в обратном, участники команды все еще чувствовали, что Джордж отвечает за проект, и относились к ежедневному скраму как к собранию по статусу проекта, на котором они отчитываются. Они не верили, что ежедневный скрам – это событие, во время которого они синхронизируются друг с другом.
Поняв это, Джордж объяснил отличия своей новой роли участникам команды разработки, подчеркнув, что присутствует только для облегчения общения между ними. Чтобы помочь им приспособиться к реальной цели ежедневного скрама, Джордж попросил участников команды смотреть друг на друга при рассказе о прогрессе и планах.
Извлеченные уроки
Убеждение, что нами должен кто-то управлять, крепко укоренилось в нашей жизни и на работе. Родители, учителя и боссы, которые учат нас управлять собой, а не стремиться оправдать их ожидания, редки. Тогда почему мы ожидаем, что, сообщив команде, что теперь она сама отвечает за управление собой, она поймет, что мы имеем в виду? «Самоуправление» – это просто термин, еще не привязанный к реальности. Команде разработки нужен живой опыт работы по скраму, чтобы действительно понять, как управлять собой и как взять на себя ответственность и полномочия по планированию, координации и выполнению своих задач. Скрам-мастер должен не только помочь команде приобрести этот опыт, но и преодолеть свои собственные привычки и склонность к управлению командой. И скрам-мастер, и команда разработки должны изучить и понять новый для них подход к управлению.
Учимся программировать лучше
Во время ежедневного скрама я услышал просьбу одного разработчика о том, чтобы другой разработчик проверил его код. Хорошим в этой просьбе было то, что команда разработки использовала систему управления исходным кодом. Плохим – то, что, по-видимому, команда не использовала некоторые хорошие инженерные практики, иначе код проверялся бы регулярно. Я попросил участников встретиться со мной после ежедневного скрама.
Собравшись, я повторил для команды концепцию готового к поставке инкремента продукта. Каждый спринт команда разработки обязуется превращать выбранный элементы продукта в такой инкремент. Для того чтобы функциональность была готовой к поставке пользователям, она должна быть чистой. Участники команды хотели знать, что я имел в виду под «чистой». Без дефектов? Я ответил утвердительно, добавив, что чистый код не содержит как ошибок, так и заумных программистских трюков, а также соответствует стандартам кодирования и прошел рефакторинг для удаления любых дублей и изменения плохо структурированного кода, он прост для чтения и понимания. Если код удовлетворяет всем этим требованиям, система более устойчива и проще поддерживается. Если нет, то код станет раздутым, нечитаемым и сложным для отладки, а разработка функциональности в будущих спринтах занимает все больше времени. Я также напомнил участникам, что скрам требует прозрачности. Когда команда разработки демонстрирует функциональность владельцу продукта и заинтересованным лицам на обзоре спринта, они имеют полное право предполагать, что работа завершена. Завершена – значит, не только код написан, но и написан в соответствии со стандартами, легко читается, претерпел рефакторинг. Значит, компонент протестирован, автоматический тест написан и пройден, функциональность проверена. Если это не так, команде нельзя демонстрировать функциональность, потому что в этом случае зрители будут предполагать другое.
