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?

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?"

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.

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.

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.

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.

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.

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.

Esta respuesta es agregar peso al lado SÍ 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

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í)

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.

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.

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.

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.

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 .

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.

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).

¡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.

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.

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

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.

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

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.

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?

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.

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.