¿Demasiado control de versiones y sobrecarga de seguimiento de errores por cambio?

Trabajo en un lugar que es loco por CVS y loco por Bugzilla.

1. Hay tantas ramas de cada lanzamiento que no se pueden contar. Todos están constantemente fusionándose automáticamente.

2. No hay fluidez en este trabajo. Todo se siente paso a paso . Toma 25 pasos incluso para una cosa simple. No es como estar en una línea de producción de fábrica: es como establecer una fábrica yo mismo todos los días.

Situación de ejemplo:

Para corregir un solo error, primero obtengo una máquina virtual nueva y limpia. Luego creo una rama para esa única corrección de errores, basada en otra rama descrita en el informe de Bugzilla. Instalo la rama en la máquina, la configuro. Arreglo el error. Lo reviso, dejándolo y la máquina para que otros lo prueben. Luego tengo que ir al software de control de errores y explicar lo que hice y escribir un caso de prueba, con todos los pasos. Finalmente, alguien más lo fusiona con un lanzamiento.

No importa cuán pequeño sea el error, tengo que hacer todas estas cosas. A veces, las personas combinan el trabajo en múltiples errores, pero como dije, hay tantas ramas que esto es casi imposible.

En cualquier otro trabajo, solo entraría y arreglaría el error. Apenas recuerdo haber usado SCM, aunque todos los trabajos que he tenido lo han usado: eso es porque en cualquier otro trabajo, de alguna manera lo mantuvieron fuera del camino .

¿Hay algún punto en el que el proceso se interponga y se convierta en un fin en sí mismo? ¿Eso es incluso ingeniería?

¿Hay algún punto en el que el proceso se interponga y se convierta en un fin en sí mismo?

Los procesos pesados ​​son comunes, desafortunadamente. Algunas personas, especialmente la gerencia, imaginan religiosamente que los procesos producen productos. Por lo tanto, exageran los procesos y se olvidan de que es realmente un puñado de personas inteligentes y trabajadoras las que realmente crean los productos. Para la alta gerencia, es aterrador incluso pensar que su negocio está en manos de pocos geeks, por lo que cierran los ojos de la realidad y piensan en su querido "proceso", lo que les da la ilusión de control.

Es por eso que las nuevas empresas ágiles con un puñado de buenos ingenieros pueden vencer a las grandes corporaciones establecidas, cuyos trabajadores gastan el 95% de su energía en procesos e informes. Algunos ejemplos de pequeñas empresas que alguna vez vencieron a sus competidores y / o crearon mercados completamente nuevos:

• Apple (Apple I fue creado por 1 ingeniero; había 3 hombres en la compañía en ese entonces).
• Google (creado originalmente por 2 programadores).
• Facebook ( esfuerzo de 1 hombre originalmente).
• Microsoft ( compañía de 2 hombres en 1975).

Se podría decir fácilmente que estos son solo valores atípicos, excepciones extremas, y para hacer algo serio, será mejor que seas una corporación grande y establecida. Pero la lista continúa. Y en. Es vergonzosamente largo. Casi todas las grandes corporaciones actuales comenzaron como una tienda de garaje, lo que hizo algo inusual. Algo raro. Lo estaban haciendo mal. ¿Crees que lo estaban haciendo de acuerdo con el proceso?

Las empresas suelen sufrir lo que me gustaría llamar el dilema Control-Flexibilidad. Cuantas menos reglas, estructuras y gastos generales burocráticos, más fácil y rápido es lograr las cosas (también es más divertido). Sin embargo, es igualmente fácil hacer cosas "malas" que cosas "buenas". Eso significa que solo estás bien cuando tienes empleados calificados que cometen pocos errores no críticos.

Por otro lado, si tiene muchos empleados poco calificados o semi calificados y / o el costo de cometer errores es demasiado alto (como el riesgo de escombros del transbordador espacial en el hemisferio norte), las empresas tienden a acumular más y más "reglas" "y" procesos "para intentar minimizarlos.

El único problema es que la sobrecarga acumulativa de estos procesos hace que sea difícil lograr algo que resultará en que los empleados más talentosos abandonen la empresa. Esto da como resultado que la habilidad promedio disminuya aún más, lo que requiere aún más procesos y burocracia. Entonces, la espiral de la muerte continúa hasta que sucede algo radical o la empresa se arruina.

Si se encuentra en una empresa que parece haber pasado el punto de no retorno en este aspecto, puede decidir "no preocuparse" por su trabajo (que es lo que han hecho la mayoría de los que se han quedado) o largarse. de allí con tu alma intacta :)

Si la compañía no ha ido demasiado lejos y usted tiene los medios, puede tratar de revertir el rumbo con absoluta determinación y fuerza de voluntad. Sin embargo, tenga en cuenta que puede requerir una enorme cantidad de trabajo y energía personal sin garantía de éxito, así que asegúrese de que valga la pena. A veces es mejor simplemente reducir la pérdida y contar una experiencia más rica.

Solo hay una razón válida para tal estilo de desarrollo: el software desarrollado es absolutamente crítico y no debe, bajo ninguna circunstancia, contener ningún error. Piense en el firmware de inyección de combustible del motor a reacción en aviones de pasajeros, en el firmware del marcapasos cardíaco o en el sistema de lanzamiento de misiles nucleares.

En todas las demás situaciones, los costos indirectos matarán al negocio. Tiempo de seguir adelante.

Esta pregunta realmente contiene dos preguntas, que deben abordarse por separado:

¿Por qué algunos equipos tienen un estricto proceso de desarrollo?

La respuesta simple es porque si no lo hacen, suceden errores. Errores costosos. Esto es cierto para el desarrollo y también para el resto del campo de TI (administradores de sistemas, administradores de bases de datos, etc.).

Esto es muy difícil de entender para muchos desarrolladores y trabajadores de TI porque la mayoría de nosotros solo hemos trabajado en uno de los "extremos", ya sean grandes empresas de estilo Fortune con al menos una docena de desarrolladores y procesos estrictos a seguir, o pequeños, micro-ISV o incluso trabajos independientes donde las personas simplemente no se equivocan mucho, o el costo de un error es bajo.

Pero si alguna vez ha visto una empresa entre estas fases, incluso una empresa con personal de TI brillante y talentoso, comprenderá los peligros de no tener un proceso o tener un proceso a medias. Usted ve, la comunicación entre el personal sufre de un problema de explosión combinatoria ; Una vez que alcanza el nivel de alrededor de 6-10 desarrolladores en un solo equipo, la causa principal de defectos importantes o críticos no es la falta de talento o conocimiento, sino la falta de comunicación.

Alice pregunta el lunes por la mañana y decide que está bien hacer una cirugía reconstructiva en el tronco porque nadie más está trabajando en esa parte. Bob llega una hora después, de regreso de sus vacaciones y lleno de energía, y decide que implementará una nueva característica importante en esa misma área, y ¿por qué molestarse con una sucursal porque nadie toca ese código de todos modos? Entonces Alice paga esa "deuda técnica", Bob implementa su característica asesina que ha estado en segundo plano durante 6 meses, y cuando finalmente ambos registran su código (¡justo antes de la hora de cierre el viernes, por supuesto!), Todo El equipo tiene que quedarse atrás e intentar trabajar en el infierno de pesadilla de conflictos que continúan viviendo como errores y regresiones durante las próximas dos semanas.

Alice y Bob hicieron un gran trabajo en las tareas de codificación, pero ambos comenzaron con una mala decisión ("¿qué es lo peor que podría pasar?"). El líder del equipo o gerente de proyecto los lleva a través de una autopsia y elabora una lista de verificación para evitar que esto vuelva a suceder:

• Los registros deben ser diarios para minimizar el impacto de los conflictos;
• Los cambios que tomarán significativamente más de 1 día deben hacerse en las sucursales;
• Todas las tareas importantes (incluido el trabajo sin características como la refactorización) se deben rastrear y asignar correctamente en el rastreador de errores.

Apuesto a que, para muchos de nosotros, este "proceso" parece sentido común. Es viejo sombrero. ¿Pero sabías que muchos equipos más pequeños no hacen esto? Es posible que un equipo de dos personas ni siquiera se moleste en controlar la fuente. ¿A quien le importa? Honestamente no es necesario. Los problemas solo comienzan a suceder cuando el equipo crece pero el proceso no.

Por supuesto, la optimización del proceso es como la optimización del rendimiento; sigue una curva exponencial inversa. La lista de verificación anterior puede eliminar el 80% de los defectos, pero después de implementarla, encontrará que otra cosa representa el 80% restante de los defectos. En nuestro ejemplo ficticio pero familiar, podrían tratarse de errores de compilación debido a tener diferentes entornos de compilación, lo que a su vez se debe al hecho de que no hay hardware estándar y los desarrolladores están utilizando bibliotecas de código abierto que se actualizan cada 2 semanas.

Por lo tanto, tiene tres opciones: (a) estandarizar el hardware y restringir severamente el uso de bibliotecas de terceros, que es costoso y puede afectar significativamente la productividad, o (b) configurar un servidor de compilación, que requiere la cooperación del grupo sysadmin y un desarrollador a tiempo completo para mantenerlo, o (c) dejar que los desarrolladores lo hagan ellos mismos distribuyendo una máquina virtual estándar y diciéndoles a los desarrolladores que construyan sobre eso. Claramente (b) es la mejor solución a largo plazo, pero (c) tiene un mejor equilibrio a corto plazo de confiabilidad y conveniencia.

El ciclo sigue y sigue. Cada "política" que ve generalmente se ha instituido para resolver un problema real. Como Joel Spolsky escribió en el año 2000 (en un tema completamente diferente, pero aún así relevante):

Cuando entras en un restaurante y ves un letrero que dice "No se admiten perros", puedes pensar que ese letrero es puramente prohibitivo: al Sr. Restaurant no le gustan los perros, así que cuando construyó el restaurante colocó ese letrero.

Si eso fuera todo lo que estaba sucediendo, también habría un letrero de "No Snakes"; Después de todo, a nadie le gustan las serpientes. Y un letrero de "No hay elefantes", porque rompen las sillas cuando se sientan.

La verdadera razón de que ese letrero sea histórico es histórico: es un marcador histórico que indica que las personas solían tratar de llevar a sus perros al restaurante.

Es lo mismo en la mayoría de los equipos de software (no lo diré todo): las políticas como "Es necesario agregar un caso de prueba para cada corrección de errores" casi siempre indican que el equipo históricamente ha tenido problemas con las regresiones. Las regresiones son otro de esos problemas que con mayor frecuencia se deben a la interrupción de la comunicación y no a la incompetencia. Siempre y cuando comprenda la política, es posible que pueda tomar atajos legítimos (por ejemplo, tuve que corregir 6 pequeños errores pero todos estaban en la misma función, por lo que en realidad solo puedo escribir un caso de prueba para los 9).

Eso explica por qué los procesos están ahí, pero no es toda la historia. La otra mitad es:

¿Por qué es tan difícil seguir el proceso?

Esta es en realidad la pregunta más simple de responder: es porque el equipo (o su administración) se enfoca en resultados repetibles y en minimizar los defectos (como se indicó anteriormente) pero no ha prestado suficiente atención a la optimización y automatización de ese proceso.

Por ejemplo, en la pregunta original, veo varios problemas:

• El sistema de control de revisión (CVS) es heredado por los estándares actuales. Para nuevos proyectos, ha sido reemplazado casi por completo por subversión (SVN), que se está eclipsando rápidamente por sistemas distribuidos como Mercurial (Hg). Cambiar a Hg haría que la ramificación y la fusión fueran mucho más simples, e incluso en mi ejemplo hipotético anterior, el requisito de compromiso diario sería mucho menos doloroso. El código ni siquiera tiene que compilarse, porque el repositorio es local; - De hecho, los desarrolladores más perezosos podrían incluso automatizar este paso si quisieran, configurando un script de cierre de sesión para confirmar automáticamente los cambios en el repositorio local.

• No se ha dedicado tiempo a automatizar el proceso de la máquina virtual. Todo el proceso de obtención, configuración y descarga de fuentes / bibliotecas a una máquina virtual podría ser 100% automatizado. Podría ser un proceso desatendido que ejecuta en un servidor central en algún lugar mientras trabaja en la corrección de errores en su máquina local (y solo usa la VM para asegurar una compilación limpia).

• Por otro lado, a cierta escala, la solución VM por desarrollador comienza a ser tonta y solo debe tener un servidor de integración continua. Ahí es donde entran los beneficios reales de productividad, porque (en su mayoría) libera a los desarrolladores individuales de tener que preocuparse por las compilaciones. No debe preocuparse por configurar máquinas virtuales limpias porque el servidor de compilación siempre está limpio.

• La redacción de la pregunta ("caso de prueba con todos los pasos") implica que hay algunas pruebas manuales en curso. Esto, nuevamente, puede funcionar para equipos pequeños con una carga de trabajo relativamente baja, pero no tiene ningún sentido a mayor escala. Las pruebas de regresión pueden y deben ser automatizadas; no hay "pasos", solo una clase o método agregado al conjunto de pruebas de unidad / integración.

• No hace falta decir que pasar de Bugzilla a un sistema de seguimiento de errores más nuevo (mejor) haría que esa parte de la experiencia fuera mucho menos dolorosa.

Las empresas no son necesariamente baratas o estúpidas simplemente porque no han resuelto estos problemas. Todo lo que saben es que el proceso actual funciona , y en algunos casos son reacios al riesgo y reacios a cambiar cualquier cosa al respecto. Pero realmente solo necesitan estar convencidos de los beneficios .

Si los desarrolladores pasaron una semana rastreando su tiempo en todas las tareas que no son de codificación, entonces podría sumarlo fácilmente, mostrarle a la administración que (por ejemplo) una inversión de 100 horas hombre y capital cero en una actualización a Mercurial elimine hasta 10 horas-hombre por semana en la resolución de conflictos de fusión, entonces eso es una recompensa de 10 semanas y seguramente lo aceptarán. La misma idea con servidores de compilación (CI) o mejor seguimiento de errores.

En resumen: los equipos aún no han hecho estas cosas porque nadie ha convencido a la gerencia de que es lo suficientemente importante como para hacerlo hoy . Así que toma la iniciativa y conviértela en una ecuación de costo-beneficio; descubra cuánto tiempo se dedica a tareas que podrían simplificarse / automatizarse con un riesgo mínimo, y calcule el punto de equilibrio y la rentabilidad final de una nueva herramienta o técnica. Si todavía no escuchan, entonces ya sabes cuáles son tus opciones restantes.

Si los desarrolladores pasaron una semana rastreando su tiempo en todas las tareas que no son de codificación, entonces podría agregarlo fácilmente, mostrar la administración ... y convertirlo en una ecuación de costo-beneficio, etc.

Por encima de la parte parece que vale la pena ampliar aún más.

Puedo confirmar que funciona. Los programadores lo usaron pocas veces en uno de los proyectos en los que trabajé y cada vez condujeron a los cambios deseados.

Mi impresión general fue que si se hace bien, este truco puede anular grandes cantidades de ignorancia e inercia de la gerencia.

Sin embargo, me gustaría señalar que la empresa en la que nosotros (los desarrolladores) tuvimos que recurrir a este tipo de enfoque de bricolaje era muy inmadura en cuanto a TI. En los vendedores de software más experimentados, vi cosas como esa principalmente realizadas por los propios gerentes. Y como regla, fueron más productivos en eso que nosotros los programadores. Mucho más productivo.

Si está trabajando en una industria fuertemente regulada, puede haber alguna razón para ese engorroso proceso: un día podría ser auditado y tendrá que mostrar todos sus registros para explicar quién solucionó ese error, cómo, quién lo revisó, quién realizó la prueba eso, etc ...

Entonces podría ser un mal necesario.

Por otro lado, si no hay justificación para ese proceso, aparte de tal vez una falta de confianza por parte de la administración, debe intentar hablar con su gerente y decirle cómo puede ahorrar tiempo (y, por lo tanto, dinero) para la empresa.

Nadie en su sano juicio que rechace un proceso más rápido y mejor si se explica correctamente.

Pero prepárate para defender tu argumento para justificar el cambio.

La mitad del problema es que estás usando herramientas obsoletas en un proceso, para las que no están diseñadas. Lo que describe es muy fácil de tener en los DVCS modernos, sin la tediosa tarea de crear una rama por error.

Otro problema es que claramente no estás en la línea de trabajo que disfrutas. Usted trabaja en mantenimiento, mientras que le gustaría el desarrollo. Se puede hacer poco al respecto además de cambiar el trabajo.

La disciplina de la ingeniería de software es inherentemente "todo sobre el proceso", por lo que preguntarse si "se ha convertido" de esa manera es como perder el punto.

Si bien la mayoría de los programadores prefieren molestarse con el mínimo absoluto de proceso, en la medida en que algunos aboguen por metodologías ágiles incluso cuando no resuelven los problemas que enfrenta su organización, es totalmente posible que una empresa decida utilizar " "procesos pesados ​​por razones comerciales sólidas, como" el cliente lo exige ". Esto es común si sus clientes son compañías de Fortune 500, universidades o agencias gubernamentales. Las recompensas de vender a estos clientes pueden ser lo suficientemente grandes como para justificar la sobrecarga del proceso adicional.

Su empresa es un punto de datos, y es imposible generalizar su experiencia en una tendencia de toda la industria hacia o lejos de procesos más pesados. La verdadera pregunta es, ¿qué equilibrio funciona mejor para su empresa, sus productos, sus clientes y usted, personalmente, como programador? Si no le gusta trabajar para esa compañía, instigue el cambio u obtenga otro trabajo.

Por la otra pregunta que he visto de usted hoy, parece muy descontento con su trabajo. No ha estado allí por mucho tiempo, solo puede decirle a su supervisor que cree que ha cometido un error, y es hora de que se separe antes de lo esperado.

Si eres bueno en tu trabajo, realmente no te será muy difícil encontrar uno nuevo y, sinceramente, si no hay una buena razón para que exista este proceso, probablemente consideraría mudarme también. El uso de CVS realmente sería un factor decisivo para mí, pero siempre hago la pregunta de control de fuente en la entrevista. Obviamente, no puedo conocer su situación, y puede ser imposible dejar un trabajo si tiene otras obligaciones.

Iba a hablar sobre cómo la ingeniería de software se está inundando con programadores muy malos, pero la situación que usted describe es horrible.

En mi experiencia personal, parte de este "proceso" que usted describe está acompañado de que la administración y la administración del sistema desconocen por completo las ineficiencias de los sistemas que están imponiendo a los programadores. Los ejemplos incluyen restringir la elección del sistema operativo, restringir el software utilizado, acceso a internet, privilegios administrativos de escritorio personal; Todas estas cosas son esenciales para un buen desarrollo.

Además, los requisitos de compatibilidad entre las "soluciones mágicas" empleadas por diferentes sucursales de empresas. Los ejemplos incluyen oficinas centrales que imponen un control de fuente centralizado, servidores de Outlook fuera del sitio y pautas de codificación o idiomas que podrían no ser apropiados para cada problema.

No es muy divertido mantener en marcha las ruedas de los gigantes de la empresa, pero he descubierto que en algunas empresas existen pequeñas burbujas de innovación, creatividad y brillantez.

Probablemente trabajas en una empresa orientada a procesos . En su lugar, trataría de encontrar una empresa orientada a los resultados , donde importa lo que haces, no cómo lo haces.

En mi empresa también tenemos un "proceso" (pero es muy simple). Pero cuando se interpone, rompo las reglas y omito los pasos. Nadie nunca me dirá nada mientras no rompa nada tomando atajos porque obtengo resultados.

¿Hay algún punto en el que el proceso se interponga y se convierta en un fin en sí mismo? ¿Eso es incluso ingeniería?

Literalmente, la mayoría de la ingeniería está juntando piezas bien establecidas en un orden establecido en respuesta a un problema particular. Esto es más obvio si le preguntas a un ME qué hacen todo el día. Confunde la ingeniería con la arquitectura o el desarrollo de productos en una etapa temprana (en cualquier campo). Tengo dos observaciones sobre tu pregunta.

1. Parece que has sido asignado a trabajos de corrección de errores, no a trabajos de arquitectura o diseño.
2. Parece que sus compañeros de trabajo han encontrado soluciones limitadas (combinando máquinas virtuales de corrección de errores) para que sean más eficientes, no parece estar siguiendo su ejemplo sensato.

Es simplemente un hecho que en cualquier esfuerzo constructivo que requiera una gran cantidad de personas, algunas personas pueden hacer el diseño y un grupo más grande 'hace' la implementación. Lo siento, pero estás en ese segundo grupo.

Como han señalado otros comentaristas, CVS no es la mejor herramienta para el trabajo de un modelo de desarrollo altamente ramificado, pero también noto que usted no es responsable de la fusión ... así que no se preocupe.

La mayoría de sus quejas esencialmente parecen ser "¡No quiero probar, antes, durante o después del desarrollo!" Analicemos sus pasos, punto por punto.

• Para corregir un solo error, primero obtengo una máquina virtual nueva y limpia. Un ambiente de prueba
• Luego creo una rama para esa única corrección de errores, basada en otra rama descrita en el informe de Bugzilla. - Duplica el entorno en el que se encontró el error ... ¿cómo es irrazonable?
• Instalo la rama en la máquina, la configuro. Arreglo el error. Lo reviso: el proceso de desarrollo básico
• ... dejándolo y la máquina para que otros lo prueben. - Su equipo de fusión probablemente quiera que esto pueda verificar la solución si la fusión se va hacia el sur.
• Luego tengo que entrar en el software de control de errores y explicar lo que hice : si estás en una tienda que no hace esto ... ¿por qué estás rastreando errores?
• y escribe un caso de prueba con todos los pasos. - Podría estar equivocado, pero esa es la dirección en la que todos los 'chicos geniales' van de todos modos
• Finalmente, alguien más lo fusiona con un lanzamiento. - Y varios de los pasos anteriores son para facilitar su trabajo

Obviamente, alguien más frente a usted hace una selección de errores para asegurarse de que un error que se encuentre no se repare en otra versión o se rompa en una versión posterior (para eso están los casos de prueba).

Lo único, incluso remotamente inusual o demasiado celoso sobre este proceso es lo de VM. Hay una posibilidad justa que se consideraría razonable si supiéramos en qué dominio trabajaba.

Interesante. ¿Tienes probadores? Deberían estar haciendo algo de eso. Soy uno, y donde trabajo tenemos una solución decente.

Para un defecto funcional, como está explicando, nuestro proceso es el siguiente:

1. Pruebo el defecto en una VM (ya sea informado por un cliente, o durante mis pruebas exploratorias, o w / e)
2. Se ha encontrado / reprobado el error.
3. Yo creo el error. Los errores incluyen:
   • Reproducción completa, desde el punto de instalación hasta el punto de ver el error.
   • Un enlace a una instantánea de la máquina virtual (si creo que el desarrollador lo necesitará ... lo tomo de todas formas, en caso de que lo soliciten).
   • Información del sistema, cualquier configuración especial que necesitaba hacer.
4. Ese error se asigna al desarrollador. Mientras están trabajando en una solución, yo:
   • Crea un caso de prueba
   • Escriba (o convierta) la prueba manual en una prueba automatizada

Luego espero una resolución y ayudo al desarrollador en cualquier forma que necesiten. Cuando vuelve como resuelto, yo:

1. Ejecute el caso de prueba automatizado y una versión manual (a veces) para confirmar la solución.
2. Cierra el error.

TL; DR: Si no tienes probadores, entonces necesitas algunos. Si tienes algunos, entonces no están 'haciendo su parte'.

Tom DeMarco:

... Mi primer libro de métricas ... la línea más citada es su primera oración: "No puedes controlar lo que no puedes medir". Esta línea contiene una verdad real, pero me siento cada vez más incómoda con mi uso. Implícito en la cita (y de hecho en el título del libro) es que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es.

... cuanto más se centre en el control, más probable es que esté trabajando en un proyecto que se esfuerza por ofrecer algo de valor relativamente menor.

En mi opinión, la pregunta que es mucho más importante que cómo controlar un proyecto de software es, ¿por qué estamos haciendo tantos proyectos que ofrecen un valor tan marginal? ...

Ingeniería de software: una idea ¿De quién es el momento?

"Luego creo una rama para esa única corrección de errores"

No es necesario hacer una bifurcación para la corrección de un solo error. Primero crea el error en bugzilla. Echa un vistazo a la rama de lanzamiento. Haz el arreglo. Realice la confirmación con el mensaje de confirmación que contiene el número de error, que actualiza el error y lo marca como "corregido, necesita prueba" o "corregido, probado, necesita fusionarse" adecuadamente, dependiendo de las palabras clave de texto escritas en el mensaje de confirmación. La base de datos de errores es el mecanismo de seguimiento perfecto para todos los cambios realizados y por qué se hicieron; Se pueden ejecutar informes desde la base de datos de errores para extraer esta información.

Creo que la mayor parte del proceso podría automatizarse , de modo que la máquina virtual y la creación de sucursales (incluida la compilación de código, la configuración de depuradores, etc.) se haya realizado por usted antes de comenzar a trabajar en el error.

Describir lo que hizo y cómo debe probarse vale la pena para todas las correcciones de errores. He descubierto que solo escribir el texto puede detectar problemas , ya que me hace pensar en el riesgo, etc.

Así que creo que el proceso puede ser un poco "exagerado", pero que el verdadero problema es la falta de herramientas automatizadas personalizadas para respaldar el proceso.

Hombre, tu proceso de pensamiento es correcto, ya que lo que describiste es completamente malo y una verdadera demostración de lo mal que pueden estar las cosas en el software. Sin embargo, estas son las buenas noticias, hay tantas compañías que practican Agile con verdadero espíritu. La empresa para la que trabajo es una de esas. Hay muchos en estos días y eso es una muy buena noticia.

Cuando sienta que las cosas realmente no están bien en su lugar de trabajo, hay dos cosas que puede hacer: puede influir en un cambio positivo o abandonar ese lugar y unirse a uno mejor.

CVS o cualquier sistema de gestión de configuración no está mal. Desafortunadamente, la forma en que se usa, sin saber realmente su propósito, causa este tipo de dolor en el! @ # $ Para toda la organización.

Para obtener una comprensión rápida de lo que realmente es Agile, lea detenidamente el libro "Prácticas de un desarrollador ágil" de Venkata Subramaniam. Está bien escrito en un lenguaje fácil de entender.

¡Te deseo buena suerte!