hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

21

Какой длины веревочка?

Черная магия оценки продолжительности проекта

В этой главе:

•Зачем нужно оценивать время?

•Почему оценивать так трудно?

•Практические способы оценки

•Как уложиться в график

Я никогда не гадаю. Очень дурная привычка – действует пагубно на способность логически мыслить.

Шерлок Холмс (Сэр Артур Конан Дойл)

Так какой же длины веревочка? Или в на% шем случае сколько веревочке виться? На этот вопрос столь же непросто ответить, и смысла в нем примерно столько же.

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

Правила промышленного производства про% грамм неизбежно подчиняются экономике – денежным потокам. Оценки времени важны,

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								508m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 21. Какой длины веревочка?Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

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

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

Выстрел в темноте

В любой организации, в любом проекте и в любой момент оценки сро% ков разработки программного обеспечения представляют собой лишь основанные на фактах догадки – иначе они и не были бы оценками. Га% дание, конечно, вызывает сомнение в профессионализме, но ничего лучшего не существует: вы никогда не узнаете точно, сколько времени требует задача, пока она не будет завершена, а к тому моменту эта ин% формация обычно оказывается бесполезной.1

1За исключением того, что у вас появляется опыт для будущих оценок.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Почемуm		трудно делать оценки?
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
509Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

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

Хорошие оценки обоснованны и оправданны, а плохие делаются наугад. Это стандартная техническая проблема, требующая проницательно% сти и гибкости в управлении. Так было из века в век.1 Менеджеры и планировщики имеют дело с оценками для проекта в целом. Это ис# ключительно трудное занятие. Мы рассмотрим только оценки для от% дельных задач программирования. К счастью, это не исключительно, а просто трудно.

Почему трудно делать оценки?

Я живу в Кембридже, в Соединенном Королевстве; моя семья живет в Бристоле. Оценка времени разработки похожа на оценку времени, ко% торое мне нужно, чтобы навестить своих родственников. Легко опреде% лить длительность поездки при попутном ветре и отсутствии пробок. Но если на дороге ведутся работы, или есть пробки, или сломается машина, или я поздно выеду, или я поеду в часы пик, оценка становится менее надежной. Если я предвижу какие%то проблемы, то могу назвать вероят% ный интервал времени своего прибытия. Я знаю, сколько займет поезд% ка в самых благоприятных обстоятельствах; у меня есть представление

1Пример из Библии есть у Луки 14:28!

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								510m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 21. Какой длины веревочка?Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

Такого рода примеры показывают, почему оценка продолжительности разработки так трудна и так важна. Есть масса факторов, осложняю% щих эту задачу:

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

•В предъявляемые к системе требования постоянно вносятся кор% рективы, увеличивающие объем задачи. Во время технико%эконо% мического обоснования проекта новые задачи и требования пользо% вателей выявляются с невероятной скоростью. Это осложняет зада% чу оценки – удовлетворить всех очень трудно (как с этим справ% ляться, см. в разделе «Спецификация требований» на стр. 471).

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

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

Слабое звено

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Почемуm		трудно делать оценки?
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
511Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

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

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

История на этом не завершается. Трудно не только правильно сделать оценку. Не менее тяжело пережить последствия.

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

•Трудно работать согласно оценкам, выполненным кем%то посторон% ним – если вы не уложились в срок, означает ли это, что вы оказа% лись не на высоте задачи или оценка была неверна?

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

•Всегда возникают неожиданные проблемы. Мелкие проблемы мож% но компенсировать некоторым увеличением интенсивности рабо% ты, чтобы не отстать от графика. Можно ведь месяц недосыпать, правда? Но крупные проблемы влекут такой дополнительный объ% ем работы, что график может оказаться сбит.

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

сты!