Simple perú

Calle el Boulevard 141

oficina 1006

Santiago de Surco

by Simple Perú

Desarrollo de software bajo principios ágiles (Parte II)

02/10/2020

Continuando con nuestro punto de vista sobre cómo se alinea el desarrollo de software con los principios ágiles, trataremos de exponer nuestra experiencia relacionada a los cambios. Cambios, mejoras o nuevos requerimientos de desarrollo que pueden afectar el tiempo estimado y hasta los costos del proyecto. El segundo principio para el desarrollo ágil de software nos dice que debemos aceptar los cambios, incluso en una etapa avanzada de desarrollo, viendo el cambio como una oportunidad. ¿Qué tan cierto es eso? ¿sólo porque lo solicitan un cambio debemos desarrollarlo, porque nuestro principio ágil no los pide? A continuación, trataremos de responder estas incógnitas. 

 

Los que tenemos experiencia en proyectos de desarrollo de software, sabemos que es casi improbable que el usuario final o quien aprueba el proyecto no solicite cambios, mínimos o mayores durante la etapa de desarrollo; recordemos que para entrar a dicha etapa ya tenemos el requerimiento claro, las vistas, reglas de negocio y todo lo necesario para iniciar el desarrollo, sin embargo, es cierto que en cualquier momento, inclusive durante presentaciones de avance nos pueden solicitar cambios, eso es una realidad y según nuestro lineamiento ágil, debemos aceptar, pero debemos evaluar si estamos en capacidad de realizarlo (contrato previo) o autorizados para hacerlo, bajo la óptica de estar autorizados, es nuestra responsabilidad como gestores de proyectos ver todos los frentes previos al inicio de desarrollo a fin de minimizar lo más que se pueda este tipo de solicitudes. Es aquí donde vinculamos y remarcamos una etapa muy importante antes de la etapa de desarrollo: la etapa de análisis, una muy buena práctica es no solo involucrar a los usuarios finales, desde el Jefe hasta el operario que utilizará el sistema, sino también a los usuarios (stakeholders) o áreas que se ven afectadas positiva o negativamente en todo el flujo que formará parte del requerimiento, esto minimiza sorpresas futuras de algunos de los stakeholders y por lo tanto minimiza el riesgo de cambios mayores.

 

 

Al igual que la identificación clara del requerimiento con el involucramiento de todos los stakeholders, otra muy buena práctica es la presentación de todos los prototipos que se esperan que se desarrollen; en este caso, se tendrá un feedback importante porque el usuario podrá revisar los flujos en las futuras vistas y se podrá corregir o agregar previo al desarrollo; hay que recordar que la experiencia del gestor para la extracción e interpretación de la información es muy importante, dado que será el vínculo del área usuaria y equipo de desarrollo.

 

Dado que el objetivo es brindar un producto que le agregue valor al área usuaria, es importante escuchar y si el cambio solicitado es parte de su flujo de trabajo, que por algún motivo no se representó, es nuestro deber poder coordinar para que de una u otra manera se implemente el nuevo requerimiento, ya que con eso se daría un valor real al producto final

Volver