Скрам

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

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

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

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

Становление команды в Service1st

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

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

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