Agil o no tan Agil - Metodologia de Desarrollo con GeneXus

En Concepto, hemos experimentado diferentes formas de entrega de los cambios programados a los clientes, que nos piden nuevas funcionalidades. Existe una tensión natural, entre la ganas de entregar la funcionalidad en forma rápida y tener un proceso controlado y documentado.
Al estar certificados ISO-9001:2000, tenemos además que cumplir con varios registros para garantizar la trazabilidad y satisfacer a los auditores que nos controlan.
Según nuestra nomenclatura interna, tenemos los "consolidados" (no tan ágil) o los "upgrades" (ágil).

Consolidados
Los consolidados, consiste en tener una o mas KB en las cuales se realizan los cambios de programación y cada un periodo determinado (entre 2 y 6 meses) se consolidan todos los cambios (todas las transacciones mas los demás objetos modificados) en la KB desde la que se instala (llamada consolidado).
Luego que se tienen todo consolidado se realizan los siguientes pasos:
  • Verificación de la Reorganización (Que haga todo lo que cada integrante cambio y nada mas de lo que se quiere cambiar)
  • Especificación de los programas (corrregir los problemas que puedan aparecer)
  • Generación e instalacion de programas (instalar en ambiente de test)
  • Testeo general (todo el grupo de desarrollo testea la aplicacion, lo cambiado y lo no modificado, testeandose ciclos de trabajo)
  • Documentar Instalacion y prueba de la instalacion
  • Generación de la documentación de usuario
Upgrades
Se hacen con frecuencia aproximada de 15 dias.
  • Verificación de la Reorganización (Se verifica que la reorganización realice todo lo que se cambio y nada mas de lo que se quiere cambiar)
  • Especificación de los programas (Se especifica solamente los objetos que se consolidaron que son pocos y los que se saben que van a estar afectados. No se hace un build all.)
  • Generación e instalacion de programas (Se generan e instalan los programas que se necesitan (tratamos que sean pocos)
  • Testeo (Se prueban los programas cambiados y si vemos que algun cambi puede tener algun efecto colateral, se testea tambien un ciclo de trabajo)
  • Documentacion de instalacion y prueba de instalacion (Es igual que en el consolidado, pero generalmente es mas chica y controlada.)
  • Generación de documentación de usuario (Es igual que en el consolidado, pero con muchos menos cambios.)

Cuando usar consolidados o upgrades.

Existen momentos en que es necesario optar entre la forma de hacer llegar un cambio a los clientes.
En algunos casos es bastante obvio, por ejemplo si se cambia la versión de Genexus o de los generadores, no hay otra opción que hacer un BUILD ALL, por lo que es necesario utilizar la metodología de Consolidados

En el caso de hacer un arreglo en un objeto, que no cambia la estructura de la base de datos, parece mas razonable hacerlo por un upgrade.

Comparacion de Metodologias.

Ventajas de los consolidados.
Esta metodología, tiene la ventaja de que todos los objetos son generados con la ultima version. Es mas facil mantener sincronizados los objetos y tener bien claro que es lo que tienen instalado los clientes.

Desventajas de consolidados
La principal desventaja que se acarrea es que al realizarse un build all, generalmente se generan muchos programas. Con dicha regeneración es facil introducir errores en programas que funcionaban correctamente. Muchas veces, son programas que no fueron modificados, pero se ven afectados, por los cambios introducidos (por nuevas versiones del generador, del especificador, cambios en la navegación, cambios de propiedades, etc).

La segunda desventaja (creo que la mas importante) es que hay que testear todos los programas, lo cual siempre es muy dificil.

Ventajas de Upgrades
Se instala lo menos posible y por lo tanto hay que testear poco.

Desventajas de Upgrades
No es aplicable en todos los casos.

Conclusiones.
En la práctica, lo que estamos realizando es la instalación de Upgrades, con una frecuencia quincenal o mensual y Consolidados, cada vez que nos cambiamos de versión del generador o build.

Creemos que con esta forma de trabajo, logramos entregarle la funcionalidad mas rápido a los clientes y también mantenemos bajo control el proceso de desarrollo. Durante el año pasado (2006) probamos esta metodología en uno de los grupos de trabajo de Concepto y en la encuesta anual que le realizamos a nuestros clientes, los mismos mostraron conformidad con la nueva metodología, y hubo opinión unánime en que se había bajado la tasa de errores.

Es algo en lo que vamos a seguir trabajando e investigando.

Comentarios

  1. Hola! Estaba buscando gente latinoamericana interesada por el desarrollo ágil y encontré este post :o)
    Estoy organizando junto a otro entusiastas ágiles la conferencia Agiles 2008 en Buenos Aires, Argentina. Si te interesa el tema y te da ganas de participar (ojalá dando una charla o tomando parte en un debate), porfa visitá la página.

    Saludos!!
    Alan

    ResponderEliminar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

El Sordo

StackOverflow Documentation

Paleta de colores en GeneXus