Майк Кон - Agile: оценка и планирование проектов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим другой пример. Предположим, что проект состоит из 50 пользовательских историй, каждая из которых оценена в один пункт. Для простоты будем считать, что я — единственное лицо, работающее над этим проектом, и что я реализую одну историю размером один пункт за рабочий день. Таким образом, за двухнедельную итерацию я предполагаю реализовать 10 историй и добиться скорости, равной 10. Кроме этого, я рассчитываю завершить проект за пять итераций (10 недель). За первую итерацию, однако, мне удалось реализовать не 10, а только пять историй. Если с учетом скорости, которая оказалась в два раза ниже планируемой, скорректировать мое ошибочное представление, то на проект потребуется 10 итераций.