Текст книги "Agile: оценка и планирование проектов"

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

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

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

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

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

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

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

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

Часть II
Оценка размера

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

Допустим теперь, что я пошел другим путем: посмотрел на кучу и оценил ее величину. На основе ее размеров я прихожу к выводу, что объем земли составляет примерно 8,5 м3. Это моя оценка размера данного проекта. Однако оценка одного лишь размера бесполезна в этой ситуации. Нам нужно узнать, сколько времени займет перемещение земли. Поэтому необходимо преобразовать оценку размера (8,5 м3) в срок.

Из ярлыка на моей тачке следует, что ее вместимость составляет 0,17 м3. Разделив 8,5 м3 на 0,17 м3, я определяю, что для перемещения земли мне потребуется 50 ездок. По моим прикидкам, для погрузки земли на тачку уйдет 3 минуты, для перемещения тачки на другой конец двора и выгрузки земли – 2 минуты, а на возврат с пустой тачкой к куче – 1 минута. Всего одна ездка займет 6 минут. Поскольку мне нужно сделать 50 ездок, расчетный срок работы составит 300 минут, или 5 часов.

Процесс оценки срока для проекта по разработке программного обеспечения показан на рис. II.1.

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

Глава 4
Оценка размера в пунктах

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

Актриса Долли Партон в кинофильме «Стальные магнолии»

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

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

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

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

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

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

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

• терьер;

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

• пудель;

• такса;

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

• сенбернар;

• бульдог.

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

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

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

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

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


[Закрыть]. Если команда реализует три истории, каждая из которых оценивается в 5 пунктов, то ее скорость равна 15, а если две истории по 5 пунктов – 10.

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

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

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

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

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

Скорость обеспечивает корректировку ошибок оценки

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

Чтобы понять, как это работает, представьте, что вас подрядили покрасить дом, который вы никогда не видели. Вам показывают план помещений (рис. 4.2) и говорят, что обеспечат всеми необходимыми материалами, включая кисть, валик и краску. Вам хотелось бы знать, сколько времени уйдет на эту работу, поэтому вы проводите предварительную оценку. Поскольку все, что у вас есть, – это план помещений и вы еще не видели самого дома, оценка основывается на информации, которую можно получить из плана. Допустим, что трудозатраты на покраску каждой из небольших спален вы оцениваете в 5 пунктов. Цифра «пять» не несет в себе никакого физического смысла, однако она показывает, что трудозатраты на покраску каждой спальни будут одинаковыми. Хозяйская спальня примерно в два раза больше других спален, поэтому вы оцениваете трудозатраты на нее в 10 пунктов.

Теперь посмотрите еще раз на рис. 4.2 и обратите внимание на то, что на плане нет размеров. Какие габариты у двух спален – 2,5×3,0 м или 4,8×6,0 м? По плану это определить невозможно. Можно ли утверждать, что оценки, которые вы дали, совершенно бесполезны на данный момент? Нет. На деле эти оценки по-прежнему полезны, поскольку они представляют собой относительные трудозатраты на покраску каждой комнаты. Если окажется, что спальни в два раза больше, чем вы думали, то хозяйская спальня будет также в два раза больше. Оценки останутся теми же, но из-за того, что площадь помещений оказалась в четыре раза больше, чем вы ожидали, темп выполнения работы будет ниже.

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

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

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

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

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

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

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

Глава 5
Оценка размера в идеальных днях

Для великих свершений нужны две вещи: план и нехватка времени.

Леонард Бернстайн

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

Вы можете сказать, что в матче четыре 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 %)? Какой срок труднее оценить?