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

• Предыдущая
• 47/64
• Следующая

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

Фундаментальная идея этой главы в том, что основные элементы пользовательского интерфейса должны быть «на местах» уже в начале работы над проектом. Их нельзя существенно изменять, если мы хотим уложиться в первоначальный план. Бесспорно, инновации не только возможны, но и необходимы, однако работу с ними нужно завершить на этапе работы с прототипом. Именно поэтому следует быстро проверять и отрабатывать разные варианты. Протестировав прототип заранее, вы избавляете себя от необходимости вносить значительные изменения в будущем. Даже при возникновении новой идеи, представляющей прорыв в данной области, сохранится уверенность в том, что текущие идеи в состоянии удовлетворить потребности рынка, что позволит уложиться в план. Я не говорю, что во время реализации проекта нельзя вносить небольшие изменения. Как правило, во время разработки возникает масса полезных идей, существенно повышающих ценность программы с очень небольшими затратами. Многие из них вполне могут быть реализованы без риска срыва плана или возникновения серьёзных проблем.

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

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

Прежде чем приступать к планированию, нужно уяснить требования к проекту, особенности технологии, намеченной для использования в нём, и конструкцию пользовательского интерфейса программы (рис. 11-1). Разобравшись в фундаментальных аспектах проекта, можно получить чёткое представление о том, что будет создано и как это будет работать.

Рис. 11-1. Исходные данные, критически важные для процесса планирования.

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

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

Следующие понятия являются фундаментальными для создания надёжных планов.

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

Задачи — это основные строительные блоки плана, они являются представлением конкретной работы, которую нужно сделать. В общем верно, что легче следить за ходом выполнения небольших задач. Кратко и точно сформулированные задачи позволяют быстро обнаружить отставание от плана. Если задачу нельзя завершите за 1-2 недели, её следует разбить на две или больше меньших задач. Исполнение плана, составленного из долгосрочных задач, труднее контролировать.

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

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

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

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

• Разработка

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

• Тестирование

Этот раздел должен давать достаточно времени для создания планов и сценариев испытаний, а также для тестирования самой инфраструктуры. План испытаний должен выделять добавочное время на тестирование ПО после окончания каждого промежуточного этапа работы.

• Предыдущая
• 47/64
• Следующая