Razones para no construir su propio sistema de seguimiento de errores
Varias veces me he enfrentado con planes de un equipo que quiere construir su propio sistema de seguimiento de errores, no como un producto, sino como una herramienta interna.
Los argumentos que he escuchado en favor generalmente están en la línea de:
- Querer 'comer nuestra propia comida para perros' en términos de un marco web construido internamente
- Necesitar algún informe altamente especializado, o la capacidad de ajustar alguna característica de una manera supuestamente única
- Creer que no es difícil construir un sistema de seguimiento de errores
¿Qué argumentos podría utilizar 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?
Primero, mire estas 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 excelente manera de desperdiciar recursos!
Aquí están mis razones para construir su propio sistema interno de seguimiento de errores:
- Necesita neutralizar todos los bozocoders durante una o dos décadas.
- Necesita descargar algo de dinero para evitar la reducción del presupuesto el próximo año.
De lo contrario no lo hagas.
Me gustaría cambiar la pregunta. ¿POR QUÉ en la tierra te gustaría construir el tuyo?
Si necesita algunos campos adicionales, vaya con un paquete existente que pueda modificarse.
¿Reporte especial? Toque en la base de datos y hágala.
¿Creer que no es difícil? Intenta entonces. Especifíquelo y vea crecer la lista de características 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 solo necesita algunos ajustes para encajar.
A los programadores les gusta construir su propio sistema de tickets porque, habiendo 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 toma de decisiones enterrado allí: siempre hay dos razones para hacer algo: una buena y la correcta. Tomamos una decisión ("Construir 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 de opinión, debes atacar la razón real, no la justificación.
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 dice Omer van Kloeten en otro lugar, pague ahora o pague después.
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 otro uso que no sea aprender no es un buen uso del tiempo.
Otros enlaces:
Solo diría que es una cuestión de dinero: comprar un producto terminado que sabes que es bueno para ti (y a veces ni siquiera comprarlo si es gratis) es mejor que tener que ir y desarrollar uno por tu cuenta. Es un juego simple de paga ahora vs. paga después.
Primero, contra los argumentos a favor de construir el suyo 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 rastreadores de errores gratuitos dignos, también hay muchos marcos dignos. Me pregunto si sus desarrolladores tienen sus prioridades claras. ¿Quién está haciendo el trabajo que hace que su empresa sea dinero real?
De acuerdo, si deben crear un marco, déjelo evolucionar orgánicamente a partir del proceso de creación del software real que su empresa utiliza para ganar dinero.
Necesitar algún informe altamente especializado, o la capacidad de ajustar alguna función de una manera supuestamente única
Como otros han dicho, tome uno de los muchos rastreadores de código abierto y ajústelo.
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 después, todavía hay una gran lista de solicitudes de funciones sin hacer, 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 utilizar 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, entonces pueden tomar muchos atajos, ya que pueden cablear cosas. Si lo está compilando para muchos usuarios diferentes, en muchos escenarios diferentes, entonces es difícil el soporte para la configurabilidad. Flujo de trabajo configurable, campos personalizados y permisos.
Creo que dos características que debe tener un buen rastreador de errores, que tanto FogBugz como BugTracker.NET tienen, son 1) integración tanto del correo electrónico entrante como saliente, de modo que toda la conversación sobre un error viva con el error y no en un hilo de correo electrónico separado, y 2) una utilidad para convertir una captura de pantalla en una publicación de error con solo un par de clics.
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 función que tienes que ajustar y que 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 inherentemente malo para una empresa/equipo. La mayoría de las prácticas ágiles favorecen 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 te pongas demasiado burocrático sobre esto.
Un sistema de seguimiento de errores puede ser un gran proyecto para iniciar desarrolladores junior. Es un sistema bastante simple que puede usar para entrenarlos en sus convenciones de codificación, etc. Hacer que los desarrolladores junior creen 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 poner un costo a un desarrollador junior que pueda experimentar el ciclo de vida completo y todas las oportunidades para la transferencia de conocimiento que traerá dicho proyecto.
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 que queríamos un sistema de seguimiento de errores que también produjera informes del historial de versiones y algunas otras características que no pudimos encontrar en productos comerciales.
Ahora estamos analizando nuevamente los sistemas de seguimiento de errores y estamos considerando seriamente migrar a Mantis y usar Mantis Connect para agregar características personalizadas adicionales. La cantidad de esfuerzo en rodar nuestro propio sistema es demasiado grande.
Supongo que también deberíamos mirar FogBugz :-)
Lo más importante, ¿dónde enviará los errores para su rastreador de errores antes de que termine?
Pero en serio. Las herramientas ya existen, no hay necesidad de reinventar la rueda. Modificar herramientas de seguimiento para agregar ciertas características específicas es una cosa (he modificado Trac antes) ... reescribir una es simplemente una tontería.
Lo más importante que puede señalar es que si todo lo que quieren hacer es agregar un par de informes especializados, no requiere una solución básica. Y además, el ÚLTIMO lugar en el que "su solución casera" es importante es en las herramientas internas. ¿A quién le importa lo que estás usando internamente si está haciendo el trabajo como lo necesitas?
Ser un programador que trabaja en una tarea ya crítica (o al menos importante), no debe desviarse tratando de desarrollar algo que ya está disponible en el mercado (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 usted eligió 3. Pase el tiempo mínimo para intentar personalizarlo según sus necesidades. Si es posible, no pierdas el tiempo personalizando
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 podíamos extenderlo usando el complemento ya disponible. Dado que el código recibió parte de la asistencia paga, solo dedicamos un tiempo mínimo a escribir el complemento personalizado para iniciar sesión.
Sobre la base de lo que otras personas han dicho, en lugar de simplemente descargar uno gratuito/de código abierto. ¿Qué tal descargarlo, luego modificarlo completamente para sus propias necesidades? Sé que he tenido que hacer eso en el pasado. Tomé una instalación de Bugzilla y luego la modifiqué para admitir pruebas de regresión e 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.
He estado en ambos lados de este debate, así que permítanme ser dos caras aquí.
Cuando era más joven, presioné para construir nuestro propio sistema de seguimiento de errores. Solo resalté todas las cosas que las cosas disponibles no podían hacer, y conseguí que la gerencia lo hiciera. ¿A quién eligieron para dirigir el equipo? ¡Yo! Sería mi primera oportunidad de ser líder de equipo y tener voz en todo, desde el diseño hasta las herramientas y el 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 a la misma pregunta nuevamente, decidí seguir con FogBugz. Hace el 99% de lo que necesitamos y los costos son básicamente 0. Además, Joel le enviará correos electrónicos personales para que se sienta especial. Y al final, ¿no es ese el problema, sus desarrolladores piensan que esto los hará especiales?
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.
El 99% de ellos están equivocados.
¿Cuáles son las posibilidades de que su empresa tenga empleados en el 1%?
Yo diría que uno de los mayores obstáculos sería la agonía sobre el modelo de datos/flujo de trabajo. Predigo que esto tomará un largo tiempo e involucrará 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 si simplemente implementara un sistema preconstruido, la mayoría de las personas aprenderán cómo usarlo y aprovecharlo al máximo, sin importar las decisiones que ya se hayan solucionado. Elija algo de código abierto, y siempre puede ajustarlo más tarde si es necesario, eso será mucho más rápido que rodar el suyo desde cero.
En este punto, sin una gran dirección nueva en el seguimiento de errores/venta de entradas, simplemente estaría reinventando la rueda. Lo que parece ser lo que todos piensan, en general.
Sus discusiones comenzarán con lo que constituye un error y evolucionarán a qué flujo de trabajo aplicar y terminarán con una discusión masiva sobre cómo administrar proyectos de ingeniería de software. ¿De verdad quieres eso? :-) Nah, pensé que no, ¡ve a comprar uno!
Si "Necesita algún informe altamente especializado, o la capacidad de Ajustar alguna característica de una manera supuestamente única", la mejor y más barata forma de hacerlo es hablar con los desarrolladores de los 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, solo paga a los fabricantes de ruedas para que coloquen radios con forma de resortes.
De lo contrario, si intenta mostrar un marco, todo está bien. Solo asegúrese de incluir las renuncias de responsabilidad relevantes.
Para las personas que creen que el sistema de seguimiento de errores no es difícil de construir, siga estrictamente el SDLC en cascada. Obtenga todos los requisitos por adelantado. Eso seguramente los ayudará a comprender la complejidad. Por lo general, son 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 "buscar" y un botón "Me siento con suerte", y el botón "Me siento con suerte" se puede hacer en la fase 2.
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 dominios.
Es casi seguro que no vale la pena el costo (en términos de horas de desarrollador). Simplemente 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.
La pregunta es ¿qué le está pagando su empresa por hacer? ¿Es para escribir software que solo usted usará? Obviamente no. Entonces, la única manera de 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 incluso un sistema gratuito de seguimiento de errores.
Bien puede haber casos en los que esto tenga sentido. ¿Necesita integrarse con un sistema existente? (¿Seguimiento de tiempo, estimación, requisitos, control de calidad, pruebas automatizadas)? ¿Tiene algunos requisitos únicos en su organización relacionados con el cumplimiento de SOX que requiere elementos de datos específicos que serían difíciles de capturar?
¿Estás en un ambiente extremadamente beauracrático que conduce a un "tiempo de inactividad" significativo entre los proyectos?
Si la respuesta es afirmativa a este tipo de preguntas, entonces el argumento "comprar" frente a compilación diría compilación.
Porque Trac existe.
Y debido a que tendrá que capacitar al nuevo personal en su software a medida cuando probablemente tengan experiencia en otros sistemas en los que pueda desarrollar en lugar de tirar.
Estoy de acuerdo con todas las razones para NO hacerlo. Intentamos por un tiempo usar lo que hay ahí fuera y terminamos escribiendo el nuestro de todos modos. ¿Por qué? Principalmente porque la mayoría de ellos son demasiado engorrosos para involucrar a nadie, excepto a los técnicos. 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 de "informar un error" que escribimos en el código con una línea de JavaScript. Permite a nuestros clientes abrir una pequeña ventana, ingresar información rápidamente y enviarla a la base de datos.
Pero, ciertamente tomó muchas horas codificar; se convirtió en un gran proyecto para mascotas; mucho tiempo de fin de semana.
Si quieres echarle un vistazo: http://www.archerfishonline.com
Me encantaría algunos comentarios.
Porque no es un tiempo facturable o incluso muy útil a menos que lo vendas.
Hay sistemas de seguimiento de errores perfectamente buenos disponibles, por ejemplo, FogBugz .
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. El argumento era que evitaríamos gastar mucho dinero en un sistema comercial y obtendríamos un sistema de seguimiento de errores que se ajustara 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 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.
se algún software de código abierto como está. Seguro que hay errores, y necesitará lo que aún no está allí o está pendiente de una corrección de errores. Sucede todo el tiempo. :)
Si extiende/personaliza una versión de código abierto, debe mantenerla. Ahora, la aplicación que se supone que lo ayudará con las pruebas aplicaciones para ganar dinero se convertirá en una carga de soporte.
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 crear nuestra propia herramienta es que pasarás mucho tiempo trabajando en ella. Y ese es el momento en que podría estar facturando por su tiempo. Tiene mucho más sentido, como pequeña empresa, pagar la tarifa mensual que puede recuperar fácilmente con una o dos horas facturables, que gastar todo ese tiempo en la suya propia. Claro, tendrá que hacer algunas concesiones, pero a la larga estará mucho mejor.
En cuanto a nosotros, decidimos hacer que nuestra aplicación esté disponible para otros desarrolladores. Compruébalo en http://www.myintervals.com
Creo que la razón por la cual 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 programador
- Insatisfacción general con la experiencia y la solución entregada por los sistemas existentes.
- Lo venden como producto :)
Para mí, la razón principal por la cual la mayoría de los rastreadores de errores fallaron fue que no ofrecían una experiencia de usuario óptima y puede ser muy doloroso trabajar con un sistema que usa MUCHO, cuando no está optimizado para la usabilidad.
Creo que la otra razón es la misma por la que casi todos nosotros (programadores) hemos construido su propio marco CMS o CMS personalizado en algún momento (culpables de los cargos). ¡Solo porque puedes!
No creo que construir un sistema de seguimiento interno sea relativamente fácil de construir, y ciertamente no coincidirá con una solución paga o de código abierto. La mayoría de las veces optaría por el "ego programador" o simplemente por tener un departamento de TI que realmente no puede usar software de terceros y tiene que construir literalmente cada pieza de software utilizada.
Una vez que trabajé en una compañía de telecomunicaciones que tenía su propio sistema de control de versiones interno, y fue bastante malo, pero mantuvo ocupado a todo un equipo ...
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 un software que hace lo mismo (y mejor) por menos tiempo y dinero gastado.
He construido mis propios sistemas de seguimiento de errores. Yo también pensé: "cuán difícil podría ser, es solo un sistema de seguimiento de errores" ERR - WRONG * - tardó seis meses en 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 el único momento en que se justifica construir uno propio si es como un proyecto de pasatiempo. Ninguna empresa debería pasar su tiempo haciéndolo.
Mi software se llama Bugweb por cierto.
Supongamos, mañana (el año próximo), si decidieran incorporar una popular herramienta de código abierto/comercial para TODOS los sistemas de seguimiento de errores de la empresa, ¿cómo podrá esta herramienta exportar todos sus tickets de errores a la otra herramienta?
Mientras exista una necesidad real de un sistema de seguimiento de errores personalizado y se respondan tales preguntas, NO me molestaría demasiado.
Ya hay tantos grandes por ahí, ¿por qué perder el tiempo para reinventar la rueda?
Solo use FogBugz .
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 realiza un nuevo desarrollo, no debería hacerlo solo para usted.
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. Cualquiera que desee tomar sus vacaciones anuales en su lugar para trabajar en el proyecto es libre de hacerlo.