Кен Швабер - Скрам [Гибкое управление продуктом и бизнесом] [litres]

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

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

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

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

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

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

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

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

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

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

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