В разработке программного обеспечения в основном используются две финансовые модели: разработка с фиксированным бюджетом (fixed price) и почасовая оплата (time and materials). DEVPROM позволяет вам эффективно управлять проектом с любой финансовой моделью, при этом вам не потребуется приобретать дополнительный софт, подключать дополнительный инструментарий и переобучать команду. Более того, одновременно, вы можете вести проекты с различными финансовыми моделями.

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

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

Image4

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

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

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

Image6

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

Роли и управление правами доступа

Основное внимание в этой версии было уделено ролям и правам доступа. Теперь вы можете создавать свои роли или переименовывать базовые. Например, вы можете создать новую роль "Тест-менеджер", которую наделить правами тестировщика и координатора проекта.

Управление правами доступа позволяет вам эффективно разграничивать доступ к проектным данным между пользователями DEVPROM. Например, какие-то представители заказчика могут управлять пожеланиями и другими артефактами проекта, но в другом проекте могут только просматривать некторые данные.

Отдельно вы можете задавать права на просмотр отчетов. Настройка ролей и прав доступа осуществляется на закладке "Участники". Для того, чтобы проконтролировать какие итоговые права получает участник, обладающий несколькими ролями, выберите действие "Права доступа" для участника.

Выполнение пожеланий

Если вы не используете планирование и задачи в своем проекте, то все равно сможете отчитываться по затраченному времени и формировать соответствующий отчет. При выполнении пожелания доступно поле "Затрачено, ч.", в которое вы вписываете часы при выполнении пожелания.

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

Тестирование

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

17 ноября в Москве пройдет очередная конференция, на этот раз для системных и бизнес-аналитиков, на которой будут рассмотрены вопросы сбора, анализа и управления требованиями - ReqLabs. Организаторы конференции неожиданно пригласили выступить с докладом - будем рассказывать про управление требованиями в Agile и Agile-подобных проектах с помощью специально созданного для этого инструмента - системы управления требованиями в Agile проектах Devprom Requirements.

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

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

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

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

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

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

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

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