Текст книги "Скрам"

Команда разработки в Service1st

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

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

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

Ситуация в Service1st

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

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

Команда разработки в действии

Я провел с командой упражнение «Быстрый старт». Это интенсивная двухдневная сессия, в которой участники изучают практики скрама и готовятся к запуску своего первого спринта. Учебная часть сессии прошла хорошо, но, когда я добрался до первой части планирования спринта, все начало рассыпаться. Комната была переполнена: 17 участников команды разработки плотно расположились вокруг небольшого стола, а заинтересованные лица сформировали кольцо за ними. Более активные участники команды расспрашивали и общались с владельцем продукта, а более пассивные – выпали из процесса. К началу второй части планирования спринта, когда команда разработки определяет свой бэклог спринта, по-прежнему участвовали только самые бойкие. Прерывая их, я несколько раз старался вовлечь молчунов и спрашивал, над чем они будут работать. Я уточнил, понимают ли они, что нет ничего хуже, чем во время ежедневного скрама сознаваться, что они ничего не делали и вообще не сильно вовлечены в проект. Имея благие намерения, этим своим замечанием я добился лишь того, что пассивным участникам стало только хуже.

Команда разработки была слишком большой, поэтому вовлечь всех не удалось. Оптимальный размер команды – от трех до девяти человек, чтобы во время планирования спринта они могли общаться, глядя друг другу в глаза, взаимодействовать и формировать общий план действий. Команда из 17 человек сделала фактически то же самое: 7 активных участников планировали спринт, а 10 пассивных сотрудников не участвовали в процессе. Что мог сделать я? Понимая, что пересобирать команду уже поздно, я решил оставить все как есть и посмотреть, что произойдет. Несколько дней спустя я присутствовал на ежедневном скраме этой команды разработки. К моему большому удивлению, о выполненной и планируемой работе рассказывали все. Конечно, с таким количеством людей ежедневный скрам длился 20 минут вместо 15, но это была активная, оживленная сессия, и все участники команды, казалось, были увлечены работой. После встречи они поделились со мной своими соображениями. Они решили, что менеджмент сформировал такую большую команду разработки по ошибке, однако не хотели перечить ему, полагая, что мудрое руководство знает о причинах, по которым команда должна быть настолько многочисленной. Но большая команда разработки не функционировала – прогресса в работе над задачами спринта почти не было. Команда решила разделиться на четыре подгруппы численностью от трех до пяти участников каждая. Руководители программистов и тестировщиков помогли сформировать эти подгруппы и разделить работу так, чтобы сложносоставные задачи выполнялись внутри подгрупп, а коммуникации между ними свелись к минимуму. Также они взяли на себя ответственность за устранение зависимостей, возникающих между участниками команды в ходе работы. Эти руководители были частью команды разработки, они были преданы работе и общей цели, поэтому их действия являлись проявлением самоорганизации.

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

Ценность команды разработки

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

Выводы

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

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

Глава 3
Скрам-мастер

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

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

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

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

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

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

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

Давайте рассмотрим другие примеры реальных ситуаций, с которыми сталкивались скрам-мастера с разным опытом работы. Они покажут, насколько важно иметь в команде высококвалифицированного скрам-мастера.

Необученный скрам-мастер в Trey Research

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

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

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

Что было не так

В начале визита я встретился с командой руководителей, подчинявшихся ИТ-директору, и кратко рассказал им о скраме. Затем мы обсудили текущие проекты в Trey Research и то, как фирма использует скрам. Каждая команда уже завершила по несколько спринтов, и все были довольны результатами изменений и достигнутым прогрессом.

Самый опытный скрам-мастер компании пригласил меня посетить «его ежедневный скрам». В моей голове тут же раздался первый тревожный звонок. Почему это был «его ежедневный скрам», а не «ежедневный скрам команды»? Я решил придержать язык за зубами и искать ответ. Скрам-мастер привел меня в большую комнату в подвале старого особняка, который был штаб-квартирой Trey Research. Девять разработчиков трудились за компьютерами: пятеро располагались в центре и по паре на каждом конце комнаты. С точки зрения расположения рабочих мест все было хорошо: такая открытая рабочая зона обеспечивает быстрые коммуникации, что критично для успешной совместной деятельности.

Скрам-мастер начал ежедневный скрам, вытащив план работ. Зачитывая пункты списка, он ходил по комнате, спрашивая каждого присутствующего, выполнил ли он задачи, записанные напротив его имени. В частности, он задавал такие вопросы: «Мэри, ты закончила дизайн экрана, который я передал тебе вчера? Готова ли ты приступить к диалоговым окнам сегодня?» Дойдя до конца списка и поговорив с каждым в комнате, он спросил, нужна ли команде разработки его помощь. Участники команды молчали.

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

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

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

1. Что я сделал с момента окончания предыдущего ежедневного скрама, чтобы помочь команде достичь цели спринта?

2. Что я планирую сделать до следующего ежедневного скрама, чтобы помочь команде достичь цели спринта?

3. Какие препятствия могут помешать мне и команде достичь цели спринта?

Однако он был давним практиком традиционных методов управления проектами, потратил годы на планирование задач и обеспечение их выполнения, поэтому интерпретировал прочитанное примерно так:

1. Он проверит, что участники команды выполнили его поручения, данные во время предыдущего ежедневного скрама.

2. Он скажет каждому участнику команды, что нужно сделать до следующего ежедневного скрама.

3. Он уточнит, может ли чем-то помочь команде, чтобы участники выполнили полученные задачи.

Чтобы сэкономить время, последний вопрос он задал всей команде разработки сразу.

Реальный переход от роли менеджера проекта к скрам-мастеру не произошел. Он считал, что скрам представляет собой лишь набор практик и методов для реализации итеративно-инкрементальной разработки[9]9
  См. подглаву «Скелет и сердце скрама».


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

Необученный скрам-мастер в Litware

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

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

Что было не так

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

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

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

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

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

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

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

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