Razones para no construir su propio sistema de seguimiento de errores

Question

Varias veces me he enfrentado a planes de un equipo que quiere construir su propio sistema de seguimiento de fallas, no como un producto, sino como una herramienta interna.

Los argumentos que he escuchado en favous son por lo general a lo largo de las líneas de:

• Queriendo 'comer nuestra propia comida para perros' en términos de algún marco web integrado internamente
• necesitar algún informe altamente especializado , o la capacidad de ajustar algún rasgo de alguna manera supuestamente única
• creyendo que no es difícil construir un sistema de seguimiento de errores

¿Qué argumentos que podría utilizar para ayudar a comprar un sistema de seguimiento de errores existente? En particular, ¿qué características suenan fáciles pero resultan difíciles de implementar, o son difíciles e importantes pero a menudo se pasan por alto?

Answer 1

En primer lugar, un vistazo a estos Ohloh métricas:

Trac: 44 KLoC, 10 Person Years, $577,003 
Bugzilla: 54 KLoC, 13 Person Years, $714,437 
Redmine: 171 KLoC, 44 Person Years, $2,400,723 
    Mantis: 182 KLoC, 47 Person Years, $2,562,978 

¿Qué aprendemos de estos números? ¡Aprendemos que construir Yet Another Bug Tracker es una gran manera de desperdiciar recursos!

Así que aquí están mis razones para construir su propio sistema de seguimiento de fallos internos:

1. Es necesario para neutralizar todos los bozocoders para una o dos décadas.
2. Necesita descargar un poco de dinero para evitar la reducción del presupuesto el próximo año.

De lo contrario, no.

Answer 2

El argumento más básico para mí sería la pérdida de tiempo. Dudo que pueda completarse en menos de un mes o dos. ¿Por qué pasar el tiempo cuando hay tantos buenos sistemas de seguimiento de errores disponibles? Dame un ejemplo de una característica que tienes que ajustar y no está disponible.

Creo que un buen sistema de seguimiento de errores tiene que reflejar su proceso de desarrollo. Un proceso de desarrollo muy personalizado es intrínsecamente malo para una empresa/equipo. La mayoría de las prácticas ágiles favorecen a Scrum o este tipo de cosas, y la mayoría de los sistemas de seguimiento de fallas están en línea con tales sugerencias y métodos. No seas demasiado burocrático sobre esto.

Answer 3

Solo diría que es una cuestión de dinero: comprar un producto terminado que sabe que es bueno para usted (y en ocasiones ni siquiera comprarlo si es gratis) es mejor que tener que ir y desarrollar uno por su cuenta. Es un juego simple de pagar ahora contra pagar más tarde.

Answer 4

Me gustaría dar vuelta la pregunta. ¿POR QUÉ en la tierra querrías construir la tuya?
Si necesita algunos campos adicionales, vaya con un paquete existente que pueda modificarse.
¿Informe especial? Toca la base de datos y hazlo.

¿Crees que no es difícil? Prueba entonces Especifíquelo y vea crecer la lista de funciones y horas. Luego, una vez completada la lista, intente encontrar un paquete existente que pueda modificarse antes de implementar el suyo.

En resumen, no reinvente la rueda cuando otra necesite ajustes.

Answer 5

Yo diría que uno de los mayores escollos sería angustioso sobre el modelo de datos/flujo de trabajo. Predigo que esto llevará un tiempo largo e involucro muchos argumentos sobre lo que debería sucederle a un error bajo ciertas circunstancias, lo que realmente constituye un error, etc. En lugar de pasar meses discutiendo de un lado a otro, si solo tiraras con un sistema preconstruido, la mayoría de las personas aprenderá cómo usarlo y aprovecharlo al máximo, independientemente de las decisiones que ya se hayan resuelto. Elija algo de código abierto, y siempre puede modificarlo más adelante si fuera necesario: será mucho más rápido que hacerlo funcionar desde cero.

Answer 6

A los programadores les gusta construir su propio sistema de tickets porque, al haber visto y usado docenas de ellos, saben todo al respecto. De esa manera pueden permanecer en la zona de confort.

Es como visitar un nuevo restaurante: puede ser gratificante, pero conlleva un riesgo. Es mejor pedir pizza de nuevo.

También hay un gran hecho de la toma de decisiones enterrado allí: siempre hay dos razones para hacer algo: una buena y la correcta. Tomamos una decisión ("Desarrollamos la nuestra"), luego la justificamos ("necesitamos control total"). La mayoría de las personas ni siquiera son conscientes de su verdadera motivación.

a cambiar de opinión, hay que atacar la causa real de , no la justificación.

Answer 7

Lo que es más importante, ¿dónde va a enviar los errores para su rastreador de errores antes de que haya terminado?

Pero en serio. Las herramientas ya existen, no hay necesidad de reinventar la rueda. La modificación de las herramientas de seguimiento para agregar ciertas características específicas es una cosa (he modificado Trac antes) ... reescribir uno es simplemente una tontería.

Lo más importante que puede señalar es que si lo único que quieren hacer es agregar un par de informes especializados, no requiere una solución básica. Y además, el ÚLTIMO lugar que importa "su solución de homebrew" es para las herramientas internas. ¿A quién le importa lo que está usando internamente si está haciendo el trabajo como lo necesita?

Answer 8

En este punto, sin una gran nueva dirección en el seguimiento de errores/emisión de tickets, simplemente sería reinventar la rueda. Lo cual parece ser lo que todos los demás piensan, en general.

Answer 9

no inventado aquí síndrome!

construir su propio gestor de fallos? ¿Por qué no crear su propio cliente de correo, herramienta de gestión de proyectos, etc.

Como Omer van Kloeten says en otro lugar, pague ahora o pague después.

Answer 10

Sus discusiones comenzarán con lo que constituye un error y evolucionarán en qué flujo de trabajo aplicar y terminarán con un argumento masivo sobre cómo gestionar proyectos de ingeniería de software. ¿De verdad quieres eso? :-) Nah, pensé que no - ve y compra uno!

Answer 11

Al ser un programador que trabaja en una tarea que ya es crítica (o menos, importante), no debe desviarse tratando de desarrollar algo que ya está disponible en el mercado (de código abierto o comercial).

Ahora intentará crear un sistema de seguimiento de errores para realizar un seguimiento del sistema de seguimiento de errores que utiliza para rastrear errores en su desarrollo principal.

Primero: 1. Elija la plataforma en la que se ejecutará su sistema de errores (Java, PHP, Windows, Linux, etc.) 2. Intente encontrar herramientas de código abierto que estén disponibles (por código abierto, me refiero tanto comercial como herramientas gratuitas) en la plataforma que eligió 3. Dedique un tiempo mínimo para tratar de personalizar sus necesidades. Si es posible, no pierda tiempo en la personalización en absoluto

Para un equipo de desarrollo empresarial, comenzamos a usar JIRA. Queríamos algunos informes adicionales, inicio de sesión SSO, etc. JIRA era capaz de hacerlo, y podríamos ampliarlo utilizando el complemento ya disponible. Como el código recibió parte de la asistencia paga, solo pasamos un tiempo mínimo escribiendo el complemento personalizado para iniciar sesión.

Answer 12

Un sistema de seguimiento de errores puede ser un gran proyecto para iniciar a los desarrolladores junior. Es un sistema bastante simple que puede usar para entrenarlos en sus convenciones de codificación y demás.Conseguir que los desarrolladores más jóvenes construyan un sistema de este tipo es relativamente barato y pueden cometer errores en algo que un cliente no verá.

Si es basura puede tirarla pero puede darles la sensación de que el trabajo ya es importante para la empresa si se usa. No puede costarle a un desarrollador junior la posibilidad de experimentar el ciclo de vida completo y todas las oportunidades de transferencia de conocimiento que tal proyecto traerá.

Answer 13

Cada desarrollador de software quiere construir su propio sistema de seguimiento de errores. Es porque podemos obviamente mejorar lo que ya existe, ya que somos expertos en el dominio.

Es casi seguro que no vale la pena el costo (en términos de horas de desarrollador). Solo compre JIRA.

Si necesita informes adicionales para su sistema de seguimiento de errores, puede agregarlos, incluso si tiene que hacerlo accediendo directamente a la base de datos subyacente.

Answer 14

La pregunta es ¿qué le está pagando a usted su empresa? ¿Es para escribir software que solo usarás? Obviamente no. Entonces, la única forma en que puede justificar el tiempo y los gastos para construir un sistema de seguimiento de errores es si cuesta menos que los costos asociados con el uso de un sistema gratuito de seguimiento de errores.

Bien puede haber casos donde esto tenga sentido. ¿Necesita integrarse con un sistema existente? (Seguimiento del tiempo, estimación, requisitos, control de calidad, pruebas automatizadas)? ¿Tiene algunos requisitos únicos en su organización relacionados con el cumplimiento de SOX que requieren elementos de datos específicos que serían difíciles de capturar?

¿Está en un entorno extremadamente beauracratic que conduce a un significativo "tiempo de inactividad" entre los proyectos?

Si la respuesta es sí a este tipo de preguntas, entonces, por supuesto, el argumento de "comprar" frente a construir diría build.

Answer 15

Hemos hecho esto aquí. Escribimos nuestro primero hace más de 10 años. Luego lo actualizamos para usar servicios web, más como una forma de aprender la tecnología. La razón principal por la que hicimos esto originalmente fue porque queríamos un sistema de seguimiento de fallas que también produjera informes de historial de versiones y algunas otras características que no pudimos encontrar en productos comerciales.

Estamos buscando sistemas de seguimiento de fallas de nuevo y estamos considerando seriamente la posibilidad de migrar a Mantis y usar Mantis Connect para agregar funciones personalizadas adicionales. La cantidad de esfuerzo en hacer rodar nuestro propio sistema es demasiado grande.

Creo que también deberíamos tener en FogBugz :-)

Answer 16

Hay una tercera opción, comprar ni construimos. Hay montones de buenos gratis por ahí. Por ejemplo:

• Bugzilla
• Trac

rodar su propio gestor de fallos para cualquier uso que no sea el aprendizaje no es un buen uso del tiempo.

Otros enlaces:

• Three free bug-tracking tools
• Comparison of issue tracking systems

Answer 17

Sobre la base de lo que otras personas han dicho, en lugar de descargar una/uno de código abierto. ¿Qué tal descargarlo, luego modificarlo por completo para sus propias necesidades? Sé que me han requerido hacer eso en el pasado. Tomé una instalación de Bugzilla y luego la modifiqué para admitir las pruebas de regresión y los informes de prueba (esto fue hace muchos años).

No reinventar la rueda a menos que esté convencido de que se puede construir una rueda más redondo.

Answer 18

Porque existe Trac.

Y debido a que tendrá que capacitar al personal nuevo en su software a medida cuando probable que tenga experiencia en otros sistemas que se pueden construir en vez de tirar.

Answer 19

Porque no es tiempo facturable o incluso muy útil a menos que se va a vender.

No son perfectamente buenos sistemas de seguimiento de errores disponibles, por ejemplo, FogBugz.

Answer 20

Estoy de acuerdo con la mayoría de las personas aquí. No sirve de nada reconstruir algo cuando hay muchas herramientas (incluso gratuitas) disponibles. Si desea personalizar algo, la mayoría de las herramientas gratuitas le dan el código, juegue con él.

Si lo hace nuevo desarrollo, que no debería estar haciendo por sí mismo solamente.

Answer 21

Si "necesitar algún informe altamente especializado, o la capacidad de modificar alguna característica de alguna manera supuestamente única", la mejor y más barata manera de hacerlo es hablar con los desarrolladores de sistemas de seguimiento de errores existentes. Págales para poner esa característica en su aplicación, ponerla a disposición del mundo. En lugar de reinventar la rueda, simplemente pague a los fabricantes de ruedas para que pongan radios en forma de muelles.

De lo contrario, si se trata de mostrar un marco, todo es bueno. Solo asegúrate de incluir las renuncias relevantes.

Para las personas que creen sistema de seguimiento de fallos no son difíciles de construir, siga estrictamente la cascada SDLC. Obtenga todos los requisitos por adelantado. Eso seguramente los ayudará a comprender la complejidad. Estas suelen ser las mismas personas que dicen que un motor de búsqueda no es tan difícil de construir. Solo un cuadro de texto, un botón de "búsqueda" y un botón "me siento afortunado", y el botón "me siento afortunado" se pueden hacer en la fase 2.

Answer 22

La mayoría de los desarrolladores piensan que tienen algunos únicos poderes que nadie más tiene y, por lo tanto, pueden crear un sistema que sea único de alguna manera.

99% de ellos son incorrectos.

¿Cuáles son las posibilidades de que su empresa tenga empleados en el 1%?

Answer 23

Trabajé en una startup durante varios años donde comenzamos con GNATS, una herramienta de código abierto, y esencialmente construimos nuestro propio sistema de seguimiento de errores elaborado en la parte superior.El argumento era que evitaríamos gastar mucho dinero en un sistema comercial, y obtendríamos un sistema de seguimiento de fallas que se ajustaba exactamente a nuestras necesidades.

Por supuesto, resultó ser mucho más difícil de lo esperado y fue una gran distracción para los desarrolladores, que también tenían que mantener el sistema de seguimiento de fallas además de nuestro código. Este fue uno de los factores que contribuyeron a la desaparición de nuestra empresa.

Answer 24

Utilice un software de código abierto como. Para asegurarse de que hay errores, y necesitará lo que aún no está allí o está pendiente una solución de error. Sucede todo el tiempo. :)

Si amplía/personaliza una versión de código abierto, entonces debe mantenerla. Ahora, la aplicación que se supone que lo ayudará a probar aplicaciones para hacer dinero se convertirá en una carga de soporte.

Answer 25

En primer lugar, en contra de los argumentos a favor de la construcción de su propia:

Queriendo 'comer nuestra propia comida para perros' en términos de algún marco web integrado internamente

Eso, por supuesto, plantea la pregunta por qué construyes tu propio marco web. Al igual que hay muchos buscadores de errores gratuitos valiosos, también hay muchos marcos valiosos. Me pregunto si tus desarrolladores tienen sus prioridades correctas. ¿Quién está haciendo el trabajo que hace que su empresa tenga dinero real?

OK, si deben crear un marco, déjelo evolucionar orgánicamente desde el proceso de creación del software real que su empresa utiliza para ganar dinero.

necesitar algún informe altamente especializado, o la capacidad de modificar alguna característica de alguna manera supuestamente única

Como han dicho otros, agarra uno de los seguidores de código abierto muchos finos y modificarlo.

creyendo que no es difícil construir un sistema de seguimiento de errores

Bueno, escribí la primera versión de mi BugTracker.NET en sólo un par de semanas, a partir de C# sin conocimiento previo. Pero ahora, 6 años y un par de miles de horas más tarde, todavía hay una gran lista de solicitudes de funciones deshechas, por lo que todo depende de lo que desee que haga un sistema de seguimiento de errores. Cuánta integración de correo electrónico, integración de control de fuente, permisos, flujo de trabajo, seguimiento de tiempo, estimación de programación, etc. Un rastreador de errores puede ser una aplicación importante.

¿Qué argumentos podría usar para respaldar la compra de un sistema de seguimiento de errores existente?

No necesite buy.Too muchos buenos código abierto: Trac, Mantis_Bug_Tracker, mi propia BugTracker.NET, por nombrar algunos.

En particular, ¿qué características de sonido fácil, pero resultan difíciles de implementar, o son difíciles e importantes, pero a menudo se pasa por alto?

Si lo está creando solo para usted, entonces puede tomar muchos atajos, porque puede cablear las cosas. Si lo está creando para muchos usuarios diferentes, en muchos escenarios diferentes, entonces es la compatibilidad con la capacidad de configuración lo que es difícil. Flujo de trabajo configurable, campos personalizados y permisos.

creo dos características que un buen seguimiento de errores debe tener, que tanto FogBugz y BugTracker.NET tienen, son 1) la integración de tanto el correo electrónico entrante y saliente, de modo que toda la conversación acerca de un error vive con el insecto y no en un hilo de correo electrónico por separado, y 2) una utilidad para convertir una captura de pantalla en una publicación de error con solo un par de clics.

Answer 26

Supongamos, mañana (próximo año), si decidieron traer en una popular herramienta de código abierto/comercial para todos los sistemas de control de errores en la empresa, ¿cómo esta herramienta será capaz de exportar todas sus entradas de errores a la otra herramienta ?

Siempre que haya una necesidad real de un sistema de seguimiento de errores personalizado, y tales preguntas se respondan, NO me molestaría demasiado.

Answer 27

Ya hay tantos buenos, ¿por qué perder el tiempo para reinventar la rueda?

Simplemente use FogBugz.

Answer 28

He estado en ambos lados de este debate, así que permítanme ser un poco dos caras aquí.

Cuando era más joven, impulsé a construir nuestro propio sistema de seguimiento de errores. Acabo de resaltar todas las cosas que las cosas no disponibles no podían hacer, y tengo la dirección para hacerlo. ¿A quién eligieron para dirigir el equipo? ¡Yo! Iba a ser mi primera oportunidad de ser un líder de equipo y tener voz en todo, desde diseño hasta herramientas y personal. Yo estaba muy emocionado. Entonces mi recomendación sería verificar las motivaciones de las personas que impulsan este proyecto.

Ahora que soy mayor y me enfrento con la misma pregunta nuevamente, decidí usar FogBugz. Hace el 99% de lo que necesitamos y los costos son básicamente 0. Además, Joel te enviará correos electrónicos personales que te harán sentir especial. Y al final, ¿no es ese el problema, tus desarrolladores piensan que esto los hará especiales?

Answer 29

No escriba su propio software solo para que pueda "comer su propia comida para perros". Simplemente está creando más trabajo, cuando probablemente podría comprar software que hace lo mismo (y mejor) por menos tiempo y dinero gastado.

Answer 30

Creo que la razón la gente escribe sus propios sistemas de control de errores (en mi experiencia) son,

1. Ellos no quieren pagar por un sistema que consideran que son relativamente fáciles de construir.
2. Programador ego
3. Insatisfacción general con la experiencia y la solución entregada por los sistemas existentes.
4. lo venden como un producto :)

Para mí, la mayor razón por la mayoría de los gestores de fallos fallaron fue que no ofrecen una experiencia de usuario óptima y puede ser muy doloroso trabajar con un sistema que le usa MUCHO, cuando no está optimizado para la usabilidad.

creo que la otra razón es la misma que la razón por casi cada uno de nosotros (programadores) han construido sus propias costumbres o CMS CMS marco en algún momento (culpable de los cargos). ¡Solo porque puedes!

Answer 31

No creo que la construcción de un sistema de seguimiento de la casa es relativamente fácil de construir, y ciertamente no lo haría con una solución de código abierto o de pago. La mayoría de las veces prefiero el "ego de programador" o simplemente tener un departamento de TI que realmente no puede usar software de terceros y tiene que construir literalmente cada pieza de software utilizado.

Una vez trabajé en una empresa de telecomunicaciones que tenía su propio sistema de control versión de la casa, y que era bastante malo, pero seguía todo un equipo ocupado ...

Answer 32

Estoy de acuerdo con todas las razones No a. Intentamos por un tiempo usar lo que hay, y terminamos escribiendo el nuestro de todos modos. ¿Por qué? Principalmente porque la mayoría de ellos son demasiado engorrosos para involucrar a cualquier persona que no sea la técnica. Incluso probamos basecamp (que, por supuesto, no está diseñado para esto y falló en ese sentido).

también se nos ocurrió alguna funcionalidad única que funcionaba muy bien con nuestros clientes: un botón "informar de un error" que con guión en código mediante una línea de javascript. Permite a nuestros clientes abrir una pequeña ventana, escribir información rápidamente y enviarla a la base de datos.

Pero, sin duda tomó muchas horas al código; se convirtió en un GRAN proyecto de mascota; mucho tiempo de fin de semana.

Si quieres comprobarlo: http://www.archerfishonline.com

Me encantaría algunos comentarios.

Answer 33

Hemos hecho esto ... un par de veces. La única razón por la que construimos la nuestra es porque fue hace cinco años y no había muchas buenas alternativas. pero ahora hay toneladas de alternativas. Lo principal que aprendimos al construir nuestra propia herramienta es que pasará mucho tiempo trabajando en ello. Y ese es el momento en que podrías estar cobrando por tu tiempo. Tiene mucho más sentido, como una pequeña empresa, pagar la tarifa mensual que puede recuperar fácilmente con una o dos horas facturables, en lugar de gastar todo ese tiempo en hacer su propia inversión. Claro, tendrás que hacer algunas concesiones, pero estarás mucho mejor a largo plazo.

En cuanto a nosotros, hemos decidido hacer nuestra aplicación disponible para otros desarrolladores. Compruébelo en http://www.myintervals.com

Answer 34

Dígales, que es genial, la compañía podría ahorrar un poco de dinero por un tiempo y estará encantado de contribuir con las herramientas de desarrollo mientras trabaja en este año sabático no remunerado.Cualquier persona que desee tomar sus vacaciones anuales para trabajar en el proyecto puede hacerlo.

Answer 35

He creado mis propios sistemas de seguimiento de errores. Yo también pensé: "qué difícil podría ser, es solo un sistema de seguimiento de errores" ERR - INCORRECTO * - tomó seis meses codificarlo.

La razón principal por la que horneé la mía fue para obtenerla exactamente como la quería. La otra razón fue como un proyecto de hobby.

Diría que es casi la única vez que se justifica construir uno propio si se trata de un proyecto de hobby. Ninguna compañía debería pasar su tiempo haciéndolo.

Mi software se llama Bugweb por cierto.