Реализованы пожелания:

• I-1222 Иерархия тестовых наборов
• I-1300 Доработать управление версиями: необходимо иметь страницу с перечнем всех версий...
• I-1350 Добавить в футер локального девпром ссылки на Документацию и FAQ, а так же на ст...
• I-1361 Архив для справочных документов. Необходимо иметь возможность помещать сами доку...
• I-1533 Нужен архив документов, архивирование должно быть доступно как из списка докумен...
• I-1556 Необходимо привязывать сборки к релизу, а не к итерации, это нужно для проектов,...
• I-1532 Пожелания внутри функции - выполненные не становятся серыми, не оказываются вниз...
• I-1546 При нажатии на + в дереве (IE, Opera) открывается отдельная страница с текстом f...
• I-1551 Нажимаю "Добавить" на странице "Вехи проекта", выбираю дату 17.1...
• I-1552 Необходимо запретить добавление пустого комментария. Сейчас это возможно в двух ...
• I-1706 При удалении пожелания открывается форма ввода нового пожелания и так в блоке Ат...
• I-1711 Локальная установка, в настройках системы указан мой email как администратора. П...

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

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

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

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

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

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

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

На презентации DEVPROM в одной компании нам задали задачку: как эффективно управлять поставкой реализации некоторого требования, которое затрагивает функционал нескольких продуктов?

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

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

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

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

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

Таким образом:

1. Гипертекстовые ссылки на требования, находящиеся на одном ресурсе, позволяют связывать требования и удобно по ним навигироваться.
2. Информация по срокам реализации связанных требований доступна на странице с текстом требования в каждом проекте, куда могут заходить любые зарегистрированные пользователи и получать доступ к информации на уровне "только для чтения".
3. Информация по оценкам сроков релизов в каждом проекте, а также механизмы управления журналами релизов позволяют согласовать нужный порядок реализации пожеланий и достичь основной цели: выхода реализации исходного пожелания в различных продуктах к единому сроку.

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

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

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

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

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

Вариантов здесь два:

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

При планировании мы оперируем задачами, которые просто создаем в нужных нам итерациях: анализ требований по фиче в итерации 2, ее разработка в итерации 3.

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

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

2. Использовать систему управления проектами DEVPROM в качестве инструмента планирования и ведения беклога продукта, который сам создает и отслеживает связи между пожеланиями и созданными задачами.

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

Если нам необходимо запланировать их все в одну итерацию, это просто:

• создаем задачи - исходное пожелание меняет свой статус на Запланировано в итерации;
• начинаем работу по задачам - пожелание меняет свой статус на В работе;
• после завершения последней задачи - пожелание меняет статус на Выполнено
• пожелание уходит в раздел Выполненные беклога продукта.

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

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

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

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

Таким образом, DEVPROM следит за связями пожелание-задачи самостоятельно, освобождая ваше время для более важных и нужных дел.

А так же позволяет:

• Разработчику при работе над своей задачей видеть перед глазами ссылку на требования, подготовленные аналитиком во время выполнения задачи анализа;
• Генерировать план проекта в MS Project с разбиением задач по пожеланиям и функциям системы (даже в Agile проектах заказчики и руководство хотят видеть проджект-планы)
• Проводить анализ времени, запланированного и фактически затраченного на реализацию той или иной функциональности.

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

Управляйте своими проектами эффективно!