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

Рис. 11-1. Исходные данные, критически важные для процесса планирования.
Однако если основные требования не определены, а самые рискованные фрагменты программы не отработаны на прототипах или моделях интерфейса, то для разработки точного плана просто не хватит данных. Тогда сформулировать все задачи проекта и точно оценить время, необходимое для выполнения каждой из них, будет невозможно. Поэтому весь проект будет составлен из расплывчатых задач, у которых слишком общая формулировка, препятствующая мониторингу и контролю их выполнения. При этом получится нереалистичный план, от которого придётся отказаться при первых признаках трудностей. В результате вы останетесь без средства управления реализацией проекта.
Основные понятия и трудности планирования
Чтобы создать план проекта или оценить план, созданный другими, нужно хорошо разбираться в основных понятиях планирования. В этом разделе мы обсудим основные понятия, которые должен знать каждый участник процесса планирования. Затем я опишу наиболее серьёзные трудности работы с людьми, возникающих при создании плана. И в завершение мы рассмотрим ряд наиболее распространённых проблем, с которыми сталкиваются команды разработчиков при планировании.
Основные понятия
Следующие понятия являются фундаментальными для создания надёжных планов.
Равновесие
Объём предстоящей работы, количество доступных ресурсов и время, отведённое на реализацию проекта, должны быть сбалансированы — вот старейшее и самое важное правило планирования. Если хоть один из этих параметров начинает перевешивать или, хуже того, наложены ограничения, которые нельзя сбалансировать, создать ПО вовремя будет невозможно. Даже если в начале работы проект был сбалансирован, велика вероятность, что в дальнейшем равновесие будет нарушено. В цикле разработки возникает достаточно препятствий, чтобы вывести из равновесия даже самый лучший план. По ходу работы менеджер проекта должен регулярно проверять план и всемерно поддерживать его равновесие. Способы мониторинга проекта и внесения изменений в процессе его реализации мы обсудим в главе 12.
Задачи и оценка времени для их выполнения
Задачи — это основные строительные блоки плана, они являются представлением конкретной работы, которую нужно сделать. В общем верно, что легче следить за ходом выполнения небольших задач. Кратко и точно сформулированные задачи позволяют быстро обнаружить отставание от плана. Если задачу нельзя завершите за 1-2 недели, её следует разбить на две или больше меньших задач. Исполнение плана, составленного из долгосрочных задач, труднее контролировать.
При составлении списка задач обязательно нужно учитывать их взаимосвязи в рамках проекта. Например, зная, как одни задачи зависят от других, можно расположить их в нужной последовательности, причём ключевые задачи всегда должны завершаться в первую очередь. Нужно выяснить, сколько времени займёт каждая задача. Это можно сделать, оценив время, необходимое для выполнения некоторой задачи (т.е. выдвинув обоснованное предположение о сроках). Поскольку для формулирования требований, конструирования интерфейса и реализации выбранной технологии сделано уже довольно много, должно быть накоплено достаточно информации, чтобы точно и без особых затруднений оценить срок для выполнения той или иной задачи. Если точно оценить время исполнения ключевых задач невозможно, вы, вероятно, провели недостаточно экспериментов, исследований и работы с прототипом.
Оценка должна учитывать всю работу, необходимую для выполнения задачи. Например, специалисты по ПО должны оценить суммарное время конструирования низкоуровневой структуры, а также реализации, отладки и блочного тестирования программы. Специалисты по обучению пользователей должны оценить, какое время потребуется на написание, рецензирование, редактирование и правку их материалов. Хотя каждый участник команды самостоятельно оценивает срок завершения своей части работы, его оценку всегда должен проверить ведущий специалист в соответствующей области. На основе этих оценок рассчитывается время реализации проекта, поэтому следует быть уверенным в цифрах.
Со временем вы увидите, что ваши оценки становятся все точнее, особенно при работе над аналогичным продуктом с использованием те же самых технологий. Обязательно проанализируйте задачи, на которые ушло значительно больше времени, чем ожидалось. чтобы понять, почему в оценку вкралась ошибка.
Полнота плана
Не совершайте ошибку, планируя лишь разработку самой программы: план должны отражать все аспекты проекта.
• Разработка
Часть плана, регламентирующая разработку ПО, должна отводить достаточно времени на разработку, блочное тестирование и отладку всех функций программы. Команде разработчиков следует выделить дополнительное время на анализ результатов работы тестировщиков и материалов, подготовленных группой по обучению пользователей. Не исключено, что разработчикам также понадобиться время для анализа результатов специалистов по инженерной психологии и технологов.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88