+7 (499) 638-64-11
Попробовать
Постановка и автоматизация процессов разработки ПО

Эффективное управление скоупом и планом проекта

29.03.2010 12:46

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

 

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

 

  • Использование Excel вместе с инструментом планирования, например, MS Project. В таблицах содержатся границы очередного релиза и описание функциональности, выполняется фильтрация и приоретизация, а в плане проекта отслеживается состояние реализации этой функциональности. Команде приходится постоянно синхронизировать приоритеты и функциональный состав с планом проекта, который уже был оптимизирован под предыдущее понимание того, что нужно заказчику.
  • Использование только баг-трекера. Описание только состава работ (набора дефектов или issue) не позволяет вам увидеть реальный план действий команды и наложить процесс реализации дефектов на календарь вашего проекта. Работа нескольких участников над одним дефектом не позволяет эффективно списывать затраченное время. С другой стороны отсутствие четкого плана действия дезорганизует команду и не позволяет ее участникам эффективно синхронизировать свои действия. Оценки по срокам реализации очередного релиза всегда очень грубые, единственное, на что могут рассчитывать команды: исправить все текущие дефекты, а когда это случится никто точно сказать не может, просто умножают исходную оценку трудоемкости на некоторые эмпирические коэффициенты.
  • Использование баг-трекера с инструментом планирования. В трекере содержится набор фич или ошибок с описанием функциональности, приоритетами. Участники проекта передают дефекты друг другу, выполняя анализ, разработку и тестирование. В плане проекта описан план этой деятельности и отдельный человек синхронизирует состояние дефектов с задачами по каждому участнику, чтобы отслеживать сроки выполнения проекта. Более того, списание времени в таких случаях существенно усложняется, поскольку один дефект может пройти несколько этапов разработки и тестирования. Каждый отклоненный дефект необходимо заново описывать в плане.
  • Использование только инструмента планирования задач. В WBS (work breakdown structure) проекта по сути сливаются понятия границ, содержания и плана работ по проекту, что формирует монолитный план, который крайне трудоемко поддерживать, менять и обслуживать. В случае с итерационной разработкой, использование таких планов-монстров лишь отнимает время, но не добавляет прозрачности и управляемости процесса разработки. Вся необходимая информация для членов команды (обсуждения, требования, тестовые сценарии) не может быть втиснута в план проекта и часто разбросана по различным файлам и сетевым дискам.

img1

img2

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

 

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

img3

img4

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

 

Какие есть недостатки в данном плане в существующих инструментах, используемых проектными командами? В целом, видны два основных тренда, в рамках которых создаются и развиваются современные инструменты: процесс строится вокруг управления 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 отслеживает реальные показатели производительности команды и на их основе строит прогноз по срокам реализации будущего функционала.

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