casos de uso

2
Historias de usuario vs casos de uso UML ¿Pero qué es una Historia de Usuario, y porqué son tan importantes como toma de requisitos en un ambiente productivo Agile? La primera gran diferencia es que en un análisis funcional con descripción de requisitos, generalmente se utiliza UML. Un lenguaje descriptivo pensado inicialmente en la sencillez de la comunicación y que se ha convertido en un, a mi parecer, monstruo que entienden muy pocos y que utilizan correctamente aún menos. En cambio la Historia de Usuario está escrita en lenguaje coloquial al ser, simplemente, el recordatorio de la conversación con el cliente. Y un acuerdo formal de mínimos para dar por buena la funcionalidad descrita y esperada. El concepto de Criterios de Aceptación de las Historias de Usuario, es la gran segunda ventaja sobre los requisitos funcionales UML. Ya que no requieren de las terribles matrices de seguimiento de requisitos, al incluir en la propia HU las pruebas que debe superar para ser aceptada como completada. Y que dicha aceptación es binaria: o vale o no vale. No hay medias tintas, ni el 99% finalizado. El concepto de “Done” en estado puro. Las Historias de Usuario están vivas. Al realizarse el análisis funcional y técnico en profundidad en la reunión de planificación del Sprint, su desglose en tareas lo realiza un equipo de personas. Y ya se sabe lo cierto del dicho que dice “dos cabezas mejor que una”, y no veas si son cinco o nueve. El nivel de detalle y previsión supera en mucho al que puede hacer un único arquitecto o analista funcional.

Upload: amadeus-catacora

Post on 30-Sep-2015

215 views

Category:

Documents


0 download

DESCRIPTION

Casos de Uso

TRANSCRIPT

Historias de usuario vs casos de usoUML

Pero qu es una Historia de Usuario, y porqu son tan importantes como toma de requisitos en un ambiente productivoAgile?

La primera gran diferencia es que en un anlisis funcional con descripcin de requisitos, generalmente se utilizaUML. Un lenguaje descriptivo pensado inicialmente en la sencillez de la comunicacin y que se ha convertido en un, a mi parecer,monstruo que entienden muy pocosy que utilizan correctamente an menos.

En cambio la Historia de Usuario est escrita en lenguaje coloquial al ser, simplemente,el recordatorio de la conversacin con el cliente. Y un acuerdo formal de mnimos para dar por buena la funcionalidad descrita y esperada.

El concepto de Criterios de Aceptacin de las Historias de Usuario, es la gran segunda ventaja sobre los requisitos funcionalesUML. Ya que no requieren de las terribles matrices de seguimiento de requisitos, al incluir en la propia HUlas pruebas que debe superar para ser aceptada como completada. Y que dicha aceptacin es binaria: o vale o no vale. No hay medias tintas, ni el 99% finalizado. El concepto de Done en estado puro.

Las Historias de Usuario estn vivas. Al realizarse el anlisis funcional y tcnico en profundidad en la reunin de planificacin del Sprint, su desglose en tareas lo realiza un equipo de personas. Y ya se sabe lo cierto del dicho que dice dos cabezas mejor que una,y no veas si son cinco o nueve. El nivel de detalle y previsin supera en mucho al que puede hacer un nico arquitecto o analista funcional.

Mientras, el resto de las Historias de Usuario pueden ser modificadas en su declaracin, en su objetivo o en sus criterios de aceptacin. Pueden serre priorizadas u ordenadas por nuevos parmetrosque le surjan al cliente. O pueden ser sacadas del Product Backlog al modificar el alcance o las tareas ha desarrollar.

Por ltimo, hay una ventaja de la forma en que se construyen las historias de usuario, una conversacin con el cliente, que es muy poderosa. Las historias de usuario, en cualquiera de sus caractersticas indican,sealan y emergen otras Historias de Usuarioque pudieran estar ocultas o no existir.