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.