Sunday, 19 November 2017

Cómo ser ágiles en proyectos a precio cerrado

La mayor parte de mi vida profesional, como muchos otros, la he vivido trabajando en proyectos a precio cerrado (fixed price) en concreto trabajando para administraciones públicas en las que el alcance del proyecto venía prefijado de antemano en pliegos de condiciones administrativas y claúsulas técnicas.

En este tipo de proyectos tienes que presentar una propuesta económica, de recursos y de tiempo a la administración pública que valorará cuál es la mejor de las ofertas presentadas, normalmente la de presupuesto económico más bajo, decidiendo luego qué proveedor será el adjudicatario. Por tanto, desde antes de iniciar el proyecto, tendrás que estudiar las condiciones y el alcance fijados en los pliegos y hacer una arriesgada estimación de cada una de las tareas o módulos que se requiere desarrollar y lanzar tu oferta.

¿Se puede ser ágil en proyectos en los que el costo, el alcance y a veces la fecha de entrega están cerrados desde el inicio? Yo pienso que sí, veamos cómo.

¿Qué hacer con el coste?

Este es el lado más arriesgado de este triángulo de hierro. Hemos hecho una estimación basada en lo que ponía en los pliegos de contratación pero estos contienen en la mayor parte de las ocasiones una descripción genérica de las tareas a realizar que luego se concretará a medida que se avanza en el proyecto o se analiza con las partes interesadas. Más que una oferta hemos hecho una apuesta que no sabemos si nos saldrá bien.

Tendremos que confiar en haber hecho una buena estimación. Por naturaleza todos tendemos a ser demasiado optimistas teniendo en cuenta sólo los escenarios en los que todo marcha bien. Sólo cuando usamos estimaciones tipo PERT en la que se nos obliga a ponernos también en el peor caso nos paramos a pensar en esos grandes imprevistos que siempre pueden pasar (como se dice en inglés, shit happens). A partir de aquí nos basaremos en las mejoras de eficacia que proporciona la agilidad.

En Scrum y otros frameworks iremos entregando cada poco tiempo una parte del alcance prometido lo que permitirá ir enseñando nuestros trabajo, haciendo correcciones y aprendiendo de lo que ya hemos hecho. En los proyectos en cascada también hay fases: Análisis, Diseño, Construcción y Testeo pero al final de las primeras sólo entregamos unos documentos sobre lo que se va a construir. Sería como analizar, diseñar un nuevo prototipo de móvil y esperar a construir 10.000 unidades para luego comenzar a venderlo y ver si le gusta a los usuarios que lo han comprado o no.

Incluir los tests y planes de aseguramiento de la calidad en cada sprint nos permitirá construir bien desde el inicio y con menos costes. Es mucho más fácil corregir los problemas de cobertura de un móvil cuando se está desarrollando y diseñando la antena en los primeros modelos que cuando ésta ya ha llegado a la línea de ensamblaje para la producción en masa.

¿Qué hacer con el alcance?

A medida que avanza el proyecto es habitual que el cliente se dé cuenta de que necesita cosas que no están incluidas en el contrato inicial. Elaboró los pliegos con el conocimiento que tenía en ese momento pero según se adquiere más experiencia en el proyecto y se va usando la aplicación (recordemos que la vamos entregando poco a poco para que la comiencen a utilizar) se va dando cuenta de que hay partes sin las que el software sería mucho menos provechoso.

En los proyectos ágiles en los que he trabajado admito modificaciones negociadas al alcance. Si se quieren incluir cinco informes nuevos a la aplicación que la harían mucho más útil deberemos acordar qué otras tareas de igual o similar estimación quitamos del alcance del proyecto. Normalmente está tan interesado en incluir las nuevas funcionalidades que no le importa sacar del proyecto otras tareas que ahora no ve tan importantes o que incluso considera que no deben hacerse.

Para la negociación habré presentado al cliente desde el arranque del proyecto una estimación de cada una de las funcionalidades a entregar de forma que sabe cuánto valen para él cada uno de estos puntos si decide quitarlos del alcance. Esta estimación fue realizada al inicio del proyecto y puede que ahora sepamos que hay cosas que son mucho más costosas de realizar de lo que estimamos al inicio, sin embargo, no cambio esta estimación inicial para que el cliente no se sienta engañado. Normalmente las estimaciones que ahora son más costosas son compensadas con otras que ahora sabemos que no lo son tanto y que también quiere que quitemos del proyecto. En cualquier caso, si hemos conseguido que el cliente esté satisfecho con el trabajo que le hemos ido entregando poco a poco y además está contento por las nuevas funcionalidades que va a conseguir, la negociación no debería ser muy dura.

¿Que hacer con el tiempo?

A veces, además de tener un importe económico y un alcance fijos tenemos que cumplir también con unas fechas de entregas inalterables que nos obligarían a aumentar las horas extras, los tiempos dedicados durante el fin de semana y el número de desarrolladores implicados en el proyecto aumentando considerablemente nuestro coste del proyecto.

Si hemos sido ágiles en el proyecto y hemos ido poniendo en producción cada poco tiempo lo que hemos ido desarrollando, el cliente podrá tener ya en uso el día de la fecha de entrega un porcentaje alto de lo que se necesita entregar. Si además hemos priorizado correctamente, desarrollando en primer lugar aquellas funcionalidades que más valor aportan, sólo quedarán fuera aquellas de menor importancia por lo que normalmente pueden entregarse en una segunda fase sin que se altere demasiado el valor del sistema.

Si hubiésemos realizado un desarrollo en cascada y estuviésemos retrasados, en la fecha de entrega no tendríamos nada que subir a producción a pesar de que podríamos tener un 80% del trabajo realizado. Durante las últimas semanas del proyecto tendríamos que abusar de las horas extras y del estrés para entregar ese 20% que nos falta pero probablemente sólo consigamos que sufra la calidad del software que entregamos y que se se ignore la fase de tests del desarrollo apareciendo un montón de bugs después de la entrega.

Sunday, 12 November 2017

Cómo ser ágiles en proyectos de mantenimiento

Son habituales en la industria ciertos proyectos, denominados de mantenimiento, en los que el trabajo consiste no en desarrollar nuevas funcionalidades al producto sino en realizar correcciones a bugs o las tareas mínimas para lograr que el sistema esté activo y dando servicio las 24 horas.

Pero a veces la carga de trabajo es tan alta, o la organización del equipo no es todo lo eficiente que debería ser, que no hay tiempo para corregir estos problemas de raíz y en lugar de corregir el código que produce los bugs ponemos parches que dan una patada hacia adelante a los problemas. Tampoco tenemos tiempo para refactorizar el código y aumentarle su calidad de forma que el número de errores tan alto que se come todo el tiempo de desarrollo. El problema llega a ser tan preocupante que, incluso cuando nuestro contrato incluye tareas de mantenimiento evolutivo, la corrección de bugs nos consume todo el tiempo disponible evitando que añadamos más valor a nuestro producto.

Si intentamos usar Scrum para poner orden en esto probablemente no nos vaya a funcionar porque semana tras semana nuevas tareas de corrección de bugs nos asaltan de forma urgente en nuestra planificación del sprint impidiendo que lleguemos nunca a cumplirlo. Retomar el trabajo días después hace que tardemos aún más debido a los cambios de contexto y porque nos vemos asaltados de nuevo por más bugs urgentes. Las planificaciones de los sprints no serán nada fiables, el análisis hecho para las nuevas funcionalidades caducará o habrá que revisarlo y ningún sprint se cumple.

Yo utilizaría Kanban en lugar de Scrum en una primera fase de estos proyectos. El uso de Kanban conlleva un menor cambio cultural en el equipo de trabajo y en los clientes y una menor sobrecarga de reuniones pero sobre todo permite una mayor agilidad para dar entrada a tareas urgentes en medio de la carga de trabajo de la semana.

En este Kanban utilizaría tres códigos de tarjetas de colores: Rojo para las tareas de corrección de bugs, amarillo para las tareas que corrigen deficiencias técnicas y code smells en nuestro código y que están haciendo que el código sea difícilmente mantenible o están produciendo bugs de forma continuada. Por último utilizaría el color verde para las tarjetas que implican el desarrollo de nuevas funcionalidades.

Tampoco separaría el equipo en dos partes, uno para corregir bugs y otro para desarrollar nuevas funcionalidades. Hacer eso está reconocido como una mala práctica debido a que los equipos dedicados a los nuevos desarrollos no aprenden lo que pasa cuando se introducen errores y por otro lado se castiga a los equipos de mantenimiento a que sólo arreglan desaguisados y con prisas y tampoco crean nada nuevo que aporte valor y reconocimiento al equipo.

En un principio nuestro Kanban estará lleno de tarjetas de color rojo pero si logramos introducir nuevas tarjetas de color amarillo y subirles la prioridad a aquellas que solucionan un número alto de bugs, en un periodo prudente de tiempo deberíamos conseguir bajar el número de bugs que se están produciendo obteniendo tiempo así para añadir al Kanban más tarjetas amarillas o incluso verdes.

Con el paso del tiempo, nuestro tablero Kanban deberá mostrar un reportorio más amplio de colores en el que finalmente, con suerte, predominará el color verde. Para esto sirven los tableros visuales Kanban, para dar visibilidad a lo que está sucediendo en nuestros proyectos.

Es en este momento, en el que el equipo realiza sobre todo tareas de mantenimiento evolutivo, cuando podríamos volver a pensar en utilizar Scrum para nuestro proyecto bajando un poco el factor de dedicación para solventar aquellas tareas urgentes que nos llegan ahora con menor asiduidad.



Sunday, 5 November 2017

Error nº 9: Apretar demasiado en el objetivo del sprint

Es el equipo el que decide qué funcionalidades caben en un Sprint y cuáles no. Los miembros del Equipo de Desarrollo son los que mejor saben cómo se hace el trabajo y los que por tanto mejor pueden calcular si en el sprint caben seis u ocho historias de usuario o lo hacen a 10.

Si viene presión de fuera para que metan más cosas en el Sprint y que se comprometan a entregar más trabajo cuando realmente no lo ven factible, esto sólo puede hacer que se acumule el resentimiento o la desconfianza o que se fomente la baja calidad del trabajo para poder entregar a tiempo. Se sabe que cuanto más ridículos son los plazos de entrega más tiempo y dinero se malgastan en intentar conseguirlos.

Cuando se planea la cantidad de trabajo que podemos hacer, se planea un tiempo para las pruebas que necesitamos hacer y asegurarnos de que el trabajo es fiable. Se planifica también una cantidad de tiempo razonable para pensar y estructurar el desarrollo. Si falta tiempo para hacer estas cosas, la calidad del trabajo se resentirá y, más adelante, en próximos sprints o después de finalizado el proyecto, pagaremos esta deuda que hemos dejado atrás con intereses de demora convertidos en bugs que nos asaltarán en los momentos más inoportunos y que reducirán el nivel de satisfacción de nuestros usuarios.

Otra cosa es que el Equipo de Trabajo se sienta retado a conseguir más cosas dentro del Sprint y que se sientan con ánimo de conseguir mucho en poco tiempo. Si conseguimos un ambiente así, en el que los desarrolladores se comprometen por sí sólos al máximo alcanzable por ellos, habremos conseguido un gran objetivo y tendremos un gran equipo.

Sunday, 29 October 2017

Error nº 8: El Scrum Master reparte las tareas

Se trata de que los equipos de trabajo sean auto-organizados y se repartan ellos mismos las tareas. Ellos son quienes mejor saben cómo hacer el trabajo y cómo mejor repartírselo entre ellos. Si dejamos que el Scrum Master o el jefe de proyecto reparta el trabajo probablemente no quede balanceado entre todos los miembros del equipo quedando más peso en unos que en otros o se hayan asignado tareas a alguien que no tiene ahora las habilidades técnicas para resolverlo igual que algún otro.

Si dejamos que ellos mismos, los miembros del Equipo de Trabajo, se repartan las tareas a realizar, el trabajo quedará más repartido y ellos tendrán un sentimiento de reparto más justo. Se trata de que levanten la mano y digan ‘Esa tarea la hago yo’ o ‘Creo que quién mejor puede hacerla es Carolina’ a lo que Carolina puede responder ‘Quizás sí, pero ya tengo asignadas las tareas 14 y 16 ¿Qué tal si la hace Fernando? Ya lo hizo una vez y puede ir ganando más experiencia con eso’.

Sunday, 8 October 2017

Error nº 7: Reuniones diarias de Scrum demasiado largas

Esto suele suceder cuando las reuniones de la Daily Scrum se utilizan para resolver los problemas y las dudas que se están teniendo en el trabajo diario. Esta es una reunión que debe mantenerse muy corta y en la que sólo deberemos comentar lo que hicimos ayer, lo que se hará hoy y qué problemas nos estamos encontrando o vamos a necesitar solución.

Es en este último punto cuando todo el mundo tiene una posible solución y la comenta en la reunión por lo que ésta se alarga y alarga con los comentarios sobre un problema que quizás sólo atañe a una o dos personas y a que a las otras no afecta directamente por lo que se aburren y pierden un tiempo en el que podrían estar ya desarrollando.

Aquí el Scrum Master debería mantener bajo control estas reuniones para que no se vayan de tiempo y hagan perder el tiempo a todo el mundo. Siempre que una discusión sobre un problema comience, deberá emplazar esta discusión para otro momento en el que sólo intervengan las personas involucradas y quizás algún tercero que no está en la reunión diaria pero cuya opinión pueda ser importante.

Es esencial también que no olvidemos tener esa otra reunión para resolver el problema ¿Para qué si no se avisó de que había un problema? Si no puede resolverse durante la reunión diaria debe atenderse en algún otro momento del día o días posteriores para ponerle solución.

Sunday, 1 October 2017

Error nº 6: Diseñar todo el proyecto desde el inicio

En Scrum es mejor no diseñar todo el proyecto antes de comenzarlo. Analizarlo todo, diseñarlo todo, construir un gran documento de requisitos de proyecto muy detallado es volver a trabajar como en los clásicos proyectos en cascada. Todas las especificaciones han sido declaradas desde el inicio y no hay posibilidad de cambio.

A estos diseños se les llama big up-front design y no permiten adaptarse a los cambios que pueden verse necesarios a medida que se va construyendo porque todo está ya especificado en un gran diseño antes de comenzar a construir una sola línea de código.

Si tienes una lista de producto pequeña al inicio, que puede ir creciendo a medida que se va avanzando en el proyecto y que se va adaptando a las opiniones y necesidades del Interesado, podrás construir un mejor producto que si haces todo o buena parte del diseño por adelantado. Mientras se va construyendo el proyecto, incluso puede que ya lo estén usando. Alguno de los Interesados puede opinar que es mejor crear una exportación a MS Excel de los informes, y esto es algo en lo que nadie había pensado por lo que no se incluyó en el diseño hecho por adelantado al inicio del proyecto.

Puede también que ya no estén tan interesados en la integración con el sistema de contabilidad Contaplus. Es un desarrollo muy complejo para las ventajas que se obtendrían y corre el rumor por la empresa que el sistema de contabilidad será migrado a SAP antes o después, así que para qué desarrollarlo ¿Qué hacemos ahora con todas las horas que usamos para diseñar esa integración con Contaplus? Puede incluso que ya estén preparadas las clases y los esquemas de base de datos con los campos necesarios para esa integración y ahora ya no van a ser usados.

Sunday, 24 September 2017

No tener reuniones de demo o retrospectiva: Otro error habitual en Scrum

Si no demostramos al cliente lo que hemos hecho en el último Sprint ¿Cómo podemos saber si vamos bien o vamos mal? Podemos seguir avanzando sin que nadie vea nuestro trabajo, tomando suposiciones y huyendo hacia adelante pero cuando llegue el momento de la entrega final en el que el cliente vea todo el proyecto podemos estar en un apuro.

Es mejor que cada poco lo vaya viendo, que dé su opinión, que corrija errores o malentendidos y sobre todo que nos diga qué hicimos bien y podemos dejar cerrado ya para seguir avanzando. Es necesario estar seguros de que el cliente ha aceptado lo que ha visto y que avanzamos sobre estructuras sólidas sobre las que seguir construyendo nuevas funcionalidades.

La demo tiene también el efecto de probar todo en su conjunto para ver que funciona bien. Alguien podría estar trabajando en el backend, otro en el frontend, otro estaría construyendo un servicio web y un cuarto está trabajando en una migración de datos. En la demo vamos a poner cada dos semanas todo esto a trabajar junto. Van a salir las dependencias, los errores por asumir que ciertas interfaces eran de una manera y no de otra y los problemas que se pueden tener al desplegar (redes, certificados de seguridad, diferencias entre los entornos de desarrollo y de demo o pre, etc.).

También es importante que te reúnas con el Equipo de Trabajo después de la reunión de demo para tener una reunión de retrospectiva. Que te cuenten si están bien, si están teniendo problemas o si creen que algo es manifiestamente mejorable. Justo después de la reunión de demo es el momento para confrontarse con la realidad. Se acaba de ver lo que salió bien y lo que salió mal, lo que quedó fuera porque no hubo tiempo y lo que el cliente rechazó porque no se le había entendido bien. Justo ahí todo el mundo tendrá una opinión de lo que es mejorable. Toma buena nota sobre algunos cambios que podrían hacerse, seguramente saldrán buenas ideas de ahí.

Sunday, 17 September 2017

Errores más habituales de Scrum (II)

Error nº 3: Pruebas insuficientes

El proyecto se te ha vuelto una pesadilla, todas las tareas hay que volver a abrirlas cuando se está terminando el proyecto porque el cliente las rechaza en las pruebas de aceptación o porque se convierten en bugs una vez están en producción. Los Interesados están descontentos y tu equipo está más tiempo buscando y corrigiendo incidencias que desarrollando nuevas funcionalidades que den más valor al producto. Para colmo de males todos están perdiendo los nervios con la situación.

Esto es señal de que en cada Sprint se han estado entregando las cosas sin estar realmente terminadas y sin ser suficientemente probadas. Una forma de probar más y mejor es automatizando los tests con pruebas unitarias, o tests de regresión y de integración con herramientas como JUnit, o de record&play como Selenium IDE. Irás creando unos pocos tests más cada Sprint para probar las historias de usuario desarrolladas en ese Sprint y el núcleo de la aplicación pero añadirás más el siguiente Sprint mientras se siguen probando automáticamente las pruebas de todos los sprints anteriores.

Los tests automatizados difícilmente sustituirán totalmente a los testers y a las pruebas manuales. Resérvate los dos o tres últimos días del Sprint para que se pare el desarrollo de funcionalidades y todos los miembros del equipo comiencen a probar las funcionalidades ya hechas para asegurarse de que están completamente libres de errores. Cada uno puede probar sus propios tickets y al terminar pueden coger las tarjetas de otros y comenzar a probar las funcionalidades de los demás miembros del equipo.

Error nº 4: Todos los entregables están grabados a fuego hasta el día del juicio final

Esto sucede cuando la Lista del Producto ha sido dividida en fases coincidiendo los sprints con una serie de entregables definidos desde el inicio del proyecto. Es decir, que si tenemos que entregar 80 funcionalidades en un proyecto de un año, se definirá desde el arranque del proyecto que debemos entregar 3 funcionalidades en los 26 sprints del año (suponiendo sprints de dos semanas) y además se definirá qué tres funcionalidades en concreto se van a entregar y éstas son inamovibles.

Esto puede convertir al proyecto en un terror de noches sin dormir porque en este Sprint hay que entregar las funcionalidades P, Q y R y en los sprints pasados no pudieron terminarse E, H, J y L. El trabajo se nos acumula. Además no estamos dando la oportunidad de redirigir el proyecto dando más peso a unas funcionalidades, quitándoselo a otras para añadir o quitar funcionalidades según lo que se demuestre más efectivo o importante.

La Lista del Producto se ha convertido en un contrato y cada Sprint en otro del que además arrastramos errores y deuda técnica dejada en el anterior. No se deja hueco para trabajar más en unas funcionalidades que llevaron más tiempo del previsto inicialmente. Todo está fijado y anclado a una estimación que se hizo al inicio del proyecto cuando no se tenía idea de qué iba a ser más fácil, qué más difícil o que podía obviarse por resultar irrelevante. Cumpliremos el ‘contrato’ de nuestra estimación diga lo que diga aunque el tiempo haya demostrado lo equivocado que estábamos cuando la hicimos.

Wednesday, 13 September 2017

Ya a la venta el libro Curso Práctico de Scrum

Ya está a la venta en Amazon las versiones en papel y electrónica del libro Curso Práctico de Scrum: Algo más que teoría. Puedes comprarlo aún a un precio reducido mientras esté en promoción.

Se trata de eso, de un curso de Scrum en el se explica al teoría de Scrum de forma práctica. En buena parte del libro se sigue la estructura que tiene la guía de Scrum de Jeff Sutherland y Ken Schwaber siguiendo su mismo orden pero evitando las palabras y tecnicismos que son sólo una traducción literal y aderezando las explicaciones con un caso real o ejemplo que te ayude a entender y poner en práctica luego lo que aquí trato de explicarte ¡Espero que te guste!

Curso práctico de Scrum: Algo más que teoría por Antonio Martel
Curso práctico de Scrum: Algo más que teoría

Sunday, 10 September 2017

Los errores más habituales de Scrum (I)

En esta seríe de posts voy a publicar una lista de los errores de Scrum más habituales que hacen que fallen las implementaciones de Scrum en muchos proyectos. Muchos de estos errores los he cometido yo mismo. Te dejo aquí los dos primeros de la serie por si pueden ayudarte a que no los cometas tú:

Error nº 1: Pasarnos de ágiles


Queremos llevar Scrum a su máximo nivel desde el principio, hacer Extreme Programming, BDD, TDD, Kanban, integración continua y un sinfín de conceptos y prácticas que implican la agilidad. No quieres perderte una pero terminas perdido entre todas sin llevar ninguna a buen puerto. Te recomiendo que empieces por lo básico de Scrum: reunión diaria, reunión de retrospectiva y que planifiques bien los sprints para que las tarjetas o historias que se entregan a los desarrolladores estén bien masticadas y sean sencillas de hacer. Ya habrá tiempo luego para ir añadiendo nuevas técnicas ágiles una vez las primeras están ya firmes y asentadas en las costumbres del trabajo.

Error nº 2: Dejar que el miedo campe a sus anchas


Los trabajadores necesitan de un entorno de confianza para poder trabajar y proponer o aventurarse a hacer cosas sin miedo a que les caiga un palo encima si algo sale mal o alguien piensa que lo que han hecho está mal.
Si no existe esa confianza para trabajar comenzarán a inflar las estimaciones para no fallar, a decidir que caben muy pocas cosas en el Sprint para que dé tiempo de sobra para hacerlas todas y a no comprometerse con el trabajo. Esto va a afectar, y mucho, al rendimiento del equipo (y su bienestar).
Las reuniones en Scrum no se han hecho para encontrar culpables a lo sucedido o para atemorizar para que trabajen más rápido. Si es así, tus compañeros estarán más tiempo pensando excusas o trabajando en cubrirse las espaldas que en arrimar el hombro para sacar el proyecto adelante. Proporciónales un entorno de trabajo tranquilo con unas metas claras en cada Sprint y tendrás un equipo con un rendimiento mucho más alto.

Monday, 4 September 2017

Ya está en preventa mi libro Curso práctico de Scrum: Algo más que teoría

Mi nuevo libro, Curso práctico de Scrum: Algo más que teoría ya está en preventa en Amazon.es, Amazon.com y Amazon.com.mx. Puedes pedir una copia ya que te será entregada en tu ebook el próximo domingo 10 de septiembre.

En este libro encontrarás capítulos como:
  • Scrum funciona y te explicaré cómo lo hace
  • Los valores que están detrás de Scrum
  • Teoría de Scrum
  • El equipo de trabajo de Scrum
  • Ceremonias de Scrum
  • Herramientas de Scrum
  • Kanban con Trello
  • Los errores más habituales en Scrum
  • Ventajas y desventajas de Scrum
Ya sabes, no lo pienses más y adquiere ya tu copia de Curso práctico de Scrum: Algo más que teoría.

Wednesday, 30 August 2017

Curso práctico de Scrum: Algo más que sólo teoría

En unas semanas estará listo mi próximo libro, Curso práctico de Scrum: Algo más que sólo teoría en Amazon España, Méjico e Internacional (.com).

De mi primer libro siempre había alguien que echaba en falta algo más de teoría en el libro sobre cómo usar Scrum y no sólo contar mis experiencias personales. De esa idea sale este libro que pretende ahondar más en la teoría de Scrum, siguiendo y explicando la popular guía de Scrum de Scrum.org pero ampliándola con ejemplos reales que ayuden a poner en contexto toda esa teoría.

Este libro está destinado a todos aquellos que se quieran iniciar en el mundo de Scrum, qué han oído un montón de palabras extrañas asociadas a este framework pero que no las entienden bien o que incluso están usando ya Scrum en sus empresas pero lo hacen de una manera incompleta o desordenada porque les falta el conocimiento teórico y práctico de Scrum que este libro les podría aportar.

Jefes de proyecto, Scrum Masters que están empezando, desarrolladores y técnicos que trabajan en equipos que usan Scrum pero no entienden por qué se hacen de esta manera las cosas, etc., todos ellos podrán encontrar en este libro la explicación teórica a una reunión o un artefacto de Scrum pero también un ejemplo práctico que te ayudará a ponerlo en situación.


Curso práctico de Scrum: Algo más que teoría por Antonio Martel
Curso práctico de Scrum: Algo más que teoría

Monday, 28 August 2017

Número 1 en Programación y desarrollo de software

Mi libro Gestión Práctica de Proyectos con Scrum ha alcanzado de nuevo el puesto número 1 en ventas en la categoría Programación y desarrollo de software de la tienda Kindle de Amazon España.

Además, si se busca en Amazon España por la palabra 'Scrum', mis libros aparecen en las posiciones 2 y 4 de los más relevantes. Si se busca por la palabra 'Agile' mi primer libro aparece en la posición número 3 y su versión en inglés (Agile 101) en la posición número 15 de los resultados más relevantes.

Les dejo aquí con capturas del momento:
Libro Gestión Práctica de Proyectos con Scrum número 1 en ventas

Libro Gestión Práctica de Proyectos con Scrum número 1 categoría Programación y Desarrollo de software de la Tienda Kindle de Amazon España

Sunday, 27 August 2017

Los valores que están detrás de Scrum (II)

Responding to change over following a plan
Si al inicio del proyecto trazamos un plan inmutable por el cual en el primer mes tendremos una funcionalidad A, en el segundo mes las funcionalidades B y C, en el tercer mes la funcionalidad D y seguimos así hasta el final del proyecto tendremos una planificación reluciente que, aparentemente, nos conducirá sin un solo problema hasta el final del proyecto.
Pero la realidad es tozuda y en algunas funcionalidades tardamos más de los previsto, en otras menos. En otras ocasiones nos pedirán que modifiquemos una o dos de las funcionalidades o que quitemos una tercera porque ya no hace falta. El resultado se traducirá en un millón de modificaciones al diagrama de Gantt y mucha presión para que las funcionalidades estén listas en el mes prefijado sin tener en cuenta la gran cantidad de cambios que han habido.
Es necesario hablar constantemente con el cliente, explicarle los cambios y volver a colaborar con él para reajustar la planificación o roadmap previsto. Puede que termine con una lista de funcionalidades distintas pero será las que él ha pedido y no las que se grabaron a fuego al inicio del proyecto y que se terminaron haciendo sean ya útiles o no.
De este Agile Manifiesto salió también una lista de doce principios a seguir por todas las metodologías ágiles. Uno de estos principios es:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Parece obvio que esto es lo que debe hacerse en cualquier desarrollo, y con ese ánimo comenzamos cada nuevo proyecto, pero pronto comienzan las prisas. Nuestro director nos pregunta cuántas horas llevamos empleadas (y llevamos ya muchas), nuestro cliente nos pregunta cuándo va a tener listas todas las funcionalidades y nuestros compañeros de trabajo nos preguntan si ya pueden cogerse las dos semanas de vacaciones que les debemos.
Empieza a pintar feo. Ya nos hemos vuelto a meter en un jaleo. Tenemos que volver a rehacer el diagrama de Gantt con las nuevas fechas de entrega programadas, tenemos que buscar otras fechas para las vacaciones (incluso las nuestras) y tenemos que dar un montón de explicaciones al director: 'Es que nos han pedido cambios, es que las tecnologías eran nuevas, es que estimamos mal'.
A partir de aquí es cuando tendemos a ponernos firmes, a exigir un esfuerzo adicional al Equipo de Trabajo y a negar cualquier pequeño cambio al cliente. Si no está exactamente escrito así en el contrato que firmamos o en el acta de una reunión que tuvo lugar hace ocho meses, lo siento, pero no lo haremos.
El caso es que el cliente también hizo esto. Redactó un contrato muy claro en el que te dijo cada una de las funciones que quería (o las que quería en el momento de redactarlo). Quizás ya no las necesite o se haya dado cuenta de que hay otras más importantes pero están en el contrato y hay que hacerlas. El proyecto no puede acabar y dejar un 30% de funcionalidades por hacer.
En este momento ya hemos perdido de vista la que debe ser la máxima prioridad en nuestro trabajo. Entregar de forma continua software que funcione y que aporte valor. A partir de aquí ya no quedan sino duras negociaciones y un contrato que trataremos de cerrar cuanto antes con el menor daño posible.
El contrato podrá tener muchos artículos y estipulaciones pero, ponga lo que ponga, cuando el cliente lo redactó lo que quería era una solución a su problema, no una discusión sobre si se debe o no implementar esa función o la otra.
Pero, si vamos entregando cada poco tiempo el software que vamos haciendo, lo dejamos para que lo pruebe y lo use, que nos diga su opinión. Dejemos que encuentre lo que echa en falta o lo que podría mejorar. Va a querer que le implementemos esto que ahora ha visto que necesita y estará encantado de quitar a cambio esa funcionalidad para exportar a ficheros .rpt que ya ni se acuerda de quién se lo pidió ni por qué.
Al finalizar el proyecto el cliente tendrá un producto que de verdad resuelve sus problemas, que ha ido evolucionando a medida que él mismo aprendía y que ha podido usar y probar desde las primeras semanas del proyecto. Suena mejor para cliente y proveedor ¿no?
Otro de esos principios que rigen Scrum es:
Working software is the primary measure of progress.
Cuántas veces no nos habremos puesto a escribir software y sin enseñárselo a nadie ni que nadie lo use hemos ido poniendo cada semana o cada mes que íbamos por el 30, 40 o 50% del software hecho ¿Cómo podíamos haber sabido esto si nunca estuvo todo el software funcionando junto ni lo vió ningún responsable para saber que eso era en verdad lo que ellos requerían?

Esos porcentajes eran una simple estimación, una medida de progreso que no se basaba en una realidad constatable. Por esto se definió este principio: El software funcionando es la principal medida de progreso. Si hemos hecho 10 de las 20 funcionalidades que nos han solicitado, éstas son de tamaño similar, las hemos probado, hemos recibido la aprobación del cliente, entonces, y sólo entonces, podremos decir que nuestro proyecto está completado en un 50% (mejor aún si ese 50% ya ha sido subido a producción y ha sido usado por usuarios reales que son la verdadera prueba de fuego).

Thursday, 24 August 2017

Los valores que están detrás de Scrum

Hace 16 años, en 2001, se reunieron en Utah diecisiete profesionales del software críticos con los modelos de desarrollo de software que se llevaban hasta entonces. Los consideraban demasiado pesados o rígidos. En esa reunión estaba gente como los fundadores de Scrum o Kent Beck y Martin Fowler. Habían quedado para hablar sobre nuevas técnicas y procesos para desarrollar software.
De esa reunión salió un manifiesto con una serie de valores y principios que debían cumplir los nuevos métodos alternativos (y ágiles) que estaban proponiendo: Valores detrás del movimiento ágil.
Estos valores que rigen los principios ágiles son:
Individuals and interactions over processes and tools
Se pone el énfasis en los individuos y los equipos de trabajo más que en los procesos rígidos que hayamos establecido para comunicarnos entre todos o para hacer las cosas. Poniendo a los miembros del equipo de trabajo en el centro de las decisiones obtendremos un plus de productividad mayor que si es un proceso el que dicta qué hacer y no hacer en cada momento.
Tampoco las herramientas son importantes. Nos basta un tablero o unas hojas de papel con las listas del producto y del sprint o unos pequeños post-it. Las últimas herramientas, más caras (y difíciles de usar) herramientas en gestión de proyectos no nos van a dar una gran ayuda a la hora de resolver nuestro trabajo. Por esto, rara vez, una implementación de Scrum aconseja usar una u otra herramienta. Eres libre de elegir la que quieras siempre que seas consciente que esa no es la decisión más importante en tu proyecto.
Working software over comprehensive documentation
Esto significa que valoramos más un software que funciona y que está libre de errores que una exhaustiva documentación que documenta con pelos y señales cada sección de la aplicación. Esto no quiere decir que ignoremos o pasemos de la documentación. La documentación sigue siendo necesaria pero, por favor, no la pongamos por encima de loa verdaderamente importante, que es el código funcionando. Un código chapuza o de difícil mantenimiento funciona igual si tiene mucha o poco documentación. Prestémosle nuestro tiempo a mejorar el código y no a documentarlo. Nos pagan por línea de código funcionando no por tonelada de papel con documentación.
Customer collaboration over contract negotiation
Esta es uno de los problemas más enraizados en el desarrollo de software hoy en día. Los proyectos salen mal, se pasan de horas, se retrasan las fechas de entrega y para evitarnos las posibles discusiones con los clientes ponemos paños calientes sobre el problema preparando una batería de cambios que han solicitado y que no estaban en el contrato inicial.
Probablemente el cliente no entenderá que los cambios solicitados sean tan importantes como para justificar un retraso tan grande y aquí comienzan las negociaciones sobre el contrato: ‘Yo no te haré la integración con el sistema SAP porque me has saturado con pequeños cambios en las funcionalidades anteriores’ a lo que el cliente contesta ‘Sin esa integración el proyecto vale poco o nada por lo que no voy a abonar los pagos pendientes hasta que esté hecha hasta la última coma del contrato’.
En una negociación no seas el primero el poner el arma encima de la mesa. El cliente siempre tendrá una arma más poderosa que la tuya y ambos saldrán perdiendo. Sobre todo tú que perderás un posible futuro cliente y ganará en malas referencias.

Es más fácil tener la lista del producto sobre la mesa desde el inicio cuando comenzaron a pedir cambios que probablemente sí que les hacían falta hacer. Sobre esa lista del producto anotar los nuevos cambios y pedirle al cliente que saque de la lista otra serie de funcionalidades de igual valor que ya no le resulten tan importantes. Seguro que de buen grado encontrará funcionalidades a las que ya no le ve tanto sentido y que estará encantado de quitarlas con tal de que les hagas las que sí les hacen falta realmente.

Sunday, 20 August 2017

Definición de Terminado

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



Sunday, 13 August 2017

Transparencia en Scrum

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.

Wednesday, 9 August 2017

La lista del sprint o Sprint backlog

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.



Sunday, 6 August 2017

Seguimiento del progreso en Scrum

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.

Saturday, 5 August 2017

Test de Scrum con Ruby on Rails

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.


Wednesday, 2 August 2017

La Lista del Producto o Product Backlog

La Lista o Pila del Producto es una lista ordenada por prioridad de todas las funcionalidades que pueden ser necesarias para incorporar al producto. Tendremos ahí todos los requisitos del proyecto y de esa lista tomaremos un subconjunto para los requisitos que implementaremos en un Sprint. Ese subconjunto de tareas es la que compondrá la Lista del Sprint.

El Dueño del Producto, que es quién paga o quien representa a quien paga el producto, es quién conoce lo que quiere para su producto y quién, por tanto, nos dirá lo que hay que hacer. El definirá los requisitos del proyecto por lo que es él el responsable del contenido de la Lista del Producto y de su priorización.

La Lista del Producto no tiene que estar completa desde el principio, de hecho, nunca está completa. Más requisitos pueden ir llegando a medida que se va avanzando en el proyecto. Al principio sólo contendrá los requisitos conocidos y que están más claros o mejor entendidos.

Si nuestro proyecto proviene de un contrato con nuestro cliente en el que ya se definen las funcionalidades que tendrá el producto podremos comenzar con estas funcionalidades como germen de nuestra Lista del Producto. Pero no de sólo funcionalidades viven los proyectos, hay muchas otras tareas que deberemos realizar y que también van en la Pila del Producto. Tareas como estas compondrán nuestra lista:

  • Funcionalidades o características del software, por ejemplo: Permitir pago con Paypal
  • Bugs: Corregir error de certificado no autorizado al acceder a la aplicación
  • Trabajo técnico: Instalar la base de datos o Preparar los entornos de desarrollo y pruebas con Docker
  • Adquisición de información: Tomar requisitos más detallados sobre cómo se debe recoger la información de los clientes que pagan a crédito.
La forma habitual en la que se expresan los requisitos en cada una de las tarjetas o elementos que componen la Lista del Producto es como historias de usuario que son descripciones breves del requerimiento. Por ejemplo: "Cómo usuario de la banca online, quiero poder ver una lista de las transferencias periódicas que ya tengo creadas para poder revisarlas antes de crear una nueva".


Cada poco tiempo y de forma continua el equipo de trabajo deberá acometer una revisión de estas tarjetas o historias de usuario de la Pila del producto para añadirles el detalle suficiente para poder comenzar a trabajar. Esta tarea de revisión se llama Refinamiento (refinement). Podemos tener una tarjeta que diga "Permitir el pago con Paypal" pero no podemos pasar esto así a los desarrolladores, deberemos analizar esto un poco más para añadir "Cuando un cliente está en el sitio web, quiero tener la opción de pagar con PayPal después de haber establecido el pedido, de forma que pueda confirmar la compra".

Pero aún así, cuando lleguemos al Sprint en el que queramos acometer este trabajo, deberemos de tener esta historia de usuario descompuesta en otras más pequeñas:

  • "Como usuario de la banca online, quiero tener un enlace a registrarme como usuario de PayPal después de haber realizado el pedido"
  • "Como usuario de la banca online, quiero poder introducir mi número de tarjeta, fecha de caducidad y número CCD para identificar mi tarjeta después de haberme registrado como usuario de PayPal"
  • "Como usuario de la banca online, quiero poder hacer clic en un botón 'Pagar con Paypal' debajo del subtotal de mi compra para poder confirmar mi pedido"

Los elementos de la Lista del Producto de prioridad más alta estarán normalmente más detallados y más refinados mientas que los de prioridad más baja tienen un nivel de detalle más bajo y son más vagos en su descripción. Debemos trabajar más en el refinamiento de las funcionalidades de más alto nivel que son las que van a ser acometidas en los próximos sprints y evitar dar un detalle muy alto en tarjetas de muy baja prioridad que no sabemos si van a ser acometidas o si tenemos ya toda la información que necesitamos para acometerlas.

Será el equipo de trabajo el que se encargue de proporcionar una estimación para los elementos de la Lista del Producto ya que son quienes van a hacer el trabajo y quienes se están comprometiendo a tenerlo terminado para el final del Sprint. No será necesario que estimen todos los elementos de la Pila del Producto de una sola tacada sino que estimen los que se van a acometer ahora. De este modo tendremos estimaciones más precisas porque los elementos de la lista están más claros y detallados y evitamos perder el tiempo estimando elementos muy abajo en la lista para los que no tenemos suficiente información y que puede que ni siquiera se lleven a cabo.

Sunday, 30 July 2017

Retrospectiva del sprint

Esta reunión se realiza después de la reunión de demo con el cliente y tiene una duración de tres horas para sprints de un mes. Se trata de una reunión en la que queremos que el equipo Scrum se revise a si mismo y dé feedback de cómo han ido las cosas, por qué no pudieron conseguirse todos los objetivos del sprint, si fue así, y qué podemos hacer para mejorar en el siguiente sprint.

A esta reunión asistirán el Dueño del Producto, el Scrum Master y el equipo de desarrollo. El Scrum Master como siempre se encargará de que la reunión tenga lugar. de que se mantenga dentro de los tiempos máximos definidos y que se traten al menos los siguientes aspectos en la reunión:

  • Qué cosas han funcionado bien
  • Qué cosas no han funcionado tan bien y evitaron que pudiéramos demostrar al cliente todo lo que se esperaba de este sprint que acaba de terminar
  • Qué problemas han impedido o pueden impedir que no consigamos nuestra meta del sprint y que el cliente por tanto no obtenga lo esperado. El Scrum Master se encargará de anotarlas para luego ponerse a resolverlas.

De esta reunión de retrospectiva debería salir un plan, ordenado por prioridad, con las distintas mejoras que podrían implementarse para evitar los problemas detectados.

Existen diversas causas por las que las reuniones de retrospectiva resultan poco provechosas o no todo lo útiles que deberían:

Las reuniones son aburridas y monótonas

La gente puede perder la confianza en las retrospectivas y verlas como una perdida de tiempo si no se toma ninguna acción después de analizados los problemas que se están teniendo. Se están identificando los problemas y se están declarando pero no se hace nada al respecto o tarda mucho en tomarse consciencia de lo que están suponiendo. Debemos tomar buena nota de cada una de las mejoras propuestas y de los impedimentos que están impidiendo avanzar y hacer algo con ellos. Tener una reunión de retrospectiva para luego no tomar ninguna medida va a hacer que se pierda la fe en estas reuniones.


La gente tiene miedo de las retrospectivas

Miembros del equipo de desarrollo pueden sentirse temerosos de comentar los problemas reales que están viendo y sólo dicen vaguedades o pequeños impedimentos pero no la causa que ellos ven como la más importante y por la que no se consiguen los objetivos del sprint. Quizás por temor a herir los sentimientos del Scrum Master o del Dueño del Producto si no están haciendo bien su trabajo, quizás por no molestar al analista que no recoge bien los requerimientos, quizás por temor a ser represaliados si son demasiado directos con lo que se piensa.

Recordemos que la reunión de retrospectiva no es una reunión formal en la que buscar culpables a lo que está pasando. Debe crearse un ambiente en el que todos deben sentirse libres de dar su opinión sin temor a que alguien se moleste. Se trata de una reunión para aprender no para echar las culpas. De ella deberemos salir con un listado de mejoras y no de nombres. Es bueno recordar estos puntos antes de comenzar cada reunión si comenzamos a pensar que el equipo de trabajo no se siente libre para decir lo que piensa.

Wednesday, 26 July 2017

Demo del sprint o sprint review

Al finalizar el sprint se realiza una revisión de lo entregado en el sprint para poder ver lo que se ha estado haciendo durante el mismo y tener la oportunidad de adaptarse si hubiese que hacer algún cambio. No se trata de una reunión de seguimiento en la que se va a juzgar al equipo de desarrollo sino de tener la posibilidad de presentar el trabajo y comprobar cómo de cerca o de lejos estamos del objetivo y si necesitamos hacer cambios para que el producto esté más orientado a las necesidades del cliente.

El tiempo máximo establecido para esta reunión de demo o presentación del trabajo del sprint es de 4 horas para sprints es de un mes o la mitad si el sprint es de sólo dos semanas. Es trabajo del Scrum Master el que la reunión se lleve a cabo y se mantenga dentro de los tiempos establecidos.

A esta reunión de demo asistirán el Scrum Master, el Dueño del Producto, el equipo de trabajo y los interesados que el Dueño del Producto invite a la reunión y en ella se explicarán qué elementos de la pila del producto se han terminado y cuales no para poder acabarlos. Tras esto el equipo de desarrollo demostrará ante todos los asistentes cómo funcionan los elementos terminados de la lista del sprint.

Esta reunión servirá para que el cliente pueda ver cómo se han desarrollado los requisitos que ha dado, si se están entendiendo estos requisitos, sus objetivos generales para el producto y comprobar si se cumplen sus objetivos. El equipo, desde su punto de vista, puede comprobar si realmente está entendiendo estos requisitos y mejorar la comunicación con el cliente. Estas reuniones en las que se presenta el producto poco a poco servirán para ir entregando el trabajo e ir obteniendo feedback del mismo sin esperar meses y meses antes de presentarlo al cliente que podría no estar contento con las decisiones tomadas en todo ese tiempo.

Algunos de los problemas más habituales de las reuniones de demo del sprint son:

Demos indemostrables

Habrá ocasiones en las que los miembros del equipo de desarrollo pueden pensar que no tienen nada que mostrar en esta reunión de demo o que lo que han hecho en este sprint no tiene una interfaz gráfica que pueda ser mostrada. En casos como estos deberemos buscar una demo mínima que pueda presentarse.

Por ejemplo, si tenemos una funcionalidad que se trata de montar el entorno de desarrollo para poder comenzar a trabajar, en la reunión de demo mostraremos el Eclipse funcionando con el jetty configurado para las pruebas, el cliente de Subversion instalado y la herramienta de conexión a la base de datos correctamente configurada para establecer la conexión.

Si tenemos otra tarjeta que nos indica que debemos montar una estructura de tablas de bases de datos y sus relaciones podremos crear una página Hello World mínima que se conecte a esta base de datos y muestre un listado de las tablas que acabamos de crear.

Demos vacías

Hacemos demos pero en estas se muestran sólo powerpoints y no trabajo real que demuestre que no estaremos avanzando a través de los sprints y cuando alcanzamos el final del proyecto nada funciona, los módulos no están bien integrados entre sí y nada pinta tan bien como lo hacían en los powerpoint.

Deberemos mostrar trabajo real en las demos que presenten lo que se ha estado haciendo. Los powerpoint están prohibidos en estas presentaciones. Será necesario buscar la manera de presentar nuestro trabajo y que sea éste el verdadero valor de lo que estamos haciendo.

Temor a las demos

A veces el equipo de trabajo acude con miedo estas demos. Va a estar el cliente, el dueño del producto, quizás más representantes del cliente y no hemos terminado todos las funcionalidades previstas para el sprint, o lo que es peor, algo puede fallar en la presentación y verse mal. Bueno, no pasa nada, la reunión de demo no es una reunión de seguimiento, se trata de mantener una reunión intencionalmente informal.

Se mantiene esta reunión cada poco tiempo para que no haya grandes dramas o grandes sorpresas en ellas. Se trata de tomarle el pulso al proyecto y ver cómo va, no de apretarle las tuercas al equipo de desarrollo. Si algo salió mal en la reunión de demo será nuestra prioridad en el siguiente sprint y como seguramente sólo será la corrección de un bug podremos sumar puntos fácilmente en la reunión de demo del siguiente sprint.

Si las cosas salen mal repetidamente en las reuniones de demo o muchas funcionalidades previstas para el sprint quedan marcadas como no terminadas porque no pasan los tests, deberemos reducir la carga de trabajo prevista para nuestros sprints. Nuestra velocidad está siendo más baja de lo que pensábamos y necesitamos algo más de tiempo para que más cosas sí queden bien terminadas en la reunión de demo.


Sunday, 23 July 2017

Scrum diario o Daily Scrum

La reunión diaria de Scrum es una reunión de 15 minutos en la que el equipo Scrum se reúne siempre en el mismo sitio y a la misma hora para comentar sus actividades diarias. Cada uno de los miembros del equipo contesta a las siguientes preguntas:
  • ¿Qué hice ayer?
  • ¿Qué haré hoy?
  • ¿Qué me impide avanzar?
Con estas preguntas se sincroniza todo el equipo de trabajo que cada día sabrá qué es lo que han estado haciendo sus compañeros de trabajo y en qué van a trabajar hoy. También sabrán si sus compañeros tienen alguna dificultad o la prevén para un futuro cercano y si pueden ayudar. Esto favorece que surjan cuestiones, dudas y ofrecimientos de ayuda que nos hagan avanzar más rápidamente. Algunas de las frases más útiles que pueden surgir durante estas reuniones son:
  • "No sé cómo añadir la autoridad certificadora a nuestra KeyStore de Java" a lo que otro compañero responde "Yo he hecho esto antes, luego nos vemos y te explico".
  • "Se me están acabando las tareas antes de ejecutar los nuevos scripts, pronto necesitaré un backup de seguridad de producción" a lo que el Scrum Master podría responder "Le pediré al cliente que realice un export de producción con fecha de mañana a las 03:00 AM".
  • "Hoy voy a acabar con las historias de usuario para las transferencias periódicas. Pronto se necesitará analizar nuevas historias de usuario con el Dueño del Producto" a lo que el analista responde "Me veré con el Dueño del Producto lo antes posible para que las tengas preparadas antes de comenzar el trabajo".
A menudo, después de esta reunión, el equipo de desarrollo o algunos de sus miembros se reúnen inmediatamente después para resolver las cuestiones que han surgido. En los ejemplos anteriores se reunirían los dos desarrolladores para explicar cómo añadir la autoridad certificadora al KeyStore, el analista y el Dueño del Producto para describir nuevas historias de usuario y el Scrum Master iría a llamar por teléfono al cliente para programar una exportación de la base de datos de producción.

El trabajo del Scrum Master en esta reunión consistirá en asegurarse de que tenga la reunión todos los días, de cumplir la regla de que sólo los miembros del equipo de desarrollo participan en el Scrum Diario y de que esta reunión se mantenga en los límites de tiempo de 15 minutos por reunión.

Es habitual que en muchas organizaciones esta reunión de Scrum diaria se haga de pie (Daily stand-up meeting) para evitar que los asistentes hablen más de la cuenta y la reunión dure más de 15 minutos. Yo en cambio las prefiero organizar sentados alrededor de una mesa de reunión y escribir en una hoja de papel o en un documento de Google Docs las respuestas a las tres preguntas de la reunión. Luego, una vez terminada la reunión, revisaba cada una de las respuestas y a modo de checklist comprobaba que no quedasen cuestiones sin resolver o que se dijeron en la reunión y no queden en el olvido.

Un problema habitual en muchos equipos Scrum es que las reuniones diarias duren mucho más de los 15 minutos programados, reuniones de pie que duran más de una hora consumiendo el tiempo productivo de los desarrolladores y que llegan a ser temidas por los miembros del equipo de trabajo. Es frecuente también que algunos opinen que 15 minutos no son suficientes para mantener la reunión diaria. Hay diversas razones por las que pasa esto. Algunas de las más habituales son:

Reuniones dentro de la reunión diaria

Dentro de la reunión diaria se quieren mantener las reuniones detalladas para resolver problemas específicos que deberían mantenerse después de la reunión diaria. El equipo de trabajo no debe entrar en cómo añadir la autoridad certificadora a la KeyStore en Java sino que ésto debe quedar para otra reunión inmediata posterior, en la que estén sólo los implicados, para ahondar en esta explicación.

Las cosas no están claras

Falta un objetivo del sprint claro o falta refinamiento en el backlog. Cuando no hay un claro objetivo del sprint es habitual que surjan muchas dudas durante la reunión diaria. Del mismo modo cuando los requisitos de las historias de usuario no están suficientemente bien refinadas y recogidas vuelven a surgir muchas cuestiones en la reunión diaria. Si trabajas en resolver estos puntos, el trabajo diario de los desarrolladores será mucho más claro y conciso por lo que estarán deseando acabar la reunión para continuar con su desarrollo.

Se explica hasta el último detalle

Se entra en especificar hasta el último detalle de la tarea que se está haciendo. Si la reunión dura 15 minutos y en el equipo trabajan 4 desarrolladores tendrá menos de 5 minutos cada uno para responder a las 3 preguntas. Aproximadamente 1 minuto 15 segundos por pregunta. Es realmente muy poco tiempo por lo que hay que ser muy conciso. Hay personas que con esto tienen tiempo suficiente pero otras que realizan un repaso tan completo a cada uno de los detalles en los que están trabajando que requieren al menos el triple de tiempo. Hay que explicarles que se trata de ser breves, explicar a grandes rasgos en qué están trabajando y del límite de tiempo que se tiene para que la reunión sea productiva y para que los demás no se aburran o desconecten de la reunión.

Saturday, 22 July 2017

Mi libro, de nuevo bestseller

Ya van más de tres años desde que mi libro Gestión práctica de proyectos con Scrum salió a la venta. Desde entonces ha alcanzado numerosas veces el puesto número 1 en ventas en diversas categorías a a las vez, y en dos ocasiones, el número 1 en ventas en todo Amazon.

Hoy, sobre las 9:00, ha vuelto ha alcanzar un puesto como número 1 en ventas en la categoría Internet y web de la tienda Kindle de Amazon España alcanzando también el número 2 en la categoría de libros (todos, electrónicos y de papel) de Programación y desarrollo de software.

Les dejo imágenes de las posiciones en Amazon España:

Libro Gestión práctica de proyectos con Scrum bestseller en Amazon
Número 1 en categoría Internet y web

Libro Gestión práctica de proyectos con Scrum bestseller en Amazon
Libro como bestseller en Amazon España


Wednesday, 19 July 2017

El objetivo del sprint

El objetivo del sprint es la meta que definiremos durante la reunión de planificación del sprint y que nos permite tener una idea clara, en palabras, de qué es lo que conseguiremos si acabamos de implementar todas las funcionalidades definidas para este Sprint. Se trata de dar una función coherente a los elementos de la lista del producto seleccionados para este sprint.

Si por ejemplo desarrollamos una web para la banca online podríamos tener un sprint en el que habría que desarrollar los siguientes elementos:

  • Desarrollar formulario que permita definir transferencias periódicas de dinero (mensuales, trimestrales, anuales).
  • Desarrollar vista que permita ver, anular y modificar transferencias periódicas.
  • Desarrollar módulo backend que permita que las transferencias periódicas programadas se ejecuten a su debido momento.
Para que, a medida que se trabaja, el equipo mantenga el objetivo del sprint en mente podríamos definir la meta del sprint la siguiente:
Permitir crear al usuario transferencias periódicas de dinero.
Sin embargo, con frecuencia tendremos para el sprint una serie de funcionalidades o bugs a resolver que juntos no permiten dar un objetivo o meta clara en común. Pensemos por ejemplo que estamos desarrollando una web de eCommerce en la que, durante la reunión de planificación del sprint, decidimos que las historias de usuario a desarrollar sean:

  • Implementar la forma de pago con PayPal.
  • Añadir varios productos a la vez a la cesta de la compra.
  • Proporcionar sugerencias útiles a los usuarios registrados que ya compraron algo.
  • Corregir bug en producción por el que no se muestra el último elemento de la cesta de la compra cuando éste contiene más de 200 caracteres en su descripción.
  • Corregir bug en producción por el que no se muestran correctamente los caracteres especiales como tildes y acentos del idioma francés.

Para un caso como este en el que no tenemos una narrativa común que defina un objetivo claro para el sprint podríamos definir lo siguiente como meta del sprint:

Objetivo del Sprint: Implementar 3 historias de usuario y corregir todos los errores de producción.

Sunday, 16 July 2017

Reunión de planificación del Sprint

Durante esta reunión, mantenida al inicio del Sprint o poco antes de empezarlo, se planifica el trabajo a realizar durante el Sprint. Participarán en ella el Scrum Master, el equipo de desarrollo y el Product Owner.

Para sprints de un mes esta reunión durará un máximo de ocho horas durando menos si el Sprint es más corto de un mes. El Scrum Master se encargará de que la reunión se lleve a cabo, de que todos entiendan para qué es la reunión y que ésta se mantenga dentro de las ocho horas de margen de tiempo.

En esta reunión de planificación calcularemos qué puede entregarse al finalizar el Sprint que va a comenzar y cómo haremos el trabajo para conseguir este objetivo:

Qué puede entregarse al finalizar el Sprint

Con la vista puesta en los objetivos definido por el Dueño del Producto discutiremos con el equipo de Desarrollo qué funcionalidades deberemos desarrollar y si caben dentro del Sprint. Escogeremos de la Lista de Producto esas funcionalidades y las pasaremos a la Lista del Sprint. Si logramos acabar esta selección de elementos de la Lista de Producto dentro del Sprint habremos conseguido el Objetivo del Sprint.

Sólo el equipo de desarrollo puede decir cuantos elementos de la lista de producto entran a formar parte de la lista del sprint. Con la vista puesta en esa lista de producto y en el rendimiento obtenido en sprints pasados, el equipo de desarrollo hará una proyección de hasta donde puede llegar en este sprint.

Cuando el equipo de desarrollo ha finalizado este cálculo de cuantos elementos de la lista de producto puede terminar en el sprint, el equipo Scrum al completo (Scrum Master, Dueño del producto y equipo de desarrollo) deciden cuál será el Objetivo del Sprint (Sprint Goal). Este objetivo estará presente durante todas las semanas de implementación del Sprint y servirá como guía al equipo de desarrollo para saber por qué y para qué se está trabajando en ese sprint

Cómo haremos el trabajo para conseguir el Objetivo del Sprint

 Los elementos de la Lista de Producto (Product Backlog) seleccionados para este Sprint componen la Lista del Sprint (Sprint Backlog) y son los elementos que el equipo de desarrollo implementará para entregarlos al final del Sprint.

El equipo de desarrollo diseñará las funcionalidades y el trabajo necesario a realizar para completar el Sprint y concluirá la reunión con éste trabajo descompuesto en unidades o tareas de un día o menos. A partir de ahí el equipo de desarrollo se auto-organizará para tomar estas tareas y llevarlas a cabo a lo largo del Sprint.

Durante la reunión de planificación el Dueño del Producto explicará lo que hay que desarrollar para poder hacer las nuevas funcionalidades de la Pila del Sprint. El equipo de desarrollo tomará más elementos de la Pila del Sprint si no tiene suficiente trabajo para el Sprint o renegociará con el Dueño del Producto los elementos de esta lista si tiene demasiados.

Al finalizar esta reunión del planificación del sprint tendremos:

  • La Lista o Pila del elementos del Sprint (Sprint Backlog)
  • El Objetivo del Sprint
  • La descomposición de la Lista del Sprint en tareas de 1 día o menos.

Sunday, 9 July 2017

Ceremonias de Scrum

En Scrum existen diversas reuniones o eventos, también llamadas ceremonias, que tratan de crear regularidad y reducir al mínimo la necesidad de reuniones fuera de las definidas en Scrum. Todas estas reuniones tienen una duración máxima (timeboxing) con el objetivo de que estos eventos no se conviertan en eternos llevándonos por disquicisiones que no van a ningún lado o a la pérdida de tiempo.

El propio Sprint es el evento central dentro de Scrum y contiene al resto de eventos y ceremonias. Todos estos eventos están diseñados para permitir la inspección y la adaptación de lo que está pasando en el proyecto. Cada uno de ellos es una oportunidad de mejorar el proyecto y darle transparencia a todos los participantes. Si falta alguno de ellos podría estar faltando transparencia al proyecto y perderse esa oportunidad de adaptarse a los cambios para mejorar.

El Sprint

El Sprint es el corazón de Scrum, es un bloque de tiempo de un menos o menos, suele ser de dos semanas, durante el que se crea un incremento del producto Terminado, Utilizable y Potencialmente desplegable. Estas tres características son importantes:

  • Terminado: Se dice así cuando por consenso de los participantes del proyectos, las funcionalidades, nuevas características o errores corregidos durante el Sprint están completamente hechos o terminados. Es decir que no faltan fases de test o que las funcionalidades están incompletas a falta de uno o más sprints para finalizarlos.
  • Utilizable: Las nuevas características que estamos añadiendo en este Sprint son utilizables por el usuario final que las puede comenzar a usar tan pronto como hayan sido desplegados. No se trata de características a las que les falte alguna otra funcionalidad a ser desarrollada más adelante para poder ser utilizada.
  • Potencialmente desplegable: Puede que decidamos no subir a producción tan pronto como terminemos el Sprint y que esperemos a tener un conjunto mayor de funcionalidades a hacer esta subida pero lo que entreguemos al final el Sprint estará listo y podría ser desplegado en producción si así lo hubiéramos decidido.

Dentro de cada Sprint encontraremos las siguientes reuniones y ceremonias que se explicarán con más detalle a lo largo de este capítulo:

  • Reunión de planificación del Sprint (Sprint Planning Meeting)
  • Reuniones de Scrum Diario (Daily Scrums)
  • Reunión de demo o revisión del sprint (Sprint Review)
  • Retrospectiva del Sprint (Sprint Retrospective)

El Sprint tiene las siguientes características:

  • Cada Sprint comienza justo después de la finalización del Sprint anterior.
  • El Sprint se ajusta a un Objetivo del Sprint que es la meta que quiere alcanzarse cuando se acabe el Sprint. Por ejemplo: Desarrollar el sistema de login de la aplicación.
  • No se disminuyen los objetivos de calidad para llegar al objetivo del Sprint.
  • El alcance del Sprint puede ser clarificado con el Dueño del Producto y el Equipo de Desarrollo para renegociarlo con ellos a medida que sucede el Sprint y vamos conociendo más durante el Sprint. 

Podemos considerar al Sprint como un mini proyecto que tiene un horizonte de un mes o menos (por ejemplo dos semanas). Un proyecto que tiene un objetivo y unas etapas en las que se va a definir qué se va a construir, se diseña y se trabaja un plan para la construcción del producto resultante al finalizar esas dos semanas.

El objeto de dividir el proyecto en todos esos mini proyectos de un mes o menos es el del clásico divide y vencerás. Con proyectos tan pequeños podemos mantener acotada al complejidad, evitar que cambie lo que se está construyendo y evitar que aumente el riesgo de proyecto durante ese tiempo. Además al ser proyectos tan pequeños podemos adaptarnos al finalizar y comenzar un nuevo Sprint a lo que hayamos aprendido en el Sprint anterior. Por todo esto el riesgo de estos mini proyectos estarán limitados al costo de un mes de trabajo como máximo.

¿Se puede cancelar un Sprint?

Sí, un Sprint puede ser cancelado antes de que llegue a su fin. El Dueño del Producto y sólo él puede decidir que no merece ya la pena el Objetivo del Sprint por lo que puede concluirlo.

Algunas cosas pueden ocurrir en el plazo máximo de un mes que puede durar un Sprint: la dirección cambia de estrategia, a los interesados en el producto ya no le interesan las funcionalidades a desarrollar en este Sprint, o las condiciones del mercado o de la tecnología cambian y ya no tiene sentido el objetivo del Sprint.

Debido a la corta duración del Sprint las cancelaciones normalmente no tienen lugar porque no tantas cosas pueden cambiar de repente. Es algo que debemos de evitar porque cancelar un Sprint tiene un coste: Hemos estado preparando y planificando el Sprint y debemos reunirnos de nuevo para planificar el siguiente. Casi todo ese esfuerzo se tira a la basura para comenzar un nuevo Sprint. Podemos dar además la sensación de estar actuando sin una clara dirección o estar tomando los objetivos de los sprints muy alegremente, sin pensarlos demasiado.

A la hora de cancelar un Sprint revisaremos todos los elementos de la Lista o Pila de Producto y comprobamos cuales de ellos están en estado Terminado y son potencialmente entregables para presentarlos al Dueño del Producto y que éste diga si lo acepta como entrega o no. El resto de elementos de la Lista del Sprint que no estuviesen completados vuelven a la Pila del Producto para volver a ser estimados ya que el trabajo que se haya hecho en ellos pierde valor con rapidez y debe volverse a estimar.