Каталог статей.


Изучаем «Планирование» как одну из методик экстремального программирования.

В этой статье мы опишем игру в планирование из практики экстремального программирования. Она похожа на подход к планированию в нескольких других методиках гибкой разработки: SCRUM, Crystal, разработка по свойствам (FDD) и адаптивная разработка ПО (ADP). Однако ни в одном из этих процессов описываемая методика не сформулирована так детально и строго.

 


Первичное обследование


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


Вновь выявленная функция разбивается на одну или несколько пользовательских историй, которые записываются на учетной карточке или чем-то подобном. Много писать не надо, достаточно названия истории (например, «Вход в систему», «Добавление пользователя», «Удаление пользователя», «Изменение пароля»). На этой стадии мы не пытаемся зафиксировать все детали, а просто хотим оставить памятку о состоявшемся разговоре по поводу функций системы.


Разработчики совместно оценивают истории. Эти оценки относительны, а не абсолютны. Мы записываем на карточке число «баллов», то есть относительную стоимость истории. Мы не знаем точно, сколько времени потребуется на реализацию истории, но можем сказать, что на историю стоимостью 8 баллов уйдет в два раза больше времени, чем на историю стоимостью 4 балла.


Объединение, разбиение и скорость


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


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

• Пользователь может войти в систему;

• Пользователь может выйти из системы;

• Пользователь может положить деньги на свой счет;

• Пользователь может снять деньги со своего счета;

• Пользователь может перевести деньги с любого из своих счетов на другой.


После разбиения или объединения историю нужно заново оценить. Было бы неправильно просто сложить или вычесть оценки. Весь смысл разбиения и объединения историй состоит в том, чтобы получить размер, при котором оценка точна. Нередко бывает, что история, первоначально оцененная в 25 баллов, раскладывается на истории, которые в сумме дают 30 баллов! Тридцать - более точная оценка.


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


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


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


Планирование выпуска


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


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


Планирование итерации


Затем разработчики и заказчик определяют длительность итерации: обычно 1 или 2 недели. И снова заказчик решает, какие истории реализовать на первой итерации, но не может выбрать больше историй, чем позволяет текущая скорость.


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


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


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


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


Определения понятия «готово»


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


Планирование задач


В начале новой итерации разработчики и заказчики вырабатывают план. Разработчики разбивают истории на задачи. Задачей называется объем работы, с которым один разработчик может справиться за 4-16 часов. Истории анализируются совместно с заказчиком, и задачи формулируются максимально полно.


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


Разработчик может выбрать любую задачу. Специалисты по базе данных не обязаны ограничиваться только задачами, связанными с базой. Специалисты по разработке ГИП могут при желании выбрать задачу, касающуюся базы данных. Хотя на первый взгляд это может показаться неэффективным, но выгода очевидна: чем больше каждый разработчик знает о проекте в целом, тем успешнее и информированнее вся команда. Мы добиваемся, чтобы за проект отвечала команда целиком, независимо от специализации.


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


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


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


Предположим, к примеру, что заказчик выбрал восемь историй на общую сумму 24 балла. Пусть они были разбиты на 42 задачи. Ожидается, что в середине итерации будет завершена 21 задача и набрано 12 баллов. Эти 12 баллов должны соответствовать полностью закрытым историям. Наша цель - завершить реализацию историй, а не просто задач. Кошмарная ситуация возникает, когда к концу итерации завершено 90% задач, но ни одной истории. В середине пути мы хотим видеть завершенные истории на сумму, равную половине общего числа баллов, запланированного на данную итерацию.


Подведение итогов итераций


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


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


Мониторинг


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


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


Рассмотрим также график на рис. 2. Это диаграмма выгорания; она показывает, сколько баллов оставалось набрать в конце каждой недели до следующей важной контрольной точки. Наклон этого графика - разумный индикатор даты завершения.


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


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


Заключение


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


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


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


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