Cambio de requerimientos: Es conveniente renombrar todo?
El usuario me plantea hacer una determinada funcionalidad, supongamos que se relaciona con el manejo de SOBRES y defino algo como
Tabla de Sobres
*SobreID
SobreRemitente
SobreDireccion
SobreFechaHora
Defino dos o tres tablas relacionadas y también hago programas del tipo
Trabajar con Sobres
Recibir un Sobre
Modificar Sobre
Se instala la funcionalidad en ambiente de pruebas y el cliente lo prueba y lo acepta.
Pocos dias antes de poner en producción, el cliente decide que quiere generalizar el uso de lo desarrollado para el manejo de sobres, para el manejo de paquetes (son sobres + cajas + bolsas)
Lo que pide es "un cambio chiquitito" que en todas las pantallas, donde dice SOBRE, se cambie por PAQUETE.
Si accedemos solo a lo que nos dice el cliente, nos va a quedar una tabla llamada Sobres, con contenido de paquetes y atributo con nombre SobreID, que en realidad va a tener el ID de un paquete.
Se analiza el alcance del cambio y tenemos
0) No cambiar nada (0 dias de trabajo)
1) Cambiar las pantallas y listados y documentación (1 día de trabajo)
2) Cambiar las pantallas, listados, documentación y nombre de programas (2 días)
3) Cambiar pantallas, listados, documentación, nombres de programas, atributos y tablas (4 días)
Esta planificada una puesta en producción en tres días.
Que hacen en estos casos?
Se trata de maximizar la satisfacción del cliente, minimizando el esfuerzo realizado y tratando de dejar un sistema lo mas entendible y mantenible posible.
1). Luego se agenda para mantenimiento evolutivo 3)
ResponderBorrary de paso se toma al usuario por el cuello, se lo aprieta contra la pared y golpeandolo compulsivamente se le grita en la cara "me habías dicho que eran Sobres, SO-BRES, no paquetes, PA-QUE-TES. Sobre no es Paquete, entendes?"
Justo estoy en una situacion "hipotetica" parecida :)
ResponderBorrarCreo que haría la 1 para que el cliente arranque y luego me parasaría meses arreglando todo rogando no perder datos... que mal lo mío!
Atte.
Nicolás
Nicolás:
ResponderBorrarEn este tipo de problemas no hay una solución buena y otra mala, sino que todas tienen pros y contras.
Siempre que sea posible, intento hacer la solucion mas completa lo antes posible, de forma que si aun no se salio en produccion, se pueda postergar dicha salida en produccion y tener un sistema mas facil de mantener en el futuro.
El concepto de "deuda tecnica" aplica en este caso. Todo lo que no pagues como costo de mantenimiento a corto plazo, lo vas a tener que pagar (y con intereses) a medida que tengas que hacer todos los arreglos a largo plazo. Y si nunca lo haces, vas a pagar el costo de tener un software un poco mas dificl de mantener y de entender.
Mi experiencia indica que es mas redituable arreglar y ajustar todo lo antes que se pueda, pero esto no siempre es posible, pues hay plazos del cliente que tambien hay que cumplir.
Si se opta por la opcion 1), es bueno dejar registrado el cambio para poder hacerlo en tiempos de carga menor de mantenimiento.
Hace ya mucho tiempo me pasó, hice un export (xpz), descomprimir, editar, search and replace. Ahi es donde no me acuerdo bien si hice import con análisis de impacto o hice una KB nueva y migre los datos. Sólo me llevo un rato lo que recuerdo (un día o menos), el problema es hacer review de cambios y probar casi todo again. Si tienes pruebas automatizadas te podría ayudar a bajar los tiempos de volver a probar todo.
ResponderBorrarWhat! We me escapó 'esta planificada puesta en producción en tree días'.
BorrarPara ese caso.a los usuarios le pongo un postit en el.monitor en donde dice 'donde dice sobre es paquete', y en algún momento en paralelo se harán las cosas bien, si quien te da la info para los requerimientos no entiende cómo funciona justamente su sistema/negocio el que desarrolla no puede hacer maravillas. En la medida que se pueda hay que educar también al cliente, cuanto cuestan las cosas y porqué cuando se hace relevación de requerimientos pensarlo bien es importante, invertir en pensar bien al inicio te ahorrará tiempos y problemas a futuro.
A veces puede usarse postit, y otras veces esta solucion no sirve.
BorrarLo importante es registrar esto como algo que esta en deuda de corregirse y luego tener un plan para achicar la deuda.
Nosotros aun no encontramos la mejor forma (o una forma sistemática) de registrar y manejar estas mejoras. La estamos buscando..
El CATEGORY es una buena alternativa para organizar estas cosas :)
BorrarEn KB chicas, usar category es una buena opcion.
BorrarLas categorias tienen la desventaja que cambian el objeto (y su fecha de actualizacion), por lo que cada vez hay que subir el objeto al server, se vuelve a especificar, etc. Todo esto enlentece todo el proceso de build innecesariamente y en KB grandes, esto puede ser un problema grande.
Seria mejor tener una "Lista de objetos" que haga referencias al objeto y no lo modifique, de forma que no produzca estos problemas.
Buen tema, porque pasa seguido
ResponderBorrarYo cambiaría atts, tablas y etiquetas, dejaria los programas para otra etapa. Me parece mejor que cada entidad sea representativa de la realidad.
Igualmente, si tomamos la precaución de usar siempre las propiedades descriptivas de los atts, el trabajo se alivia bastante
Guillermo, coincido pues pasa mas a menudo que lo que uno desea.
BorrarEl cambio en la base de datos, creo que es lo mas influyente en el diseño futuro del sistema, por lo que tu prioridad parece acertada. Con Genexus es relativamente fácil de arreglar el nombre de los atributos y tablas, por lo que podría hacerse sin mucho costo.
Este tipo de problema tiene la cualidad de ser acumulativo, y empeora con el tiempo. Si tengo un tabla que se llamaba SOBRES y luego se llama PAQUETES, puede quedarme programas con variables &SobreId basada en el atributo PaqueteId, ya se hace mas difícil de entender.
Si se juntan varios de estos cambios de nomenclatura, se complica el sistema en forma innecesaria.
En Genexus no es fácil renombrar variables, por lo que este trabajo convendría como dijo David (export . search&Replace e import).
Arreglar documentación, casos de pruebas, consultas externas, etc, es todo un trabajo también, pero conviene arreglarlo lo antes posible.
100%... el XML nos ha salvado a todos en estas tareas masivas :)
BorrarUn tema a tener en cuenta son los Pattern, por ej. con K2B hemos tenido problemas porque toma la descripción la 1ra vez y la clava en las propiedades del label, en lugar de usar =Att.ContextualTitle o lo que corresponda, así que quedan estáticas.
Eso es siempre un gran problema y creo que es un error enorme de K2B
Si, los patterns son un tema adicional a toda esta problematica.
BorrarGeneralmente manejan bastante bien el cambio de nombres en atributos, pero es cierto que algunos no manejan tan bien el cambio de etiquetas y otras propiedades.
En el caso del =Att.Contextualtitle, no deberia ser un cambio complejo para K2B y habria que pedirlo.
De acuerdo Guillermo. Lo tomamos como pedido. Te avisamos cuando este el cambio.
BorrarSaludos!!!.
Genial Fede, mil gracias !
Borrar