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.