Ниже перечислены термины, используемые в системе, и их краткое описание.

• Пожелание - текстовое описание желаемого поведения разрабатываемого продукта, аналоги: user story, use case. Пожелание характеризуется приоритетом, ответственным, сроком реализации, оценкой трудоемкости и т.п. Пожелания могут быть сгруппированы по функциям.
• Скоуп - некоторый выделенный набор пожеланий, реализация которого ведет к достижению промежуточной цели проекта. Гораздо проще работать не с потоком пожеланий, а с некоторыми отдельными наборами, обсуждать их, включать в релизы и итерации.
• Функция - высокоуровневое описание некоторой функциональности разрабатываемого продукта, аналоги: feature, компонент. За функциями, то есть различными участками функциональности продукта, могут быть закреплены ответственные. Функции используются для оценки хода выполнения проекта на высоком уровне.
• Ошибка - частный случай пожелания, связанный с требованием, описанное поведение в котором не соответствует наблюдаемому поведению продукта.
• Доработка - частный случай пожелания, связанный с требованием, расширяющий поведение продукта так, как это отражено в требовании.
• Журнал пожеланий - объединяет набор пожеланий (формирует скоуп пожеланий) по определенному признаку, полноценный аналог термина product backlog. Например, журнал пожеланий продукта - это все пожелания, которые поступают в систему от клиента и других участников проекта. Журнал пожеланий релиза объединяет все пожелания, которые планируется реализовать в данном релизе.
• Релиз - описывает среднесрочную цель по реализации крупной части функциональности продукта. Релиз характеризуется номером, датами начала и окончания, а также набором пожеланий, которые необходимо реализовать в этом релизе. Как правило релизы охватывают несколько месяцев разрабоки. Релиз объединяет итерации.
• Итерация - описывает краткосрочную цель по реализации небольшой функциональности продукта. Итерация характеризуется номером, датами начала и окончания, а также набором задач, которые необходимо выполнить для завершения итерации. Как правило итерации охватывают несколько недель разработки. Итерация - это связующее звено между скоупом пожеланий и планом работ по их реализации.
• Задача - описывает конкретную цель для каждого участника проекта, характеризуется плановой и фактической трудоемкостью, приоритетом, типом работы (анализ, разработка, документирование и т.д.), состоянием (назначена, открыта, выполнена, закрыта, отклонена и т.д.). Задача всегда является частью итерации и связывает конкретное пожелание с этапами его реализации через анализ, разработку, тестирование и документирование. В итерацию может быть включена задача и не связанная с пожеланием, например, задача по регрессионному тестированию.
• Планирование - действие пользователя, при котором он включает пожелание в итерацию, то есть определяет какие задачи необходимо выполнить для того, чтобы пожелание было реализовано. При планировании указываются этапы разработки, по которым должно пройти пожелание, при необходимости назначаются ответственные по каждой задаче, задается планируемая трудоемкость по каждой задаче и добавляются необходимые комментарии, уточняющие постановку задачи.
• Веха - контрольная точка, то есть срок с описанием цели, которая должна быть достигнута к данному сроку. Вехи используются для фиксации промежуточных сроков и периодического контроля достигнутых командой результатов.
• База знаний - иерархия wiki-страниц, в которой сосредоточены знания команды, общая информация, регламенты и т.п.
• Блог - список новостей по проекту, доступный всем участникам проекта. Все сообщения блога отображаются в обратном хронологическом порядке. Для хранения статичной информации необходимо использовать базу знаний проекта.
• Тэг - дополнительный атрибут, определенный пользователем. Тэги используются для группировки пожеланий, сообщений блога, требований, разделов документации, тестовых наборов. В случае пожеланий тэги позволяют формировать журналы пожеланий по пользовательским критериям. С использованием тэгов вы можете построить произвольную систему классификации объектов системы.
• Методология проекта - набор принципов, отражающих детали вашего процесса разработки с использованием системы. Например, если вы не планируете использовать фазы анализа и документирования, то просто отключите эти опции методологии.
• Окружение - описание некоторого окружения, в котором исполняется разрабатываемый продукт, например, тип или версия ОС и т.п. Окружения используются при тестировании, заведении пожеланий и помогают команде понять в каких условиях эксплуатировался продукт.
• Требования - иерархия wiki-страниц, содержащая детальное описание поведения разрабатываемого продукта. Wiki-страницы обеспечивают возможность совместной работы над требованиями. Требования связываются с пожеланиями, тестовыми наборами и документацией, обеспечивая тем самым трассировку изменений и автоматическое уведомление о необходимости привести тестовые наборы или документацию в соответствие с требованиями.
• Тестовая документация - содержит описание ожидаемого поведения, критериев корректности и результатов работы функционала при заданных входных данных.
• Тест-план - логически связывает разделы тестовой документации в группу, например, с целью проведения приемочного или регрессионного тестирования.
• Справочный документ - иерархия wiki-страниц, представляющая некоторый тип документации, например, справку для пользователей. Wiki-страницы обеспечивают возможность совместной работы на документацией.
• Артефакт - некоторый продукт работы команды. Часть артефактов: требования, тесты, документация располагаются на соответствующих закладках. Остальные артефакты или исходные документы от заказчика можно разместить на закладке "Файлы".
• Участник проекта - связь пользователя системы с конкретным проектом, характеризуется ролью (аналитик, заказчик, разработчик и т.д.) и ежедневной загрузкой участника.
• Загрузка участника - плановая загрузка участника, выраженная в часах. Данная характеристика используется для построения статистики, оценки эффективности и выработки каждым участником.
• Burndown график - (Burndown chart) - лучший индикатор текущего состояния дел в итерации. Красная линия показывает необходимую скорость работ, зеленая - фактиическую скорость. Пунктирная зеленая линия указывает на прогнозируемую дату завершения итерации. Желтая линия показывает изменения планируемого объема работ на итерацию (добавление\удаление задач, переоценка).
• Скорость разработки - (Velocity) - суммарная планируемая трудоемкость задач, выполненных командой за каждую из итераций релиза. Средняя скорость разработки является хорошей метрикой для прогнозирования объема задач, которые можно включить в следующую итерацию или даже релиз. В DEVPROM она измеряется в количестве часов в день.

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

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

После авторизации в DEVPROM, на закладке "Мои проекты" отображается список проектов, в которых вы принимаете участие. Здесь по каждому проекту отображается важная информация о текущем статусе проекта:

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

Для создания нового проекта выберите соответствующий пункт в меню "Действия".

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

Встроенные шаблоны

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

• Проект разработки программного продукта (SDLC)
• В этом шаблоне максимально используются все возможности DEVPROM: управление пожеланиями, версиями, релизами, планирование итераций и задач, разработка требований, тестовой и справочной документации, выполнение тестирования, трассировка проектных артефактов. Структура требований и тестовой документации содержит типовые разделы. Доступны следующие шаблоны артефактов: вариант использования, тестовый случай.
• Этот шаблон подойдет командам, использующим свой собственный полноценный процесс разработки программных продуктов, со своими шаблонами артефактов и другими настройками процесса.
• Разработка по процессу OpenUP
• В этом шаблоне содержатся все типовые документы и структура документации для организации процесса разработки по OpenUP. В проекте, созданном по этому шаблону, вы найдете соответствующие названия ролей участников проекта, описание стадий процесса, соответствующие типы активностей, шаблоны для статусных встреч и ретроспектив.
• Данный шаблон подойдет тем командам, которые хотят использовать принципы и практики Agile, но дополнительно хотят иметь формализованное описание процесса разработки, в котором сосредоточены советы, описаны контрольные проверки и распределены зоны ответственности между всеми участниками проекта, а также шаблоны артефактов (статус-репорты, варианты использования, тестовые сценарии и т.п.).
• Проект поддержки программного продукта
• По сравнению с шаблоном "Проект разработки программного продукта" в данном шаблоне отключено планирование задач на участников проекта. Используйте этот шаблон для исследовательских проектов, разработки небольших приложений, поддержки программных продуктов, когда количество участников не превышает 2-3 человек, когда не требуется детальное планирование их деятельности.
• Обработка заявок
• Этот шаблон предназначен для отслеживания выполнения каких-либо заявок, например, проект по администрированию DEVPROM как раз организуется по процессу, описанному в этом шаблоне.
• И другие шаблоны, например, для проектов Scrum, MSF Agile и др.

Создание собственных шаблонов

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

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

Различные опции по настройке проекта доступны в меню "Проект -> Настройки". Настройка проекта доступна координатору проекта.

Помимо названия и языка проекта вы можете подключить или отключить следующие функции системы:

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

В качестве инструмента по работе с текстовой документацией в проекте DEVPROM предлагает два механизма:

• Wiki - редактор текстовой документации в формате Wiki-разметки.
• WYSIWYG - редактор текстовой документации в формате HTML, работающий по аналогии с типовыми текстовыми процессорами.

Если для сбора требований вы используете только пожелания (или истории пользователя), то включив опцию "Описание пожелания редактируется при помощи WYSIWYG" вы сможете использовать различные варианты форматирования текста, списки, таблицы и вставку изображений, непосредственно при составлении описания истории пользователя.

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

Использовать планирование релизов

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

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

Использовать планирование задач

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

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

Используется управление вехами проекта

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

Использовать управление версиями

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

Использовать ежедневные митинги

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

Использовать фазу <название фазы>

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

Оценки трудоемкости

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

• Без оценки - оценка трудоемкости не используется, однако, Burndown-диаграмма строится по количеству пожеланий в релизе.
• Оценка в идеальных часах - оценка трудоемкости задается целым числом по методике идеальных часов (eXtreme Programming).
• Оценка в Story Points (SP) - оценка трудоемкости в очках, путем выбора значения на шкале чисел, повторяющих последовательность Фибоначчи (каждое следующее значение равно сумме двух предыдущих).

Определяется порядок выполнения пожеланий

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

Использовать декомпозицию по функциям

Если в разрабатываемом продукте довольно много функциональных блоков, то используйте эту опцию, для классификации пожеланий по функциям разрабатываемого продукта. В данном случае используется практика FDD (Feature Driven Development), когда проводится декомпозиция функциональности системы на два уровня: функции и пожелания. Декомпозиция по функциям позволяет получить высокоуровневое представление о ходе работ по проекту.

Использовать сборки

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

Использовать итерации фиксированной длительности

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

Также эта опция влияет на единицы измерения скорости работы команды в итерации (спринте) или релизе:

• Если опция включена, то скорость измеряется в единицах измерения оценки трудоемкости, например скорость итерации составляет 25 SP (Story Points), если в итерации выполнены пожелания, с суммарной оценкой трудоемкости равной 25 SP.
• Если опция отключена, то скорость измеряется в единицах измерения оценки трудоемкости из расчета на один день. Например, скорость итерации составляет 5 SP (Story Points) в день, если за 5 дней было выполнено пожеланий с суммарной оценкой трудоемкости равной 25 SP.

Использовать оценку трудоемкости задач

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

Участники отчитываются о затраченном времени

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

Участники выбирают себе задачи самостоятельно

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

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

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

Роли в проекте

Роль определяет видимость закладок, доступ к объектам и отчетам системы через систему прав. Вы можете изменять права для базовых ролей, или создавать свои роли на основе базовых и тонко настраивать нужные права доступа.

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

Типы задач

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

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

Стадии процесса

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

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

Шаблон HTML

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

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

Окружения

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

Результат тестирования

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

Настройки состояний и переходов между ними позволяют описывать жизненные циклы основных объектов системы, например, пожеланий. Когда над некоторым пожеланием вы выполняете действие "Выполнить", вы переводите его из состояния "Запланировано" в состояние "Выполнено".

Вы можете создавать собственные состояния и определять переходы между ними для следующих сущностей системы:

• Пожелания
• Задачи
• Вопросы
• Требования
• Тестовая документация
• Пользовательская документация

Состояния

Помимо названия и описания состояния вам необходимо указать его ссылочное имя, например, resolved. Данное имя идентифицирует состояние среди остальных состояний и используется системой для выполнения запрограммированных действий. Вы можете отметить состояние опцией "Является терминальным". Идентификаторы объектов, находящихся в терминальном состоянии зачеркиваются, например, I-123

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

Переходы

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

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

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

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

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

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

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

Отображение на форме

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

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

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

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

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

В разделе настроек проекта отображается выпадающий список "Действия", в котором вы найдете следующие пункты :

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

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

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

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

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

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

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

Базовые роли

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

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

Контроль за ресурсами

В разных проектах могут быть разные роли, по сути, выполняющие схожие функции в проектах. Например, в одном проекте его управлением занимается "Руководитель проекта", в другом "Менеджер проектов", а в третьем - "Лидер команды разработки". Поскольку все эти проектные роли создаются на основе одной базовой (Координатор), то можно оценить наличие доступных ресурсов с данными навыками, а также оценить распределение времени в проектах по типовым (базовым) ролям. Данный функционал доступен в Enterprise-версии системы.

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

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

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

Вы можете использовать различные редакторы проектной документации:

• Wiki-синтаксис - простой и общепризнанный способ объединения текста и стилей, позволяющий быстро формировать текст, содержащий списки, таблицы и основные возможности по форматированию текста.
• WYSIWYG - ориентирован на пользователей, предпочитающих работать с текстовыми процессорами. Позволяет оформлять и форматировать текст при помощи панели инструментов.

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

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

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

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

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

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

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

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

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

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

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

Форматирование текста

 *жирный*
 _курсив_
 -зачеркнуто-
 +подчеркнуто+

Результат:

жирный

курсив

зачеркнуто

подчеркнуто

Выравнивание текста

 [left]Текст расположен слева[/left]
 [right]Текст расположен справа[/right]
 [center]Текст расположен по центру[/center]

Результат:

Текст расположен слева

Заголовки

 h1 Заголовок 1
 h2 Заголовок 2
 h3 Заголовок 3
 h4 Заголовок 4
 h5 Заголовок 5
 h6 Заголовок 6

Результат:

Заголовок 1

Заголовок 2

Заголовок 3

Заголовок 4

Заголовок 5

Заголовок 6

Списки

 * Первый уровень списка с точками
 ** Второй уровень списка с точками
 
 # Первый уровень пронумерованного списка
 #* Второй уровень пронумерованного списка

Результат:

• Первый уровень списка с точками
• Второй уровень списка с точками

1. Первый уровень пронумерованного списка
• Второй уровень пронумерованного списка

Таблицы

 |Заголовок столбца 1|Заголовок столбца 2|
 |Содержимое ячейки 1|Содержимое ячейки 2|
 
 [table noborder] // таблица без рамки
 |Заголовок столбца 1|Заголовок столбца 2|
 |Содержимое ячейки 1|Содержимое ячейки 2|

Результат:

// таблица без рамки

Код

 [code]$(document).ready(function(){});[/cоde]

Результат:

 $(document).ready(function(){});

Гиперссылки

 [url=http://devprom.ru]
 [url=http://devprom.ru text=DEVPROM]

Результат:

http://devprom.ru

DEVPROM

Ссылки на страницы

 [page=D-2474] // идентификатор объекта
 [page=D-2474 text=Альтернативное название ссылки на страницу]

Результат:

Язык разметки

Альтернативное название ссылки на страницу

Изображения

 [imаge=filename.png]
 [imаge=filename.png width=40%]
 [imаge=filename.png width=120]

Результат:

Блоки текста

 [note=заметка]
 [important=важное замечание]

Результат:

 Страница не найдена: D-1234

Результат:

В тексте страницы появляется содержимое другой страницы, идентификатор которой был указан в скобках (D-1234)

UML (Unified Modelling Language)

 [uml]bob->alice[/uml]

Результат:

Полный синтаксис UML-диаграмм описан в разделе: Проектирование

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

• Просмотр - позволяет просмотреть всю иерархию wiki-страниц на одной странице в браузере, то есть сформировать, передавать и изучать целостный документ.
• Рецензирование - помимо отображения целостного документа позволяет вести обсуждение каждого из разделов этого документа, что удобно при согласовании крупного блока требований.
• Экспорт - позволяет выгружать документ в формате MS Word или HTML. При выгрузке в HTML вы можете определить собственные стили для отображения документа и тем самым сформировать файл справки, содержащий все необходимые стилистические элементы, изображения и т.п.
• Все тэги страниц - позволяет получить перечень тэгов, которые прикреплены к страницам и для каждого тэга посмотреть перечень страниц, которые он объединяет.
• Последние изменения в страницах - отображает перечень измененных страниц в обратном хронологическом порядке, с указанием участника проекта, который создал или изменил страницу.
• Архив - отображает разделы документа, которые помещены в архив. Страницы, помещенные в архив не отображаются в общем дереве wiki-страниц.

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

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

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

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

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

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

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

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

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

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

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

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

При создании сообщения в блоге все участники проекта получают уведомление по почте, а также в своем RSS-ридере, если блог проекта в нем подключен.

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

Для публикации состава сборки или релиза в блоге проекта перейдите на журнал выполненных пожеланий, отфильтруйте его по нужной версии и нажмите на пиктограмму "Опубликовать перечень пожеланий в блоге проекта". При этом DEVPROM автоматически подготовит заметку к релизу (release notes) по данным пожеланиям, сохраните сообщение блога, после чего команда узнает о выходе новой версии продукта.

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

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

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

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

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

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

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

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

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

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

Почтовые уведомления

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

• Получение уведомлений обо всех изменениях в проекте.
• Получение уведомлений о тех изменениях, которые важны для участников проекта по мнению системы.
• Получение дайджеста (краткой сводки) об изменениях в проекте. Сразу после установки DEVPROM доступно несколько периодов, за которые можно отправить дайджест, например, каждые 10 минут, каждый день или раз в неделю. Вы можете самостоятельно задавать удобные для вас периоды уведомления в форме дайджеста путем создания соответствующих заданий, выполняемых по расписанию, настраиваемых в разделе "Администрирование".

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

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

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

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

Управление планом выпуска релизов продукта осуществляется на закладке "Релиз". Вы можете добавлять новые релизы, создавать итерации и сборки. Каждое пожелание характеризуется номером версии продукта, к которой оно относится и номером версии, в котором выполнено. В списке версий вы можете просматривать какие пожелания были добавлены или выполнены в той или иной версии.

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

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

Контроль за ходом проекта

Оценки сроков завершения релизов и итераций вычисляются на основе оценок трудоемкостей пожеланий и фактической скорости работы команды. Прогресс по выполнению задач релизов и итераций отображается в форме Burndown-диаграммы.

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

Бывают ситуации, когда окончательный объем работ в релизе фиксируется уже после его начала. При этом прогноз по завершению релиза (зеленая пунктирная линия на burndown) работает некорректно. Чтобы исправить эту проблему планирования вы можете сбросить burndown, при этом, начальная трудоемкость работ по релизу станет равной максимальной трудоемкости и прогноз по завершению выровняется. Данная операция доступна из меню "Операции" на закладке "Релизы".

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

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

Начальные значения

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

При использовании планирования задач и итераций начальная скорость первой итерации соответствует начальной скорости релиза.

Индикаторы прогресса

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

При использовании планирования задач и итераций прогресс по итерации также отображается в виде BurnDown-диаграммы. Но для отображения прогресса по релизу используется BurnUp-диаграмма.

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

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

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

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

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

Состав итерации, то есть перечень задач или пожеланий, реализация которых запланирована в данной итерации, отображается на закладке "Итерация".

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

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

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

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

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

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

Функциональная декомпозиция

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

Альтернативная декомпозиция

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

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

Начало

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

Добавлено

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

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

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

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

Запланировано

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

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

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

Выполнено

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

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

Настройка жизненного цикла

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

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

Журналы пожеланий

Каждое новое пожелание попадает в журнал пожеланий продукта. Управление скоупами пожеланий для различных релизов осуществляется путем включения пожелания в тот или иной релиз.

Планирование

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

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

Реализация пожелания

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

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

Приемка функциональности

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

Трассировка

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

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

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

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

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

Типы пожелания

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

Порядок выполнения

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

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

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

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

Укажите номер версии продукта к которой относится данное пожелание.

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

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

Связи с пожеланиями

Вы можете связать пожелания с другими пожеланиям, указав тип связи:

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

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

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

Если вы не используете планирование задач, то под планированием пожелания подразумевается указание ответственного (исполнителя) и релиза, в котором планируется выполнения пожелания.

При планировании пожеланий в правой части экрана отображается BurnDown-диаграмма релиза или итерации, под которой расположено два поля:

• Доступно для планирования - суммарная оценка трудоемкости пожеланий, которые сможет выполнить ваша команда при ее средней скорости. В случае использования опции методологии "Использовать итерации фиксированной длительности" данная цифра совпадает со значением средней скорости команды.
• Запланировано на - суммарная оценка трудоемкости пожеланий, включенных в итерации или в релиз.

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

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

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

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

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

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

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

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

Доска задач

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

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

Вы можете перемещать задачи между состояниями при помощи мыши (используя механизм drag and drop). Если при этом требуется заполнить обязательные поля, то система откроет форму для задания значений этих полей.

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

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

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

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

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

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

Список всех задач проекта

Позволяет просмотреть все невыполненные задачи в проекте, вне зависимости от итерации, в которую они включены. Ссылка на этот отчет также доступна из меню "Все задачи", расположенном на закладке "Задачи".

Список выполненных задач проекта

Позволяет просмотреть выполненные задачи в проекте. Ссылка на этот отчет также доступна из меню "Выполненные", расположенном на закладке "Задачи".

График выполнения задач

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

Задачи сгруппированные по приоритетам

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

Задачи сгруппированные по исполнителям и приоритетам

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

Дополнительные отчеты по задачам проекта расположены в разделе метрики.

Суммарное планируемое время по задачам в разрезе их типов

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

Фактическое время по задачам в разрезе их типов

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

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

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

Kanban - это несколько простых принципов, заимствованных из производства и позволяющих повысить эффективность работы проекта в определенных условиях:

1. Визуализируйте производство
• Разделите работу на задачи, каждую задачу напишите на карточке и поместите на стену или доску.
• Используйте названные столбцы, чтобы показать положение задачи в производстве.
2. Ограничивайте WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства.
3. Измеряйте время цикла (среднее время на выполнение одной задачи) и оптимизируйте постоянно процесс, чтобы уменьшить это время.

Для использования практики Kanban в своем проекте необходимо перейти к настройкам методологии и включить соответствующую опцию.

Доска историй

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

Ограничения

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

Измерение цикла

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

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

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

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

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

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

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

Дополнительные материалы по управлению требованиями вы сможете найти в блоге.

Система обеспечивает совместную работу участников над требованиями, ведет историю изменений, контроль за жизненным циклом и рецензирование. Вы можете выгружать требования в формате HTML, PDF и RTF (MS Word). Вы можете добавлять собственные атрибуты для разделов требований, выполнять по ним фильтрацию, сортировку и группировку разделов в списке. При помощи действия "Массовые операции" вы можете изменить атрибуты выбранных разделов требований.

Шаблоны

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

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

Тэги

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

Настройка жизненного цикла

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

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

Настройка типов требований и матрица трассируемости

Типизация требований позволяет реализовать матрицу трассируемости требований разных типов. Например, вы можете определить такие типы требований: Видение, Вариант использования, Спецификация и т.п.

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

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

Трассировка требований

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

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

Диаграмма последовательности

 User -> Application: login(credentials)
 Application -> Database: storeSession(credentials)
 Application --> User: token
 
 User -> Application: getProjects()
 Application -> Database: SQL query
 Application --> User: projects[]

Диаграмма прецедентов

 (Get the list of projects) as (Projects)
 (Authenticate) as (Login)
 
 User --> (Login)
 User --> (Projects)
 
 (Login) <|-- (Windows integrated auth)
 note right of User : This is an example.

Диаграмма классов

 Object <|-- ArrayList
 
 Object : equals()
 ArrayList : Object[] elementData
 ArrayList : size()

Диаграмма активностей

 (*) --> if "User has credentials" then
   --> [true] "Enter password in login form"
   --> "Check for user permissions" as perm
 else
   ->[false] "Ask admin to register him in the system"
 endif
 
 perm --> if "User is active" then
   -->[true] "Return token"
 else
   ->[false] "Display message about wrong name or password"
 endif

Диаграмма компонентов

 interface "Direct API" as DA
 
 DA - [First Component] 
 [First Component] ..> WebServices : use
 
 note right of [First Component]
   A note can also
   be on several lines
 end note

Диаграмма состояний

 [*] --> NotShooting
 
 state NotShooting {
   [*] --> Idle
   Idle --> Configuring : EvConfig
   Configuring --> Idle : EvConfig
 }
 
 state Configuring {
   [*] --> NewValueSelection
   NewValueSelection --> NewValuePreview : EvNewValue
   NewValuePreview --> NewValueSelection : EvNewValueRejected
   NewValuePreview --> NewValueSelection : EvNewValueSaved
   
   state NewValuePreview {
      State1 -> State2
   }
 }

Диаграмма объектов

 object Object01
 object Object02
 object Object03
 object Object04
 object Object05
 object Object06
 object Object07
 object Object08
 
 Object01 <|-- Object02
 Object03 *-- Object04
 Object05 o-- "4" Object06
 Object07 .. Object08 : some labels

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

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

График подготовки требований

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

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

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

В системе тестировщики разделяются на две роли, выполняющие соответствующие типы задач:

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

В системе автоматизируются типовые процессы контроля качества:

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

В системе могут быть созданы следующие артефакты тестирования:

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

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

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

Система обеспечивает совместную работу участников над тестовой документацией, ведет историю изменений, контроль за жизненным циклом и рецензирование. Вы можете выгружать тестовую документацию в формате HTML, PDF и RTF (MS Word). Вы можете добавлять собственные атрибуты для разделов тестовой документации, выполнять по ним фильтрацию, сортировку и группировку разделов в списке.

Тэги

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

Шаблоны

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

Настройка жизненного цикла

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

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

Рецензирование

Отметив разделы тестовой документации и выбрав пункт "Рецензирование" в меню "Действия" вы можете перейти в режим рецензирования тестовой документации. Оставляйте комментарии и изменяйте состояние разделов тестовой документации.

Представления списка

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

При просмотре раздела тестовой документации под ним отображаются следующие списки:

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

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

Результаты функционального тестирования фиксируются на странице выполнения теста. Для перехода на страницу выполнения теста необходимо выбрать действие "Начать тестирование":

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

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

Необходимо указать параметры теста:

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

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

• P (Passed) - количество пройденных,
• F (Failed) - количество проваленных,
• N (Not run) - количество еще не выполненных тестов.

При ручном указании результата выполнения тестов обновляется состояние еще не выполненных тестов на указанное пользователем.

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

Задачи по тестированию

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

Тестирование инкрементов функциональности

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

Тестирование по тест-планам

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

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

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

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

DEVPROM предоставляет несколько отчетов для оценки результатов тестирования. Следующие отчеты доступны на закладке "Тестирование".

Результаты тестирования

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

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

Представление "детально" позволяет увидеть отчет по тестированию по всем разделам тестовой документации.

Для просмотра результатов тестирования по определенной версии необходимо указать номер версии и нажать кнопку "Обновить".

Результаты тестирования по версиям

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

В секции "Обнаруженные пожелания и ошибки" отображаются пожелания, которые были добавлены в этой версии.

График подготовки тестовой документации

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

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

График продолжительности этапов разработки тестовой документации

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

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

График переоткрытых дефектов

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

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

График сходимости дефектов

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

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

График числа ошибок, обнаруженных тестировщиками

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

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

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

Подготовленные документы можно выгрузить в следующих форматах:

• RTF - для просмотра или редактирования в MS Word или OpenOffice.
• CHM - для последующей компиляции в стандартный файл справки Microsoft
• HTML - для печати или создания индивидуального внешнего вида страниц документации.

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

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

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

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

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

График подготовки справочной документации

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

Используйте график для контроля за готовностью очередного релиза продукта.

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

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

• Экспорта списка пожеланий в Excel.
• Создания записи в блоге проекта.
• Печати списка пожеланий.

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

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

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

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

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

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

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

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

Текущие задачи проекта

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

Работы выполненные участниками

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

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

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

Отчет по затраченному времени

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

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

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

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

DEVPROM оценивает реальный срок выполнения пожеланий, завершения релиза на основе таких показателей как: скорость команды, доля ошибок в общем объеме работ, погрешность оценки:

• Скорость - объем работ, выраженный в оценках трудоемкости и выполняемый командой за день или за итерацию, если используются итерации фиксированной длительности.

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

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

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

Метрики по участникам проекта

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

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

• Графики реализации пожелания и других артефактов проекта - позволяют отобразить распределение пожеланий и других артефактов проекта по состояниям и календарным дням проекта. На графиках видны соотношения количества объектов, находящихся в различных состояниях, что позволяет оценить текущую ситуацию в проекте и сходимость работ по реализации пожеланий, разработке требований, тестовой документации т.д.
• Распределение ошибок по приоритетам - отображает изменение распределения ошибок по приоритетам во времени. Используя данный график вы можете контролировать сфокусированность команды над наиболее важными задачами в проекте.
• Распределение пожеланий по исполнителям и приоритетам - позволяет контролировать загруженность участников проекта пожеланиями различных приоритетов, перераспределять их между участниками.
• График переоткрытых дефектов - отображает историю изменений состояний пожеланий в проекте. Чем больше пожеланий было переоткрыто на некоторую дату, тем больше будет значение линии соответствующего цвета. Используйте данный график для контроля за количеством действий, значимых для текущей стадии проекта.
• График сходимости дефектов - отображает распределение дефектов по состояниям во времени. Под сходимостью дефектов подразумевается неуклонное снижение количества невыполненных дефектов и неуклонный рост количества выполненных дефектов.
• График числа ошибок, обнаруженных тестировщиками - отображает распределение обнаруженных дефектов по авторам и приоритетам. Используйте этот график для анализа эффективности тестировщиков.

Типы графиков

Система позволяет строить несколько типов графиков:

• Круговые диаграммы - для отображения распределения значения некоторого параметра по шкале 100%, например, распределение пожеланий по состояниям.

• Столбиковые диаграммы - для отображения распределения некоторого количества по двум параметрам, например, отчет о количестве дефектов, обнаруженных тестировщиками, с распределением по приоритетам.

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

Собственные графики

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

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

• Группировка - данная секция позволяет задать поле, по которому будут группироваться значения на графике, например, если вы выберете состояние объекта, то будет построено распределение относительно состояний заданного типа объекта.
• По дате - это специальный случай группировки, который позволяет построить линейчатую диаграмму, на которой заданное распределение будет отображается в развороте по времени. При этом группирующее поле задается в секции "Агрегация по".
• Агрегация по - эта секция позволяет указать поле, по которому будет осуществляться агрегация сгруппированных данных.
• Тип агрегации - позволяет указать способ агрегации данных: подсчет количества, среднего значения, максимума или минимума и т.п.
• Без агрегации - это специальный случай, который позволяет строить столбиковые диаграммы по двум измерениям, как, например, для отчета о дефектах, обнаруженных тестировщиками, с указанием распределения по приоритетам.

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

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

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

Интеграция с системами контроля версий исходного кода включает:

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

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

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

Поддерживаются следующие способы подключения к репозиториям:

• Subversion - удаленное подключение к репозиторию по протоколу WebDAV (http или https), что является стандартным способом работы с репозиториями.
• Git - подключение к локально расположенному репозиторию, или к удаленному репозиторию по протоколу WebDAV (http или https).

Особенности по заполнению полей при подключении к различным системам контроля версий описаны сразу под этими полями, на форме создания подключения.

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

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

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

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

Пункт меню "Отладка" предназначен для просмотра отладочной информации, создаваемой при подключении, с целью анализа возникающих проблем.

Детали по организации и настройке репозиториев исходного кода описаны в документации по администрированию.

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

Вот пример волшебных слов, которые нужно включить в комментарий к коммиту:

 I-123 #resolve #time 5h #comment это результат выполнения пожелания
 T-321 #resolve #time 5h

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

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

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

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