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

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

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

Отслеживание процесса разработки релиза

 

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

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

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

Диаграмма выгорания релиза

 

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

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

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

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

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

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

 

Гистограмма выгорания релиза

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

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

Для того чтобы понять, как это работает, приведу пример. На рис. 19.4 по плану релиз должен включать объем работы, равный 240 пунктам. В начале первой итерации на диаграмме выгорания находится один столбик, вытянутый от 0 до 240. Как и прежде, команда ожидает, что ее скорость будет равна 30, а работу удастся завершить за восемь итераций. В первой итерации команда достигает ожидаемой скорости, и поэтому верхняя часть второго столбика находится на уровне 210. Владелец продукта, однако, решил, что в релизе должно быть больше функций, чем считалось первоначально. Работу, которую решили добавить к релизу, оценили в 50 пунктов. По этой причине столбик второй итерации опустился ниже нулевой линии и стал занимать пространство от –50 до 210. Другими словами, объем работы в релизе теперь составляет 260 пунктов, т. е. больше, чем вначале. К концу второй итерации, глядя на рис. 19.4, можно отметить три интересных факта.

1. Скорость команды находится на ожидаемом уровне. Это видно по выгоранию, о котором говорит расположение вершин первых двух столбиков.

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

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

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

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

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

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

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

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

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

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

• Когда работу удаляют, нижняя часть столбика смещается вверх.

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

Особенности применения гистограммы выгорания релиза

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

Диаграмма парковки

Джефф Делюка (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 пунктов.

Итоговый отчет в конце итерации

 

Контекст

 

Даты

 

Персонал

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

Рабочие дни

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

 

Показатели

 

Результаты ночной сборки

Цвет строк

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

 

Выгорание итерации

 

Скорость

 

Контент и оценка

 

 

Анализ итерации

Анализ итерации проводился в 9:00 15 сентября. Высказаны следующие предложения:

Резюме

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

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

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

Вопросы для обсуждения

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

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

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