«Скрам-команды работают по принципу самоуправления сверху донизу — вы не заставляете их что-то делать, а ставите цели»

Отрывок из книги «Гибкое управление: как перевести всю компанию на скрам» от соавтора скрам-методологии Кена Швабера, которая выйдет в издательстве «Альпина Паблишер» в мае.

Как объединить сотрудников в скрам-команды?

Главные в скрам-команде — это владелец продукта и скрам-мастер. Они отвечают за формирование скрам-команд разработки. Чтобы производительность команды была оптимальной, разработчики отбираются согласно трем принципам:

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

Людей можно набирать из других команд, выполняющих работу с более низким приоритетом. А можно брать их со «скамейки запасных». Так называют ожидающих работы сотрудников, не назначенных в команды. Они могли оказаться в запасе потому, что их работа уже окончена или их попросили покинуть скрам-команды, в которых он состояли.

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

Не стоит также зацикливаться на вопросе, кого назначить в состав команд. Лучший способ решить этот вопрос — позволить командам самим определить, кого брать, а кого не брать. Этой премудрости научил меня случай из жизни.

Банк Woodgrove — крупный финансовый институт, основной профиль которого — оказание банковских услуг. Изначально Woodgrove был региональной компанией, но потом разросся за счет приобретения других банков по всей стране.

Кассовые системы в новоприобретенных банках отличались от кассовой системы Woodgrove и были сложны в использовании. Банк запустил проект по созданию новой кассовой системы Teller4Uи сформировал группу разработки из 45 человек. Вся команда подчинялась вице-президенту по развитию Джеку Кризи.

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

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

Я обсудил это с Джеком, и он попросил меня разработать более подходящий процесс. Сколько он ни ломал голову, его метод по-прежнему казался ему лучшим из возможных. И тут мы вспомнили о самоуправлении. Люди, выполняющие эту работу, должны сами понять, что и как делать. Мы предложили им использовать скрам и предоставили возможность решить, как создавать Teller4U.

Мы с Джеком организовали встречу со всеми 45 разработчиками. Джек напомнил, что они теперь самоуправляемые, а значит, должны сами определить подходящую структуру команды и необходимые внутренние процессы для разработки Teller4U с использованием скрама.

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

А вдруг не сработает? Вдруг разработчики так и не смогут определить, как им выполнять работу? Вдруг 45 человек — слишком большая группа для самоуправления? Вдруг мы вернемся, а они за эти два часа так ничего и не придумают? Многого никто из нас не ждал. Больше всего мы опасались, что, вернувшись, застанем в конференц-зале не более пяти-шести ведущих разработчиков.

К нашему большому удивлению, когда мы вернулись, в зале были все 45 разработчиков. Они также пригласили на встречу Скотта и менеджера команды-прототипа. Доски были изрисованы схемами, а стол для переговоров завален бумагами.

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

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

Самоуправляемая команда придумала методику, которая должна сработать. Если возникнет неожиданная проблема и методика перестанет работать из-за нее, ответственность за изменение подхода будет лежать на них: ведь они должны выполнить свои обязательства. Либо мы доверяем им самоуправление, либо нет.

Мы с Джеком вышли из конференц-зала вместе со Скоттом. В результате нам каждый месяц представляли инкременты функциональности и в том же году было выпущено еще два релиза. Проект работает уже второй год. Все идет прекрасно.

Сотрудники компании не привыкли постоянно работать в команде. Как их к этому подготовить?

Каждая скрам-команда, независимо от ее уровня, проходит через этапы формирования, конфликта, нормализации и функционирования. Этот процесс показан на рисунке.

Если все делается организованно и правильно, первая фаза — формирование (forming) — упрощает все последующие шаги. Она дает команде инструменты для преодоления предстоящих проблем.

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

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

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

В модели Такмена выше это фаза конфликта (storming). Умение разрешать конфликты команда потом использует на фазе нормализации (norming), чтобы прийти к согласию. Если группа не в состоянии сделать это самостоятельно, следует снова прибегнуть к помощи отдела по работе с персоналом или любого другого внешнего консультанта. Согласие, к которому приходит команда, становится основой ее работоспособности на стадии функционирования (performing).

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

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

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

Как управлять сотрудниками в соответствии с задачами компании? Кто за что отвечает? Как убедиться в том, что все будет сделано?

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

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

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

Команда далее декомпозирует и перестраивает бэклог продукта так, чтобы его подразделы могли быть переданы для выполнения новым командам. Согласно ее выкладкам, есть возможность немедленно добавить четыре новые скрам-команды.

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

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

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

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

Каждая новая команда состоит из владельца продукта, скрам-мастера и разработчиков. В новые команды разработчиков назначаются сотрудники из «родительского» узла, например 1.1. По мере развития компании структура приобретает вид, представленный на рисунке ниже.

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

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

Скрам-мастер показывает владельцу продукта, как максимизировать рентабельность инвестиций и достичь поставленных целей с помощью скрама. Кроме того, скрам-мастер содействует творчеству разработчиков и расширению полномочий. Его задача — всеми способами повышать производительность команды разработчиков.

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

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

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

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

Однако команды очень неохотно избавляются от сотрудников. Такие социальные группы, как правило, очень снисходительно и бережно относятся к своим членам.

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

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

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

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

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

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

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

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

#скрам #гибкаяразработка #методология