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

Обычно в таком случае используют один общий баклог (Product Backlog), который координируется одним владельцем продукта (Product Owner).

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

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

Чаще всего наблюдаются такие сценарии решения этих вопросов:

• На прошлой работе мы использовали инструмент X, зачем нужно что-то еще искать, подбирать или настраивать, если просто можно пойти тем же путем? Без внятного понимания процесса работы над проектом, без обучения команды работе с инструментом X, такой подход приводит к использованию 5% возможностей инструмента, вовлечению в процесс разработки еще 10-ти дополнительных инструментов и, как следствие, низкой эффективности автоматизации работы в проекте, низкого уровня прозрачности и управляемости проектом.
• Я считаю, что методология Y является решением всем проблем, а еще в манифесте сказано: люди важнее инструментов. Методология - это слабо формализованный процесс разработки, а значит и автоматизировать работу по этому процессу практически невозможно, то есть вы не найдете инструмента, который полностью покроет потребности вашей команды в управлении проектом. Через некоторое время, работа в проекте встанет из-за отсутствия сил и времени на переработку всей информации, которая создается в процессе работы над проектом. Работа в проекте будет носить бессистемных характер, постоянно будут происходить сбои, которые потребуют ручного управления (микроменеджмента). Мотивация участников проекта постоянно будет страдать от непонимания того, что должно происходить и кто-что должен делать.
• В нашей компании все процедуры уже прописаны, нечего тут вводить смуту, следуйте прописанным регламентам создания требований, заведения багов и написания тестовой документации, используйте уже готовые шаблоны, которые написали гениальные сотрудники еще 5 лет назад. Любые отклонения от этих процедур должны проходить согласование с генеральным директором.
• Мы наберем самых лучших специалистов и "звезд", заставим работать вместе и в результате сразу получится самоорганизованная проектная команда, которая выстроит наиболее эффективный процесс разработки программных продуктов.

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

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

Любая методология или унифицированный процесс (или framework) выстраиваются относительно некоторых условий выполнения проектов, навыков и уровня квалификации участников проектов, особенностей взаимодействия с заказчиком, пользователями или рынком. В лучшем случае методология требует выполнения определенных магических ритуалов, а в худшем - просто предлагает набор методик и практик, которые при "правильном" применении решают все основные проблемы проекта. Если эти тезисы вызывают у вас сомнения, то самое время перечитать описание семейства методологий Crystal от Alistair Cockburn

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

Любой инструмент предназначен для автоматизации вполне конкретных задач: в лучшем случае инструмент предлагает автоматизацию вполне конкретного процесса разработки ПО (например, семейство продуктов IBM Rational для автоматизации работы по RUP), в худшем - реализует простую вводилку или трекинг списка дефектов.

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

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

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

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

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

Измерение прогресса по выполненным пожеланиям

Одним из преимуществ DEVPROM является возможность вести несколько проектов при помощи одной инсталляции приложения, организуя тем самым возможность управления портфелем проектов, при этом аккуратно разграничивая права доступа к проектам между различными группами пользователей.

При обсуждении проблем в управлении проектами при личном общении с пользователями или на демонстрациях, которые мы проводим, часто пробегает тема экспертных оценок по трудоемкости реализации функций или подготовки требований. Если быть честными, то никто систематически не собирает метрики своих команд, чтобы использовать их потом в экспертной оценке. Чаще это происходит на примере недавних реализованных требований, которые могут не иметь общего с тем, что нужно реализовать. Разработчик вам говорит: мне нужно 20 часов. Но почему не 10 и не 30? Тем более, это важно, когда исходная задача не достаточно хорошо детализирована.

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

Алгоритм очень простой, и главное, не требует от вас каких либо дополнительных действий. Команда оценивает пожелания в некоторых субъективных критериях, например, в попугаях. Реализует эти пожелания в соответствии с требуемыми параметрами качества, то есть проводит все необходимое тестирование и на выходе получает готовое и качественное решение. DEVPROM при этом вычисляет скорость команды и каждого участника. Теперь, оценив трудоемкость нового пожелания вы автоматически получаете хорошую оценку продолжительности его реализации.

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