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.