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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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