Читать книгу "Agile: Оценка и планирование проектов - Майк Кон"

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

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

Доводы в пользу пунктов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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