Начиная разработку DEVPROM мы отталкивались от опыта работы с различными заказчиками и применения различных инструментов управления проектом и процессом разработки ПО. Опыт был разным, но все случаи объединяли примерно одни и те же проблемы, которые испытывали наши команды. Решение одной из таких проблем мы считаем важным преимуществом DEVPROM, а именно разделение понятий scope (границ, целей и содержания проекта, релиза, либо итерации) и плана проекта, то есть набора задач, выполняемых участниками.

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

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

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

Какие есть недостатки в данном плане в существующих инструментах, используемых проектными командами? В целом, видны два основных тренда, в рамках которых создаются и развиваются современные инструменты: процесс строится вокруг управления issue (JIRA, Redmine), процесс строится вокруг управления планом работ (TFS, TeamWork, TrackStudio).

• В JIRA есть возможность создавать задачи, назначать исполнителей и списывать потраченное время, но с планом проекта и итерационной разработкой это практически не имеет ничего общего. Это лишь детализация выполнения исходного issue. Участникам по-прежнему приходится отдельно выполнять задачи и отдельно изменять состояние issue, вручную продвигая их по настроенному workflow. То есть выполнение проектных задач не связано с реализацией исходного скоупа релиза. Другой проблемой является необходимость постоянно контролировать создание необходимых подзадач и, как только, кто-то перестает следовать этому подходу, то все планирование проекта рушится.
• В TFS и Polarion все построено вокруг понятия WorkItem, который наделяет всех своих наследников (требования, тесты, истории пользователей, задачи) возможностью указать плановую трудоемкость и списать часы. То есть, по сути это обычный WBS, элементы которого типизированы и могут связываться как угодно. Таким образом, смешиваются понятия описания функциональности, произведенных артефактов и задач на выполнение. Построить на этом фундаменте прозрачный процесс, увы, нетривиальная задача, тем более, что все связи вам придется поддерживать вручную и распутывать клубки причинно-следственных связей между элементами.
• В TrackStudio или TeamWork все построено вокруг дерева задач, которое идеально описывает классическую концепцию WBS, но увы не позволяет разделить понятия функционала и плана по его реализации, что характерно для планирования вообще, но плохо подходит для разработки ПО. Вот, в частности, как разработчик TrackStudio рассматривает интеграцию issue tracking и project management: "TrackStudio позволяет интегрировать issue tracking и project management - для этого нужно создать дерево проектов в TrackStudio, после чего в каждом из этих проектов менеджер дает конкретные задания для программистов. TrackStudio позволяет на основе данных программистов считать затраты времени на любую часть проекта, устанавливать сроки и бюджеты, контролировать их выполнение."

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

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

• Как просто оценить историю или задачу
• Планирование на перспективу в Agile
• Планирование релиза и итераций в Agile
• Планирование в Agile - общее видение
• А как вы планируете релизы?