Но что если пользователям действительно известны проблемы с производительностью? Что если эти проблемы становятся препятствием для тех пользователей, которые просто делают свою работу, и именно быстродействующее программное обеспечение, а не новые функции сделает их жизнь намного лучше? Значит, команда должна сделать тонкую настройку производительности своим приоритетом. В этом случае владелец продукта, который еженедельно встречается с командой и обсуждает наиболее ценные функции в бэклоге, имеет больше шансов в первую очередь улучшить производительность.
Когда команда все планирует заранее, она займется тонкой настройкой прежде, чем новыми функциями, только в том случае, если с первого дня знает, что это необходимо пользователям. А если владелец продукта не привык постоянно говорить команде о том, что ценно для пользователей, и члены команды не привыкли слушать, что может произойти, когда владелец продукта в середине проекта сообщит, что пользователям в первую очередь действительно нужны именно эти настройки производительности? Менеджер проекта и команда, скорее всего, «замнут» эту тему, потому что она потребует серьезных изменений и приведет к неразберихе. Они также, вероятно, пожалуются, что бизнесмены, с которыми приходится работать, постоянно меняют свое мнение и будут мечтать о проекте без таких многочисленных изменений.
Такая команда все равно будет работать над внесением этих изменений. Но на их выполнение потребуется больше усилий, а также, как правило, реорганизация проекта. Реальность такова, что почти каждая группа пользователей имеет дело с проблемами, которые постоянно меняются. Такова жизнь. Не стоит думать, что изменения – это из ряда вон выходящее событие. Именно поэтому 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, помогите ей найти человека, готового принимать решения в интересах бизнеса и обладающего полномочиями на это.
