Сегодня довелось присутствовать на митинге по планированию релиза в одной очень крупной российской компании, работающей в банковской сфере.

Почти всю сознательную жизнь проработав в аутсорсе с его преобладающими fixed price проектами, то, что происходит во внутренней разработке многих компаний, порой заставляет сильно удивляться.

Например, задачи на релиз длиной в месяц оцениваются в десятках человеко-дней. Попробуйте точно оценить задачу трудоемкостью в 70 человеко-дней? Все верно, это нереально. В подтверждение этому один раз даже прозвучала цитата: 'ну ладно, я готов согласиться на 20 вместо 30' - речь тут шла о человеко-днях на одну из задач релиза :)

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

Обычно в таком случае используют один общий баклог (Product Backlog), который координируется одним владельцем продукта (Product Owner).

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

Вряд ли сейчас найдется хотя бы одна команда, работающая по Scrum и не использующая доску задач.

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

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

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

Доска баклога (журнала пожеланий):

Доска задач в итерации:

Состав столбцов на доске определяется настройками состояний пожеланий и задач (настройками workflow), которые вы можете поменять для каждого проекта (Проект - Настройки - Состояния пожеланий (задач)).

В текущей версии Devprom (2.8.4) есть одна тонкость - до этого на доске задач в итерации было "искусственное" состояние "В работе", в которое попадали задачи после начала работы над ними (например, после списания затраченного времени).

Теперь, когда есть полностью настраиваемый workflow задач, такое состояние должно определяться в самом workflow, а не быть вычисляемым системой.

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

В новых проектах, созданных на основе Scrum шаблона, состояния задач и столбцы доски задач будут стандартными - Запланирована/В работе/Выполнена. В любой момент вы так же сможете изменить их, например, добавив состояние "На ревью" или "В тестировании".

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

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

И напоследок небольшой анонс - в версии 3.0, над которой мы уже работаем, доска станет супер-модной и удобной, со всякими приятными плюшками в виде перетаскивая и быстрого редактирования атрибутов пожеланий и задач!

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

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

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

Структура программы

В качестве примера рассмотрим программу, состояющую из трех проектов:

1. Корневой проект "Программа: система хранения данных", назначением которого является агрегация пожеланий по программе, хранение общей информации по программе, контроль за ходом выполнения программы проектов.
2. Дочерний проект (или подпроект) "СХД: поддержка продукта", созданный на основе шаблона "Поддержка" и используемый для поддержки пользователей основного продукта, при помощи плагина или автоматической обработки входящих email.
3. Подпроект "СХД: разработка продукта", в котором ведется основная разработка продукта.

Объединение знаний по всей программе

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

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

Управление ожиданиями по программе

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

Таким образом, руководитель программы может оперативно реагировать на ожидания пользователей, управлять руководителями проектов и корректировать их активности. Для этого в связанных проектах необходимо настроить импорт пожеланий из подпроектов в программу проектов.

Просмотр результатов работы по программе

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

Контроль за ресурсами программы проектов

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

Пример описанной программы проектов доступен демо-версии DEVPROM: http://demo.pmcloud.ru

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

Любой процесс, связанный с разработкой ПО, делится на этапы, в каждом из которых обозначаются цели этапа, полезные результаты (deliverables), задачи по получению этих результатов, распределение зон ответственности между типовыми ролями участников процесса. Рассмотрим для примера стадии двух известных процессов, отличающихся по структуре: