7 Fallos habituales en una sprint review

Una sprint review parece sencilla. Pero como siempre, podemos caer en la dejadez, dejar de trabajar con rigor, cayendo en una serie de fallos habituales que os comento. Al final del post os dejo un vídeo que satiriza una sprint review. Pero empecemos con los 7 fallos habituales en una sprint review:

1.Expectativas de trabajo completado fuera del plan original.

Es muy típico esperar que se lleven a cabo tareas “extra”. Después de todo ¿no es eso ser ágil? Entonces, ¿porqué no incluir pequeños cambios o tareas adicionales, durante el sprint? Creo que todos ya sabemos que un sprint precisamente está pensado para acometer de la mejor manera posible, las historias de usuario planificadas. Nada menos, pero tampoco nada más.

2.Confundir estimaciones con compromisos.

Esto es también muy habitual. Una estimación no es más que eso. A veces las estimaciones son erróneas, y un sprint trata de acometer todo el trabajo planificado, pero a veces simplemente no es posible. Deja la historia de usuario sin completar para el próximo sprint, no sin antes asegurarte de ver porqué te equivocaste al estimar, no sea que en realidad haya más trabajo oculto del que creías.

3.Expectativas no realistas

Podemos tener expectativas no realistas de ausencia de errores, corrección de errores existentes, funcionalidades pretenciosas, hitos inalcanzables, etc.

4.El product owner que no actúa como tal.

El product owner puede que vea la funcionalidad por primera vez en la propia sprint review. Eso significa que no ha dado feedback durante su desarrollo, y que su labor de product owner no ha sido tal.

5.No mantener informado al equipo.

La comunicación y la información son claves. El equipo debe estar puntualmente informado de todo, pero especialmente de revisiones hechas sobre los objetivos del sprint.

6.Ver la review como una oportunidad para buscar culpables, en lugar de aprender y educar.

Esto es también muy típico en proyectos que se inician por primera vez en SCRUM u otras metodologías ágiles. Cuando algo falla, debemos investigar los motivos y buscar soluciones…no culpables.

7.Confundirlo con una retrospectiva.

Efectivamente, los conceptos de sprint review y sprint retrospective son bastante diferentes. Mejor dejaremos el detalle de su comparativa en un post dedicado a ellos y a sus diferencias.

Anuncios

Metodología XP – Introducción

extreme programmingHoy me apetece hablar de la metodología XP (eXtreme Programming). Personalmente, me gusta porque es de las primeras metodologías ágiles con la que tuve contacto, allá por el año 1999. Al igual que en otras metodologías ágiles, es una metodología adaptativa y centrada en las personas. XP agrega buenas prácticas que abarcan más allá de la gestión de proyectos definiendo aspectos más técnicos y cercanos al desarrollo software. El autor o precursor de esta metodología fue Kent Beck, y está basada en 5 valores fundamentales:

  • Respeto: todos los miembros del equipo muestran respeto por el trabajo de cada uno de los demás.
  • Simplicidad: la he puesto en segundo lugar, porque aunque en teoría leeréis que lo simple y la búsqueda de lo simple es la base de XP, me niego a verlo por detrás del respeto.
  • Comunicación: cada una de las tareas del equipo se consideran una forma de comunicación, desde el código, pruebas unitarias, etc.
  • Feedback: XP fue una de las primeras metodologías en incorporar el feedback del cliente. De hecho, el cliente se considera parte del equipo de trabajo.
  • Valor: se refiere principalmente al valor o valentía necesarios para realizar algunas de las prácticas ágiles que XP incorpora. Como el comenzar a programar lo antes posible, o valentía para que el código sea refactorizado y no haya deuda técnica desde el principio, etc.

Como metodología, XP es muy ligera, o más bien podríamos decir, poco estructurada (“ligera” podría considerarse como un término despectivo en el mundo del desarrollo del software). Lo que sí hace XP es incorporar una serie de técnicas o buenas prácticas. Algunas prácticas fundamentales de XP:

  • Programación por parejas: es el punto más controvertido, ya que propone que sean dos personas las que se dediquen a programar. Una persona escribiendo y otra revisando (se pueden alternar). De todas formas, el código se discute antes y durante la escritura. Aquí se practica el famoso “cuatro ojos ven mejor que dos”.
  • Desarrollo por iteraciones: el código se construye mediante iteraciones que van sumando valor o funcionalidad al resultado final.
  • Simplicidad: el axioma “KISS” (Keep It Simple, Stupid), se aplica con regularidad.
  • Refactorización: el código se refactoriza regularmente para que la calidad de código sea notoria, y se evite la deuda técnica. Recordemos que refactorizar, tal y como hemos indicado ya en este blog, nos puede llevar a la refactoritis, una enfermedad de la que ya hemos hablado anteriormente en este mismo blog.

Metodología XP – Los 15 principios

Hace tiempo que quería escribir algo sobre XP (eXtreme Programming). Y es que todo el mundo está emocionado con las metodologías ágiles, principalmente Scrum. Pero para entender los problemas de Scrum y sus ventajas en función del tipo de proyecto (ya he comentado esto otras veces), hay que entender la historia de las metodologías ágiles.

Y qué mejor forma de empezar, que recordando los principios básicos de XP (hablo de eXtreme Programming, la metodología ágil antecesora de las actuales).

La metodología XP comenzó oficialmente con el libro de Kent Beck de 1999, aunque ya llevaba al menos uno o dos años oyéndose por la red. Ya existía un brote ágil que terminaría de catalizar a partir del año 2000.

El propio Martin Fowler, en su blog nos habla en un artículo de los 15 principios de XP. Vamos a revisarlos.

Tenemos los 5 principios fundamentales:

  • Rapid Feedback
  • Assume Simplicity
  • Incremental Change
  • Embracing Change
  • Quality Work

Aunque existen otros 10 principios adicionales, hasta conformar los 15 principios ágiles:

  • Teach Learning
  • Small Initial Investment
  • Play to Win
  • Concrete Experiments
  • Open, honest Communication
  • Work with people’s instincts – not against them
  • Accepted Responsibility
  • Local Adaptation
  • Travel Light
  • Honest Measurement

Si os fijáis, estos principios serían anteriores incluso al manifiesto ágil, surgido a raíz de la reunión que convocó Kent Beck y que dio origen a dicho manifiesto. Kent Beck fue el autor, 2 años antes del manifiesto ágil del libro “Extreme Programming Explained”.

El resto, como se suele decir, es historia.

Estimación basada en tallas de ropa

Hoy voy a hablar de una forma de estimar el tamaño del software, que en realidad no es más que una variante de un viejo conocido: el uso de las cartas en el planning poker. Estas cartas, suelen estar numeradas utilizando la conocida serie de Fibonacci:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100…

Sin embargo, hay más. Y aunque quizás no se usen tanto, la estimación basada en tallas de ropa (o “t-shirt estimation”), también existe. En concreto, es popular por ejemplo entre grupos de trabajo de Microsoft, entre otros.

Ventajas

Por supuesto, esta forma de estimación presenta varias ventajas:

  • Más fácil de imaginar incrementos de forma cualitativa.
  • Más fácil de comunicar las estimaciones al product owner. Los usuarios finales pueden más fácilmente asimilar que las estimaciones y por tanto los desarrollos, son de magnitud diferente.
  • Facilita la estimación ágil en grupos menos experimentados.

Inconvenientes

Y ahora, pasemos a ver los inconvenientes:

  • Más difícil de mapear los incrementos de forma cuantitativa. El paso entre tallas pequeñas parece ser similar al paso entre tallas grandes. Sin embargo, la estimación ágil basada en la serie de Fibonacci se parece más a la realidad, ya que las diferencias entre estimaciones pequeñas son mucho menores que el salto entre las estimaciones más grandes. Es decir, la estimación en tallas de ropa sugiere erróneamente que los escalones son iguales, cuando no es así.
  • Conforme los grupos de trabajo son más experimentados, es mejor pasar a otros tipos de estimación ágil.
  • Es complejo intercambiar estimaciones con otros grupos ágiles, ya que su uso no está tan extendido.

Mi consejo es usar las tallas de ropa como una referencia de trabajo, y mapear, como indican varios autores, cada talla con un número de la tradicional serie de cartas de póker (o Fibonacci). De esta forma, se pueden aprovechar las ventajas y evitar los inconvenientes antes mencionados. Con el tiempo, de todas formas, lo ideal es que los equipos de trabajo acaben estimando directamente con los números y acaben abandonando las tallas de ropa.

Fuentes:
http://qeworks.com/t-shirt-estimation-in-agile/
http://tech.mindcandy.com/2011/06/t-shirt-sizes-in-story-estimation/
http://www.mountaingoatsoftware.com/blog/estimating-with-tee-shirt-sizes

Cuidado con las estimaciones ágiles

Hoy os voy a traer un caso real. En estos tiempos en las que las metodologías ágiles están en todas partes, es el momento de reflexionar el qué queremos, pero sobre todo, qué necesitan nuestros clientes.

En concreto, mucho cuidado con las estimaciones ágiles porque los clientes siguen necesitando saber en muchas ocasiones cuándo van a estar disponibles sus aplicaciones, y a qué precio. Os adjunto una conversación que podría ocurrir a pocos metros de donde estáis:

– [Cliente] ¿Cuánto va a costar esto? ¿Y cuánto tiempo tardaremos en tenerlo? La verdad es que tenemos unas fechas límite muy definidas, y el presupuesto no nos da para muchos cohetes.
– [Vendedor/Técnico ágil] Pues es que nosotros no estimamos en horas, sino en StoryPoints. Pero no se preocupe, porque esto es un marco de trabajo Scrum altamente reconocido.
– [Cliente] ¿Ah, sí? Pues que sepas que mientras tanto, te pagaré en BarPoints (tickets del bar). Pero no te preocupes, porque esto en nuestra cafetería de empresa es una forma de pago altamente reconocida.

En fin. Creo que ha quedado claro. Mucho cuidado con las obsesiones y sobre todo actitudes talibanes respecto al agilismo. De nuevo tenemos las balas de plata de nuestra generación. Y de nuevo, hemos de usarlas como lo que son: tan sólo una herramienta más, que hemos de adaptar a cada situación y necesidad.

¿Y tú …qué les das a tus clientes? ¿Lo que ellos necesitan, o lo que tú les quieres dar?

Programación eXtrema (XP)

EXtreme Programming (en adelante, XP), al igual que en otras metodologías ágiles, es una metodología adaptativa y centrada en las personas. XP agrega buenas prácticas que abarcan más allá de la gestión de proyectos definiendo aspectos más técnicos y cercanos al desarrollo software.

Las buenas prácticas de XP

XP establece unas serie de buenas prácticas entre las que encontraremos:

  • Planning Game: Este método de estimación de la siguiente iteración.
  • Entregas pequeñas: pequeñas e iterativas, las entregas en XP permiten la construcción y despliegue de forma rápida.
  • Metáfora: produce una descripción simple y entendida por todos de lo que hay que construir. De esta forma, se guía a los desarrolladores sin entrar en complejos documentos funcionales. La metáfora es fácil de comprender por el cliente y el equipo, y proporciona suficiente información para guiar la arquitectura del proyecto.
  • Programación estándar: Los programadores escribirán el código fuente de acuerdo con estándares de programación y buenas prácticas que favorezcan la comunicación. En este sentido, la buena práctica no tiene que malinterpretarse y generar una gran cantidad de documentación sobre cómo escribir código fuente.

La metáfora: ventajas

  • La metáfora ayuda a entender los elementos básicos y sus relaciones
  • Mediante ejemplos, es posible completar la definición funcional sin entrar en compleja documentación.
  • Proporciona una visión de la arquitectura, sin entrar en el detalle.
  • Establece un mecanismo sencillo de elaborar el producto y comunicar los objetivos.

La metáfora: inconvenientes

  • Por desgracia, una metáfora no da detalles y profundidad a la explicación de lo que hay que construir.
  • Los ejemplos asociados a la metáfora, pueden ser confusos, y no deben ser tomados de forma literal.
  • La metáfora, no es realmente una arquitectura.
  • La metáfora, no es sólo para los programadores, clientes o jefes de proyecto.

SEPG North America 2013

Hoy he recibido un correo de notificación del CMMI Institute, recordando la celebración de un interesante evento que tendrá lugar en Pittsburg el próximo 1 y 2 de Octubre de 2013. Nada menos que el SEPG North America 2013, un evento anual (bueno, vale, hay otros similares en Europa y Asia, también anuales), donde se tratarán temas candentes y de actualidad como por ejemplo:
– Kanban y CMMi
– Flexibilidad Agile: cómo CMMi hará que Agile sobreviva y se fortalezca.
– Implementación ágil de CMMi
– Métricas.
– Desarrollo de Software seguro con Secure by Design for CMMI-DEV
– Microsoft IT Data Management Maturity
…y más.

Me parece muy interesante el esfuerzo por simplificar y acercar CMMI al movimiento ágil, y en general, al resto de iniciativas y tendencias actuales en el desarrollo de software. Espero que sean muy interesantes, y aunque no creo que esté presente, espero poder acceder al material de los eventos y poder estudiarlos. Algunas de las conferencias prometen bastante.

Aunque ya os he puesto más arriba el enlace principal al evento, os adjunto otro par de enlaces directos a:
– Agenda: Conferencias y ponentes.
– Acerca de: ¿Qué son las conferencias SEPG?