Uso de software de seguimiento de errores / seguimiento de problemas para discutir preguntas de diseño, nuevas herramientas, etc.

¿Alguien tiene experiencia con el uso de un software de seguimiento de errores / seguimiento de problemas como bugzilla, mantis o JIRA no solo para errores o tareas, sino para iniciar y mantener discusiones que al final conducen a una decisión?

Por ejemplo, un desarrollador piensa que todos los campos protegidos deben ser abolidos y cambiados a campos privados con métodos protegidos que accedan a ellos. No es su llamado, y le gustaría discutirlo. Normalmente, saca a relucir el punto en la próxima reunión de desarrolladores al final de la cual se toma una decisión. En cambio, mi idea era que él abriera un problema de un cierto tipo de "decisión" y describiera su intención como normalmente describiría un error o una tarea.

Otros desarrolladores pueden hacer sus comentarios si lo desean, y al final, el problema se cierra como "aceptado" o "negado".

Las ventajas que veo en esto:

• Comunicación asincrónica: nadie se ve obligado a expresar su opinión en una reunión cuando aún no tuvo tiempo de supervisar todas las ramificaciones de dicha decisión.
• Registro escrito de consideraciones que conducen a una decisión. Si luego se vuelve a plantear esa pregunta, se le puede remitir a ella.
• Se pueden establecer relaciones con otros temas, por ejemplo, una tarea se puede seguir hasta una decisión.
• La integración con el software de control de versiones, p. Ej., Un commit puede rastrearse hasta una decisión.

Desventajas

• Olor fuerte de un martillo dorado: el software de seguimiento de problemas normalmente se usa para rastrear elementos procesables
• Los gastos generales de la organización pueden ser desproporcionados: en lugar de una pequeña charla informal, uno tiene que comunicar sus ideas por escrito

La forma en que trabajamos, el seguimiento de problemas debe realizar un seguimiento de todos los problemas. No sabemos qué problemas son procesables hasta que se haya analizado. Si el sistema de seguimiento solo tiene problemas procesables, es probable que estén siendo evaluados demasiado pronto, lo que significa que se pierden las discusiones y la decisión. Tomamos el enfoque que todo debe seguir (en nuestro flujo de trabajo de todos modos), ya que de lo contrario los problemas pueden surgir repetidamente sin visibilidad.

Tenemos una categoría en nuestra implementación de Jira para "Riesgo", por lo que estamos usando Jira para rastrear elementos que no son procesables, pero que tienen la capacidad de poner en peligro el software de alguna manera. Se realiza un seguimiento de la discusión sobre el elemento y una vez que el riesgo desaparece (o se mitiga), el problema se cierra. El ejemplo que ha dado podría entrar fácilmente en la categoría Riesgo.

Es importante que cosas como esta sean discutidas y rastreadas, y la decisión registrada. Cuando el desarrollador vuelve a plantear el problema dentro de unos meses, la respuesta "Preguntado y respondido" tiene una justificación.

Corrígeme si estoy equivocado; pero creo que de lo que estás hablando es: "¿Puede / Cómo usar el seguimiento de errores / Sistemas de seguimiento de problemas para hacer también 'Seguimiento de decisiones'? ¿Es o me estoy perdiendo algo?

Al principio, diría que esta es una gran idea. Aunque no lo usamos exactamente de la misma manera, tiene sentido que lo usemos con el propósito de rastrear. En nuestro caso, un largo hilo de correo electrónico, más a medida que se sigue un foro / lista de correo.

Sin embargo, su pregunta en un sentido más amplio es sobre cómo tomar (y administrar) decisiones de manera efectiva y conectar las implicaciones del trabajo con las decisiones tomadas que brindan mejores conocimientos.

Como dije, puede ser una gran idea si eso ayuda a las personas. No tiene nada de malo. Pero para tomar / gestionar decisiones de manera efectiva se necesitan pocas cosas concretas.

1. Es cierto que la mayoría de las decisiones deben ser un esfuerzo inclusivo de base amplia para que todos los aspectos importantes se cubran y se consideren adecuadamente antes de basar las decisiones. Entonces, cualquier herramienta que use debe haber habilitado el acceso transparente a la información para todos los interesados. Tiene razón en que el modo asincrónico de transmisión y recopilación de información ayuda porque las personas pueden pasar el tiempo antes de hacer sugerencias. Si se le solicitan respuestas por adelantado , generalmente en las reuniones, el juicio podría no ser igualmente sólido en comparación con la misma persona con suficiente tarea.

2. Sin embargo, esto no significa necesariamente "democracia pura" donde cada voto es igual. En general, la persona que toma las decisiones debe ser una o pocas, y aunque han tomado todas las opiniones, deben ser individualmente responsables de las decisiones y no todas las personas que expresaron sus opiniones.

3. La mayoría de las decisiones deben ser procesables. Esto puede resultar difícil de evitar contradicciones; pero el hecho de que las decisiones no sean accionables y solo subjetivas significa que hay posibilidades para futuras (malas) interpretaciones.

4. Es importante clasificar el nivel y el alcance de la decisión. Lo más importante es que debemos identificar si estamos discutiendo un problema de diseño específico o un aspecto específico del código, un aspecto de los procesos o si estos son temas relacionados con la planificación y el seguimiento del proyecto. Muy a menudo, cuando surgen problemas de un código de producción, todos estos son aplicables, pero debemos ser capaces de distinguir todos los aspectos diferentes e independientemente para poder gestionar estas decisiones de manera efectiva.

5. Algunas veces las decisiones pueden ser si usamos ciertos sistemas o roles y responsabilidades para los individuos; Puede ser difícil poner estas decisiones junto con la codificación de decisiones específicas en un foro de tipo tablón de anuncios.

6. Solo unas anécdotas adicionales; cada equipo debe poner las revisiones de código y las revisiones de diseño como un proceso en sí mismo, lo que cubrirá exhaustivamente muchos problemas como el ejemplo que usted citó. Son imprescindibles independientemente de si las decisiones siguen o no tratos con otras cosas.

Las buenas prácticas para la toma de decisiones implican mucha disciplina sobre cómo reunir la información y asegurar que las decisiones se sigan con las implementaciones con el espíritu adecuado.

Una herramienta solo puede ayudar a hacer que la información sea más presentable, no más allá de eso; pero eso podría ser una buena ayuda si te funciona.

FogBugz es el camino a seguir. No es gratis Las características más recientes hacen que implementar una metodología ágil sea aún más fácil.

Una manera más simple y libre de ir sería Asana.

No importa qué herramienta utilice, la comunicación del equipo es la más importante para facilitar un proyecto exitoso.