martes, octubre 14, 2014

¿Por qué prefiero las Historias de Usuario a los Casos de Uso?

o

Los casos de uso como fuente de insatisfacción entre analistas, desarrolladores, testers y usuarios

--


Por mucho tiempo expliqué y empleé los casos de uso con todos sus elementos:
·         Precondiciones
·         Postcondiciones
·         Flujo básico
·         Flujos alternativos
·         Flujos de excepción
·         los misterios de los include y extend
·         Y variaciones de acuerdo al autor y la empresa
Pero lo que siempre notaba es que:
·         Los diferentes autores lo explican distinto la documentación de los casos de uso
·         El mismo caso de uso queda escrito de forma diferente por diferentes personas
·         En muchas ocasiones no quedan bien escritos
·         Y lo que es peor los clientes/usuarios NO LOS ENTIENDEN - sabiendo que fueron creados para ellos y supuestamente están en lenguaje de usuario - (he notado que los casos de uso no los entendemos muchas veces entre los mismos ingenieros de sistemas)

Luego, tiempo después, con el agilismo aprendí dos lecciones importantes:
·       la comunicación escrita tiene baja efectividad (ver imagen de Alistair Cockburn)  
·       De la comunicación solo el 7% es transmitido en las palabras, el 38% corresponde al tono de la voz y el 55% a la comunicación no verbal (ver más aquí)
Pero el punto que quiero presentar no es que los casos de uso hacen parte de la práctica de levantamiento de especificaciones funcionales donde el usuario aparece, se levanta información y luego desaparece por un tiempo hasta que por fin regresa a validar el sistema, lo que quiero evidenciar es que los Casos de Uso llevan consigo un problema de comunicación que genera una cantidad de insatisfacciones, reprocesos y hasta de bugs, miremos como sucede:
1.       Se levanta el Caso de Uso por el Analista y se identifican 5 escenarios de uso.

Especificado por el analista
Flujo básico
FB1

Flujo Alterno 1
FA1
Flujo Alterno 2
FA2
Flujo Alterno 3
FA3
Flujo de Excepción
FEx1
Flujos identificados
5
Flujos adicionales
0
Flujos totales
5

2.       El desarrollador es creativo e identifica 6 escenarios adicionales que funcionan perfectamente dentro de los flujos identificados. El desarrollador tiene gran satisfacción por su proactividad y es posible que hasta su gerente de proyecto lo felicite.
 Escenarios
Especificado por el analista
Desarrollados e identificados por el desarrollador
Flujo básico
FB1

FB1

Flujo Alterno 1
FA1
FA1
FA1.1
Flujo Alterno 2
FA2
FA2
FA2.1
FA2.2
Flujo Alterno 3
FA3
FA3
FA3.1
Flujo de Excepción
FEx1
FEx1
FEx1.1
FEx1.2
Identificados
5

Adicionales

6
Flujos totales
5
11

3.       El tester, que es alguien que es experto en encontrar escenarios de fallo, encuentra adicionales a los especificados y los 6 adicionales hallados por el desarrollador. En este punto el dialogo del  tester y desarrollador es en el mejor de los casos el siguiente:
·         Tester: Mira encontré 5 incidentes, me toca devolverte el caso de uso
·         Desarrollador: ¿Cómo así? No los vi, identifique 6 escenarios adicionales, pero bueno pásamelo y déjame reviso, si es del caso los corrijo.
(Para ser sensatos no son incidentes, ni bugs, ese golpe no lo veía venir el desarrollador(ni el especificador, ni el gerente de proyecto) por ningún lado, pero empezó a pagar los platos rotos de cuenta de esta cadena de errores involuntarios de cuenta de la metodología de trabajo)
Escenario
Especificado por el analista
Desarrollados e identificados por el desarrollador
Probados y otros nuevos identificados por el analista
Flujo básico
FB1

FB1

FB1

Flujo Alterno 1
FA1
FA1
FA1.1-
FA1
FA1.1-
Flujo Alterno 2
FA2
FA2
FA2.1-
FA2.2-
FA2
FA2.1-
FA2.2-
FA2.3-
FA2.4-
Flujo Alterno 3
FA3
FA3
FA3.1-
FA3
FA3.1-
FA3.2-
FA3.3-
Flujo de Excepción
FEx1
FEx1
FEx1.1-
FEx1.2-
FEx1
FEx1.1-
FEx1.2-
FEx1.3-
Identificados
5


Adicionales identificados

6
5
Flujos totales
5
11
16
Nota: por lo general el Flujo básico es el que queda mejor especificado y no tiene lugar a malas interpretaciones

4.       El cliente recibe el caso de uso y al probarlo se da cuenta que el producto está muy bien construido pero encuentra que 5 escenarios no especificados “pero obvios” no fueron considerados y al revisar la documentación junto con el analista, el cliente y el gerente de proyecto del equipo del proveedor concluyen que deben ser elaborados. Estos 5 escenarios son 5 incidentes que se le suman a los 5 anteriores detectados por el tester. A este punto tanto desarrollador como tester tienen cuestionada su “reputación” tanto con el cliente como con el gerente de proyecto.

Escenario
Especificado por el analista
Desarrollados e identificados por el desarrollador
Probados y otros nuevos identificados por el analista
Cliente usuario
Flujo básico
FB1

FB1

FB1

FB1

Flujo Alterno 1
FA1
FA1
FA1.1-
FA1
FA1.1-
FA1
FA1.1-
FA1.2-
FA1.3-
Flujo Alterno 2
FA2
FA2
FA2.1-
FA2.2-
FA2
FA2.1-
FA2.2-
FA2.3-
FA2.4-
FA2
FA2.1-
FA2.2-
FA2.3-
FA2.4-
FA2.5-
FA2.6-
Flujo Alterno 3
FA3
FA3
FA3.1-
FA3
FA3.1-
FA3.2-
FA3.3-
FA3
FA3.1-
FA3.2-
FA3.3-
FA3.4 -

Fujo de Excepción
FEx1
FEx1
FEx1.1-
FEx1.2-
FEx1
FEx1.1-
FEx1.2-
FEx1.3-
FEx1
FEx1.1-
FEx1.2-
FEx1.3-
Identificados
5



Adicionales identificados

6
5
5
Flujos totales
5
11
16
21

A este punto 5 escenarios identificados por el analista, se han convertido en 21 debido a la ambigüedad y falta de precisión de los casos de uso, generando gran insatisfacción y reprocesos en toda la cadena.
---
Aquí es donde los comparo con las historias de usuario (ver más acá - la magia de las historias de usuario-) donde estas tienen:
·         Una pequeña descripción funcional
·         Y unos criterios de aceptación los cuales tiene la gran ventaja de:
o   Discutirse hasta el completo entendimiento  (hasta la saciedad) con el cliente (recordemos CCC – Card-Conversation-Confirmation)
o   Si se olvida un criterio de aceptación se realizará el próximo Sprint o iteración (que comenzara a lo sumo en un mes)
o   No hay lugar a bugs por “omisión funcional” o escenarios “obvios” no identificados, por lo tanto la probabilidad de éxito de un desarrollo satisfactorio es altísima pues no hubo lugar a ambigüedades, ni olvidos no intencionales
·         Si hay algo que aclarar se resolverá durante la iteración o sprint con el cliente, el cual estará disponible para resolverla.


Por esta razón es que prefiero hoy en día las historias de usuario a los casos de uso.

Queda abierto el espacio para  la discusión y las experiencias. 

Saludos ágiles

Jorge Abad

7 comentarios:

  1. Jorge:

    Excelente artículo, me gustó mucho el enfoque.

    Otro aspecto importante es que los casos de uso, por su propia naturaleza (la cual ya has explicado aquí), pueden llegar a ser tan complejos o grandes que construirlos (como lo hacemos con las Historias de Usuario), en un corto sprint de 1 semana o 2, por ejemplo, no sea posible.

    Esa es una de las razones por las que el mismo Dr. Jacobson, creador de los casos de uso, respondió con Casos de Uso 2.0, un enfoque hibrido que mezcla las historias de usuario con sus casos de prueba asociados en un elemento que llama “Porciones de Caso de Uso”. Estos elementos tienen la simplicidad que necesitamos de las historias de usuario y el poder del modelado de los casos de uso, asunto que no debemos desestimar.

    Toda la información, si me lo permites, sobre Casos de Uso 2.0 la encuentran en el libro del mismísimo Jacobson y que tuve la oportunidad de traducir hace ya un par de años. Lo pueden descargar de www.ivarjacobson.com, van por la opción Resources | White Papers y allí lo encuentran de manera gratuita.

    Creo que es un enfoque que deberíamos mirar un día de estos.

    Salud@s,

    Lucho

    ResponderEliminar
    Respuestas
    1. Por acá Lucho estuve mirando el tema.. cuando nos sentamos y escribimos algo juntos

      Eliminar
  2. Si Lucho, esta pendiente la tertulia al respecto. Yo lo veo como la conciliación de los dos mundos pero me sigo quedando con las historias de usuario, pues los casos de uso llevan "casi" implícito que se deben construir completamente, lo que generaría desgastes y reprocesos.

    ResponderEliminar
  3. Buenas noches Jorge,

    Excelente artículo! A mi también me gustan las historias de usuario las he estado aplicando durante 8 meses. pero he encontrado que a los desarrolladores les hace falta una descripción detallada de los campos y los criterios de evaluación no alcanzan a llenar ese vacio con buena descripción. ¿ me puedes indicar como se pueden sortear esas barreras? o un ejemplo de una historia de usuario de la vida real?

    Saludos

    ResponderEliminar
  4. Te comparto una historia de un Updater de un sistema Cliente-Servidor

    ---
    Product Backlog Item 9:TR: Updater de Tiempo Real

    Yo como OPERADORA
    deseo TENER LA ULTIMA VERSIÓN DE TIEMPO REAL
    para CONTAR SIEMPRE CON LA VERSIÓN MÁS ACTUALZADA DEL SISTEMA DE TRACKING

    Escenario 1: Verificando versión

    DADO que hago clic en el ícono de tiempo real
    CUANDO el sistema verifica que tengo la última versión
    ENTONCES el sistema sacará un mensaje que diga "Verificando versión. Espere un momento..."

    Nota:La verificacion se realizara de la siguiente forma

    al ejecutar el updater verificara la version que esta en la base de datos contra la version que leera el updater del ejecutable local, si la version es igual solo abrira la version existente de tiempo real ubicada en la maquina local, en caso contrario descargara la ultima version del repositorio y posteriormente abrirá tiempo real con la version actualizada en la maquina local

    Escenario 2: Tengo la última versión
    DADO que estoy verificando versión
    CUANDO se comprueba que tengo la última versión
    ENTONCES El sistema llama a la aplicación de TIEMPO REAL permitiendo el ingreso de usuario y contraseña.


    Escenario 3: No tengo en mi máquina la última versión
    DADO que estoy verificando versión
    CUANDO se comprueba que no tengo la última versión
    ENTONCES El sistema descargará la última versión del repositorio oficial en la máquina local
    Y eliminará la versión anterior
    Y realizará la invocación de TIEMPO REAL permitiendo el ingreso de usuario y contraseña
    Y Presentará la información de la versión de tiempo real en la parte superior derecha de la pantalla ejemplo: "Versión 1.0.1"

    ResponderEliminar
  5. OTRA historia

    ------
    Product Backlog Item 161:Registrar REUNIONES para TR --Validaciones

    Yo como INGENIERO DE PRODUCCIÓN
    deseo REGISTRAR LAS REUNIONES
    para QUE LOS IMPRODUCTIVOS QUEDEN CORRECTAMENTE BIEN AFECTADOS

    Criterios de Aceptación

    Que la pantalla tenga validaciones.

    Nombre :
    máximo 20 caracteres: Sino se cumple poner mensaje de validación
    mínimo 5 caracteres: Sino se cumple poner mensaje de validación

    Descripción
    mínimo 5 caracteres: Sino se cumple poner mensaje de validación
    máximo 50 caracteres: Sino se cumple poner mensaje de validación
    que el campo quede como un text area de 2 rengolones

    Tiempo
    mínimo 5 mín : Sino se cumple poner mensaje de validación
    máximo 480 min: Sino se cumple poner mensaje de validación

    Fecha
    igual o superior a hoy : Sino se cumple poner mensaje de validación
    máximo, un mes mas : : Sino se cumple poner mensaje de validación
    que los tiempos se ingresen.
    que los tiempos en minutos.
    que aparezca un mensaje de éxito o de fracaso.
    que en el grid de reuniones aparezca la columna fecha
    que se puedan quitar personas de la reunión
    que la invitación de usuarios que permita filtrar por usuarios (que yo ingrese a y traiga todos los de a)
    que la invitación sea organizable por nombre
    que el listado de los invitados sea organizado por nombre

    ResponderEliminar
  6. Hola Jorge... Pero igual si un equipo decide que al tener las HU le falta mas detalle técnico para construir el producto. Es válido apoyarse de otro tipo de artefactos? Cuales serían en tu opinión?

    ResponderEliminar