PMsoop: Глава №8: Функциональная декомпозиция

В ролях – Менеджер Проекта, Команда Проекта (разработчики, старшие разработчики, руководители разработки)

Артефакты – ТЗ, feature-list, task-list

Суть – Команда проекта выбирает оптимальный вариант технической реализации и определяет основные задачи разработки

В этой главе продолжается описание подготовительного (к старту) этапа проекта и рассматриваются следующие цели:

4. Обсудить возможные варианты реализации проекта. Выбрать оптимальный вариант реализации с учётом всех условий и “набросать” концепцию архитектуры

5. Выделить основные задачи по реализации функционала и определить их последовательность

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

Цель 4. Обсудить возможные варианты реализации проекта. Выбрать оптимальный вариант реализации с учётом всех условий и “набросать” концепцию архитектуры

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

- Основные функциональные элементы. Для проекта типа “нужно чтобы пользователи удобным образом могли из данных, хранящихся на их ПК, формировать контент представленный на некотором сайте” элементами могут быть приложение исполняемое на ПК пользователя + сайт + API взаимодействия между ними. Для проекта типа “video-chat” элементами могут быть сайт (PHP or Java) + “движок” передачи видео интегрированный в сайт (Flash/Flex + FMS). Обычно элементы выделяют по принадлежности к разным технологиям и разным средам исполнения.

- Язык разработки для каждого компонента (C++, PHP, Java, Flash/Flex, etc)

- Платформа разработки для каждого компонента (Windows, Linux etc.)

- Используемые готовые решения – библиотеки, сторонние приложения, фреймворки и т.п.

- Компоненты среды разработки – что должно стоять на ПК разработчика чтобы вести разработку

- Компоненты среды работы готового продукта – что должно стоять на сервере/ПК на котором будет работать готовый продукт

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

Обычно определение этих моментов происходит простым образом – разработчики, исходя из ТЗ, предлагают возможные варианты, далее на собрании Менеджер Проекта обсуждает предложенные варианты и выбирает вариант с минимальными трудозатратами и/или рисками. Таким образом, для реализации цели МП необходимо:

- озадачить разработчиков предложением возможных вариантов реализации проекта

- провести собрание с разработчиками и выбрать оптимальный вариант

- выбранный вариант следует некоторым образом зафиксировать, достаточно зарисовки общей схемы на листике с перечислением используемых элементов

Проверка достижения цели – некоторый артефакт (листик с рисунками, схема в Visio, документ) который представляет выбранную схему реализации проекта.

Цель 5. Выделить основные задачи по реализации функционала и определить их последовательность

Непосредственно после определения варианта реализации проекта можно начинать функциональную декомпозицию проекта на высоком уровне – выделить основные элементарные задачи по реализации функционала проекта и определить связи между такими задачами, определяющие последовательность их выполнения. По результату необходимо получить список технических задач, которые можно поручить отдельным разработчикам (либо группам разработчиков), записанных в порядке их желаемого выполнения; при этом подразумевается, что выполнение всех задач по списку приведет к реализации всего функционала проекта согласно ТЗ. Как это сделать?

Для начала вспомним про такой артефакт проекта как feature-list (фиче-лист). Данный артефакт обычно создаётся на этапе приблизительной оценки трудозатарат по проекту, предшествующем подготовке предложения по разработке. Фактически речь идет о списке выделенных из ПОЗП основных функций будущего приложения. Если фиче-лист есть – для начала стоит его актуализировать в соответствии с текущим ТЗ (обычно ТЗ весьма отличается от первичного описания). Если фиче-листа нет – Менеджер Проекта может легко его получить из ТЗ, возможно с помощью бизнес-аналитика.

Далее, имея актуальный фиче-лист, Менеджер Проекта на собрании с разработчиками проводит его анализ, по результату которого получается необходимый список задач. Делается это также простым образом. В “идеале”, реализация отдельной функции приложения подразумевает отдельную задачу для разработчика(ов). В реальности нужно учесть выбранный вариант реализации проекта. Для реализации некоторых функций может потребоваться выполнение нескольких технических задач, в некоторых случаях даже связанных с разными технологиями. Некоторые другие функции могут быть реализованы совместно в рамках выполнения одной технической задачи. Некоторые технические задачи для своего решения требуют предварительной реализации других задач – что и определяет последовательность разработки. Все эти моменты Менеджеру Проекта любезно покажут разработчики, если задавать им правильные вопросы

Кроме того, на последовательность выполнения технических задач непосредственно влияет утверждённый в Контракте план “вех” проекта и сдачи готовых версий. Если по какой-то причине этого плана ещё нет – у Менеджера Проекта появляется большая свобода в выборе удобного и наименее рискованного пути реализации проекта. Но чаще всего такой план уже есть, так что последовательность реализации функций из ТЗ определяется не только удобством разработки, но и этим планом.

Также последовательность выполнения технических задач может определяться необходимостью “как можно раньше реализовать и проверить самые “узкие” и рискованные технические решения”, например задачи обеспечивающие быстродействие проекта или связанные с использованем нестабильных сторонних компонент (библиотек и фреймворков в бета-версиях например).

Таким образом, необходимые действия выглядят так:

- берем актуальный фиче-лист

- вместе с разработчиками выделяем технические задачи и их взаимосвязи

- определяем “узкие места” и стараемся вынести соответствующе задачи на ранние этапы разработки

- “подгоняем” полученное под план сдачи версий проекта, утвержденный в контракте

- составляем список задач, учитывая последовательность их выполнения

- для каждой задачи в списке подписываем технологию реализации / кто из разработчиков за неё будет отвечать / какая роль за неё ответственна из орг. схемы проекта

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

Готовый список технических задач будем называть task-list (таск-лист). Впрочем, это еще не окончательный вид таск-листа, он будет дополняться в следующей главе.

Проверка достижения цели №5 – наличие таск-листа, одобренного разработчиками и Менеджером Проекта.