Стратегия компонента JIRA

Question

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

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

Существует ли лучшая практика для определения того, как разделить проект на компоненты? Являются ли такие вещи, как «Пользовательский интерфейс» и «Безопасность» слишком широкими?

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

Answer 1

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

Answer 2

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

Answer 3

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