¿Existen estudios sobre las desventajas de usar sistemas de seguimiento de problemas? [cerrado]

9

No me gustan los sistemas de seguimiento de problemas porque:

Lleva demasiado tiempo describir los problemas que contiene. Esto desalienta su uso.
Creas un lugar para guardar tus errores. Y si hay un lugar para ellos, a las personas generalmente no les importa demasiado arreglar un error porque pueden ponerlo allí para que algún día alguien pueda arreglarlo (o no).
Con el tiempo, las listas de errores se alargan tanto que ya nadie puede lidiar con ellas, lo que nos quita mucho tiempo.

Prefiero manejar problemas usando post-its en una pizarra, conversaciones cara a cara y matando errores importantes tan pronto como aparezcan. No me importa demasiado hacer un seguimiento del historial de errores porque no creo que valga la pena la sobrecarga.

¿Estoy solo aquí? ¿Existen estudios (libro / artículo / lo que sea) sobre las desventajas (o grandes ventajas) de usar sistemas de seguimiento de problemas?

project-management agile issue-tracking

— usuario1062120
fuente

55

Votación para cerrar, demasiado localizada. El problema aquí no parece ser con los sistemas de seguimiento de problemas, sino con el proceso de manejo de errores en la empresa.

— P.Brian.Mackey

1

¿Qué sistemas de seguimiento de problemas ha probado (aparte de las notas y las pizarras)? ¿Cuál fue el proceso en torno a su uso?

— FrustratedWithFormsDesigner

1

De esos, solo he usado Jira (estoy de acuerdo en que parece tener muchos gastos generales, hasta que te acostumbras a su "ritmo"). No soy fanático de la interfaz de usuario web, pero hace el trabajo. Aquí, también usamos MKS, que también controla la fuente. Es mejor que Jira. Ninguno de ellos es perfecto, pero todos son mejores que las notas en papel y los recuerdos orgánicos falibles de las personas.

— FrustratedWithFormsDesigner

15

Creo que estoy confundido por la pregunta. El uso de post-its en una pizarra blanca es un sistema de seguimiento de problemas. Si su proyecto / equipo / base de código es lo suficientemente pequeño y post-its + funciona cara a cara, probablemente le resulte difícil convencerse de agregar más sobrecarga al proceso. Hay muchos inconvenientes para usar un sistema como ese, como se indica a continuación. Tan pronto como el proyecto y el equipo crecen, especialmente cuando los miembros del equipo pueden no estar en el mismo edificio, ciudad o país, otros sistemas comienzan a brillar como se indica en las respuestas a continuación.

— s_hewitt

2

¿Cómo adjuntar un seguimiento de pila a una publicación? o una captura de pantalla? o un mensaje de error?

— jk.

41

Lleva demasiado tiempo describir los problemas que contiene. Esto desalienta su uso.

Si ni siquiera puede describir un error, ¿cómo puede comenzar a solucionarlo?

Creas un lugar para guardar tus errores. Y si hay un lugar para ellos, a las personas generalmente no les importa demasiado arreglar un error porque pueden ponerlo allí para que algún día alguien pueda arreglarlo (o no).

Ese es un problema con su equipo, no con el software.

Con el tiempo, las listas de errores se alargan tanto que ya nadie puede lidiar con ellas, lo que nos quita mucho tiempo.

Nuevamente estás describiendo un problema con tu equipo.

El objetivo del software de seguimiento de errores no es ayudarlo a motivar a su equipo a corregir errores, es mantener un registro para que pueda rastrear la causa de los errores y evitar que vuelvan a suceder. Ningún software será nunca un reemplazo para una buena gestión.

— Tom Squires
fuente

El software de seguimiento también ayuda a realizar un seguimiento de los errores para corregir. Una nota adhesiva puede caerse, y si cuatro personas se acercan a ti con errores en los que puedes trabajar en ese momento, podrías arreglar tres y olvidar el cuarto. Es útil incluso si no prestas atención a las causas de los errores.

— David Thornley el

y para solucionar el problema con su equipo, puede usar gamification -> en.wikipedia.org/wiki/Gamification

— marc.d

11

@JoaoBosco: los boletos escritos a mano se pierden, se garabatean, se tiran por accidente ... las conversaciones cara a cara son geniales, excepto cuando se describen errores complejos a personas que no tienen memoria fotográfica. La gente se olvide de las cosas de las conversaciones, no porque quieran, sino porque eso es simplemente lo que sucede.

— FrustratedWithFormsDesigner

3

@JoaoBosco: ¿Qué pasa con las capturas de pantalla de los errores de la GUI? ¿Los volverás a dibujar a mano? Muestras de salida de datos incorrecta (si se trata de un error en la base de datos, ¿está preparado para escribir n filas con m columnas de datos incorrectos a mano)? ¿Otras formas de artefactos digitales asociados con el defecto que simplemente no se traducen bien en notas adhesivas? Todo eso se puede conectar fácilmente a un ticket en un sistema de seguimiento de problemas. Y si luego va a convertir su nota adhesiva en archivos de texto, ¿por qué no una base de datos que le permite ordenar, ordenar y clasificar sus tickets, y luego un poco más para el seguimiento de problemas?

— FrustratedWithFormsDesigner

10

@ user1062120: "Si no hay lugar para guardar errores, las personas comienzan a corregirlo con más frecuencia", o comienzan a ignorar y olvidar los errores. No es un "truco para motivar a las personas" sino un intento absurdo de volver a etiquetar una debilidad en una fortaleza.

— Michael Borgwardt

12

OMI, su punto de partida está sesgado. Si los desarrolladores no corrigen los errores, el proyecto está condenado al fracaso, ya sea que rastreen los errores utilizando una herramienta adecuada de seguimiento de errores, post-its, tallados en piedra o no. No es culpa de la herramienta si no se usa o se usa incorrectamente. (Dicho esto, por supuesto, hay rastreadores de errores / problemas por ahí ... Trabajé en un proyecto usando una herramienta totalmente inadecuada para este trabajo, así que creo que sé lo malo que puede ser. Pero también hay otros buenos, que requieren una ceremonia mínima y gastos generales, lo que le permite concentrarse en la información relevante).

Sin embargo, si a los desarrolladores les importa, y el proyecto es más grande que un tamaño trivial, y hay más de un solo desarrollador, y hay algún tipo de gestión involucrada (todo lo cual es bastante común en proyectos del mundo real ), pronto surgirán preguntas como:

¿Cuál de los errores abiertos debe corregirse primero? (nota: en un proyecto sensato, esto debe decidirlo el propietario y / o la administración del producto, NO un desarrollador, ¡para lo cual deben estar al tanto de todos los errores abiertos en primer lugar!)
¿Cuántos errores abiertos tenemos y de qué gravedad?
¿Cuál de estos debe arreglarse antes de que estemos listos para lanzar?
¿Cuánto tiempo para planificar estas correcciones?
¿Cuántos errores han sido reportados por los clientes en la última versión?
¿Quién solucionó este error y cuándo, y qué cambios (código / configuración / datos) implicó la solución?
¿Qué correcciones de errores se incluyen en el lanzamiento que estamos a punto de publicar?
...

¿Puede responder a esas preguntas [actualización] de forma repetida, confiable y eficiente [/ actualización] en función de sus notas post-it?

Sí, ingresar datos de errores en un rastreador de problemas implica una sobrecarga. Sin embargo, está más que compensado por el tiempo y el esfuerzo ahorrados al buscar y crear informes como los anteriores, a partir de los datos de errores almacenados.

— Péter Török
fuente

Los post-it no responderán todo. Es solo una herramienta. Todavía puede priorizarlos, hacer estadísticas sobre errores abiertos, reparados, etc. Todo lo que digo es que creo que los sistemas de seguimiento de problemas pueden ser más contraproducentes que ayudarlo a solucionar los problemas de administración que tiene.

— usuario1062120

77

@ user1062120: Y todo lo que todos los demás dicen es que estás muy, muy equivocado. Los post-it son un sistema de seguimiento de problemas, solo uno muy pobre que carece de muchas características esenciales.

— Michael Borgwardt

@ user1062120, por supuesto, en teoría, todo esto podría responderse con notas adhesivas: si agrega identificaciones únicas a cada una, continúe agregando comentarios detallados del historial sobre ellas (por lo que comienza a necesitar notas adhesivas bastante grandes después de un tiempo :-), y Pase una cantidad de tiempo horrible clasificándolas, reorganizándolas y reorganizándolas de acuerdo con la pregunta actual (para lo cual es posible que necesite contratar a un nuevo tipo en un proyecto más grande ;-).

— Péter Török

@ user1062120, por ejemplo, la planificación produce la Pregunta 1 anterior: reorganicemos las notas adhesivas según la prioridad. Pronto PM pregunta Q2: oops, reorganícelos por gravedad. Pero Q1 aún está abierto, así que ahora ordenemos todos de nuevo por prioridad. Vaya, se dejaron 3 post-it porque estaban en el escritorio de Joe. ¡Comienza de nuevo! Luego P6: busquemos las cajas que almacenan publicaciones históricas, hojeemos todas a mano para encontrar la correcta, luego intentemos leer el garabato en su parte posterior, con la intención de describir los cambios ... ¡Uy, alguien abrió un ventana cercana, apúrate para evitar que tus post-it escapen por el viento ... etc.

— Péter Török

9

Su metodología puede funcionar para proyectos muy pequeños con un número limitado de programadores. Una vez que un proyecto se hace más grande, tener un sistema de seguimiento de problemas se vuelve mucho más importante para la coordinación entre los diferentes equipos, especialmente si las soluciones se publicarán en diferentes versiones de código. Los proyectos complejos tendrán muchas partes / componentes móviles, y garantizar que los problemas estén programados y reparados es una gran parte de una buena implementación de seguimiento de problemas

Algunos artículos / estudios que pueden interesarle incluyen este artículo sobre el uso de Jira por parte de Zend y este estudio francés sobre el uso de sistemas de seguimiento de errores.

— JW8
fuente

1

Muchas gracias por las referencias. Los echaré un vistazo. Y sí, está trabajando dentro de 3 equipos pequeños aquí.

— user1062120

2

+1 para las referencias, que fueron solicitadas explícitamente en la pregunta.

— mattnz

4

Puede haber estudios, pero aún mejor son las experiencias duramente ganadas de las personas en el campo. La mayoría de los sistemas de seguimiento de problemas sufren los procesos que impulsan su diseño. Los rastreadores de problemas a menudo necesitan admitir 2 clases distintas de usuarios:

El equipo de desarrollo
Los usuarios del sistema.

Cal Henderson (anteriormente de Flickr) tiene una gran publicación sobre el diseño de muchos rastreadores de problemas y por qué prefiere el rastreador de problemas de GitHub (al igual que yo). Además, Garrett Dimon cubrió el diseño de Sifter e ilustró una forma de simplificar el proceso para un seguimiento de problemas más efectivo . Adopté algunas de las ideas de ambas publicaciones para ayudar a simplificar el flujo de trabajo de seguimiento de problemas de mi equipo.

Dicho todo esto, todavía se reduce a las personas sobre el proceso y las herramientas. Mi opinión general es que los rastreadores de problemas tienden a crear este atraso que debes administrar. Durante la selección, es más probable que las personas racionalicen lo que es o no un error. En nuestro proceso, tomamos decisiones casi tan pronto como se presenta el error sobre si se trata o no de un problema. Una vez que se toma esa decisión, el error entra en Pivotal Tracker. La diferencia aquí es que usamos el Rastreador para la priorización , no como un bolígrafo para las cosas que no queremos hacer. De hecho, cuando el Icebox comienza a crecer demasiado, elimino activamente elementos, incluidos los errores. Si un problema es lo suficientemente grande como para ser manejado, volverá a surgir.

Raramente necesitamos un historial de errores. Ocasionalmente, alguien puede mencionar un síntoma de un error y podemos hacer una búsqueda para ver si está relacionado con algún problema que ya hemos solucionado. Pero eso es raro.

TL; DR Céntrese en su proceso, elija herramientas simples y aborde los problemas a medida que surjan.

— kstewart
fuente

Eso es exactamente lo que quise decir. También damos prioridad a los elementos tan pronto como aparecen y también eliminamos elementos no importantes. Lo importante volverá en el tiempo. Descubrí que los gastos generales para realizar un seguimiento de todo no son dignos. La idea de tener una pequeña pizarra blanca es que físicamente no puede registrar todo, solo lo importante. Entonces este truco te obliga a manejarlo lo antes posible. Pero ese es mi caso, así que no estoy seguro de si funcionaría en todas partes.

— user1062120

2

matando errores importantes tan pronto como aparezcan

Parece que estás entrando por la puerta abierta aquí. Los errores importantes se "matan" lo antes posible, sin importar si usa el rastreador de problemas o no.

Ah, y la parte "tal como aparecen" es bastante resbaladiza, por cierto. En un proyecto, tuvimos un error importante que amenazaba con sacar todo el producto del negocio (¿qué podría ser más importante?). Fue muy complicado (error de arquitectura) y sabíamos que tardaría mucho en solucionarlo. Los clientes aceptaron amablemente darnos un año para arreglarlo (antes de dejar nuestro producto) y lo hicimos en aproximadamente un año.

En cuanto a los rastreadores de problemas, los he estado usando durante casi diez años y, por regla general, todos los programadores a mi alrededor pasaron bastante poco tiempo con el rastreador (tenga en cuenta que estoy hablando de programadores; los gerentes son una historia diferente). He visto casos (raramente) cuando no fue así, en todos estos casos algo se rompió severamente.

Con respecto a los estudios sobre conversaciones cara a cara versus seguimiento de problemas, nuevamente parece que estás entrando por la puerta abierta aquí. El seguimiento de problemas es una comunicación escrita típica ; Hay muchas investigaciones que demuestran que para discutir cosas, la comunicación cara a cara es mucho más eficiente que por teléfono, que a su vez es mucho más eficiente que la escrita .

En realidad, dado que preguntas sobre f2f, parece que estás (mal) usando el rastreador para discutir cosas; este no es su propósito. Para calcular su uso previsto, simplemente deletree su nombre lenta y claramente: sistema de seguimiento de problemas .

las listas de errores se alargan tanto

En mi experiencia, lo anterior es una ventaja, no un problema.

Con una larga lista de errores, los desarrolladores pueden configurar una cola y planear soluciones mucho más adelante. Esto es tan productivo como se pone; para mí esto es básicamente un nirvana cuando tengo una cola con la que trabajar. Primer error - corrección - hecho, segundo error - corrección - hecho, siguiente error - corrección - hecho, etc. Sin interrupciones estúpidas, sin distracciones dolorosas con conversaciones f2f tan eficientes, flujo puro .

Solo recuerdo un caso en el que largas listas de errores han sido un problema. Sucedió cuando un idiota de la alta gerencia decidió una política que obligaba a los desarrolladores a elegir el siguiente error de una pila de 50-100 casi a diario. Que desperdicio. Nos tomó algunos meses de dolor hasta que descubrimos cómo escalar esto sobre su cabeza y arreglarlo.
Algún tiempo después de que pudimos establecer un flujo de trabajo conveniente, descubrimos que nuestro "atraso interminable" mágicamente se vació.

— mosquito
fuente

2

Recientemente pasé 2.5 días vadeando más de 300 errores abiertos (en su mayoría, IU) acumulados en más de un año, todos asignados a freelancers / internos hace mucho tiempo, o al gerente del proyecto que no tuvo tiempo para lidiar con ellos. Descubrí que podía cerrar aproximadamente la mitad de ellos como ya arreglados o ya no relevantes. El resto se está arreglando a un ritmo decente después de asignarlos a las personas adecuadas. El sistema de seguimiento de errores se usó mal, pero sin él, todos esos errores (sin obstáculos, pero algunos bastante feos) seguramente habrían sido olvidados.

— Michael Borgwardt

1

@MichaelBorgwardt, sí, las listas siempre que nadie pueda lidiar con eso, en mi experiencia, siempre resultaron manejables siempre y cuando uno no se congele con números de aspecto aterrador como 200, 400, 1000. Solo hice un rápido chequeo por curiosidad: para el año pasado arreglé más de 300 problemas, solo yo (!). Por curiosidad, también revisé a otros muchachos en el equipo pensando que tal vez soy único: no, 200-400 arreglos / año parecen solo una tasa promedio. 500 errores, sin embargo, este aspecto aterrador, puede ser solo medio año de trabajo para 4-5 desarrolladores, pan comido :)

— mosquito