Глава 15. Первый план

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

Составляем первый план

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

Конечно, он будет так же неточен, как и оценки.

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

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

Скорость вычисляется опытным путем. Вы все равно не получите мало-мальски правдивые цифры, пока не пройдете несколько итераций. До этого можно лишь делать предположения.

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

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

Определить объем работ по отдельным задачам очень сложно, особенно поначалу. Легче всего нам было сделать это следующим образом: сначала команда рассматривала те задачи, объем которых было совсем несложно оценить. Для этого программисты задавали себе вопрос: «Если бы я должен был сделать только эту задачу, и ни на что не отвлекался бы в процессе работы, сколько бы она заняла времени?» Когда с легкими задачами было покончено, мы переходили к более сложным, взяв за основу только что полученные оценки.

А если рядом с вами работает команда, у которой уже есть опыт подобных разработок? Можно ли использовать их опыт? Да, только не просите их оценивать объем задач вместо вас. Это нарушает основное правило ХР – оценивает объем работы тот, кто будет ее выполнять. Те, кто пользуются чужими оценками, постепенно теряют чувство ответственности, у команды исчезает боевой дух. Не сделайте такую ошибку.

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

Выбираем продолжительность итерации

Как долго должна продолжаться итерация? У итеративного способа разработок есть множество приверженцев, и каждый отвечает на этот вопрос по-своему. Некоторые, например, утверждают, что итерации могут быть длиной до полугода. Мы придерживаемся противоположного мнения: итерация должна быть очень короткой, от одной до трех недель. Лично мы предпочитаем две недели, а согласно недавнему опросу[1], большинство людей считает, что размер итерации не должен превышать трех недель.

Таблица 15.1. Какова должна быть продолжительность одной итерации?а

Choices

Варианты

Votes

Проголосовало

Percent

В процентах

Week (weeks)

Неделя (недели)

Month

Месяц

a. Based on 37 replies

а. На основе 37 ответов

 

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

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

l      Нужно убедиться, что все приемочные тесты работают

l      Нужно спланировать итерацию

l      Нужно отчитаться перед руководством

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

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

И еще один вопрос: когда начинать новую итерацию? Вы будете удивлены, когда узнаете, сколько команд избегают начинать новую итерацию в понедельник. Как выразился один из клиентов Кента: «Понедельник – тяжело. Планирование – тяжело. Так зачем же совмещать одно с другим?» Этот клиент предпочитает, чтобы итерации начинались во вторник, и надо сказать, своим выбором абсолютно доволен. Понедельники пригодятся разработчикам на то, чтобы навести последний лоск: подготовить демо-версию, подчистить код, дописать тесты. Назавтра все готовы двигаться дальше.

С чего начать

Итак, у вас есть план и можно приступать к программированию, но как это сделать? Разве можно разделить работу на части, если у вас есть всего один класс?

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

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

l      Подготовить каркас для тестирования

l      Подготовить механизм полной и автоматизированной сборки системы

l      Подготовить сетевое окружение, включая различные права доступа

l      Подготовить базовые сценарии для инсталляции системы

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

 



[1] http://www.egroups.com/group/extremeprogramming (прим. авторов)


Copyright notice

© Copyright Addison-Wesley, 2001, все права защищены
© Copyright maxkir.com, перевод, 2002
© Copyright Издательский дом "Питер", 2002, все права защищены