Время - деньги. Создание команды разработчиков программного обеспечения

Легко заметить, что реализация двух задач в этом примере запланирована на период работы над бета-версией 1. Во время работы над любой бета-версией надо воздерживаться от добавления новых функций, особенно важных и сложных. Однако иногда есть смысл планировать включение в первую бета-версию функций, реализация которых не требует больших затрат и не вносит особого риска. Чем дольше задерживается передача программы в руки бета-тестеров, тем больше времени займёт сбор отзывов о качестве реализации и работе функций программы. Часто польза от раннего цикла бета-тестирования превышает риск включения небольших функций после начала программы бета-тестирования.

Хотя включить несколько дополнительных функций время работы над первой бета-версией ещё допустимо, в период работы над последней бета-версией реализацию дополнительных функции лучше не планировать. При работе над последней бета-версией функции остаются неизменными, и усилия команды концентрируется на качестве, производительности и интеграции. (О тестировании бета-версий см. главу 13.)

Неожиданные проблемы

Создавая план согласно описанным в этой главе принципам, вы, вероятно, будете планировать проект, как обычно. Однако разработка ПО — это не точная наука, и до проблем всегда рукой подать. Чтобы заметить малейшее отклонение проекта от намеченного пути, нужно регулярно проверять ход выполнения плана и после завершения каждого промежуточного этапа сравнивать фактическое состояние проекта с планом. Если работа отстаёт от плана, надо определить проблему, изменить план и постараться завершить очередной промежуточный этап в срок. Все так просто? Однако это та самая ситуация, когда от менеджера проекта и ведущих специалистов требуется полная самоотдача. Поскольку очень сложно вести работу над проектом, не отставая от графика, в третьей части основное внимание уделено именно этому вопросу.

Типичные проблемы и их решение

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

Ничего не получается!

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

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

Это сложнее, чем кажется на первый взгляд…

Кажется, что втиснуть задачи в рамки 1-2 недель так просто, но это может быть настоящим испытанием. Наверное, в плане всегда найдётся задача, на выполнение которой отводится 3-5 недель. Такую долгосрочную задачу лучше разбить на несколько меньших. Чем чаще контролируется прогресс проекта, тем проще обнаружить отклонения от плана. Как правило, трудности при разбиении задачи возникают из-за неполного её понимания, а это тревожный признак. Чтобы лучше разобраться в том, что предстоит сделать, решение нужно смоделировать.

Потеря согласованности

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

Часть 3

Исполнение проекта

Глава 12

Держим курс

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

Анология с самолётом

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

• План полёта