Metodo MIKADO - aplicación práctica para simplificar una KB.
Hace unas semanas hablé del metodo MIKADO, que me resulta util para diversos proyectos.
La semana pasada, tenía que hacer una simplificación en un sistema que conozco bastante, que tenia varias tablas en el modelo de datos, que habian sido utiles en el pasado, pero ahora ya no se utilizaban mas.
Es en este tipo de limpiezas, donde es común empezar a borrar algo y que salte que se necesita corregir otra cosa. Al corregir la segunda, vemos que hay una tercera cosa a arreglar y se pueden disparar cambios en cascada.
El problema de los cambios en cascada es que muchas veces termina siendo tan grande y difícil de controlar, que muchas veces el riesgo del cambio es muy grande y no se hace nada, o se acaba el tiempo para hacerlo y todo queda como esta.
El problema era asi:
En unas 6 horas debía simplificar una tabla llamada Proyectos que hacía referencia a varias tablas que ya no se quieren usar mas.
Al final de esas 6 horas, debía quedar todo operativo y funcionando con los cambios en producción.
1)Anoto el objetivo en en grafo de dependencias.
2)Hago un cambio de las hojas del grafo de dependencias
3)Si al hacerlo descubro una dependencia, VUELVO TODO AL ESTADO ANTERIOR y anoto la dependencia en un grafo de dependencias.
4)Si no hay dependencias (y todo funciona bien) marco el cambio como realizado
5)Subo el cambio al server (si lo amerita)
6) Si quedan cambios sin marcar como realizados voy al paso 2)
7) FIN
Lo primero y fundamental es crear una tener una version donde todo especifique y compile sin errores a donde volver cuando encuentre alguna dependencia.
Para esto, lo que yo hago es crear una Frozen Version antes de empezar la limpieza y le pongo un nombre que me recuerde que fue.
Luego creo la primer versión de mi grafo de dependencias, que solo tiene lo que quiero lograr.
Analizo y encuentro que tengo que cambiar una formula y eliminar un atributo para simplificarlo. Anoto las dependencias en el grafo.
Miro el modelo de datos y detecto otros cambios que debo realizar y los anoto en el grafo. Hago el cambio de unas formulas, compilo todo y subo el cambio al servidor. Tambien creo un nueva version congelada a la cual volver.
Cuando todo está marcado, ya está el cambio listo.
Puedo cortar el proceso de mejora en cualquier momento (pues en todo momento tengo una KB operativa) y puedo retomar en cualquier momento la mejora.
Si me quedaron algunos nodos sin marcar, no hay problema, pues puedo retomarlo mas adelante.
En una forma de hacer grandes cambios en forma paulatina y sistemática.
La semana pasada, tenía que hacer una simplificación en un sistema que conozco bastante, que tenia varias tablas en el modelo de datos, que habian sido utiles en el pasado, pero ahora ya no se utilizaban mas.
Es en este tipo de limpiezas, donde es común empezar a borrar algo y que salte que se necesita corregir otra cosa. Al corregir la segunda, vemos que hay una tercera cosa a arreglar y se pueden disparar cambios en cascada.
El problema de los cambios en cascada es que muchas veces termina siendo tan grande y difícil de controlar, que muchas veces el riesgo del cambio es muy grande y no se hace nada, o se acaba el tiempo para hacerlo y todo queda como esta.
El problema era asi:
En unas 6 horas debía simplificar una tabla llamada Proyectos que hacía referencia a varias tablas que ya no se quieren usar mas.
Al final de esas 6 horas, debía quedar todo operativo y funcionando con los cambios en producción.
Breve resumen del Metodo MIKADO.
Consiste en siempre dejar una version operativa, dando pequeños pasos.1)Anoto el objetivo en en grafo de dependencias.
2)Hago un cambio de las hojas del grafo de dependencias
3)Si al hacerlo descubro una dependencia, VUELVO TODO AL ESTADO ANTERIOR y anoto la dependencia en un grafo de dependencias.
4)Si no hay dependencias (y todo funciona bien) marco el cambio como realizado
5)Subo el cambio al server (si lo amerita)
6) Si quedan cambios sin marcar como realizados voy al paso 2)
7) FIN
Como hacerlo con GeneXus?
Lo primero y fundamental es crear una tener una version donde todo especifique y compile sin errores a donde volver cuando encuentre alguna dependencia.
Para esto, lo que yo hago es crear una Frozen Version antes de empezar la limpieza y le pongo un nombre que me recuerde que fue.
Luego creo la primer versión de mi grafo de dependencias, que solo tiene lo que quiero lograr.
Analizo y encuentro que tengo que cambiar una formula y eliminar un atributo para simplificarlo. Anoto las dependencias en el grafo.
Miro el modelo de datos y detecto otros cambios que debo realizar y los anoto en el grafo. Hago el cambio de unas formulas, compilo todo y subo el cambio al servidor. Tambien creo un nueva version congelada a la cual volver.
Elimino una tablas que ya no se deben usar mas y detecto que también hay que corregir dos atributos que están en dicha tabla que también hay que eliminarlo de otras transacciones. Lo anoto en el grafo y vuelvo a la version anterior.
Sigo trabajando, agregando en el grafo, volviendo atrás cuando es necesario y trabajando solucionando las dependencias de abajo a arriba.Que ventajas tiene esta forma de trabajo?
El metodo es muy simple. Pequeños pasos que mejoran, pero si rompo algo, documento y volvo atrás a una situación conocida.Puedo cortar el proceso de mejora en cualquier momento (pues en todo momento tengo una KB operativa) y puedo retomar en cualquier momento la mejora.
Si me quedaron algunos nodos sin marcar, no hay problema, pues puedo retomarlo mas adelante.
En una forma de hacer grandes cambios en forma paulatina y sistemática.
Comentarios
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.