Pesadilla en la oficina

Ahora que tenía este post pensado, me comentan que ya existe una entrada en youtube que parodia la serie “Pesadilla en la cocina”, pero en el mundo del software, es decir: “pesadilla en la oficina”. Pues ale, os adjunto el enlace para que disfrutéis del vídeo:


¿Os imagináis algo así en vuestras empresas? ¿Aguantaríais que alguien criticara tan duramente vuestro trabajo? Y ojo, no me vale la típica respuesta de listillo en plan “sólo si sabe mucho más que yo”. Las cosas son como son, nos la diga Chicote, el tal Alvarote del vídeo, o Rita la Cantaora.

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.

La línea de Base y los cambios en producción

branch-per-taskMuchos me diréis que a qué viene esto ahora a cuento. Pues me sigo encontrando muchos casos en los que hay programadores que no terminan de entender el concepto de línea base. Además, este concepto es fundamental para entender los cambios en el ciclo de vida del software, desde el entorno de desarrollo, hasta el de producción. Y no, no me refiero a permitir o no hacer cambios directamente en producción. De eso creo que ya hemos hablado. Me refiero a controlar los cambios en cualquier entorno mediante el concepto de línea base.

¿Qué es la línea base?

La línea base es un concepto de la gestión de la configuración (otro día hablaremos de ella). La línea base se define en el IEEE 600.12/1990 como:

Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

La línea base es un contrato. Un contrato igual que lo es una API, o el WSDL de un servicio web. La línea base establece en qué puedo confiar, porque es algo acordado (ni siquiera tiene porqué ser bueno, probado, excelente o definitivo). Hablamos de una versión de cada uno de los componentes software, que en conjunto, se ha acordado que es correcta en su conjunto. Pero sin suponer esto que cumpla los requisitos, ni las pruebas…simplemente es un hito.

Cuando trabajas con Subversión, TFS o Github, tenemos los conjuntos de cambios, tags o Changesets. Esas etiquetas o paquetes de cambios identifican el software en su conjunto, y son como una foto. Sí, como una foto del software en un momento y situación determinados del tiempo.

Aquí la idea no es versionar. No es un control de cambios. Es tener la posibilidad de devolver todo el código a un momento del tiempo en el que sabíamos que algo funcionaba (o no), pero al menos conocíamos su estado en conjunto. Esto es muy importante para controlar el estado de los entornos, para poder devolver un entorno (pruebas, desarrollo, calidad, preproducción, formación, producción), a un estado conocido.

Si la línea base es una foto, instalar una línea base es devolver a un entorno a un estado conocido, es un viaje al pasado.

Por ese motivo, jamás deberemos tocar el código en producción, ni en pre-producción, ni en otro entorno que no tengamos debidamente controlado con el correspondiente gestor (SVN, Github, TFS…). Porque si tocamos el código, hemos perdido la partida. Ya no podremos tener control de hacer una nueva “foto”, y empezaremos a perder el control de los cambios, de los entornos, del desarrollo.

Y claro que podemos coger ese código, hacer un checkout en desarrollo y poner ese código después para recuperar el estado del entorno de desarrollo. Y claro, también existe Santa Claus, y Blancanieves, y los siete enanitos. Si no lo hicimos en un principio, si nos hemos dejado seducir para tocar el código en producción y “jugárnosla”, hemos perdido el control y ha dejado de jugar a nuestro favor todos los beneficios de la integración continua, testing automático, etc, etc.

Alguna vez he oído decir que tocar el código en producción es como dejarse seducir por el lado oscuro de la fuerza. Tentador…pero no sólo es algo que esté mal…es algo cuyo precio vas a pagar tarde o temprano.

DevOps: la palabra de moda

devopsBueno, parece que el concepto de DevOps ha adquirido categoría casi viral. Se habla de él en las redes, y se hace a través de términos relacionados, o de herramientas usadas para llevar a cabo soluciones relacionadas con dicho concepto.

¿Pero qué es esto de DevOps?

Aunque varios conceptos de DevOps son viejos conocidos, se les añadieron algunos nuevos para dar una visión unificada. Ha adquirido especial protagonismo, por la visión de DevOps desde el punto de vista de los programadores. En realidad, la palabra ya incluye la definición. DevOps no es más que Development (Desarrollo) y Operations (Operaciones).

El origen del conflicto…

El concepto, como decía antes, no es nuevo. El objetivo de la “gente de sistemas” (operaciones), es mantener estables los sistemas, y por tanto, establecen controles en el número y forma de los despliegues en producción. Sin embargo, siempre ha existido una corriente opuesta (la de los desarrolladores), de poder tener acceso a producción, de poder desplegar un cambio o un producto con la mayor rapidez posible, y sin todos los controles, validaciones y protocolos que les imponen desde los departamentos de operaciones (recordemos: sistemas).

Ambas corrientes se sienten poseedoras de la razón. Pero como ya ha ocurrido en muchas otras iniciativas…el sentimiento agile habría de venir al rescate para facilitar a los desarrolladores el imponerse sobre la gente de operaciones.

…Y la llegada de la solución

El área de desarrollo apuesta por el cambio, por la facilidad del cambio. Y operaciones…por la estabilidad y el control. Con esto, ya tendríamos la semilla para que aprovechando las tendencias ágiles, la gente de desarrollo se sintiera legitimada para poder imponer su criterio y tener un mayor acceso y control sobre los sistemas de producción. Por otro lado, para apoyar los criterios del personal de operaciones, se usarían diversas técnicas que integraran control y rapidez de puesta en producción: un ejemplo lo tenemos en la adopción de buenas prácticas como ITIL, o los conceptos de Integración Continua.

De esta forma, se adoptarían metodologías ágiles que integrarían por un lado los esfuerzos de los equipos de desarrollo, que dejarían los objetos/código fuente bien probados y convenientemente etiquetados . Por otro, el equipo de operaciones recoge el testigo y se encarga de la puesta en producción del desarrollo/cambio, pero de una manera ágil y al mismo tiempo, segura.

DevOps trata de integrar así los objetivos de las diversas partes en conflicto con términos más o menos novedosos (al menos en su aplicación):

  • Asegurar la calidad de la entrega mediante métricas de calidad de código y pruebas automatizadas. De esta forma, el área de operaciones (ahora parte de “DevOps”), confía en el producto y corre muchos menos riesgos, lo que facilita realizar despliegues prácticamente inmediatamente después de estar el código disponible.
  • Los procesos (apoyados en conceptos como ITIL e integración continua, automatización de pruebas, etc), facilitan la integración Dev+Ops, al trabajar todos en una misma cadena.
  • Automatización: la clave de una puesta rápida en producción es que se realice al máximo a través de herramientas, no de personas. Las validaciones han de ser objetivas al máximo.

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