bug tracking - tipo - Razones para no construir su propio sistema de seguimiento de errores
tipos de errores de software (30)
Varias veces me he enfrentado con 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 favor son generalmente los siguientes:
- Querer ''comer nuestra propia comida para perros'' en términos de un marco web construido internamente
- Necesitando algún informe altamente especializado, o la capacidad de ajustar alguna característica de alguna manera supuestamente única
- Creer que no es difícil construir un sistema de seguimiento de errores
¿Qué argumentos podría usar para apoyar la compra de 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?
Basándose en lo que otras personas han dicho, en lugar de simplemente descargar uno gratuito / 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 reinvente la rueda a menos que esté convencido de que puede construir una rueda más redonda.
Cada desarrollador de software quiere construir su propio sistema de seguimiento de errores. Es porque obviamente podemos 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 desarrollo). Solo compra 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.
En este punto, sin una gran nueva dirección en el seguimiento de errores / ticketing, simplemente sería reinventar la rueda. Lo cual parece ser lo que todos los demás piensan, en general.
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.
Ahora estamos analizando los sistemas de seguimiento de errores nuevamente 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 estar mirando FogBugz :-)
La mayoría de los desarrolladores piensan que tienen algunos poderes únicos que nadie más tiene y, por lo tanto, pueden crear un sistema que sea único de alguna manera.
99% de ellos están equivocados.
¿Cuáles son las posibilidades de que su empresa tenga empleados en el 1%?
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ás en un ambiente extremadamente beauracrático que te lleva a un "tiempo de inactividad" significativo entre proyectos?
Si la respuesta es sí a este tipo de preguntas, entonces, por supuesto, el argumento de "comprar" frente a construir diría construir.
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.
¿Reporte especial? Toca la base de datos y hazlo.
¿Creyendo 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 necesita ajustes para encajar.
Si "Necesita algún informe altamente especializado, o la capacidad de ajustar alguna característica de alguna manera supuestamente única", la mejor y más económica forma de hacerlo es hablar con los desarrolladores de los sistemas existentes de seguimiento de errores. 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 intenta mostrar un marco, todo está bien. Solo asegúrate de incluir las renuncias relevantes.
Para las personas que creen que el sistema de seguimiento de errores no es difícil 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 "tengo suerte", y el botón "me siento afortunado" se pueden hacer en la fase 2.
Solo diría que es una cuestión de dinero: comprar un producto final que sabe que es bueno para usted (y, a veces, ni siquiera comprar si es gratis) es mejor que tener que ir y desarrollar uno por su cuenta. Es un simple juego de pago ahora contra pago después .
Sus discusiones comenzarán con lo que constituye un error y evolucionará en qué flujo de trabajo aplicar y terminará 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!
Un sistema de seguimiento de fallas 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 se trata de basura, puede tirarla, pero puede darles la sensación de que el trabajo ya es importante para la compañía 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á.
Yo diría que uno de los mayores escollos sería agonizar sobre el modelo de datos / flujo de trabajo. Predigo que esto llevará mucho tiempo e involucrará muchos argumentos sobre lo que debería sucederle a un error en ciertas circunstancias, lo que realmente constituye un error, etc. En lugar de pasar meses discutiendo de un lado a otro, si solo fuera a lanzar 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 es necesario, será mucho más rápido que hacerlo desde cero.
Use un software de código abierto como está . Seguro que hay errores, y necesitarás lo que aún no está allí o está pendiente una corrección de errores. Sucede todo el tiempo. :)
Si extiende / personaliza una versión de código abierto, entonces debe mantenerla. Ahora, la aplicación que se supone que lo ayudará a probar las aplicaciones para hacer dinero se convertirá en una carga de apoyo.
He estado en ambos lados de este debate así que déjenme ser un poco dos cara 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í ir con 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?
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.
Creo que la razón por la que las personas escriben sus propios sistemas de seguimiento de errores (en mi experiencia) son,
- No quieren pagar por un sistema que consideran relativamente fácil de construir.
- Ego del programador
- Insatisfacción general con la experiencia y la solución entregada por los sistemas existentes.
- Lo venden como un producto :)
Para mí, la razón principal por la que la mayoría de los rastreadores de errores fallaron fue porque no ofrecían una experiencia de usuario óptima y puede ser muy doloroso trabajar con un sistema que se usa mucho, cuando no está optimizado para la usabilidad.
Creo que la otra razón es la misma por la que casi todos nosotros (los programadores) hemos construido su propio marco CMS o CMS personalizado en algún momento (culpable como se le acusa). ¡Solo porque puedes!
Estoy de acuerdo con todas las razones por las que NO lo hago. 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ó una funcionalidad única que funcionó muy bien con nuestros clientes: un botón "informar un error" que escribimos en el código con 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, ciertamente tomó muchas horas codificar; se convirtió en un GRAN proyecto de mascota; mucho tiempo de fin de semana.
Si quieres verlo: http://www.archerfishonline.com
Me encantaría algún comentario.
Hemos hecho esto ... algunas 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, decidimos poner nuestra aplicación a disposición de otros desarrolladores. Compruébelo en http://www.myintervals.com
Dígales, eso es genial, la compañía podría ahorrar un poco de dinero por un tiempo y estará feliz 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.
Primero, mira estas métricas de Ohloh :
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 interno de seguimiento de errores:
- Debes neutralizar todos los bozocoders durante una o dos décadas.
- Debe desembolsar algo de dinero para evitar la reducción del presupuesto el próximo año.
De lo contrario, no.
A los programadores les gusta construir su propio sistema de tickets porque, al haber visto y usado a 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 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.
Para cambiar sus mentes, debes atacar la verdadera razón, no la justificación.
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 debe 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 errores están en línea con tales sugerencias y métodos. No seas demasiado burocrático sobre esto.
Lo que es más importante, ¿dónde enviarás los errores para tu rastreador de errores antes de que esté 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 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?
Porque Trac existe.
Y porque tendrá que capacitar al nuevo personal en su software a medida cuando es probable que tengan experiencia en otros sistemas en los que puede construir en lugar de tirarlos.
Porque no es un tiempo facturable o incluso muy útil a menos que vayas a venderlo.
Hay sistemas de seguimiento de errores perfectamente disponibles, por ejemplo, FogBugz .
Primero, contra los argumentos a favor de construir uno propio:
Querer ''comer nuestra propia comida para perros'' en términos de un marco web construido internamente
Eso, por supuesto, plantea la pregunta de por qué construir su 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 sea dinero real?
De acuerdo, si deben crear un marco, permita que evolucione orgánicamente desde el proceso de creación del software real que su empresa utiliza para generar dinero.
Necesitando algún informe altamente especializado, o la capacidad de ajustar alguna característica de alguna manera supuestamente única
Como han dicho otros, agarra uno de los muchos y finos rastreadores de código abierto y ajústalo.
Creer que no es difícil construir un sistema de seguimiento de errores
Bueno, escribí la primera versión de mi BugTracker.NET en solo un par de semanas, comenzando sin conocimiento previo de C #. 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 apoyar la compra de un sistema de seguimiento de errores existente?
No es necesario comprar. Demasiados buenos de código abierto: Trac , Mantis_Bug_Tracker , mi propio BugTracker.NET, por nombrar algunos.
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?
Si lo está creando solo para ustedes mismos, entonces pueden tomar muchos atajos, porque pueden cablear 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 que dos características que un buen rastreador de errores debe tener, que tanto FogBugz como BugTracker.NET tienen, son 1) integración del correo electrónico entrante y saliente, de modo que toda la conversación sobre un error viva con el error y no en un correo electrónico separado hilo, y 2) una utilidad para convertir una captura de pantalla en una publicación de error con solo un par de clics.
Ser un programador trabajando 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ía 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 a herramientas comerciales y gratuitas) en la plataforma eliges 3. Dedica un tiempo mínimo para tratar de personalizar según tus necesidades. Si es posible, no pierdas tiempo en personalizar 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.
Trabajé en una startup durante varios años donde comenzamos con GNATS , una herramienta de código abierto, y esencialmente construimos nuestro propio y elaborado sistema de seguimiento de errores 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, quienes también tuvieron que mantener el sistema de seguimiento de errores además de nuestro código. Este fue uno de los factores que contribuyeron a la desaparición de nuestra empresa.
Hay una tercera opción, ni comprar ni construir. Hay montones de buenos gratis por ahí. Por ejemplo:
Hacer rodar su propio rastreador de errores para cualquier uso que no sea el aprendizaje no es un buen uso del tiempo.
Otros enlaces:
Síndrome de no inventado aquí!
Construye tu propio rastreador de errores? ¿Por qué no crear su propio cliente de correo, herramienta de gestión de proyectos, etc.
Como Omer van Kloeten dice en otro lugar, pague ahora o pague después.