Кен Швабер - Скрам

• Название: Скрам
• Автор: Кен Швабер
• Жанр: Отраслевые издания
• Год: 2019
• ISBN: 978-5-9614-2860-5

Эта книга несет в себе дух скрама, раскрывая его ценности и основные принципы. Кен Швабер, один из создателей скрама, соавтор «Руководства по скраму» и основатель Scrum.org, собрал лучшие кейсы из своей практики, демонстрирующие примеры успехов и неудач применения скрама в реальных проектах. Они помогут вам понять, как использовать скрам для решения комплексных проблем и достижения результатов. Автор рассказывает, как эффективно управлять сложными, громоздкими проектами и изменяющимися требованиями к продукту; упрощать организационную структуру с помощью самоуправляемых команд разработки; получать более четкие описания требований и внятную обратную связь от клиентов и заказчиков. Вы узнаете, как эффективнее планировать работу над проектом, научитесь избегать ошибочных действий, используя регулярную инспекцию, а также увеличивать отдачу от инвестиций.

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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