Скрам

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

Два топ-менеджера – основатели компании Service1st Том и Хэнк – были ее первыми программистами. По мере роста Service1st им стало ясно, что придется отказаться от повседневного контроля за разработкой и делегировать полномочия другим. Однако со временем они все сильнее расстраивались, потому что релизы стали все чаще отставать от графика, а качество продукта ухудшалось.

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

Обзор спринта

Семь команд работали спринтами и завершали их в один день, чтобы проводить обзоры одновременно. Чтобы привлечь к событию руководство компании, стандартный формат обзора спринта был изменен. На один день бронировалась лаборатория проверки качества. Каждая команда выбирала себе зону и обустраивала ее для демонстрации их прироста функциональности так, будто участники представляли продукт на конференции: оформляла табличку с названием команды, вывешивала на стене цель спринта и бэклог продукта. Стулья размещались перед демонстрационным компьютером, а для обратной связи были доступны формуляры оценок. Во время встречи команды и подрядчики представляли свои готовые к поставке инкременты продуктов. Такой формат требует гораздо больше подготовки, чем я предпочитаю видеть в использующих скрам проектах, однако он поднял уровень оптимизма, энергии и мотивации.

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

Руководители последовательно участвовали в демонстрациях каждой команды. Затем команды ответили на вопросы и записали предложения для следующих спринтов в бэклог продукта. После двух часов такого тесного взаимодействия команды по очереди озвучили результаты встречи. Потратив по 10 минут, участники каждой команды перечислили предложенные улучшения, уточнили, не пропустили ли они что-нибудь, и учли дополнения.

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

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

Некоторые топ-менеджеры остались после встречи, чтобы прокомментировать проведенный обзор спринта. Вице-президент по маркетингу сказал: «Это было замечательно. Я смог четко увидеть, каков прогресс в работе по созданию системы. Как я могу получить демоверсию, чтобы показать ее клиентам? Можно ли пригласить клиентов на следующий обзор спринта?» Самым показательным был комментарий Тома, одного из основателей фирмы: «Пока мы были маленькой компанией, мы все время так делали. Став больше, мы утратили способность поддерживать непосредственную вовлеченность в происходящем, но такой вариант взаимодействия поможет нам снова начать работать вместе».

Устранение проблемы XFlow в MegaFund

С компанией MegaFund вы познакомились в третьей главе. Там работал Джефф – менеджер продукта XFlow, который управляет всеми бизнес-процессами фирмы. Он был «теневым владельцем продукта», потому что использовал скрам, но никто в MegaFund не знал об этом. Вот что Джефф писал мне о своем опыте в роли тайного владельца продукта: