[vc_row][vc_column width=»1/1″][vc_column_text]
“La vida es muy corta para escribir cada detalle”
De acuerdo al desarrollo Agile, el tener una documentación pesada en la captura de requerimientos no funciona pera el desarrollo de software. Los clientes o las personas que quieren el software raramente saben que es lo que quieren. Los equipos raramente construyen lo que se necesita. Por esto, pasar mucho tiempo y energía discutiendo que se va a escribir, en lugar de hacer lo que se necesita hacer, se considera una pérdida de tiempo.
Algunas consideraciones:
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width=»1/1″][vc_column_text]Los requerimientos cambian, ocurre que el usuario describe una necesidad y esta puede cambiar en el tiempo, pues los negocios son dinámicos. Una funcionalidad que antes era requerida, hoy cambio tal cual fue definida. Las metodologías agiles proponen de que lo único constante es el cambio y le dan la bienvenida, así un requerimiento puede cambiar su definición mientras no haya ingresado al proceso de desarrollo o al spring de programación.
Programar según especificaciones y no basado en lo que el usuario necesita, en muchos proyectos, quién captura los requerimientos es el analista de sistemas o el analista funcional. Luego el programador realiza la programación basado en la especificación del analista y no exactamente en lo que el usuario necesita. Se depende de cuan bueno es el analista para la captura de requerimientos. En las metodologías agiles se propone que el usuario interactúe directamente con el equipo de desarrollo y realice pruebas constantes sobre lo que se avanza.
Si algo no está claro, se realizan supuestos o se asumen cosas. Es difícil que al momento de realizar el análisis de requerimientos se puedan realizar todas las preguntas o absolver todas las dudas, pues ocurre que el analista no conoce todas las aristas del negocio y el usuario inicialmente recuerda, por lo general, el proceso principal, más no todos los escenarios o todos los detalles. Las metodologías agiles, proponen no suponer o asumir nada, y al tener una interacción constante con el usuario, si hay una duda, se puede realizar la pregunta o absolver la duda en el momento que ocurre, de esta forma no se asume o se supone nada. En este momento el requerimiento se enriquece con nueva información o con un detalle de la misma.
Se pierde mucho tiempo en la definición del requerimiento. Es más sencillo entender un prototipo que un documento de análisis y esta es la principal recomendación de las metodologías agiles. Incluso para entender mejor el requerimiento, antes de realizar un documento demasiado extenso, es mejor realizar una pantalla, incluso muchas veces dibujada a puño inicialmente. De esta forma, el usuario puede visualizar cómo será el software a ser desarrollado y puede realizar observaciones directamente sobre la pantalla.
Principio Agile:
La forma más eficiente y eficaz para transportar información y convertirla en desarrollo es cara a cara.
[/vc_column_text][/vc_column][/vc_row]
