Оценка и планирование критически важны для успеха проекта по разработке программного обеспечения любого размера и значимости. Планы определяют наши инвестиционные решения: мы можем взяться за проект, на выполнение которого, по нашим оценкам, потребуется полгода и $1 млн[1], и отказаться от этого же проекта, если на него потребуется два года и $4 млн. Планы помогают нам понять, кого нужно привлечь к работам по проекту в течение определенного периода. Планы помогают нам понять, как продвигается создание функциональности, которая нужна пользователям и получения которой они ожидают. Без планов мы открываем ворота для целого ряда проблем.

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

Тот факт, что оценка и планирование — дело непростое, не является открытием. Это известно давным-давно. В 1981 г. Барри Боэм построил первую версию того, что Стив Макконнелл (Steve McConnell, 1998) позднее назвал «конус неопределенности». На рис. 1.1 показаны первоначальные диапазоны неопределенности Боэма в разных точках в процессе последовательного развития («каскадный процесс»). Конус неопределенности говорит о том, что на этапе оценки осуществимости проекта оценка обычно отклоняется от истины на 60–160 %. Иначе говоря, на проект, который, как ожидается, должен занять 20 недель, может потребоваться от 12 до 32 недель. После формулирования требований в письменном виде оценка может отклоняться на ±15 % в любом направлении, т. е. плановый срок 20 недель может сократиться до 17 недель или вырасти до 23 недель.

Институт управления проектами (Project Management Institute — PMI) имеет сходную точку зрения на постепенное повышение точности оценок, однако он считает, что конус неопределенности должен быть асимметричным. PMI предлагает принимать начальный уровень отклонений оценки в диапазоне от +75 % до –25 %. Следующий этап — бюджетные предположения — предполагает диапазон отклонений от +25 % до –10 %, за ним следует этап окончательной бюджетной оценки с диапазоном отклонений от +10 % до –5 %.

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

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

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

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

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

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

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

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

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

Итак, при определении agile-подхода к планированию мы установили, что он:

• фокусируется на планировании, а не на плане;

• поощряет изменения;

• приводит к составлению планов, легко поддающихся изменению;

• распределяет процесс планирования по всему сроку осуществление проекта.

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

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

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

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

2. Какие еще доводы в пользу планирования вы можете привести?

3. Вспомните один или два наиболее успешных проекта, в которых вы участвовали. Какую роль планирование играло в этих проектах?

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

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

• почти две трети проектов значительно превышают сметы затрат (Lederer and Prasad, 1992);

• 64 % функций, включенных в продукты, используются редко или вообще не используются (Johnson, 2002);

• срок выполнения среднего проекта превышает календарный график на 100 % (Standish, 2001).

Второй причиной неудовлетворительных результатов традиционных подходов к планированию является многозадачность, под которой понимается одновременное выполнение нескольких задач. Многозадачность ужасным образом сказывается на производительности. Кларк и Уилрайт (Clark and Wheelwright, 1993) в своем исследовании эффектов многозадачности пришли к выводу, что время, посвящаемое создающей стоимость работе, быстро сокращается, когда человек занимается более чем двумя задачами. Этот эффект виден на рис. 2.2, где представлены результаты этого исследования.

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

Многозадачность нередко превращается в проблему, когда какие-либо проектные работы начинают завершаться с запозданием. В этом случае взаимозависимость между видами работ становится критически важной. Разработчик, ожидающий завершения задачи своим коллегой, начинает просить последнего предоставить ему хотя бы сокращенную версию, чтобы можно было продолжить работу. Допустим, мне отведено 10 дней на работу с определенными изменениями базы данных, потом 10 дней на реализацию интерфейса прикладной программы (ИПП) для доступа к базе данных, а затем 10 дней на разработку пользовательского интерфейса. Эта ситуация отражена в верхней части рис. 2.3. Ваша работа не может начаться до тех пор, пока вы не получите ИПП от меня. Вы просите меня сделать необходимый минимум работы по ИПП, чтобы начать выполнение своей задачи. Аналогичным образом тестировщик просит меня сделать минимальную версию пользовательского интерфейса, чтобы он мог начать тестирование. Я соглашаюсь, и мой календарный график приобретает вид, представленный в нижней части рис. 2.3.

Это зачастую создает иллюзию скорости, однако, как видно на рис. 2.3, моя работа над базой данных и ИПП завершается позже, чем первоначально планировалось. Вряд ли стоит сомневаться в том, что это повлияет на последующие запланированные работы. Кроме того, в нашем примере каждый из затребованных видов работ остается незавершенным в течение 20, а не 10 дней, которые потребовались бы при последовательном выполнении работ.

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

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

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

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

Четвертый изъян традиционных подходов к планированию — игнорирование неопределенности. Мы не принимаем во внимание неопределенность, связанную с продуктом, и считаем, что первоначальный анализ требований позволяет определить полный и идеальный набор характеристик продукта. Мы исходим из того, что пользователи не передумают, не изменят свое мнение и не выдвинут новые требования в период, охватываемый планом.

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

Несмотря на неопределенность, календарные графики зачастую содержат конкретные, безусловные даты, например «Поставка продукта — 30 июня». В начале проекта неопределенность наиболее высока. Оценки, которые мы даем, должны отражать эту неопределенность. Можно, например, представить срок окончания в виде диапазона: «Поставка продукта — июнь — август». Оценки по мере выполнения проекта и устранения неопределенности и риска можно пересматривать и уточнять. Именно в этом суть конуса неопределенности, представленного в главе 1 «Цель планирования».

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

Любая оценка — это вероятностная величина, предполагающая, что работа будет выполнена в расчетный срок. Допустим, вашей команде дают задание разработать новый высокоэффективный текстовый процессор. Вероятность завершения этой работы к концу недели равна 0 %. Вероятность ее выполнения через 10 лет равна 100 %. Если я попрошу вас дать оценку срока и вы назовете конец недели, то вероятность ее реализации будет нулевой. Если вы назовете 10 лет, то вероятность реализации оценки будет 100 %-ной. Вероятность реализации всех оценок в диапазоне от конца недели до 10 лет будет находиться в интервале от 0 до 100 % (Armour, 2002).

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

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

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

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

1. Какие проблемы возникают, если планы составляются на основе видов деятельности, а не на основе поставляемых функций?

2. Существует ли у вас практика отождествления оценки и обязательства? Какие проблемы это влечет? Что можно сделать для изменения ситуации?

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

Хотя этот процесс начался намного раньше, официально agile-движение существует с момента принятия Agile-манифеста в феврале 2001 г. (Beck et al.). Манифест был разработан и подписан 17 «идеологами облегченных методологий», как они называли себя в то время. Их документ дал и название проповедуемому ими подходу к разработке программного обеспечения, и заявления о ценностях. Авторы Agile-манифеста писали о том, что для них более значительную ценность имеют:

• люди и взаимодействия, а не процессы и инструменты;

• работающая программа, а не полный пакет документации;

• сотрудничество с клиентом, а не переговоры по условиям контракта;

• реагирование на изменение, а не следование плану.

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

Работа agile-команды разбивается на короткие, ограниченные по времени итерации, и каждая из них завершается поставкой работоспособного продукта. Функции, разрабатываемые в процессе выполнения итераций, выбираются на основе их приоритетности для бизнеса. Это позволяет гарантировать первоочередную разработку наиболее важных функций. Пользовательские истории — наиболее распространенный подход, применяемый agile-командами для представления потребностей пользователей. Agile-команды исходят из того, что планы быстро устаревают. Как результат, они корректируют свои планы по мере необходимости.

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

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

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

1. Как изменилась бы работа над текущим или предыдущим проектом, если бы ваша команда действовала как единое целое?

2. Какие условия удовлетворенности вы идентифицировали для своего текущего проекта? Все ли заинтересованные в проекте лица и участники согласны с ними? Какие риски возникают при осуществлении проекта, когда согласие достигнуто не по всем условиям удовлетворенности?

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

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

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

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

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

Существует два общепринятых подхода к оценке размера в пунктах. Первый заключается в выборе наименьшей истории среди тех, с которыми вы будете работать, и присвоении ей размера, равного одному пункту. Второй предполагает выбор истории среднего размера и присвоение ей значения из середины того диапазона пунктов, который вы будете использовать. Я лично предпочитаю использовать диапазон от 1 до 10. (Причина этого объясняется в главе 6 «Методы оценки».) Иначе говоря, я выбираю историю среднего размера и присваиваю ей значение 5 пунктов. После того как вы произвольным образом установили количество пунктов для первой истории, каждая последующая история оценивается относительно первой или любой другой уже оцененной истории.

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

• лабрадор-ретривер;

• терьер;

• немецкий дог;

• пудель;

• такса;

• немецкая овчарка;

• сенбернар;

• бульдог.

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

Мои оценки приведены в табл. 4.1. Я присваивал эти значения, начиная с лабрадора-ретривера. Размер собак этой породы, на мой взгляд, можно отнести к среднему, поэтому я присвоил им значение 5. Немецкий дог будет, пожалуй, в два раза выше, поэтому он получает 10. Сенбернар значительно выше лабрадора, но чуть ниже дога — он получает 9. Такса по росту самая маленькая и больше чем на 1 не тянет. Бульдог повыше, но тоже не вышел ростом, поэтому я даю ему 3. Если бы я присваивал пункты по весу собак, то бульдог получил бы больше.

Agile-проект нередко начинается с итерации с неполным набором требований, детали которых выясняются в процессе работы. Так или иначе, нам нужно дать оценку всем историям, в том числе и тем, которые сформулированы нечетко. Вы уже видели, как это делается на примере присвоения пунктов пуделю и терьеру. Без дополнительной информации оценить их было бы трудно. Как известно, есть карликовые, средние и стандартные пудели и все они разного размера. Аналогичным образом терьеры — это группа, включающая в себя более двух десятков пород. Одни терьеры (белый высокогорный терьер, норвич-терьер, норфолкский терьер) имеют в холке менее 30 см, а другие (эрдельтерьер) — почти 60 см.

Когда вам дают свободно изложенную пользовательскую историю (или описание собаки), вы делаете определенные допущения, строите предположения и принимаете решение. В табл. 4.1 я выдвинул предположения в отношении терьера и пуделя и присвоил им по 3 пункта. По моему разумению, даже самые крупные из них меньше лабрадора-ретривера, а самые мелкие не заслуживают больше 1–2 пунктов. Поэтому среднее значение, равное 3, выглядит довольно правдоподобным.

Пункты — это относительный показатель размера пользовательской истории. Пользовательская история, оцененная в 10 пунктов, в два раза больше, сложнее или рискованнее, чем история, оцененная в 5 пунктов. Аналогичным образом 10-пунктовая история в два раза меньше по размеру, сложности или рискованности, чем 20-пунктовая история. Что здесь по-настоящему важно, так это относительные значения, присвоенные разным историям.

Скорость — это показатель темпа продвижения команды при осуществлении итерации. В конце каждой итерации команда может взять реализованные истории и определить свою скорость путем суммирования оценок всех этих историй в пунктах.

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

1. Во сколько пунктов вы бы оценили те или иные функции своего текущего проекта?

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

3. Сказать, что две вещи очень близкого размера одинаковы, нетрудно. В пределах какого диапазона размеров (от наименьшего объекта до наибольшего) вы могли бы дать надежную оценку? От одного до пяти? От одного до 10? От одного до 100? От одного до 1000?

Сколько времени идет матч в американском футболе?

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

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

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

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

Конечно, из телевизионной программы я могу узнать, что игра начинается в 13:00 и заканчивается в 16:00. Из этого следует, что кто-то в телевизионной компании оценил общее затраченное время. Что известно компании, а нам нет? Ей известен целый ряд моментов. Во-первых, она собирается добавлять или удалять рекламу в зависимости от того, как быстро будет продвигаться игра. Во-вторых, продолжительность большинства матчей близка к трем часам. Если матч заканчивается раньше, то телевизионная компания добавляет в трансляцию рекламу, интервью или другие заставки. Если матч продолжается дольше, то в чем проблема? Зрители, которые интересуются игрой, будут смотреть ее хоть на 15, хоть на 30 минут дольше. Они не выключат телевизор просто потому, что в программе значится время окончания матча 16:00. Зрители, которым матч не интересен, но которые включили канал, чтобы посмотреть другую передачу в 16:00, тоже, скорее всего, подождут, если задержка не будет слишком долгой. Наконец, за десятилетия трансляции футбольных матчей телевизионная компания приучила нас не рассчитывать на окончание матча минута в минуту.

Этот последний момент очень важен. В результате многолетней практики большинство футбольных болельщиков знают, что время окончания матча 16:00 — всего лишь оценка. Никто не удивится, если игра продлится до 16:15 (превышение на 8 %). Болельщики могут расстроиться или рассердиться, но не удивиться. Почему же тогда мы удивляемся, если проект по разработке программного обеспечения, оцененный в 12 месяцев, занимает 13 месяцев (превышение на те же 8 %)? Какой срок труднее оценить?

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

• поддержка текущего релиза;

• отсутствие из-за болезни;

• совещания;

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

• работа с персоналом;

• телефонные переговоры;

• специальные проекты;

• повышение квалификации;

• электронная переписка;

• анализ сделанного и прогоны;

• собеседования с кандидатами;

• переключение на другие задачи;

• устранение ошибок в текущих релизах;

• управленческий анализ.

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

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

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

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

Хотя на это редко когда стоит тратить силы, иногда такой подход просто необходим. Не так давно у меня был клиент, работающий с тремя версиями продукта — одна для Macintosh, другая для Windows и третья для карманных компьютеров. В этом случае критически важно обеспечить абсолютно одинаковую функциональность. Более того, члены команды на тот момент не могли переключаться с разработок для Mac на разработки для Windows и карманных компьютеров. В такой ситуации оценка идеального времени для каждой роли по каждой истории может быть полезна. Следует, однако, учитывать, что это увеличивает бремя администрирования.

Идеальное время и общее затраченное время — не одно и то же. Идеальное время игры в американский футбол составляет 60 минут (четыре 15-минутных периода). Вместе с тем для завершения 60-минутного матча обычно требуется около трех часов. Такая разница объясняется наличием перерывов в игре.

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

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

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

2. Можно ли как-то улучшить ситуацию?

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

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

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

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

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

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

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

Agile-команды предпочитают держаться ближе к левому краю графика на рис. 6.1. Они признают невозможность устранения неопределенности оценок, однако считают, что небольшие усилия приносят большой результат. Хотя agile-команды не так далеко продвигаются по осям точности/усилий, их планы более надежны, поскольку они часто поставляют полностью работоспособные, протестированные, интегрированные программы с небольшими дополнениями.

Оценкой занимается не какой-то один представитель команды. Agile-команды не полагаются на оценку единственного эксперта. Несмотря на хорошо известный факт, что оценка, подготовленная тем, кто выполняет работу, лучше оценки, данной кем-то другим (Lederer and Prasad, 1992), наилучшими являются коллективные оценки членов команды, которые участвуют в работе. Это объясняется двумя причинами.

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

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

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

Во-первых, покер планирования сводит вместе мнения нескольких экспертов и позволяет получить общую оценку. Поскольку эти эксперты образуют кроссфункциональную команду, представляющую все дисциплины софтверного проекта, они более компетентны в сфере оценки, чем кто-либо другой. На основе тщательного анализа литературы по оценке программного обеспечения Йоргенсен (Jørgensen, 2004) пришел к выводу, что «оценивать задачи должны те, кто наиболее компетентен в их выполнении».

Во-вторых, в процессе игры в покер планирования возникает живой диалог, и оценщики обращаются к мнению коллег для подтверждения своих оценок. Это повышает точность оценки, особенно когда дело касается объектов со значительным уровнем неопределенности (Hagafors and Brehmer, 1983). Обращение за подтверждением оценок в определенной мере компенсирует недостаток информации (Brenner at al., 1996). Это очень важно в agile-проекте, поскольку оцениваемые пользовательские истории нередко намеренно составляются нечетко.

В-третьих, исследования показывают, что усреднение индивидуальных оценок дает лучшие результаты (Hoest and Wohlin, 1998), как и коллективное обсуждение оценок (Jørgensen and Moløkken, 2002). Коллективное обсуждение является основой покера планирования, а такие обсуждения ведут к усреднению различных индивидуальных оценок.

Наконец, покер планирования работает, потому что это занятие доставляет удовольствие.

Более значительные затраты времени и усилий на оценку не обязательно повышают точность результата. Трудозатраты на оценку должны определяться целью этой оценки. Хотя все знают, что наилучшие оценки дают те, кто выполняет работу, в agile-команде исполнитель работы не известен заранее. Таким образом, оценка должна представлять собой коллективную деятельность членов команды.

Оценки должны проводиться по заранее определенной шкале. Функции, с которыми будут работать в ближайшем будущем и которые требуют относительно надежной оценки, должны быть достаточно маленькими, чтобы их можно было оценивать по нелинейной шкале от 1 до 10, такой как 1, 2, 3, 5 и 8 или 1, 2, 4 и 8. Крупные функции, которые, скорее всего, не будут реализованы в ближайших нескольких итерациях, можно оставить крупными и оценивать в таких единицах, как 13, 20, 40 и 100. Некоторые команды добавляют в свою шкалу оценки ноль.

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

1. Насколько правильны ваши оценки сегодня? Какой метод вы в основном используете: экспертную оценку, оценку по аналогии или разбивку?

2. Какую шкалу оценки вы предпочитаете использовать? Почему?

3. Кто должен участвовать в покере планирования для вашего проекта?

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

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

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

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

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

Сначала подчеркну, что при определении скорости я обычно придерживаюсь подхода «всё или ничего»: если история реализована (запрограммирована, протестирована и принята владельцем продукта), то команда получает все пункты, но если в истории что-то осталось недоделанным, она не получает ничего. Если команда предполагает реализовать оставшуюся часть истории в следующей итерации, то такой подход работает хорошо. Ее скорость в первой итерации будет немного ниже ожидаемой, поскольку она ничего не зарабатывает на частично реализованной истории. Во второй итерации, однако, скорость команды будет выше ожидаемой в силу того, что она получит все пункты, хотя часть работы выполнена до начала этой итерации. Это работает хорошо до тех пор, пока все помнят, что нам важно поддерживать стабильную скорость команды на протяжении всего времени, а не учитывать скачки или падения скорости в отдельно взятой итерации.

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

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

Не слишком увлекайтесь процессом переоценки. Когда выясняется, что одна или несколько историй оценены неправильно относительно других историй, старайтесь переоценивать как можно меньше объектов, ограничиваясь лишь приведением относительных оценок в соответствие. Используйте переоценку для учебы и накопления полезного опыта, который пригодится вам при оценке будущих пользовательских историй. Как говорил мне Том Поппендик[5], «неспособность учиться — единственная настоящая ошибка». Учитесь на каждой переоценке истории и приближайтесь к успеху.

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

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

1. Как скорость корректирует неправильные оценки?

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

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

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

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

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

Так вот, хотя команде и предлагается возможность проводить оценку в идеальных днях, я постоянно задаю ее членам вопросы вроде такого: «Насколько велик этот объект по сравнению с тем, что мы оценивали пять минут назад?» или «Так эта история чуть меньше той, что мы только что оценивали?». Цель этих вопросов — перевести разговор в более абстрактную плоскость и переключить внимание на относительный размер историй с обсуждения сроков разработки дизайна экрана, хранимой процедуры и нескольких форм на HTML. В результате команда, начавшая проводить оценку в идеальных днях, может постепенно отделить свои оценки от количества дней.

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

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

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

Лично я предпочитаю пункты. У оценки историй в пунктах больше преимуществ. Когда команда не может понять, насколько полезно разделение оценки размера и срока, я настаиваю, чтобы она начала с оценки в идеальных днях, а потом склоняю к переходу на пункты. Чтобы добиться этого, я чаще спрашиваю членов команды о том, «насколько велик этот объект по сравнению с тем, что мы уже оценивали», а не о том, «сколько идеальных дней потребуется для реализации этого объекта». Большинство команд даже не замечают перехода, а когда все же обращают на него внимание, оценка в пунктах уже входит в привычку.

1. Какой подход вы предпочитаете — использование пунктов или идеальных дней? Почему?

2. Как внедрить такую практику во всей организации? Какие препятствия вы предвидите и как вы предполагаете справиться с ними?

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

• Фиксация всех персональных записей и предоставление пловцам возможности их просмотра.

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

• Предоставление тренерам возможности вводить план тренировок и отслеживать дистанции, пройденные на тренировках.

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

• Импорт и экспорт данных.

• Предоставление официальным представителям возможности следить за результатами заплывов и счетом в соревнованиях.

Чтобы объединить все четыре фактора приоритизации, думайте сначала о стоимости функции по сравнению с затратами, которых эта функция потребует при реализации сегодня. Это позволит определить первоначальный порядок реализации тем. Темами с высоким отношением «стоимость/затраты» следует заниматься в первую очередь.

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

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

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

1. Финансовая стоимость использования функций.

2. Затраты на разработку (и, возможно, поддержку) новых функций.

3. Объем и значимость обучения и нового знания, созданного в результате разработки функций.

4. Величина риска, ликвидированного в результате разработки функций.

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

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

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

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

В табл. 10.1 предусмотрена строка для каждого квартала следующих двух лет. Временной горизонт устанавливается по усмотрению команды. Иногда команды предпочитают определять месячную отдачу для одного или двух лет. По моему опыту, для большинства проектов подходит двухлетний период. Это своего рода золотая середина между гаданием относительно отдаленного будущего и разумным взглядом вперед. Из-за высокой неопределенности, связанной с проектами по разработке программного обеспечения, такого подхода придерживаются и другие (Bills, 2004a).

Табл. 10.1 содержит колонки для различных типов отдачи, которые могут быть у тем. Если в вашем проекте фигурируют другие типы отдачи, измените заголовки соответствующим образом. Аналогичным образом используйте другие заголовки колонок, если требуется их конкретизация (например, «Увеличение дохода от клиентов из США» и «Увеличение дохода от клиентов из Европы»). Совершенно не обязательно иметь для всех тем одинаковый набор колонок.

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

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

Нельзя сравнивать проекты и принимать решения о приоритетах, просто суммируя числа в строке «Итого» рабочего листа вроде того, что показан в табл. 10.2, для каждой темы. Поток доходов, который составляет $100 000 в первом квартале, $200 000 во втором и $500 000 в третьем, имеет значительно меньшую ценность, чем такой же поток, в котором доходы изменяются в обратном порядке. Для сравнения множества тем нам необходим один или несколько стандартных финансовых показателей. В этой главе мы рассмотрим следующие показатели:

• Чистая приведенная стоимость.

• Внутренняя ставка доходности.

• Срок окупаемости.

• Дисконтированный срок окупаемости.

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

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

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

Дополнительная информация по экономике проектов

Хотя в этой главе изложены базовые аспекты использования и расчета четырех финансовых показателей, многое осталось нераскрытым. Дополнительную информацию по вопросу экономики софтверных проектов можно почерпнуть в книге Стива Токи «Рентабельность разработки программного обеспечения: Максимизация доходности инвестиций» (Return on Software: Maximizing the Return on Your Software Investment) (Steve Tocke, 2004). Все четыре финансовых показателя в данной главе и формулы для их расчета позаимствованы из этой книги.

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

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

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

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

1. Если бы вашей организации пришлось выбирать темы, перечисленные в табл. 10.15, каким было бы наиболее приемлемое решение? Почему?

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

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

Я могу разбить особенности этого гостиничного номера на следующие категории:

• Обязательные: кровать, душ, письменный стол, чистота.

• Чем больше, тем лучше: удобство кровати, размер номера, разнообразие и количество тренажеров в фитнес-центре.

• Приятные: встроенные телевизоры на тренажерах «беговая дорожка», бесплатная бутылка воды в номере ежедневно.

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

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

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

Суммарное значение в колонке «Общая стоимость» (в нашем случае 33) представляет стоимость реализации всех функций. Для расчета относительного вклада каждой функции разделите ее общую стоимость на суммарное значение колонки «Общая стоимость». Например, построение графика результатов соревнований имеет стоимость 14. Общая стоимость всех функций составляет 33. Деление 14 на 33 дает 0,42, или 42 %. Это означает, что возможность построения графика результатов соревнований представляет 42 % общей стоимости всех перечисленных функций.

В следующей колонке, «Оценка», приведена оценка в пунктах или идеальных днях. Как и в случае «Общей стоимости», значения этой колонки суммируются (в нашем случае 61), после чего определяется процентная доля каждой оценки (колонка «Затраты, %»). В этом примере построение графика результатов соревнований оценено в 32 пункта или идеальных дня. Сумма трех оценок составляет 61 пункт или идеальный день. Поэтому возможность построения графика результатов соревнований представляет 53 % затрат на все три истории (32 / 61 = 0,53).

Значения в последней колонке, «Приоритет», определяются путем деления стоимости в процентах на затраты в процентах. Более высокие значения представляют более высокие приоритеты, поскольку соответствующие функции создают более значительную стоимость на затраченные на них силы и время. Это ясно видно в табл. 11.2 на примере функции размещения информации о специализации. Данная функция приносит немногим более половины стоимости функции построения графика результатов соревнований (общая стоимость 8 по сравнению с 14), однако на ее реализацию требуется всего одна четверть соответствующих затрат (оценка 8 по сравнению с 32). Из-за высокого отношения стоимости к затратам возможность размещения информации о специализации имеет наивысший приоритет в настоящем анализе.

Важность включения относительных потерь

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

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

Это наглядный пример функции с относительными выгодами, равными 1, и относительными потерями, равными 9.

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

1. Объем и значимость обучения и нового знания, созданного в результате разработки функций.

2. Величину риска, ликвидированного в результате разработки функций.

3. Финансовую стоимость использования функций.

4. Затраты на разработку (и, возможно, поддержку) новых функций.

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

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

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

1. Назовите сравнительные достоинства анализа Кано и относительного взвешивания в вашей организации.

2. Какие привлекательные функции предполагается включить в ваш текущий проект?

3. Можно ли сказать, что ваш текущий проект имеет оптимальное соотношение привлекательных, линейных и обязательных функций?

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

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

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

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

Лучше всего разбивать большие пользовательские истории по данным, которые будут поддерживаться. Например, в одном из проектов команда разрабатывала продукт, предназначенный для сбора финансовой информации. Она начала с одной крупной пользовательской истории: «Как пользователь я могу вводить информацию из моего баланса». Баланс в данном случае мог иметь очень много полей. На самом высоком уровне в нем находятся активы и пассивы. Активы содержат такие статьи, как денежные средства, ценные бумаги, объекты недвижимости, автомобили, кредиты. Система позволяла пользователю работать с этим балансом на различных уровнях детализации. Пользователь мог ввести одну сумму, представляющую все его активы. Или он мог ввести более детальную информацию (подробное перечисление всех кредитов). Вывод множества полей на экран и взаимодействие между этими полями представляли задачу значительно более крупную, чем команда, по ее оценкам, могла реализовать за одну двухнедельную итерацию.

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

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

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

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

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

• Как заемщик я хочу иметь возможность погасить мой кредит. Примечание: допускаются переплаты.

• Как заемщик я в случае ненамеренной переплаты получаю возврат излишка, если он превышает $2.

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

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

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

Общий подход к этому заключается в разбивке истории по границам обычных CRUD-операций — создание, чтение, редактирование и удаление. Чтобы понять, как это работает, предположим, что вы создаете систему SwimStats, а команда готова к реализации такой истории: «Как тренер я могу управлять пловцами в моей команде». Команда разработчиков обсуждает историю с тренерами/пользователями и выясняет, что тренер под этим понимает возможность добавлять новых пловцов, редактировать существующие данные по пловцам и удалять записи о пловцах, которые ушли из команды. Подобная первоначальная история легко разбивается на три более мелкие истории:

• Как тренер я могу добавлять новых пловцов в мою команду.

• Как тренер я могу редактировать информацию о пловцах, входящих в мою команду.

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

Эти истории практически совпадают с операциями создания, редактирования и удаления. Разбивка большой истории на эти три более мелкие истории представляет очень распространенную модель и дает нам следующее правило:

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

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

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

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

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

Это подводит нас к следующему правилу:

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

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

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

• Если пользователь вводит корректные имя и пароль, он получает доступ.

• Если пользователь вводит некорректный пароль три раза подряд, он лишается доступа до тех пор, пока не свяжется со службой поддержки клиентов.

• Если пользователю отказали в доступе, на его адрес направляется электронное письмо о том, что была совершена попытка использовать его учетные данные для получения доступа.

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

• Программирование пользовательского интерфейса.

• Написание среднего яруса.

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

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

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

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

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

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

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

1. Есть ли в вашем текущем или другом проекте пользовательские истории, которые трудно поддаются разбивке? Как бы вы подошли к их разбивке теперь?

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

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

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

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

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

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

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

План релиза не должен в точности описывать, чтó будет разрабатываться в течение каждой итерации. В реальности такой уровень детализации требуется редко. Для большинства проектов вполне достаточно идентифицировать истории, которые пойдут в работу в первой паре итераций, а остальные истории должны распределяться по конкретным итерациям позднее.

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

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

1. Каким является ваш текущий проект, ориентированным на сроки или на функции? Почему он именно такой?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эти основные различия между планом релиза и планом итерации представлены в обобщенном виде в табл. 14.2.

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

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

Эффективны оба подхода — и планирование итерации на основе скорости, и планирование итерации на основе обязательств. Я, однако, предпочитаю подход на основе обязательств. Хотя скорость играет критическую роль в планировании релиза, я не считаю, что она должна играть такую же роль при планировании итерации. Для такого заявления есть две причины.

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

Во-вторых, команде необходимо реализовывать 20–30 пользовательских историй за итерацию, чтобы ошибки в пунктах или идеальных днях взаимно уравновешивались. Мало какие команды реализуют столько историй за итерацию.

Чтобы показать, к чему приводят эти проблемы, предположим, что команда имела скорость 30 в каждой из последних пяти итераций. Скорость команды практически стабильна, и, скорее всего, в очередной итерации она вновь выполнит 30 пунктов. Вместе с тем мы знаем, что не все пятипунктовые истории одинаковы. Если взять большой набор пятипунктовых историй, мы наверняка сможем найти, скажем, шесть пятипунктовых историй, которые немного легче, чем пять пунктов. Мы можем промахнуться с некоторыми из них, но, если впервые попробуем это, возможно, все получится — скорость может возрасти с 30 до 40. В то же время можно отобрать только те истории, которые немного сложнее, чем пять пунктов. Мы по-прежнему считаем, что их надо оценивать в пять пунктов, однако они немного сложнее, чем остальные пятипунктовые истории.

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

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

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

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

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

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

Дни недели

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

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

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

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

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

1. Какой подход к планированию итерации вы предпочитаете: на основе скорости или на основе обязательств? Почему?

2. Как вы относитесь к идее отказа от распределения конкретных задач между членами команды во время планирования итерации?

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

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

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

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

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

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

• длина релиза, над которым ведется работа;

• уровень неопределенности;

• простота получения обратной связи;

• продолжительность сохранения неизменности приоритетов;

• готовность продолжать работу без получения внешней обратной связи;

• издержки итерационного подхода;

• быстрота появления ощущения цейтнота.

1. Какая длина итерации больше всего подходит для вашего текущего проекта?

2. Что изменится в вашем проекте при использовании однонедельных итераций? Что изменится в случае использования двухмесячных итераций?

Одной из проблем при планировании релиза является оценка скорости команды. Существует три подхода к ее решению:

• использовать исторические значения;

• выполнить одну итерацию;

• воспользоваться прогнозом.

Бывает, что применимы все три подхода. Так или иначе, несмотря на выбранный подход, при оценке скорости результат следует представлять в виде диапазона. Допустим, вы оценили скорость команды в определенном проекте как 20 идеальных дней на итерацию. Шансы на то, что вы дали правильную оценку, очень ограничены. Скорость может составлять 21, 19 и даже 20,0001. Поэтому не говорите, что скорость равна 20, а давайте диапазон, например скажите, что ваша скорость находится в интервале между 15 и 24.

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

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

• Осталась ли прежней технология?

• Осталась ли прежней область деятельности?

• Осталась ли прежней команда?

• Остался ли прежним владелец продукта?

• Остались ли прежними инструменты?

• Осталась ли прежней рабочая среда?

• Были ли эти оценки сделаны теми же людьми?

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

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

Прежде чем читать о том, как преобразовать этот показатель в диапазон, посмотрите на рис. 16.1. На нем показан конус неопределенности, о котором мы говорили в главе 1 «Цель планирования». Из конуса неопределенности следует, что фактический срок проекта лежит в диапазоне между 60 % и 160 % от того, чему он равен в соответствии с нашими представлениями. Поэтому, чтобы преобразовать нашу среднюю скорость в диапазон, я умножаю ее на 60 % и на 160 %[6]. Таким образом, если наша историческая скорость равна 15, то я говорю, что скорость лежит в диапазоне от 9 до 24.

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

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

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

По тем же причинам, как и в случае директора по разработке, большинству руководителей проектов полезно воздерживаться от оценок на протяжении как минимум одной итерации. Если вы оказались в такой ситуации, воспользуйтесь возможностью выполнить итерацию и измерить скорость. Затем определите диапазон относительно ее значения с помощью конуса неопределенности. Так, если вы выполните итерацию и получите скорость 15, преобразуйте ее путем умножения на 0,6 и 1,6 в диапазон 9–24.

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

Во-вторых, она может применить конус неопределенности. Хотя у подхода, который я собираюсь описать, нет солидной эмпирической основы, он работает и дает результаты. Вот этот подход: рассчитайте среднюю скорость для выполненных итераций. Затем для каждой итерации сместитесь на один этап вправо на конусе неопределенности. Если команда выполнила одну итерацию, используйте диапазон для этапа «начальная концепция продукта». Если команда выполнила две итерации, используйте диапазон для этапа «утвержденная концепция продукта» (от 80 % до 120 %) и т. д. Для удобства значения нужных множителей приведены в табл. 16.1.

Предположим, что команда выполнила три итерации при средней скорости 20 за период. Для трех итераций диапазон составляет 85–115 %. Это означает, что фактическая скорость к концу проекта будет, скорее всего, лежать в диапазоне от 17 до 23.

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

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

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

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

• Используйте фактическую скорость команды в сходном проекте.

• Оценивайте скорость по тому объему работы, с которым вы можете справиться.

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

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

1. В табл. 16.2 истории, оцениваемые одинаковым числом пунктов, имеют разную оценку задач в часах. Почему? (Если вам нужна подсказка, обратитесь к разделу «Соотнесение оценок задач с пунктами» в главе 14 «Планирование итерации».)

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

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

• Планирование проекта осуществляется задолго до его начала.

• Проект необходимо выполнить до жестко установленного срока и реализовать жестко заданный набор функций.

• Проект передается на договорной основе из одной организации в другую.

• Требования понятны только на очень поверхностном уровне.

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

Умение составлять надежные планы в таких условиях чрезвычайно важно. Зачастую использования простого подхода, рассмотренного в предыдущих главах, недостаточно. В подобных условиях общим у всех проектов является то, что каждый из них характеризуется либо дополнительной неопределенностью, либо более серьезными последствиями в случае ошибки. Я, например, был когда-то вице-президентом по разработке программного обеспечения в компании, входящей в список Fortune 40, и календарный график для наших проектов обычно составлялся за 12–18 месяцев до их начала, когда мы верстали бюджет на следующий год. Мы, конечно, не фиксировали требования, однако должны были определять характер продукта, который будет создаваться. Несмотря на то, что представление о требованиях было расплывчатым, нам приходилось принимать обязательства первого уровня, которые позволяли составлять адекватное штатное расписание для организации. Существовала и другая неопределенность: я редко знал задолго до начала проектов, кто именно из моей команды будет над ними работать. Чаще всего исполнителей просто не было в штате.

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

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

Прошлым вечером я отправился в продовольственный магазин со списком продуктов из 37 пунктов. В моем распоряжении было лишь полчаса, чтобы купить нужные продукты и вернуться домой, поскольку я хотел посмотреть баскетбольный матч, который начался в это время. Как обычно, я начал с одного конца магазина и стал продвигаться к другому. Я шел вдоль полок, а мое внимание было сконцентрировано примерно на 20 товарах, которые нам требовались больше всего. Я знал: если приду домой без молока, хлеба или нарезки из индейки, то в перерыве мне придется снова идти в магазин. Если же я забуду что-то менее важное, то моя жена смирится с этим, у моих дочек будет что поесть, а у меня — возможность спокойно посмотреть баскетбол.

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

Для лучшего понимания того, как это работает, предположим, что владелец продукта идентифицировал работу объемом 100 пунктов как обязательную. Каждая из отобранных историй предполагает выпуск продукта, который будет хорошо принят рынком. Владелец продукта затем выбирает дополнительные 30 % работы, идентифицируя пользовательские истории, оцениваемые еще в 30 пунктов. Эти истории добавляются в проект как опциональная работа. Ожидаемый суммарный размер проекта теперь составляет 130 пунктов. Используя методы, описанные в главе 16 «Оценка скорости», команда определяет, что ее скорость составит 10 пунктов на однонедельную итерацию. В план проекта закладывают 13 итераций (130 / 10). Если все идет хорошо, то обязательная работа выполняется за первые 10 итераций, а оставшиеся три итерации посвящают опциональным функциям.

Процесс функциональной буферизации согласуется с agile-процессом, называемым «метод разработки динамических систем (dynamic systems development method — DSDM)». В DSDM-проектах требования разделяют на четыре категории: обязательные, желательные, опциональные, ненужные. К обязательным может быть отнесено не более 70 % запланированных функций в проекте. Таким образом, в DSDM-проектах создается функциональный буфер, эквивалентный 30 % срока проекта.

Допустим, мне нужно отправиться в аэропорт и успеть на рейс в Италию. (Ну вот, сплоховал! Можно было придумать место и получше.) Для авиаперелетов характерно очень жесткое расписание. Самолет улетит в любом случае, со мной или без меня. В план перемещения от дома до соответствующей посадочной зоны в аэропорту мне необходимо заложить достаточно времени, чтобы точно успеть на самолет, но не столько, чтобы оказаться в аэропорту за три дня до вылета.

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

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

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

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

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

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

Не забывайте также, что в проекте могут использоваться и другие буферы, помимо функционального и временнóго. В проект можно включить бюджетный буфер, где, например, на проект выделяются 30 разработчиков, а средства позволяют увеличить их число до 33. Это обычная практика для средних и крупных проектов, однако в небольших проектах к ней прибегают не так часто по двум причинам.

1. Один-два дополнительных человека для создания буфера по персоналу в небольшом проекте почти всегда вносят прямой вклад в срок проекта. Увеличение штата с 30 до 33 разработчиков вряд ли заметно повысит производительность, если вообще повысит. Если же штат увеличивается с четырех разработчиков до пяти, то производительность практически наверняка вырастет.

2. Очень трудно создавать буферы для чего-то небольшого. Когда в проекте, где занято 30 человек, создается резерв из трех работников и полный штат увеличивается до 33, мы получаем 10 %-ный буфер по персоналу. Аналогичный буфер для проекта, в котором заняты три человека, составит всего 0,3 разработчика. Понятно, что часть человека не добавишь в проект.

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

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

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

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

• При добавлении временнóго буфера используйте подход с двумя оценками, описанный в этой главе, а при использовании одной оценки следите за тем, чтобы она была 50 %-ной. Добавление временнóго буфера к и без того пессимистичным 90 %-ным оценкам приведет к чрезмерному удлинению сроков.

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

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

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

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

Временной буфер, в свою очередь, создается путем включения в календарный график дополнительного времени с учетом неопределенности, присущей размеру команды. Функциональный буфер можно сконструировать на основе присвоения каждой пользовательской истории двух оценок — с 50 %-ной и 90 %-ной вероятностью. Формула «извлечение квадратного корня из суммы квадратов» позволяет найти подходящий размер временнóго буфера.

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

1. Дает ли затрата дополнительных усилий на расчет временнóго буфера какие-либо выгоды в условиях вашей организации?

2. Предусмотрены ли в вашем текущем проекте буферы для компенсации какого-либо типа неопределенности? Если да, то какие? Если нет, то какие типы буферов были бы наиболее полезными?

3. Есть ли признаки проявления закона Паркинсона или синдрома студента в вашей организации? Что еще, помимо предложений, представленных в этой главе, вы можете предпринять для снижения влияния этого закона и синдрома?

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

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

1. Принять общую базу для оценок.

2. Быстрее добавлять детали в пользовательские истории.

3. Выполнять опережающую разработку планов.

4. Включать в план поддерживающие буферы.

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

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

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

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

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

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

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

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

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

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

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

Скорость оценивается как 20 пунктов на итерацию для одной и другой команды. Поскольку объем работ составляет 110 пунктов, команды должны поставить полную функциональность за три итерации. Вместе с тем 30 пунктов приходятся на разработку API, а еще 40 пунктов (три последние истории в табл. 18.1) можно реализовать только после разработки API. Это приводит к такому распределению работ, которое представлено на рис. 18.1, где взаимозависимость команд обозначена стрелкой между реализацией API первой командой и работой над индивидуальными результатами, выполняемой второй командой.

Возможно, вы помните, что в главе 13 «Основные аспекты планирования релиза» я рекомендовал показывать в плане релиза детали только следующих двух итераций. Объясняется это тем, что такой подход нередко достаточен для поддержки взаимозависимостей, с которыми имеют дело многие команды. Когда нескольким командам приходится работать вместе, план релиза следует обновлять с тем, чтобы показывать и координировать работу в следующих двух или трех итерациях. Точное число итераций, конечно, зависит от частоты и серьезности взаимодействий команд. После завершения итераций связанные с ними детали удаляют из плана. Таким образом, план релиза становится скользящим опережающим планом, который всегда отражает ожидания относительно нескольких новых итераций. Лауфер (Laufer, 1996) называет это «заглядывание вперед».

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

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

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

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

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

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

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

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

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

1. Как вы устанавливаете общую базу для оценок в проектах с участием нескольких команд?

2. Насколько значительна взаимозависимость команд в вашем текущем проекте? Какие приемы из описанных в этой главе являются самыми действенными?

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

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

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

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

В прямоугольнике «Гендерно-возрастная информация пловцов» на рис. 19.6 видно, что эта тема включает в себя восемь историй, которые оцениваются в сумме в 36 пунктов. Из этого числа уже выполнено 18 пунктов, поскольку, как мы знаем, реализовано 50 % функции. Мы не можем сказать, какие именно пользовательские истории реализованы. Отдельные прямоугольники на диаграмме можно даже выделить цветами, чтобы показать, реализована ли тема, идет ли ее реализация в соответствии с календарным графиком, требует ли эта тема повышенного внимания или значительно отстает от календарного графика.

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

Скорость — это показатель объема работы, выполняемой командой за каждую итерацию. Скорость должна определяться на основе правила «все или ничего». Если история реализована, то команда может включить ее полную оценку в расчет скорости. Если история частично реализована в течение итерации, то она не учитывается при определении скорости.

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

Гистограмма выгорания релиза представляет собой полезный в некоторых случаях вариант стандартной диаграммы выгорания. Гистограмма позволяет разделить прогресс команды относительно запланированной работы и изменения объема релиза. Изменения объема релиза отображаются как смещение столбика ниже горизонтальной оси. Этот тип диаграммы более нагляден, чем стандартная диаграмма выгорания, однако его следует использовать осмотрительно, поскольку он может вызвать в организации споры относительно того, на какую часть столбика повлияли изменения — на верхнюю или на нижнюю.

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

1. Если вы не используете диаграмму выгорания релиза в своем текущем проекте, какой результат дало бы построение такой диаграммы в конце каждой итерации?

2. Какой из методов мониторинга и представления прогресса, описанных в настоящей главе, был бы наиболее результативным для вашего текущего проекта?

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

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

Доска задач выполняет двойную роль — дает команде удобный механизм организации работ и обеспечивает возможность увидеть, как много работы осталось. Очень важно, чтобы доска задач (или в некоторых случаях ее аналог) допускала значительную гибкость в организации работы команды. Члены agile-команды не берут на себя новую работу (или не получают новое задание) до тех пор, пока они не будут готовы взяться за нее. Это означает, что вплоть до последних одного-двух дней итерации обычно имеется множество нераспределенных задач. Доска делает эти задачи хорошо видимыми, так что у каждого есть возможность узнать, над чем предстоит работа и какую работу можно взять на себя. Пример доски задач приведен на рис. 20.1.

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

Во второй колонке находятся карточки всех задач, которые команда идентифицировала как необходимые для реализации истории или функции. На каждой из этих карточек обозначена оценка работы, оставшейся до завершения задачи.

Третья колонка показывает, готовы ли приемочные тесты для истории. Я активный сторонник разработки через тестирование (Beck, 2002) как на уровне кода, где рекомендую разработчикам писать модульные тесты до написания кода, так и на уровне функции, где рекомендую командам создавать общие приемочные тесты до начала кодирования. Если условия удовлетворенности для каждой истории идентифицируются в процессе планирования итерации (как рекомендуется в главе 14 «Планирование итерации»), это не представляет трудности, поскольку условия удовлетворенности по своей сути — это общие приемочные тесты для пользовательской истории. Такой вид специфицирования на примерах очень удобен для программистов, которые могут ссылаться на конкретные примеры ожидаемой работы каждой функции и бизнес-правила.

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

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

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

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

Ошибки отслеживания на доске задач

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

В качестве примера того, как доска задач может помочь, рассмотрим случай, когда владелец продукта включает задачу «Устранить 10 старых ошибок» в новую итерацию. Владелец продукта выбирает 10 ошибок, а разработчики составляют карточку задачи (с оценкой) для каждой из них. Эти карточки размещают в один ряд в колонке «Для разработки» доски задач. В процессе осуществления итерации разработчики занимаются этим десятком ошибок точно так же, как другими задачами. Теперь предположим, что пользователь находит новую ошибку в середине итерации. Если новой ошибке присваивается более высокий приоритет, чем у оставшихся в колонке «Для разработки», то владелец продукта может перенаправить эквивалентный объем работы на устранение новой ошибки.

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

Построение диаграммы выгорания релиза — отличный способ понять, оторвался проект от плана или нет. В зависимости от длины итераций создание диаграммы выгорания может быть полезным и применительно к итерациям. Если вы работаете с однонедельными итерациями, то диаграмма не нужна. К тому моменту, когда тренд на диаграмме выгорания станет видимым, однонедельная итерация уже закончится. Однако мой опыт показывает, что диаграммы выгорания очень полезны, когда длина итерации составляет две недели и более. Диаграмма выгорания итерации показывает оставшиеся часы по дням, как видно на рис. 20.2.

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

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

При осуществлении проекта намного полезнее знать, сколько осталось сделать, а не сколько сделано. Более того, отслеживание затраченных сил и времени и сравнение их с оценочными затратами может привести к «опасениям в отношении оценки» (Sanders, 1984). Когда оценщики боятся давать оценку, срабатывает знакомый инстинкт «бей или беги», и оценщики полагаются больше на него, а не на аналитическое мышление (Jørgensen, 2004).

Отслеживание затраченных сил и времени в целях повышения точности оценки — другое дело. В этой ситуации оно может быть полезным (Lederer and Prasad, 1998; Weinberg and Schulman, 1974). Вместе с тем руководитель проекта или тот, кто занимается таким отслеживанием, должен быть предельно осторожным и не допускать чрезмерного давления на оценщиков, поскольку оно ведет не к улучшению, а к ухудшению оценок.

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

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

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

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

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

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

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

Командам не следует подсчитывать или отслеживать индивидуальную скорость.

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

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

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

Частое предоставление информации о планах важно из-за частоты обновления agile-плана. Например, даже если команда осуществляет скользящее опережающее планирование (как описано в главе 18 «Планирование проекта с участием нескольких команд»), ее план релиза может показывать только то, что будет разрабатываться в следующих нескольких итерациях. Пользовательские истории, которые будут разрабатываться в оставшейся части релиза, могут отражаться в его плане, но без определения очередности их выполнения за горизонтом опережающего плана и как широкие темы.

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

Честное информирование важно, если команда-разработчик и команда-клиент хотят доверять друг другу. Если разработчики узнаю́т, например, что владелец продукта устанавливает для них необоснованные сроки, то они перестают доверять ему. Аналогичным образом доверие исчезает, когда разработчики дают оценки, которые, насколько известно владельцу продукта, нереалистичны. Как-то я имел дело с командой, члены которой говорили, что руководство завышает для них объем работы, действуя по принципу «если сделают 80 %, то уже хорошо». Руководство опиралось на теорию о том, что оно в любом случае получит не более 80 % от запрашиваемого, а потому нужно запрашивать больше.

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

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

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

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

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

• «Я на 90 % уверен в том, что мы завершим реализацию запланированной функциональности к 31 июля».

• «Исходя из наших предположений относительно размера проекта и производительности команды, на проект потребуется от трех до четырех месяцев».

В качестве примера информирования Рон Джеффриз (Jeffries, 2004) из www.XProgramming.com предлагает такой вариант:

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

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

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

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

В-третьих, на рис. 21.1 не показано распределение ресурсов. Поскольку за поставку всех функций отвечает команда в целом, нет смысла ставить имя Мэри напротив одной функции, а имя Вадим — напротив другой. Конечно, если диаграмма Гантта строится для отображения работы нескольких команд, то можно указать, что за такие-то функции (или чаще целые итерации) отвечает команда 1, команда 2 и т. д.

Естественно, основным способом информирования о прогрессе являются диаграммы выгорания релиза, рассмотренные в главе 19 «Мониторинг плана релиза». Прогресс на такой диаграмме — это функция количества оставшейся работы и скорости команды. Чтобы предсказать число оставшихся итераций, нужно взять количество оставшихся пунктов, разделить его на скорость команды и округлить результат до следующего большего целого числа. Иначе говоря, если остается 100 пунктов, а скорость команды равна 10, то остается 10 итераций.

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

Чтобы понять, как выбирается диапазон скоростей, рассмотрим рис. 21.2, где показана скорость команды в восьми прошлых итерациях. Скорость в последней итерации равна 19. Вместе с тем средняя скорость за восемь итераций составляет 17, а средняя скорость за три самые плохие итерации равна 14. Эти значения приводят к разным ожиданиям относительно срока завершения всех запланированных в текущий момент работ. Именно поэтому зачастую лучше использовать более одного значения скорости и представлять выводы в виде диапазона вероятных результатов.

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

1. Скорость в последней итерации.

2. Среднюю скорость.

3. Среднюю скорость в трех итерациях с самой низкой скоростью.

Эти три значения представляют хорошую картину только что произошедшего — «долгосрочное» среднее и наихудший вариант того, что может произойти. На основе этих трех значений скорости я примерно прогнозирую, какой объем работы может быть выполнен к определенной дате. Например, если мы хотим выпустить продукт после пяти дополнительных итераций, а в последней итерации скорость команды составила 19, то можно рассчитывать на то, что команда выполнит еще 95 пунктов. Аналогичные вычисления можно проделать и с другими значениями скорости. В результате мы получим диапазон вероятных объемов работы, которую команда может выполнить. Итог я обычно представляю в табличной форме (табл. 21.1).

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

Расчет трех ожидаемых значений скорости (как показано в табл. 21.1) позволяет владельцу продукта и команде предсказывать объем работы, который может быть выполнен до плановой даты выпуска релиза. На основании табл. 21.1, например, владелец продукта может быть уверен, что в последующих пяти итерациях будут добавлены как минимум 70 пунктов. Вместе с тем владелец продукта не должен рассчитывать на что-то большее, чем 85 пунктов.

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

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

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

1. Предположим, что в проекте оставшийся объем работы оценивается в 150 пунктов. В последних 10 итерациях команда имела скорость 10, 12, 13, 5, 14, 7, 6, 12, 16 и 14. Вас спрашивают, когда будет завершен проект. Как вы ответите на этот вопрос?

2. Как установлен срок в вашем текущем проекте — как конкретная дата (скажем, 18 сентября) или как диапазон? Почему?

3. В каком диапазоне итераций или дат будет завершен ваш текущий проект?

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

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

Чтобы план оказался полезным, он должен быть точным, однако мы допускаем, что первоначальные планы неточны. Одна из причин изменения плана — постепенное уменьшение неточности. Иными словами, первоначальный план может говорить, что в третьем квартале в проекте будет выполнена работа объемом 300–400 пунктов. Этот план впоследствии может оказаться более-менее точным (в августе выполняется работа объемом 305 пунктов), но он все равно неточен. В начале проекта такой план, скорее всего, служит основой для принятия решений. Позднее, однако, чтобы оставаться полезным, план уточняется, и мы можем сказать, что в сентябре в проекте будет реализовано 380–400 пунктов.

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

Обычная ошибка планирования (как у традиционных, так и у многих agile-команд) — смешивание оценок размера и срока. Понятно, что размер работы и время, необходимое для ее выполнения, взаимосвязаны, однако сроки зависят от множества дополнительных факторов. На проект одного размера программистам с разной квалификацией и опытом потребуется разное время. Аналогичным образом на сроки влияет размер команды, занимающейся проектом. У команды из четырех человек на работу может уйти шесть месяцев (24 человеко-месяца). Команда из восьми человек может сократить срок до четырех календарных месяцев, но затратить на работу 32 человеко-месяца, несмотря на то что размер проекта один и тот же.

Чтобы понять разницу между оценками размера и срока, представьте, что я показываю вам книгу и спрашиваю, за какое время вы сможете прочесть ее. Из названия вы можете понять, что это роман, но я не даю вам раскрыть книгу и посмотреть, сколько в ней страниц, какие в ней поля и насколько мелкий шрифт. Чтобы ответить на мой вопрос, вы сначала оцениваете объем — количество страниц. Допустим, их 600. Затем вы прикидываете свою скорость чтения и решаете, что она составляет одну страницу в минуту. В результате вы говорите мне, что прочтете книгу за 600 минут, или за 10 часов. Чтобы назвать срок (10 часов), вы сначала оцениваете объем работы (600 страниц).

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

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

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

Традиционный план в форме диаграммы Гантта, диаграммы PERT или разбивки работ сфокусирован на задачах, выполнение которых необходимо для создания продукта. Agile-план концентрируется на функциях, которые должны присутствовать в продукте. Это принципиальное отличие, которое заставляет команду думать о продукте на правильном уровне — на уровне функций. Когда функции разрабатываются итеративно, уменьшается потребность в предварительном обдумывании необходимых конкретных задач. В процессе осмысления работы для очередной итерации команда обдумывает или открывает все задачи по мере их необходимости. Еще важнее то, что команда думает о функциях, которые подлежат разработке. Мой коллега Джим Хайсмит (Highsmith, 2004b) утверждает, что «agile-планирование „лучше“ других потому, что оно ориентируется на функции (истории и т. п.), а не на задачи. Довольно легко спланировать целый проект, используя стандартные задачи, без реального понимания сущности создаваемого продукта. Когда планирование осуществляется на основе функций, команда намного лучше понимает продукт». На уровне задач планы многих проектов выглядят одинаково. Каждый agile-план конкретен по отношению к создаваемому продукту.

Из теории массового обслуживания (Poppendieck and Poppendieck, 2003; Reinertsen, 1997) мы знаем о важности фокусирования на времени цикла — количестве времени, необходимого для чего-то от начала процесса до его завершения. В софтверном проекте время цикла — это время от начала работы команды над функцией до поставки этой функции пользователям. Чем короче время цикла, тем лучше.

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

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

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

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

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

Agile-подход к оценке и планированию успешно устраняет эту проблему через отслеживание прогресса только на уровне команды. Это одна из причин, по которым в главу 14 «Планирование итерации» включена рекомендация для членов команды воздерживаться от принятия обязательств по выполнению конкретных задач во время планирования итерации. Аналогичным образом не должны составляться индивидуальные диаграммы выгорания — составляется только общекомандная диаграмма выгорания.

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

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

С учетом сказанного выше я составил список из 12 правил успешного применения agile-подхода к оценке и планированию.

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

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

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

4. Выражайте неопределенность при представлении либо функциональности, либо даты. Ни один план не является полностью определенным. Обязательно включайте выражение неопределенности в составляемые планы релизов. Если объем новой функциональности зафиксирован, представляйте неопределенность в виде диапазона дат («Мы завершим работу в третьем квартале» или «Мы завершим работу через 7–10 итераций»). Если зафиксирована дата, представляйте неопределенность через набор поставляемых функций («Мы завершим работу 31 декабря, и продукт будет содержать по меньшей мере вот эти функции, но, возможно, не более, чем те новые функции»). Используйте более крупные единицы (итерации, месяцы, кварталы, например) по мере роста неопределенности.

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

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

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

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

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

10. Стройте оценки и планы на фактах. Когда возможно, стройте оценки и планы на реальной основе. Конечно, бывает, что в некоторых организациях приходится оценивать показатели вроде скорости, опираясь на очень узкую базу. В главе 16 «Оценка скорости» на этот случай представлены подходящие методики. Вместе с тем, когда возможно, оценки и планы должны строиться на реальных, наблюдаемых величинах. Это относится также и к оценке того, сколько функций реализовано. Несложно увидеть, что функция выполнена на 0 % (в момент, когда с нею только начинают работать), и довольно легко определить, когда она выполнена на 100 % (пройдены все тесты для всех условий удовлетворенности владельца продукта). Однако в промежутке между этими состояниями очень трудно сказать, на сколько реализована функция — на 50 % или на 60 %. Как результат, придерживайтесь того, что вам известно: 0 % и 100 %.

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

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

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

1. Есть ли другие причины, которыми, на ваш взгляд, объясняется успех agile-подхода к оценке и планированию?

2. Какие из 12 правил применимы к вашему текущему процессу оценки и планирования? Будет ли полезно следовать другим правилам?

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

Как менеджер по продукту в Bomb Shelter Studios, он знал, что их последняя игровая программа Deep Black & White демонстрировала хорошие результаты. Она позволяла играть в игру под названием го, которая была чрезвычайно популярна в Японии, Китае и Корее, но вызывала лишь умеренный интерес в Европе, Северной Америке и остальном мире. Программисты из его команды использовали решения на основе искусственного интеллекта, которые позволили Deep Black & White дойти в игре до уровня сложности, известного как пятый дан. Это, конечно, далеко от девятого дана — уровня лучших профессиональных игроков, однако значительно лучше, чем у конкурентов компании Bomb Shelter.

Фрэнк был полон энтузиазма в отношении выпуска и продажи Deep Black & White в Азии через одного издателя, с которым удалось договориться о дистрибуции во время конференции. Доход от продаж на этих рынках был бы очень кстати для Bomb Shelter. Фрэнк знал: дополнительные шесть месяцев, которые потребовались для завершения Deep Black & White, чуть было не привели к разорению небольшую частную компанию по разработке игр, соучредителем которой он являлся.

Из малоперспективной начинающей компании за три года Bomb Shelter Studios превратилась в признанного разработчика интеллектуальных и стратегических игр. В дополнение к только что законченной Deep Black & White у Bomb Shelter были программы для игры в шахматы, триктрак, реверси, бридж, шашки, манкалу и др. После создания игры права на ее дистрибуцию продавались тому или иному издателю, который занимался производством и распространением, позволяя Bomb Shelter полностью сконцентрироваться на разработке новых игр.

Пока Фрэнк был на конференции, его аналитик и небольшая команда в Санта-Барбаре обдумывали новую игру Havannah, разработку которой они были практически готовы начать. Из-за проблем с Deep Black & White — не только из-за шестимесячной задержки, но и из-за слишком большого количества ошибок и обнаруженного в последний момент неудобства использования — им нужно было срочно найти другой подход к планированию и реализации проектов. Саша, ведущий разработчик архитектуры в компании, проработала ряд выдвинутых командой идей. Она предложила в следующем проекте использовать то, что называют «agile-процесс». Фрэнк не совсем понимал, что это означает, однако у него не было сомнений в том, что им нужно подходить к делу по-другому. Шестимесячное опоздание с выпуском следующей игры было бы концом. Все члены команды горели идеей попробовать agile-процесс и знали, чтó поставлено на кон.

— Всем привет, — сказал Фрэнк, входя в конференц-зал. До девяти оставалась еще целая минута, однако почти вся команда была в сборе и ожидала его появления. Это был хороший знак. Несмотря на то, что команда измоталась в процессе последнего рывка с Deep Black & White, она выглядела так, словно была готова взяться за разработку Havannah.

— Привет, Фрэнк. Я видел твое электронное письмо о Deep Black & White. Сделка по дистрибуции — отличная новость, — сказал Аллан, программист C++, который разрабатывал игровой движок на искусственном интеллекте, сделавший Deep Black & White таким сильным игроком.

— Возьми пончик, Фрэнк, — предложила Саша и подвинула к нему почти пустую коробку.

— Спасибо, — ответил Фрэнк и запустил руку в коробку.

— Фрэнк, это Карлос, — сказала Саша. — Он опытный agile-тренер. Мы пригласили его, чтобы он помог нам освоить этот новый agile-подход к работе.

Фрэнк и Карлос обменялись рукопожатиями и приветствиями.

— Похоже, все в сборе, за исключением Роуз, — сказал Фрэнк. — Давайте начнем. Мы введем ее в курс дела позже. Вряд ли на этом совещании разговор пойдет о художественном оформлении.

— Мы не можем начать, Фрэнк, — сказал Карлос. — Это важный момент. Нужно, чтобы присутствовала вся команда. Значительная часть выгоды, которую мы хотим получить в результате применения agile-процесса, зависит от участия всех членов команды. Роуз, возможно, мало что скажет об искусственном интеллекте в игровом движке, но нам все равно нужно знать ее мнение, если мы хотим создать лучшую игру.

— Она всегда появляется по понедельникам в пять минут десятого. Ей приходится отвозить Брук в школу по понедельникам, средам и пятницам. Она вот-вот придет, — заметил Прасад. И точно, стоило ему сказать это, как отворилась дверь и в конференц-зал вошла Роуз.

— Извините, пробки, — сказала Роуз, быстро усаживаясь в кресло.

— Итак, Делани, ты занималась исследованием продукта для проекта Havannah, — обратился Фрэнк к аналитику. — Прошло довольно много времени с того момента, как я задумал эту игру. Прошу прощения, но напомни мне, пожалуйста, как в нее играют.

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

— Правильно, но, в отличие от го, фишки не захватывают. Цель игры Havannah — построить кольцо, мост или вилку. Кто первым это сделает, тот и выигрывает.

— А что такое кольца, мосты и вилки? — спросил Фрэнк, когда Делани взяла пригоршню фишек и начала ставить их на доску.

— Кольцо — самая простая фигура. Оно выглядит так, — ответила Делани, расставляя фишки, как показано на рис. 23.2. — Кольцо — это ряд стоящих на соседних клетках фишек, которые окружают одну или несколько клеток.

— Ну, это выглядит довольно просто. Что усложняет игру? — спросил Аллан. Он уже начал думать о том, как создать движок на основе искусственного интеллекта, который будет выбирать ходы.

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

— Должен ли игрок говорить до начала игры, какую фигуру он попытается построить? — поинтересовался Аллан.

— Нет, это часть интриги и часть задачи. Ты можешь начать со строительства моста, понять, что он не получается, и попытаться построить вилку.

— А что такое вилка?

— Вилка выглядит вот так, Фрэнк, — сказала Делани, добавив несколько фишек на доску, как показано на рис. 23.4. — Вилка соединяет три обреза доски, а не углы. Углы — это не обрезы, поэтому их нельзя использовать для создания вилки, они подходят только для моста.

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

— Именно так, Аллан, — сказала Делани. — Многие считают, что эта игра сложнее, чем шахматы, поскольку в ней больше вариантов и невозможно использовать огромную базу эндшпилей. В шахматах, когда остается всего несколько фигур, можно использовать базу лучших завершений партии и не нужно полагаться только на генератор ходов. В игре Havannah слишком много фишек и слишком много позиций.

— Но ведь тебе неинтересно возиться с какой-нибудь простенькой игровой программой, правда же, Аллан? — поддела его Саша.

По виду Аллана было похоже, что в этот раз он не прочь заняться чем-нибудь попроще.

— Не волнуйся. Из-за того, что сейчас в эту игру мало кто играет, нам не понадобится такой же мощный движок, как в Deep Black & White, — поспешила успокоить его Делани. — В конечном итоге мы доберемся и до такого же уровня, но в версии 1.0 этого пока не нужно. Вполне подойдет движок, который берет верх над людьми в большинстве случаев.

— Окей, Делани. Есть ли еще какие-то правила, о которых нам нужно знать? — спросил Фрэнк.

— Нет, это все. Правила простые, но эта игра реально заставляет поломать голову. Именно поэтому мы считаем, что она понравится клиентам, которые уже покупали наши игры.

— Так ты уже оформила документ с требованиями?

— Пока нет, Фрэнк. Из того, что мы узнали от Карлоса об agile-подходе к разработке программного обеспечения, следует, что команда должна формулировать требования коллективно.

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

— Звучит довольно просто. А что мы будем делать с ними, когда сформулируем?

— Мы оценим каждую из них, приоритизируем, а потом найдем наилучший баланс между функциями и сроками, — сказал Карлос.

— Ну и как же составляются эти пользовательские истории? — спросил Фрэнк.

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

— Конечно, — ответила Делани. — Начнем вот с этого: «Как игрок я могу отменить ход с тем, чтобы исправить серьезную ошибку».

— Это наша первая история? — спросил Прасад, тестировщик.

— Да, поэтому я запишу ее на карточке, чтобы не забыть, — сказала Делани и написала карточку истории (23.1.)

— Теперь нам нужно оценить эту историю? — спросил Аллан.

— Пока нет, Аллан. Это будет легче сделать, когда у нас появится группа историй. Мы оценим их одновременно, — ответил Карлос.

— Теперь моя очередь. Если есть история об отмене действия, то нам нужна и история о повторе действия. «Как игрок я хочу иметь возможность повторить ход, который отменил, с тем, чтобы восстановить последовательность ходов», — сказал Фрэнк.

— Хорошая история, Фрэнк. Запиши ее на карточку, — предложил Карлос менеджеру по продукту.

— А не лучше ли ввести это в электронную таблицу? — спросил Фрэнк.

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

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

Фрэнк начал понимать преимущества использования карточек. Он мог написать новые карточки или забрать уже написанные. В электронной таблице проделать такое невозможно. Пока что этот новый «agile-процесс» был ему малопонятен, но уже увиденное внушало оптимизм. С растущим энтузиазмом Фрэнк написал карточку истории (23.2).

— Чтобы записать все истории, нужно… — начал было Карлос.

— Ты и в самом деле имеешь в виду все, Карлос? — перебила agile-тренера команды Саша.

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

— Хорошо, я сделаю это, — сказал Фрэнк и написал карточку истории (23.3). — А как показать, что эта карточка связана с двумя другими? Их нужно как-то пронумеровать?

— Нет, просто разорви первые две карточки, — ответил Карлос. — Они нам больше не нужны.

Фрэнк разорвал первые две карточки.

— Карлос, Фрэнк не включил в карточку причину. Там нет «с тем, чтобы». Это нормально? — спросил Аллан.

— Эй, это всего лишь моя вторая история! — Фрэнк шутливо парировал выпад.

— В действительности, — пояснил Карлос, — «с тем, чтобы» требуется не всегда. Если это помогает сделать историю более ясной, то такое дополнение нужно. Но слишком беспокоиться о нем не стоит, особенно в истории вроде этой, где и так понятно, почему пользователь хочет иметь данную возможность.

— Карлос, ты сказал, что нам нужно написать все истории сегодня, даже если некоторые из них будут сформулированы в самом общем виде. Но разве нельзя добавить истории позже? — спросила Роуз.

— Конечно, можно. Мы обязательно будем добавлять какие-то истории позже. Если это будет не так, значит, мы подходим к игре недостаточно креативно. Я и мысли не допускаю, что позже у нас не появятся новые идеи, более удачные, чем те, с которых мы начинаем сегодня. Цель письменного изложения «всех» историй сегодня — описать наши знания, пусть даже в общем виде, о том, какие функции наиболее желательны. Это здорово поможет Саше и Аллану, которые будут разрабатывать архитектуру игры и продумывать подходы к созданию генератора ходов.

— Это здорово, Карлос. Продолжим. Может быть, мы все просто начнем писать карточки?

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

Со стороны членов команды послышались возгласы согласия, а Карлос продолжил:

— Что может пользователь захотеть сделать сразу после загрузки Havannah?

— Начать игру.

— Восстановить сохраненную партию.

— Выбрать уровень сложности.

— Ну вот, давайте запишем это, — сказал Карлос. Через несколько минут команда выдала кучу историй (табл. 23.1).

— Карлос, — сказал Фрэнк, — если эти истории представляют то, что пользователь может захотеть до начала игры, почему в их число включили «Как игрок я хочу, чтобы в игре был музыкальный фон»? Ведь это нечто нужное игроку во время игры, а не до ее начала.

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

— Понятно. А что делать дальше?

— Теперь давайте подумаем, чего пользователь может захотеть во время игры.

В ответ на предложение Карлоса члены команды написали истории, представленные в табл. 23.2.

— А теперь, я думаю, нам надо перейти к тому, что пользователь может захотеть сделать после завершения игры, — сказал Фрэнк.

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

— Игрок может также захотеть вернуться и просмотреть ходы. Deep Black & White поддерживает такую возможность, — заметила Роуз. — Я могу сделать комментарий к ходу вроде такого: «Я также обдумывала возможность пойти на клетку А3».

— Окей, запишем это в виде историй, — сказал Карлос (результат представлен в табл. 23.3).

— Что дальше, Карлос? — спросил Аллан.

— Пока ты будешь шлифовать Deep Black & White в течение следующих двух недель, Делани проведет более глубокое исследование продукта.

— Да, — добавила Делани. — Я хочу проработать с потенциальными пользователями набор функций, которые они считают наиболее важными.

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

— Конечно, давайте оценим их. Но сначала сделаем 10-минутный перерыв, — предложил Аллан.

— Теперь, — подвел итог совещания Карлос, — займемся оценкой размера историй в пунктах.

— А что такое пункты? — поинтересовался Фрэнк.

— Пункт — это безразмерная величина объема и сложности истории, — ответил Карлос. — Предположим, мы решили, что оценка сохранения партии составляет три пункта. Если, на наш взгляд, реализация восстановления сохраненной партии требует таких же усилий, то мы присвоим ей оценку «три пункта». Если же мы решим, что восстановление партии требует чуть меньше усилий, то дадим ей два пункта.

— Получается, что числа ничего не значат? — спросил Фрэнк.

— Только относительно. Два — вдвое больше одного. Восемь — вчетверо больше двух. Примерно так. Это все, что они значат, — пояснил Карлос. — Мы будем заниматься оценкой, играя в покер планирования. — Карлос раздал присутствующим по набору карт с цифрами 1, 2, 3, 5 и 8. — Теперь Делани прочтет нам одну из пользовательских историй. Мы обсудим ее и сможем задать вопросы. Затем каждый поднимет одну из розданных мною карт. Цифры на ней — это наши оценки. Все сначала выберут карты, а потом одновременно откроют их. Если цифры окажутся одинаковыми, это и будет оценка, а если нет, то мы обсудим их и историю в течение нескольких минут и повторим процесс. Процесс повторяется до тех пор, пока все не придут к одной и той же оценке.

Карлос ответил на несколько вопросов относительно метода и попросил Делани прочитать первую историю: «Как игрок я могу начать новую игру».

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

— Что ты имеешь в виду под «этой историей»? — спросил Аллан. — Пока неясно, что означает «начало новой игры».

— Мы написали эту историю, когда размышляли о том, чего пользователь может захотеть после запуска нашей программы, — сказала Делани. — Мы говорили, что он, скорее всего, захочет начать новую игру или восстановить старую. Вот и все, что имелось в виду.

— А эта история включает в себя построение чистого игрового поля и задание установок, с тем чтобы компьютер был готов играть? — спросил Аллан.

— На мой взгляд, включает. Не думаю, что для этой истории нужно красивое игровое поле. У нас есть другая история о создании эстетически привлекательного экрана. Но эта история, несомненно, требует создания игрового поля Havannah на экране.

Карлос немного подождал, чтобы удостовериться, нет ли других вопросов. «А теперь каждый выбирает карту с оценкой этой истории».

— Один, — сказал Аллан, показывая всем свою карту.

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

Цифры на картах варьировали от единицы у Аллана и Роуз до пяти у Прасада.

— Почему пять, Прасад? — спросил Карлос.

— На мой взгляд, эта история из разряда крупных, — ответил тот.

— И близко не валялась, — возразил Аллан. — Все, что нужно для нее, это пользовательский интерфейс, где игрок может выбрать кнопку «Начать новую игру» и получить чистое игровое поле Havannah. Поле не обязательно должно выглядеть красиво, а размещения фишек здесь не требуется. Для этого есть отдельные истории. Эта история простая.

— Хорошо, я не смотрел на нее под таким углом, — сказал Прасад.

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

— Наша следующая история, — сказала Делани, — звучит так: «Как игрок я могу восстановить сохраненную игру».

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

— Окей, следующая история — «Как игрок я могу выбирать уровень сложности». Давайте оценим ее, — сказала Саша.

— Это уже целый генератор ходов, — заметил Аллан. — Это довольно сложно. Можем ли мы на время оставить эту историю и вернуться к ней после того, как оценим несколько историй покрупнее?

— Я не против, — ответила Саша.

— Погодите, — сказала Роуз. — Я думаю, что это история о выборе пользователем уровня сложности, а не об игре компьютера на этом уровне сложности. Это просто — всего лишь одно или два поля на экране.

— Именно это я и имел в виду, когда записывал эту историю, — вставил слово Фрэнк.

— Отлично, но тогда нам нужна такая история: «Как игрок я могу играть против компьютера на разных уровнях сложности», — сказала Роуз.

— А можно разбить эту историю? — спросил Аллан. — Я думаю, она довольно сложна. Как насчет такой: «Как игрок я могу играть против слабого компьютерного противника»? И таких: «Как игрок я могу играть против сильного компьютерного противника» и «Как игрок я могу играть против среднего компьютерного противника»?

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

Все закивали в знак согласия с тем, что две истории действительно имеют один размер.

— Теперь перейдем к истории «Как игрок я могу играть против слабого компьютерного противника», — предложил Аллан, горевший желанием обсудить истории, связанные с генератором ходов, разрабатывать который, скорее всего, придется ему. — Насколько сильно должен играть наш слабый движок?

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

— Ну так давайте оценим ее, — сказал Аллан.

— Погодите, — вставил слово Прасад, — как мы будем тестировать это? Похоже, тестирование окажется сложным делом.

— Хороший вопрос, — сказал Карлос. — Какие будут соображения? — Он обвел взглядом присутствующих.

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

— Звучит хорошо. А можно ли это автоматизировать? — спросила Делани. — Нам нужно автоматизировать тестирование так, чтобы, если движок начнет генерировать странные ходы, как наша Deep Black & White в апреле, мы сразу узнали об этом.

— Абсолютно согласен, — заметил Прасад. — Мы можем создать файл, который описывает позиции на доске и потом говорит, как компьютер должен реагировать.

— Приемлемых ходов может быть несколько, — сказал Аллан. — Этот файл должен допускать определение нескольких хороших ответов.

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

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

— Аллан, ты ведь должен был поднять одну карту, а не все сразу. Тебе трудно принять решение?

— Нет, просто у меня не нашлось карты с достаточно большим числом, поэтому я и поднял их все. Все эти карты, — программист показал карты с цифрами 1, 2, 3, 5 и 8, — в сумме дают 19. Это, на мой взгляд, и есть правильная оценка.

— У меня есть карты и с большими числами — 13, 20, 40 и 100, — сказал Карлос и раздал всем дополнительные карты. — Я надеялся, что они не понадобятся нам, однако их тоже можно использовать.

— А почему ты надеялся, что они не понадобятся?

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

— Итак, Аллан, ты даешь этой истории 19. Уверен? — спросила Саша, глядя на восьмерку в своей руке.

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

— Ну, тебе виднее. Но 19 — слишком много, — сказала Саша.

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

— Тестирование не кажется мне сложным. Не думаю, что с ним придется много возиться. Я создам текстовые файлы для тестирования, и все.

— Конечно, но ведь мы оцениваем историю в целом, а не твою часть работы с нею. Тестирование, может быть, и тянет только на тройку, однако нужно учитывать и время, которое потребуется Аллану, — пояснил Карлос.

— Вот незадача! Тогда Аллан прав, — сказал Прасад. — Это большая история.

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

На всех картах в этот раз было 20.

— Похоже, ты всех убедил, Аллан, — сказал Карлос. — Двадцать, однако, великовато для одной истории. Аллан, нельзя ли как-то разбить эту историю? Может быть, для начала достаточно слабого движка? С последующей доработкой перед поставкой?

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

— А что, если первый движок будет распознавать только кольца? — спросила Роуз. — Тогда мы на время смогли бы отбросить мосты и вилки. Аллан, разве ты не можешь написать программу, которая будет делать наступательные и защитные ходы, ориентированные на построение — и блокировку — только колец?

— Без проблем. Это может сработать. Поэтому давайте разобьем нашу историю на три части по числу фигур.

Все согласились и оценили эти три истории, как показано в табл. 23.4.

— Когда это была одна история, мы ее оценивали в 20 пунктов. Теперь оценка составляет 21. Нужно ли снять один пункт с какой-нибудь истории, чтобы оценка осталась на уровне 20? — спросил Фрэнк.

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

— Аллан, а как мы поступим с движками среднего и высокого уровня? На твой взгляд, в каждом случае должна быть одна история или их тоже нужно разбить на кольца, мосты и вилки?

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

— Так как бы ты сформулировал это в виде историй? — спросил Фрэнк.

— Я думаю, так: «Как игрок я могу играть против движка среднего уровня», — сказала Делани.

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

Команда продолжила обсуждение этой истории, провела раунд покера планирования и решила оценить ее в восемь пунктов.

— А потом, на мой взгляд, нам нужна история «Как игрок я могу играть против движка высокого уровня», — сказал Фрэнк.

— Она как минимум в два раза больше, чем история с движком среднего уровня, — заметил Аллан. — Предыдущую историю мы оценили в восемь. Но мне бы не хотелось давать этой истории оценку 16. Может быть, достаточно 13? Это самая скромная величина. Или все же остановимся на 16?

— Представьте, — сказал Карлос, — что карточки — это ведра. Если история равна 16, то она не войдет в ведро, которое вмещает 13. Введение новых величин нам ни к чему, поскольку это приводит к излишней точности. Мы не знаем, сколько здесь в точности: 13, 16 или 19. Важно помнить, что это всего лишь оценки, а не гарантии.

— Окей, я думаю, что эта история в два-три раза больше, чем движок среднего уровня, — сказал Аллан. — Это означает диапазон от 16 до 24. Поскольку 24 не войдет в ведро, вмещающее 20, значит, мне надо дать оценку 40? Это многовато. Наша история не тянет по размеру на пять историй с движком среднего уровня.

— Нет, я бы не стал делать этого, — ответил Карлос. — Это, конечно, ведра, но представьте, что их наполняют не водой, а песком. Значит, вы можете насыпать песок горкой.

— Перейдем к оценке, — сказал Аллан.

После этого обсуждения все единодушно согласились с Алланом и подняли оценку 20.

— Итак, мы оцениваем эту историю в 20, — сказал Карлос. — На данном этапе это нормально, но потом, вполне возможно, нам придется разбить такую работу как минимум на две части.

— Значит, нам не нужно разбивать эту историю на более мелкие, точно так же, как историю со слабым движком? — спросил Аллан.

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

— Хорошо. Идем дальше, — предложила Делани. — На очереди история «Как игрок я хотел бы иметь возможность использовать систему для игры с другим человеком на моем компьютере». Имеется в виду, что два игрока могут сидеть за одним компьютером и делать ходы по очереди с помощью клавиатуры или мыши. Все, что нам здесь нужно, это получать от компьютера сообщение, когда кто-то выигрывает.

— Другие функции, которые мы идентифицировали, по-прежнему работают, так ведь? — спросил Прасад. — Два игрока могут захотеть использовать функцию отмены и повтора или получать подсказку.

— Конечно, — ответила Делани.

— Думаю, нам надо добавить историю «Как игрок я хочу, чтобы компьютер распознавал выигрышную фигуру», — заметил Аллан.

— А разве это не часть историй о генераторе ходов?

— Да, но если мы вытащим ее, то сможем реализовать отдельно, а это позволит нам быстро написать версию игры «человек против человека» при наличии работающего генератора ходов.

Возражений не последовало, и новую историю оценили в два пункта.

— Аллан, ведь тогда понизятся оценки историй для слабого движка, не так ли? — спросил Фрэнк.

— Не должны. Я бы не стал менять их оценки. Но, если тебе так хочется, можно понизить восьмипунктовые истории до семипунктовых.

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

— Пять — это слишком мало, — сказал Аллан.

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

После двух раундов покера планирования члены команды пришли к согласованной оценке: три пункта.

— Теперь очередь истории «Как игроку мне хотелось бы, чтобы оформление игры на экране было эстетически приятным», — прочитала Делани.

— Ну наконец-то моя история, — сказала Роуз, художник.

— Да, только мне хочется переформулировать ее, — сказала Саша. — В нынешней форме она расплывчата и очень большая. Я бы предпочла, чтобы она выглядела так: «Как игрок я хотел бы иметь возможность выбирать между деревянными доской и фишками и металлическими доской и фишками». Что еще мы подразумевали под словами «эстетически приятный»?

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

— Понятно. А нельзя ли разбить это на отдельные истории? — спросила Саша.

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

— Да, вполне. Мне в любом случае пришлось бы работать над ними по отдельности.

Команда быстро оценила следующий набор историй.

— А что нам делать с этой историей? — спросил Прасад, указывая на карточку, где значилось «Как игрок я хотел бы иметь возможность иногда пользоваться подсказками».

— Что ты имеешь в виду?

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

— Ну вот, мы получили взаимозависимость: подсказку можно сделать только после реализации генератора ходов, — сказал Аллан.

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

Все согласились, и историю оценили в один пункт.

— А что бы мы сделали, если бы и впрямь захотели реализовать подсказку до разработки генератора ходов?

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

— Надо не забыть вернуться к этому вопросу позднее и сделать так, чтобы генератор подсказки действительно обращался к генератору ходов, — сказал Аллан.

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

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

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

Карлос раздал всем игрокам в покер планирования карты с нулем: «Я придержал их с тем, чтобы вы не использовали ноль до тех пор, пока не зайдет разговор о том, какая история может быть нулевой». У каждого участника теперь была колода карт, содержащая 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100.

— В нашем случае, впрочем, необходимо добавить поддержку подсказки после реализации генератора ходов. Так? — спросил Фрэнк.

— Да, мы оформим это как однопунктовую историю, — ответила Саша.

Обсуждение продолжалось до тех пор, пока команда не оценила все записанные истории. Эти истории с оценками приведены в табл. 23.5.

— Так что мы будем делать после этого? Нам нужна еще одна двухнедельная итерация на Deep Black & White, прежде чем мы сможем отправить ее издателю, — сказал Фрэнк.

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

— На это уйдет много времени?

— Нет, я собираюсь закончить все до завершения итерации, — добавила Делани. — Давайте соберемся опять через две недели, сразу после отгрузки Deep Black & White и после того, как Фрэнк соберет нас, чтобы отпраздновать завершение этой работы.

— Хорошая идея. Я займусь организацией этого мероприятия. Гамбургеры подойдут, Делани? Или мы замахнемся на пиццу?

Таблица 23.5. Оценки всех записанных историй

Текст истории	Оценка
Как игрок я могу начать новую игру	1
Как игрок я могу восстановить сохраненную игру	2
Как игрок я могу выбирать уровень сложности	1
Как игрок я могу играть против слабого движка, распознающего только кольца	8
Как игрок я могу играть против слабого движка, распознающего только мосты	5
Как игрок я могу играть против слабого движка, распознающего только вилки	8
Как игрок я могу играть против движка среднего уровня	8
Как игрок я могу играть против движка высокого уровня	20
Как игрок я хотел бы иметь возможность использовать систему для игры с другим человеком на моем компьютере	3
Как игрок я хочу, чтобы компьютер распознавал выигрышную фигуру	2
Как игрок я хочу видеть привлекательный начальный экран при загрузке игры	5
Как игрок я хочу видеть привлекательный фон вокруг игрового поля, сочетающийся с выбранной доской	5
Как игрок я хотел бы иметь возможность выбирать между деревянной и металлической доской и фишками	8
Как игрок я хотел бы иметь возможность иногда пользоваться подсказками	1
Как новый игрок я хочу иметь возможность ознакомиться с интерактивным самоучителем по игре	8
Как игрок я хочу, чтобы в игре был музыкальный фон	5
Как игрок я могу выбирать музыкальный фон игры	1
Как игрок я хочу ставить фишку на доску с помощью клавиатуры или мыши	3
Как игрок я хочу видеть визуальный индикатор очередности хода	2
Как игрок я хотел бы видеть визуальный индикатор последней поставленной фишки (возможно, сделать ее мигающей)	2
Как игрок я хотел бы иметь возможность отменять и повторять ходы	2
Как игрок я хотел бы иметь возможность сохранять партии	3
Как игрок я хочу иметь возможность закончить игру	1
Как игрок я хочу возобновлять игру так, чтобы можно было отказаться от текущей игры и начать новую	1
Как новый игрок я хочу иметь доступ к онлайновой справочной системе	8
Как игрок я хочу, чтобы все фишки выигрышной фигуры мигали или подсвечивались с тем, чтобы можно было видеть выигрышную фигуру	3
Как новый игрок я хотел бы получать предупреждение о неудачном ходе и иметь возможность отменять его	8
Как новый игрок я хотел бы, когда наступает моя очередь делать ход, видеть клетку, на которую нужно поставить фишку, чтобы ее не занял компьютер и не обыграл меня	3
Как игрок я хотел бы, чтобы компьютеру требовалось на ход не более двух секунд на 2,0 ГГц PC	8
Как игрок я хочу, чтобы система отслеживала, сколько партий я выиграл, а сколько проиграл (в зависимости от уровня сложности?)	3
Как игрок я хотел бы добавлять комментарии к сохраненным партиям	3
Как игрок я хотел бы просматривать ходы с тем, чтобы иметь возможность анализировать сыгранные партии	5

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

— Здравствуй, Делани, — поприветствовал Фрэнк аналитика. — У тебя найдется для меня минутка в это чудесное утро?

— Конечно. Я пришла пораньше, чтобы доработать анкету, которую собираюсь разослать. Посмотри, что получилось.

— Давай посмотрим, — сказал Фрэнк, усаживаясь в кресло. — Покажи, что у тебя получилось.

— Я напечатала это полчаса назад, — сказала Делани и протянула Фрэнку страницу с текстом (табл. 23.6). После этого я добавила еще кое-что, но это все равно дает представление о том, что я собираюсь разослать.

Фрэнк просмотрел страницу, которую дала ему Делани, и спросил: «Ты задаешь каждый вопрос дважды. Зачем?»

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

— Можешь ли ты привести пример, показывающий, насколько это может быть важным?

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

— Окей, согласен.

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

— Но разве это нельзя выяснить, попросив пользователей оценить важность функций по шкале от одного до пяти, как мы сделали в случае Deep Black & White? — спросил Фрэнк.

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

— Кому ты собираешься давать эту анкету?

— Я собираюсь разослать ее примерно 500 членам ряда игровых клубов, в которых, насколько мне известно, играют в Havannah. Многие из них находятся в Европе и в крупных американских городах. Тем, кто ответит, мы предлагаем купон на скидку в размере $10 при покупке наших существующих игр. Я рассчитываю получить порядка полусотни ответов. А еще я собираюсь провести небольшой телефонный опрос.

— Не многовато ли будет вопросов для респондентов, если о каждой пользовательской истории спрашивать дважды? — поинтересовался Фрэнк.

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

— Отлично. Я хочу убедиться в том, что это необременительно. Как предполагается использовать ответы, которые ты получишь?

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

Прежде чем Фрэнк успел ответить, к нему с Делани подкатил на своем кресле Аллан.

— Привет, — сказал он. — Я невольно подслушал часть вашего разговора. Звучит действительно интересно. А у остальных членов команды будет доступ к результатам твоего опроса?

— Конечно, Аллан.

— Чудесно. Знаешь, мне было бы интересно послушать парочку твоих телефонных интервью, хочу знать, что говорят пользователи. Это осуществимо? — спросил Аллан.

— Без проблем, — ответила Делани. — Понимание нашей аудитории идет на пользу всей команде. Чем больше ты и другие технари хотят участвовать в этом, тем лучше для меня. Я буду больше знать о ваших представлениях, а вы узнаете, о чем говорят клиенты.

— Идет, — сказал Аллан. — Сегодня я не могу сидеть на телефоне, мне нужно устранить ошибки в системе подсчета очков в Deep Black & White. Но в остальные дни этой недели дай мне знать, когда соберешься обзванивать пользователей.

— Непременно, — ответила Делани.

— У тебя, похоже, серьезные планы, — заметил Фрэнк. — Очень интересно. Можно рассчитывать на какие-нибудь результаты на следующей неделе?

— Несомненно. ИТ-группа обещает разместить анкету на нашем сайте уже завтра. После этого предварительные результаты могут появиться в любой момент.

— Чудесно. Спасибо тебе за информацию, — сказал Фрэнк и откланялся.

— Жаль, что нам не удалось реализовать все. Тем не менее меня удивляет, как много мы сделали, — говорила Саша коллегам, пока они ждали начала совещания.

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

— Не стоит, Аллан. Все жалеют об этом, но продемонстрировать движок, который умеет выстраивать кольца и мосты, было важнее, — ответила Саша.

— Все готовы к представлению демоверсии? — спросил Фрэнк, который вошел в зал точно в 9:00. Он поставил на стол коробку с булочками.

— Конечно, — ответила Саша. — На анализе результатов итерации будет присутствовать кто-нибудь из руководства?

— Обещали быть Фил и Лора, — сказал Фрэнк.

— А еще придет пара инженеров из других команд. Они очень интересуются agile-подходом к разработке, — добавил Аллан.

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

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

— Это фантастика, — заявил Фил, поднимаясь с кресла. — Так вы будете показывать что-то новое каждые две недели?

— Да. Каждые две недели здесь в 9:00, — ответила Саша.

— Я обязательно приду. Я включу эти совещания в свой график. Эта получасовая демонстрация работы реальной программы более полезна, чем отчет о ходе работ, который я обычно читаю. А вы определились со сроками? Могу я сейчас об этом спросить?

— Конечно, — ответил Фрэнк. — Сейчас мы придерживаемся нашей прежней оценки: 12–20 недель. После этого совещания мы будем планировать следующую итерацию. Через две — четыре недели мы будем знать больше. А пока нам необходимо определить сроки, которые можно сообщить издателям.

— Отлично, — сказал Фил.

Он и Лора вышли из конференц-зала. За ними последовали еще человек пять, которые приходили познакомиться с проектом.

— Если я не ошибаюсь, — сказал Фрэнк, — наша плановая скорость составляла 18 пунктов.

— Именно столько, — ответила Делани.

Однако нам не удалось завершить историю о распознавании выигрышной фигуры, поэтому наша скорость оказалась меньше 18. Можем ли мы дать себе один пункт за выполнение половины этой истории? — спросил Фрэнк.

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

— Поэтому наша скорость составила 16 с учетом того, что мы оценили незаконченную историю в два пункта, — сказала Роуз.

— Так мы должны исходить из того, что выполнение проекта займет больше времени. Правильно? — спросил Фрэнк.

— Мы все еще не вышли из диапазона 12–20 недель, который представили руководству, — сказала Саша. — Мы начали, имея 132 пункта, выполнили 16, значит, у нас осталось 116 пунктов. Делим 116 на 16 и получаем 7,25. Для страховки скажем, что это скорее восемь двухнедельных итераций. С учетом прошедших двух недель в сумме получается 18 недель.

— Это на две недели больше, чем четыре месяца, Фрэнк. Это существенно? — спросил Прасад.

— Нет, на самом деле. Релиз не привязан к конкретной дате. Мы просто хотим сделать его как можно быстрее, — ответил Фрэнк. — Да, должен вам сказать, мы не закрыли договор на Deep Black & White с японским издателем. Они все еще хотят издавать игру. До подписания окончательного договора осталось совсем немного. Однако они не хотят начинать продажу игры, пока не запустят серьезную маркетинговую программу с рекламой во всех крупнейших журналах. На это может уйти четыре месяца. Деньги же мы начнем получать только через квартал после начала продаж. Таким образом, прежде чем Deep Black & White принесет нам какие-нибудь деньги, может пройти восемь месяцев. Было бы хорошо, если бы Havannah дала быструю отдачу. Пусть даже не в таком масштабе, как Deep Black & White. Но из-за того, что она не требует предварительной рекламной раскрутки, выручка от нее может поступить быстрее.

— Фрэнк, прошу прощения, но из-за более значительного объема тестирования, которым мне пришлось заниматься, я мало что сделала для исследования продукта во время этой итерации, — сказала Делани.

— Ничего страшного, но пусть это будет приоритетом в следующей итерации, даже в ущерб объему тестирования, — успокоил ее Фрэнк.

— Итак, Фрэнк, что бы ты хотел видеть реализованным в следующей итерации?

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

— Но, если наша скорость в прошлой итерации была равна 16, почему мы в этот раз включаем в план 18 пунктов? — спросил Фрэнк.

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

— Почему?

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

— Убедили, — сказал Фрэнк. — Давайте так и сделаем.

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

— Игра начинает приобретать очертания. Не могу поверить, что ваш генератор ходов уже может обыграть меня, — сказал Фил. — Роуз, эти первые две доски выглядят фантастически. Сроки у нас все еще прежние? Через 8–16 недель с текущего момента?

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

— Мне нравится то, что ты сказал насчет увеличения выручки, — сказала Лора, финансовый директор.

— Мне тоже, — поддержал ее Фил. — Но я не в восторге от возможного переноса сроков.

— Речь идет не о переносе сроков, Фил, — сказал Фрэнк. — Если имеются в виду первоначально запланированные 12–20 недель, то мы не видим здесь проблемы. Но после этого совещания мы собираемся обсудить, насколько больше времени займет создание более ценной игры. А после мы посмотрим, нет ли таких функций, от которых можно отказаться, чтобы уложиться с более ценной игрой в те же 20 недель.

— Я всегда за более ценные игры. Сообщите мне о своем решении, — сказал Фил, покидая конференц-зал. Вслед за ним вышли и остальные гости. В зале осталась только проектная команда.

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

— Звучит занятно, — вмешался Аллан. — Это изменит генератор ходов, но, пожалуй, не сильно. Его уже сейчас можно настроить на более агрессивную или более консервативную игру.

— Это первая новая функция, — продолжила Делани. — Вторая — это онлайновая игра. Люди хотят играть друг с другом в сети.

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

— Мы можем с кем-нибудь скооперироваться для этого, — заметил Фрэнк. — Это не такой уж сложный вопрос, но, ты права, он большой. Делани, ты представляешь, какая функция более важна?

— Характеры. Хорошие характеры должны стать действенно очень привлекательными. Это функция, которая реально понравится людям, но которую они совершенно не ожидают, — ответила Делани.

— Делани, ты только что сообщила, что объем работ поползет. Но мы ведь и так уже у верхнего края нашего 12–20-недельного диапазона, — заметил Прасад. — Почему же ты говоришь, что это «хорошая новость»? У тебя есть еще что-то для нас?

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

— Давайте займемся этим, — сказал Фрэнк. — Я полностью готов изменить сроки проекта, если мы сможем больше заработать. И это не такая уж большая отсрочка. Эти функции выглядят очень заманчиво.

— Но, Делани, почему анкета, которую ты рассылала, не позволила идентифицировать эти функции? — спросил Прасад.

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

— Мне нравится эта мысль, — сказал Аллан. — Если игра принесет больше денег, возможно, Фрэнк пригласит нас в какое-нибудь более дорогое местечко, чем Fatburger, чтобы отпраздновать выпуск релиза.

— Мне понравились бургеры, когда мы отмечали выпуск Deep Black & White, — сказал Прасад.

— А мне нет. После нынешнего релиза, я думаю, Фрэнк раскошелится на суши, — заметила Роуз.

Команда оценила новые истории, записанные Делани. При этом одни первоначальные истории были разбиты, а другие объединены. Когда обсуждение закончилось, истории, связанные с онлайновой игрой, оценили в 30 пунктов. Созданию первого характера присвоили 15 пунктов, а каждому последующему — пять пунктов. Поразмыслив, команда пришла к выводу, что пяти характеров будет вполне достаточно. Это означало, что разработка характеров в сумме вносит 35 дополнительных пунктов.

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

— В первых двух итерациях мы реализовали 16 и 18 пунктов. Теперь мы добавили 35 пунктов и, таким образом, вернулись туда, где были! — пошутил Аллан.

— Ты прав, Аллан, — сказал Карлос, доставая калькулятор. — Мы получили 133 пункта. При текущей средней скорости 17 пунктов на итерацию нам нужно 7,8 итераций.

— Восемь итераций плюс две, которые мы уже выполнили, итого 10 итераций, — сказал Фрэнк.

— Мы подошли ужасно близко к пределу, Фрэнк, — сказала Саша. — Да, похоже, мы справимся с работой за 10 итераций. Как хорошо, что мы установили первоначальный срок в виде диапазона и не сказали просто «восемь итераций». Все же если что-то пойдет не так — если история окажется больше, чем мы думали, или мы замедлимся, или кто-нибудь заболеет, — то нам может потребоваться больше восьми итераций.

— Не хочешь ли ты сказать, что нам нужно изменить сроки? — спросил Фрэнк.

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

— Пожалуй, при необходимости я могу отказаться от некоторых историй, — сказал Фрэнк.

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

— Вот парочка тех, без которых я могу прожить: «Как новый игрок я хотел бы получать предупреждение о неудачном ходе и иметь возможность отменять его» и «Как новый игрок я хочу иметь возможность ознакомиться с интерактивным самоучителем по игре». Каждая из них тянет на восемь пунктов. Еще, как я уже говорил, я вполне могу обойтись без историй о музыкальном фоне на шесть пунктов.

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

— А если мы уложимся в график и решим отказаться от реализации этих историй, то сможем выпустить релиз как минимум на одну итерацию раньше, так? Когда мы должны выпустить релиз, если откажемся от этих историй? — спросил Фрэнк.

— У нас включено в план 133 пункта. Вы готовы выбросить 22 пункта. Остается 111 пунктов, — сказал Карлос, отрываясь от калькулятора. — При скорости 17 вам нужно еще семь итераций. Это означает, что проект можно завершить за 18, а не за 20 недель.

— Пусть эти истории пока остаются в плане. Я сниму их при необходимости, но на них, пожалуй, стоит потратить две недели, — сказал Фрэнк. — Я хочу показать этот новый план Филу, он хотел узнать, что мы решили. Кто-нибудь хочет составить мне компанию?

Сопровождать Фрэнка вызвались Делани и Аллан. В случае Делани удивляться здесь нечему — как аналитик, она часто участвовала в принятии решений по продукту и срокам. А вот интерес Аллана удивил Фрэнка. Обычно Аллана, одного из самых консервативных технарей в Bomb Shelter, совершенно не трогали споры в сфере бизнеса. Однако с начала этого проекта четыре недели назад он по-настоящему стал участвовать в них. Фрэнк оценил перемены. Это позволяло принимать более качественные решения по продукту.

— Я иду прямо сейчас, — сказал Фрэнк. — Давайте покажем, что получилось.

— Может, лучше сначала подготовить демонстрационные материалы для Фила? — спросил Аллан.

— Лишнее. У него есть магнитно-маркерная доска. Мы нарисуем все на ней.

— Привет, Фил. Ты по-прежнему хочешь узнать, что мы решили по этим новым функциям в Havannah? — спросил Фрэнк.

— Конечно. Это те функции, о которых Делани говорила утром?

— Да.

— У меня есть примерно 15 минут. Хватит?

— С лихвой, — сказал Фрэнк. Затем он попросил Делани объяснить, как ее исследование привело к появлению новых идей по онлайновой игре и характерам.

— Фил, помнишь, как я несколько недель назад рассказывала об оценках историй в пунктах?

— Конечно.

— И о том, что пункты — это показатель размера. Мы начали со 132 пунктов. В первой итерации было реализовано 16 пунктов, во второй — 18. Аллан, можешь изобразить это в виде графика? — попросил Фрэнк, указывая на свободное место на доске Фила. Аллан подошел к доске и начертил то, что изображено на рис. 23.5. — То, что ты здесь видишь, — продолжил Фрэнк, — мы называем диаграммой выгорания релиза. Глядя на нее, ты можешь видеть наш темп прогресса. После двух итераций мы реализовали 34 пункта. Если продолжить линию, то ты увидишь, что мы завершаем работу на восьмой итерации. Это в сумме 16 недель.

Пока Фрэнк говорил, Аллан продлил линию, как показано на рис. 23.6.

— Команда Havannah сошлась на том, что добавление характеров, идентифицированное Делани, это хорошая идея.

— Сколько времени это займет? — спросил Фил.

— Мы считаем, что нам нужно пять характеров. Всего это 35 пунктов, — ответил Фрэнк.

— Это означает, что наше выгорание фактически возвращается сюда, — сказал Аллан. Он провел вертикальную линию вверх до уровня 133 пункта, как показано на рис. 23.7.

— М-м-м… Выглядит не очень хорошо. После двух итераций вы на том же месте, откуда начинали.

— В действительности наше положение намного лучше. За четыре недели мы заметно продвинулись вперед, — сказал Аллан, указывая на линию на диаграмме. — Мы устранили некоторые из наиболее рискованных частей проекта, было показано, как идет разработка генератора ходов. Хотя был сделан только слабый движок, я понял, как нужно подходить к созданию сильного движка. Мы многому научились. Мы нашли новую функцию, которую Делани определила как привлекательную для целевой аудитории. Обычно это выясняется намного позже. Если смотреть на то, где мы находимся, то действительно кажется, что у нас столько же работы, сколько было четыре недели назад, но сейчас я намного больше уверен в плане, чем тогда. И каждый раз, когда мы добавляем новую точку на этой диаграмме выгорания, моя уверенность крепнет, хотя далеко не все новости хорошие. Главная новость в том, что я могу быть уверенным в нашем прогрессе. — Аллан остановился. — Нет, наше положение намного лучше, чем четыре недели назад.

— Так сколько займет проект, если мы добавим характеры? — спросил Фил. К приятному удивлению Фрэнка, этот вопрос был адресован Аллану.

— Возможно, еще восемь итераций, или всего 20 недель. За итерацию мы выполняем работу объемом 17 пунктов. Это называется скоростью. Если продлить линию, показывающую скорость 17 пунктов на итерацию, то, как видно, мы завершим проект через восемь итераций. — Аллан продолжил линию, как показано на рис. 23.8. — Это очень близко к предельному сроку, поэтому мы идентифицировали несколько низкоприоритетных элементов, от которых можно отказаться, если начнем отставать или если решим выпустить релиз через 18 недель вместо 20.

— И игра будет продаваться лучше или по более высокой цене? — спросил Фил.

— Да, я уверен в этом, — сказал Фрэнк. — Я хочу провести еще несколько исследований и построить модель, чтобы решить, следует ли нам продавать по текущей цене или можно увеличить ее на $5.

— Вы меня убедили. Спасибо за презентацию, — сказал Фил.

Аллан начал стирать нарисованную диаграмму.

— Не надо. Пусть останется, — сказал Фил. — Я хочу обновлять ее каждые две недели.

— Спасибо, что уделил нам время, Фил, — сказал Фрэнк, когда они с Делани и Алланом покидали кабинет.

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

— Допускаю, что получилась отличная игра, но мне не нравится ощущение запаздывания. Первоначально мы думали, что ее можно сделать всего за 14 недель, но всем говорили, что за 12–20 недель. А в результате мы сдали работу еще на две недели позже, — сказал Прасад.

— Да, мы сделали ее за 22 недели, — сказала Саша. — Но мы и не говорили, что сдадим ее через 14 недель. После планирования первой итерации мы утверждали, что нам требуется от 12 до 20 недель, а более точная оценка появится только через шесть недель.

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

— А еще не забывайте, что Deep Black & White вышла позже на полгода, а не на две недели.

— Так что, Фрэнк, ты опять будешь угощать нас бургерами в честь этого релиза?

— Нет, на этот раз я куплю вам все, что вы пожелаете.