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
521Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

цикл проекта – с начала и до конца. Процесс планирования PRINCE со% стоит из семи ступеней, включая проектирование плана, оценивание и составление графика и выполнение плана. На базе этой модели была развита новая модель с оригинальным названием PRINCE2.

Не отставай!

Как получается, что проект опаздывает на год?

. . . Это происходит по одному дню.

Фредерик П. Брукс

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

При наличии реалистичных оценок длительности задач программиро% вания есть несколько способов уложиться в график и избежать спеш% ки последних минут:

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

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

1Забавно, что хорошие оценки тоже могут стать причиной этой проблемы. Демарко и Листер вспоминают реальный случай, когда руководитель про% екта доложил о своей 100%процентной уверенности в своевременном и не выходящем за рамки бюджета завершении проекта (DeMarco 99). Менед% жеры, опешившие от таких хороших новостей, решили перенести оконча% тельный срок на более раннее время! Как бы ни был хорош инженер, всегда

найдется еще лучший менеджер, который погубит весь его тяжелый труд!

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								522m
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

Все зависит от планирования

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

Утром в понедельник мы прибыли на новое место, и действи% тельно все было установлено и отлично работало! Вся инфра% структура IT была в порядке. Серверы были подключены к сети и полностью функционировали. Все рабочие места были настрое% ны. Огромная работа!

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

И это называется планированием.

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

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

Постоянно сверяйте свои успехи с планом. Тогда не случится внезапно обна& руженного отставания.

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

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

				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
523Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

•Пишите добротный код с полным набором тестов для модулей. Для опытного мастера это должно быть очевидно! В результате вы резко снижаете время на отладку и сопровождение.

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

впоследние несколько дней перед датой окончания требовалось

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

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

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

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

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

•Поддерживайте позитивный и оптимистичный подход. Если ду%

мать, что проект обречен, так оно и окажется на деле.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								524m
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

Удача – это оценка бездельником успеха работяги.

Неизвестный автор

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

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

Хорошие программисты…

•Делают хорошие оценки, учи% тывая все составляющие про% цесса разработки и основываясь на разумном разделении систе% мы на компоненты

•Стремятся выпускать отлажен% ный код с полной документаци% ей и надлежащей интеграцией в отведенных временных рамках

•Выявляют проблемы со сроками на раннем этапе, чтобы их мож% но было своевременно решить

Плохие программисты…

•Делают оптимистичные оцен% ки, основываясь на догадках и внутреннем голосе

•Могут выдать код в установлен% ные сроки, не успев отладить его и придать законченный вид

•Считают, что сообщить о воз% можности не уложиться в срок – признак слабости, и отчаянно пытаются догнать график, а ко% гда это не удается, выглядят глупыми и измученными

См. также

Глава 13. Важность проектирования

Надежные оценки сроков исполнения могут основываться только на крепком начальном проекте кода.

Глава 19. Спецификации

Чтобы сделать правильную оценку, нужно четко определить объем работ, который недвусмысленно должен быть отражен в специфи# кации.

Глава 22. Рецепт программы

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