Conceptos principales de Scrum

Basándome en lo explicado en el libro de Henrik Kniberg “Scrum y XP desde las trincheras”, en este post lo que pretendo es recopilar y explicar brevemente los conceptos principales en los que se basa Scrum.

Vamos a separar por un lado las personas implicadas en un proyecto que sigue esta metodología y, por otro lado, los productos y tareas que hay que completar durante el proceso que Scrum propone.

En primer lugar las personas:

• El cliente: Es la persona que solicita un proyecto de cara a satisfacer una necesidad propia o de su negocio.


• El propietario del producto (Product Owner): Es la persona que hace de intermediario entre el cliente (no técnico) y el equipo y tiene capacidad de decisión sobre los requisitos a implementar.


• El equipo: Es el personal técnico que se encargará de la realización del proyecto.


• El Scrum Master: Es la persona conocedora del proceso Scrum que se encarga de orientar al equipo y al propietario del producto para que sigan el proceso determinado por Scrum. Si las personas involucradas en el proyecto ya conocen Scrum su labor puede no ser necesaria.

Y, en segundo lugar, los productos y tareas necesarias:

• La pila de producto: Es una lista priorizada de requisitos o “historias” del cliente escritos usando su propia terminología, de forma no técnica.


• Reunión de planificación del sprint: En esta reunión el equipo y el propietario del producto negocian sobre el alcance de cada sprint en base a las estimaciones y a la importancia de cada una de las historias de la pila del producto.


• La pila de sprint: El la lista de historias sacadas de la pila del producto que conforman el alcance del sprint actual.


• Reunión diaria de scrum: En esta reunión el equipo discute los problemas que se va encontrando a medida que el producto avanza y revisa sus estimaciones para poder llevar el seguimiento del avance del proyecto.


• Demostración: Como colofón a cada sprint se debe presentar una demostración de aquello que se ha implementado, de cara a obtener retroalimentación sobre el proyecto por parte de los interesados que permita encaminar futuros sprints.


• Retrospectiva: Al final de cada sprint se lleva a cabo una reunión que permite revisar qué se ha hecho bien y mal durante el sprint con el objetivo de mejorar el proceso.

Para terminar, resumiré de forma breve el proceso que define Scrum:

• En primer lugar, el propietario del producto construye la pila del producto con las historias de usuario o requisitos del proyecto. La pila del producto no es algo invariable, será modificada a medida que avanza el proyecto y se clarifican los requisitos.


• Antes de cada sprint, iteración de aproximadamente 3 o 4 semanas, el equipo y el propietario del producto se reunen para decidir que historias de la pila del producto se van a implementar en él. Estas historias a implementar forman la pila del sprint.


• Durante el sprint, el equipo tendrá una reunión diaria de sprint, en la que se actualiza la evolución del proyecto y se tratan de resolver posibles problemas.


• Al final del sprint, se lleva a cabo la demostración, en la que se exponen las nuevas funcionalidades implementadas durante el sprint.


• Antes de comenzar un nuevo sprint, se lleva a cabo una retrospectiva que permite identificar posibles mejoras en la forma de trabajar.

Referencias:
Aplicando Scrum y XP
Metodologías ágiles
Qué es Scrum

Scrum y XP desde las trincheras

Aunque ya lo he leído hace algún tiempo, ahora mismo siento la necesidad de releer el libro de Henrik Kniberg “Scrum & XP from the trenches” (“Scrum y XP desde las trincheras” en su traducción al español ) en busca de ideas que aplicar para tratar de incorporarlas en las nuevos proyectos que voy a comenzar.

En este libro, disponible para su descarga gratuita, Henrik Kniberg cuenta sus propias experiencias durante la implantación de Scrum en la empresa en la que estaba trabajando. En él expone sus ideas acerca de cómo usar la metodología de desarrollo ágil Scrum.

El libro, con prólogos por parte de Jeff Sutherland y Mike Cohn, consta de los siguientes capítulos:

1. Introducción: Según el propio creador de Scrum, Ken Schwaber, Scrum no es una metodología, sino un marco de trabajo y, por tanto, no dice exactamente qué es lo que hay que hacer. Sin embargo, en este libro, Henrik Kniberg sí que dice qué es exactamente lo que él hace para aplicar Scrum. A pesar de ello, previene de que Scrum es una metodología que debe adaptarse a la situación específica de cada proyecto.


2. Cómo hacemos las pilas de producto: La pila de producto es una lista priorizada de requisitos o “historias” del cliente escritos usando su propia terminología, de forma no técnica.


3. Cómo nos preparamos para la planificación de sprint: El propietario de la pila de producto debe tener ésta ya preparada para cuando se va a planificar un sprint. El propietario debe comprender todas las historias de usuario y asignarlas una importancia.


4. Cómo hacemos la planificación de sprint: La reunión de planificación de sprint es la actividad más crítica de Scrum. La meta de esta reunión es definir un objetivo, la lista de miembros del equipo implicados, la lista de tareas que se desarrollarán, una fecha de demostración y un lugar y hora para la reunión de scrum diaria. En ellas, el propietario de producto y el equipo negocian sobre el alcance de cada sprint en base a las estimaciones y a la importancia de cada una de las historias.


5. Cómo comunicamos los sprints: Es necesario informar a todo el mundo de qué está ocurriendo en cada sprint. Para ello, después de la reunión de planificación del sprint se debe redactar una hoja de información del sprint que recoja los objetivos que se han definido. Esta hoja debe publicarse para todo el mundo.


6. Cómo hacemos las pilas de sprint: Después de la reunío de planificación de sprint y antes de la primera reunión de scrum diaria, el Scrum master debe crear la pila de sprint. La pila de sprint es la lista de tareas que se realizan durante el sprint, con gráficos de avance de estas tareas (burndown). La forma más efectiva de mostrar la pila de sprint es mediante un tablón en la pared.


7. Cómo distribuímos la sala del equipo: Las discusiones más interesantes tienen lugar de forma espontánea delante de una pizarra donse se puedan pintar diagramas o gráficos de diseño. Los miembros del equipo se pueden reunir en frente de esta pizarra y discutir sobre el diseño en cualquier momento. También es importante que los miembros del equipo se sienten junto para fomentar la comunicación entre ellos. El propietario del producto no debe estar sentado con el equipo para que no sienta la tentación de medrar en los detalles, pero debe sí estar accesible para el equipo por si surge alguna duda y hay que preguntarle. El resto de la gente no debe interferir para nada con el equipo.


8. Cómo hacemos los scrums diarios: El mejor sitio para el scrum diario es delante del tablón con la pila de scrum. Durante la reunión, que no debe durar mucho más de 15 minutos, se debe actualizar el tablón con los avances que el equipo ha realizado.


9. Cómo hacemos la demo de sprint: El hecho de tener que hacer demostraciones al final de cada sprint fuerza al equipo a tener algo hecho que mostrar y fomenta lo comunicación sobre lo que se está haciendo dentro del equipo y con otros equipos que asistan a la demostración. Las demostraciones además permiten obtener realimentación sobre el proyecto por parte del cliente.


10. Cómo hacemos las restrospectivas de sprint: La retrospectiva es la segunda tarea más importante, puesto que es la que premite mejorar. La restrospectiva es una reunión que tiene lugar al final de cada sprint donde el equipo expone sus ideas sobre qué cosas se pueden hacer mejor.


11. Descansos entre sprints: Después de cada sprint, que pueden ser muy intensos, es necesario un tiempo de descanso que permita además asimilar nuevas ideas o información.


12. Cómo hacemos la planificación de entregas y los contratos de precio fijo: En algunos casos, normalmente unidos a un contrato de precio fijo, es necesario planificar con antelación las entregas de varios sprints posteriores. Para ello el propietario del producto necesita estimaciones de las tareas incluidas en el contrato, que se deben haber realizado de forma conjunta con el equipo. En función de estas estimaciones y la velocidad del equipo se establece el plan de entregas a lo largo de los siguientes sprints. Este plan puede ser modificado a medida que surgen cambios según el proceso avanza.


13. Cómo combinamos Scrum con XP: Scrum y XP se complementan a la perfección, puesto que Scrm se centra en la gestión y la organización del proyecto y XP se centra en las prácticas de programación. Algunas de las prácticas de XP son también parte inherente de Scrum, como el concepto de equipo, sentarse juntos, las historias de usuario y el juego de la planificación. Además, hay otras prácticas de XP que se complementan con Scrum, como la programación en parejas, el desarrollo guiado por pruebas (TDD), el diseño incremental, la integración continua, la propiedad colectiva del código y su estandarización y el trabajo a un ritmo enérgico pero sostenible.


14. Cómo hacemos pruebas: Esta es la parte más difícil del desarrollo de software y la más variable entre distintas organizaciones. Es necsario realizar algún test de aceptación manual antes de dar un trabajo por realizado. Sin embargo, se puede reducir esta fase de test aumentando la calidad del código entregado y aumentando la eficiencia de las pruebas automáticas realizadas. O, incluso, incluir que algún miembro del equipo realice tareas de tester. El tester será la persona que certifique que una tarea está completamente terminada. Las pruebas de aceptación no encajan bien dentro del ciclo de un sprint, por lo que se definen ciclos de aceptación fuera del sprint.


15. Cómo manejar múltiples equipos Scrum: Los equipos demasiado grandes no se adaptan bien a las prácticas de Scrum porque la comunicación entre todos los miembros es mucho más difícil. Es preferible tener varios equipos pequeños que uno grande, si el proyecto lo permite. El número ideal de personas parece estar entre 5 y 9 personas.


16. Cómo gestionamos equipos distribuidos geográficamente: Aquí se discuten distintas formas de gesrionar equipos distribuídos, que pueden ser bien distintos equipos en localizaciones distintas o un mismo equipo con miembros distribuídos.


17. Lista de comprobación del Scrum Master: Aquí se listan las tareas administrativas del Scrum Master, tareas que debe realizar al comienzo, durante y al final de cada sprint.

Este libro es una introducción estupenda a Scrum y permite comenzar a usar esta metodología siguiendo las ideas que en él se exponen. Luego, a través de la práctica, se pueden ir perfeccionando las prácticas en base a aquello que resulte realmente valioso.

Referencias:
Scrum & XP from the trenches
Scrum y XP desde las trincheras

Patrones de diseño: Adapter

Este patrón convierte la interfaz de una clase en otra distinta que es la que esperan los clientes y permite que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.

Se encarga de proporcionar a una clase cliente el interfaz que necesita para trabajar utilizando en su implementación una clase o clases que no cumplen con dicho interfaz.

La mejor forma de ver este patrón es a través de un ejemplo. Supongamos que tenemos una clase Cliente que realiza cálculos matemáticos complejos cuya realización se delegan en otra clase. Vamos a suponer a modo de ejemplo que estos cálculos complejos pueden ser una suma o una resta. La interfaz requerida por esta clase cliente para sus cálculos se define en la interfaz Calculadora:

package com.roldan.adapter;

public interface Calculadora {
 public int suma(int operador1, int operador2);
 public int resta(int operador1, int operador2);
}

Para la ejecución de estos complejos cálculos se dispone de la clase Procesador que los implementa:

package com.roldan.adapter;

public class Procesador {
 public static final int SUMA = 1;
 public static final int RESTA = 2;
 
 public static int realizarOperacion(
   int operador1,
   int operador2,
   int operacion) {
  int resultado = 0;
  
  switch(operacion) {
   case SUMA:
    resultado = operador1 + operador2;
    break;
   case RESTA:
    resultado = operador1 - operador2;
    break;
  }
  
  return resultado;
 }
}

En este caso, a pesar de que la clase Procesador realiza las operaciones que necesita la clase Cliente, no implementa la interfaz que ésta necesita para poder usarla. Sin embargo, se puede crear una clase Adaptador que adapte la clase Procesador a la interfaz Calculadora:

package com.roldan.adapter;

public class Adaptador implements Calculadora {
 public int suma(
   int operador1,
   int operador2) {
  return Procesador.realizarOperacion(
    operador1,
    operador2,
    Procesador.SUMA);
 }
 
 public int resta(
   int operador1,
   int operador2) {
  return Procesador.realizarOperacion(
    operador1,
    operador2,
    Procesador.RESTA);
 }
}

De esta forma, la clase Cliente puede usar los cálculos realizados en la clse Procesador a través de la clase Adaptador, que la adecúa a la interfaz Calculadora que necesita la clase Cliente.

El siguiente diagrama UML refleja las relaciones entre dichas clases:

Adapter pattern en Wikipedia
Patrón Adaptador en Wikipedia
Design Patterns Uncovered: The Adapter Pattern en DZone
Adapter Pattern en OODesign.com
Otros patrones de diseño

Consideraciones sobre el diseño

Este artículo está basado en el artículo de Martin Fowler “Is Design Dead?” y en su traducción al castellano realizada por Alejandro Sierra.

La verdad es que he descubierto en Martin Fowler una verdadera fuente de inspiración y de ideas sobre la ingeniería del software. En los últimos tiempos, basándome en sus artículos, estoy encontrando respuestas y reflexiones valiosas sobre los problemas que me afectan como desarrollador de software.

En este caso, llevo algún tiempo en conflicto entre la idea de realizar el diseño al principio del proyecto, paralizando todo desarrollo hasta tener una visión clara, o comenzar a desarrollar tan pronto como sea posible para tener algo que ofrecer como propugnan las metodologías ágiles, aunque esto implique rehacer lo ya hecho cuando las ideas se aclaran o varían.

En este artículo, Martin Fowler expone sus ideas sobre el diseño dentro de una metodología ágil como es XP que, aparentemente, no le da importancia.

Hay dos maneras de plantear el diseño, el diseño evolutivo y el diseño planeado:

• Durante el diseño evolutivo el diseño se realiza a medida que el sistema evoluciona, formando parte de la programación. Esta forma de diseño suele acabar en desastre porque termina siendo una agregación de decisiones puntuales que complican el código y deterioran el diseño.
• El diseño planeado se corresponde con la visión del diseño de cualquier ingeniería clásica, en donde se trata de anticipar los problemas de forma abstracta sin entrar en la codificación hasta haber terminado esta fase de diseño. Sin embargo, es difícil anticipar todos los problemas antes de comenzar con la programación, lo que hace aparecer tensiones entre programadores y diseñadores. También se pueden producir cambios en los requisitos que pueden deberse a cambios en el negocio y que, por tanto, son muy difíciles de preveer y de controlar sus efectos.

XP aboga por el diseño evolutivo. Sin embargo, para ello propugna una serie de prácticas que permiten controlar los efectos negativos de este tipo de diseño. Según la curva del cambio del software, el coste del cambio en programación aumenta exponencialmente a medida que avanza un proyecto, dificultando el diseño evolutivo. Pero esta curva se puede aplanar mediante una serie de prácticas que reducen el efecto de los cambios. Estas prácticas son:

• Pruebas: permiten controlar el efecto de los cambios eviatndo la introducción de nuevos errores.
• Integración continua: permite mantener el equipo en sincronía evitando que los cambios afecten a más gente.
• Refactorización: permite limpiar el código y hacerlo más mantenible y fácil de modificar.

En el diseño evolutivo XP dice que “hay que hacer la cosa más simple que pueda funcionar” y que no lleve a cabo todo aquello que no sea necesario (principio YAGNI – “You Ain’t Gonna Need It”). Se trata de mantener el diseño lo más simple posible haciendo sólo aquello estructamente necesario. Para ello existen dos razones:

• Si se hace algo que no es necesario ahora mismo se está comprometiendo el esfuerzo para quello que sí lo es. Además, se puede estar haciendo de forma incorrecta por falta de información, es mejor posponer su implementación hasta que se conozca con más detalle.
• Un diseño complicado es más difícil de comprender e implementar que uno sencillo. Haciendo lo estrictamente necasio se tiene un diseño más sencillo y fácil de implementar.

Sin embargo, esta forma de mantener el diseño simple añadiendo posteriormente lo que se vaya convirtiendo en necesario sólo es factible si se están usando las prácticas anteriormente descritas para reducir el costo del cambio.

Como pautas de le lo que es un diseño simple, Kent Beck expone los siguientes cuatro criterios:

• Correr todas la pruebas.
• Revelar toda la intención del código haciendo que sea fácil de leer.
• Evitar duplicación.
• El menor número de clases y métodos.

No es necesario perder demasiado tiempo buscando el diseño más simple. La refactorización permite irlo simplificando a medida que se va entendiendo. Tampoco es bueno usar patrones de diseño sin ton ni son, es mejor dejar que el diseño evolutivo te guíe hacia el uso de un patrón que introducirlo prematuramente.

Respecto al uso de diagramas y UML XP dice que se usen si son útiles, pero no es partidario de su uso. Los diagramas pueden ser útiles para la comunicación siempre y cuando se reduzcan a la mayor sencillez posible. Sin embargo, el uso de diagramas se complica cuando se producen cambios durante la evolución del proyecto, porque es difícil mantenerlos en sincronía con el código.

Algo importante en el diseño es evitar la irreversibilidad de las decisiones. De esta manera la toma de decisiones no es dramática porque las malas decisiones pueden ser deshechas. En este sentido es importante contar con sistemas de control del código que permitan garantizar la reversibilidad.

Es importante contar con gente involucrada en el diseño. Alguien debe ejecercer control sobre el proyecto vigilando el diseño del código y responsabilizándose de él. Estas personas deben actuar cuando se detecta que el diseño puede verse comprometido o hay alguna dificultad técnica durante el proyecto. Esta rol es el del líder técnico. No tiene sentido el rol de arquitecto, puesto que no puede existir el diseño por parte de alguien que luego se desentienda de la construcción del software.

El diseño de un proyecto se puede medir en función de la calidad del código base. Si la calidad del código base de un proyecto se deteriora y se vuelve más difícl trabajar, entonces el diseño es insuficiente. Éste es un criterio subjetivo, pero es la gente técnica la que primero sufre la dificultad de hacer cambios y a quienes se debe escuchar.

Según Martin Fowler, la naturaleza del sideño ha cambiado. Ahora se buscan las siguientes habilidades:

• Mantener el código tan claro y simple como sea posible.
• Ser capaz de refactorizar, haciendo mejoras en el diseño cuando sea necesario.
• Conocer y reconocer patrones y cuándo evolucinar hacia ellos.
• Saber comunicar el diseño mediante diagramas, código y comunicación directa con las demás personas.

Como resumen, Martin Fowler aboga por un diseño evolutivo que permita comenzar con el desarrollo de forma temprana. Pero esto no se puede hacer de cualquier manera, es necesario introducir prácticas que faciliten el cambio durante el desarrollo de forma que el diseño pueda mejorar y adaptarse a las nuevas necesidades que vayan apareciendo.

Esto va en contra de un diseño planeado que deja todo por sentado en un larga fase inicial y que es seguido por una fase de implemantación en que los cambios no se contemplan y que, cuando se incorporan porque terminan siendo absolutamente inevitables, son difíciles de incorporar, rompiendo el diseño previamente establecido e introduciendo una gran propensión a errores.

El diseño evolutivo delega gran cantidad de trabajo de diseño en los desarrolladores. No existe la figura de arquitecto como persona que realiza todo el trabajo de diseño, sino como alguien que supervisa el trabajo de estos. Se debe contar con un equipo capaz y comprometido para poder seguir esta forma de trabajo, de lo contrario, se hace inviable.

Referencias:
Is Desing Dead? - Por Martin Fowler
¿Ha muerto el diseño? - Traducción de Alejandro Sierra
Examining the Agile Cost of Change Curve