testing - Mal uso del término "Congelamiento de código"

process agile (9)

¿Estoy por analizar esto?

Sí.

Probablemente vamos. Realísticamente, deberías pensarlo dos veces antes de hacer cualquier cambio de código después del congelamiento. Los errores deben pasar una prueba de gravedad, más si la solución requiere cambios potencialmente peligrosos en la base de código o invalida la prueba que se ha realizado. Si no estás haciendo eso , entonces sí, te estás engañando a ti mismo.

Pero si no vas a arreglar ningún error, entonces congelar el código es algo sin sentido: simplemente compila y envía.

En última instancia, lo importante es que todos comprendan lo que significa la etiqueta, no la etiqueta en sí misma. Una gran y feliz Humpty-Dumpty ...

Solo tengo curiosidad si la comunidad considera que es aceptable usar el término "Code Freeze" para las situaciones en las que dejamos de desarrollar, excepto para probar y corregir errores.

Situación de desarrollo

Estamos terminando nuestro tercer y último sprint, que será seguido por un "congelamiento de código" y 2 semanas de prueba de Q / A. Es un gran lanzamiento y el desarrollo de algunos componentes ha trascendido los 3 sprints. Históricamente, a pesar de que lo llamamos un "Congelamiento de código", aún cometemos un código para corregir errores.

Problema

Cada versión intento y corrijo a mi gerente y compañeros de trabajo que deberíamos llamarlo "Congelamiento de funciones", porque es bastante obvio que vamos a encontrar errores y código de compromiso para solucionarlos tan pronto como comencemos las pesadas pruebas. Pero aún persisten en llamarlo "Code Freeze". A veces todavía tenemos errores conocidos y declaramos un "Congelamiento de código".

La definición de Wikipedia parece estar de acuerdo conmigo aquí

Análisis

Sospecho que llamar a estas situaciones "Code Freeze" es una especie de Pensamiento doble voluntario para proporcionar confianza falsa a los interesados. O simulamos estar en una situación de "Congelamiento de código" porque, según Scrum, después de cada sprint deberíamos tener una pieza de software enviable y esperamos que sigamos a Scrum. Entonces debemos llamarlo lo que Scrum espera en lugar de lo que realmente es.

Conclusión

¿Estoy por analizar esto? Me parece que no es saludable ignorar las realidades de las situaciones y debería renunciar a llamarlo algo que no es o solucionar el problema de raíz. ¿Alguien más ha tenido experiencias similares con Code Freezes?

Algunas personas que entran en metodologías de ingeniería adaptativas y ágiles como el scrum pueden no darse cuenta en qué se han metido.

La razón de ser una ingeniería ágil es liberar a sus clientes todo lo que se puede usar ahora y aumentar gradualmente su usabilidad y características.

Si se proyecta que su proyecto finalice en 18 meses, pero si pudiera tener cada vez más algo utilizable cada 2 meses, ¿por qué no lanzar características cada dos meses en lugar de esperar hasta el gran día sagrado de 18 meses de distancia porque de todas maneras el proyecto duraría 18 meses? .
El requisito de sus clientes podría cambiar, por lo que darles a sus clientes la oportunidad de cambiar de opinión con frecuencia, antes de que sea demasiado tarde, los resultados en clientes entusiasmados.
Alguien podría lanzar el módulo de código abierto de uno de sus módulos dentro de 10 meses y luego no tendrá que hacer mucho más sino integrar ese módulo.

Por lo tanto, los scrummers, o al menos los scrummasters y / o gerentes de proyectos / arquitectos son requeridos por la dinámica del scrum para modularizar ... modularizar no es lo suficientemente bueno; pero granularice el proyecto.

Debe personalizar los módulos al tamaño adecuado y proporcionar una especificación de interfaz de contrato para cada uno, de modo que los cambios dentro de un módulo se administren dentro de un módulo. Si su módulo por sí mismo o debido a la dependencia de otros módulos no es capaz de satisfacer una interfaz contractual, tiene que congelar el código para permitirle transmitir una interfaz de contrato versión 1 para que otros equipos puedan continuar aunque con características menores a las esperadas en la próxima versión general del producto.

Un congelamiento de código es un congelamiento de código.

Si el código se congela, experimenta retrasos de descongelamiento frecuentes, su maestro de scrum y el arquitecto del producto no se están comunicando o no están haciendo su trabajo correctamente. Tal vez, no tiene sentido tratar de impresionar o consentir a su administración que están usando alguna moda de la industria llamada programación ágil . O la gerencia necesita contratar arquitecto y scrum master que puedan diseñar y detallar el proyecto dentro de las habilidades del equipo, así como las expectativas de los clientes y las limitaciones tecnológicas del proyecto.

Creo que hay elementos de gestión y su maestro de scrum que no se dan cuenta de cuán crucial es un buen arquitecto incluso para un entorno de scrum y se niegan a contratar uno. Un buen arquitecto que puede escuchar y trabajar con el equipo es invaluable para el proceso de scrum porque tiene que adaptar constantemente la arquitectura a las cambiantes granularidades y expectativas.

También creo que hay elementos de gestión y su maestro de scrum que pertenece al otro espectro del universo de programación debido a malas experiencias con ciclos de desarrollo más largos como cascada, que por lo tanto piensan que el scrum está destinado a producir un producto en un mes y por lo tanto una investigación meticulosa en efectos de módulos cruzados no es realmente necesario. Se sientan, mojan sus dedos en el aire y logran un gran sprint.

Si su equipo está experimentando un descongelamiento frecuente de las congelaciones de código, quizás necesiten congelar el código de todo su proyecto y reconsiderar su estrategia, y ver que la causa se deba a su negativa a definir contratos de módulos que se ajusten a la granularidad de los módulos. ¿O están definiendo contratos de módulos para que las características de un módulo atascado puedan rarizarse actualmente para permitir que otros equipos o módulos continúen?

¿Ustedes tienen una estrategia UML que ayuda a descubrir las características proyectadas de un lanzamiento de proyecto y le permite ver los efectos de un módulo trenzado y luego ver qué módulo necesita enfoque para alcanzar el nivel deseado de lanzamiento del producto? ¿Asistes a scrums y sprints y no tienes una imagen de un UML para mostrar lo avanzado o retrasado que eres para que te lleves feliz o ciegamente? ¿O su maestro de scrum le diría a la sala de sí o no, hmm ... ese módulo parece importante, sin tener una idea clara de cuáles son los módulos más vagabundos en relación con una versión de producto.

Un congelamiento de código de liberación de producto se logra mediante la congelación progresiva de módulos. Tan pronto como se completa un módulo, se realiza una prueba del producto para garantizar que el módulo cumpla con su contrato y que el módulo esté congelado por código para decir la versión 2.1. Aunque el trabajo avanza en ese módulo para 2.2, el proyecto en general no debería depender de 2.2 sino de 2.1. La estrategia es minimizar el número de módulos cuyos contratos deben descongelarse cuando se prueba una versión del producto y si la versión del producto debe reducir sus características. Si la congelación modular progresiva no ayuda a su equipo de desarrollo ... o el producto es tan complejo y su administración no espera el número de iteraciones para lograr una versión adecuada o la arquitectura modular y la estrategia necesitan un replanteamiento serio.

Creo que, en realidad, son más correctos en su interpretación. Una congelación de funciones, para mí, sería un alto a la introducción de nuevas características, pero las características actualmente en desarrollo podrían continuar hasta su finalización o podría programar algún trabajo de refactorización para eliminar la deuda técnica sin generar nuevas características. Una congelación de código detiene todos los nuevos desarrollos, incluida la refactorización: el único código nuevo permitido es corregir los errores encontrados durante el control de calidad. El último parece ser lo que está haciendo tu equipo.

Mientras que "Code Freeze" puede tener un significado nublado y es, como se ha mencionado, más acertadamente un "Feature Freeze" al considerar proyectos / lanzamientos individuales, TIENE un lugar en un despliegue más grande e integrado donde otra entidad es responsable del embalaje y / o implementando múltiples lanzamientos de software de varios equipos. El "Congelamiento de código" les da tiempo para asegurarse de que los entornos estén alineados y de que se tengan en cuenta todos los paquetes. La "Congelación de código" también significa que no se está produciendo nada más que cambios de "show stopping". Todo lo demás se manejará en la próxima versión de mantenimiento.

En un mundo perfecto, las pruebas con guiones se habrían completado antes de este punto y se habría tenido tiempo de implementar las últimas correcciones y volver a probar. Todavía tengo que ver que esto suceda en cualquier "globo-corp". Los probadores (comerciales) prueban hasta e incluso después del despliegue y el "Congelamiento de código" se convierte en una señal para que intensifiquen sus esfuerzos y registren todo lo que han estado esperando. En algunos casos, es una señal para que comiencen las pruebas.

Realmente, "Code Freeze" es solo negocios para "Aquí hay Tygers". ;-)

Sí, es un pensamiento excesivo. Sí, es un nombre inapropiado.

Si el código no está roto / desordenado, no lo tocará, y si lo está, lo arreglará. Esa es exactamente la misma situación que si no estuvieras en congelación de código. Sí, es "congelación de requisitos" o "interrupción de integración" que son antipatrones. Es un punto en el que dejar de incluir nuevas funciones en la próxima versión, que es valioso en el lado de las ventas / marketing / customersupport. Pero probablemente deberían llamarlo "prelanzamiento".

Lo que debería ocurrir es que siempre hay algunas versiones liberables del sistema en el control de la versión, y la empresa elige una para enviar.

el nombre Lean para "congelación de código" es "desperdicio".

cuando codificamos la congelación, el repositorio está bloqueado, ojalá se corrijan todos los errores que se pretendía corregir, y los probadores a una ronda completa de pruebas antes de la bifurcación y la construcción hasta la producción. si hay errores pendientes programados para esta iteración, los clientes potenciales estarán respirando en tu cuello hasta que se cierre, o se considere no crítico y se retrase una iteración. Entonces, sí, está realmente congelado.

Usamos el término "Característica completa". Todas las funciones están codificadas y son funcionales, pero nos dirigimos a un pase de prueba para confirmar que no hay errores. Si hay errores, los encontraremos, los solucionaremos y volveremos a probar. Después de estar satisfechos con el resultado, estamos "Code Complete".

En tu comentario, mencionaste la palabra ''sprint''. Eso me dice que puedes estar usando la metodología Scrum (o cualquier otra metodología Agile). En Scrum casi no se congela nada :) Flexibilidad, identificación y mitigación de riesgos y, sobre todo, en términos de ingeniería, la integración continua importa mucho en Scrum.

Dado esto, el equipo debe ser multifuncional y el código se integrará continuamente. Como resultado, es posible que no tenga cosas como ''congelar el código''. Solo tiene un producto liberable al final del sprint. Debería haber sido probado continuamente y ya debería haber recibido los informes de errores que ya debería haber solucionado.

Bueno, esto es teoría. Sin embargo, los buenos equipos de scrum no están muy lejos de la teoría, ya que el scrum se trata principalmente de principios. No hay demasiadas reglas.

Personalmente, no voy a dividir demasiados pelos en la terminología, pero la intención detrás del término. Sin duda, el término se usa para identificar una etapa en el SDLC, en su organización. Hablando estrictamente de acuerdo con Scrum, no tiene una fase de corrección de errores. En caso de que dedique uno o más sprints para corregir errores, este término puede significar que "no se incluirán retrasos en la función en el sprint, sino solo correcciones de errores". Esto se puede manejar fácilmente en la (s) reunión (es) de planificación de sprints (y preplanificación) y el equipo ni siquiera tiene que preocuparse por la terminología. Mejor aún, esta terminología / intención ni siquiera tiene que ir más allá del Product Owner.

He trabajado en un proyecto (cascada) en el que hemos congelado la característica Y el congelamiento del código.

La congelación de funciones significa el comienzo de un período de corrección de errores. También se creó una nueva sucursal para la nueva versión para que pudiéramos implementar características, es decir, este es el momento en que la empresa comienza a trabajar en la nueva versión. No se implementan nuevas características, solo se reparan los errores.

La congelación de código se produce cuando QA piensa que el producto está en condiciones de liberación (es decir, no conoce ningún error grave). Antes de un ciclo de prueba final, se anuncia un congelamiento del código (recuerde que un ciclo de prueba puede llevar una semana). Si la prueba tiene éxito, se convierte en el producto lanzado. Si falla, los nuevos errores son corregidos. Estos controles están supervisados por arquitectos y gerentes, y el riesgo de cada línea está prácticamente documentado. Luego, el ciclo de prueba se inicia nuevamente.

Resumen: después del congelamiento de la característica, solo puede verificar las correcciones de errores. Después de la congelación del código, solo puede registrarse en casos excepcionales.