ботать на практике?
Вспомните пример из предыдущей главы, когда командно-административный руководитель проекта проводил неэффективные ежедневные scrum-митинги и ежедневно назначал задачи каждому члену команды. Идя на собрание, руководитель проекта должен знать все зависимости задач, чтобы распределить задания между сотрудниками. Сравните это с самоорганизующейся командой. Когда один ее участник назначает себе задачу, вся команда активно ищет зависимости во время летучки, а также на всех предыдущих и последующих встречах. Поэтому уже на третьем scrum-митинге любой член команды знает, какие существуют преграды. Каждая из них – это зависимость, которую пытается обнаружить команда. Все ее члены ищут зависимости ежедневно и поэтому находят. В результате они предотвращают многие каскадные задержки, с которыми сталкивается командно-административный проект.
Почему это удается сделать? Когда командно-административный менеджер проекта выполняет анализ зависимостей для проекта на этапе его планирования, один из его наиболее важных инструментов – экспертное заключение. Это беседа руководителя проекта с членами команды, на чьи знания он готов положиться, чтобы помочь избавиться от зависимостей. Когда самоорганизующаяся команда ежедневно контролирует свой план во время scrum-митингов, она использует ту же экспертную оценку, но имеет гораздо больше информации, потому что участвуют все члены команды. Планирование на протяжении всего проекта дает ей гораздо более широкий обзор и позволяет принимать лучшие решения. Самоорганизующаяся команда имеет больше шансов найти критическую зависимость, потому что ищет ее во время проекта. А командно-административная имеет меньший обзор и более скупую информацию, потому что делает анализ за несколько недель или месяцев до начала работы. Улучшенный обзор и высокое качество анализа зависимостей, проведенного в нужное время, – важный источник производительности успешных scrum-команд.
Мне немного дискомфортно от выражения «в последний ответственный момент». Не лучше ли планировать заранее, даже если план придется изменить?
Руководители проектов любят цитировать президента США Дуайта Эйзенхауэра, который сказал: «В процессе подготовки к сражению я всегда находил, что планы бесполезны, но планирование необходимо». Когда вы садитесь вместе с командой и планируете проект, каждый думает о деталях работы и конкретных проблемах, с которыми придется столкнуться в ходе ее выполнения. Даже если расчеты руководителя проекта и команды неидеальны, после удачного планирования команда знает о проекте больше и все лучше подготовлены к работе. Когда происходят изменения, команда выявляет их и получает опыт, позволяющий ей в будущем избежать любых ситуаций, вызывающих проблемы планирования. Так почему бы не планировать заранее и получить эти преимущества, особенно если есть возможность изменить план, когда это будет нужно?
Команда, которая планирует в последний ответственный момент, получает все эти преимущества и многое другое. Это не значит, что она не планирует заранее. Наоборот! Разница в том, что вы заранее планируете крупные работы: задачи в продуктовом бэклоге. Продуктовый бэклог содержит такие задачи (часто пользовательские истории), которые будут понятны владельцу продукта и другим нетехническим специалистам компании. До начала первого спринта команда и владелец продукта должны сесть и договориться о бэклоге спринта, а это требует от них большого продуктового бэклога с точными оценками историй, то есть чтобы они уже фактически составили продуктовый бэклог заранее. Что ж, команда и впрямь уделяет много внимания предварительному планированию!
Вы можете привести пример того, как работает планирование scrum-спринта?
Конечно! Представьте, что вы член традиционной проектной команды, которая работает над проектом, где нужно разработать несколько новых функций, а также провести тонкую настройку производительности. Если бы вы планировали проект, то какую задачу сделали бы в первую очередь? Большинство команд, как правило, начинает с разработки новых функций, а настройку производительности делает в конце проекта. Если вы разработчик, то разработка новой функции кажется гораздо более интересной, дает возможность развития, а отслеживание и исправление ошибок производительности – это трудно и неинтересно, поэтому неудивительно, что такая работа часто располагается в самом конце плана.
Но что если пользователям действительно известны проблемы с производительностью? Что если эти проблемы становятся препятствием для тех пользователей, которые просто делают свою работу, и именно быстродействующее программное обеспечение, а не новые функции сделает их жизнь намного лучше? Значит, команда должна сделать тонкую настройку производительности своим приоритетом. В этом случае владелец продукта, который еженедельно встречается с командой и обсуждает наиболее ценные функции в бэклоге, имеет больше шансов в первую очередь улучшить производительность.
Напомните мне еще раз – какое это имеет отношение к принятию решений в последний ответственный момент?
Когда команда все планирует заранее, она займется тонкой настройкой прежде, чем новыми функциями, только в том случае, если с первого дня знает, что это необходимо пользователям. А если владелец продукта не привык постоянно говорить команде о том, что ценно для пользователей, и члены команды не привыкли слушать, что может произойти, когда владелец продукта в середине проекта сообщит, что пользователям в первую очередь действительно нужны именно эти настройки производительности? Менеджер проекта и команда, скорее всего, «замнут» эту тему, потому что она потребует серьезных изменений и приведет к неразберихе. Они также, вероятно, пожалуются, что бизнесмены, с которыми приходится работать, постоянно меняют свое мнение и будут мечтать о проекте без таких многочисленных изменений.
Такая команда все равно будет работать над внесением этих изменений. Но на их выполнение потребуется больше усилий, а также, как правило, реорганизация проекта. Реальность такова, что почти каждая группа пользователей имеет дело с проблемами, которые постоянно меняются. Такова жизнь. Не стоит думать, что изменения – это из ряда вон выходящее событие. Именно поэтому agile-команды любят использовать фразу «принять изменения».
Негибкое отношение к «планированию наперед» превращает внесение изменений в проект в переговоры между командой и владельцем продукта. А мы уже знаем, что agile-команды ценят сотрудничество с заказчиком выше, чем переговоры по условиям контракта. В переговорах кто-то выигрывает, кто-то проигрывает, и все идут на компромисс. Это не эффективный способ выполнения проекта, он приводит к потере производительности.
В то же время, когда команда сотрудничает с клиентом, все работают вместе и все в выигрыше – ведь каждый признает трудности, с которыми нужно справляться вместе. Планирование в последний ответственный момент поощряет такое отношение, потому что это помогает команде избежать установления произвольных ограничений, которые необходимо будет обсудить позже. Это позволяет команде оставаться открытой к изменениям и дает возможность (может быть, не всегда легко) изменить порядок работы, чтобы достичь меняющихся целей (в отличие от планирования работы и рабочего плана). Это облегчает задачу владельца продукта, который постоянно вовлекает команду в выполнение этих целей.
Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с командой).
Если вы работаете с командой, которая уже проводит ежедневные встречи, то попросите всех ответить на три вопроса, которые задаются во время ежедневных scrum-митингов.
Если вы работаете с командой, которая еще не проводит ежедневные митинги, выясните, можете ли вы провести хотя бы одно такое совещание.
Поговорите с вашей командой о последнем ответственном моменте. Напишите список решений, которые вы и ваша команда сделали. Не исключено, что их придется пересмотреть, потому что они были сделаны слишком рано.
Обсудите с командой задачи, которые могут появиться в продуктовом бэклоге. Какую работу вы еще не делаете? Можете ли вы составить список этих задач?
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
Вы можете узнать больше о самоорганизующихся командах и о том, как управлять scrum-проектами, в книге Кена Швабера Agile Project Management with Scrum (Microsoft Press, 2004).
Вы можете узнать больше о планировании scrum-проекта в книге Майка Кона Agile Estimating and Planning (Addison-Wesley, 2005).
Вы можете узнать больше о scrum-правилах, прочитав The Scrum Guide (Sutherland and Schwaber, 2011). Текст можно скачать на сайте Scrum.org.
Здесь мы предлагаем советы для agile-коучей, помогающих своей команде разрабатывать идеи этой главы.
• Одна из самых сложных задач внедрения Scrum – это поиск владельца продукта. Если вы работаете с командой, которая хочет внедрить Scrum, помогите ей найти человека, готового принимать решения в интересах бизнеса и обладающего полномочиями на это.
• Многие agile-тренеры считают, что их scrum-команды сталкиваются с проблемами, потому что выбрали владельца продукта из числа команды. Помогите им понять, что владелец продукта должен иметь полномочия принимать разработанные функции от имени компании.
• Проводят ли команды ежедневные встречи, именуемые scrum-митингами, которые по сути являются обычными статус-митингами? Помогите команде осознать разницу между командно-административным управлением и самоорганизацией.
• Помогите scrum-мастеру понять, что он не несет ответственности за ежедневную работу каждого члена команды и не должен отслеживать, выполнил ли тот свою работу. Помогите команде понять, что роль scrum-мастера состоит в том, чтобы помогать команде правильно выполнять scrum-правила и устранять любые препятствия, мешающие это делать.