Scrumízate
Si estás empezando un proyecto de software seguramente quieres definir bien los requisitos para poder planificar bien todo el trabajo. Quieres controlar todo lo que debes hacer, definir bien cada punto, para que llegado el momento, todo funcione perfecto.
¿Cómo se ha hecho clásicamente?
Un primer paso es definir los objectivos y el alcance del proyecto. Una vez definido el sistema y su contexto, empezamos con el diseño de los escenarios y los casos de uso. Un caso de uso es una secuencia de interacciones que se desarrollan ente un sistema y sus actores. Los actores dan respuesta a un evento que inicia un actor principal sobre el propio sistema.
La forma más común es definir una imagen global con las relaciones entre los actores y cada uno de los casos de uso del sistema. Cada actor representa un rol jugado por un usuario o cualquier otro sistema que interactúa con el sistema.
El objectivo de un caso de uso, es definir un documento de especificaciones funcionales; cerrar una funcionalidad y algunas pautas básicas sobre el diseño. Cada uno de los casos de uso debe contar con su arugmento de satisfacción de os objectivos. El documento se convierte en una guía para el desarrollo y su posterior plan de test.
Primero debemos definir una ficha para cada uno de los actores. En esta ficha se describen las características principales, de manera que se tenga presente su actuación en unos o otros casos de uso. Podemos ver un ejemplo a continuación.
Cada caso de uso cuenta con una ficha en la que se define y concreta que se espera en cada una de las funcionalidades del sistema. Debemos definir los actores que participan, algunos campos de nomenclatura para su identificación, una precondición y una postcondición. Debera responder al propósito del caso de uso y un breve resumen la acción.
Finalmente nos falta una tabla con el curso normal y otra para los alternos. De este modo se podrán identificar los eventos que iniciará un actor y como responderá el sistema.
El siguiente paso es definir los diagramas de actividad. Estos diagramas se construyen a partir de la definición del curso normal y los distintos cursos alternos. De este modo se pueden visualizar de forma muy sencilla los caminos que puede tomar el caso de uso y que datos se verán en juego en esa funcionalidad.
Si lees el diagrama anterior y dejas correr un poco la imaginación a medida que lo leas te irás imaginando distintas pantallas con elementos básicos para su interacción. Ahora debemos traducir este diagrama a pantallas. De una forma muy esquemática, sólo para identificar claramente la navegación por el sistema durante la ejecución de un caso de uso.
El paso siguiente ya entraríamos en la definición de la arquitectura según los objectivos y alcance del proyecto y la especificación del modelo de datos. Para luego ya empezar a planificar como se desarrollará el proyecto según las dinámicas internas de los equipos. No todas las empresas trabajan exactamente así, de hecho seguramente la mayoría no lo hagan todo.
La definición de casos de usos la hacen la mayor parte de las empresas o equipo que se dedican el desarrollo de software. Este documento, acompañado con las explicaciones más detallas, hacen firmar al cliente externo o interno, para satisfacer completamente sus necesidades. Podemos afirmar que gracias a destinar un tiempo incial a definir el comportamiento de la aplicación podermos gestionar y desarrollar mejor el proyecto.
¿Es valida la definición clásica de requisitos?
Ahora todo parece muy bonito y fácil. Pero quien está acostumbrado a lidiar con documentos de requisitos, sabe que muchas veces éstos entran en conflicto entre ellos. Se han escrito y pensado con el objetivo de describir de forma correcta y sin ambigüedades el comportamiento del sistema. Desgraciamente en muchas ocasiones no sirven, o mejor dicho, no sirven lo suficiente, para minimizar los problemas en su etapa de desarrollo.
El motivo del caso anterior puede venir dado por errores de comunicación, del proceso de definición o porqué el mundo cambia y también las necesidades de nuestros clientes o usuarios. Es un problema cuya solución puede ir sufriendo cambios. No podemos controlar ni evitar que el mundo cambie de modo que debemos trabajar entendiendo que el mundo es así.
¿Qué son las historias de usuario?
Si has llegado hasta aquí leyendo atentamente probablemente estás introduciéndote en el mundo de la agilidad y las historias de usuario. En este caso te recomiendo la lectura de User Story Mapping, que estoy seguro que te ayudará a centrar los esfuerzos en los usuarios y sus necesidades.
A continuación vamos a ver en el marco teórico en qué consisten las historias de usuario. Puedes leer este post acerca de cómo aplicar las historias de usuario en la definición de funcionalidades de un proyecto y uno de sus elementos clave: la conversación para generar acuerdos.
Las historias de usuario són una forma de definir un requisito con los objetivos que cada una sea:
1. Independiente: Debe ser totalmente atómica en su deficinión
2. Negociable: Ambiguas en su enunciado para poder ser debatidas. La concreción vendrá dada por los criterios de validación.
3. Valorable: Es importante conocer el valor que aportan al proyecto, poder valorar la cantidad de trabajo que suponen para poder planificar y gestionar el proyecto.
4- Pequeña: Para poder hacernos una idea rápida una historia de usuario debería poderse llevar a cabo durante un tiempo superior a dos días e inferior a una semana.
5- Verificable: Es obligatorio verificar que els software cumple con la funcionalidad acordada, se hace mediante los criterios de validación.
Para definir una historia de usuario debemos responder a la siguientes preguntas. ¿Quién se beneficia de esta historia de usuario? ¿Qué se quiere? ¿Cuál es el beneficio? Para responder estas tres preguntas de una forma clara y comuna en cada uno de los casos lo construiremos a partir de esta frase: "Como ROL quiero ALGO para poder BENEFICIO". Aquí tenemos un ejemplo.
A esta frase debemos añadir los criterios de validación. Estos criterios son básicos para poder entender cada uno de los casos con los que debe tener presente en el diseño y desarrollo. En los criterios de validación deben aparecer descritos todo lo que quieres ver y poder hacer.
Siguiendo el caso anterior podría ser:
- Quiero poder ver las impresiones, clicks y CTRs dado un anuncio concreto.
- Quiero poder separar los resultados anteriores por los distintos dominios en los que se ha mostrado el anuncio.
- Dado uno de los dominios, quiero poder separar los resultados anteriores por url.
- Quiero poder filtrar los resultados del anuncio seleccionando una fecha de inicio y otra de final.
- No puedo seleccionar fechas anteriores a la creación del anuncio.
- No puedo selecciona fechas futuras.
- ...
Desde hace un tiempo, el Scrum apuesta para definir los requisitos mediante historias de usuario. La idea principal en el punto partida de un proyecto es definir todas las historias de usuario que queremos que el software pueda ejecutar. Una vez escritas todos debemos valorar que historias tienen más importancia. Se trata de ordenar las historias de usuarios expuestas en una lista (backlog) y definir un producto mínimo viable.
El objetivo del producto mínimo viable es poder hacer una entrega al cliente lo antes posible. Si te interesa, en el próximo artículo explicamos como podemos gestionar el backlog y las pequeñas entregas mediante sprints. De este modo el usuario final podrá empezar a usar el software que desea lo antes posible, para poder dar feedback y así ajustar mejor que y como deseamos que evolucione nuestra aplicación.
Si quieres entender las motivaciones de definir historias de usuario y como hacerlo de forma correcta puedes leer este post.
Te ha gustado el post? Ayúdanos a dar a conocer Scrumízate i comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
