Скрам. Гибкое управление продуктом и бизнесом Швабер Кен

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

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

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

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

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

В этой главе мы рассмотрим организацию Service1st, пережившую этот трудный переход. Рассмотрим команды, которые пытаются научиться самоорганизации и самоуправлению. Увидим, насколько тяжело скрам-мастерам и их командам начать самоорганизовываться и управлять собой, потому что это легко понять умом, но трудно реализовать. Эти подходы противоречат культуре многих компаний, и многие команды сбиваются с пути. Затем мы рассмотрим, как в компании WebNewSite я захожу сверху через руководство, чтобы вы могли поразмышлять о том, что представляют собой разумное и необоснованное лидерство скрам-мастера.

Становление команды в Service1st

Когда компания переходит на скрам, сильнее всего изменяется команда. Раньше руководитель проекта говорил, что нужно делать, а теперь необходимо выяснять это самостоятельно. Раньше участники команды работали обособленно, а теперь им нужно работать друг с другом. Раньше у участников команды было много времени на завершение работ по релизу, а теперь их попросят собирать готовое к поставке программное обеспечение в конце каждого спринта. Во второй, четвертой и седьмой главах мы уже рассмотрели несколько примеров использования скрама в компании Service1st. В этой главе мы увидим трудности и невзгоды, через которые прошла команда разработки, пока Service1st изучала скрам от и до.

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

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

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

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

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

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

Команды в Service1st встречались каждый день. Скрам-мастер нескольких команд Алисия решительно и профессионально организовывала ежедневные скрамы, помогая командам завершить их в течение 15 минут. Поскольку команды заранее договорились об этом формате, она гарантировала, чтобы каждый ответил на три вопроса:

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

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

3. Мешает ли что-то мне или команде достичь цели спринта?

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

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

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

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

Убеждение, что нами должен кто-то управлять, крепко укоренилось в нашей жизни и на работе. Родители, учителя и боссы, которые учат нас управлять собой, а не стремиться оправдать их ожидания, редки. Тогда почему мы ожидаем, что, сообщив команде, что теперь она сама отвечает за управление собой, она поймет, что мы имеем в виду? «Самоуправление» – это просто термин, еще не привязанный к реальности. Команде разработки нужен живой опыт работы по скраму, чтобы действительно понять, как управлять собой и как взять на себя ответственность и полномочия по планированию, координации и выполнению своих задач. Скрам-мастер должен не только помочь команде приобрести этот опыт, но и преодолеть свои собственные привычки и склонность к управлению командой. И скрам-мастер, и команда разработки должны изучить и понять новый для них подход к управлению.

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

Собравшись, я повторил для команды концепцию готового к поставке инкремента продукта. Каждый спринт команда разработки обязуется превращать выбранный элементы продукта в такой инкремент. Для того чтобы функциональность была готовой к поставке пользователям, она должна быть чистой. Участники команды хотели знать, что я имел в виду под «чистой». Без дефектов? Я ответил утвердительно, добавив, что чистый код не содержит как ошибок, так и заумных программистских трюков, а также соответствует стандартам кодирования и прошел рефакторинг для удаления любых дублей и изменения плохо структурированного кода, он прост для чтения и понимания. Если код удовлетворяет всем этим требованиям, система более устойчива и проще поддерживается. Если нет, то код станет раздутым, нечитаемым и сложным для отладки, а разработка функциональности в будущих спринтах занимает все больше времени. Я также напомнил участникам, что скрам требует прозрачности. Когда команда разработки демонстрирует функциональность владельцу продукта и заинтересованным лицам на обзоре спринта, они имеют полное право предполагать, что работа завершена. Завершена – значит, не только код написан, но и написан в соответствии со стандартами, легко читается, претерпел рефакторинг. Значит, компонент протестирован, автоматический тест написан и пройден, функциональность проверена. Если это не так, команде нельзя демонстрировать функциональность, потому что в этом случае зрители будут предполагать другое.

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

Участники команды смотрели на меня смущенно. Они рассказали, что без особенных обстоятельств или указания они собирают систему только в конце шестимесячного цикла разработки релиза. Используя скрам, они планировали начать собирать систему с последней недели месячного спринта. Тогда-то они и приступили бы к чистке кода. Это откровение застало меня врасплох. Когда участники команды сообщали во время ежедневного скрама, что конкретная функция готова, ее код еще даже не был добавлен в единый репозиторий, система не была собрана и протестирована. Я уточнил, так ли это. На встрече неожиданно повисла тишина. Все осознали: есть проблема. Один участник команды разработки, Джареш, поделился, что обычно он дорабатывает локальную копию кода от 5 до 10 дней и только потом отправляет изменения на сервер. Он поинтересовался, как часто он может возвращать[20] измененный код в единый репозиторий? Я спросил, как он понимает, что вносимые им изменения не противоречат коду, над которым работают другие разработчики при столь редких синхронизациях с базовой версией? Джареш ответил, что, если будет возвращать изменения кода часто, ему придется устранять разногласия между фрагментами кода ежедневно, а внося изменения на сервер только после завершения разработки функции, он может производить такую корректировку лишь один раз.

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

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

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

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

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

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

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

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

Что стало результатом ретроспективы спринта? Многие в Service1st были рады помочь друг другу. Когда кто-то отставал, другие участники команды были рядом. Некоторые программисты были рады сидеть рядом с тестировщиками, потому что еще в процессе кодирования могли понять полный набор тестов, которые впоследствии будут применены к системе. Все были довольны, а очевидный прогресс достигнут уже через два спринта после начала цикла создания релиза. Один программист был в восторге оттого, что ему пришлось общаться и работать с проектировщиком, с которым он не обменялся и фразой за три года работы в Service1st.

Что можно улучшить? Участники команды, которые были назначены сразу в несколько команд, не были довольны этим. Они не могли сосредоточиться на одной группе задач, и им не удалось понять, как распределить свое время, чтобы быть доступными для каждой команды при наличии такой потребности. Большинство команд были недовольны перегородками между рабочими местами. Первоначально они полагали, что им нужна приватность, но в итоге начали чувствовать, что стены мешают сотрудничеству. Все команды считали, что им не хватает навыков для выполнения работы: одним не хватало тестировщиков, а другим – технических писателей.

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

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

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

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

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

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

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

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

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

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

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

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

Бабатунде Огуннайке и Хармон Рэй. Динамика, моделирование и управление процессами (Process Dynamics, Modeling, and Control)

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

Как скрам улучшает оценки

Первый спринт команды является самым грубым и неточным. Часто это первый раз, когда участники команды работают вместе, и, безусловно, это первый раз, когда они работают вместе над конкретной задачей из бэклога продукта. Она может быть хорошо известна команде разработки и тем не менее требовать более глубокого понимания. Используемая командой технология могла использоваться раньше, но часто в проект попадает по крайней мере одна новая технология или ее новая версия. И вот приходим мы и просим команду, которая находится в этом комплексном тумане неточности, определить, что она сможет поставить за один спринт, и взять на себя ответственность за это. Мы просим участников команды ответить на этот вопрос к концу события по планированию спринта (максимальная длительность планирования составляет восемь часов для спринта длительностью один месяц). Конечно, их оценка будет неточной!

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

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

Что происходит, если фактические значения сравниваются с оценками и планами

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

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

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

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

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

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

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

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

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

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

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

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

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

WebNewSite: дать команде шанс

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

WebNewSite было одним из первых новостных интернет-издательств. Публикация новостей осуществлялась с помощью своего продукта NewsWeb, а ключом к конкурентному преимуществу был движок лексико-синтаксического разбора. Принимая потоки данных из многих источников, он быстро разбирал информацию, чтобы в дальнейшем ее можно было найти по категории, времени, теме, ключевому слову и почти всему, что можно придумать. Этот движок спроектировали и разработали Джефф Сазерленд, второй создатель скрама, и Томас Сан, затворнический кандидат наук Массачусетского технологического института. Впоследствии Джефф возглавил подразделение разработки в WebNewSite, Томас остался мозговым центром движка лексико-синтаксического разбора.

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

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

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

Через три дня после ухода Томаса в отпуск лексико-синтаксический движок начал икать, а затем случился приступ. Новые перестановки в новостных лентах выявили недостатки в работе Томаса. В это время он был где-то далеко, совершенно недоступный для команды. Настроение команды менялось от отчаяния к ярости. Как участники команды разработки могли выполнить свои обязательства и поставить то, что отдел продаж уже пообещал подписчикам? Как Томас мог так поступить с ними? Разве он не понимал, что они взяли обязательство? Почему он не предусмотрел способ связи, чтобы помочь им, подсказав исправление?

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

К сожалению для Томаса и его планов на отпуск, я поклонник детективных романов. «Конечно! Найму частного детектива для поиска Томаса», – подумал я. После некоторых изысканий я вышел на бывшего агента ФБР с офисом в Биллингсе, штат Монтана. Обрадовавшийся возможности работать на интернет-стартап, он нашел Томаса за два дня. Томас смог помочь команде, и цель спринта была достигнута. Я считаю, что проявил неплохую изобретательность, потратив всего несколько сотен долларов на нетрадиционный обход серьезного препятствия.

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

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

Выводы

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

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

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

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

Во время моего последнего визита компания Service1st уже была отличным местом. Я видел, как люди стремятся улучшить организацию, команды, себя и свою профессию. Я горжусь тем, что знаком с ними. За последнее десятилетие я помог реализовать скрам в сотнях организаций и уверен, что это заслуженный ожидаемый результат. Что еще можно просить от жизни?

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

Ядром, вокруг которого происходит все масштабирование, являются скрам-команды. Проект на 800 человек будет состоять из 100 команд по 8 человек. В этой главе мы рассмотрим, как координировать работу этих команд, сохраняя при этом производительность каждой отдельной команды. Мы также рассмотрим, как масштабировать проекты независимо от количества участников, предметной области программного приложения, технологии системы, количества локаций сотрудников и других аспектов масштабирования. В этой главе я продемонстрирую применение методов масштабирования скрама в критически важном проекте с сильным желанием руководства масштабировать его, чтобы несколько команд имели возможность разрабатывать один программный продукт одновременно из нескольких географических мест.

Масштабирование в MegaFund

Мы рассматривали компанию MegaFund в третьей и пятой главах. Если вы, будучи клиентом MegaFund в 1997 году, хотели перевести деньги, открыть счет, торговать ценными бумагами или воспользоваться любым другим финансовым предложением MegaFund, у вас было два варианта: позвонить агенту по телефону или пойти в ближайший офис MegaFund и использовать туповатый терминал типа IBM 3270, подключенный через сеть к мейнфреймам компании. Хотя эта технология и была новаторской в 1980-х годах, спустя 17 лет конкуренты MegaFund позволяли клиентам самостоятельно управлять своими учетными записями с домашних или офисных компьютеров, сотовых телефонов, веб-устройств, пейджеров и телефонных голосовых систем в любой день в любое время. Это несоответствие стало неотложной бизнес-проблемой MegaFund. Требовалось как можно скорее устранить отставание от конкурентов и предоставить клиентам новую технологию. Все в MegaFund хотели начать свой собственный проект и тут же создать конкурентоспособное предложение.

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

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

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

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

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

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

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

1. Еще до начала масштабирования постройте соответствующую инфраструктуру.

2. Даже при построении инфраструктуры всегда создавайте и предоставляйте ценность для бизнеса.

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

Эти практики более подробно описаны в следующем разделе.

Масштабирование скрама

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

Все, что поддерживает масштабирование проекта, должно быть разработано и реализовано до начала масштабирования. Вся эта работа выполняется в спринтах.

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

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

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

декомпозировать бизнес-архитектуру для возможности разработки системы несколькими командами с использованием понятных интерфейсов;

декомпозировать системную архитектуру для возможности разработки системы несколькими командами с использованием понятных интерфейсов;

при необходимости определить и внедрить среду разработки для поддержки распределенных команд.

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

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

Эти подходы оказались полезными при масштабировании проекта «Год 2000» (Y2K)[23]. В конце 1990-х годов почти каждая организация пыталась добиться, чтобы ее программное обеспечение поддерживало даты позднее 1999 года и не создавало проблем на заре XXI века. В следующем разделе я расскажу, как одна компания успешно применила подходы к масштабированию скрама в крупном проекте, направленном на обновление программного обеспечения для Y2K, и помогла клиентам обновить версию системы.

Масштабирование в Medcinsoft

Компания Medcinsoft использовала скрам для управления проектом Y2K, целями которого были адаптация продуктов Medcinsoft к датам после 31 декабря 1999 года, установка обновлений программного обеспечения более чем в 350 крупных организациях здравоохранения, обучение персонала больниц, стабилизация установленного обновления до 1 октября 1999 года. Программное обеспечение Medcinsoft автоматизирует административные документы организаций здравоохранения, включая регистрацию пациентов, выписки, выставление счетов на оплату, страхование, ведение медицинских карт, учет задолженностей клиентов. Неудача такого программного обеспечения имела бы катастрофические последствия для этих организаций и обслуживаемого ими населения. До начала использования скрама компания Medcinsoft для управления проектами применяла диаграммы Ганта, но они оказались крайне неуместными. Клиенты были недовольны: релизы часто задерживались на несколько месяцев, имели пугающее количество ошибок и не содержали ожидаемых функций.

Проект Y2K был комплексным и требовал масштабирования в нескольких измерениях одновременно. Необходимо было координировать работу более 300 разработчиков, определив приоритеты задач по реализации нового функционала различных продуктов, устранению «ошибки 2000 года» и исправлению дефектов. Более 400 полевых сотрудников поддержки нуждались в приоритизации и координации их работы и взаимодействия с клиентами Medcinsoft. Более 600 сотрудников из 350 организаций-клиентов нуждались в возможности сообщать в Medcinsoft о планах и изменениях в них. Клиенты работали с разными версиями программного обеспечения Medcinsoft, доработанными и настроенными под их конкретные потребности. У каждого клиента был свой уникальный график обновления используемых им систем, в том числе и обновления программного обеспечения Medcinsoft по проблеме Y2K. У клиентов также были уникальные расписания тестирования устанавливаемых систем и обновлений. Проще говоря, графики установки и тестирования и уровни знаний и навыков клиентов Medcinsoft существенно различались.

Скрам уже применялся успешно в одном из проектов Medcinsoft, поэтому руководство спросило менеджера проекта Y2K Джека Харта, сможет ли он использовать скрам для исправления ситуации. Самыми большими проблемами, стоящими перед Джеком, были сложность координации выполняемой работы и изменчивость сроков в разных частях этой работы. Для адекватной координации ему нужна была точная и своевременная информация. Нерегулярная информация о планах клиентов часто оказывалась противоречивой, а информация о статусе релизов – недостоверной. Задержки в предоставлении релизов достигали нескольких недель. Клиенты и полевые инженеры поддержки общались друг с другом неэффективно или не общались вообще.

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

Перечисленных проблем было предостаточно, но список трудностей Джека на этом не заканчивался. Несмотря на то что ранее проводились обширные и внимательные поиски недочетов по проблеме Y2K в соответствии с отраслевыми и внутриорганизационными рекомендациями, новые дефекты Y2K все еще регулярно обнаруживались. Кроме того, Medcinsoft планировала добавить в релиз Y2K новую функциональность веб-доступа, а ошибки, возникающие при ее реализации, оказались трудными для обнаружения. По мере устранения новых дефектов часто создавались другие – регрессионные дефекты. Некоторые части программного обеспечения были очень древними. Написавшие код разработчики уже е работали в компании и не могли внести исправления Y2K или хотя бы помочь советом, поэтому сегодняшним разработчикам приходилось параллельно изучать и обновлять код. При этом базовое программное обеспечение было велико согласно почти любым стандартам, оно оценивалось в 2500 функциональных единиц[24]. Особенности управления программным обеспечением со стороны клиентов Medcinsoft дополнительно осложняли ситуацию. Многие компании никогда не проводили столь массивную модернизацию своих систем и не были готовы к этому. У неожиданно большого числа клиентов не было ни тестовых сред, ни понятных отлаженных процессов проверки новых релизов.

Скрам обеспечивает определенную степень регулярности и предсказуемости в комплексной или хаотичной среде. Именно таким был проект Y2K, поэтому Джек решил применить скрам ко всем аспектам проекта, даже к действиям полевых инженеров на площадках клиентов. Джек синхронизировал релизы с 30-дневными спринтами: в конце каждого спринта Medcinsoft предоставляла клиентам новую рабочую версию программного обеспечения. Каждый спринт выпускался релиз, содержащий самые приоритетные элементы бэклога продукта и обнаруженные в процессе разработки критические ошибки. Однако Джек испытывал затруднения в своевременном получении точной информации о приоритетах клиентов, датах установки и критических исправлениях. Информацию о потребностях каждой компании-клиента предоставляли полевые инженеры поддержки, с которыми общались разные сотрудники организации-заказчика. Поэтому Джеку нужен был нормализующий фильтр и прием, позволяющий сделать эту информацию своевременной, предсказуемой и точной. Таким приемом стали ежедневные скрамы для клиентов, которым релиз Y2K от Medcinsoft требовался в течение трех месяцев, и еженедельные версии ежедневных скрамов для клиентов, дата релиза которых была позднее трех месяцев. На каждом событии ежедневного скрама клиент и полевые сотрудники службы поддержки Medcinsoft обсуждали текущее состояние и проблемы проекта. Они поддерживали в актуальном состоянии планируемую дату очередного релиза программного обеспечения Medcinsoft и упорядоченный по приоритету бэклог релиза клиента, содержащий список требуемых доработок, настроек, функциональных возможностей системы, оставшихся критических и высокоприоритетных дефектов (см. рис. 9.2). У каждого клиента был свой собственный бэклог продукта, эволюционирующий со временем.

Полевые инженеры агрегировали бэклоги клиентов в бэклоги Medcinsoft по районам, затем районные – в бэклоги по регионам (см. рис. 9.3), а региональные – в единый «бэклог службы поддержки Medcinsoft». При любом изменении бэклога клиента изменялась и соответствующая ему часть в бэклоге службы поддержки Medcinsoft. Затем этот комбинированный бэклог упорядочивался по приоритету, чтобы планировать работу среди всех клиентов. Руководители полевых инженеров использовали его, чтобы распределять персонал на местах для выполнения настроек и оказания помощи во внедрении, тестировании и тиражировании программного обеспечения.

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

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

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

Часть верхних элементов бэклога продукта в начале спринта могла выглядеть так:

дефект неправильной даты печати в заголовке отчета в модуле или отчете;

дефект отображения неправильного года на экранной форме в модуле демографических данных пациента;

модуль демографических данных пациента зависает при вводе 2010 года в поле даты;

новый подключаемый модуль от поставщика программного обеспечения для устранения проблемы с переносом даты;

ошибка в модуле демографических данных пациента: экранная форма изменения адреса не возвращается к корректной предыдущей странице;

клиент MediLife запрашивает релиз для внедрения (в настоящее время установлена версия 8.1);

клиент MedClinic запрашивает релиз для внедрения (в настоящее время установлена версия 7.2).

Команды разработки были сгруппированы по функциональности, например СОЗ (счета клиентов, оплата по выставленным счетам, задолженность клиентов), РАСП (ведение расписаний) и т. д. (см. рис. 9.4). На планировании спринта Джуди помогала каждой команде разработки выбрать элементы бэклога продукта, соответствующие ее функциональной области. Участники команды работали в Medcinsoft достаточно долго, поэтому выбор исполнителей не вызывал вопросов. Если задач для полной загрузки команды было недостаточно, то команда во время этого спринта работала над проектом Y2K только часть своего времени, а оставшуюся часть – над другими проектами. Джек использовал такой подход, чтобы обеспечить четкое разделение работы, поскольку над элементами бэклога продукта Y2K могли одновременно работать до 20 команд по 10 участников в каждой. Среди этих команд находились функциональные команды, команды сборки системы, команды обнаружения дефектов Y2K, команды тестирования и команды релизов.

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

Обнаруживаемые ошибки вносились в систему отслеживания дефектов. Одни ошибки команда тестирования находила при регрессионной проверке создаваемого инкремента продукта. Другие были ошибками Y2K и выявлялись в ходе их постоянного поиска для снижения возможных последствий неправильной работы программного обеспечения в связи с этой проблемой. Третья группа ошибок возникала при установке и тестировании релизов Y2K на площадках заказчиков. Изначально Medcinsoft намеревалась исправить все ошибки и дефекты вплоть до финальной версии релиза Y2K, запланированной к выпуску 1 октября 1999 года. Но такой план был отвергнут клиентами. Они хотели как можно скорее обезопасить себя, «задраив люки» задолго до начала 2000 года. Чтобы успеть в более сжатые сроки и повысить целостность каждого релиза, Джуди анализировала новые дефекты перед ежедневным скрамом, а затем добвляла все критические и высокоприоритетные ошибки в бэклоги спринтов различных команд, работавших над этим релизом. Этим действием Джуди явно нарушала правило скрама, согласно которому никакая внешняя работа не может добавляться в спринт команды после его начала. Тем не менее другая практика скрама – «руководствуйся здравым смыслом» – одержала верх, поскольку поставка новых релизов без незамедлительного устранения дефектов просто впустую потратила бы время клиентов и спровоцировала бы дополнительные проблемы.

Джек установил скрам-командам следующие правила для управления своим временем и работой, сказав, что задачи Y2K имеют наивысший приоритет. Если они выделили только 50 % своего времени на задачи спринта, а оставшиеся 50 % времени работали над другими вещами, то о последних можно забыть, пока не будут исправлены все ошибки и дефекты Y2K. Если команда разработки была загружена задачами Y2K на 100 %, то участники команды должны пойти в остальные команды и пригласить других инженеров помочь устранить все ошибки Y2K до последней.

Компания Medcinsoft успешно обошла комплексные отмели проекта Y2K и удовлетворила потребности своих клиентов за счет постоянной инспекции, анализа, выработки решений и адаптации. Многие из участвующих в этом проекте команд не разрабатывали программное обеспечение; они тестировали его, устанавливали его, координировали деятельность. И тем не менее все они использовали механизмы инспекции и адаптации скрама, чтобы оставаться в курсе любых изменений.

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

Выводы

Когда я рассказал эту историю на встрече скрам-мастеров в Милане в июне 2003 года, Мел Пуллен отметил, что считает практику скрама скрамов противоречащей принципам самоорганизации и самоуправления скрама. Иерархические структуры навязаны руководством, утверждал Мел, а не теми, кто фактически выполняет работу. Почему бы не дать каждой команде выяснить, с какими другими командами нужно сотрудничать и координировать работу и где команды зависимы? Либо скрам-мастер сможет указать на зависимость от другой команды, либо команда разработки сама столкнется с зависимостью в процессе работы. Наткнувшись на зависимость, команда может отправить участника в качестве «цыпленка» на ежедневный скрам другой команды, работающей над зависимостью. Если никто не работает над этой зависимостью, команда может попросить владельца продукта создать соответствующий элемент бэклога продукта с высоким приоритетом. Скрам-мастер может либо позволить первой команде самостоятельно решить проблему зависимости, либо помочь сформировать другую команду для этого.

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

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

Планирование спринта

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

В ходе планирования спринта скрам-команда принимает решения по двум темам:

каким будет инкремент продукта в конце спринта;

как организовать свою работу, чтобы получить готовый к поставке инкремент.

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

Команда разработки прогнозирует объем функциональности, который будет разработан в течение спринта. Владелец продукта выносит на обсуждение два важных вопроса:

бизнес-цели, которые должны быть достигнуты в спринте;

элементы бэклога продукта, необходимые для достижения цели спринта.

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

Цель спринта

Цель спринта – это установленный для спринта ориентир, который достигается через выполнение части бэклога продукта. Она формируется во время его планирования и объясняет команде разработки, для чего создается инкремент.

Цель спринта оставляет команде разработки некоторую гибкость в объеме функциональности, которую она разрабатывает в рамках спринта. Так, выбранные элементы бэклога продукта могут реализовывать одну связанную функцию, которая является целью спринта. Или целью спринта может быть любая другая логическая связь, для достижения которой команда разработки будет работать совместно, а не разрозненно над разными задачами.

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