Archivos por Etiqueta: SCRUM

Definición de Terminado

domingo, 20 agosto 2017 18:06

antoniomartel

0 Comentarios

Un error que solemos cometer los que hemos trabajado como programadores es que decimos que hemos terminado una tarea nada más terminar de codificarla, sin esperar a probarla intensamente con pruebas unitarias, de integración o de aceptación por parte del cliente.

Una parte importante de Scrum es que cuando hemos terminado un sprint debemos tener un entregable que potencialmente pueda ser puesto en producción. No significa que lo pongamos nada más terminar pero sí que está listo para poder ser puesto en producción si así se requiriese. Esto es importante porque no debemos cerrar en falso cosas en un sprint porque aún contienen errores o no han sido exhaustivamente comprobadas o aceptadas por el cliente. Si seguimos avanzando así sprint tras sprint pronto nos daremos cuenta de que hemos ido metiendo cosas debajo de la alfombra que salen a la luz con las primeras entregas en producción porque están llenas de errores o porque no son tal y como el cliente las quería.

Hace algunos años leí que en un proyecto de aplicación web usada por decenas de miles de médicos y personal sanitario en USA la definición de hecho consistía en subir a producción la nueva característica del software, si no sonaba el teléfono en la siguiente hora significaba que la funcionalidad estaba ‘terminada’ (Done en inglés). Esa sí que es una definición de ‘terminado’ muy particular.

La definición de hecho o terminado en un equipo Scrum debe ser algo entendido y compartido por todos y podría consistir en algo tan sencillo como:

Código completado
Código subido al control de versiones
Tests completados
Aprobado por el Dueño del Producto.

A medida que un equipo progresa puede ir añadiendo más controles de calidad a la definición de terminado como ésta de este ejemplo:

Código completado
Código subido al control de versiones
Test unitarios completados
Pasaron los tests de integración
Tests de aceptación
Documentación

Transparencia en Scrum

domingo, 13 agosto 2017 17:58

antoniomartel

0 Comentarios

Como dice la guía de Scrum, Scrum se basa en la transparencia. La lista del producto o la lista del Sprint debe ser conocida por todos los miembros del equipo de trabajo y los interesados. Todos deben saber qué está pasando en el proyecto y por qué para poder tomar las decisiones más correctas.

Si Scrum se basa en la transparencia, la transparencia es también la base de la confianza. Si no conocemos el estado de las cosas, se oculta información al dueño del producto que no sabe si las cosas están correctamente terminadas o no, en qué estado está su producto o si es tan robusto como le están diciendo, terminará fallando la confianza en el proyecto y en las personas. Puede que el proyecto se cancele, que deje de haber flexibilidad cuando algo ha fallado y que perdamos toda credibilidad. El proyecto pasará a ser una marcha tortuosa hasta el final del mismo.

Para esto están las listas del producto, para decirnos cuántas cosas quedan por hacer en el proyecto, las listas del sprint, para que veamos qué estamos haciendo justo ahora y las reuniones de demo, para que el cliente pueda ver el resultado de las últimas semanas de trabajo y el producto por el que está pagando. Esta transparencia, si no la falseamos ni ocultamos la verdad será de gran valor en el proyecto.

A veces, por temor a llevarnos una reprimenda o evitar el enfado del cliente, del dueño del producto o del propio Scrum Master tendemos a ocultar la verdad convirtiendo la transparencia en una palabra hueca carente de todo sentido. Si una funcionalidad falla en ocasiones pero no se ve en la demo es mejor decirlo y explicar que queda este problema atrás. Si no hemos podido tener a todo el equipo de trabajo al 100% en el proyecto, es mejor decirlo también y que no falle la confianza. La transparencia será una gran aliada cuando las cosas pinten mal y necesitemos de la confianza de todos en que el proyecto saldrá bien.

La lista del sprint o Sprint backlog

miércoles, 09 agosto 2017 18:58

antoniomartel

0 Comentarios

La lista del sprint es la lista de elementos que hemos escogido para realizar durante el sprint actual. El equipo de desarrollo habrá seleccionado de entre los elementos de la lista de todo el producto un subconjunto de historias de usuario o tareas que cree que puede terminar en este sprint.

La diferencia con la lista del producto es que esa es la lista de todas las cosas previstas a hacer e incorporar a nuestro producto o aplicación, en cambio, la lista del sprint es sólo la lista de cosas que el equipo de desarrollo se compromete a tener terminadas en este sprint. Normalmente, en la lista del producto tendremos historias de usuario o una descripción de las funcionalidades a realizar y en la lista del sprint tendremos una descomposición de esas historias de usuario en tareas que pueden realizarse en un máximo de dos días y en un mínimo de dos horas.

Para el sprint podríamos haber escogido dos historias de usuario como las que pueden verse en el siguiente ejemplo que para la pila del sprint habremos descompuesto en tareas más pequeñas y abordables:

Historias de usuario y tareas para la lista del sprint

A veces el equipo de trabajo se ha comprometido a demasiadas cosas para el sprint o a demasiado pocas por lo que terminan antes. En esos casos el equipo se comprometerá a hacer más o tendrá que quitar elementos de la lista si no pueden terminar con todos.

Cuantas tareas debe acometer un equipo por sprint

No hay una única respuesta para esto. Podemos estimar en horas cuanto nos llevará cada tarea y calcular cuantas de ellas podemos acometer en las semanas que tengamos de sprint. Podemos también ver cuál ha sido la velocidad (número de tareas y horas estimadas resueltas) que hemos tenido en sprints anteriores para calcular cuantos puntos u horas podemos terminar en este sprint. Hay incluso quien no hace estimaciones (no-estimates movement) en horas de cada tarea sino que hace un cálculo rápido de cuantas tareas puede completar en el sprint y si le cabe alguna tarea más o no.

En mi caso particular, yo no le pido al equipo una estimación en horas de cada una de las tarjetas que acometemos sino que les pregunto por cuántas y cuáles de esas tarjetas podríamos tener terminadas en el sprint. Tenerlas terminadas en el sprint no significa estar trabajando hasta el último día en desarrollar hasta la última tarea sino que paramos nuevos desarrollos 3 días antes de la reunión de demo para hacer un despliegue en desarrollo de lo que tengamos en ese momento. A partir de ahí comenzamos todos los miembros del equipo a probar cada una de las tareas y a subir nuevas versiones con las correcciones que hayamos hecho hasta tener una versión en el entorno de demo que podamos mostrar en la reunión de revisión del sprint el último día del mismo.

Seguimiento del progreso en Scrum

domingo, 06 agosto 2017 20:11

antoniomartel

0 Comentarios

Existen varias formas de medir el progreso del trabajo total hasta acabar el proyecto. Al menos una vez por sprint el dueño del producto mide cuánto ha sido trabajo que se ha terminado y cuanto queda para acabar el proyecto y lo anota.

Esta forma de contar el trabajo restante para acabar el proyecto se le llama Burndown y si se pinta en una gráfica será la llamada gráfica de Burndown. Se le llama así porque se va anotando la cantidad de trabajo que queda pendiente en lugar de la cantidad de trabajo o puntos que vamos sumando al realizar más trabajo. El trabajo va disminuyendo o quemándose hasta llegar a 0 horas o puntos de trabajo pendiente, momento en el cuál toca suelo en el eje horizontal.

La línea roja en esta imagen de ejemplo es la línea del plan inicial en la que acabaríamos el proyecto en 9 sprints si en cada sprint acabamos el mismo número de puntos. La línea azul en cambio muestra la línea real que lleva nuestro proyecto. Como vamos algo más lentos sumamos menos puntos que la planificación inicial por lo que nuestra línea lleva menos pendiente de lo que quisiéramos y acabará en el sprint 12 o 13 si no mejora y avanzamos más rápidos.

En cada sprint el dueño del producto seguirá anotando la suma de puntos estimados para las tarjetas que nos quedan pendientes. Si en próximos sprints logramos terminar muchas tarjetas o historias de usuario quedarán menos puntos restantes y la gráfica tendrá una mayor pendiente hacia el cero, señal de que vamos más rápidos.

En muchos proyectos se lleva una actualización de esta gráfica día a día, revisando cada día lo que se ha terminado para restárselo al trabajo pendiente. Yo encuentro esto un poco complicado de mantener y en mi trabajo suelo llevar una única gráfica para todo el proyecto y no una gráfica por cada sprint, de forma que pongo en el eje horizontal los sprints que me está llevando el proyecto y no los días transcurridos en el sprint. Cuando llevo unos cuantos sprints puedo ver la pendiente media que tiene mi gráfica lo que me permite calcular en qué sprint aproximadamente va a tocar suelo la gráfica y acabaremos por tanto el proyecto.

Test de Scrum con Ruby on Rails

sábado, 05 agosto 2017 11:07

antoniomartel

0 Comentarios

He decidido poner de nuevo a disposición del público en general la pequeña base de datos de tests de Scrum que realicé hace unos años con Ruby on Rails.

Se trata de un test 10 preguntas aleatorias en español sobre este marco de trabajo y al final del mismo te indicará información sobre el número de respuestas correctas que has tenido y un enlace al test de prueba en inglés donde practicar antes de tomar el examen oficial para el certificado Professional Scrum Master I.

La aplicación está hecha con Ruby on Rails y desplegada en la nube de Heroku. La base de datos está en la nube y es un Postgres facilitado por Heroku también.

Les dejo el enlace para que prueben sus conocimientos sobre Scrum: Test de Scrum.

Página 4 de 22