Enfoque Lean Agile en Acción

Ejemplo de Portal para Estudiantes

Una universidad comunitaria desea desarrollar un portal para estudiantes que ofrezca servicios en línea. Invitaron a un representante estudiantil, al personal del departamento y a los miembros del administrador del portal para formar un equipo que participe en el proyecto de desarrollo del portal para estudiantes. A continuación se presentan las actas extraídas de la primera reunión.

Reunión de interesados

Orden del día

• Sugerir funciones para el portal de estudiantes
• Discutir la viabilidad de la lista de funciones propuestas
• Priorizar las funciones para implementarlas como principales, siguientes, deseables…

Steve (Equipo de Desarrollo): Bienvenidos… Queremos que la reunión sea más productiva y fructífera. Cuando sugieran funciones que deseen tener, podemos usar el siguiente formato como forma estándar de expresión: quién (usted es), qué función (desea), y por qué (desea tenerla)… Estas funciones se registrarán como historias de usuario como herramienta de comunicación durante todo este proyecto.

Luego, realizamos una lluvia de ideas para obtener una lista de historias de usuario de diferentes interesados:

Representante estudiantil: registrar cursos, pagar cuotas, ver horario, editar horario, ver boletín de calificaciones, dar de baja cursos…

Representante académico: agregar información del curso, editar información del curso, eliminar información del curso…

Administrador del portal: realizar copia de seguridad de la información del curso, editar el estado de la cuenta del estudiante

Ahora, tenemos un grupo de tarjetas que se pueden organizar en filas y columnas

Priorizar las funciones propuestas

Representante del equipo de desarrollo: Tenemos una lista de historias de usuario priorizadas que se implementarán en la próxima iteración. Para ello, debemos profundizar en cada historia de usuario para comprender mejor y obtener más información. Vamos a revisar la primera historia de usuario principal: ‘registrar curso’

Obtenemos información adicional, como sigue, de los usuarios finales durante la reunión:

• Académico: el estudiante debe estar matriculado como estudiante de tiempo completo
• Administrador: el estudiante debe proporcionar credenciales de cuenta correctas para iniciar sesión
• Académico: el curso no está completo
• Académico: se deben cumplir los requisitos previos del curso
• Administrador: un curso seleccionado para añadir al horario no debe entrar en conflicto con la franja horaria de otro curso
• Desarrollador: ¿qué otras funciones desea que se agrupen junto con esta función en el sistema objetivo?
• Estudiante: dar de baja cursos, ver horario, editar horario.

Las 3C de la historia de usuario

Las buenas historias de usuario son mucho más que simples declaraciones. Una historia de usuario estándar consta de tres partes, comúnmente conocidas como las tres C. La primera ‘C’ de cada historia de usuario debe seguir el formato estandarizado: Como un [rol], quiero [hacer algo], para que [beneficios], que es el contenido mínimo de una historia de usuario para incluir en la tarjeta. Las ‘Conversaciones’ son el contenido de la segunda ‘C’ de una historia de usuario, que representan la discusión entre los usuarios finales, el propietario del proyecto y el equipo de desarrollo. En estas conversaciones, se registra la discusión verbal o muchas otras informaciones útiles, como correos electrónicos, prototipos o cualquier otro contenido relacionado con el proyecto. La última ‘C’ de una historia de usuario es la confirmación, que son los criterios de aceptación utilizados para confirmar que la historia de usuario se ha implementado correctamente y se ha entregado con éxito.

Déjeme ampliar un poco más sobre cómo desarrollar la parte de confirmación de una historia de usuario. Aquí utilizamos la plantilla más conocida llamada Gherkin, que adopta la fórmula Given-When-Then para guiar la redacción de pruebas de aceptación para una historia de usuario:

• (Dado.. y) algún contexto
• (Cuando.. y) se realiza alguna acción
• (Entonces.. y) Realizar algunas acciones

Herramientas como Cucumber y los marcos de pruebas Jbehave fomentan el uso de la plantilla Given/Then/Then para realizar pruebas automatizadas, aunque también puede usarse puramente como una heurística independientemente de si se utiliza alguna herramienta.

Reunamos toda la información para la historia de usuario «registrar curso» y coloquemos en formato 3Cs:

Ahora, pongamos la información en UeXceler, que incluye la conversión y confirmación que desarrollamos anteriormente.

Dividir el Episodio en Historias de Usuario

Si investigamos más a fondo la historia de usuario «registrar curso», podríamos encontrar que es demasiado grande como para incluirla en un sprint. Podríamos considerarla como un Episodio (una historia de usuario más grande), que podría dividirse en un grupo de historias de usuario más pequeñas relacionadas. Podemos dividir un episodio en tareas, a lo que llamaría división horizontal, o alternativamente podemos dividir el episodio en escenarios y llamarlo división vertical.

División Horizontal

El enfoque tradicional para construir una función grande era descomponerla en el trabajo que debía realizarse en capas arquitectónicas. Por ejemplo, modelo-vista-controlador (MVC) o arquitectura cliente-servidor, para que se logre una separación de preocupaciones en la arquitectura del sistema, y posteriormente afinarla en una arquitectura de n capas, como GUI, lógica de control, modelo de objetos, mapeo objeto-relacional, capas de base de datos, etc. Hay muchos elementos en la arquitectura de n capas, y aquí solo mencionaré algunos a continuación:

• Nos permite desarrollar alta especialización en una de las capas arquitectónicas
• Otras aplicaciones podrán reutilizar la funcionalidad expuesta por sus capas.
• Podrá distribuir sus capas sobre múltiples niveles físicos. Esto puede tener un impacto muy positivo en su aplicación al mejorar el rendimiento (a veces), la escalabilidad y la tolerancia a fallos.
• El mantenimiento de su aplicación es más sencillo debido al bajo acoplamiento entre capas.
• Añadir más funcionalidad a su aplicación se vuelve más sencillo.
• Las capas hacen que su aplicación sea más fácil de probar.

Hay un gran número de implementaciones exitosas basadas en la arquitectura de n capas, como Ruby on Rails y arquitecturas basadas en servicios web.

Historias de Usuario y División Horizontal

Aunque tenemos o los beneficios de la arquitectura de n capas para nuestro sistema, tiene algunas desventajas cuando la usamos con el enfoque de historias de usuario. Tiende a tener un bucle de retroalimentación muy lento, dependiendo del tamaño de la característica, ya que estamos esperando a que todos terminen su parte separada para integrarla y asegurarnos de que funcione. El término «corte horizontal» se refiere a utilizar este enfoque de capas arquitectónicas como método principal de descomposición de características grandes.

División Vertical

Para acelerar el bucle de retroalimentación, podemos tomar un episodio y dividirlo en varios escenarios de usuario que atraviesan cada una de las capas arquitectónicas. Podemos descomponer casi cualquier característica en trozos de forma que solo se necesiten un par de días como máximo para construir, integrar y probar todas las piezas. Cada trozo incluye todo el trabajo necesario en una capa arquitectónica, así como cualquier prueba e integración que se deba realizar para prepararlo para su lanzamiento.

Normalmente, la división horizontal divide las características en historias de usuario o tareas a nivel de componente arquitectónico. Ejemplo: interfaz de usuario frontend, bases de datos o servicios backend. Mientras que un corte vertical produce software funcional y demostrable que aporta valor empresarial. Por lo tanto, la división vertical mejora la capacidad del equipo para entregar un incremento de producto potencialmente entregable en cada sprint. Imagine cortar un pastel con capas de crema, chocolate, fruta y pastel. Si cortara el pastel horizontalmente, su amigo solo obtendría un trozo de pastel, chocolate, crema o fruta. Estoy seguro de que a sus amigos les gustaría más un trozo que contenga un poco de todas las capas. Obtener solo una capa del pastel no les permite probar el sabor real de todo el pastel. Un enfoque más amigable para sus amigos es crear cortes verticales (el valor deseado).

División Horizontal del Episodio con Objetivo

Recuerde que la conversión para la historia de usuario «registrar curso» que tuvimos en la reunión con los interesados, la característica fue propuesta primero por los estudiantes (rol principal) y apoyada por otros interesados. Cuando profundizamos en los detalles de la historia de usuario, descubrimos que hay bastante información reservada por otros interesados que participarán en la historia de usuario como roles de apoyo.

En la realidad, algunos estudiantes pueden no importarles o incluso no querer las restricciones impuestas por las personas del «rol de apoyo». Por ejemplo, un estudiante olvida su contraseña y la ha introducido incorrectamente tres veces, podría no querer pasar por el proceso de restablecimiento de contraseña, pero aún así tiene la confianza para intentarlo varias veces más, o un estudiante no quiere tener un límite para libros de biblioteca, o un período de préstamo, y así sucesivamente. Quienes desean establecer algunas reglas de negocio, restricciones para las características propuestas como su objetivo de usuario, son precisamente quienes participan como roles de apoyo en la historia de usuario. La característica no debería funcionar en absoluto si no se imponen las reglas de negocio y el segundo objetivo a la característica propuesta. Si dividimos el episodio horizontalmente según los objetivos de los actores secundarios en un grupo de historias de usuario, podremos cumplir con los objetivos de los actores secundarios, hacer que la historia de usuario sea verificable y obtener retroalimentación directamente de la persona adecuada.

Examinemos la información de las secciones de conversión y confirmación para ver cómo podemos dividir la historia más grande «registrar curso» en un grupo de historias de usuario relacionadas.

1. El estudiante debe ser un estudiante registrado; de lo contrario, no tendrá la credencial proporcionada por la notificación para los nuevos estudiantes. Si recibió la notificación pero la cuenta aún no ha sido activada, deberá registrar la nueva cuenta en línea (marcado como círculo rojo 1)
2. Si profundizamos un poco más en el proceso de inicio de sesión, sabemos que si un estudiante proporciona incorrectamente las credenciales tres veces, deberá ingresar al «proceso de restablecimiento de contraseña» (marcado como círculo rojo 2 y 3)

Compartimento General de Historias de Usuario

Creemos estas historias de usuario en UeXceler:

La historia de usuario de inicio de sesión se crea dentro del compartimento general de historias de usuario. Además de las historias de usuario de inicio de sesión, se están creando dos historias de usuario relacionadas más dentro del mismo compartimento general de historias de usuario, que son la historia de usuario de “restablecer contraseña” y la historia de usuario de “crear nueva cuenta de estudiante”, por las siguientes razones:

• En caso de que las credenciales de la cuenta sean ingresadas incorrectamente por el estudiante tres veces, se activará la historia de usuario de “restablecer contraseña”;
• y si un estudiante nuevo aún no se ha registrado para una cuenta de estudiante, podría activar la historia de usuario de “crear nueva cuenta de estudiante” dentro de la pantalla de inicio de sesión.

1. Como estudiante, quiero iniciar sesión en el portal del estudiante, para que…
2. Como administrador del portal, quiero verificar que la persona que inicia sesión es un estudiante registrado, para que…
3. Como líder del curso, quiero verificar la idoneidad antes de permitir que el curso seleccionado se agregue al horario del estudiante, para que…

Podemos considerar que estas tres historias de usuario se han dividido horizontalmente desde el epítome “registrar curso”, pero estas historias de usuario cumplirán el objetivo de algunos actores secundarios con los que puedes obtener retroalimentación y confirmar. Si no se cumplen las condiciones previas, la historia de usuario principal ya no tendría sentido alguno.

Puedes ver que hemos colocado todas estas historias de usuario dentro del compartimento general de historias de usuario, y la razón es que es probable que compartan la misma condición previa junto con otras características relacionadas (historias de usuario) en la misma página de invocación, como por ejemplo, “ver horario”, “editar horario”, “eliminar cursos”, etc.

Compartimentos de casos de uso

Quedan tres marcados con círculo rojo numerados 4, 5 y 6 en la figura anterior. Son los escenarios alternativos del epítome “registrar curso”. Cualquiera de estas tres condiciones falsificadas generará un escenario alternativo para esa situación y podría representarse como una historia de usuario dividida. Quizás podríamos dividirlo horizontal o verticalmente, pero ¿no es siempre preferible la división vertical? No necesariamente, depende realmente de la situación. No existe una solución única que sirva para todos los casos en el mundo, debemos considerar qué enfoque es más adecuado para tu caso. Déjame explicarlo un poco más.

Por ejemplo, si vas a asignar la historia de usuario principal a un desarrollador y las tres historias de usuario de inicio de sesión, registro de nueva cuenta y restablecimiento de contraseña a otro desarrollador. Podrías preferir que el desarrollador responsable de la historia de usuario principal desarrolle primero el escenario principal en el sprint actual y desarrolle de forma incremental los escenarios alternativos en los sprints posteriores, por el mismo desarrollador (si el marco de tiempo lo permite). Pero si el marco de tiempo es corto y al mismo tiempo sientes que es demasiado pesado para que un solo desarrollador se encargue de todo el epítome, entonces puedes dividirlo horizontalmente en tareas para asignarlas a varios desarrolladores de forma paralela.

División del epítome en escenarios

Si consideramos los detalles del escenario descrito en la sección de confirmación del epítome, podemos encontrar fácilmente los cortes verticales para un grupo de historias de usuario relacionadas.

1. Como líder del curso, quiero verificar los requisitos previos antes de permitir que el curso seleccionado se agregue al horario del estudiante, para que…
2. Como líder del curso, quiero verificar la disponibilidad del curso antes de permitir que se agregue al horario del estudiante, para que…
3. Como líder del curso, quiero verificar la disponibilidad del horario del estudiante antes de permitir que el curso seleccionado se agregue al horario del estudiante, para que…

División del epítome en tareas

Si deseamos descomponer el epítome en tareas más pequeñas para un desarrollo paralelo en el mismo sprint, como sigue:

1. Verificar el estado del cupo del curso
2. Verificar los requisitos previos del curso
3. Verificar el horario

Ahora, tienes a tu disposición la elección de cómo dividir el epítome en historias de usuario para el proceso de desarrollo ágil. Puedes ver que la historia de usuario “Registrar curso” y sus historias de usuario relacionadas se encuentran dentro de un compartimento de casos de uso (tu epítome), también llamado “Registrar curso”, que se utiliza como un marcador de posición para albergar todas las historias de uso principales y aquellas historias de uso derivadas de la principal.