в облаке
Попробовать

Что важнее: план или процесс?

08.11.2009 21:42

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

 

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

 

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

 

Используя знание о процессе вы можете сделать вывод, что каждая позиция скоупа (пожелание) должна пройти все этапы процесса разработки. Перемножив примерную продолжительность нахождения пожелания на каждом из этапов вы делаете вывод о продолжительности проекта и плановом сроке завершения. Сильно ли вы при этом ошибаетесь? Очень.

 

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

 

Мейнстримом во многих старых (ClearQuest) и даже современных инструментах управления процессом разработки (Jira, Mingle) является именно настройка процесса (workflow), по которому ваша команда должна двигаться при выполнении некоторого скоупа. Очевидно, что использовать эти инструменты для прогнозирования сроков проектов чревато самыми печальными последствиями для вашей команды. Выходом является составление плана работ, то есть анализ структуры работ команды, распределение ответственных и предварительная оценка трудоемкостей. Именно поэтому часто встречаются команды, которые работают с Jira, но для планирования используют, например, MSProject.

 

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

 

Именно этот подход используется в DEVPROM и позволяет командам правильно и эффективно оценивать сроки своих проектов. Это различие является уникальной особенностью DEVPROM по сравнению с баг-трекерами, размывая тем самым грань между управлением пожеланиями (доработками, ошибками, дефектами) и планированием деятельности команды. Нас часто спрашиваю: можно ли в DEVPROM настраивать workflow? Да, конечно можно, можно отключить ненужные фазы, можно их не отключать, но пропускать при планировании пожеланий. Но главное здесь не это, а то, что DEVPROM базируется на плане работ, а не на описании процесса или жизненного цикла пожеланий.

 

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