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.

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

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?

Nos gusta programar pero no documentar

La documentación debe estar al servicio del proyecto y no al revés

Efectivamente, no nos gusta documentar. Esta afirmación llevo muchos años oyéndola, diciéndola y sufriéndola.

¿Porqué no nos gusta documentar?
Pues porque no nos proporciona ningún beneficio aparente. ¿Me cambia en algo la vida si documento 1, 2 o 700 páginas? Probablemente no.
Pero claro, esto es porque lo afirmamos mientras documentamos. Documentar no da el mismo tipo de satisfacción a los programadores que tirar líneas de código. ¿Qué pasa si dejamos pasar los años y tratamos de mantener un sistema sin documentación? Pueden pasar dos cosas:

  • Yo mismo soy el autor del código, y dependeré de mi memoria. Esto apenas me ha pasado el 10% de las veces (el mantener mi propio código pasado mucho tiempo). Y mi memoria, sobre lo cual me considero una persona normalita, no es capaz de retener todas las decisiones funcionales y técnicas que dan lugar a cientos, miles de líneas de código en cada proyecto.
  • El autor del código no está. Bajo mi experiencia, esto me ha pasado alrededor del 90% de las veces. Bien porque he cambiado de empresa y tengo que lidiar con las perlas de otros, o bien porque la persona que lo hizo o empezó ya no está, y ahora yo tengo que mantener lo suyo. En este caso, dependeré de lo bien que el autor o autores lo hayan comentado. Pero como veremos a continuación, tampoco será de utilidad.

Documentar el propio código, no me resolverá nada. Con suficiente tiempo, es posible deducir lo que hace el código. Eso es como decir que si tuviéramos el código de Windows, nos arreglaríamos los problemas que encontrásemos (no tengo otra cosa que hacer si tengo un error, que ponerme a mirar millones y millones de instrucciones, probando a ver qué pasó y cómo arreglarlo). Pero es que estamos dando por sentado que solo tocamos código para corregir cosas, que en nada afectan al resto del código.

Ahí está la clave: no se comenta el código para tener documentación, sino para acelerar los cambios en el código siempre que el objetivo del mismo ni sus circunstancias cambien. Si las circunstancias, la interrelación entre componentes, los requisitos, etc cambian…de poco me sirve el código ni sus comentarios.

Me hace mucha gracia quien afirma que la mejor documentación es el código. Me preocupa y me hace dudar de si esa persona ha mantenido proyectos grandes y antiguos. Las realidades de la empresa cambian, los programas y módulos con los que interactuamos cambian…los sistemas físicos en la empresa cambian. Tener que tirar del hilo del código y sus comentarios para tratar de deducir decisiones antiguas es agotador…e inútil. Porque es el pasado.

Hay quien afirma y afirmará que el código documentado lo es todo gracias a las habituales “balas de plata”: patrones de diseño y arquitectura, buenas prácticas, estándares de desarrollo…Eso está muy bien para pequeños cambios y proyectos no muy antiguos. Pero la realidad es que todo eso ha cambiado en el tiempo. Lo que hoy nos parece la piedra filosofal, mañana estará obsoleto y habrá otros patrones, estándares, etc. Mantener código antiguo nos suele llevar a criticar a su autor, simplemente porque no entendemos las “balas de plata” de aquel momento (bueno, de acuerdo, a veces también hay código antiguo realmente horrendo).

Otro problema está en la dispersión y el tamaño. Está muy bien mantener código con comentarios de módulos pequeños, o sistemas concentrados. ¿Qué ocurre si mi código tiene millones de líneas de código, miles de módulos distribuidos en docenas de aplicaciones? ¿Qué ocurre si no tengo siquiera visibilidad de parte del código o de las aplicaciones porque son de otras empresas?

Aquí de nuevo entran en juego la documentación y los estándares. El primer punto a documentar es siempre las APIs o interfaces. Tanto si son nuestras como si no. Un fallo en el código no sabremos si es porque está mal implantada una API, si está con una versión obsoleta…a no ser que tengamos la documentación actualizada de esa API o interfaz. Los comentarios y la documentación, han de satisfacer objetivos diferentes.

Otra razón ineludible de documentar es la esencia misma de la orientación a objetos: abstracción, encapsulación, etc. Una capa de la arquitectura no puede saber de otra. Lo mismo las funciones o módulos. ¿Entonces cómo rastreo las decisiones que abarcan varios elementos si están dispersos y no saben unos de otros? ¿O es que tengo que hacer un “meta-comentario” (comentario de comentarios)? En realidad, esto que acabo de decir, no es ni más ni menos que la documentación que queremos evitar.

La mejor documentación, es la que está orientada a complementar al código y sus comentarios. Habitualmente, se hace a través de los entregables típicos:

  • Requisitos. Recogen a alto nivel las necesidades del sistema desde el punto de vista de cliente/usuario. Son las necesidades básicas. Podemos de alguna forma asimilarlas a las historias de usuario a muy alto nivel. Deben aclarar el qué se espera.
  • Análisis funcional: Contienen el qué debe hacerse para lograr lo que espera el cliente. Es suficiente con definir lo que la parte de la documentación de diseño técnico ha de desarrollar.
  • Diseño técnico: Si se da trabajo a un programador, un diseño técnico puede contener la resolución a problemas técnicos que se han previsto (los comentarios en el código ya comentan los problemas imprevistos).

¿Estoy diciendo que estos entregables deben hacerse? No, para nada.
¿Tienen que ser 3? Pues tampoco. El hacer 1, 2 o 3 documentos dependerá del contexto. Incluso  un breve correo puede ser un análisis funcional de un pequeño cambio. Y no necesitas más. Dependerá de la metodología que se haya definido para el proyecto, el tamaño del mismo, la experiencia…

Lo que digo es que los anteriores son entregables típicos y satisfacen una necesidad. Pero una metodología que obliga de forma rígida (las que por desgracia se implantan en muchísimas empresas), son la causa de las críticas que hay hacia la documentación y hacia las propias metodologías. Si la metodología no se adapta a la realidad del proyecto, será un obstáculo, no un acelerador del trabajo.

¿Cuál es el límite? ¿Hasta dónde documentar? Eso, por desgracia, lo da la experiencia. Yo suelo dar en mis formaciones una máxima: si el analista técnico tiene dudas, es que el funcional necesita más. Si el programador no sabe qué hacer, seguramente el diseño técnico cojea.

Ojo: tampoco quiero decir que no contestemos a la persona que ha de continuar el trabajo. Yo por ejemplo, en un cliente, revisaba la documentación técnica con los programadores, y o bien modificaba el diseño técnico sobre la marcha, o directamente les indicaba cómo quería realizar las cosas, y ellos por un lado, y yo por el otro, seguíamos cada uno haciendo código/documentos. De hecho, algunos programadores terminaban llevando a cabo una solución ligeramente distinta: ellos después me explicaban el motivo, y yo adaptaba el documento a su realidad. Cuesta tiempo llegar a este nivel de colaboración, pero es un placer trabajar así. Das libertad a quien está a pie de teclado soltando código, y al final, lo importante, es que la documentación y el código no se descuadren, y que el equipo sienta que hay cierta libertad de hacer las cosas.

Y un apunte final: todo lo dicho aquí, sirve para cualquier ciclo de vida: cascada, iterativo, RUP, scrum, etc, etc. Siempre alguien tendrá que empezar a trabajar partiendo de algo que le habrán dado: un documento, una servilleta, un post-it en una pizarra…

Comando Scrum

Me ha gustado. Un compañero me ha facilitado el link que voy a comentar, y donde vais a poder disfrutar con todo detalle del contenido, que me parece brillante. Aquí va un resumen:

El sargento

Esta figura la podemos asimilar al Scrum Manager, el responsable de mantener al equipo enfocado y motivado, de forma que los grupos de desarrollo actúen como unidades eficientes. Luchará encarnizadamente por eliminar cualquier impedimento u obstáculo a este fin.

Comunicaciones

El product owner, realiza esta función de mantener al equipo bien informado de los requisitos del producto, y asegura que la información fluya bidireccionalmente.

Infantería

En Scrum representado por el equipo de desarrollo. Sin estos tíos, no existiría el ejército, ni sería posible ninguna batalla. Representan la fuerza necesaria, que hay que cuidar y mantener, entrenar y no agotar nunca.

Médicos

Los especialistas en aseguramiento de calidad (QA), son responsables de saltar las alarmas cuando la salud del proyecto no es la adecuada. Verifican el cumplimiento de estándares, y dan soporte en su consecución.

Reconocimiento

En todo proyecto suele haber una parte del equipo que realiza un prototipo, o que investiga una tecnología para identificar si es plausible o no implantarla en el proyecto. Estos investigadores (equipo de reconocimiento), hacen las labores de preparar el camino al resto, y de identificar problemas. En todo proyecto hay “zonas minadas” que hay que evitar, y que esta avanzadilla de héroes nos ayuda a anticipar.

¡ El día de la victoria!

Este día, es el día del despliegue. El pase a producción habrá sido más o menos complicado, pero con las dosis adecuadas de esfuerzo, planificación, gestión y suerte, la victoria habrá llegado. Es el momento de celebración, liberar a los rehenes, y pasar a la reconstrucción del país…quiero decir…al mantenimiento del producto.

¿Han muerto las metodologías ágiles?

Me siento culpable. Y me siento culpable porque soy de los que no les gusta aceptar las cosas porque sí. Necesito verificar criterios, y confirmar que realmente, las indicaciones recibidas y los objetivos, son coherentes.

Y no, no me acabo de levantar con resaca tras una noche de alcohol y desenfreno. Estoy hablando de la muerte de las metodologías ágiles. Y me siento culpable, porque soy muy crítico con posturas tipo “si es ágil es bueno” o también “con SCRUM siempre es mejor”.

Yo veo las metodologías ágiles, SCRUM y XP entre ellas, como los representantes de una gran promesa, un mito casi religioso que ha alcanzado su paroxismo en un cierto momento, y se ha creado una burbuja insostenible. Y la desgracia, será que cuando fallen los proyectos, la culpa se la van a llevar los de siempre: los programadores. Precisamente las metodologías que ponen por encima a las personas, van a ser las que usen a dichas personas como chivos expiatorios, tratando de justificar sus fallos. Y es que tienen fallos (son “humanas”), como me esfuerzo en demostrar con éste y otros mitos.

Y me siento culpable, porque me gustaría ver muchos más proyectos usando Scrum, XP, Lean, etc. Pero no a cualquier precio. No a costa de terminar sufriendo los mismos fallos que las metodologías pesadas y tradicionales nos han traído:
–       Retrasos en las entregas.
–       Spaguetti Code.
–       Deuda técnica.
–       Etc..
Echo la vista atrás y veo que ya hace unos cuantos años que muchísima gente se hace las mismas preguntas que yo:
http://www.infoq.com/news/2008/11/decline-of-agile
http://stackoverflow.com/questions/301993/is-agile-development-dead
http://practicalagility.blogspot.com.es/2008/11/agile-circling-drain.html
http://www.boost.co.nz/blog/agile/rules-of-improv-applied-to-scrum/
http://craignicol.wordpress.com/2011/05/16/agile-is-dead/
http://agilesoftwaredevelopment.com/blog/janusz-gorycki/agile-dead
http://myagileeducation.com/2011/long-live-agile-is-agile-dead/
http://blog.recursivity.com/post/934000041/why-agile-is-dead

Y son sólo unos pocos ejemplos.

Viendo los comentarios que la gente escribe en esos blogs, al final es lo de siempre. Es un flujo que se está cumpliendo con exactitud:

  1. Grandes promesas. En este caso, surge el manuscrito ágil.
  2. No hay pruebas de lo contrario, de que las metodologías no sean el nuevo “resuelve-todo”, por lo pero se genera gran expectativa esperando éxito en los proyectos. Curiosamente, con un esfuerzo mínimo. Y además, contentando al colectivo al que se dirige la promesa: por fin los programadores encuentran una metodología que promueve sus aspiraciones y les da el control. ¿Porqué me suena esto extrañamente a la pastilla que todos los años aparece de forma milagrosa y que permite adelgazar sin esfuerzo?
  3. Conforme se añade gente, y un colectivo importante pasa a vivir de la formación, consultoría y porqué no decirlo: de apuntarse al carro y vivir del cuento y de la fama que se consigue con las metodologías ágiles, la burbuja se hace imparable.
  4. ¿Y ahora qué? Pues decepción, sensación de tiempo perdido, proyectos con problemas (los ya comentados retrasos, código spaguetti,…).
  5. ¿Y después? ¿Qué nos depara el futuro? Pues como siempre, adoptaremos las nuevas ideas, aunque esta vez sin verlas como una varita mágica, sino como lo que son: herramientas tan útiles como su adecuación al proyecto en curso, nuestra situación particular, etc…

No hay bola de cristal que nos solucione el punto 5. Ni siquiera tengo claro el que haya explotado aún la burbuja de las metodologías ágiles, a pesar de que muchos autores en la red así lo afirman. De momento, las metodologías “tradicionales” y “pesadas”, no han muerto tampoco. Siguen teniendo sus problemas, pero siempre encuentran un tipo de empresas o proyectos en los que ser de utilidad. En todo caso, evolucionan. Como espero que también evolucionen las metodologías ágiles, evitando convertirse en un elemento más de la cadena de palabras de moda:

·         2nd generation languages
·         3rd generation languages
·         CASE tools
·         UML
·         OOP
·         Java
·         CMM (and CMMI)
·         XML
·         Generics
·         Design patterns
·         .NET
·         Outsourcing/offshoring
·         Agile/Scrum
·         LINQ
·         TDD
·         Etc.

Todos ellos han sido útiles. Muchos de ellos se siguen usando. Pero han tenido su momento burbuja. La clave está en ser lo suficientemente inteligente en mirar atrás y darse cuenta de que al final, no son más que herramientas en nuestra mochila, y no constituye ninguna por sí misma una solución que elimine a las demás de un plumazo.

De todas formas, yo os recomiendo mirar con desconfianza cada vez que un supuesto gurú nos venda la nueva “pastilla milagrosa” en forma de metodología o herramienta.

Además, el uso de SCRUM y otras metodologías ágiles me recuerda a la teoría del caballo muerto que ya comenté en otro post. Se ha tratado de exprimir tanto y tanto a estas metodologías, llegando hasta sinsentidos, que en los casos en que realmente pueden ser útiles (que no son pocos), se genera desconfianza. Curiosamente, es lo mismo que ha pasado ya hace años con las metodologías tradicionales, el desarrollo en cascada, etc.

Defectos de Scrum (II)

En un reciente post hablaba de defectos de Scrum. Con este título, yo pretendía destacar los riesgos habituales en proyectos que por el motivo que sean, no encajan con las premisas de estas metodologías.

Vamos a ver a continuación una segunda parte con nuevos supuestos o problemas que presenta la implantación de una metodología como SCRUM, y que tendremos que considerar a la hora de implantarla.

  1. En estas metodologías hay entregas frecuentes y estables, lo que supone probar y estabilizar un producto con un número mínimo de funcionalidades. Por desgracia, a pesar de que las metodologías ágiles se presentan como preparadas para el cambio, tienen el mismo problema que las metodologías tradicionales: las funcionalidades de una iteración pueden cambiar en la siguiente. Al final, una iteración es como un mini proyecto: tiene desarrollo, pruebas, un esfuerzo de integración con la funcionalidad existente, y despliegue. Por mucha involucración que queramos tener del usuario, nada impide que las funcionalidades cambien. Si pensáramos eso, entonces ¿porqué cambian en las metodologías tradicionales? ¿Es que allí el usuario nos ignora, no se involucra, va en contra de sí mismo? ¿Es que los analistas de las metodologías tradicionales son unos inútiles, y los de las ágiles unos hachas?
  2. Presupone que no es necesaria la férrea gestión de recursos de otras metodologías “clásicas”. El problema está en cómo coordinar pues los desarrollos con la presencia de personal de sistemas, DBA’s, disponibilidad de recursos hardware, etc… El problema es que estas metodologías ágiles se venden desde el punto de vista del programador. Es el cliente el que debe sopesar si necesita o no un manual, una documentación exhaustiva, un seguimiento del proyecto, un control de costes y gastos…no el equipo.
  3. Esta metodología no parece estar pensada para equipos de desarrollo dispersos en el espacio o en el tiempo. SCRUM presupone reuniones diarias cortas y presenciales. Presupone una colaboración de los equipos muy integrada. Eso no quiere decir que no se pueda trabajar en remoto. Simplemente, que en el segundo caso, puede haber dificultades adicionales que en pequeños equipos cercanos, no existen.
  4. Se habla de que existe incompatibilidad o contradicción entre el uso de metodologías ágiles y que la empresa esté certificada CMMi. (Actualmente, con CMMi en su versión 1.3, esto ya no es cierto). Por desgracia, existen muchas administraciones públicas nacionales e internacionales que exigen a sus proveedores la certificación CMMi (entre otras). El Manifiesto Ágil en que se basan estas metodologías ágiles, habla de valorar más el individuo y el código frente a documentación (por ejemplo). Pero esto no quiere decir, que haya que hacerse lo que quiera el equipo, sino que ante la falta de otras directrices (es decir, si nadie pide documentación), se de mas importancia al código.
  5. Los concursos públicos y muchos clientes privados exigen la certificación CMMi de la empresa, pero es raro que un cliente exija una certificación en metodologías ágiles (que por otro lado no existe tal, sino que es la persona quien se certifica ScrumMaster o equivalente). Esto es un problema para las metodologías ágiles, que chocan ante la falta de un auténtico certificado de empresa. La gente va y viene, pero es la empresa la que necesita ganar proyectos.
  6. La falta de documentación detallada es un grave problemas en clientes de sectores legal, financiero, público,… y en general en proyectos grandes que requieran posterior mantenimiento, o en los que simplemente el cliente exige la documentación como parte del contrato.
  7. En general, los métodos ágiles promueven la iniciativa e independencia del desarrollador (propietario del bloque funcional que está desarrollando), lo que puede derivar en que se implementen funcionalidades asociadas o paralelas NO SOLICITADAS, que terminen retrasando y complicando el desarrollo.
  8. También existen problemas en la implantación de grandes clientes en los que varios proveedores interactúen. En estos casos, es muy importante definir documentación que permita la integración entre proveedores, tema que las metodologías ágiles (puras) suelen dificultar.
Con las que ya había en el anterior post, parece que hay muchas, y así es. ¿Estoy queriendo decir que SCRUM y en general las metodologías ágiles son problemáticas o difíciles de implantar? ¿O ineficaces? Pues no. Problemas hay en todas partes. Lo que no puede ser es que como veo constantemente en la red, vanagloriemos a las metodologías ágiles como el mantra que nos va a salvar del desastre en que nos han dejado las metodologías tradicionales. Hay que tener en cuenta las limitaciones de dichas metodologías, y saber adaptarlas a los proyectos. Si caemos en el purismo  y tratamos de implantar las metodologías por ellas mismas, estaremos perdiendo de vista los objetivos de los proyectos.

Este post no deja de ser una visión general de riesgos como en cualquier otro proyecto, pero esta vez desde el punto de vista de la metodología.