Выбор организационной структуры проекта зависит от характеристик проекта и внешних ограничений, таких как существующая организационная стратегия. По этой причине, трудно заранее оговаривать, какой должна быть эта структура, поскольку в значительной степени это будет зависеть от конкретных обстоятельств. Основные вопросы вкратце освещены в разделе  Рекомендация: план разработки программного обеспечения, содержащем также структуру проекта по умолчанию, которую можно адаптировать к конкретным требованиям проекта. Структура по умолчанию также предлагает отображение ролей (Rational Unified Process) в должности организации. Форма и размер организации проекта меняются в зависимости от этапа, и план разработки программного обеспечения, который всегда можно модифицировать, будет обновлен в соответствии с этими изменениями.

На основе оценки трудозатрат для проекта, желательного расписания, выбранной организационной структуры и отображения ролей руководитель проекта определяет профайл персонала (необходимое количество сотрудников в разные периоды и их навыки) для проекта. Оценка трудозатрат для проекта, конечно, не зависит от количества сотрудников, их опыта и квалификации; в то же время, при оценке трудозатрат руководитель почти наверняка будет исходить из неявных предположений о возможностях персонала. В параграфе Модель оценивания COCOMO (см. раздел Задача: этапы и итерации проекта) возможности и опыт персонала являются основными драйверами трудозатрат. Таким образом, выбор приемлемых общих трудозатрат (путем варьирования драйверов трудозатрат COCOMO) и осуществимого расписания будет определяющим при составлении профайла персонала.

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

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

Подбор персонала на начальный этап и этап уточнения

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

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

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

Подбор персонала на этап построения

На этапе построения обеспечивается архитектурная целостность системы в условиях добавления в систему все новых и новых функций. Для этого необходимы архитектурное уточнение (создание "контрольных версий", а не "замораживание" архитектуры после этапа уточнения) и коллектив архитекторов, который следит за работой проектировщиков.

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

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

Подбор персонала для выполнения задач тестирования

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

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

• Тестирование в режиме "черного ящика". Тестирование вариантов использования извне системы на основе потока событий варианта использования (см. раздел Рабочий продукт: вариант использования).
• Тестирование в режиме "белого ящика". Тестирование фактической отправки сообщений в варианте использования на основе последовательных панелей для сценариев.
• Тест системы. Тестирование системы на отказоустойчивость для выяснения ее истинной природы.

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

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

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

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

Подбор персонала на этап внедрения

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

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