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

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


[Закрыть], «неспособность учиться – единственная настоящая ошибка». Учитесь на каждой переоценке истории и приближайтесь к успеху.

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

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

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

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

Глава 8
Что выбрать – пункты или идеальные дни

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

Генерал Джордж Паттон

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

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

• Пункты способствуют выработке кроссфункционального поведения.

• Оценки в пунктах не устаревают.

• Пункты – это чистый показатель размера.

• Оценка в пунктах обычно требует меньше времени.

• Мои идеальные дни – это не ваши идеальные дни.

Пункты способствуют выработке кроссфункционального поведения

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

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

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

Оценки в пунктах не устаревают

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

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

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

Пункты – это чистый показатель размера

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

То, что пункты являются чистым показателем размера, дает два преимущества. Во-первых, это означает, что у нас есть возможность оценивать истории исключительно по аналогии. Существуют убедительные свидетельства того, что мы намного лучше оцениваем объекты по принципу «это похоже на то», чем определяем абсолютный размер объектов (Lederer and Prasad, 1998; Vicinanza et al., 1991). При использовании идеальных дней мы также можем оценивать по аналогии, однако в этом случае мы мыслим в категориях календарного графика и продолжительности реализации истории.

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

Оценка в пунктах обычно требует меньше времени

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

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

Мои идеальные дни – это не ваши идеальные дни

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

Предположим теперь, что вместо обсуждения длины дорожки эти два бегуна начинают обсуждать время, за которое пробегут ее. Быстрый бегун может сказать: «Это пятиминутная дорожка». Медленный бегун может ответить так: «Нет, чтобы одолеть ее, нужно не менее восьми минут». Конечно, и тот и другой правы, но прийти к согласию они могут только в том случае, если всегда будут обсуждать дорожки с точки зрения времени одного из них (или кого-то другого).

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

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

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

• Идеальные дни легче объяснить за пределами команды.

• Идеальные дни легче использовать для оценки в начальный момент.

Идеальные дни легче объяснить за пределами команды

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

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

Идеальные дни легче использовать для оценки в начальный момент

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

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

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

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

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

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

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

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

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

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

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

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

Часть III
Планирование на основе стоимости

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

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

Глава 9
Приоритизация тем

Чтобы получить то, чего вы хотите, сначала нужно решить, что именно вам нужно.

Бен Стейн

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

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

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

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

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

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

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

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