Проектирование и коллективная разработка программных продуктов

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

Существует две основные модели организации коллектива при разработке ПО: иерархическая модель и модель группы. Господствующей моделью разделения труда в наше время является иерархическая структура. Если в современных производственных средах один начальник отвечает за все тонкости разработки и принимает все важные решения, возникает множество проблем, ведущих к провалу проекта. Иерархическая модель грешит множеством недостатков: нехватка информации невозможность учесть все особенности проекта, отсутствие полноценной связи между всеми участниками проекта, трудность освоения новых технологий, сложность расстановки приоритетов. Кроме того, опыта одного человека чаще всего недостаточно для быстрого решения задачи и интеграции приложения в существующую инфраструктуру. В организациях, построенных на основе иерархической модели, затруднен обмен информацией в этой модели он, по определению, осуществляется через посредников. Чтобы сгладить недостатки иерархической модели, в проектной группе предусматривается распределение обязанностей руководителя между участниками коллектива. При этом за проект отвечает не один человек, а все члены группы, каждый за свою сферу деятельности. Модель группы не определяет структуру коллектива с точки зрения отдела кадров. Задача модели проектной группы определить цели проекта и распределить обязанности. Руководители каждого направления с помощью выделенных им ресурсов выполняют возложенную на них часть работы. Обязанности ролей определяются работой над проектом, а не деятельностью «штатной единицы». У коллективного подхода также есть недостатки: разрозненная связь с внешними источниками информации, несогласованное представление о разных сторонах проекта, несогласованность личных планов членов группы и отсутствие опыта, снижающее эффективность коллективной работы.

В 1994 году, стремясь достичь максимальной отдачи от IT-проектов, Microsoft выпустила в свет Microsoft Solutions Framework (MSF) — пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. В MSF определены шесть ролей, составляющих модель проектной группы. У каждой из ролей свои цели и обязанности, выполнение которых и обуславливает удачу проекта (Таблца 1).

Таблица 1. Роли в модели проектной группы

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

Чтобы справиться с крупным проектом, необходимо делить проектную группу на тематические и функциональные подгруппы. Тематические группы — небольшие подгруппы из одного или нескольких человек, роли которых различны. Каждой из таких групп выделяется некий набор функциональных возможностей приложения, за все стороны проектирования и разработки которого она и отвечает (включая составление проекта и графика реализации). В противоположность им, функциональные группы формируются в рамках одной роли. Они нужны в очень крупных проектных группах или при работе над крупномасштабными проектами, когда отдельные роли нуждаются в дополнительном подразделении. Например, в Microsoft отдел менеджмента продукта обычно состоит из групп планирования и маркетинга. Обе занимаются менеджментом продукта, но первая отвечает за определение действительно необходимых заказчику функций приложения, а вторая за информирование потенциальных клиентов о достоинствах продукта.

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

Использованная литература:

1. Microsoft. Анализ требований и создание архитектуры решений на основе Microsoft .NET