¿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.

Scrum / Agile: Malos hábitos III - Agilidad sin disciplina

Siguiendo con la serie de "malos hábitos" en desarrollo de software ágil que inicié hace algunos días, donde he escrito acerca de la importancia de la autonomía e información para los equipos que desarrollan software, me referiré hoy a lo importante que es la disciplina:

III. Agilidad sin disciplina

Hay quienes creen que basta con tener en el cajón del escritorio una carpeta que define el proceso o tener a alguien en el equipo que lleva el título de scrum master para tener garantizado el éxito en el proyecto de desarrollo de software.  Pero no se trata del nombre del proceso, o si se llama Scrum, Kanban o V-Model XT. Lo importante es que no es posible hacer software de calidad sin disciplina, y menos aún si se utilizan técnicas ágiles para el desarrollo de software.

En el Manifiesto por el Desarrollo Ágil de Software dice entre otras cosas que "Software functionando tiene más valor que documentación extensiva". Esta frase ha sido malinterpretada al punto que he oído muchas veces gente decir que el desarrollo Ágil de Software no es más que hacer software sin hacer planes ni escribir documentación. Lo cual no puede ser más falso!

Desarrollar software de manera ágil significa permitirle al equipo que la desarrolla encontrar los mejores caminos para hacerlo.  Implica también tener en el equipo gente capacitada y con experiencia, que sepa que el camino más corto no es siempre el más rápido ni el mejor.  Un equipo de software ágil sabrá por lo tanto:

• Que hay que documentar todo lo que sea necesario, pero no más. Hay que hacerlo de manera eficiente. No se trata de cumplir con una aburrida obligación, sino de guardar suficiente información para futuras decisiones.
• Que hay que testear desde el principio al fin, pues esa es la única garantía de que lo que el producto final cumpla con los requerimientos de calidad y que el usuario pueda hacer con el software lo que tiene que hacer. Idealmente, el equipo debe pensar como automatizar las pruebas de testeo para reducir el esfuerzo a futuro.
• Hay que respetar los acuerdos, pues esa es la única forma de trabajar eficientemente en equipo.
• Hay que imponerse metas agresivas pero alcanzables.
• Que si se tiene información o experiencia, hay que usarla y si no se tiene, pues primero hay que buscarla.  

Agilidad requiere una dosis extra de disciplina, porque cada miembro del equipo es indispensable.  El valor, el peso y la responsabilidad de cada uno es por lo tanto mayor. 

Scrum / Agile: Malos hábitos II - Agilidad sin información

Siguiendo con el tema de los malos hábitos en el desarrollo de software ágil iniciado la semana pasada con este post, donde escribí acerca de la agilidad sin autonomía, me referiré hoy a otro problema que frecuentemente he visto en equipos que han optado por utilizar técnicas de desarrollo ágil de software.

II. Agilidad sin información

Desarrollar software de manera ágil significa que individuos (programadores, testeadores, clientes, arquitectos) trabajan (colaboran) juntos para producir software.  Para hacerlo, utilizan herramientas y procesos, pero ellos, quienes hacen el trabajo, son más importantes que dichas herramientas y procesos.  También utilizan documentación, pero miden el progreso del proyecto con resultados (software) y no con papeles llenos de documentación que nadie lee.

El equipo que trabaja para producir el software toma decisiones, para lo cual no sólo necesita la autonomía mencionada en el post anterior, sino que también necesita información fidedigna, correcta y actual.

El primer paso, es que el equipo sepa hacia donde debe ir.  Sólo así podrá tomar buenas decisiones y encontrar las mejores respuestas a la pregunta de cómo llegar a dicho objetivo. Debe saber toda la verdad acerca de las expectativas que se tienen del equipo.

El siguiente paso, igualmente importante es que el equipo cultive un ambiente de honestidad y apertura, donde todos sientan que pueden hablar con la verdad y que pueden confiar en lo que los otros dicen. Si no es posible lograr esto, recomiendo sinceramente desistir de usar cualquier técnica de desarrollo ágil inmediatamente, pues el equipo no logrará obtener los resultados que se esperan de él.

Uno de los puntos más frecuentes que un equipo debe acordar en este sentido es la definición de "terminado" (done). Cuando alguien afirma estar listo con una tarea, es importante que todos en el equipo entiendan qué es lo que ello significa. Si alguien dice que terminó una tarea, por haberse comprometido a ello y pese a no haberlo logrado, estará poniendo en riesgo al equipo entero, pues éste basará sus decisiones en información errónea.

El tema de la honestidad y comunicación abierta debe ser tratado en retrospectivas, para encontrar acuerdos que ayuden a un equipo a crecer y mejorar sus resultados.

La comunicación hacia el exterior, por ejemplo el estado de avance del proyecto, debe ser realizado de la misma manera: en forma directa y transparente.  Pues todo lo dicho antes acerca de la toma de decisiones dentro del equipo, también se aplica hacia afuera: otros proyectos necesitan también poder tomar buenas decisiones.

Scrum / Agile: Malos hábitos I - Agilidad sin autonomía

Existen algunos hábitos que dificultan o impiden aprovechar las ventajas de sistemas como Scrum o metodologías ágiles en general. He recibido muchas preguntas al respecto e intentaré ir posteando algunos de estos malos hábitos con cierta frecuencia, para compartir con ustedes mi experiencia, además de recibir vuestras ideas y comentarios.

I. Agilidad sin autonomía

No basta con decir que se utiliza Scrum, que se tiene un Scrum Master y un Product Owner.  No basta con trabajar en iteraciones y hacer reuniones de pie (standup meetings). He visto equipos que dicen ser ágiles, donde alguien (un gerente de proyectos o arquitecto, por ejemplo) prepara el proyecto de tal manera que lo único que resta por hacer al equipo que ha de implementar el software es ejecutar el plan que otro diseñó. Andes de empezar el proyecto, la arquitectura ya está definida, las tareas asignadas, incluso con estimaciones.  Ejemplar, dirán algunos.  ¡Un desastre!

El equipo debe recibir toda la información necesaria para poder DECIDIR.  El equipo toma decisiones, el equipo ha de entender el objetivo y ha de recibir lo que necesita para poder alcanzarlo.  Pero es el equipo el que decide qué camino seguir para llegar a la meta.  Cuando alguien decide de antemano qué camino debe seguir el equipo, se le está quitando autonomía, se le está restringiendo la libertad necesaria para que el equipo se sienta responsable de lograr el objetivo.

Un equipo de desarrollo de software ha de recibir lo máximo de información posible y lo mínimo posible de restricciones. Sólo así aflora la motivación intrínseca y la creatividad.

Manifiesto por el Desarrollo Ágil de Software

He visto muchos equipos que desarrollan software, siguiendo procesos que dicen ser ágiles, donde quienes participan en el desarrollo de software no saben de la existencia del Manifiesto por el Desarrollo Ágil de Software (agile manifesto).  Eso es terrible!

Quien lidera una proyectos u organizaciones influenciados por el pensamiento de la agilidad deben explicar a todos los miembros del equipo los principios y fundamentos que forman la base de la forma en que el equipo trabaja.  Es la única forma de lograr que la agilidad produzca los frutos que ofrece.

Mando y control

Dos seres humanos caminan por una multitud.  Uno le dice al otro en qué dirección debe ir, el otro le sigue ciegamente las órdenes. Una simbiosis. Tres pasos, deben detenerse. Dos pasos, detenerse nuevamente. Siempre vuelven a cruzarse personas, siempre es necesaria una nueva orden.  Izquierda, recto, izquierda, derecha. Dos seres humanos, uno piensa, el otro obedece. Dos seres humanos que hacen el trabajo de uno.

No son un equipo, pues en tal caso serían más que sólo dos seres humanos que hacen el trabajo de uno. Son dos seres humanos que siguen al pie de la letra su función. El resultado no es bueno y ninguno disfruta de lo que hace. Ambos saben que podrían caminar más si cada uno decidiera por su cuenta la dirección en la que debe caminar. Los une nada más que una estricta definición de roles: uno comanda, el otro ejecuta y el primero controla.

Existen jefes hoy en día que trabajan de esa manera con sus empleados. Y eso en pleno siglo dieci...veintiuno.

Hacer todo al mismo tiempo

En cualquier área de la industria es necesario que quienes trabajan se hagan cargo de múltiples tareas. Un error que con frecuencia se hace es tratar de hacer todo al mismo tiempo.  Parece obvio que es mejor hacer una cosa después de la otra para producir muchos y buenos resultados, pero desgraciadamente la tentación de intentar abarcarlo todo simultáneamente es muy grande.

A lo largo de mi carrera, como programador, jefe de proyectos y gerente en desarrollo de software, he visto en multiples ocasiones personas y organizaciones muy capaces fracasar por tratar de hacer mucho simultáneamente. Personalmente me ha ocurrido y debo confesar que debo esforzarme a veces por evitar caer en la tentación.

Aquí algunas razones por las cuales es tentador tratar de paralelizar:

• Crea la impresión de "estar haciendo algo", de no haber dejado de lado el tema. 
• Hacer varias cosas en paralelo puede servir para utilizar mejor la capacidad disponible, pues existen tiempos de espera en toda actividad. Sirve para "aprovechar mejor el tiempo".
• Aprovechar el hecho de que una organización tiene múltiples miembros para tratar multiples temas en paralelo

Esos puntos pueden ser ciertos y puede que paralelizar tenga en algunos casos un efecto positivo.  Lo cierto es que también tiene riesgos:

• Cada una de las actividades que se realiza en paralelo, avanza más lento que si se llevaran a cabo una después de la otra (en secuencia). 
• Debido a que actividades que se realizan en paralelo tardan más en finalizar, se tiene permanentemente la sensación de avanzar lento y entregar resultados de mala calidad.  Esto es muy, muy, muy frustrante!
• Mantener distintas actividades andando simultáneamente requiere más concentración pues hay que estar pendiente de cada una de las actividades que se realiza. Puede parecer trivial, pero no lo es. En la práctica nos cuesta hacer dos cosas a la vez sin equivocarnos o dejar de prestar atención a una de las actividades.
• Paralelizar implica aumentar el esfuerzo requerido para coordinar los distintos procesos. No hay que menospreciar este esfuerzo!

Una buena organización se preocupa de ordenar las tareas en una única lista e intenta resolver las tareas una después de la otra, concentrando toda su capacidad y energía en hacerlo rápido y bien. No siempre es posible hacerlo, pero es una meta que hay que seguir.

Lo difícil es ponerse de acuerdo en la lista de tareas y definir el orden (no prioridad!) de ellas. Lograr acordar dicha lista común es una difícil actividad, pero lograr hacerla es un hito tremendamente importante para toda organización. He visto organizaciones florecer después de hacer este "pequeño" cambio.

To Scrum or not to Scrum

En el mundo del desarrollo de software ha ocurrido una pequeña revolución en los últimos años. La gente se ha dado cuenta que la calidad del software no depende principalmente de pesados procesos y herramientas, sino de la gente que lo hace, de cómo se comunica, de lo que sabe y qué es lo que la motiva. El pensamiento ha llevado a cambiar las bases del desarrollo de software por principios y conceptos que otorgan "agilidad".

Ese descubrimiento (nada nuevo, dirán algunos) ha creado una nueva industria de gente que ayuda a equipos de desarrolladores de softwre a modificar la forma en que trabajan para ser más ágiles. Han aparecido expertos, coaches, miles de libros, programas, conferencias y cursos.

Uno de esos "productos" que ha nacido se llama "Scrum", es un sistema, un marco (framework) para desarrollar software. Consiste en una serie de métodos, consejos, definiciones que permiten a un equipo trabajar de manera ágil.

Me parece bien, muy bien. Es bueno que existan esta clase de sistemas, claramente definidos.

Pero al mismo tiempo es un peligro. El peligro está que que esos sistemas se usen ciegamente, como quien sigue un proceso, sin pensar, sin siquera cuestionarse que algo podría hacerse de mejor manera.

Yo prefiero seguir principios que seguir una definición tan detallada como Scrum. Eso me deja pensar si lo que hago sigue los principios, y si no lo hace, pues debo corregir la dirección. Prefiero eso que pensar si estoy haciendo Scrum como dice en el libro, sin pensar que las ideas del libro puedan alejarme de una mejor manera de trabajar.

Scrum es mejor que Waterfall, Scrum es mejor que ningún proceso definido. Pero en mi experiencie, tener como meta ser cada día mejor y seguir los principios de la agilidad entrega más libertad y mejores resultados.

Acerca de la importancia de las retrospectivas

En mi experiencia, nunca debe faltar tiempo para retrospectivas.  Nunca, nunca, nunca!

He visto proyectos, he trabajado en proyectos y los he gestionado y conozco el costo que tiene no tomarse suficiente tiempo, frecuentemente,  para reflexionar acerca de la forma en que se trabaja y de las maneras que existen para mejorar, para superar problemas, para acercarse un paso más a la excelencia.

He visto a geniales arquitectos de software, analistas, programadores, testers fracasar usando métodos ágiles, siguiendo con fervor las ideas de Ken Schwaber, pero olvidando tomarse tiempo para hacer retrospectivas.

Si tu proyecto está tarde, si crees que no tienes tiempo que perder para lograr producir el software en que trabajas, entonces para por unos minutos, o por algunas horas y habla con tu equipo acerca de aquello que les impide ser más rápidos y mejores.  Da igual si usas Scrum, FDD, V-ModelXT o lo que sea, el tiempo invertido se recuperará más rápido de lo que puedes imaginar!

Gerentes y Agilidad

Hoy toda la industria del software habla de agilidad y Scrum. Quienes desarrollan software trabajan cada vez más en equipos multifuncionales, que buscan organizarse solos.  La pregunta que crece y crece es el rol de los gerentes, jefes de departamentos y áreas en una organización que desarrolla software de forma ágil.

Si los equipos se organizan solos, cuál es el rol del jefe? Si los equipos determinan por su propia cuenta, a través de retrospección, lo que deben modificar para ser más productivos, qué es lo que hace el jefe de un departamento de desarrollo de software?

Incluso el tema de la capacitación es algo que ocurre dentro del equipo.  Si se determina que alguien necesita capacitarse para rendir más, pues el equipo (con ayuda quizás de un scrummaster) lo organiza.  No era esa un área exclusiva del jefe o del área de recursos humanos?

El movimiento de agilidad y lean han cambiado mucho la industria del software y de seguro tendrá un impacto en el resto de las organizaciones.  El jefe ha pasado de ser una máquina de decisiones a ser un ayudante, que ayuda a resolver los problemas y un coach.  Si el foco de los métodos ágiles está en los equipos, el del jefe de desarrollo (o R&D) está en crear el entorno para que los equipos puedan desenvolverse y en cada individuo.  Qué hacer para que cada empleado obtenga retroalimentación (feedback)? Qué hacer para que aplique y desarrolle sus talentos? En qué dirección debe desarrollarse para que sus habilidades y sus resultados crezcan?

El mundo del desarrollo de software ha cambiado mucho, a favor de programadores, testers y analistas. Ahora por fin es permitido y requerido usar el cerebro completo. Para quienes lideran el mundo también es muy distinto, mucho mejor.

Consumo de Energía

Hace unos días recibí la cuenta de electricidad del año pasado y noté un aumento de un 40% en el consumo eléctrico. Ante ello decidí utilizar un medidor de corriente para investigar qué aparato ha producido dicho aumento.

Compré un Energy Logger 3500 de la firma Voltcraft, cree una biblioteca en C# para procesar los datos almacenados en archivos binarios y programé una pequeña interfaz gráfica en WPF para visualizar los datos y exportarlos en CSV.

Así se ve el resultado:

Si necesitas un programa que convierta o visualize los datos de un Energy Logger 3500 ó 4000 de Voltcraft, envíame un mail y con gusto te ayudaré.

Con esa aplicación me ha sido fácil descubrir al malhechor y preocuparme que el próximo año, la cuenta de electricidad se vea considerablemente mejor.

Kanban, Scrum, XP y la pérdida de agilidad

Existen muchos métodos ágiles para desarrollar software. Cuando uno empieza a buscar, uno se da cuenta de la variedad de métodos que existe. ¿Cuál es el mejor de todos? ¿Por qué hay tantos distintos métodos? ¿Son todos necesarios?


Como en cualquier clase de cosas y en cualquier área de la ingeniería, hay muchos caminos que nos llevan a la meta. Pero no hay un camino ideal, que sea el mejor en toda circunstancia. Lo importante es entender el significado de agilidad y preguntarse de qué manera uno se puede beneficiar de ella. También es conveniente pensar en las posibles desventajas.


Para hacer más difíciles las cosas existen unos factores en torno a la agilidad que reducen la transparencia y aumentan la dificultad de encontrar un método de desarrollo que ayude a aumentar la productividad y calidad del desarrollo de software:

• El concepto de agilidad no es ni debe ser un dogma: se trata de utilizar la creatividad y la información para adaptarse y encontrar el mejor camino hacia la meta. Hay quienes dicen que sólo se puede hacer software de forma iterativa o que los equipos que no se reúnen día a día (y de pié) no son equipos de verdad. Hacer de algo un dogma es perder capacidad de reaccionar al cambio o sea perder agilidad.
• Cuando métodos se convierten en sectas: cada método tiene hoy en día su guru y miles de ciegos seguidores. Eso es peligrosísimo, pues lo que en verdad se requiere son ojos abiertos y capacidad de adaptarse. El concepto de seguir ciegamente un plan (o un gurú?) es justamente lo que queremos evitar, ¿no? Hay quienes dicen que hay sólo UN camino correcto, que SCRUM es la verdad o KANBAN es la solución a todos los problemas. El problema no es SCRUM ni KANBAN sino que los ignorantes que predican agilidad sin ser de verdad ágiles.
• Expertos, expertos y más expertos: hay tantísimos expertos en el área del desarrollo ágil, muchos de ellos no hicieron más que decir una frase correcta en el momento correcto y hoy son venerados hoy como gurús. Varios se han hecho un dineral en libros, cursos y congresos, donde predican acerca de algo que hace más de diez años ya no practican.

Mi recomendación es elegir el método que se usa a partir de los requrimientos y problemas existentes y no a base de lo que otros dicen. Es bueno leer y aprender de la experiencia de otros, pero hay que tener cuidado de distinguir entre el trigo y la paja.

Desarrollo de software en cascada

En un mundo lleno de cambios, en el cual producir con rapidez aplicaciones que satisfagan las necesidades reales del mercado es clave para el éxito, es indispensable pensar y repensar la forma y las herramientas que los equipos que desarrollan software utilizan para trabajar.

Durante muchos años, lo normal era desarrollar software en lo que llamamos "desarrollo en cascada" (waterfall model), que divide el proceso en bloques definidos y donde cada paso depende sólo del paso anterior:

• Análisis de requisitos
• Diseño del Sistema
• Diseño del Programa
• Codificación / Implementación
• Pruebas
• Implantación
• Mantenimiento

Con los años se han establecido nuevas técnicas que en la mayoría de los casos reducen en cierto grado los problemas producidos por ésta metodología y aumentan la probabilidad de éxito de los proyectos de desarrollo de software. Durante muchos años he tenido que desarrollar software utilizando éste método y ésta es la lista de lo que a mí parecer son sus principales problemas:

• Malas decisiones, poco uso del aprendizaje: El método obliga a tomar muchas y muy importantes decisiones muy temprano en el proyecto. Las decisiones se toman en el peor momento, cuando menos se sabe del tema y de las tecnologías utilizadas. El costo de cambiar el rumbo tomado es muy alto, pues la información fluye sólo en una dirección (de arriba hacia abajo). Frecuentemente ocurre que cerca del final del proyecto todos los participantes han logrado recién alcanzar un grado suficiente de profundidad en su conocimiento del tema y sus tecnologías como para poder tomar decisiones correctas. Lamentablemente, en ese momento ese conocimiento ya no es requerido.
• Mala comunicación: El camino de la información es desde arriba hacia abajo (ver lista más arriba). La forma consiste en general en interminables documentos que nadie es capaz de leer ni entender.  La pérdida de información es considerable. Quien describe los requerimientos del sistema no dialoga con quien lo implementa y el testeo ocurre sin conocer al cliente. No es que siempre deba ser así, pero en la mayoría de los casos así ocurre y es difícil revertir esa tendencia.
• Falta de flexibilidad: Debido a que mucho se define con muchos detalles en un inicio, es muy difícil cambiar la dirección y reaccionar al cambio. En nuestro mundo en el que nuevas tecnologías aparecen a diario y en mercados donde la competencia no duerme es necesario poder reaccionar. Por muy elaborado que sea el plan, si las reglas del juego cambian, habrá que rehacerlo y eso es caro!
• Responsabilidad diluida: La responsabilidad por un producto no se comparte si cada parte involucrada es únicamente responsable por su trabajo. Los proyectos exitosos no sólo requieren excelentes profesionales que dominen sus áreas, sino que además un equipo en el cual todos trabajan juntos tras un objetivo común.  Si cada quién es responsable sólo por su parte del proceso y no por el resultado común, es difícil producir un buen producto.

La industria del software ha reaccionado a éste fenómeno con movimientos como el desarrollo ágil, que ayudan a subsanar estos problemas. Estoy seguro que el desarrollo en cascada puede ser la solución para uno que otro proyecto de software, pero para la gran mayoría hay alternativas mejores y mi recomendación para todo aquel que gane su vida en la industria del software es que gaste algunos minutos leyendo y pensando acerca de metodologías modernas como por ejemplo Scrum, XP, Kanban, Lean y Feature Driven.

Transición hacia desarrollo ágil de software

El desarrollo ágil de software existe ya hace varios años, pero se ha comenzado a masificar sólo dentro de los últimos años. Ya que el proceso de migrar desde un método "tradicional" a uno ágil es bastante similar en cada empresa y equipo, vale la pena aprender de otros que han vivido el cambio.

Les recomiendo ver este interesante webcast (en inglés) titulado "Agile transformation of a Microsoft product team", en el cual Cameron Skinner (MS) relata lo que él ha aprendido durante ese proceso.