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

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

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

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

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

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

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

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

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

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

Все откинулись на стульях. Менеджер по разработке систем Эд пообещал готовую систему через пять месяцев. Учитывая длину наших спринтов в один месяц, грубые расчеты показали, что система будет готова через семь. Никто не произнес вслух, но все знали, что дополнительные два месяца стали следствием нового определения готовности. Оставив первоначальные оценки команды разработки, мы, возможно, получили бы оценку в пять месяцев. Более того, команда, вероятно, реализовала бы в этот срок систему, однако она не соответствовала бы новому определению готовности. Но поскольку теперь Джули понимала, что означает «готово», она понимала и то, что требуется дополнительное время. Взглянув на Джули, я спросил, хочет ли она вернуться к старым оценкам. Джули была расстроена и поинтересовалась, почему мы пообещали срок в пять месяцев, заранее зная, что будем поставлять систему, не отвечающую требованиям. Я ответил, что мы не знали этого и не могли достоверно предсказать срок до сегодняшней сессии планирования.

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

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

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

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

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

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