Metodologías ágiles y gestión del cambio: propuestas (3 de 3)

• Establecer una herramienta visual de seguimiento y control de las historias de usuario (nada que ver con la imputación de horas que ya está hecho en Navision) para ver de un vistazo el estado de cada tarea a nivel semanal o por iteración por parte de los jefes de proyecto en formato visual (por medio de post-it, tablero Kanban). Hay muchas, una de ellas podría ser iceScrum o Trello.
• Podríamos repartir las tareas si son muy pequeñas durante una semana y situarlas en el tablero aunque sean de diferentes proyectos.
• Levantar la mano ante las posibles desviaciones que se puedan producir e informar al cliente en la ejecución de proyectos (tanto de implantación como de desarrollo).
• Formación en metodologías, las herramientas y versiones que aparezcan y que se vayan liberando de los productos que utilicen el equipo de trabajo.
• Hacer entender al cliente que entre las tres variables de funcionalidad, coste y tiempo solo podrá elegir dos de ellas, nunca las tres. Aunque siempre habrá que llegar a un equilibrio entre las tres variables.
• Para cualquier tipo de implantación o desarrollo siempre exigiría una BD de pruebas en cliente (incluso lo exigiría por contrato) para que los desarrollos que se realicen siempre se pongan en esta BD de pruebas e inicialmente nunca en la de producción directamente porque por mucho que hayamos probado siempre será el cliente (Product Owner) quién dé el visto bueno. Nunca hacerlo en la BD de producción.
• En todo diseño de interfaz de usuario se podría utilizar una herramienta de Mockups para modelar un boceto.
• Ejemplo de pizarra o tablero si quisiéramos organizar el desarrollo de parches para un producto software, se podrían incluir las siguientes columnas:

• Hay que probar y en la medida de lo posible automatizar las pruebas. Muchas veces es difícil preparar casos de prueba reales tal y como el cliente realizará después de la entrega. Sin pruebas, no hay manera de saber que el código funciona (ni con pruebas tenemos seguridad, pues imagínate sin ellas) y muchas veces se entrega código no probado lo suficientemente bueno. Además, en este punto también se puede descubrir grandes cambios o en la funcionalidad que tocarán gran parte. Aquí es donde cobra vital importancia ir entregando funcionalidad lo más rápido que se pueda. En este punto es imprescindible la cooperación de product owner.

Bibliografía

Roberto Canales Mora. Informática profesional. Ed. Starbook. Roberto Canales Mora

Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI. Javier Garzás, Miriadax