Скрам

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

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

Что стало результатом ретроспективы спринта? Многие в Service1st были рады помочь друг другу. Когда кто-то отставал, другие участники команды были рядом. Некоторые программисты были рады сидеть рядом с тестировщиками, потому что еще в процессе кодирования могли понять полный набор тестов, которые впоследствии будут применены к системе. Все были довольны, а очевидный прогресс достигнут уже через два спринта после начала цикла создания релиза. Один программист был в восторге оттого, что ему пришлось общаться и работать с проектировщиком, с которым он не обменялся и фразой за три года работы в Service1st.

Что можно улучшить? Участники команды, которые были назначены сразу в несколько команд, не были довольны этим. Они не могли сосредоточиться на одной группе задач, и им не удалось понять, как распределить свое время, чтобы быть доступными для каждой команды при наличии такой потребности. Большинство команд были недовольны перегородками между рабочими местами. Первоначально они полагали, что им нужна приватность, но в итоге начали чувствовать, что стены мешают сотрудничеству. Все команды считали, что им не хватает навыков для выполнения работы: одним не хватало тестировщиков, а другим – технических писателей.

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

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

Разбившись на малые группы, участники разработали улучшения. Команды решили корректировать свои рабочие нагрузки так, чтобы никто не был назначен нескольким командам. Если это окажется невозможным, сотрудник с критической компетенцией будет помогать второй команде только консультациями, помня об обязательстве поставлять результат для своей основной команды. Чтобы решить проблему нехватки смежных навыков, участники договорились больше помогать друг другу. Тестировщик, программист, технический писатель и проектировщик начнут с проектирования функциональности. Затем тестировщик приступит к тестовым сценариям, технический писатель – к документации, а программист – к написанию кода. Проектировщик свяжет результаты их работы так, чтобы к моменту готовности кода функции были готовы и ее тесты, и текст справки. Чтобы сократить время на первичное и повторное тестирование функциональности, команды решили начать применять подход «разработка через тестирование» с автоматическими модульными тестами.