Muy bonito todo pero...

Bien, ya hemos terminado nuestra aplicación y esta funciona más que bien... ¿Ya somos los mejores programadores del mundo? ¡Pero claro que no! Si apenas es que hemos empezado. Hoy vamos a tocar uno de los temas que a muchos desarrolladores me incluyo no nos agrada mucho pues usualmente conlleva aún más quebraderos de cabeza que el iniciar un proyecto: el cambio.

No, no estamos hablando del típico cambio que nos ofrecen los políticos en cada periodo electoral, estamos hablando de cambios en nuestro software. Pero... ¿Y si todo funciona perfectamente? ¿Por qué lo he de cambiar? Esa pregunta se la tendría que hacer tu jefe a sí mismo, pero como es tu jefe estoy seguro que no se la hará así que acostúmbrate, el cambio es la única constante en el desarrollo de cualquier sistema y debes de estar listo para aplicarlo así que... ¡No te preocupes! Aquí enlistaremos algunos de los pasos que puedes seguir para no morir en el intento.

Requerimiento vs. Casos de Uso (rematch)

via GIPHY

¿Ya no recuerdas qué es un caso de uso y qué es un requerimiento? Bueno, no estás solo, a mi también me pasa mucho. Así que aquí vamos de nuevo:

• Requerimiento: cosa específica que tu sistema tiene que hacer de una manera correcta.
• Caso de uso: describen qué es lo que tu sistema debe de hacer para cumplir una meta o tarea de nuestro cliente.

¿Aún tienes dudas? Pásate a la anterior entrada: Dale justo lo que necesita

Todo se derrumbó

via GIPHY

Son las 8:00 A.M., ni siquiera te has tomado tu primer café cuando tu jefe llega y te dice que tienes que cambiar algo de tu software, ¿por qué tanta violencia? Bueno, la vida es así, puedes elegir llorar o ponerte manos a la obra pero como la recepcionista vio todo y realmente te gusta prefieres ponerte manos a la obra. Muy bien, así se hace pero... ¿Por dónde empezamos?

• Cambia tus casos de uso: una vez que los nuevos requerimientos llegan lo más sensato es modificar los casos de uso que estaban ya prestablecidos, recuerda que los casos de uso deben de tener sentido para tí y si un caso te resulta confuso reescríbelo. Habrá ocasiones en que tu path alternativo toma cierto protagonismo y ahora es tu path principal, recuerda que esto es completamente válido y será una decisión que tomarás con más frecuencia de lo que piensas.
• Revisa tus nuevos escenarios: los escenarios no son otra cosa más que un path individual de principio a fin, este puede seguir un diferente camino pero cada uno de ellos será un escenario. Tendrás tantos escenarios como paths alternativos.
• Mantente atento: a veces un cambio en los requerimientos muestran puntos débiles en tu sistema de los cuales no estabas ni enterado así que revisa que todo esté funcionando correctamente antes de entregar esta nueva versión. Tu software no debe de hacer otra cosa más que mejorar con cada cambio. 

¡Y ya está! Sí, esta entrada no fue tan larga pero es lo que hay. Tampoco te iba a hablar de algo que se supone que ya deberías de saber.

¡Nos vemos a la vuelta!

Recuerda que siempre puedes visitar la página de O'REILLY y comprar el libro del cual estos post están basados.