Прежде чем приступать к планированию, нужно уяснить требования к проекту, особенности технологии, намеченной для использования в нём, и конструкцию пользовательского интерфейса программы (рис. 11-1). Разобравшись в фундаментальных аспектах проекта, можно получить чёткое представление о том, что будет создано и как это будет работать.
Рис. 11-1. Исходные данные, критически важные для процесса планирования.
Однако если основные требования не определены, а самые рискованные фрагменты программы не отработаны на прототипах или моделях интерфейса, то для разработки точного плана просто не хватит данных. Тогда сформулировать все задачи проекта и точно оценить время, необходимое для выполнения каждой из них, будет невозможно. Поэтому весь проект будет составлен из расплывчатых задач, у которых слишком общая формулировка, препятствующая мониторингу и контролю их выполнения. При этом получится нереалистичный план, от которого придётся отказаться при первых признаках трудностей. В результате вы останетесь без средства управления реализацией проекта.
Основные понятия и трудности планирования
Чтобы создать план проекта или оценить план, созданный другими, нужно хорошо разбираться в основных понятиях планирования. В этом разделе мы обсудим основные понятия, которые должен знать каждый участник процесса планирования. Затем я опишу наиболее серьёзные трудности работы с людьми, возникающих при создании плана. И в завершение мы рассмотрим ряд наиболее распространённых проблем, с которыми сталкиваются команды разработчиков при планировании.
Следующие понятия являются фундаментальными для создания надёжных планов.
Объём предстоящей работы, количество доступных ресурсов и время, отведённое на реализацию проекта, должны быть сбалансированы — вот старейшее и самое важное правило планирования. Если хоть один из этих параметров начинает перевешивать или, хуже того, наложены ограничения, которые нельзя сбалансировать, создать ПО вовремя будет невозможно. Даже если в начале работы проект был сбалансирован, велика вероятность, что в дальнейшем равновесие будет нарушено. В цикле разработки возникает достаточно препятствий, чтобы вывести из равновесия даже самый лучший план. По ходу работы менеджер проекта должен регулярно проверять план и всемерно поддерживать его равновесие. Способы мониторинга проекта и внесения изменений в процессе его реализации мы обсудим в главе 12.
Задачи — это основные строительные блоки плана, они являются представлением конкретной работы, которую нужно сделать. В общем верно, что легче следить за ходом выполнения небольших задач. Кратко и точно сформулированные задачи позволяют быстро обнаружить отставание от плана. Если задачу нельзя завершите за 1-2 недели, её следует разбить на две или больше меньших задач. Исполнение плана, составленного из долгосрочных задач, труднее контролировать.
При составлении списка задач обязательно нужно учитывать их взаимосвязи в рамках проекта. Например, зная, как одни задачи зависят от других, можно расположить их в нужной последовательности, причём ключевые задачи всегда должны завершаться в первую очередь. Нужно выяснить, сколько времени займёт каждая задача. Это можно сделать, оценив время, необходимое для выполнения некоторой задачи (т.е. выдвинув обоснованное предположение о сроках). Поскольку для формулирования требований, конструирования интерфейса и реализации выбранной технологии сделано уже довольно много, должно быть накоплено достаточно информации, чтобы точно и без особых затруднений оценить срок для выполнения той или иной задачи. Если точно оценить время исполнения ключевых задач невозможно, вы, вероятно, провели недостаточно экспериментов, исследований и работы с прототипом.
Оценка должна учитывать всю работу, необходимую для выполнения задачи. Например, специалисты по ПО должны оценить суммарное время конструирования низкоуровневой структуры, а также реализации, отладки и блочного тестирования программы. Специалисты по обучению пользователей должны оценить, какое время потребуется на написание, рецензирование, редактирование и правку их материалов. Хотя каждый участник команды самостоятельно оценивает срок завершения своей части работы, его оценку всегда должен проверить ведущий специалист в соответствующей области. На основе этих оценок рассчитывается время реализации проекта, поэтому следует быть уверенным в цифрах.
Со временем вы увидите, что ваши оценки становятся все точнее, особенно при работе над аналогичным продуктом с использованием те же самых технологий. Обязательно проанализируйте задачи, на которые ушло значительно больше времени, чем ожидалось. чтобы понять, почему в оценку вкралась ошибка.
Не совершайте ошибку, планируя лишь разработку самой программы: план должны отражать все аспекты проекта.
•
Часть плана, регламентирующая разработку ПО, должна отводить достаточно времени на разработку, блочное тестирование и отладку всех функций программы. Команде разработчиков следует выделить дополнительное время на анализ результатов работы тестировщиков и материалов, подготовленных группой по обучению пользователей. Не исключено, что разработчикам также понадобиться время для анализа результатов специалистов по инженерной психологии и технологов.
•
Этот раздел должен давать достаточно времени для создания планов и сценариев испытаний, а также для тестирования самой инфраструктуры. План испытаний должен выделять добавочное время на тестирование ПО после окончания каждого промежуточного этапа работы.
•
Здесь должно даваться достаточно времени на создание документации, электронной справки и учебника по работе с программой. На редактирование потребуется дополнительное время, которое также нужно учесть. И не забывайте проводить разбор технических особенностей ПК с участниками команды.
•
Отведённого здесь времени должно быть достаточно для разработки детальной конструкции пользовательского интерфейса и его оценки. Выделите также время на оценку графических материалов продукта, внутренние и внешние испытания пользовательского интерфейса, и проверку документации. Кроме того, в плане должно быть время для проверки первоначального впечатления от продукта.
•
Времени, запланированного в этом разделе, должно хватить для создания системы сборки ПО, разработки установочной процедуры, для конфигурирования и сопровождения системы управления исходным текстом.
•
План должен в полной мере учитывать возможную зависимость проекта от внешних факторов и предусматривать выделение дополнительного времени в случае необходимости. К таким факторам относятся поставки и использование ПО от сторонних разработчиков, доступность оборудования и даже расширение штата или получение поддержки от других групп.
Одна из основных идей этой книги может быть сформулирована так: параллельная реализация всех аспектов проекта повышает эффективность цикла разработки. Для её воплощения прекрасно подходит план проекта. При этом целью является реализация функций ПО путём интеграции различных задач по разработке, тестированию, обучению пользователей, инженерной психологии и работе над выпуском ПО.
Рассмотрим пример. Разработчики должны реализовать функции, соответствующие командам
