Creo que todas las respuestas "sí" ayudan mucho a respaldar la idea. Pero voy a desechar la idea de que la decisión se basa en algunas preguntas:

• ¿Cómo desea comunicarse en equipo? Con 2 desarrolladores, ahora es un equipo. ¿Cómo quieres comunicarte? Un montón de equipos ágiles viven con discusiones en persona y bocetos de pizarra. Pero también pueden ir tan lejos como para escribir cosas, especialmente si se trata de un error que no estará alto en la lista de prioridades por un tiempo.
• ¿Cómo desea comunicarse con sus clientes? No conozco la respuesta a esto, pero si tiene algún motivo para publicar errores (o corregir errores en un documento de versión), entonces Voy a terminar anotándolos eventualmente. También podría elegir un sistema de gestión de errores de bajo estrés y terminar con él.
• ¿Existe algún valor para conservar el historial? La respuesta puede ser "no en este momento", pero si piensa que en el futuro, le gustaría ver la tendencia de los errores para poder ver los lugares donde están los usuarios. teniendo la mayoría de los problemas, o lugares donde podría pasar un tiempo revisando y revisando antes de un lanzamiento importante, y luego obtenga un sistema de seguimiento de errores. Lo que pasa con la historia es que el día que desea el registro no es el día en que debe comenzar a llevar registros.

OMI, las respuestas a estas preguntas son más acerca de dónde ve el producto y cómo quiere que crezca su equipo y menos acerca de si "2 personas = razón para el sistema de seguimiento de errores". Probablemente, la pregunta más importante es "¿vale la pena un tiempo para configurar y gestionar el sistema de seguimiento de errores y el costo de compra?"

1, pero solo si es indoloro. GitHub, por ejemplo, tiene un rastreador de problemas muy simple y útil con más que suficiente features 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 usé el software de seguimiento de errores y me sorprendió la cantidad de cosas que habíamos pensado que debíamos solucionar, que de alguna manera nunca se solucionaron. Vale la pena, no importa cuán grande sea tu equipo.

  

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

1

Sí. Mil veces sí.

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

Ser capaz de ver todas sus tareas en tickets tiene una gran ventaja. Puedes mantener un historial de una tarea en un solo lugar. Sabes quién trabajó en ello 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 hacer un seguimiento de los que se han completado y de los que todavía están en progreso.

Simplemente te ayuda a manejar las cosas mucho mejor.

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

Enfréntelo, ya sea que compre una solución de software formal o no, tendrá un sistema de seguimiento de errores / características. 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 solo estés desarrollando al azar, estarás anotando tus listas de tareas pendientes en algún lugar. ¿Por qué no usar un sistema más organizado que pueda crecer con su equipo?

También vale la pena considerar: muchos de los rastreadores de errores son de uso gratuito para equipos muy pequeños (1-2), por lo que no es como si estuvieras incurriendo en ningún gasto importante para el beneficio.

No necesita ningún software de seguimiento de errores mientras 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 que:

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 solucionado.
3. Haga un seguimiento de quién corrigió un error que ya se ha encontrado de nuevo.
4. Volumen de negocios del desarrollador: permite la transferencia de conocimientos, incluso si te golpean en el bus proverbial.

Probablemente querrá ver algo que no le llevará mucho tiempo configurar o administrar. También sugeriría buscar algo que incluya esa capacidad para integrarlo con su control de código fuente.

Esta respuesta es para agregar peso al lado SÍ del argumento.

Soy sobre todo 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 eso; mi calidad bajaría porque me olvidaría de las cosas, y perdería el rastro de lo que tengo que trabajar.

Herramientas de productividad:

• IDE decente
• Seguimiento de problemas
• control de fuente

Seguimiento de problemas; no salgas de casa sin él

Si tienes menos de 3, probablemente puedas arreglártelas con una hoja de cálculo de Google docs, tal vez, supongo. Pero en realidad, 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 algún sistema de seguimiento de errores, no dinero. Dependiendo del proyecto, puede hacerlo 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.

Sí.

¡Necesitas seguirlos de alguna manera!

El problema es cuántos errores tienes en lugar de cuántos desarrolladores. Puede gestionar con una hoja de Excel cuando se trata de algunos errores, pero incluso entonces no es el mejor.

Hay un benifet definido: uso software de seguimiento de errores incluso en proyectos personales. Es útil no solo para el seguimiento de errores, sino también para el seguimiento de las TODO y las solicitudes de funciones.

He utilizado errores en todas partes cuando trabajo solo. Funciona con su DVCS manteniendo la información de error junto con su fuente. Sobrecarga muy baja 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 propagan de manera oportuna, aunque puede que no importe mucho si desea rastrear sus propios errores y lo que se solucionó en su último intento. que rastrear el estado de un equipo en su conjunto.

Simplemente comienza a usar uno

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

Madurez del desarrollo

No importa si tiene un equipo de 100 o 1, comencé a usar el seguimiento de errores y el control de versiones distribuido (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 administrar mi trabajo en otro nivel ... a un nivel que podría escalar sin que yo invirtiera 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 de proyectos, y todos y cada uno de los proyectos deben 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 ofrece los siguientes beneficios:

Encuentro que esto funciona muy bien con 2+ testers y 3+ desarrolladores.

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

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

Decidir qué hace y qué no se soluciona

La detección de nuevos errores en un proceso diario es una excelente manera de ayudar a concentrarse en lo que hace y no soluciona, así como cuando lo soluciona. Al principio de un proyecto, quieres arreglar todo. Al final, solo desea reparar los paradores de programas, y la herramienta de seguimiento de errores es excelente para eso

Cuando necesite métricas

Lo importante para mí son las métricas, es decir, cuando desea poder ver las tendencias de búsqueda y corrección de errores, dónde están las áreas con errores del código o la rapidez con la que los evaluadores encuentran y vuelven a probar los 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 tener uno o dos usuarios reales, pero muy importante antes de su primer lanzamiento.

Personalmente, me gusta fósil tanto para el control de origen como para el seguimiento de errores. Es un SCM distribuido de ceremonia baja completo que está bien integrado a un rastreador de errores y una 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 está servida casi en su totalidad por una copia de un fósil.

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

Sí, sí, sí, sí! Ser capaz de rastrear, priorizar y administrar sus problemas es clave para el desarrollo exitoso de software. Con una sola persona, puede (casi) escapar con una hoja de cálculo y cerrar los viejos árboles de origen. Agregar un solo desarrollador a un proyecto cambia las cosas drásticamente; de repente, es necesario el seguimiento de los problemas y el control del código fuente, o de lo contrario, se eliminarán los problemas, se sobrescribirá la funcionalidad y, en general, se pasará un mal momento.

Me sorprende que nadie mencione a la empresa matriz de StackExchange, FogCreek, sin embargo, su software FogBugz es la mejor aplicación de seguimiento de problemas que he usado. Alta velocidad, bajo arrastre y asequible, especialmente si utiliza su solución alojada. Solían tener una versión de prueba gratuita que, según creo, tenía dos licencias de usuario gratis, tal vez ya no sea así, pero recomiendo que lo revise.

aquí están mis 2 centavos.

para el seguimiento de errores, solo uso una hoja de cálculo de google-doc, puedo invitar a cualquier persona que quiera editar o ver. Es gratis por lo que no es una gran inversión. Realizo un seguimiento de todas las tareas allí para corregir errores.

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

algunos clientes han requerido el uso de un software de gestión de proyectos / seguimiento de fallos de gestión de proyectos, pero prefiero las soluciones gratuitas que mencioné anteriormente.

Si tienes 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 un poco extraño a veces). Es decir, porque puede presentar un error solo ingresando texto en UN campo. También he usado FogBugz antes. Es gratis para 2 o menos personas. Y permite la misma simplicidad, archivando un error al completar solo un campo de texto. (También proporciona gráficos y otras cosas que son increíblemente útiles)

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

Finalmente, tener una lista de errores (incluso si todos los errores contienen cada uno de unos 50 caracteres de texto) es extremadamente valioso. "Hmm, a punto de lanzar la versión 1.0. Creo que corregí 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 intentan mantener en su mente un conjunto diferente de listas de tareas mentales. Y corrige el mensaje "¿Arreglaste ese [error de seguridad realmente malo]? Um, sí, lo PIENSO. Ok, vamos a lanzar la versión 1.0".

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

También, vea lo que Joel dijo 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 ... usted 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, no uno.

Sí. Y una recomendación es bitbucket enlace . Proporcionan seguimiento gratuito de errores, así como depósitos gratuitos privados en mercurial.

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

Supongo que al invertir tu tiempo. Hay un montón de sistemas gratuitos de seguimiento de errores por ahí, que deberían estar bien para un equipo de dos personas. No buscaría ofertas comerciales hasta que tuviera un equipo más grande.

Creo que tu pregunta ha resaltado tu error. 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 crees?

Puede que no valga la pena si se presentan las dos condiciones siguientes:

1. Los problemas tienen una vida útil corta. En este caso, podría ser suficiente con un panel 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, 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 viviente. Es decir, los errores y las correcciones se documentan con 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, utilizando alguna herramienta BDD como FitNesse o Cucumber). Dicha documentación debería estar fácilmente disponible desde un servidor de CI como Jenkins.

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

No

No rastree errores, corríjalos .

Lo que importa no es el tamaño del equipo, es el tiempo que estás dispuesto a ver 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.