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

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

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

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

При такой оценке необходимо учитывать множество действующих факторов. Первое, и в идеале самое главное, — прогресс, которого добивается команда. Второе — изменение объема проекта. Владелец продукта может добавлять или удалять требования. Если он добавляет 40 пунктов, а команда реализует 30, то у нее остается больше работы, чем в начале предыдущей итерации. Цель сдвигается, и полезно знать, как далеко команда находится от достижения новой цели. Или разработчики могут получить во время итерации такие знания, которые заставят их пересмотреть оценки в пунктах, присвоенные последующим работам в плане релиза.

Эти факторы (выполненная работа, изменение требований и пересмотренные оценки) можно считать аналогами силы ветра (называемой дрейфом ) и силы моря (называемой сносом ). Посмотрите на рис. 19.1, где показаны силы, действующие на парусную лодку. Лодка на этом рисунке проходит меньшее расстояние, чем то, которое должно получиться на основе показаний ее измерителя скорости. Аналогичным образом, даже если компас лодки показывает на восток в течение всего плавания, ветер заставит эту лодку сместиться к югу. Без корректировки курса нашей лодке потребуется больше времени, чтобы добраться до цели, не вполне совпадающей с первоначальной. Мысленно переименуйте стрелки на рис. 19.1 так, чтобы дрейф и снос стали изменением требований (добавлением или удалением функций) и изменением оценок. Теперь рис. 19.1 отражает проблемы отслеживания прогресса софтверного проекта по отношению к его календарному графику.

Темп продвижения корабля измеряют в узлах; agile-команда измеряет темп своего продвижения в единицах скорости. Скорость выражается как число пунктов (или идеальных дней), реализованных за итерацию. О команде, которая реализовала 12 историй, оцениваемых в сумме в 30 пунктов, в прошлой итерации, говорят, что ее скорость равна 30, или 30 пунктам на итерацию. Если считать, что объем проекта не меняется, то именно на столько меньше работы осталось выполнить команде.

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