SCRUM parte 3: “Introducción” y primeras dificultades que se presentan.

Standard

Bueno, despué de la novela de los últimos 2 posts, pasaré a hablarles ahora sí del proceso de SCRUM en cuanto al desarrollo de un proyecto, trataré de mantener la explicación lo más sencilla posible.

Bueno, este gráfico del proceso de scrum me gusta porque incluye todo los detalles de scrum, y además agrega la visión. Ahora sí explicaré a manera de pasos, el proceso que se sigue cuando se implementa SCRUM.

1.- Lo primero, basándonos en el gráfico es que el cliente nos comparta su visión del proyecto, y nos platique lo que espera del mismo, para que TODOS, tanto él como el PO, SM y ST tengamos en mente lo que se busca (igual pudiéramos llamarlo paso 0).

2.- Una vez que todos hemos entendido la visióndel proyecto, es hora de generar nuestro product backlog, que no es otra cosa que nuestra lista de requerimientos. Para esta parte SCRUM nos pide cumplir con algunas cosas:

  • Que los requerimientos estén en forma de historias de usuario (User stories).
  • Que se listen TODAS las historias de usuario del proyecto, no sólo una parte.
  • Que las historias de usuario estén ordenadas por prioridad.
  • Que se les asigne una complejidad a cada historia de usuario.
  • Que se indique el tipo de historia de usuario.
  • Que a cada historia de usuario se le asigne un número o identificador.
  • Que las historias de usuario hablen de funcionalidad.
  • Que se incluyan pruebas de aceptación (de ser necesario).
  • En lo posible las historias de usuario deben ser independientes.

Bueno, pasaré a explicar algunos de estos puntos que considero clave.

El formato de historia de usuario debe ser más o menos como sigue:

“Como usuario deseo poder realizar esta acción.”

Ese es el formato más básico que puedo pensar, un ejemplo de esto sería un login.

“Como administrador deseo poder loguearme/ingresar al sistema”

Así mismo las historias pueden tener más detalles o notas como pruebas de aceptación, es decir, esta historia de usuario no decirnos exactamente lo que el cliente quiere. Así que de ser necesario podemos agregar pruebas de aceptación donde se describa, qué quiere decir para el usuario que la historia de usuario está completa, ejemplo:

“El administrador ingresa un correo y una contraseña, y da click al botón ‘ingresar’, y de ser correctos se redirige al administrador a la página de administración”.

Como podemos ver, las pruebas de aceptación o notas, nos pueden aclarar dudas sobre la historia de usuario.

El otro punto muy importante es el de que las historias de usuario hablen de funcionalidad. Una historia de usuario debe agregar valor al PO.

“Como usuario deseo que haya una base de datos para guardar a los usuarios”.

Como podemos ver, resulta obvio que para el PO o usuario promedio, esto no tiene mucho sentido, y a su vez esto suena más como una tarea que una historia de usuario, la historia de usuario debiera ser algo como esto.

“Como administrador, deseo poder crear usuarios en el sistema”

Si vemos la diferencia en el enfoque, sabremos que la segunda historia de usuario hace más sentido al PO que la primera.

Bueno ahora pondré un ejemplo de un product backlog imaginario con lo mínimo que debiera llevar.

Id de la historia de usuario, normalmente es el número que se genero al ser escrita por primera vez Es el nombre de la historia de usuario Los “Puntos de Historia” nos hablan de la complejidad, no el tiempo que nos lleva hacer algo. Normalmente se utilizan 3 posibles valores: Obligatoria, opcional y deseable Como ya mencionamos son como notas aclaratorias.
ID Historia Puntos de Historia Tipo de historia de usuario Criterios de aceptación
1 Como administrador deseo poder ingresar al sistema. 1 Obligatoria
2 Como administrador deseo poder agregar estudiantes. 3 Obligatoria
3 Como administrador deseo poder editar estudiantes. 5 Opcional
4 Como administrador deseo poder eliminar estudiantes. 1 Opcional
5 Como administrador deseo poder ver un listado de estudiantes. 2 Opcional
6 Como administrador deseo poder ordenar el listado de estudiantes. 5 Deseable
7 Como administrador deseo poder capturar calificaciones de estudiantes. 2 Obligatoria
8 Como administrador deseo poder editar calificaciones de estudiantes. 1 Obligatoria
9 Como administrador deseo poder agregar asignaturas. 5 Obligatoria
10 Como administrador deseo poder editar asignaturas. 3 Obligatoria
11 Como estudiante deseo poder ingresar al sistema. 7 Obligatoria
12 Como estudiante deseo poder ver un listado de mis calificaciones. 2 Obligatoria
13 Como estudiante deseo poder ver un listado de las asignaturas. 2 Opcional

En este ejemplo las historias de usuario aún no tienen prioridad (y tanto los puntos de historia como el tipo son random, simplemente ejemplos de posibles valores).

Lo primero que tenemos que ver es que el ID o el “orden” en este caso realmente no nos habla de la prioridad, simplemente es el orden en el que se me ocurrieron, sin embargo en SCRUM la prioridad está dictada por la posición de la historia de usuario en la lista, es decir, si para nuestro PO es más importante una historia, esta debe estar más arriba que las demás. Y obviamente entre menos prioridad o importancia tenga para él, debe estar más abajo en nuestra lista.

Lo segundo es que como podemos ver, tenemos puntos de historia variados, como dijimos, normalmente cuando estimamos pensamos en tiempo, pero en SCRUM nos piden que lo hagamos en complejidad, lo cual es bastante complicado de lograr en un principio. Por ejemplo, ¿qué es más complicado, hacer un login, o hacer un reporte?, digamos que si nosotros consideramos que el login es lo más fácil de hacer, va a ser un 1 de complejidad, y un reporte si por ejemplo es 3 veces más complicado, debería ser un 3. Normalmente para determinar complejidad se utiliza una serie ajustada de fibonacci. 1, 2, 3, 5, 8, 13, 20, 50, 100, ?.  El ? se utiliza cuando no existe ni idea de la complejidad de la historia, y normalmente se busca que el tamaño mayor que se utilice sea el 13, ya que, entre más complejas las historias, se propicia el hecho de que no se cumpla, así que se recomienda partir esas historias en otras más pequeñas.

Bueno, hasta aquí por el día de hoy, en estos días haré la continuación.

Leave a Reply

Your email address will not be published. Required fields are marked *