¿Qué tamaño de equipo necesita para beneficiarse del software de seguimiento de errores? [cerrado]

59

Mi equipo de desarrollo acaba de crecer en un 100% (de 1 desarrollador a 2). Mi nuevo grupo quiere invertir en software de seguimiento de errores. ¿Hay beneficios para dicho software para un equipo tan pequeño?

plntxt
fuente
136
Un equipo de uno se beneficia del software de seguimiento de errores.
Dominique McDonnell
55
Es posible que desee probar FogBugz Student and Startup Edition, muy fácil y conveniente de configurar y usar ( fogcreek.com/fogbugz/StudentAndStartup.html ).
Maxim Zaslavsky
2
incluso un equipo de <1 persona necesita software de seguimiento de errores ...
vrdhn
55
@Vardhan ¿Un equipo de menos de una persona? ¿Como un equipo inexistente?
Ikke
2
@Ikke ... como una persona que trabaja en múltiples proyectos ... y sigue olvidando lo que se debe hacer en múltiples proyectos ... ¡la llamada de gestión es 0.5 recurso!
vrdhn

Respuestas:

51

Creo que todas las respuestas de "sí" contribuyen en gran medida a respaldar la idea. Pero voy a descartar la idea de que la decisión se basa en algunas preguntas:

  • ¿Cómo quieres comunicarte como equipo? Con 2 desarrolladores, ahora eres un equipo. ¿Cómo quieres comunicarte? Muchos equipos ágiles viven con debates en persona y bocetos de pizarra. Pero también pueden llegar a escribir cosas, especialmente si es un error que no estará en la lista de prioridades por un tiempo.
  • ¿Cómo quieres comunicarte con tus clientes? No sé la respuesta a esto, pero si tienes alguna razón para publicar errores (o errores corregidos en un documento de versión), terminarás por escribirlos eventualmente. También podría elegir un sistema de gestión de errores de bajo estrés y acabar de una vez.
  • ¿Hay valor para preservar la historia? La respuesta puede ser "no en este momento", pero si cree que en el futuro, le gustaría ver la tendencia de los errores para que pueda ver los lugares en los que los usuarios tienen más problemas, o los lugares donde podría pasar algún tiempo revisando y revisar antes de un lanzamiento importante, luego obtenga un sistema de seguimiento de errores. Lo importante del historial es que el día que desea el registro no es el día en que debe comenzar a mantener registros.

En mi opinión, las respuestas a estas preguntas son más sobre dónde ve el producto y cómo desea hacer crecer su equipo y menos sobre si "2 personas = razón para el sistema de seguimiento de errores". La pregunta más importante es probablemente "¿vale la pena configurar y gestionar un sistema de seguimiento de errores y el costo de compra?"

bethlakshmi
fuente
Muy bien puesto! ¡Elija una herramienta que optimice la forma en que quiere trabajar! De lo contrario, ¡use un panel de corcho!
Andres Jaan Tack
79

1, pero solo si es indoloro. GitHub, por ejemplo, tiene un gestor de incidencias muy simple y utilizable con más que suficientes características para un equipo pequeño. Bugzilla, Trac u otros son buenos, pero todos requieren hardware, instalación y configuración antes de su uso, y el mantenimiento es definitivamente un gasto distinto de cero.

l0b0
fuente
66
Bugzilla probablemente se puede instalar en un servidor virtual por un costo bastante mínimo.
Zachary K
2
Trac tampoco requiere mucho mantenimiento. He tenido una instancia de Trac ejecutándose aproximadamente 2 años seguidos y nunca he tenido que mantener nada aparte de agregar nuevos proyectos.
cuál es
2
Sé que ambos son fáciles de mantener, el punto es más bien que es un "gasto distinto de cero", es decir, no es gratuito. Tal vez unas pocas horas al año si desea instalar parches de seguridad, o unos días si necesita migrar desde una versión anterior o su hardware muere.
l0b0
El gasto de instalación no es cero, pero si se usa bien será mucho menor que las ganancias de tenerlo.
BillThor
2
No olvides BitBucket para esos usuarios de hg.
sholsinger
41

Tuvimos un equipo muy pequeño la primera vez que utilicé el software de seguimiento de errores y me sorprendió la cantidad de cosas que habíamos pensado que necesitábamos arreglar que de alguna manera nunca se arreglaron. Vale la pena, no importa cuán grande sea su equipo.

revs HLGEM
fuente
Puedo relacionarme totalmente con esto. Justo ayer perdí mi cuaderno donde escribí algunos errores que necesitaban reparación. Ahora tendré que perder otras dos horas repasando el área problemática. Voy a descargar Bugzilla o algo así.
3
Buen punto. La investigación psicológica dice que las personas pueden mantener ~ 7 elementos en su memoria a corto plazo. Si tiene más de ~ 7 elementos en la lista de tareas, el seguimiento de errores es una buena idea. Si los está escribiendo de todos modos, puede hacerlo de manera escalable y sistemática (no es mucho más esfuerzo).
dbkk
27

Si. Mil veces si.

Ni siquiera lo pienses en términos de seguimiento de errores, sino como seguimiento de tickets.

Poder ver todas sus tareas en los tickets tiene una gran ventaja. Puede mantener un historial de una tarea en un solo lugar. Sabes quién trabajó en eso y cuándo. Puede ser tan detallado como decir qué se completó en qué día para una tarea.

Para el seguimiento de errores, puede colocar todos sus errores en un solo lugar y realizar un seguimiento de los que se han completado y los que aún están en progreso.

Simplemente te ayuda a manejar las cosas mucho mejor.

Tyanna
fuente
+1 por mencionar el seguimiento del "ticket". Sería estúpido almacenar solo errores en un sistema de este tipo, si puede usarlo también como lista de
tareas
En serio, debe vincular el seguimiento de errores a su sistema de control de revisiones. Entonces todos los cambios tienen una razón revisable. Y tienes que tener un RCS de algún tipo. No usar ambos es como ir a trabajar sin pantalones.
Tim Williscroft
Sí, no lo llamen seguimiento de "error". Lo llamamos seguimiento de "tarea", ya que un error es una tarea, pero una tarea no es necesariamente un error.
Carson63000
16

Vale la pena con un equipo de uno o más.

Acéptelo, ya sea que compre una solución de software formal o no, tendrá un sistema de seguimiento de errores / funciones. Puede estar en el bloc de notas, puede ser notas adhesivas, puede estar en un bloque de comentarios en la parte superior de su código. Sin embargo, a menos que esté desarrollando al azar, anotará sus listas de tareas en algún lugar. ¿Por qué no utilizar un sistema más organizado que pueda crecer con su equipo?

También vale la pena considerarlo: muchos de los rastreadores de errores son gratuitos para equipos muy pequeños (1-2), por lo que no es como si incurriera en un gasto importante para el beneficio.

JohnFx
fuente
13

No necesita ningún software de seguimiento de errores siempre que cada miembro del equipo

  • Tiene una memoria fotográfica perfecta y
  • Puede sincronizar sus pensamientos con todos los demás miembros del equipo.
Andy Lester
fuente
11

La respuesta corta es sí.

Algunas razones por las cuales:

  1. Capacidad para registrar errores que se han encontrado en versiones específicas.
  2. Capacidad para saber qué errores (conocidos) aún no se han corregido.
  3. Rastree quién solucionó un error que desde entonces se ha encontrado nuevamente.
  4. Rotación de desarrolladores: permite la transferencia de conocimiento incluso si te golpean con el bus proverbial.

Es probable que desee ver algo que no le tomará mucho tiempo configurar / administrar. También sugeriría buscar algo que incluya esa capacidad de integrarlo con su control de fuente.

Ken Henderson
fuente
8

Esta respuesta es agregar peso al lado del argumento.

Soy principalmente un equipo de uno. Uso ampliamente el seguimiento de problemas (redmine) junto con la integración SVN.

Es realmente excelente y me volvería loco sin él; mi calidad disminuiría porque me olvidaría de las cosas y perdería la noción de lo que tengo que trabajar.

Herramientas de productividad:

  • IDE decente
  • Seguimiento de problemas
  • Fuente de control

Seguimiento de problemas; no salgas de casa sin ella

Richard Harrison
fuente
4

Si tienes menos de 3, probablemente puedas sobrevivir con una hoja de cálculo de Google Docs, tal vez, supongo. Pero realmente el costo de instalar bugzilla o similar en algún lugar es tan trivial al lado del costo de un programador que es mejor que lo haga. (Además, cuando crezcas a 7 ya estará allí)

Zachary K
fuente
2

Incluso un equipo de uno puede beneficiarse de algún tipo de rastreador de errores, ya sea un archivo de texto de notas o algún software completo. Para 2 desarrolladores, recomendaría solo invertir tiempo en configurar un sistema de seguimiento de errores, no dinero. Dependiendo del proyecto, puede salir bien escribiendo errores en papel, manteniendo una lista a través de un documento compartido en línea o utilizando un software gratuito de seguimiento de errores como Trac o Bugzilla. Fogbugz también está disponible como prueba gratuita durante 45 días.

Jeff
fuente
1

Si.

¡Necesitas rastrearlos de alguna manera!

El problema es cuántos errores tienes en lugar de cuántos desarrolladores. Puede manejar una hoja de Excel cuando se trata de algunos errores, pero aun así no es la mejor.

Imbéciles
fuente
1

Hay define benifet: uso el software de seguimiento de errores incluso en proyectos personales. Es útil no solo para rastrear errores, sino también para rastrear 'TODOS' y solicitudes de funciones.

Jimmy Collins
fuente
0

He usado errores en todas partes cuando trabajo solo. Funciona con su DVCS al mantener la información del error junto con su fuente. Muy baja sobrecarga ya que no requiere servidor central. La desventaja es que debe tener cuidado en las ramas en las que ingresa nuevos errores para asegurarse de que se propaguen de manera oportuna, aunque puede no importar mucho si en su mayoría desea rastrear sus propios errores y lo que se corrigió en su último tirón, más bien que rastrear el estado de un equipo como un todo.

Karl Bielefeldt
fuente
0

Solo comienza a usar uno

Si comienza a usar uno, comenzará a darse cuenta de su conveniencia en la práctica, al igual que el software de control de versiones o, para el caso, el control de versiones distribuido.

Desarrollo madurez

No importa si tiene un equipo de 100 o 1, comencé a usar el seguimiento de errores y el control de versiones distribuidas (tiene mucho sentido debido a los compromisos locales) solo para mí y para mí y ya me sentí en otro nivel, pero no solo eso, podría manejar mi trabajo a otro nivel ... a un nivel que podría escalar sin que invierta más esfuerzo.

Al usar un rastreador puede anticipar problemas y priorizar el trabajo, los rastreadores de errores / problemas no son solo para errores / problemas, son más para la administración del proyecto, y todos y cada uno de los proyectos deberían tener eso .

dukeofgaming
fuente
0

Para mí no se trata solo del software, sino del proceso que lo rodea. En mi trabajo diario como administrador de pruebas, básicamente vivo en uno y proporciona los siguientes beneficios:

Creo que esto funciona muy bien con 2+ probadores y 3+ desarrolladores.

Gestión de los esfuerzos de corrección de errores del desarrollador.

Gestionamos activamente una "cola de errores" de los desarrolladores para controlar la cantidad de trabajo que les han asignado y asegurarnos de que tengamos una asignación de nivel de trabajo de corrección de errores en todo el equipo.

Decidir qué se arregla y qué no

Probar nuevos errores en un proceso diario es una excelente manera de ayudar a enfocarse en lo que hace y no repara, así como también cuando lo arregla. Al principio de un proyecto, quieres arreglar todo. Al final solo quieres arreglar los stoppers de show, y la herramienta de seguimiento de errores es ideal para eso

Cuando necesitas métricas

Lo más importante para mí son las métricas, es decir, cuando desea poder ver la búsqueda de errores y corregir tendencias, dónde están las áreas de código con errores, o qué tan rápido los probadores están encontrando y volviendo a probar errores. Es hora de un sistema de seguimiento de errores.

Bruce McLeod
fuente
0

Estoy de acuerdo con la opinión común de que un miembro del equipo es suficiente para comenzar a necesitar un rastreador de errores. Lo caracterizaría como obligatorio después de que tenga uno o dos usuarios reales, pero importante antes de su primer lanzamiento.

Personalmente, me gustan los fósiles tanto para el control de fuente como para el seguimiento de errores. Es un SCM completo de baja ceremonia distribuido que está bien integrado a un rastreador de errores y un wiki. Y es una instalación ejecutable única, ampliamente portátil, y utiliza una aplicación web interna como su GUI. Su página de inicio en realidad es servida casi en su totalidad por una copia de fósiles.

Con el rastreador estrechamente integrado con el control de revisiones, puede vincular fácilmente los cambios a los tickets y ver las actualizaciones de los tickets en la misma vista de línea de tiempo que las revisiones (y las ediciones de la página wiki).

RBerteig
fuente
-1

¡Si si SI SI! Ser capaz de rastrear, priorizar y administrar sus problemas es clave para el desarrollo exitoso de software. Con una persona, puede (casi) salirse con una hoja de cálculo y comprimir los viejos árboles fuente. Agregar incluso un desarrollador a un proyecto cambia las cosas drásticamente: de repente, el seguimiento de problemas y el control del código fuente son necesarios, o se van a caer problemas, sobrescribir la funcionalidad y, en general, pasar un mal momento.

Me sorprende que nadie haya mencionado la compañía matriz de StackExchange, FogCreek, todavía. Su software FogBugz es la mejor aplicación de seguimiento de problemas que he usado. Alta velocidad, baja resistencia y asequible, especialmente si utiliza su solución alojada. Solían tener una versión de prueba alojada gratuita que, creo, tenía dos licencias de usuario gratuitas, puede que ese ya no sea el caso, pero recomiendo comprobarlo.

usuario18782
fuente
-1

Aquí están mis 2 centavos.

para el seguimiento de errores, solo uso una hoja de cálculo de google-doc, puedo invitar a cualquiera que quiera editar o verla. es gratis, así que no es una gran inversión. Realizo un seguimiento de todas las tareas allí solo para errores.

También ejecuto SVN en mi servidor web que no agrega ningún costo adicional al alojamiento web.

Algunos clientes han requerido el uso de Unuddle u otro software de gestión de proyectos / seguimiento de errores, pero preferiría las soluciones gratuitas que menciono anteriormente.

usuario18794
fuente
-1

Si tiene un rastreador de errores minimalista, diría que es útil incluso para un equipo de uno. En uno de los sitios de proyectos de mi amigo QuokForge , proporcionan básicamente una instancia de Red Mine para cada proyecto. Red Mine, en mi opinión, tiene un buen rastreador de errores (aunque a veces sea un poco extraño). Principalmente porque puede presentar un error ingresando solo texto en UN campo. También he usado FogBugz antes. Es gratis para 2 o menos personas. Y permite la misma simplicidad, presentando un error al completar un solo campo de texto. (También proporciona gráficos y otras cosas que son increíblemente útiles)

Básicamente, no haga que la presentación de errores sea un proceso estricto y formal que requiera que reserve 30 minutos para completar un informe de error (BugZilla, lo estoy mirando). Esto solo significa que la gente no lo usará.

Finalmente, tener una lista de errores (incluso si todo lo que contiene contiene aproximadamente 50 caracteres de texto) es extremadamente valioso. "Hmm, a punto de lanzar la versión 1.0. Creo que arreglé el último de los errores". Y también es genial para los gerentes ver que en realidad estás haciendo algo :). En un equipo, es más valioso porque ambos no están tratando de mantener un conjunto diferente de listas de tareas mentales en su cabeza. Y soluciona el problema "¿Arreglaste ese [error de seguridad realmente malo]? Um, sí, así lo creo. Ok, vamos a liberar 1.0 entonces".

También me encanta hacer un seguimiento de las características también. Esto es un poco más opcional, pero todavía encuentro beneficios de poder descargar la tarea mental de mantener una lista de tareas pendientes en mi cabeza.

Además, vea lo que Joel tenía que decir al respecto

Earlz
fuente
-1

Acabas de llegar a ese número ... 2 ! Si bien puedo ver los beneficios de usar el software de seguimiento de errores, incluso si usted es el único desarrollador ... puede sobrevivir sin él cuando el número total de desarrolladores es 1.

Sin embargo, tan pronto como tenga dos o más desarrolladores, no hay una sola razón para no tener un software de seguimiento de errores, ni uno solo.

usuario18806
fuente
-1

Si. Y una recomendación es bitbucket http://www.bitbucket.org Proporcionan un seguimiento de errores gratuito, así como repositorios privados gratuitos en mercurial.

basarat
fuente
-1

Uno. En cuyo caso es más como una lista de tareas pendientes.

Supongo que invirtiendo significa tiempo. Hay muchos sistemas gratuitos de seguimiento de errores, lo que debería estar bien para un equipo de dos personas. No buscaría ofertas comerciales hasta tener un equipo más grande.

Adán
fuente
-1

Creo que su pregunta ha resaltado su idea errónea. Porque no es el equipo el que necesita el seguimiento de errores, es el producto (s).

Entonces, ¿el seguimiento de errores debe hacerse en el software? Bueno, eso ayudaría, ¿no te parece?

Lee Kowalkowski
fuente
-1

Puede que no valga la pena si las siguientes dos condiciones están presentes:

  1. Los problemas tienen una corta vida útil. En este caso, podría ser suficiente con un tablero de tareas simple (ya que es inteligente visualizar el flujo de trabajo por muchas otras razones). Sin embargo, si no puede resolver los problemas rápidamente, p. Ej. corrigiendo errores rápidamente, le resultará útil rastrear el problema.
  2. Los cambios en el código se documentan con pruebas automatizadas como documentación viva. Es decir, los errores y las correcciones se documentan con las pruebas fallidas cuando aparecen, y las pruebas aprobadas se convierten en pruebas de regresión después de la corrección. - Y los cambios de funcionalidad se documentan con pruebas de aceptación automatizadas (por ejemplo, usando alguna herramienta BDD como FitNesse o Cucumber). Dicha documentación debería estar fácilmente disponible desde un servidor CI como Jenkins.

Si 1 o 2 no están presentes, se beneficiará del seguimiento de problemas.

Ingvald
fuente
-5

No

No rastree los errores, corríjalos .

Lo que importa no es el tamaño del equipo, es cuánto tiempo está dispuesto a mirar los errores en una lista antes de corregirlos.

Si está utilizando Agile / TDD, su lista de errores será corta y los errores no permanecerán en la lista por mucho tiempo. Cualquier sistema de seguimiento será suficiente en ese caso.

Steven A. Lowe
fuente
[Solo tenía que decir algo para contrarrestar todas las respuestas sin respuesta]
Trufa
2
¿Cómo recuerdas que se solucionó el error? ¿Cómo recuerdas que no te perdiste un error antes de hacer un lanzamiento?
Earlz
2
Lo siento hombre, parece que estás tratando de hacer un punto, pero es discutible.
dukeofgaming
2
@ Steven: ¿Alguna vez ha tenido un producto con un número de instalaciones de 7 dígitos? Ninguna cantidad de TDD evitará que varios miles de usuarios presenten errores, y mucho menos varios millones. Puede que ni siquiera sean errores reales que se deben corregir en su extremo, pero aún tendrá que mirarlos, cerrar duplicados, señalar a los clientes las soluciones a los originales, etc. Si es una empresa unipersonal, tiene que recurrir a lápiz / papel, Excel, su propia base de datos, o simplemente usa algún software hecho para esto.
sbi
2
@ Steven: Mis habilidades psíquicas no logran ver tan lejos las necesidades no declaradas de Jim (y ciertamente no hay nada en la pregunta que indique su interpretación).
sbi