Estrategia del componente JIRA

Question

Recientemente cambié a JIRA de otro sistema de seguimiento de errores, y anteriormente no estábamos usando el campo "componente". El proyecto era bastante pequeño, por lo que no parecía necesitarlo en ese momento. A medida que el proyecto se hace un poco más grande, descubro que el campo de componentes puede ser útil, pero no estoy seguro de cómo dividir los componentes.

Por ejemplo, digamos que tengo una aplicación bancaria y estoy agregando una función para transferir dinero entre cuentas. Esa característica podría clasificarse como un componente de "Cuentas", pero también afectaría a la interfaz de usuario, además de tener algunos problemas de seguridad asociados. Parece que muchos problemas tendrán esta preocupación transversal.

¿Existe una mejor práctica para determinar cómo dividir un proyecto en componentes? ¿Son cosas como "Interfaz de usuario" y "Seguridad" demasiado amplias?

No estoy seguro de si esta pregunta tiene una sola respuesta correcta, por lo que tal vez debería ser trasladada a una wiki de la comunidad, pero cualquier información que las personas puedan proporcionar sería útil aquí.

Answer 1

Los componentes son más útiles si tienen asignados predeterminados obvios para cada uno (cables de componente). Otro enfoque es esperar un tiempo y usar etiquetas. Vea si hay etiquetas comunes que a sus usuarios les gusta usar, y luego cree componentes en unas pocas semanas para esas etiquetas.

~ Matt

Answer 2

Un usuario que crea un error puede agregar varios componentes al informar el problema. Para que puedan seleccionar la cuenta, las transferencias y el problema de seguridad (o Préstamo, pagos y problemas de seguridad) como todos los componentes afectados por un error en particular. Se puede combinar cualquier combinación de componentes para que el equipo de desarrollo sepa exactamente dónde se está produciendo este error.

Answer 3

Utilizamos el campo componente de nuestra empresa sobre todo para agrupar los temas de una manera significativa, por lo que los informes de estos componentes que pueden dar retroalimentación que parte de su desarrollo de aplicaciones consigue la mayoría de los problemas, o donde están ocurriendo la mayoría de los cambios (con la mayoría de los errores resultantes). Algunas veces, los componentes reflejan la organización de un proyecto, luego el aspecto del asignado por defecto es válido (como lo responde @mdoar). Pero incluso entonces, la visión general del proyecto es el aspecto más interesante aquí.