Читать «Скрам (Гибкое управление продуктом и бизнесом)» онлайн - страница 29
Кен Швабер
Реальный переход от роли менеджера проекта к скрам-мастеру не произошел. Он считал, что скрам представляет собой лишь набор практик и методов для реализации итеративно-инкрементальной разработки. Первое, что он пропустил, – это тонкий, но критичный момент перехода от контроля к фасилитации процесса, от босса к коучу. Второе – важность самоорганизующейся команды. Команда и скрам-мастер договорились о цели спринта, но команда не была самоорганизующейся и в действительности не стремилась к этой цели. К тому же команда не могла сама решать, как справляться с возникающими трудностями, и поэтому участники не испытывали глубоких личных обязательств. Способность команды разработки самостоятельно решать свои проблемы является сердцем скрама и залогом исключительной производительности скрам-команды. Как только я указал на это менеджеру проекта, он сразу осознал свою ошибку и воскликнул: «Конечно же!» Независимо от того, сколько статей и книг прочитали начинающие скрам-мастера, они действуют по укрепившимся привычным шаблонам и не замечают, что конкретно нужно изменить.
Litware – небольшой поставщик программного обеспечения для планирования. Джон Чен руководил тремя менеджерами, вместе они составляли офис управления проектами. Офис тщательно планировал все релизы, разбивая работу на задачи и представляя их на диаграммах Ганта. Затем задачи распределялись между аналитиками, дизайнерами, программистами, тестировщиками и техническими писателями. Подход был очень водопадным и строго регламентированным. Клиентская база росла, релизы становились все более комплексными, а процесс планирования занимал все больше и больше времени, и однажды его длительность стала совсем неприемлемой. Результаты этапа планирования также никуда не годились: подготовленные планы с трудом адаптировались к возникающим сложностям и к изменениям, которые запрашивали заказчики и продавцы.
Недовольные менеджеры компании попросили Джона пригласить меня, чтобы перевести управление релизами на скрам. Оценив ситуацию, мы с Джоном решили переходить на скрам через несколько недель. За это время мы преобразовали текущие планы в бэклог продукта, обучили команды скраму и провели несколько встреч по планированию первого спринта.
Что было не так
В течение этих нескольких недель я провел сертификационный тренинг для будущих скрам-мастеров. Я пригласил Джона посетить занятие, чтобы он мог изучить скрам до внедрения в Litware. Как и обычно, тренинг был отлично принят сотрудниками компании. К сожалению, Джон не пришел на занятие ни утром, ни в течение дня. На мое письмо он ответил, что важные рабочие задачи не позволили ему быть на тренинге, но это не повлияет на дату запуска и мы начнем реализацию скрама, как и запланировали.
В назначенный день я приехал в Litware. До обеда мы формировали бэклог продукта для двух команд разработки. Во второй половине дня менеджеры попросили меня кратко рассказать о скраме всему подразделению разработки, чтобы каждый понимал, что такое скрам и как изменится работа двух команд. Закончив рассказ, я ответил на множество вопросов аудитории: людям было интересно узнать, где раньше использовался скрам, как это работает и в чем будут заключаться новые роли. Среди участников не было больших поклонников работы над задачами, которые назначал менеджер проекта, поэтому идея самоорганизации оказалась особенно интригующей. Немало времени мы потратили на обсуждение перехода от роли менеджера проекта к роли скрам-мастера, я сравнивал его с пастушьей собакой, готовой на все, чтобы защитить свое стадо или команду. Мы обсудили, что главная обязанность скрам-мастера – благополучие команды разработки и он должен прикладывать все усилия, чтобы помогать ей быть продуктивной. В конце дня мы с Джоном подтвердили время начала работы с командами.
