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

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

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

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

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

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

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

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

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

Еще интересные статьи на эту тему:

• Постоянные улучшения и ретроспективы в Agile
• Сбор реальных метрик команды и процесса
• Управление рисками проекта
• Wiki хорошо, но всегда ли?
• Подходит ли форум для общения команды?