Руководство пользователя
Термины
Ниже перечислены термины, используемые в системе, и их краткое описание.
- Пожелание - текстовое описание желаемого поведения разрабатываемого продукта, аналоги: user story, use case. Пожелание характеризуется приоритетом, ответственным, сроком реализации, оценкой трудоемкости и т.п. Пожелания могут быть сгруппированы по функциям.
- Скоуп - некоторый выделенный набор пожеланий, реализация которого ведет к достижению промежуточной цели проекта. Гораздо проще работать не с потоком пожеланий, а с некоторыми отдельными наборами, обсуждать их, включать в релизы и итерации.
- Функция - высокоуровневое описание некоторой функциональности разрабатываемого продукта, аналоги: feature, компонент. За функциями, то есть различными участками функциональности продукта, могут быть закреплены ответственные. Функции используются для оценки хода выполнения проекта на высоком уровне.
- Ошибка - частный случай пожелания, связанный с требованием, описанное поведение в котором не соответствует наблюдаемому поведению продукта.
- Доработка - частный случай пожелания, связанный с требованием, расширяющий поведение продукта так, как это отражено в требовании.
- Журнал пожеланий - объединяет набор пожеланий (формирует скоуп пожеланий) по определенному признаку, полноценный аналог термина product backlog. Например, журнал пожеланий продукта - это все пожелания, которые поступают в систему от клиента и других участников проекта. Журнал пожеланий релиза объединяет все пожелания, которые планируется реализовать в данном релизе.
- Релиз - описывает среднесрочную цель по реализации крупной части функциональности продукта. Релиз характеризуется номером, датами начала и окончания, а также набором пожеланий, которые необходимо реализовать в этом релизе. Как правило релизы охватывают несколько месяцев разрабоки. Релиз объединяет итерации.
- Итерация - описывает краткосрочную цель по реализации небольшой функциональности продукта. Итерация характеризуется номером, датами начала и окончания, а также набором задач, которые необходимо выполнить для завершения итерации. Как правило итерации охватывают несколько недель разработки. Итерация - это связующее звено между скоупом пожеланий и планом работ по их реализации.
- Задача - описывает конкретную цель для каждого участника проекта, характеризуется плановой и фактической трудоемкостью, приоритетом, типом работы (анализ, разработка, документирование и т.д.), состоянием (назначена, открыта, выполнена, закрыта, отклонена и т.д.). Задача всегда является частью итерации и связывает конкретное пожелание с этапами его реализации через анализ, разработку, тестирование и документирование. В итерацию может быть включена задача и не связанная с пожеланием, например, задача по регрессионному тестированию.
- Планирование - действие пользователя, при котором он включает пожелание в итерацию, то есть определяет какие задачи необходимо выполнить для того, чтобы пожелание было реализовано. При планировании указываются этапы разработки, по которым должно пройти пожелание, при необходимости назначаются ответственные по каждой задаче, задается планируемая трудоемкость по каждой задаче и добавляются необходимые комментарии, уточняющие постановку задачи.
- Веха - контрольная точка, то есть срок с описанием цели, которая должна быть достигнута к данному сроку. Вехи используются для фиксации промежуточных сроков и периодического контроля достигнутых командой результатов.
- База знаний - иерархия wiki-страниц, в которой сосредоточены знания команды, общая информация, регламенты и т.п.
- Блог - список новостей по проекту, доступный всем участникам проекта. Все сообщения блога отображаются в обратном хронологическом порядке. Для хранения статичной информации необходимо использовать базу знаний проекта.
- Тэг - дополнительный атрибут, определенный пользователем. Тэги используются для группировки пожеланий, сообщений блога, требований, разделов документации, тестовых наборов. В случае пожеланий тэги позволяют формировать журналы пожеланий по пользовательским критериям. С использованием тэгов вы можете построить произвольную систему классификации объектов системы.
- Методология проекта - набор принципов, отражающих детали вашего процесса разработки с использованием системы. Например, если вы не планируете использовать фазы анализа и документирования, то просто отключите эти опции методологии.
- Окружение - описание некоторого окружения, в котором исполняется разрабатываемый продукт, например, тип или версия ОС и т.п. Окружения используются при тестировании, заведении пожеланий и помогают команде понять в каких условиях эксплуатировался продукт.
- Требования - иерархия wiki-страниц, содержащая детальное описание поведения разрабатываемого продукта. Wiki-страницы обеспечивают возможность совместной работы над требованиями. Требования связываются с пожеланиями, тестовыми наборами и документацией, обеспечивая тем самым трассировку изменений и автоматическое уведомление о необходимости привести тестовые наборы или документацию в соответствие с требованиями.
- Тестовый набор - содержит описание некоторого функционала продукта, условия проведения тестирования и объединяет тестовые случаи, определяющие варианты проверки данного функционала.
- Тестовый случай - содержит описание ожидаемого поведения, критериев корректности и результатов работы функционала при заданных входных данных. Тестовые случаи описывают различные варианты использования некоторого функционала.
- Тест - объединяет результаты тестирования по некоторому тестовому набору на заданной сборке (или релизе) продукта. При выполнении теста тестировщик, используя текстовое описание тестовых случаев, отмечает результат проверки каждого варианта использования функционала, описанного одним тестовым случаем.
- Тест план - объединяет тестовые наборы в группу, определяет условия тестирования и позволяет автоматически создавать задачи на тестирование по каждому тестовому набору, включенному в план, то есть планировать в итерации проверку продукта по данному тест плану. Частным случаем тест плана является регрессионное тестирование по различным участкам функциональности продукта.
- Справочный документ - иерархия wiki-страниц, представляющая некоторый тип документации, например, справку для пользователей. Wiki-страницы обеспечивают возможность совместной работы на документацией.
- Артефакт - некоторый продукт работы команды. Часть артефактов: требования, тесты, документация располагаются на соответствующих закладках. Остальные артефакты или исходные документы от заказчика можно разместить на закладе "Файлы".
- Участник проекта - связь пользователя системы с конкретным проектом, характеризуется ролью (аналитик, заказчик, разработчик и т.д.) и ежедневной загрузкой участника.
- Загрузка участника - плановая загрузка участника, выраженная в часах. Данная характеристика используется для построения статистики, оценки эффективности и выработки каждым участником.
- Burndown график - (Burndown chart) - лучший индикатор текущего состояния дел в итерации. Красная линия показывает необходимую скорость работ, зеленая - фактиическую скорость. Пунктирная зеленая линия указывает на прогнозируемую дату завершения итерации. Желтая линия показывает изменения планируемого объема работ на итерацию (добавление\удаление задач, переоценка).
- Скорость разработки - (Velocity) - суммарная планируемая трудоемкость задач, выполненных командой за каждую из итераций релиза. Средняя скорость разработки является хорошей метрикой для прогнозирования объема задач, которые можно включить в следующую итерацию или даже релиз. В DEVPROM она измеряется в количестве часов в день.
Функциональные особенности
Функциональность DEVPROM делится на две редакции: team и enterprise (корпоративная)
- team edition - это бесплатная редакция DEVPROM, без каких-либо ограничений, содержащая всю необходимую функциональность для ведения проектов по разработке ПО в небольших командах или компаниях.
- enterprise edition - это расширение DEVPROM, которое содержит дополнительные возможности и отчеты, активно используемые компаниями разработчиками ПО или командами, процессы разработки в которых аналогичны процессам в средних и крупных компаниях.
Проекты
DEVPROM является очень гибким инструментом и позволяет адаптироваться практически к любому процессу разработки. Более того, в процессе разработки продукта он может быть как инструментом для полноценного планирования всех стадий разработки, так и инструментом для сопровождения уже выпущенного продукта.
Деятельность команд сосредоточена внутри проектов, цель которых: объединить в себе требования к функциональности, управление процессом разработки и создание всех необходимых артефактов, в котором задействованы участники проекта.
После авторизации в DEVPROM, на закладке "Мои проекты", вам необходимо создать проект, после чего, при необходимости, выполнить настройку проекта DEVPROM под нужды вашего процесса разработки.
Деятельность команд сосредоточена внутри проектов, цель которых: объединить в себе требования к функциональности, управление процессом разработки и создание всех необходимых артефактов, в котором задействованы участники проекта.
После авторизации в DEVPROM, на закладке "Мои проекты", вам необходимо создать проект, после чего, при необходимости, выполнить настройку проекта DEVPROM под нужды вашего процесса разработки.
Настройки
Различные опции по настройке проекта доступны в меню "Проект -> Настройки". Настройка проекта доступна координатору проекта.
Общие настройки
Помимо названия и языка проекта вы можете подключить или отключить следующие опции:
- отображение репозитория исходного кода, что также позволит связывать пожелания и требования с изменениями в исходном коде проекта.
- обеспечить публикацию исполняемых файлов, документов и других вспомогательных артефактов в системе DEVPROM, предоставив к ним доступ всех участников проекта.
- планирование встреч участников проекта
- возможность проведения опросов мнения участников проекта, заказчика или пользователей продукта.
- при необходимости вы можете отключить использование базы знаний и блога проекта, например, это может быть уместно в проектах, предназначенных для обработки каких-то простых заявок.
Методология
Опции методологии управляют особенностями работы DEVPROM и должны соответствовать особенностям вашего процесса разработки. Ниже приводится развернутое описание опций методологии, которыми вы можете управлять.
В некоторых проектах возможно релизы будут не нужны, например, в случае вялотекущего сопровождения какого-то продукта. В этом случае просто отключите релизы и используйте остальной функционал DEVPROM.
Если вам не нужны планы работ и управление задачами проекта, то отключите данную опцию. При этом участники по-прежнему смогут отчитываться о затраченном времени. Это больше подходит для команд, которые работают по модели time and materials, а функциональность DEVPROM при этом становится похожей на функциональность классического баг-трекера.
Если вы не используете планирование, то данная опция позволит участникам проекта брать пожелания себе для выполнения, тем самым информируя участников проекта о том, что данное пожелание находится в работе.
Вы можете использовать эту опцию как при наличии планирования, так и без него.
Использовать планирование релизов
Релизы предназначены для объединения функциональности в виде журнала пожеланий релиза, которые команда планирует реализовать к заданному планируемому сроку. DEVPROM отслеживает скорость работы команды и прогнозирует фактические сроки завершения релиза, позволяя тем самым команде эффективно адаптироваться к текущим условиям разработки и управлять ожиданиями заказчика.В некоторых проектах возможно релизы будут не нужны, например, в случае вялотекущего сопровождения какого-то продукта. В этом случае просто отключите релизы и используйте остальной функционал DEVPROM.
Использовать планирование задач
Если вам требуется составлять план работ, детализировать реализацию пожелания по задачам и назначать задачи на участников проекта, то включите данную опцию. Эта функциональность подходит для команд, работающих по fixed price модели, то есть выполняющих заказную разработку или разработку коробочных продуктов, где важны сроки и точное понимание плана работ команды.Если вам не нужны планы работ и управление задачами проекта, то отключите данную опцию. При этом участники по-прежнему смогут отчитываться о затраченном времени. Это больше подходит для команд, которые работают по модели time and materials, а функциональность DEVPROM при этом становится похожей на функциональность классического баг-трекера.
Используется управление вехами проекта
Включите эту опцию, если вам необходимо фиксировать промежуточные сроки процесса разработки и оценивать прогресс выполнения проекта по этим контрольным точкам (вехам). Вехи позволяют указать дату и цель, которые будут доступны всем участникам проекта на закладке "Проект". Указание причины отклонения от намеченных вех проекта позволяет вам анализировать проблемы в команде.Использовать митинги Scrum
Вы можете использовать элементы практики Scrum для организации вашего процесса разработки. Используя данную опцию DEVPROM будет отображать на закладке "Проект" информацию по последним митингам. Каждый участник сможет отчитаться о том, что сделал вчера, что планирует делать сегодня и какие проблемы испытывает в настоящий момент. Это очень удобный инструмент для синхронизации работы команды.Использовать фазу <название фазы>
При планировании реализации пожелания предлагается создавать задачу по данной фазе, а также становится доступной закладка для управления артефактами данной фазы.Используется предварительная оценка трудоемкости пожеланий
Включите эту опцию для использования возможности DEVPROM прогнозировать продолжительность и срок реализации некоторого набора пожеланий. DEVPROM собирает необходимые метрики для вычисления продолжительности реализации пожелания. Таким образом, участники проекта просто оценивают трудоемкость пожеланий, а DEVPROM, на основании предыдущего опыта команды, вычисляет фактическую продолжительность выполнения этих пожеланий.Требуется утверждение пожеланий
Включите эту опцию, если вам необходимо, чтобы все, вновь добавленные пожелания, попадали на предварительную обработку, то есть не включались в текущий релиз по умолчанию.Закреплять ответственного за пожеланием
Используйте эту опцию, если вам необходимо за каждым пожеланием закреплять ответственного. Это позволит повысить контроль за выполнением или предварительным анализом пожелания.Если вы не используете планирование, то данная опция позволит участникам проекта брать пожелания себе для выполнения, тем самым информируя участников проекта о том, что данное пожелание находится в работе.
Использовать декомпозицию по функциям
Если в разрабатываемом продукте довольно много функциональных блоков, то используйте эту опцию, для классификации пожеланий по функциям разрабатываемого продукта. В данном случае используется практика FDD (Feature Driven Development), когда проводится декомпозиция функциональности системы на два уровня: функции и пожелания. Декомпозиция по функциям позволяет получить высокоуровневое представление о ходе работ по проекту.Закреплять ответственных за высокоуровневыми функциями
Данная опция позволяет распределить зоны ответственности по каждой функции разрабатываемого продукта, таким образом, каждый участник проекта сможет узнать кто отвечает за анализ некоторой функции, а кто за разработку или тестирование. При планировании пожелания некоторой функции DEVPROM автоматически подставит в качестве исполнителей ответственных по данной функции.Использовать сборки
Если вам необходимо выпускать промежуточные версии продукта для передачи тестировщикам или для предварительного ознакомления заказчиком, то включите эту опцию. У вас появится возможность создавать сборки, то есть дополнительные версии продукта и при выполнении пожеланий указывать в какой сборке его реализация доступна.Использовать итерации фиксированной длительности
Включите эту опцию для того, чтобы DEVPROM при создании итерации автоматически проставлял дату ее завершения. Итерации равной длительности позволяют задать определенный ритм в работе команды, оценивать скорость работы команды и эффективно планировать сроки проекта.Разрешать отклонения от методологии
Включите эту опцию, если ваша команда достаточно зрелая, чтобы оперативно принимать решение о том, требуется ли планирование задач по всем фазам реализации пожелания. Таким образом, при планировании пожелания вы сможете пропустить ненужные фазы.Участники отчитываются о затраченном времени
Выбирайте эту опцию, если вам необходимо, чтобы участники отмечали затраченное время по задачам или пожеланиям. При этом вы сможете строить отчеты о затраченном участниками времени за каждый день участия в проекте. Помимо отчетности, вы также получите более точную оценку скорости работы команды, базирующуюся на фактически затраченном времени, вместо планируемых единиц измерения трудоемкости (например, сложности историй пользователей).Вы можете использовать эту опцию как при наличии планирования, так и без него.
Участники выбирают себе задачи самостоятельно
Используется практика Agile, при которой в момент планирования задачи не назначаются на участников, а оценивается только их трудоемкость. Каждый участник забирает себе задачи из общего пула задач самостоятельно в соответствии со своим опытом, навыками и доступным временем.Отслеживать сроки выполнения задач и реализации пожеланий
Если данная опция включена, то на закладке "Проект" отображаются пожелания и задачи, находящиеся на критическом пути. Это позволяет участникам проекта эффективнее следить за сроками, на которые запланирована реализация пожелания или задач.Определять порядок следования задач
Включите эту опцию, если вам необходима возможность указывать зависимости между задачами. При совместном использовании с опцией "Разрешать отклонения от методологии" можно запретить выполнение задач, чьи предшественники еще не выполнены.Нумерация версий
DEVPROM помогает в организации процедуры нумерации версий создаваемого продукта, связанных с этапами разработки программного обеспечения. Вы можете самостоятельно указать, какие этапы разработки (релизы, итерации или сборки) будут составлять номер версии вашего продукта.
Большая часть создаваемых артефактов характеризуется номером версии для того, чтобы можно было их связать с моментом времени появления этой версии, а также функционалом, заключенном в ней.
Большая часть создаваемых артефактов характеризуется номером версии для того, чтобы можно было их связать с моментом времени появления этой версии, а также функционалом, заключенном в ней.
Проектные роли
При создании нового проекта в системе DEVPROM вам доступны базовые роли участия в проекте, такие как заказчик, аналитик, разработчик, тестировщик и т.д.
Роль определяет видимость закладок, доступ к объектам и отчетам системы через систему прав. Вы можете изменять права для базовых ролей, или создавать свои роли на основе базовых и тонко настраивать нужные права доступа.
Управление ролями также доступно из меню "Роли" на закладке "Участники". При настройке прав доступа вам необходимо указать требуемый доступ из выпадающего списка (пункт "Права доступа"), либо оставить доступ по умолчанию. Изменения вступают в силу сразу после выбора нужного уровня доступа.
Справа отображается история изменений в правах доступа. Используйте эту информацию для контроля управления правами доступа. Управлять ролями и правами доступа может только координатор проекта.
Роль определяет видимость закладок, доступ к объектам и отчетам системы через систему прав. Вы можете изменять права для базовых ролей, или создавать свои роли на основе базовых и тонко настраивать нужные права доступа.
Управление ролями также доступно из меню "Роли" на закладке "Участники". При настройке прав доступа вам необходимо указать требуемый доступ из выпадающего списка (пункт "Права доступа"), либо оставить доступ по умолчанию. Изменения вступают в силу сразу после выбора нужного уровня доступа.
Справа отображается история изменений в правах доступа. Используйте эту информацию для контроля управления правами доступа. Управлять ролями и правами доступа может только координатор проекта.
Шаблоны экспорта в HTML
Создаваемые в DEVPROM артефакты, такие как разделы базы знаний, требования, тестовую и пользовательскую документацию вы можете экспортировать в различные форматы, в том числе в HTML.
Для того, чтобы задать собственное оформление результата экспорта в HTML, предназначены шаблоны, которые позволяют задать содержимое колонтитулов, а также определить стили (CSS), что позволяет вам получать документацию с нужным вам оформлением.
Для того, чтобы задать собственное оформление результата экспорта в HTML, предназначены шаблоны, которые позволяют задать содержимое колонтитулов, а также определить стили (CSS), что позволяет вам получать документацию с нужным вам оформлением.
Участники
После создания проекта вы являетесь единственным его участником. Вам необходимо добавить остальных участников проекта, указав их роли и проставив плановую ежедневную загрузку. Управление участниками проекта осуществляется на закладке "Участники".
Участник может обладать несколькими ролями, например, быть одновременно координатором и разработчиком. Итоговые права доступа доступны из выпадающего списка, расположенного в столбце "Операции".
Участник может обладать несколькими ролями, например, быть одновременно координатором и разработчиком. Итоговые права доступа доступны из выпадающего списка, расположенного в столбце "Операции".
Коммуникация
Одним из важнейших элементов управления проектом является эффективная коммуникация между участниками, которой в DEVPROM уделено особое внимание.
Вы можете вести обсуждение практически по любому аспекту вашего проекта, будь то требование, пожелание или веха. Это позволяет организовывать тематические обсуждения, например, привязанные к определенному разделу требований, что существенно отличается от неструктурированного обсуждения в форумах.
Все последние обсуждения отображаются на закладке "Проект". Полный перечень обсуждений доступен в меню "Обсуждения", где отображаются все обсуждения в проекте в обратном хронологическом порядке, сгруппированные по датам. Вы можете отфильтровать только те обсуждения, в которых участвовали, либо указать объект, по которому ведутся обсуждения. На закладках "Пожелания", "Требования", "Документация", "Тестирование" также есть меню "Обсуждения", при переходе по которому вы получаете уже отфильтрованный список обсуждений по данной тематике.
Если вы участвуете в обсуждении, то DEVPROM будет автоматически отправлять вам почтовое уведомление при появлении нового ответа в вашей ветке обсуждения.
Вы можете вести обсуждение практически по любому аспекту вашего проекта, будь то требование, пожелание или веха. Это позволяет организовывать тематические обсуждения, например, привязанные к определенному разделу требований, что существенно отличается от неструктурированного обсуждения в форумах.
Все последние обсуждения отображаются на закладке "Проект". Полный перечень обсуждений доступен в меню "Обсуждения", где отображаются все обсуждения в проекте в обратном хронологическом порядке, сгруппированные по датам. Вы можете отфильтровать только те обсуждения, в которых участвовали, либо указать объект, по которому ведутся обсуждения. На закладках "Пожелания", "Требования", "Документация", "Тестирование" также есть меню "Обсуждения", при переходе по которому вы получаете уже отфильтрованный список обсуждений по данной тематике.
Если вы участвуете в обсуждении, то DEVPROM будет автоматически отправлять вам почтовое уведомление при появлении нового ответа в вашей ветке обсуждения.
Вопросы
Вопросы позволяют вести обсуждения, которые сложно отнести к какому-то объекту системы. Обычно это общие вопросы по тому, что сделано, как должно работать, относящиеся ко всем участникам команды. При создании нового вопроса всем участникам проекта отоправляется почтовое уведомление.
Вы можете задать вопрос на закладке "Проект", путем перехода по ссылке "Задать вопрос", либо в списке вопросов, расположенном в меню "Вопросы".
В списке вопросов отображается содержание самого вопроса и последний комментарий участников. Используя фильтр "Мои вопросы" вы можете отобрать только те вопросы, которые задавали вы. Удаление вопросов доступно только автору или координатору проекта.
Вы можете задать вопрос на закладке "Проект", путем перехода по ссылке "Задать вопрос", либо в списке вопросов, расположенном в меню "Вопросы".
В списке вопросов отображается содержание самого вопроса и последний комментарий участников. Используя фильтр "Мои вопросы" вы можете отобрать только те вопросы, которые задавали вы. Удаление вопросов доступно только автору или координатору проекта.
Блог проекта
Блог проекта - это сообщения для всех участников проекта, расположенные в обратном хронологическом порядке, например, освещение важных событий в проекте, сообщения о выпуске очередной сборки или версии продукта.
При создании сообщения в блоге все участники проекта получают уведомление по почте, а также в своем RSS-ридере, если блог проекта в нем подключен.
Оставляйте в блоге проекта результаты встреч с командой и заказчиком, публикуйте решения по организационным вопросам. Предыдущие сообщения блога всегда доступны участникам в меню "Блог" на закладке "Проект".
Для публикации состава сборки или релиза в блоге проекта перейдите на журнал выполненных пожеланий, отфильтруйте его по нужной версии и нажмите на пиктограмму "Опубликовать перечень пожеланий в блоге проекта". При этом DEVPROM автоматически подготовит заметку к релизу (release notes) по данным пожеланиям, сохраните сообщение блога, после чего команда узнает о выходе новой версии продукта.
Используйте тэги для объединения сообщений блога по тематикам, таким образом, участникам будет проще найти нужные сообщения, например, результаты встреч.
При создании сообщения в блоге все участники проекта получают уведомление по почте, а также в своем RSS-ридере, если блог проекта в нем подключен.
Оставляйте в блоге проекта результаты встреч с командой и заказчиком, публикуйте решения по организационным вопросам. Предыдущие сообщения блога всегда доступны участникам в меню "Блог" на закладке "Проект".
Для публикации состава сборки или релиза в блоге проекта перейдите на журнал выполненных пожеланий, отфильтруйте его по нужной версии и нажмите на пиктограмму "Опубликовать перечень пожеланий в блоге проекта". При этом DEVPROM автоматически подготовит заметку к релизу (release notes) по данным пожеланиям, сохраните сообщение блога, после чего команда узнает о выходе новой версии продукта.
Используйте тэги для объединения сообщений блога по тематикам, таким образом, участникам будет проще найти нужные сообщения, например, результаты встреч.
База знаний
Любой зрелый процесс разработки характеризуется наличием у команды знаний о том, как действовать в той или иной ситуации, набором общих правил и процедур, исключающих появление ошибок в работе команды. Для публикации этих знаний используйте базу знаний проекта.
Вы можете хранить в ней результаты исследований, результаты ретроспектив, архитектурные принципы и правила кодирования. Используйте базу знаний для хранения общей информации по проекту, контактным данным и плановым отсутствиям участников.
Все члены проекта могут участвовать в обсуждениях по каждому разделу базы знаний, тем самым дополняя и уточняя ее. Старайтесь избегать ситуации, когда важные знания по проекту остаются в почте, телефонных разговорах или в истории приложений обмена мгновенными сообщениями.
Каждый участник всегда сможет получить нужную информацию по проекту из базы знаний. При уходе участника из проекта важные знания не потеряются, а новый участник гораздо быстрее войдет в проект.
База знаний является древовидной структурой. Если вам необходимо классифицировать разделы базы знаний, то есть объединить их по какому-то признаку, не нарушив при этом исходной иерархии страниц, то используйте тэги, прикрепляемые к страницам базы знаний.
Вы можете хранить в ней результаты исследований, результаты ретроспектив, архитектурные принципы и правила кодирования. Используйте базу знаний для хранения общей информации по проекту, контактным данным и плановым отсутствиям участников.
Все члены проекта могут участвовать в обсуждениях по каждому разделу базы знаний, тем самым дополняя и уточняя ее. Старайтесь избегать ситуации, когда важные знания по проекту остаются в почте, телефонных разговорах или в истории приложений обмена мгновенными сообщениями.
Каждый участник всегда сможет получить нужную информацию по проекту из базы знаний. При уходе участника из проекта важные знания не потеряются, а новый участник гораздо быстрее войдет в проект.
База знаний является древовидной структурой. Если вам необходимо классифицировать разделы базы знаний, то есть объединить их по какому-то признаку, не нарушив при этом исходной иерархии страниц, то используйте тэги, прикрепляемые к страницам базы знаний.
Изменения
DEVPROM хранит историю изменения любого объекта системы, что позволяет не только контролировать кто и когда выполнил изменение, но также уведомлять всех участников проекта о выполненном изменении. Таким образом, ваша команда всегда узнает о новых пожеланиях, изменившемся скоупе, изменениях в требованиях и т.п.
Последние изменения в проекте отображаются на закладке "Проект", где указывается автор и время изменения, название изменившегося объекта, а также кратко приводится суть изменения.
Полный перечень изменений доступен в меню "Изменения". Вы можете отфильтровать список по участнику, который выполнил изменения, по типу изменившихся объектов, а также по виду изменения. Таким образом, у вас сохраняется полный контроль над изменениями происходящими в проекте. Вы можете всегда найти нужное изменение, например, узнать о последних созданных пожеланиях или изменениях в требованиях.
Большая часть изменений, например, об изменении состояния пожелания, дублируется путем почтового уведомления.
Последние изменения в проекте отображаются на закладке "Проект", где указывается автор и время изменения, название изменившегося объекта, а также кратко приводится суть изменения.
Полный перечень изменений доступен в меню "Изменения". Вы можете отфильтровать список по участнику, который выполнил изменения, по типу изменившихся объектов, а также по виду изменения. Таким образом, у вас сохраняется полный контроль над изменениями происходящими в проекте. Вы можете всегда найти нужное изменение, например, узнать о последних созданных пожеланиях или изменениях в требованиях.
Большая часть изменений, например, об изменении состояния пожелания, дублируется путем почтового уведомления.
Версии
DEVPROM предназначен для обслуживания современных итерационных инкрементных процессов, состоящих из нескольких итераций, в рамках которых разрабатывается функционал.
Процесс разработки или сопровождения ПО делится на релизы, в рамках которых реализуется законченный и протестированный функционал, предназначенный для передачи заказчику или пользователям. Релиз может состоять из нескольких итераций, в рамках которых реализуются пожелания релиза. Поставка промежуточных версий продукта, например, для внутреннего тестирования, может осуществляться путем выпуска сборок.
Таким образом, версия продукта неразрывно связана с процессом его разработки или сопровождения, что отражено в DEVPROM в виде связи номера версии продукта с релизом, итерацией или сборкой. Вам не нужно изобретать систему нумерации версий вашего продукта, поскольку DEVPROM самостоятельно связывает номера версий с этапами разработки продукта.
Управление версиями осуществляется на закладке "Релиз", вы можете добавлять новые релизы, создавать итерации и сборки. Каждое пожелание характеризуется номером версии продукта, к которой оно относится и номером версии, в котором выполнено. В списке версий вы можете просматривать какие пожелания были добавлены или выполнены в той или иной версии.
Для того, чтобы скрывать те версии (релизы и итерации), которые уже никому больше не понадобятся, необходимо отметить их как "устаревшие", такие версии отображаются при переходе по фильтру "Предыдущие версии".
Процесс разработки или сопровождения ПО делится на релизы, в рамках которых реализуется законченный и протестированный функционал, предназначенный для передачи заказчику или пользователям. Релиз может состоять из нескольких итераций, в рамках которых реализуются пожелания релиза. Поставка промежуточных версий продукта, например, для внутреннего тестирования, может осуществляться путем выпуска сборок.
Таким образом, версия продукта неразрывно связана с процессом его разработки или сопровождения, что отражено в DEVPROM в виде связи номера версии продукта с релизом, итерацией или сборкой. Вам не нужно изобретать систему нумерации версий вашего продукта, поскольку DEVPROM самостоятельно связывает номера версий с этапами разработки продукта.
Управление версиями осуществляется на закладке "Релиз", вы можете добавлять новые релизы, создавать итерации и сборки. Каждое пожелание характеризуется номером версии продукта, к которой оно относится и номером версии, в котором выполнено. В списке версий вы можете просматривать какие пожелания были добавлены или выполнены в той или иной версии.
Для того, чтобы скрывать те версии (релизы и итерации), которые уже никому больше не понадобятся, необходимо отметить их как "устаревшие", такие версии отображаются при переходе по фильтру "Предыдущие версии".
Релизы
При создании нового релиза вам необходимо указать его номер и добавить краткое описание целей. Релиз предназначен для формирования скоупа пожеланий, который может постоянно изменяться. При необходимости вы можете зафиксировать сроки начала и окончания релиза, чтобы система отслеживала смещения этих сроков. Срок окончания релиза вычисляется на основе оценки трудоемкости пожеланий, включенных в него.
Заранее создавайте несколько релизов, как минимум текущий и следующий. Это поможет вам эффективно управлять журналом пожеланий текущего релиза, не допускать его раздувания и разрабатывать продукт в соответствии с ожиданиями заказчика.
Перечень текущих релизов доступен на закладке "Релизы", под каждым релизом отображаются итерации или сборки данного релиза.
Заранее создавайте несколько релизов, как минимум текущий и следующий. Это поможет вам эффективно управлять журналом пожеланий текущего релиза, не допускать его раздувания и разрабатывать продукт в соответствии с ожиданиями заказчика.
Перечень текущих релизов доступен на закладке "Релизы", под каждым релизом отображаются итерации или сборки данного релиза.
Итерации
Если вы используете планирование реализации пожеланий, то реализацию скоупа релиза необходимо разбить на итерации и для каждой указать сроки начала и завершения. DEVPROM автоматически проставляет сроки итерации на основании ее продолжительности. Рекомендуем использовать итерации равной длительности, что позволит задать ритм работы вашей команды.
Основное назначение итерации - объединить набор задач, необходимых для выполнения пожеланий. Успешное выполнение итерации означает успешное выполнение всех задач, запланированных в ней. Если команда не успевает выполнение задач к окончанию итерации, то у вас появляется повод для анализа проблем.
Итерации небольшой длительности - это основной инструмент измерения процесса разработки. По окончании каждой итерации команда должна производить небольшую, но законченную часть всего функционала продукта. Использование итераций позволяет вашей команде наиболее эффективно реагировать на постоянные изменения в функциональности продукта.
Перечень итераций релиза, отображается на закладке "Релиз". По каждой итерации отображается информация о ее сроках и оставшейся продолжительности. DEVPROM вычисляет продолжительность итерации при максимальной загрузке участников, а также на основании текущей скорости команды. Сравнивая эти показатели вы можете делать вывод о проблемах в разработке.
Для каждой итерации отображается диаграмма burndown, где желтая линия характеризует текущую плановую трудоемкость, зеленая - текущую оставшуюся трудоемкость, а красная - идеальную оставшуюся трудоемкость, при которой команда успевает завершить итерацию к заданному сроку.
Состав итерации, то есть перечень задач или пожеланий, реализация которых запланирована в данной итерации, отображается на закладке "Итерация".
Основное назначение итерации - объединить набор задач, необходимых для выполнения пожеланий. Успешное выполнение итерации означает успешное выполнение всех задач, запланированных в ней. Если команда не успевает выполнение задач к окончанию итерации, то у вас появляется повод для анализа проблем.
Итерации небольшой длительности - это основной инструмент измерения процесса разработки. По окончании каждой итерации команда должна производить небольшую, но законченную часть всего функционала продукта. Использование итераций позволяет вашей команде наиболее эффективно реагировать на постоянные изменения в функциональности продукта.
Перечень итераций релиза, отображается на закладке "Релиз". По каждой итерации отображается информация о ее сроках и оставшейся продолжительности. DEVPROM вычисляет продолжительность итерации при максимальной загрузке участников, а также на основании текущей скорости команды. Сравнивая эти показатели вы можете делать вывод о проблемах в разработке.
Для каждой итерации отображается диаграмма burndown, где желтая линия характеризует текущую плановую трудоемкость, зеленая - текущую оставшуюся трудоемкость, а красная - идеальную оставшуюся трудоемкость, при которой команда успевает завершить итерацию к заданному сроку.
Состав итерации, то есть перечень задач или пожеланий, реализация которых запланирована в данной итерации, отображается на закладке "Итерация".
Сборки
Сборки предназначены для выпуска промежутночных версий программного продукта, чтобы передать ее на тестирование или показать заказчику. Сборки не характеризуются сроками и могут выпускаться хоть каждый день, демонстрируя текущую стабильность продукта. Выпуск каждой сборки желательно предварять прогоном автоматических тестов.
При использовании планирования задач сборки являются частью итерации, однако могут являться и частью релиза, если планирование ваша команда не использует.
Состав сборки, то есть перечень пожеланий, которые реализованы в этой сборке, доступен в журнале выполненных пожеланий. Вам необходимо лишь в фильтре указать версию, соответствующую данной сборке.
При использовании планирования задач сборки являются частью итерации, однако могут являться и частью релиза, если планирование ваша команда не использует.
Состав сборки, то есть перечень пожеланий, которые реализованы в этой сборке, доступен в журнале выполненных пожеланий. Вам необходимо лишь в фильтре указать версию, соответствующую данной сборке.
Пожелания
Пожелания являются основным инструментом для описания функциональности, которую необходимо разработать в рамках проекта. Аналогами пожеланий являются истории пользователя (user stories), прецеденты (use cases) и другие описания требуемой функциональности, полученные от пользователя.
Пожелания используются для предварительной постановки задач участникам проекта, для формирования скоупов релизов и других журналов пожеланий (issues backlogs), для предварительной оценки сроков реализации скоупов пожеланий.
Работа с пожеланиями построена на основе журналов, между которыми перемещаются пожелания. Участники проекта в соответствии со своими ролями работают с теми или иными журналами пожеланий, и, тем самым, управляют жизненным циклом пожеланий. Этапы жизненного цикла пожелания настраиваются при помощи соответствующих опций методологии проекта.
Вы можете формировать собственные журналы пожеланий, соответствующие, например, этапам согласования, принятым в вашей команде, при помощи тэгов.
В отличии от традиционных баг-трекеров пожелания непосредственно не участвуют в процессе разработки, то есть не передаются от аналитика к разработчику, тестировщику и т.д. Пожелания отражают текущее состояние реализации требуемой функциональности. При планировании пожелания в итерации создаются задачи на требуемые фазы разработки, которые назначаются участникам в соответствии с их ролями.
Пожелания используются для предварительной постановки задач участникам проекта, для формирования скоупов релизов и других журналов пожеланий (issues backlogs), для предварительной оценки сроков реализации скоупов пожеланий.
Работа с пожеланиями построена на основе журналов, между которыми перемещаются пожелания. Участники проекта в соответствии со своими ролями работают с теми или иными журналами пожеланий, и, тем самым, управляют жизненным циклом пожеланий. Этапы жизненного цикла пожелания настраиваются при помощи соответствующих опций методологии проекта.
Вы можете формировать собственные журналы пожеланий, соответствующие, например, этапам согласования, принятым в вашей команде, при помощи тэгов.
В отличии от традиционных баг-трекеров пожелания непосредственно не участвуют в процессе разработки, то есть не передаются от аналитика к разработчику, тестировщику и т.д. Пожелания отражают текущее состояние реализации требуемой функциональности. При планировании пожелания в итерации создаются задачи на требуемые фазы разработки, которые назначаются участникам в соответствии с их ролями.
Жизненный цикл
Жизненный цикл пожелания описывается следующей диаграммой, на которой отражены основные этапы жизненного цикла пожелания и переходы между ними.
Начало
Все добавленные пожелания содержатся "Журнале пожеланий продукта" и требуют обработки, например согласование постановки, сроков, релизов и т.п. Если в вашем проекте поток пожеланий небольшой, либо пожелания заводятся с сознанием дела, то в методологии вы можете отключить опцию "Требуется утверждение пожеланий", после этого все новые пожелания будут попадать сразу в "Журнал текущего релиза".
На обработке
На обработке находятся пожелания, с которыми необходимо поработать команде: уточнить релиз, в котором они будут реализованы, расставить приоритеты, обсудить детали и т.д.
В зависимости от методологии вашего проекта вы можете планировать реализацию пожеланий, то есть создавать задачи и назначать их на участников проекта, либо сразу выполнять пожелания. Пожелания находящиеся на обработке отображаются в начале "Журнала пожеланий релиза".
Координатор проекта планирует реализацию пожеланий, включенных в релиз или отклоненных при тестировании ранее реализованных пожеланий, то есть создает необходимые задачи анализа, разработки, тестирования, документирования и т.п.
Если участники проекта считают, что некоторое пожелание реализовывать пока нет необходимости, то они его откладывают, то есть оставляют в журнале пожеланий продукта и могут понизить приоритет.
В работе (запланировано)
В этом состоянии находятся пожелания, реализация которых запланирована в итерации. Реализация пожелания осуществляется путем выполнения задач участниками проекта. Пожелания, которые сейчас находятся в работе доступны в журнале пожеланий релиза.
После того, как все задачи по пожеланию выполняются участниками проекта, оно автоматически переходит в состояние "Выполнено". Если при выполнении задачи по тестированию тестировщик указывает, что тестирование провалено, то пожелание автоматически переходит в состояние "На обработке".
Если ваш процесс не требует создания плана работ и назначения задач на участников проекта, то вы можете отключить опцию "Использовать планирование задач" в методологии проекта. В этом случае пожелание попадает в состояние "В работе" когда участник берет пожелание себе (действие "Взять себе"), то есть назначается ответственным по данному пожеланию.
Выполнено
После выполнения всех задач по пожеланию, оно переходит в данное состояние. Также в это состояние пожелание переходит, если вызвать действие "Выполнить" над пожеланием, реализацию которого не планировали в итерации.
Выполненные пожелания доступны в одноименном журнале, просматривая который заказчик или тестировщик проверяют реализацию пожелания и закрывают пожелание, либо отклоняют его реализацию.
Для пожеланий, предполагающих периодическую реализацию, например, формирование отчетов, можно вызвать действие "Создать задачу", при котором добавляется новая задача по реализации пожелания и оно переходит в состояние "В работе".
Закрыто
Это терминальный статус пожелания, обозначающий окончание жизненного цикла пожелания. При необходимости заказчик или координатор могут переоткрыть пожелание, после чего оно попадает в состояние "На обработке".
Начало
Все добавленные пожелания содержатся "Журнале пожеланий продукта" и требуют обработки, например согласование постановки, сроков, релизов и т.п. Если в вашем проекте поток пожеланий небольшой, либо пожелания заводятся с сознанием дела, то в методологии вы можете отключить опцию "Требуется утверждение пожеланий", после этого все новые пожелания будут попадать сразу в "Журнал текущего релиза".
На обработке
На обработке находятся пожелания, с которыми необходимо поработать команде: уточнить релиз, в котором они будут реализованы, расставить приоритеты, обсудить детали и т.д.
В зависимости от методологии вашего проекта вы можете планировать реализацию пожеланий, то есть создавать задачи и назначать их на участников проекта, либо сразу выполнять пожелания. Пожелания находящиеся на обработке отображаются в начале "Журнала пожеланий релиза".
Координатор проекта планирует реализацию пожеланий, включенных в релиз или отклоненных при тестировании ранее реализованных пожеланий, то есть создает необходимые задачи анализа, разработки, тестирования, документирования и т.п.
Если участники проекта считают, что некоторое пожелание реализовывать пока нет необходимости, то они его откладывают, то есть оставляют в журнале пожеланий продукта и могут понизить приоритет.
В работе (запланировано)
В этом состоянии находятся пожелания, реализация которых запланирована в итерации. Реализация пожелания осуществляется путем выполнения задач участниками проекта. Пожелания, которые сейчас находятся в работе доступны в журнале пожеланий релиза.
После того, как все задачи по пожеланию выполняются участниками проекта, оно автоматически переходит в состояние "Выполнено". Если при выполнении задачи по тестированию тестировщик указывает, что тестирование провалено, то пожелание автоматически переходит в состояние "На обработке".
Если ваш процесс не требует создания плана работ и назначения задач на участников проекта, то вы можете отключить опцию "Использовать планирование задач" в методологии проекта. В этом случае пожелание попадает в состояние "В работе" когда участник берет пожелание себе (действие "Взять себе"), то есть назначается ответственным по данному пожеланию.
Выполнено
После выполнения всех задач по пожеланию, оно переходит в данное состояние. Также в это состояние пожелание переходит, если вызвать действие "Выполнить" над пожеланием, реализацию которого не планировали в итерации.
Выполненные пожелания доступны в одноименном журнале, просматривая который заказчик или тестировщик проверяют реализацию пожелания и закрывают пожелание, либо отклоняют его реализацию.
Для пожеланий, предполагающих периодическую реализацию, например, формирование отчетов, можно вызвать действие "Создать задачу", при котором добавляется новая задача по реализации пожелания и оно переходит в состояние "В работе".
Закрыто
Это терминальный статус пожелания, обозначающий окончание жизненного цикла пожелания. При необходимости заказчик или координатор могут переоткрыть пожелание, после чего оно попадает в состояние "На обработке".
Пример жизненного цикла
Рассмотрим использование системы на примере жизненного цикла некоторого пожелания, из которого будет понятно как применять систему для решения задач, поставленных заказчиком перед вами.
Журналы пожеланий
Каждое новое пожелание попадает в журнал пожеланий продукта. Управление скоупами пожеланий осуществляется путем включения пожелания в тот или иной релиз. Если вы считаете, что пожелание должно быть реализовано как можно скорее, то включайте его в текущий релиз, иначе включайте в будущие релизы. Вы можете отложить пожелание до лучших времен, либо закрыть его, если оно уже реализовано, либо не требует реализации.
Планирование
Включение пожелания в работу осуществляется путем планирования, при этом вы создаете необходимые задачи по реализации пожелания, например проведение анализа и подготовку требований, проектирование, разработку, тестирование и документирование. Система помогает вам не пропустить необходимые фазы разработки, однако путем настройки методологии проекта вы можете отключить неиспользуемые фазы.
После того, как пожелание будет запланировано, в текущей итерации появятся задачи по соответствующим фазам реализации данного пожелания. На закладке "Задачи" участникам проекта будут доступны задачи, назначенные им.
Реализация пожелания
Участники выполняют свои задачи: аналитик готовит раздел с требованиями и связывает его со своей задачей анализа, разработчик создает программный код и выкладывает в subversion, тестировщик формирует тестовые наборы и связывает их с задачей по тестированию, технический писатель создает раздел документации и связывает его с задачей на документирование.
После того как все задачи будут выполнены у пожелания устанавливается статус о завершении его разработки в данной итерации. Если пожелание не включалось в итерацию, то оно может быть выполнено при помощи действия "Выполнить", при этом необходимо указать результат выполнения пожелания и проставить часы, потраченные на его выполнение.
Приемка функциональности
Заказчик или тестировщик просматривает перечень реализованных пожеланий и в случае обнаружения ошибки может отклонить его, при этом пожелание отображается в журнале релиза с указанием причины отклонения и опять должно быть запланировано.
Трассировка
При реализации пожелания все созданные артефакты связывается между собой, таким образом вы всегда сможете получить исчерпывающую информацию о том, какие задачи были выполнены, какие артефакты подготовлены, например, требования и документация.
Оценка трудозатрат и фактические значения трудоемкости по задачами позволяют формировать коэффициенты, хараткеризующие скорость работы вашей команды, эффективность работы и прогнозировать сроки реализации будущих пожеланий.
Журналы пожеланий
Каждое новое пожелание попадает в журнал пожеланий продукта. Управление скоупами пожеланий осуществляется путем включения пожелания в тот или иной релиз. Если вы считаете, что пожелание должно быть реализовано как можно скорее, то включайте его в текущий релиз, иначе включайте в будущие релизы. Вы можете отложить пожелание до лучших времен, либо закрыть его, если оно уже реализовано, либо не требует реализации.
Планирование
Включение пожелания в работу осуществляется путем планирования, при этом вы создаете необходимые задачи по реализации пожелания, например проведение анализа и подготовку требований, проектирование, разработку, тестирование и документирование. Система помогает вам не пропустить необходимые фазы разработки, однако путем настройки методологии проекта вы можете отключить неиспользуемые фазы.
После того, как пожелание будет запланировано, в текущей итерации появятся задачи по соответствующим фазам реализации данного пожелания. На закладке "Задачи" участникам проекта будут доступны задачи, назначенные им.
Реализация пожелания
Участники выполняют свои задачи: аналитик готовит раздел с требованиями и связывает его со своей задачей анализа, разработчик создает программный код и выкладывает в subversion, тестировщик формирует тестовые наборы и связывает их с задачей по тестированию, технический писатель создает раздел документации и связывает его с задачей на документирование.
После того как все задачи будут выполнены у пожелания устанавливается статус о завершении его разработки в данной итерации. Если пожелание не включалось в итерацию, то оно может быть выполнено при помощи действия "Выполнить", при этом необходимо указать результат выполнения пожелания и проставить часы, потраченные на его выполнение.
Приемка функциональности
Заказчик или тестировщик просматривает перечень реализованных пожеланий и в случае обнаружения ошибки может отклонить его, при этом пожелание отображается в журнале релиза с указанием причины отклонения и опять должно быть запланировано.
Трассировка
При реализации пожелания все созданные артефакты связывается между собой, таким образом вы всегда сможете получить исчерпывающую информацию о том, какие задачи были выполнены, какие артефакты подготовлены, например, требования и документация.
Оценка трудозатрат и фактические значения трудоемкости по задачами позволяют формировать коэффициенты, хараткеризующие скорость работы вашей команды, эффективность работы и прогнозировать сроки реализации будущих пожеланий.
Журналы пожеланий
На закладке "Пожелания" отображаются журналы пожеланий, сгруппированных по релизам, статусам и другим параметрам. Справа расположен перечень журналов пожеланий. В каждом журнале пожеланий в верхней части расположен набор фильтров, например, по состояниям, приоритетам или тэгам. В нижней части журнала выводится информация о трудоемкости реализации журнала пожеланий и оценке срока его выполнения.
Журнал пожеланий продукта
При добавлении пожелания оно автоматически отображается в данном журнале, координатору необходимо принять решение о том, что делать с данным пожеланием: запланировать, отложить, закрыть и т.п. Журнал позволяет ввести дополнительный контроль над пожеланиями, добавленными пользователями, заказчиком и другими участниками проекта. В журнале содержатся все пожелания, когда-либо добавленные в проекте. При помощи фильтров вы можете отобрать нужный вам набор пожеланий.Журнал пожеланий релиза
Содержит пожелания, отнесенные к данному релизу, в рамках которого команда планирует выполнить эти пожелания. В данном журнале также отображаются ранее запланированные пожелания, но отклоненные тестировщиком при выполнении задачи по тестированию, либо отклоненные заказчиком. Реализацию отклоненного пожелания необходимо запланировать заново. Если опция методологии "Требуется утверждение пожеланий" отключена, то новые пожелания автоматически включаются в текущий релиз и доступны в данном журнале.Статистика по пожеланиям
Отображается сводная информация по пожеланиям проекта, с указанием журнала, в котором находятся пожелания, статуса пожелания, приоритета и типа (ошибка, доработка). При нажатии на соответствующую иконку вы перейдете в журнал пожеланий, отфильтрованный по данному критерию. Сводная информация помогает вам видеть в целом картину по реализации пожеланий и оперативно реагировать на появление критических ошибок.Неоцененные пожелания
Если используется опция методологии "Используется предварительная оценка пожеланий", то в данном журнале отображаются пожелания, трудоемкость реализации которых еще не была оценена участниками проекта.Добавленный мной пожелания
Журнал содержит пожелания, добавленные текущим пользователем. При помощи данного журнала заказчик, пользователи или тестировщики могут контролировать состояние собственных пожеланий.Мои пожелания (назначенные пожелания)
В журнале содержатся пожелания, назначенные некоторому участнику проекта.Выполненные пожелания
Журнал содержит все пожелания, которые были выполнены в течение проекта. Содержимое журнала можно детализировать по любой версии разрабатываемого продукта.Управление пожеланиями
Эффективное управление пожеланиями - залог успешности проекта, единого понимания целей и сроков проекта между заказчиком и командой. Основную работу по управлению пожеланиями выполняет координатор проекта совместно с заказчиком. Заказчик добавляет пожелания, устанавливает приоритеты и сроки, при необходимости выполняет приемку реализованных пожеланий.
Важную роль в управлении пожеланиями играют наборы (скоупы) пожеланий, при помощи наборов пожеланий формируются крупные вехи в разработке продукта или срезы пожеланий по состояниям. Вы можете формировать собственные наборы пожеланий, сгруппированные удобным для вас образом, при помощи тэгов. Если вам необходимо жестко контролировать набор пожеланий, то вы можете использовать приватные тэги, в этом случае их никто не сможет открепить от пожелания кроме вас.
DEVPROM контролирует все изменения выполненные над пожеланием, которые отображаются на форме пожелания в правой части, с указанием даты изменения, автора и содержания изменения. Контролируются изменения в атрибутах пожелания, состоянии, задачах, тэгах, связях и приложениях.
Важную роль в управлении пожеланиями играют наборы (скоупы) пожеланий, при помощи наборов пожеланий формируются крупные вехи в разработке продукта или срезы пожеланий по состояниям. Вы можете формировать собственные наборы пожеланий, сгруппированные удобным для вас образом, при помощи тэгов. Если вам необходимо жестко контролировать набор пожеланий, то вы можете использовать приватные тэги, в этом случае их никто не сможет открепить от пожелания кроме вас.
DEVPROM контролирует все изменения выполненные над пожеланием, которые отображаются на форме пожелания в правой части, с указанием даты изменения, автора и содержания изменения. Контролируются изменения в атрибутах пожелания, состоянии, задачах, тэгах, связях и приложениях.
Создание пожелания
При создании пожелания необходимо указать краткое название и подробное описание пожелания. При необходимости укажите приоритет пожелания. Содержимое журналов пожеланий отсортированы по приоритету.
Вы можете указать срок, к которому необходимо реализовать пожелание, либо провести аналитическую работу и т.п. Сроки пожеланий отображаются на главной странице и доступны всем участникам проекта. Задание сроков доступно при использовании опции методологии "Отслеживать сроки выполнения задач и реализации пожеланий".
Если в вашем проекте включена опция методологии "Использовать декомпозицию по функциям", то при создании пожелания необходимо указать функцию, к которой относятся пожелания.
Укажите номер версии продукта к которой относится данное пожелание.
После создания пожелания вы можете прикрепить к нему приложения, тэги, оставить комментарии, добавить связи с другими пожеланиями. Пожелание попадает в журнал пожеланий продукта. Координатор проекта получает почтовое уведомление о новом пожелании и выполняет над ним необходимые действия.
Если в проекте используется фаза подготовки требований, то вы можете добавить доработку или сообщить об ошибке, предварительно указав требование, к которому относится доработка или в реализации которого обнаружена ошибка.
Вы можете указать срок, к которому необходимо реализовать пожелание, либо провести аналитическую работу и т.п. Сроки пожеланий отображаются на главной странице и доступны всем участникам проекта. Задание сроков доступно при использовании опции методологии "Отслеживать сроки выполнения задач и реализации пожеланий".
Если в вашем проекте включена опция методологии "Использовать декомпозицию по функциям", то при создании пожелания необходимо указать функцию, к которой относятся пожелания.
Укажите номер версии продукта к которой относится данное пожелание.
После создания пожелания вы можете прикрепить к нему приложения, тэги, оставить комментарии, добавить связи с другими пожеланиями. Пожелание попадает в журнал пожеланий продукта. Координатор проекта получает почтовое уведомление о новом пожелании и выполняет над ним необходимые действия.
Если в проекте используется фаза подготовки требований, то вы можете добавить доработку или сообщить об ошибке, предварительно указав требование, к которому относится доработка или в реализации которого обнаружена ошибка.
Планирование, задачи
Пожелания - это форма описания функциональности, реализация которой может быть запланирована в итерации в виде нескольких задач по каждой фазе процесса разработки, назначенной на соответствующего участника проекта.
Задачи связывают пожелание с фазами разработки и исполнителями, характеризуются плановой, оставшейся и фактической трудоемкостью. Задачи содержатся в итерации. В итерацию могут быть добавлены дополнительные задачи, не связанные непосредственно с пожеланиями, но необходимые для проверки, развертывания решения и других задач проекта.
Задачи связывают пожелание с фазами разработки и исполнителями, характеризуются плановой, оставшейся и фактической трудоемкостью. Задачи содержатся в итерации. В итерацию могут быть добавлены дополнительные задачи, не связанные непосредственно с пожеланиями, но необходимые для проверки, развертывания решения и других задач проекта.
Итерация
На этой закладке отображается вся информация по текущей итерации. В разделе "Статистика по задачам" отображаются ссылки на задачи каждого участника, с указанием процента выполнения. А также распределение задач по состояниями и приоритетам. В правой части блока отображается прогресс выполнения пожеланий, запланированных в итерации, а также прогресс выполнения задач по каждой фазе процесса разработки, с указанием текущей и требуемой скорости команды. Если текущая скорость команды ниже, чем требуемая, то данный показатель отображается красным цветом. В этом случае вам необходимо перераспределить ресурсы, либо изменить состав задач.
В разделе "Параметры" отображаются основные параметры итерации: дата начала и окончания, оставшаяся продолжительность. Прогнозируемая продолжительность характеризует длительность итерации при текущей скорости работы команды. Минимальная продолжительность характеризует длительность итерации при максимальной скорости работы команды, то есть при скорости равной суммарной ежедневной загрузке участников.
Задачи в итерации могут отображаться в различных представлениях: в виде списка пожеланий, запланированных в итерации, в виде списка задач, а также в виде доски задач. Доска задач позволяет получить лучшее представление о состоянии итерации: к каким задачам уже приступили, какие в работе, а какие выполнены. При помощи фильтра задач вы можете отобрать задачи по типам или приоритету. Например, тест-менеджера могут интересовать только задачи по тестированию. Таким образом, доска задач может быть настроена для каждой роли.
В правой части страницы отображается burndown диаграмма, характеризующая состояние работ по итерации, а также детализация работ по каждому участнику, с указанием его загрузки. Если вы используете опцию "Участники самостоятельно выбирают себе задачи", то DEVPROM отображается загрузку по фазам процесса разработки.
В разделе "Параметры" отображаются основные параметры итерации: дата начала и окончания, оставшаяся продолжительность. Прогнозируемая продолжительность характеризует длительность итерации при текущей скорости работы команды. Минимальная продолжительность характеризует длительность итерации при максимальной скорости работы команды, то есть при скорости равной суммарной ежедневной загрузке участников.
Задачи в итерации могут отображаться в различных представлениях: в виде списка пожеланий, запланированных в итерации, в виде списка задач, а также в виде доски задач. Доска задач позволяет получить лучшее представление о состоянии итерации: к каким задачам уже приступили, какие в работе, а какие выполнены. При помощи фильтра задач вы можете отобрать задачи по типам или приоритету. Например, тест-менеджера могут интересовать только задачи по тестированию. Таким образом, доска задач может быть настроена для каждой роли.
В правой части страницы отображается burndown диаграмма, характеризующая состояние работ по итерации, а также детализация работ по каждому участнику, с указанием его загрузки. Если вы используете опцию "Участники самостоятельно выбирают себе задачи", то DEVPROM отображается загрузку по фазам процесса разработки.
Список задач
На закладке "Задачи" отображается список задач, назначенных текущему пользователю, сгруппированный по пожеланиям. Каждый участник, может отчитаться о затраченном времени по задаче, разбить ее на подзадачи или выполнить задачу, указав фактическую трудоемкость.
Над перечнем задач по пожеланию отображаются все артефакты, связанные с данным пожеланием. Таким образом, разработчик и тестировщик видят какие требования были подготовлены по пожеланию, какие тестовые наборы необходимо прогнать на версии, в которой выполнено пожелание.
В правой части отображаются показатели участника, с тем, чтобы он видел свою текущую выработку и вовлеченность, а также диаграмма burndown, характеризующая состояние проекта. Зеленая линия должна находится под красной, только тогда команда успеет выполнить итерацию в срок.
Если используется опция методологии "Участники выбирают себе задачи самостоятельно", то в верхней части страницы отображается пул свободных задач. Участнику необходимо взять задачу себе, перед тем как начать ее выполнение.
Над перечнем задач по пожеланию отображаются все артефакты, связанные с данным пожеланием. Таким образом, разработчик и тестировщик видят какие требования были подготовлены по пожеланию, какие тестовые наборы необходимо прогнать на версии, в которой выполнено пожелание.
В правой части отображаются показатели участника, с тем, чтобы он видел свою текущую выработку и вовлеченность, а также диаграмма burndown, характеризующая состояние проекта. Зеленая линия должна находится под красной, только тогда команда успеет выполнить итерацию в срок.
Если используется опция методологии "Участники выбирают себе задачи самостоятельно", то в верхней части страницы отображается пул свободных задач. Участнику необходимо взять задачу себе, перед тем как начать ее выполнение.
Исходный код
Работа с исходным кодом проекта построена на базе Subversion.
Если в качестве репозитория исходного кода вы используете Subversion, то включите соответствующую опцию в настройках проекта. Если не используете, то подумайте об использовании бесплатного и хорошо зарекомендовавшего себя инструмента контроля версиями.
DEVPROM позволяет просматривать последние изменения в исходном коде, навигироваться по дереву исходного кода, просматривать изменения в каждом файле без использования дополнительного инструментария. При коммите изменений в репозиторий указывайте ссылку на пожелание или задачу, тогда DEVPROM автоматически свяжет пожелание или задачу с данным коммитом.
Таким образом, вы получите полную трассировку изменений: от коммита к реализованному пожеланию и от пожелания к выполненным изменениям в исходном коде.
Если в качестве репозитория исходного кода вы используете Subversion, то включите соответствующую опцию в настройках проекта. Если не используете, то подумайте об использовании бесплатного и хорошо зарекомендовавшего себя инструмента контроля версиями.
DEVPROM позволяет просматривать последние изменения в исходном коде, навигироваться по дереву исходного кода, просматривать изменения в каждом файле без использования дополнительного инструментария. При коммите изменений в репозиторий указывайте ссылку на пожелание или задачу, тогда DEVPROM автоматически свяжет пожелание или задачу с данным коммитом.
Таким образом, вы получите полную трассировку изменений: от коммита к реализованному пожеланию и от пожелания к выполненным изменениям в исходном коде.
Требования
Подготовка и управление требованиями является важной частью зрелого процесса разработки и особенно актуальны, если в проекте участвуют больше двух человек, а заказчик является основным постановщиком.
DEVPROM предоставляет возможность совместной работы участников проекта над требованиями при помощи Wiki, позволяет вести дискуссии по каждому разделу требований, вовлекая всех участников, контролировать изменения в требованиях и осуществлять трассировку изменений требований в изменения в тестовой и справочной документации.
Вы можете привлекать заказчика к активному участию в формировании и уточнении требований, согласовывать с ним постановку и обмениваться требованиями с внешними по отношению к проекту участниками.
Если в вашем проекте не предполагается использование требований, то вы можете просто отключить соответствующую опцию методологии проекта. Система автоматически исключит фазу анализа из всего процесса управления проектом.
DEVPROM предоставляет возможность совместной работы участников проекта над требованиями при помощи Wiki, позволяет вести дискуссии по каждому разделу требований, вовлекая всех участников, контролировать изменения в требованиях и осуществлять трассировку изменений требований в изменения в тестовой и справочной документации.
Вы можете привлекать заказчика к активному участию в формировании и уточнении требований, согласовывать с ним постановку и обмениваться требованиями с внешними по отношению к проекту участниками.
Если в вашем проекте не предполагается использование требований, то вы можете просто отключить соответствующую опцию методологии проекта. Система автоматически исключит фазу анализа из всего процесса управления проектом.
Типовой пример
Рассмотрим пример использования системы с точки зрения анализа и подготовки требований к разрабатываемому продукту. Вы можете готовить требования независимо от плана работ, либо выполняя задачи анализа, рассмотрим второй вариант.
Планирование
Заказчик добавил пожелание о том, чтобы в продукте была возможность регистрировать пользователей. Координатор самостоятельно или с участием команды планирует пожелание, при этом создаются задачи на анализ, разработку, тестирование и документирование.
Подготовка требования
В списке своих задач аналитик видит задачу по подготовке требований к данному пожеланию. Аналитик переходит на закладку "Требования" и формирует иерархию требований, необходимую для реализации исходного пожелания, при помощи наполнения Wiki-страниц. Аналитик определяет требует ли подготовленный раздел реализации. Указать, что требование не требует реализации можно при помощи соответствующей галочки на при редактировании требования. К такому разделу требований нельзя добавить пожеланий или ошибок, такой раздел нельзя связывать с тестовыми сценариями и разделами справочной документации, а также отслеживать по нему покрытию. Примерами таких разделов требований могут являться глоссарий, варианты использования или страницы, содержащие вводные данные для следующих разделов.
По мере готовности требований Аналитик связывает свою текущую задачу по анализу с каждым подготовленным требованием. Текущие задачи анализа отображаются на странице с требованием, на правой панели, в секции "Мои текущие задачи". Таким образом связываются пожелания и требования, а также автоматически создаются связи с тестовыми наборами и разделами справочной документации при их подготовке.
Каждое готовое требование Аналитик переводит в состояние "Готово", это сигнал для заказчика для согласования требований. Аналитик завершает свою задачу анализа и указывает потраченное на нее время.
Подписание требования
Используя фильтры "Требующие подписания" или "Измененные с момента последнего посещения" Заказчик просматривает требования и оставляет свои комментарии, которые автоматически отсылаются автору требования. Заказчик подписывает согласованные разделы требований.
Разработка по требованию
Разработчики, тестировщики и технические писатели в списках своих задач видят требования, связанные с пожеланиями и перед выполнением своих задач знакомятся с требованиями, вносят предложения и дополнения.
Как правило, любое дополнение к требованию влияет на общее время итерации или релиза, поэтому изменения в требовании необходимо сопровождать созданием доработок. Данная операция доступна со страницы с текстом требования на правой панели в секции "Доработки". Добавленная таким образом доработка автоматически связывается с требованием и затем планируется как любое другое пожелание.
Контроль за реализацией требования
Координатор проекта или другой ответственный участник контролируют ход работ по требованию на странице с текстом требования. На ней отображаются обнаруженные ошибки в реализации данного требования, текущее состояние по всем пожеланиям, реализующим требования, плановая и фактическая трудоемкость. Также контролируется связь требования с остальными артефактами проекта: тестовыми наборами и справочной документацией, чтобы требование было качественно отражено в процессах тестирования и подготовки документации.
Планирование
Заказчик добавил пожелание о том, чтобы в продукте была возможность регистрировать пользователей. Координатор самостоятельно или с участием команды планирует пожелание, при этом создаются задачи на анализ, разработку, тестирование и документирование.
Подготовка требования
В списке своих задач аналитик видит задачу по подготовке требований к данному пожеланию. Аналитик переходит на закладку "Требования" и формирует иерархию требований, необходимую для реализации исходного пожелания, при помощи наполнения Wiki-страниц. Аналитик определяет требует ли подготовленный раздел реализации. Указать, что требование не требует реализации можно при помощи соответствующей галочки на при редактировании требования. К такому разделу требований нельзя добавить пожеланий или ошибок, такой раздел нельзя связывать с тестовыми сценариями и разделами справочной документации, а также отслеживать по нему покрытию. Примерами таких разделов требований могут являться глоссарий, варианты использования или страницы, содержащие вводные данные для следующих разделов.
По мере готовности требований Аналитик связывает свою текущую задачу по анализу с каждым подготовленным требованием. Текущие задачи анализа отображаются на странице с требованием, на правой панели, в секции "Мои текущие задачи". Таким образом связываются пожелания и требования, а также автоматически создаются связи с тестовыми наборами и разделами справочной документации при их подготовке.
Каждое готовое требование Аналитик переводит в состояние "Готово", это сигнал для заказчика для согласования требований. Аналитик завершает свою задачу анализа и указывает потраченное на нее время.
Подписание требования
Используя фильтры "Требующие подписания" или "Измененные с момента последнего посещения" Заказчик просматривает требования и оставляет свои комментарии, которые автоматически отсылаются автору требования. Заказчик подписывает согласованные разделы требований.
Разработка по требованию
Разработчики, тестировщики и технические писатели в списках своих задач видят требования, связанные с пожеланиями и перед выполнением своих задач знакомятся с требованиями, вносят предложения и дополнения.
Как правило, любое дополнение к требованию влияет на общее время итерации или релиза, поэтому изменения в требовании необходимо сопровождать созданием доработок. Данная операция доступна со страницы с текстом требования на правой панели в секции "Доработки". Добавленная таким образом доработка автоматически связывается с требованием и затем планируется как любое другое пожелание.
Контроль за реализацией требования
Координатор проекта или другой ответственный участник контролируют ход работ по требованию на странице с текстом требования. На ней отображаются обнаруженные ошибки в реализации данного требования, текущее состояние по всем пожеланиям, реализующим требования, плановая и фактическая трудоемкость. Также контролируется связь требования с остальными артефактами проекта: тестовыми наборами и справочной документацией, чтобы требование было качественно отражено в процессах тестирования и подготовки документации.
Управление требованиями
Шаблоны
При разработке требований желательно использовать типовые шаблоны, которые позволят не только лучше структурировать требование, но и помочь автору в описании всех необходимых аспектов требуемой функциональности. Например, все прецеденты имеют схожую структуру, таким образом, опытный или старший аналитик могут заранее подготовить шаблоны, которые будут использовать остальные участники команды.
При разработке очередного требования аналитик просто выбирает нужный шаблон из выпадающего списка и заполняет позиции текстом.
Тэги
При помощи тэгов вы можете формировать альтернативные группы разделов требований, поскольку не всегда возможно в рамках одной иерархии удобным образом сгруппировать требования. Название тэга отображается ссылкой, при переходе по которой отображаются все требования, отмеченные данным тэгом.
Фильтры
Участники проекта могут использовать фильтры для быстрого доступа к нужным разделам требований, ниже перечислены данные фильтры:
При разработке требований желательно использовать типовые шаблоны, которые позволят не только лучше структурировать требование, но и помочь автору в описании всех необходимых аспектов требуемой функциональности. Например, все прецеденты имеют схожую структуру, таким образом, опытный или старший аналитик могут заранее подготовить шаблоны, которые будут использовать остальные участники команды.
При разработке очередного требования аналитик просто выбирает нужный шаблон из выпадающего списка и заполняет позиции текстом.
Тэги
При помощи тэгов вы можете формировать альтернативные группы разделов требований, поскольку не всегда возможно в рамках одной иерархии удобным образом сгруппировать требования. Название тэга отображается ссылкой, при переходе по которой отображаются все требования, отмеченные данным тэгом.
Фильтры
Участники проекта могут использовать фильтры для быстрого доступа к нужным разделам требований, ниже перечислены данные фильтры:
- Измененные с момента последнего посещения - отображаются требования, которые были изменены другими участниками проекта с момента вашего последнего посещения закладки "Требования".
- Измененные в последней итерации - отображаются требования, которые были изменены с момента начала и до окончания итерации, с возможностью переключения между итерациями.
- Требующие подписания - отображаются подготовленные требования, которые необходимо подписать прежде чем начнется разработка соответствующей функциональности.
- Не реализованные - отображаются требования, по которым были созданы доработки или ошибки, однако не завершены соответствующие задачи по реализации функциональности.
- Не покрытые документацией - отображаются требования, которые не связаны с разделами справочной документации, возможно, данные требования не будут отражены в документации.
- Не покрытые тестовыми сценариями - отображаются требования, которые не связаны с тестовыми наборами, возможно, функциональность по этим требованиям не будет проверена тестировщиками.
- Требования в архиве - отображаются устаревшие требования, перемещенные в архив.
Тестирование
Под тестированием подразумевается часть процесса разработки, в рамках которой участники проекта формируют текстовое описание ожидаемого поведения, критериев корректности и результатов работы разрабатываемого продукта, а также проверяют разработанный функционал на соответствие данному описанию.
Используемые понятия:
Распределение ролей:
Если в вашем проекте не требуется выполнять тестирование, то вы можете отключить соответствующую опцию в настройках методологии проекта.
Используемые понятия:
- Тестовый набор - содержит описание некоторого функционала продукта, условия проведения тестирования и объединяет тестовые случаи, определяющие варианты проверки данного функционала.
- Тестовый случай - содержит описание ожидаемого поведения, критериев корректности и результатов работы функционала при заданных входных данных. Тестовые случаи описывают различные варианты использования некоторого функционала.
- Тест - отражает результаты тестирования по некоторому тестовому набору на заданной версии продукта. При выполнении теста тестировщик отмечает результат проверки каждого тестового случая.
- Тест план - объединяет тестовые наборы в группу, определяет условия тестирования и позволяет автоматически создавать задачи на тестирование по каждому тестовому набору, включенному в план, то есть планировать в итерации проверку продукта по данному тест плану. Частным случаем тест плана является регрессионное тестирование по различным участкам функциональности продукта.
Распределение ролей:
- Координатор (или тест-менеджер) формируют план тестирования продукта путем включения пожеланий в итерацию, указывая при этом, что необходимо сделать для выполнения задачи по тестированию: подготовить тестовый набор или выполнить тест по готовому тестовому набору. Координатор включает тест планы в итерацию, просматривает результаты выполнения тестов и отчеты по тестированию. Координатор оценивает покрытие требований тестовыми случаями. Координатор планирует исправление найденных ошибок тем же образом, как он планирует реализацию пожеланий.
- Тестировщик выполняет задачи по тестированию, в результате которых формируются тестовые наборы, тест планы и тестовые случаи. Тестировщик выполняет тесты и вносит результат проверки каждого тестового случая. В процессе выполнения теста тестировщик сообщает об ошибках, прикрепляет связанные с ними скриншоты и т.п., вносит пожелания к функциональности. По окончании выполнения задачи тестировщик отчитывается о часах, затраченных на подготовку тестового сценария или на выполнение теста.
Если в вашем проекте не требуется выполнять тестирование, то вы можете отключить соответствующую опцию в настройках методологии проекта.
Тестовые наборы
Тестовые наборы и тестовые случаи представляют собой текстовое описание начальных и конечных условий, критерив проверки и т.п., представленное в форме Wiki-страниц.
Система организует совместную работу участников над тестовыми наборами, ведет историю изменений и позволяет вести обсуждение. Вы можете выгружать тестовые наборы в формате MS Word, перемещать их в архив.
Шаблоны позволяют определить формат тестовых случаев, которого следует придерживаться всем тестировщикам при написании тестовых случаев. Таким образом, при создании очередного тестового случая тестировщик загружает шаблон и заполняет его необходимыми значениями.
Дополнительные разделы тестового набора:
Вне зависимости от планов и текущих задач тестировщик может выполнять тесты путем вызова соответствующего действия из списка тестовых наборов или со страницы тестового набора.
В списке неактуальных тестовых наборов отображается перечень наборов, которые связаны с требованиями, изменившимися после установления связи. Для актуализации связи необходимо перейти на страницу тестового набора, посмотреть изменения в требованиях, связь с которыми стала неактуальной, привести описание тестовых случаев в соответствие с тектом требований и актуализировать связь путем нажатия по соответствующей иконке.
Система организует совместную работу участников над тестовыми наборами, ведет историю изменений и позволяет вести обсуждение. Вы можете выгружать тестовые наборы в формате MS Word, перемещать их в архив.
Шаблоны позволяют определить формат тестовых случаев, которого следует придерживаться всем тестировщикам при написании тестовых случаев. Таким образом, при создании очередного тестового случая тестировщик загружает шаблон и заполняет его необходимыми значениями.
Дополнительные разделы тестового набора:
- Тэги - позволяют группировать тестовые наборы по нужным вам критериям или привязывать к наборам дополнительные атрибуты.
- Мои текущие задачи по тестированию - в разделе отображается список текущих задач тестировщика. Нажатием на иконку тестировщик связывает задачу с данным тестовым набором, при этом с данным набором авматически связывается пожелание и требование, если оно подготовлено для пожелания. На основании данных связей обеспечивается трассировка изменений требования.
- Связи с требованиями - отображаются требования, связанные с данные тестовым набором, то есть какие требования покрываются данным набором. В будущем при изменении требования данный тестовый набор пометится как неактуальный. Внеся необходимые изменения в описание тестовых случаев тестировщик актуализирует связь. При необходимости тестировщик может вручную добавить связь, если автоматически это сделать не удалось.
- Результаты тестирования - отображаются все тесты, с указанием даты проведения, в которых участвовал данный тестовый набор.
Вне зависимости от планов и текущих задач тестировщик может выполнять тесты путем вызова соответствующего действия из списка тестовых наборов или со страницы тестового набора.
В списке неактуальных тестовых наборов отображается перечень наборов, которые связаны с требованиями, изменившимися после установления связи. Для актуализации связи необходимо перейти на страницу тестового набора, посмотреть изменения в требованиях, связь с которыми стала неактуальной, привести описание тестовых случаев в соответствие с тектом требований и актуализировать связь путем нажатия по соответствующей иконке.
Тест планы
Тест планы предназначены для формирования некоторого сценария тестирования, описания условий его провеления, оценки его трудоемкости и распределения ответственности между тестировщиками.
Тест план группирует тестовые наборы, определяется плановую трудоемкость на выполнение теста по каждому набору и закрепляет ответственного за проведение теста по каждому тестовому набору.
Для проведения комплексного тестирования соответствующий тест план включается в итерацию, при этом система предлагает откорректировать значения плановой трудоемкости и изменить ответственного по каждому тестовому набору. Путем нажатия кнопки "Создать задачи тестирования" в итерацию включаются задачи по тестированию каждого тестового набора, где в качестве исполнителя подставляется ответственный за данный тестовый набор.
Используя тест планы вы легко можете организовать функциональное или регрессионное тестирование по крупным участкам разрабатываемого продукта.
Помимо результатов тестирования по каждому тестовому набору на странице тест плана отображается фактическая трудоемкость выполнения тестов. На основании этого показателя вы можете корректировать плановую трудоемкость тест плана и иметь представление о трудоемкости тестирования, что необходимо для планирования тестирования в итерации и оценке сроков.
Тест план группирует тестовые наборы, определяется плановую трудоемкость на выполнение теста по каждому набору и закрепляет ответственного за проведение теста по каждому тестовому набору.
Для проведения комплексного тестирования соответствующий тест план включается в итерацию, при этом система предлагает откорректировать значения плановой трудоемкости и изменить ответственного по каждому тестовому набору. Путем нажатия кнопки "Создать задачи тестирования" в итерацию включаются задачи по тестированию каждого тестового набора, где в качестве исполнителя подставляется ответственный за данный тестовый набор.
Используя тест планы вы легко можете организовать функциональное или регрессионное тестирование по крупным участкам разрабатываемого продукта.
Помимо результатов тестирования по каждому тестовому набору на странице тест плана отображается фактическая трудоемкость выполнения тестов. На основании этого показателя вы можете корректировать плановую трудоемкость тест плана и иметь представление о трудоемкости тестирования, что необходимо для планирования тестирования в итерации и оценке сроков.
Типовой пример
Рассмотрим пример использования системы с точки зрения тестирования разрабатываемого продукта. Предположим, в нашем продукте требуется реализовать некоторую функциональность, например, создание учетной записи пользователя.
Планирование
Заказчик добавил пожелание о том, чтобы в продукте была возможность регистрировать пользователей. Координатор самостоятельно или с участием команды планирует пожелание, при этом создаются задачи на анализ, разработку, тестирование и документирование.
Аналитик готовит требования, разработчики реализуют требуемую функциональность.
Подготовка тестового набора
В списке задач тестировщика отображается задача по тестированию функциональности регистрации пользователей. После подготовки требования тестировщику становится доступна ссылка на раздел требования, по которому он готовит тестовый набор. В качестве тестовых случаев тестировщик описывает варианты поведения системы в результате ввода пользователем различных данных на форме регистрации. Таким образом, тестовые случаи покрывают все возможные проверки и ограничения, предусмотренные требованиями.
Тестировщик связывает тестовый набор с задачей по тестированию, открывает задачу по тестированию и указывает затраченное время на подготовку тестового набора. В результате тестовый набор связывается с требованием.
Выполнение теста
По окончании разработки данного функционала выпускается сборка, в которой он доступен. В списке задач тестировщика отображается номер сборки, в которой доступен данный функционал. Из списка действий задачи тестировщик выбирает действие "Выполнить тест".
Система отображает текстовое описание всех тестовых случаев, входящих в тестовый набор, подготовленный тестировщиком ранее. Тестировщик проверяет работу функционала и напротив каждого тестового случая ставит резолюцию: пройден или провален. Если тест провален, то тестировщик прикрепляет к тесту необходимые файлы и заводит ошибки. При необходимости тестировщик корректирует описание тестовых случаев.
По окончании выполнения теста тестировщик завершает задачу, указывает окончательную резолюцию: выполнен тест или провален и указывает затраченные часы.
Результаты тестирования
Координатор или заказчик имеет возможность просмотреть отчет по тестированию, из которого он делает вывод о том, какие тесты пройдены и с каким результатом.
Координатор обрабатывает найденные тестировщиком ошибки, планирует их реализацию в текущей или следующей итерациях. Если при выполнении задачи тестировщик указал, что тест провален, то исходное пожелание вновь становится доступным для планирования в Журнале пожеланий с пометкой о причине отклонения.
Сходимость тестирования координатор определяет на основе графика, расположенного на странице "Тестирование", на котором отображается количество ошибок, обнаруженных в каждой сборке или итерации. Снижение потока ошибок также характеризует повышение качества, разрабатываемого продукта.
В статистике релиза отображается коэффициент "Процент ошибок в общем объеме работ", который позволяет судить о качестве работы разработчиков и оценивать сроки будущих итераций и релизов.
Доработка функциональности
Координатор или тестировщик включает подготовленный тестовый набор в тест план для будущего регрессионного тестирования.
Заказчик заводит дополнительное пожелание к функциональности регистрации пользователей. Из-за переработки кода возрастает риск разрушения реализованной функциональности. После планирования пожелания координатор включает в итерацию тест план, по которому автоматически создаются задачи на тестирование по каждому тестовому набору, включенному в данный план.
Тестировщик в очередной раз выполняет тест по тестовому набору, проверяя тем самым функционал регистрации пользователей на предмет регрессии.
Планирование
Заказчик добавил пожелание о том, чтобы в продукте была возможность регистрировать пользователей. Координатор самостоятельно или с участием команды планирует пожелание, при этом создаются задачи на анализ, разработку, тестирование и документирование.
Аналитик готовит требования, разработчики реализуют требуемую функциональность.
Подготовка тестового набора
В списке задач тестировщика отображается задача по тестированию функциональности регистрации пользователей. После подготовки требования тестировщику становится доступна ссылка на раздел требования, по которому он готовит тестовый набор. В качестве тестовых случаев тестировщик описывает варианты поведения системы в результате ввода пользователем различных данных на форме регистрации. Таким образом, тестовые случаи покрывают все возможные проверки и ограничения, предусмотренные требованиями.
Тестировщик связывает тестовый набор с задачей по тестированию, открывает задачу по тестированию и указывает затраченное время на подготовку тестового набора. В результате тестовый набор связывается с требованием.
Выполнение теста
По окончании разработки данного функционала выпускается сборка, в которой он доступен. В списке задач тестировщика отображается номер сборки, в которой доступен данный функционал. Из списка действий задачи тестировщик выбирает действие "Выполнить тест".
Система отображает текстовое описание всех тестовых случаев, входящих в тестовый набор, подготовленный тестировщиком ранее. Тестировщик проверяет работу функционала и напротив каждого тестового случая ставит резолюцию: пройден или провален. Если тест провален, то тестировщик прикрепляет к тесту необходимые файлы и заводит ошибки. При необходимости тестировщик корректирует описание тестовых случаев.
По окончании выполнения теста тестировщик завершает задачу, указывает окончательную резолюцию: выполнен тест или провален и указывает затраченные часы.
Результаты тестирования
Координатор или заказчик имеет возможность просмотреть отчет по тестированию, из которого он делает вывод о том, какие тесты пройдены и с каким результатом.
Координатор обрабатывает найденные тестировщиком ошибки, планирует их реализацию в текущей или следующей итерациях. Если при выполнении задачи тестировщик указал, что тест провален, то исходное пожелание вновь становится доступным для планирования в Журнале пожеланий с пометкой о причине отклонения.
Сходимость тестирования координатор определяет на основе графика, расположенного на странице "Тестирование", на котором отображается количество ошибок, обнаруженных в каждой сборке или итерации. Снижение потока ошибок также характеризует повышение качества, разрабатываемого продукта.
В статистике релиза отображается коэффициент "Процент ошибок в общем объеме работ", который позволяет судить о качестве работы разработчиков и оценивать сроки будущих итераций и релизов.
Доработка функциональности
Координатор или тестировщик включает подготовленный тестовый набор в тест план для будущего регрессионного тестирования.
Заказчик заводит дополнительное пожелание к функциональности регистрации пользователей. Из-за переработки кода возрастает риск разрушения реализованной функциональности. После планирования пожелания координатор включает в итерацию тест план, по которому автоматически создаются задачи на тестирование по каждому тестовому набору, включенному в данный план.
Тестировщик в очередной раз выполняет тест по тестовому набору, проверяя тем самым функционал регистрации пользователей на предмет регрессии.
Отчеты
DEVPROM предоставляет несколько отчетов для оценки результатов тестирования. Отчеты доступны на закладке "Тестирование".
Вы можете перейти к просмотру самого теста, чтобы лучше понять ход тестирования. Путем нажатия на иконку в столбце "Пожелания" вы можете перейти к тем пожеланиям, которые были обнаружены в результате выполнения теста.
Для просмотра результатов тестирования по определенной версии необходимо указать номер версии и нажать кнопку "Обновить".
В секции "Обнаруженные пожелания и ошибки" отображаются пожелания, которые были добавлены в этой версии.
Результаты тестирования
В данном отчете отображаются последние выполненные тесты в обратном хронологическом порядке. При этом указываются: тестовый набор, по которому выполнялся тест, версия продукта, на которой выполнялось тестирование, процент прохождения тестовых случаев, обнаруженные при прохождении теста пожелания и ошибки, дата проведения теста.Вы можете перейти к просмотру самого теста, чтобы лучше понять ход тестирования. Путем нажатия на иконку в столбце "Пожелания" вы можете перейти к тем пожеланиям, которые были обнаружены в результате выполнения теста.
Для просмотра результатов тестирования по определенной версии необходимо указать номер версии и нажать кнопку "Обновить".
Результаты тестирования по версиям
В данном отчете отображается матрица тестовых наборов и версий, в которых они проверялись, с указанием результата прохождения тестов. Используйте этот отчет для контроля за полнотой тестирования и изменениями в качестве функционала, которые могут происходит от версии к версии.В секции "Обнаруженные пожелания и ошибки" отображаются пожелания, которые были добавлены в этой версии.
Документация
Важным результатом работы вашей команды является справочная документация для пользователей продукта или иная проектная документация, которую требует подготовить заказчик.
На закладке "Документация" отображается перечень справочных документов, представляющих из себя Wiki-страницы. Вы можете использовать все преимущества Wiki, обсуждений справочных разделов, связи справочных разделов с требованиями и пожеланиями, а также ведения отчетности по времени затраченному на подготовку справочных или проектных документов.
Подготовленные документы можно выгрузить в следующих форматах:
Для использования возможности подготовки справочной документации необходимо включить опцию методологии "Использовать фазу подготовки справочной документации".
После того как очередной раздел документации готов, свяжите его с задачей по документированию, при этом DEVPROM автоматически свяжет раздел документации с пожеланием и требованием. Если требование в будущем изменится, то на закладке "Документация" отобразятся неактуальные разделы документации. Перейдите в раздел, доработайте его содержание и актуализируйте связь. Таким образом, DEVPROM помогает вам сохранить документацию в актуальном состоянии.
Для того, чтобы проконтролировать как пожелание отражено в документах перейдите на форму пожелания и по ссылке "Трассировка" посмотрите те разделы документации, которые были подготовлены в рамках выполнения этого пожелания.
Если у вас уже есть несколько версий продукта, для которых документация несколько отличается, то вы можете скопировать документ и тем самым получить несколько справочных документов для каждой версии продукта.
На закладке "Документация" отображается перечень справочных документов, представляющих из себя Wiki-страницы. Вы можете использовать все преимущества Wiki, обсуждений справочных разделов, связи справочных разделов с требованиями и пожеланиями, а также ведения отчетности по времени затраченному на подготовку справочных или проектных документов.
Подготовленные документы можно выгрузить в следующих форматах:
- RTF - для просмотра или редактирования в MS Word или OpenOffice.
- CHM - для последующей компиляции в стандартный файл справки Microsoft
- HTML - для печати или создания индивидуального внешнего вида страниц документации.
Для использования возможности подготовки справочной документации необходимо включить опцию методологии "Использовать фазу подготовки справочной документации".
После того как очередной раздел документации готов, свяжите его с задачей по документированию, при этом DEVPROM автоматически свяжет раздел документации с пожеланием и требованием. Если требование в будущем изменится, то на закладке "Документация" отобразятся неактуальные разделы документации. Перейдите в раздел, доработайте его содержание и актуализируйте связь. Таким образом, DEVPROM помогает вам сохранить документацию в актуальном состоянии.
Для того, чтобы проконтролировать как пожелание отражено в документах перейдите на форму пожелания и по ссылке "Трассировка" посмотрите те разделы документации, которые были подготовлены в рамках выполнения этого пожелания.
Если у вас уже есть несколько версий продукта, для которых документация несколько отличается, то вы можете скопировать документ и тем самым получить несколько справочных документов для каждой версии продукта.
Отчеты
DEVPROM предоставляет большое количество отчетов, предназначенных для лучшего понимания текущего состояния проекта и анализа проблем в работе команды.
Отчеты по задачам
При использовании планирования участники проекта выполняют задачи и отчитываются о затраченном времени. DEVPROM предоставляет несколько отчетов, которые позволяют анализировать задачи, выполняемые участниками.
Используйте этот отчет для анализа времени затраченного участниками на задачи, на сколько точно соответствует плановая трудоемкость фактической, а также для сравнения эффективности работы различных участников.
Внизу отчета отображается суммарная плановая и фактическая трудоемкость по задачам, а также подсчитывается коэффициент отклонения. Если у кого-то из участников коэффициент отклонения положительный и сильно отличается от остальных участников, то это повод задуматься над эффективностью работы данного участника.
Используйте этот отчет для контроля отработанного времени участниками, если вы ваш проект работает по модели time and materials, либо заказчик требует предоставления подтверждения израсходованных средств.
Данный отчет может использовать и без планирования, для этого в методологии необходимо включить опцию "Участники отчитываются о затраченном времени". При выполнении пожелания можно указать количество затраченных часов.
Текущие задачи проекта
В отчете отображается перечень текущих задач по проекту с указанием типа, приоритета, состояния, исполнителя и названия задачи. Вы можете отфильтровать задачи по версии, участнику и типу задачи.Работы выполненные участниками
В отчете отображается перечень задач, выполненных участниками, с указанием типа, приоритета, исполнителя и названия задачи. Также отображается индикатор различия фактической трудоемкости от плановой. Вы можете отфильтровать задачи по версиями, исполнителю и типу задачи.Используйте этот отчет для анализа времени затраченного участниками на задачи, на сколько точно соответствует плановая трудоемкость фактической, а также для сравнения эффективности работы различных участников.
Внизу отчета отображается суммарная плановая и фактическая трудоемкость по задачам, а также подсчитывается коэффициент отклонения. Если у кого-то из участников коэффициент отклонения положительный и сильно отличается от остальных участников, то это повод задуматься над эффективностью работы данного участника.
Отчет по затраченному времени
В данном отчете подсчитывается количество часов, потраченных на каждый день работы в течение заданного месяца. Включите опцию "Отображать задачи", если вам необходимо видеть на какие задачи было потрачено время. Вы можете выгрузить данный отчет в Excel для передачи заказчику.Используйте этот отчет для контроля отработанного времени участниками, если вы ваш проект работает по модели time and materials, либо заказчик требует предоставления подтверждения израсходованных средств.
Данный отчет может использовать и без планирования, для этого в методологии необходимо включить опцию "Участники отчитываются о затраченном времени". При выполнении пожелания можно указать количество затраченных часов.
Статистика
В процессе работы команды над проектом DEVPROM собирает множество статистических показателей, которые характеризуют эффективность вашей команды. Используйте их для анализа текущих проблем в работе команды.
DEVPROM оценивает реальный срок выполнения пожеланий, завершения релиза на основе таких показателей как: скорость команды, доля ошибок в общем объеме работ, погрешность оценки.
При старте проекта скорость команды равна плановой ежедневной загрузке участников проекта, выполняющих задачи. Долю ошибок и погрешность оценки вам необходимо задать самостоятельно из предыдущего опыта (ссылка "Начальные значения статистики"). Однако, в дальнейшем данные показатели постоянно вычисляются на основе реальных данных и оценка срока выполнения каждого нового релиза базируется уже на вычисленных показателях. По сути вам нужно выполнить несколько итераций, чтобы получить достаточно точные значения показателей и в дальнейшем просто их использовать.
Эффективность команды - демонстрирует изменение скорости команды по отношению к ежедневной плановой загрузке участников, тем самым характеризует эффективность использования времени, выделенного на проект и оплаченного заказчиком.
Погрешность оценки объема работ - характеризует на сколько фактический объем работ превысил плановый объем работ. Высокая погрешность говорит о том, что команда сильно ошибается при составлении плана работ и не учитывает сложность задач или дополнительные задачи.
Вовлеченность - доля времени, затраченного в течение итерации данным участником, во времени, затраченном всеми участниками проекта по заданному типу работ. Характеризует насколько разработчики вовлечены в процесс разработки, а тестировщики в процесс тестирования. По этому показателю вы можете определить тех участников, которые не столь эффективны по сравнению с остальными.
Данные показатели позволяют выявлять слабые звенья в вашей команде и своевременно принимать меры, повышать эффективность участников.
Число задач, отклоненных при тестировании показывает качество работы каждого участника.
DEVPROM оценивает реальный срок выполнения пожеланий, завершения релиза на основе таких показателей как: скорость команды, доля ошибок в общем объеме работ, погрешность оценки.
- Скорость команды - объем работ, выполняемый командой за день.
- Доля ошибок в общем объеме работ - процентное отношение ошибок в общем объеме работ по релизу или итерации, характеризует насколько много времени проекта тратится на исправление ошибок, что характеризует качество работы вашей команды.
- Погрешность оценки - характеризует на сколько фактический объем работ по пожеланиям превысил оценку трудоемкости по пожеланиям. Величина этого показателя в целом никак не характеризует команду, поскольку оценку вы можете проводить в любых величинах, однако, используется для вычисления реального срока выполнения пожеланий на основе той оценки трудоемкости, которую дает команда.
При старте проекта скорость команды равна плановой ежедневной загрузке участников проекта, выполняющих задачи. Долю ошибок и погрешность оценки вам необходимо задать самостоятельно из предыдущего опыта (ссылка "Начальные значения статистики"). Однако, в дальнейшем данные показатели постоянно вычисляются на основе реальных данных и оценка срока выполнения каждого нового релиза базируется уже на вычисленных показателях. По сути вам нужно выполнить несколько итераций, чтобы получить достаточно точные значения показателей и в дальнейшем просто их использовать.
Эффективность команды - демонстрирует изменение скорости команды по отношению к ежедневной плановой загрузке участников, тем самым характеризует эффективность использования времени, выделенного на проект и оплаченного заказчиком.
Погрешность оценки объема работ - характеризует на сколько фактический объем работ превысил плановый объем работ. Высокая погрешность говорит о том, что команда сильно ошибается при составлении плана работ и не учитывает сложность задач или дополнительные задачи.
Вовлеченность - доля времени, затраченного в течение итерации данным участником, во времени, затраченном всеми участниками проекта по заданному типу работ. Характеризует насколько разработчики вовлечены в процесс разработки, а тестировщики в процесс тестирования. По этому показателю вы можете определить тех участников, которые не столь эффективны по сравнению с остальными.
Статистика по участникам проекта
По каждому участнику вы можете получить статистику по его скорости работы и динамике ее изменения. Динамику изменения выработки и вовлеченности участника. Выработка - это отношение времени, затраченного в течение итерации, ко времени, которое должно быть затрачено за итерацию, исходя из ежедневной загрузки участника.Данные показатели позволяют выявлять слабые звенья в вашей команде и своевременно принимать меры, повышать эффективность участников.
Число задач, отклоненных при тестировании показывает качество работы каждого участника.
Файлы
Размещайте файлы, которыми часто пользуется команда в общем доступе, на закладке "Файлы". Вы можете создавать собственную структуру каталогов, загружать файлы и сопоставлять с ними версию продукта, к которой относится данный файл. Это могут быть исходные требования, различные документы для анализа, документы по тестированию, бинарные файлы и т.п.
Свободное место на сервере отображается индикатором "Объем дискового пространства". Если некоторый файл устарел, то вы можете переместить его в архив. DEVPROM отслеживает изменения в файлах и рассылает почтовое уведомление. Таким образом, каждый участник проекта находится в курсе появления новых файлов или изменений.
Модели, документы проектирования и подобные файлы вы можете размещать в требованиях или базе знаний. Для этого необходимо перейти на нужный раздел и добавить файл.
Свободное место на сервере отображается индикатором "Объем дискового пространства". Если некоторый файл устарел, то вы можете переместить его в архив. DEVPROM отслеживает изменения в файлах и рассылает почтовое уведомление. Таким образом, каждый участник проекта находится в курсе появления новых файлов или изменений.
Модели, документы проектирования и подобные файлы вы можете размещать в требованиях или базе знаний. Для этого необходимо перейти на нужный раздел и добавить файл.
Управление поддержкой
Поддержка программного продукта бывает разной, но в целом она отличается от полноценного процесса разработки, например, в части планирования, которое переходит от подробной декомпозиции деятельности команды в качественную плоскость: необходимо в очередном обновлении исправить такие-то ошибки и реализовать небольшие доработки.
DEVPROM позволяет изменить настройки проекта таким образом, чтобы отключить работу с итерациями и задачами, назначаемыми на участников, и превратить поведение DEVPROM в обычный баг-трекер (issue tracker). Для этого необходимо в методологии отключить опцию: "Использовать планирование задач".
Если поддержкой продукта занимается больше одного человека, то имеет смысл использовать возможность распределения пожеланий по участникам проекта, для этого необходимо в методологии включить опцию: "Закреплять ответственного за пожеланием". Это позволит назначать пожелания на участников команды для выполнения, то есть планировать их реализацию упрощенным способом - без создания итераций и задач.
Если при этом вам необходимо видеть отчетность по затраченному времени, то убедитесь, что опция "Участники отчитываются о затраченном времени" в настройках методологии включена. При выполнении пожелания участники смогут вводить затраченное время, а DEVPROM - предоставлять отчет о затраченном времени по проекту на каждого участника. Более того, появляется возможность списывать затраченное время по каждому пожеланию, таким образом, например, тестировщик сможет указать, сколько он затратил время на проверку пожелания.
DEVPROM позволяет изменить настройки проекта таким образом, чтобы отключить работу с итерациями и задачами, назначаемыми на участников, и превратить поведение DEVPROM в обычный баг-трекер (issue tracker). Для этого необходимо в методологии отключить опцию: "Использовать планирование задач".
Если поддержкой продукта занимается больше одного человека, то имеет смысл использовать возможность распределения пожеланий по участникам проекта, для этого необходимо в методологии включить опцию: "Закреплять ответственного за пожеланием". Это позволит назначать пожелания на участников команды для выполнения, то есть планировать их реализацию упрощенным способом - без создания итераций и задач.
Если при этом вам необходимо видеть отчетность по затраченному времени, то убедитесь, что опция "Участники отчитываются о затраченном времени" в настройках методологии включена. При выполнении пожелания участники смогут вводить затраченное время, а DEVPROM - предоставлять отчет о затраченном времени по проекту на каждого участника. Более того, появляется возможность списывать затраченное время по каждому пожеланию, таким образом, например, тестировщик сможет указать, сколько он затратил время на проверку пожелания.
Типовой пример
Рассмотрим типовой пример жизненного цикла пожелания, например, исправления ошибки, в процессе поддержки программного продукта. В процессе согласования важности и уточнения приоритета исправления данной ошибки вы договариваетесь о включении пожелания в тот или иной релиз. На этом этапе вы определяете состав очередного обновления.
Каждому участнику проекта может быть назначено пожелание путем планирования. При этом необходимо указать ответственного, уточнить релиз и указать оценку трудоемкости данного пожелания. В правой части страницы отображается burndown диаграмма выбранного релиза и информация о текущей загрузке участников команды.
После исправления ошибки участник выбирает действие "Выполнить" и описывает результаты выполнения, указывает номер версии, в которой исправлена ошибка и при необходимости отмечает затраченное время. Списать время, затраченное на выполнение пожелания, можно и до выполнения действия "Выполнить", при помощи специальной формы, расположенной в правой части страницы при просмотре пожелания.
Выполненные пожелания проверяются тестировщиком или заказчиком и переводится в состояние "Закрыто". Тестировщик также может списать время, потраченное на проверку пожелания. На этом жизненный цикл пожелания заканчивается.
Каждому участнику проекта может быть назначено пожелание путем планирования. При этом необходимо указать ответственного, уточнить релиз и указать оценку трудоемкости данного пожелания. В правой части страницы отображается burndown диаграмма выбранного релиза и информация о текущей загрузке участников команды.
После исправления ошибки участник выбирает действие "Выполнить" и описывает результаты выполнения, указывает номер версии, в которой исправлена ошибка и при необходимости отмечает затраченное время. Списать время, затраченное на выполнение пожелания, можно и до выполнения действия "Выполнить", при помощи специальной формы, расположенной в правой части страницы при просмотре пожелания.
Выполненные пожелания проверяются тестировщиком или заказчиком и переводится в состояние "Закрыто". Тестировщик также может списать время, потраченное на проверку пожелания. На этом жизненный цикл пожелания заканчивается.
Возможности Enterprise версии
Далее в этом разделе вы найдете информацию о тех возможностях DEVPROM, которые доступны в Enterprise (корпоративной) версии.
Поддержка проектных команд
Для решения рутинных задач по организации и обеспечению поддержки процесса разработки, которыми кому-то нужно заниматься, но нет возможности это делать в те моменты, когда это нужно, в DEVPROM реализована возможность поддержки проектных команд. Вот несколько примеров подобных задач:
Каждый член команды или внешний пользователь может обратиться с запросом к администратору, отследить состояние своего запроса и получить уведомления по факту его выполнения. Поскольку DEVPROM автоматизирует различные виды процессов, то самым простым и логичным способом организации процесса обработки запросов является использование самого DEVPROM, то есть специального проекта по администрированию, реализующего простую тикет-систему (систему обработки заявок или систему поддержки). При этом администратор и пользователи получают следующие возможности:
Для того, чтобы использовать эту возможность, вам необходимо перейти к настройкам системы в разделе "Администрирование" и затем перейти по ссылке "создать проект", расположенной в описании поля "Проект по администрированию". После этого DEVPROM автоматически создаст проект по администрированию. Теперь пользователи системы смогут создавать заявки администратору системы, о появлении которых он будет уведомляться по электронной почте.
- Предоставить новому пользователю доступ в систему управления проектами, кому писать, кого просить, у кого есть права на эту операцию?
- Добавить нового участника в проект, например, представителя заказчика, в тот момент, когда у координатора или менеджера проекта нет доступа к системе.
- Установить в систему нужный плагин, выполнить некоторый настройки, разобраться с проблемами в доступе внешних пользователей и т.п.
Каждый член команды или внешний пользователь может обратиться с запросом к администратору, отследить состояние своего запроса и получить уведомления по факту его выполнения. Поскольку DEVPROM автоматизирует различные виды процессов, то самым простым и логичным способом организации процесса обработки запросов является использование самого DEVPROM, то есть специального проекта по администрированию, реализующего простую тикет-систему (систему обработки заявок или систему поддержки). При этом администратор и пользователи получают следующие возможности:
- Регистрация запросов в проекте по администрированию с формы логина (для новых пользователей), при переходе по недоступной ссылке (например из-за отсутствия необходимых прав доступа), при работе с проектом при помощи меню быстрых ссылок "создать" (например, для включения нужного пользователя в проект).
- Просмотр новых запросов, установка отметки о выполнении, просмотр своих запросов, отклонение и удаление запросов.
- Обсуждение запросов при помощи комментариев, получение почтовых уведомлений об изменении параметров или состояния запроса.
Для того, чтобы использовать эту возможность, вам необходимо перейти к настройкам системы в разделе "Администрирование" и затем перейти по ссылке "создать проект", расположенной в описании поля "Проект по администрированию". После этого DEVPROM автоматически создаст проект по администрированию. Теперь пользователи системы смогут создавать заявки администратору системы, о появлении которых он будет уведомляться по электронной почте.
Анализ загрузки ресурсов
Для эффективного анализа текущей загрузки участников проектов, контроля за превышением планового (оплачиваемого) времени работы сотрудников и планирования потребностей компании в специалистах определенного профиля вы можете использовать функциональность анализа загрузки ресурсов.
Основные возможности
Доступны следующие варианты построения таблицы ресурсов:
Используется двухцветное заполнение ячеек таблицы загрузки ресурсов:
|    |
Использование таблиц загрузки ресурсов
В зависимости от потребностей в анализе загрузки ресурсов вы можете выбрать подходящий срез данных:- На закладке "Загрузка ресурсов" отображается общая картина по всем сотрудникам компании или участникам команды.
- При переходе по ссылке с именем сотрудника отображается страница пользователя, на которой представлена информации по загрузке именно этого сотрудника:
- Проекты в которых он принимает участие.
- Роли в которых он принимает участие в проектах.
- Общая загрузка пользователя на всех проектах, в которых он принимает участие.
- Внутри каждого проекта на закладке "Участники" отображается загрузка участников на данном проекте. Используйте эту информацию для выравнивания загрузки ресурсов внутри проекта.
Объединение данных из нескольких проектов
В разработке относительно больших приложений, заказных решений, адаптируемых под нескольких заказчиков, либо в разработке решений, созданных на основе базовых компонент, задействовано большое число участников, с отличающимися целями, задачами и интересами. По сути вы можете иметь дело с несколькими проектами, у которых есть смежные интересы.
Типичные ситуации:
По данной схеме чаще всего устроены проекты по кастомизации (адаптации) некоторого базового решения, настраиваемого или дорабатываемого под нужды конкретного заказчика.
Теперь команда любого проекта, к которому подключен технологический проект имеет быстрый доступ к:
В случае обнаружения ограничений в функциональности или интерфейсе компонентов, команда-пользователь дублирует свои пожелания в проекте по поддержке технологического компонента и отслеживает статус дубликатов для того, чтобы планировать сроки выхода собственных релизов, зависимых от выхода очередной версии компонента.
Иерархия проектов
 | Для реализации этой схемы к корневому проекту добавляются связанные дочерние проекты, которые могут экспортировать информацию об участниках, требования к своим продуктам, либо просто предоставлять возможность создания и отслеживания состояния пожеланий. С другой стороны, в каждый дочерний проект из корневого можно экспортировать базу знаний, в которой перечислены основные цели программы или условия работы с заказчиком, перечень базовых нефункциональных требований, выставленных заказчиком ко всем решениям и т.д.
Характерной чертой такой схемы является экспорт артефактов из корневого проекта в дочерние проекты и в меньшей степени - импорт информации об участниках или пользовательской документации из дочерних проектов в корневой. |
Типичные ситуации:
- Программа проектов. Обычно под программой проектов понимают набор из нескольких проектов, объединенных общими целями, иногда, общим интересом со стороны одного заказчика. В каждом из проектов программы могут разрабатываться независимые приложения или решения, либо частично пересекающиеся и интегрируемые.
- Поддержка продуктов для одного заказчика. Цель проекта поддержки заключается в организации единой точки управления ожиданиями заказчика. Все пожелания внутри проекта поддержки дублируются в проектах соответствующих продуктов и тем самым отслеживается и контролируется решение запросов заказчика.
- Единая служба поддержки. При передаче реализованного продукта в поддержку, заказчику сообщается адрес единой службы поддержки, через которую осуществляется взаимодействие пользователей с разработчиками. Часть проблем могут решать специалисты службы поддержки, используя базу знаний или пользовательскую документацию дочерних проектов. Другую часть проблем они передают на анализ и решение непосредственно в дочерние проекты.
- Модульная разработка. Крупное решение часто делится на несколько относительно независимых модулей, либо компоненты, отличающиеся по технологии разработки: сервер приложения и база данных. В каждом модуле происходит уточнение исходных требований под специфику данного модуля.
Звезда (кастомизация решения)
| В этой схеме один (центральный) проект связывается с несколькими другими (независимыми) проектами, которые базируются на артефактах и результатах центрального проекта. Центральный проект экспортирует свою базу знаний, требования, тестовую и пользовательскую документацию, бинарный и исходный код. Таким образом, проекты наращивают или адаптируют функционал центрального проекта под нужды своих пользователей или заказчиков. Проекты инициируют необходимые им изменения в центральном проекте путем создания дубликатов пожеланий и отслеживают статус этих зависимостей в соответствии со своими сроками.
Характерной чертой такой схемы является экспорт практически всех артефактов из центрального проекта во внешние проекты. |  |
По данной схеме чаще всего устроены проекты по кастомизации (адаптации) некоторого базового решения, настраиваемого или дорабатываемого под нужды конкретного заказчика.
Сеть (технологический актив)
 | Практически любая команда разработчиков имеет свой набор библиотек или технологий, которые она повторно использует в очередном проекте. Таким образом, проекты собираются из некоторых общих технологических элементов, на базе которых реализуется требуемая функциональность. Таким компонентом может быть и некая стандартная библиотека или framework, с которыми команда познакомилась достаточно хорошо и собрала массу полезной и уникальной информации.
Поскольку к технологическому компоненту постоянно предъявляются новые требования, область его применения расширяется и изменяется, то разумно выполнять доработку и поддержку компонента в рамках проекта, для которого есть своя база знаний, набор требований, тестовая и пользовательская документация, бинарные или исходные коды. Проект по поддержке технологического компонента включается (связывается) со всеми проектами, в которых используются его результаты. В настройках связи с технологическим проектом вы указываете экспорт базы знаний, блога проекта, пользовательской документации и файлов. |
Теперь команда любого проекта, к которому подключен технологический проект имеет быстрый доступ к:
- новостям технологического компонента: когда планируется новая версия, какие изменения были выполнены в новой версии, что вообще происходит в проекте
- базе знаний технологического проекта: как использовать компонент, какие есть особенности применения и другая полезная информация, которую участники технологического проекта старательно собирают в своей базе знаний.
- пользовательской документации, где описаны программные интерфейсы.
- релизам очередных версий компонентов, которые можно использовать при сборке продукта.
В случае обнаружения ограничений в функциональности или интерфейсе компонентов, команда-пользователь дублирует свои пожелания в проекте по поддержке технологического компонента и отслеживает статус дубликатов для того, чтобы планировать сроки выхода собственных релизов, зависимых от выхода очередной версии компонента.
Работа с Wiki
Wiki - это общепризнанный и простой способ организовать совместную работу с документацией в сети, что так важно для успешного выполнения проекта. Wiki используется для ведения базы знаний проекта, формирования требований, технической и справочной документации, а также для написания тестовых сценариев. Данные артефакты представляют собой деревья Wiki-страниц.
Добавление страниц
Wiki-страницы, то есть разделы документа, представлены в виде дерева. Для добавления новой страницы необходимо нажать на иконку, расположенную в секции "Разделы" на правой вспомогательной панели.
В зависимости от типа артефакта новые страницы могут подразделяться на разделы, требования, тестовые наборы и тестовые сценарии. Раздел представляет собой просто некоторый текст или дополнительный уровень вложенности, то есть не является требованием или тестовым набором.
При создании новой страницы вам необходимо указать ее название (заголовок), порядковый номер, по которому будут соритроваться страницы, расположенные на одном уровне дерева. При необходимости вы можете выбрать шаблон, при этом содержимое вашей страницы автоматически заполнится текстом из шаблона. Это удобно, если вы хотите создавать стандартные разделы требований (например, прецедент) или тестовых случаев. Шаблоны также являются wiki-страницами и доступны для создания и изменения на закладке для работы с конкретным артефактом.
Перед тем как сохранить страницу вы можете посмотреть как она будет выглядеть, для этого на панели инструментов нажмите кнопку с галочкой (предварительный просмотр).
Если вам необходимо перенести некоторую страницу в другое место в иерархии страниц, то вызовите ее на редактирование, измените родительскую страницу и сохраните страницу.
В зависимости от типа артефакта новые страницы могут подразделяться на разделы, требования, тестовые наборы и тестовые сценарии. Раздел представляет собой просто некоторый текст или дополнительный уровень вложенности, то есть не является требованием или тестовым набором.
При создании новой страницы вам необходимо указать ее название (заголовок), порядковый номер, по которому будут соритроваться страницы, расположенные на одном уровне дерева. При необходимости вы можете выбрать шаблон, при этом содержимое вашей страницы автоматически заполнится текстом из шаблона. Это удобно, если вы хотите создавать стандартные разделы требований (например, прецедент) или тестовых случаев. Шаблоны также являются wiki-страницами и доступны для создания и изменения на закладке для работы с конкретным артефактом.
Перед тем как сохранить страницу вы можете посмотреть как она будет выглядеть, для этого на панели инструментов нажмите кнопку с галочкой (предварительный просмотр).
Если вам необходимо перенести некоторую страницу в другое место в иерархии страниц, то вызовите ее на редактирование, измените родительскую страницу и сохраните страницу.
История изменений
По каждой странице в дереве сохраняется история изменений, так что вы всегда будете в курсе кто, что и когда изменил в тексте требования или тестового набора, а также при необходимости сможете откатить изменения.
Ссылка для отображения истории изменений находится в правом верхнем углу области с текстом раздела. Зеленым фоном подсвечиваются измененные или добавленные строки, а красным - удаленные, то есть предыдущие.
При работе с требованиями особенно важно контролировать содержание требования и следить за его изменениями. Каждый раздел требования может согласовываться с заказчиком, при этом вся история изменений состояний раздела требований также видна на странице с историей изменения. Более того, при модификации подписанного раздела требования, всем участникам проекта отсылается почтовое уведомление с историей изменений, так что вся команда будет в курсе изменений и сможет своевременно на него отреагировать.
Ссылка для отображения истории изменений находится в правом верхнем углу области с текстом раздела. Зеленым фоном подсвечиваются измененные или добавленные строки, а красным - удаленные, то есть предыдущие.
При работе с требованиями особенно важно контролировать содержание требования и следить за его изменениями. Каждый раздел требования может согласовываться с заказчиком, при этом вся история изменений состояний раздела требований также видна на странице с историей изменения. Более того, при модификации подписанного раздела требования, всем участникам проекта отсылается почтовое уведомление с историей изменений, так что вся команда будет в курсе изменений и сможет своевременно на него отреагировать.
Язык разметки
Для стилистического оформления wiki-страниц, а также для добавления таблиц и изображений, используется разметка, то есть специальные символы, которыми окружается оформляемый текст. При просмотре такой страницы появляются курсив, выделение жирным шрифтом, списки и т.п.
Синтаксис языка разметки всегда у вас находится под рукой - с правой стороны от редактируемой страницы. Для использования простой разметки вы можете применять панель инструментов, расположенную над редактируемым текстом.
Для оформления заголовков используйте символ "h", после которого должна следовать цифра от 1 до 6, соответствующая важности заголовка.
Для построения списков, используйте символ "#" для нумерованных списков и символ "*" - для точечных. При необходимости вы можете добавить второй уровень списка.
Таблицы оформляются путем разделения столбцов символом "|" (вертикальная черта), то есть сначала вы задаете заголовок, а затем на каждой новой строке заполняете ячейки таблицы.
Для того, чтобы добавить в текст страницы изображение, введите тэг image, укажите название изображения и сохраните страницу. При ее просмотре название изображения будет подчеркнуто пунктиром, а рядом будет расположен знак вопроса - это означает, что изображение еще не прикреплено к странице. Нажав на вопрос откроется форма загрузки изображения, где вы выбираете файл и сохраняете изменения. После этого изображение появится на wiki-странице. При необходимости вы можете легко изменить изображение нажав на иконку редактирования, расположенную под изображением. Вы можете добавить подпись к изображению (атрибут text) и указать ширину изображения (атрибут width). Указывать ширину изображения важно, если вы добавляете к странице изображение большого размера, чтобы оно не вылезало за границы страницы.
Для того, чтобы оставлять в тексте ссылки на разделы или другие объекты системы используйте тэг page, в качестве параметра вы можете указать название страницы или ее идентификатор. При просмотре страницы тэг превратится в ссылку на указанную страницу.
Полный перечень возможностей языка разметки смотрите на вспомогательной панели, расположенной справа в режиме создания или редактирования страницы. Там вы найдете примеры использования тех или иных тэгов.
Синтаксис языка разметки всегда у вас находится под рукой - с правой стороны от редактируемой страницы. Для использования простой разметки вы можете применять панель инструментов, расположенную над редактируемым текстом.
Для оформления заголовков используйте символ "h", после которого должна следовать цифра от 1 до 6, соответствующая важности заголовка.
Для построения списков, используйте символ "#" для нумерованных списков и символ "*" - для точечных. При необходимости вы можете добавить второй уровень списка.
Таблицы оформляются путем разделения столбцов символом "|" (вертикальная черта), то есть сначала вы задаете заголовок, а затем на каждой новой строке заполняете ячейки таблицы.
Для того, чтобы добавить в текст страницы изображение, введите тэг image, укажите название изображения и сохраните страницу. При ее просмотре название изображения будет подчеркнуто пунктиром, а рядом будет расположен знак вопроса - это означает, что изображение еще не прикреплено к странице. Нажав на вопрос откроется форма загрузки изображения, где вы выбираете файл и сохраняете изменения. После этого изображение появится на wiki-странице. При необходимости вы можете легко изменить изображение нажав на иконку редактирования, расположенную под изображением. Вы можете добавить подпись к изображению (атрибут text) и указать ширину изображения (атрибут width). Указывать ширину изображения важно, если вы добавляете к странице изображение большого размера, чтобы оно не вылезало за границы страницы.
Для того, чтобы оставлять в тексте ссылки на разделы или другие объекты системы используйте тэг page, в качестве параметра вы можете указать название страницы или ее идентификатор. При просмотре страницы тэг превратится в ссылку на указанную страницу.
Полный перечень возможностей языка разметки смотрите на вспомогательной панели, расположенной справа в режиме создания или редактирования страницы. Там вы найдете примеры использования тех или иных тэгов.
Различные представления
Вы можете использовать различные представления дерева wiki-страниц с целью передать подготовленные требования в виде отдельного файла для согласования с внешними участниками проекта, включить в инсталляцию файл помощи или провести согласование всего текста, разбитого на разделы.
- Просмотр - позволяет просмотреть всю иерархию wiki-страниц на одной странице в браузере, то есть сформировать, передавать и изучать целостный документ.
- Рецензирование - помимо отображения целостного документа позволяет вести обсуждение каждого из разделов этого документа, что удобно при согласовании крупного блока требований.
- Экспорт - позволяет выгружать документ в формате MS Word или HTML. При выгрузке в HTML вы можете определить собственные стили для отображения документа и тем самым сформировать файл справки, содержащий все необходимые стилистические элементы, изображения и т.п.
- Все тэги страниц - позволяет получить перечень тэгов, которые прикреплены к страницам и для каждого тэга посмотреть перечень страниц, которые он объединяет.
- Последние изменения в страницах - отображает перечень измененных страниц в обратном хронологическом порядке, с указанием участника проекта, который создал или изменил страницу.
- Архив - отображает разделы документа, которые помещены в архив. Страницы, помещенные в архив не отображаются в общем дереве wiki-страниц.
FAQ
Здесь мы приводим ответы на типичные вопросы пользователей, которые могут помочь вам быстрее разобраться с системой.
Импорт данных в DEVPROM из других систем
Какие существуют возможности импорта задач и дефектов в DEVPROM из других систем?
Подробная информация о возможностях миграции данных из других систем в DEVPROM изложена в разделе Мягкий переход на DEVPROM.Как импортировать иерархию задач из MSProject?
В DEVPROM используется Agile подход к планированию, который несколько отличается от "классического" подхода, обычно используемого в MSProject: в системе существует общий backlog пожеланий (задачи и дефекты), эти пожелания затем декомпозируются на задачи, которые планируются в одну-две следующие итерации.Таким образом, система не предназначена для учета неограниченного уровня вложенности задач, а так же для детального (!) долгосрочного планирования.
Иерархия в DEVPROM может быть представлена тремя уровнями:
- Функция (может не использоваться) - является элементом группировки пожеланий по некоторому логически выделенному функционалу
- Пожелание (набор пожеланий внутри функции) - основной элемент планирования, содержит в себе краткое описание требуемой доработки системы (идея) или описание ошибки
- Задача (набор задач внутри пожелания, могут не использоваться) - задание на работу, запланированное в конкретной итерации на конкретного исполнителя, с указанием планируемой трудоемкости. Может иметь тип, указывающий фазу работы: анализ, проектирование, разработка, тестирование, другое.