¿Se parece el desarrollo de software a la jardinería?

El otro día, mientras paseaba por un parque en Stuttgart, veía este hermoso jardín y me preguntaba qué similitudes existen entre el desarrollo de software y la jardinería. Me di cuenta que hay muchas.

Aquí hay algunas de las ideas que se me ocurren ahora. Si tienes otras ideas, por favor, envíame tus comentarios:

• Ambos, jardines y software evolucionan con el paso del tiempo. Las plantas, los arbustos y los árboles crecen, el paisaje cambia. Lo mismo ocurre con el software, pues aparecen nuevas librerías y tecnologías. El software debe adaptarse al cambio.
• Es imposible predecir como un jardín y el software serán en 20 años. Serán diferentes, eso es seguro. O quizá habrán dejado de existir. ¿Cómo lo podemos saber?
• Jardines y software requieren manutención y cuidado. Los jardines hermosos, así como el buen software requieren atención al detalle. No sólo al comienzo, sino que continuamente.
• Calidad no se obtiene por casualidad. Calidad es el resultado de una buena estrategia, de un trabajo profesional, de disciplina, mucha dedicación y atención al detalle.
• Puedes disfrutar mucho trabajar en tu jardín. También puedes amar crear y mantener buen software.
• Existen muchísimas tareas repetitivas que pueden ser automatizadas. Un buen automatismo da la libertad para dedicar más tiempo para mejorar otros importantes detalles.
• Buenas herramientas hacen el trabajo más fácil y entretenido.

¿Existen otras similitudes que he olvidado mencionar?

Malawi

En una de esas extrañas oportunidades que nos da la industria de software, he tenido la oportunidad de visitar Malawi durante algunas semanas. Gran experiencia, lindos recuerdos. Malawi vive más que nada de la producción de tabaco. Aquí una foto de los gigantescos e increíbles Auction Floors en Lilongwe, lugar donde los productores venden su tabaco:

Auction Floors en Lilongwe (Malawi)

Además, una foto del terminal internacional en Lilongwe, que me recordó muchísimo al aeropuerto de Santiago (Chile) de mi infancia:

Terminal Internacional en Lilongwe (Malawi)

Por qué desarrollo ágil de Software

Hace unos 5 años, un una conferencia de desarrollo de software, el presentador preguntó al público quien trabaja en una organización que utiliza desarrollo ágil de software. Casi el 90% de los asistentes levantó la mano. Estoy seguro que casi nadie lo hacía, pero claro - ¿quién querría reconocer que en su organización el software se desarrolla de manera lenta, pesada o torpe?

Lamentablemente, en la práctica, la mayoría de las empresas desarrollan software de esa manera. He aquí un intento de explicar mi argumento:

• Lento: La mayoría de las empresas han creado procesos con el fin de asegurar un mínimo estándar de calidad y una mínima velocidad. Procesos que incluyen una documentación exhaustiva de cada paso, que requieren la contribución de muchas personas de muchas áreas de la empresa, que tienen muchos objetivos distintos, muchas veces contrarios.
• Pesado: Muchos de los procesos que se utilizan en las empresas son pesados en el sentido que cada uno de los participantes debe hacer mucho "papeleo", trámites, discusiones, para ejecutar hasta el más mínimo paso. Para todos los involucrados, trabajar se siente como arrastrar un barco o una pesada locomotora.
• Torpe: Los procesos a los que la mayoría de las organizaciones ha llegado con el paso de los años son torpes en el sentido que sus largos ciclos muchas veces no les llevan a producir lo que necesitan. Una vez que el software a desarrollar está terminado, el mercado ya no lo necesita. Es muy difícil o caro corregir el rumbo del barco una vez que ha zarpado en una dirección. Eso ya no funciona hoy en día, en un mundo que cambia tan rápido.

Muchos han comprendido ya que los procesos que se han creado en las empresas que desarrollan software no sirven para producir buen software suficientemente rápido. Hay mucha literatura al respecto y es fácil perderse en la jungla de gurus y consultores. Lo importante a mi juicio es:

• volver a lo básico - concentrarse en aquello que agrega valor
• preguntarse siempre por qué se hace lo que hace - eliminar lo que ya no se necesita
• ser transparente - decir y buscar la verdad
• dejar que quienes hacen el trabajo decidan como lo quieren hacer - ellos lo saben mejor
• pensar y trabajar en ciclos cortos - planificar en largos ciclos es imposible en aguas turbulentas

Seguir esos principios es más difícil de lo que parece, pero vale la pena! He olvidado algún principio importante?

Gik.- 

El peligro de los acuerdos baratos

No deja de sorprenderme la capacidad que tienen las empresas para adoptar buenas ideas, modificarlas a su gusto y convertirlas en terribles problemas. Lo peor de todo es que en general, todo este proceso está liderado por personas muy inteligentes y condimentado con buenas intenciones.

He aquí algunos ejemplos:

• Introducir métodos ágiles de desarrollo de software: la idea es buena si existe la necesidad. Muchas organizaciones adoptan prácticas sin saber para qué lo hacen. Muchas veces copian patrones y conductas sin entender el trasfondo. Comienzan practicando daily standup meetings y creen ser ágiles. Al final resulta ser una pérdida de tiempo y la organización queda con la sensación de que eso de la agilidad es una mala idea.
• Mezclar filosofías o prácticas incompatibles: Scrum es una buena herramienta. La única desventaja desde el punto de vista de algunas organizaciones es la falta de control y la dilución de autoridad y toma de decisiones. Qué tal si se mezcla Scrum con algo de autoritarismo, control y toma de decisiones centralizada. La combinación ideal? Mejor ni lo intenten!
• Scrum especializado: Es genial tener un equipo de desarrollo de software capaz de entregar software cada 14 días. Para ello sólo se necesitan programadores. Se les encierra en una pieza y se les deja tranquilos. No hay para qué mezclarles con expertos del negocio ni testadores, pues podrían distraerlos. Horror!

No lo sé. Me encanta mi trabajo. Me encanta ayudar a organizaciones a mejorar la forma en que trabajan para producir software. Pero a veces la creatividad para convertir buenas intenciones en resultados desastrosos me sobrecoge.

Serie Scrum / Agile: Malos hábitos

Hoy en día todo aquel que desarrolla software dice hacerlo de manera ágil. Casi todos dicen usar Scrum, Lean, Kanban o alguna mezcla de dichos métodos. Muchos, quizás la mayoría, lo hacen sin saber lo que se esconde detrás de dichas palabras. He visto algunos fenómenos, algunos engendros de agilidad que vale la pena discutir.  He tratado de condensar dichos fenómenos en una serie.  He aquí la lista de temas tratados hasta ahora:

• Agilidad sin autonomía - Jefe: "¡Sean ágiles, pero el que decide soy yo!"
• Agilidad sin información - Jefe: "¡Sean ágiles, pero no les digo lo que deben hacer!"
• Agilidad sin disciplina - Equipo: "¡Seamos ágiles, así no tenemos que preocuparnos de documentación ni procesos!"
• Agilidad sin aprendizaje - Equipo: "¡Seamos ágiles, pero no perdamos el tiempo conversando de lo aprendido ayer!"

El desarrollo de software ágil requiere de algunos ingredientes para funcionar.  Requiere reglas, autonomía, confianza, información y disciplina.  Exige también vivir religiosamente ciertos rituales que ayudan a un equipo a comunicarse de manera efectiva, a detectar problemas y sacarlos del camino, a crecer como equipo, a desarrollar en conjunto nuevas estrategias que permiten mejorar los resultados.

Quienes creen que se puede "transformar un equipo" a metodologías ágiles en 10 días, sin consultar a los afectados y sin hablar de profundos témas valóricos y éticos, no han comprendido la profundidad del tema.

Pretendo seguir publicando más de estos fenómenos a futuro, espero que ayuden a alguien a evitar los errores que yo he tenido la suerte de cometer.

Scrum / Agile: Malos hábitos IV - Agilidad sin aprendizaje

Todos dicen que desarrollan software de manera ágil.  Algunos hablan de lean o de scrum.  En las últimas  semanas escribí acerca de la importancia de la autonomía e información para los equipos que desarrollan software, esta vez escribiré acerca del aprendizaje y las retrospectivas:

IV. Agilidad sin aprendizaje

Eso de desarrollar software en iteraciones es una buena cosa.  Ayuda al cliente (o al usuario) a ver resultados parciales y decidir los próximos pasos a seguir. En Scrum se les llama "Sprint" a estas iteraciones. También se asocia con desarrollo ágil el sentar a todos los participantes del proyecto en un lugar y darle todas las herramientas que necesitan para resolver el problema.  Mucha comunicación, muy fluida y caminos cortos.

El peligro de tener a todos sentados todos los días trabajando juntos, es que se tiene la impresión de estar bien comunicados con los demás participantes, sin estarlo realmente.  También ocurre con frecuencia que se posponen las conversaciones que ayudan al equipo a crecer y mejorar, pues lo operativo tiende a ahogar a lo estratégico.

Un equipo de desarrollo de software debe juntarse periódicamente a reflexionar acerca de la forma como trabajan y buscar caminos para mejorar. A esta clase de reuniones se les llama "retrospectivas".  En mi experiencia hay que hacer una al final de cada iteración, sin excusas.  No hay ningún momento en el transcurso del proyecto, ni ninguna situación que justifique no tomarse unas horas para que todos los participantes de un proyecto piensen como pueden llegar más rápido a la meta.  

En las retrospectivas se trata principalmente de solucionar problemas interpersonales, de coordinación, optimizar la dinámica del grupo, mejorar el uso común de recursos (entre ellos el tiempo), evitar desperdiciar el tiempo en tareas innecesarias o repeticiones y en algunas situaciones, hablar acerca de como mejorar la infraestructura.  En todo caso, lo más importante de las retrospectivas es descubrir los problemas e identificar aquellos cuya solución produzca el mayor beneficio para el equipo.

He visto fracasar prometedores proyectos dotados de inteligentísimos miembros y experimentados líderes, porque en el calor de la batalla se han olvidado de conversar de lo realmente importante: de qué manera debe cambiar el equipo y su forma de trabajar para llegar más rápido y mejor a la meta.

Si trabajas en un equipo y en las últimas semanas no han "tenido tiempo" para conversar acerca de la forma en que trabajan y no han dedicado tiempo a pensar como mejorar, entonces es el momento de parar y hacerlo.  Nunca es tarde para empezar, y verás que dentro de poco el equipo comentará a cosechar frutos y a trabajar con mayor intensidad y satisfacción.

Uso de métricas en el desarrollo de software

Crees que es buena idea medir la eficacia y velocidad de tu equipo de desarrollo de software? Es bueno medir cuánto tiempo trabajan los programadores y cuántos errores encuentran al día los testadores? Cierto? No, la idea no es buena!

Si bien toda información puede ayudar a aprender y tomar decisiones, hay informaciones útiles y otras que conducen a decisiones erradas. Por qué no medir la satisfacción de los clientes? O quizás la de aquellos que trabajan día a día desarrollando el software? Será posible que exista una relación entre la satisfacción de un programador y el resultado de su trabajo creativo?

La era de las métricas materiales y tangibles está llegando a su fin.

Les recomiendo este excelente video de TED que habla tangencialmente acerca del tema.  No directamente relacionado con desarrollo de software, pero sí con las métricas y aquello que de verdad vale la pena medir.