Отслеживание проблем: какие типы проблем для чего (т.е. Задача, новая функция)?

Ответ 1

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

Для нового проекта все должно быть отмечено как Задача ПЕРЕД доставкой в ​​первый раз.

После того, как вы доставили что-то, все последующие элементы работы могут быть отмечены соответствующим образом:

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

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

Надеюсь, это поможет вам.

Ответ 2

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

В нашей компании мы используем 3 разных инструмента в зависимости от типа проблемы:

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

Определения, которые мы приводили для разных типов рабочих элементов (Полярион) или выпусков (JIRA):

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

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

Итак, чтобы подвести итог:

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

Ответ 3

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

Разработка (т.е. предварительная подготовка)

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

Продукция

• Инцидент: нарушение ожидаемого обслуживания; может иметь отношение "много к одному" с дефектами.
• Дефект: что-то, препятствующее достижению артефакта по назначению (два подтипа)
  • Ошибка выполнения: артефакт не соответствует спецификациям.
  • Дефект требований: спецификации не дают желаемого результата.
• Запрос на изменение: изменение спецификации
  • Новая функция: увеличение объема программного обеспечения
  • Улучшение: улучшение качества программного обеспечения (производительность и т.д.)
  • Adaptive: изменение из-за внешних условий окружающей среды (например, изменение баз данных и т.д.).
• Запрос на обслуживание: запрос на предоставление предварительно согласованного сервиса (пароль reset и т.д.)
• Непрограммная задача: элемент действия, не изменяющий программное обеспечение (документация, обучение пользователей, миграция данных и т.д.).

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

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