You are currently browsing the monthly archive for agosto 2018.

Ya desde tiempo, los “métodos ágiles” de desarrollo de software como Scrum, eXtreme Programming o Scaled Agile son de moda; tanto que incluso tu empresa ya estará disfrutando de ellas. O de algo parecido al menos de nombre. Porque los métodos ágiles se parecen a menudo al comunismo. Son ideas maravillosas mientras no tienes que vivir con ellas.

Lo que también tienen en común con el comunismo, es que ciertos elementos, sí, son útiles. Igual como un capitalismo social avanza el bienestar general (capitalismo = hay medicamentos, socialismo = los enfermos pueden pagarlo), elementos de los métodos ágiles pueden mejorar mucho el desarrollo de software. La pregunta es: ¿qué elementos?

Para sacarles el mejor rendimiento, conviene entender el contexto cultural de donde los métodos ágiles salieron. Como muchas ideas religiosas recientes, los métodos ágiles también han salido de los Estados Unidos de América. Y como los norte-americanos tienen un don de marketing, les gusta dar nombre llamativos como “Scrum”, “eXtreme Programming” o “Chrystal Clear” que, para el tu bien mental, mejor no traduzques a tu lengua materna. El libro gordo de esta religión se llama “Agile Manifesto” y expresa, entre otras cosas, y en palabras más positivas, los siguiüente puntos en negrita.

  1. La profesionalización del concepto “el producto madura en el cliente”. Funciona muy bien, mientras el cliente piensa que las frecuente actualizaciones corresponden a “mantener el producto” y no a “no hacerlo bien desdel principio”. Madurar el producto en el cliente está aceptable para el software que tienes en tu teléfono, pero no suele ser buena idea para aparatos medicinales.
  2. Nadie tiene dominios. Todos programan de todo. En todas las empresas (menos en una en que era el único programador) se ha tenido la idea de un proxy que sería capaz de hacer tu trabajo si no estás por enfermedad, vacaciones o despido. Y en ninguna empresa ha durado mucho hasta dejarlo. Los programadores no son intercambiables. Todos no saben igual de todo. En el momento que escribes una pieza de código, eres automáticamente el máximo experto para ello. Es inevitable. Así, o bien aceptas que los demás programadores constantemente deben aprender código nuevo que les hace bastante lento, o dejas mentirte y aceptas que cada uno tiene un dominio. No quiero decir que vale la pena mandar a todos a hacer de todo. Puede funcionar si se hace con consecuencia desde el principio. Pero no pondrás un novato a estudiar una nueva parte de código por varios días, si mañana tienes la release final.
  3. No hagas documentación que nadie se lea. Porque cualquier documentación tiene el peligro de hacerse obsoleta con los cambios en el códio. Por eso es mejor no tenerla. En cambio el códio es auto-explicativo y el resto se pregunta. No olvides que comunicación es importante en los métodos ágiles. Ya sabes, todos deben saber de todo, y mejor que no haya nadie a quién ocurre proponer un documento que explica el programa al menos a alto nivel. Saber leer y dejar trabar a los demás es para introvertidos. Los novatos tienen que integrarse y esto es más fácil si deben preguntar de todo. Mejor aún si deben pasarse una semana entera (o para siempre) con una pareja veterana en la mesa. Así y comunicación.
  4. Usa el sentido común. Recordar que comunicación es importante parece poco novedoso si vienes de un país con un clima en que a la gente gusta encontrarse en la calle, pero esto quizá no es tan obvio para otros países donde tienes el permiso de sacar un arma si alguien pisa tu territorio. Tampoco falta un título en bla-bla avanzado para descubrir, que es más eficiente si un programador termina un trabajo antes de empezar uno nuevo en lugar de interumpirle constantemente. Si quieres promover métodos ágiles en tu empresa, considera que, fuera de Estados Unidos, la gente viene equipado con sentido común desde fábrica y probablemente ya lo sabe.

De hecho, sentido común ayuda considerablemente en sacar el máximo provecho de los métodos ágiles. Desgraciadamente, estos “consultores” de métodos ágiles demasiadas veces no son lo suficientemente ágiles ellos mismos para reconocer, que los prerequisitos de su método son díficiles de conseguir. Programadores no son fáciles de intercambiar, el product owner no tiene tiempo aunque debería y el cliente no tiene ganas de pasar su tiempo en la empresa que paga para quitarle el trabajo.

Un buen ejemplo del carácter religioso de métodos ágiles es la creencia de la mayor eficiencia de la programación en pareja. Una minoría de los programadores se llevará bien, y pasa el día charlando en lugar de trabajando. La mayoría acaba estando tan estresando con tener constantemente otro tipo al lado, que se marchará de la empresa. De hecho, la programación en pareja es una manera eficaz de descubrir los programadores competentes: son aquellos que se han ido tras un año. Pero también puedes verlo positivo: siempre tendrás a un equipo joven. (Si no te dejan introducir la programación en pareja para descubrir a los talentos, obligar a llevar corbata funciona también. Si ya llevas corbata pero no entiendes el chiste, entonces, enhorabuena, ya trabajas para tu empresa perfecta.)

No sigas a un método ágil porque es la moda. Busca los elementos que mejoran tu desarrollo y aplícalos al dominio adecuado.

Como ejemplo de limitar el dominio adecuado, considera una empresa que vende equipamento médico. No puede vender su producto mediamente hecha y esperar mejorarlo cada dos semanas con las opiniones de sus clientes. Un laboratorio médico puede tardar un año entero probando que tu producto funciona como deseado. Te puedes imaginar como se alegran de poder repetirlo cada mes. Pero lo que puedes hacer, es producir versiones tempranas durante el desarrollo del producto para poder probarlo con todos los componentes existentes juntos. En este caso el método ágil no funciona con el cliente externo, pero, sí, con clientes internos.

No obstante, son muchos los elementos de los métodos ágiles que valen la pena tener en consideración.

  1. Empieza con un producto minimal, pero útil y con calidad. Lo “minimal” puede a veces ser todo, pero muchas veces no lo es. Y si lo poco funciona bien, los clientes estarán interesados en la próxima versión.
  2. A nivel de equipo de desarrollo, esto se traduce a generar una versión temprana para que otros equipos puedan integrarla. Puede ser incompleta, pero debería funcionar.
  3. Genera versiones con frecuencia, para que los demás equipos pueden tener la mejor versión posible en cada momento.
  4. Intenta dividir tareas grandes en tareas pequeñas pero completas en sí, para que puedas publicar algo en cada iteración.
  5. Usa ramas de desarrollo para añadir nuevas funcionalidades y siempre manten una versión que funciona. Puede ser tu rescate si un desarrollo no funcionaba.
  6. Sólo añade cambios completos. Completo quiere decir que haya casos de pruebas (que se ejecutan automatizados) y la documentación adecuada. (Actualizar la documentación es parte del cambio.)
  7. Limitarse a lo que es necesario. Lo necesario es a veces no tan fácil de reconocer. En primer lugar no es crear un vector de n elementos especificado para el caso n = 3, si sólo necesitas un vector de tamaño 3. En el mismo primer lugar es no crear documentación porque sí, sino por qué ya sabes denominar alguien, que la quiera leer. (Miembros nuevos del equipo, por ejemplo.) De otro lado hay decisiones en que hay que pensar hasta el final: La arquitectura del programa, los requisitos mínimos, si los programadores serán intercambiales (y por lo tanto se les permite más tiempo para aprender código nuevo), la estructura de crear y testear versiones etc. Una buena estrategia para limitarse a lo necesario es pensar: ¿ya tenemos un escenario en que esto va a importar? ¿Sí? ¡Entonces hazlo! ¿No? ¡Entonces espera con ello! No hagas cosas por si acaso sino porque alguien quiere pagar por ellas.
  8. Fomentar la comunicación. Las pequeñas reuniones diarias y un tablón con las tareas pendientes fomenta que todos ven como va el equipo en completo.
  9. Ten una estructura de comunicarse con el cliente. Los métodos ágiles demandan que los clientes están presentes en el equipo de desarrollo. Esto es muchas veces imposible. Pero debería haber alguien que pueda presentar la vista del cliente – y esto será preferiblemente uno que entiende realmente a clientes aunque no entienda de todo a los programadores.
  10. Dejar a los programadores estimar cuánto tiempo necesitan para una tarea y dejarles decidir, a cuantas tareas se quieren cometer. Tendrás una mejor estimación de tiempo y los planes se basan en las palabras de aquellos que deben cumplirlas. Es decir, en lugar de “esto necesito hasta viernes” preguntar “qué necesitas pra terminarlo hasta viernes”.
  11. No cambies planes durante una iteración. Deja suficiente tiempo libre para atender a emergencias típicas.
  12. Intenta terminar el plan de una iteración. Si un programador ya hizo todo su trabajo, entonces quizá puede ayudar a otro en crear casos de pruebas o actualizar la documentación.

En fin, esto no es un pamfleto contra los método ágiles, pero uno contra su aplicación religiosa. Y un recordadorio que todas las culturas tienen puntos fuertes. Hazte conciente de ellas antes de adoptar algo sólo porque aparenta tener éxito en EEUU.

Lectura adicional

Escribe tu dirección de correo electrónico para suscribirte a este blog, y recibir notificaciones de nuevos mensajes por correo.

Únete a otros 52 seguidores

Archivos

agosto 2018
L M X J V S D
« Abr   Nov »
 12345
6789101112
13141516171819
20212223242526
2728293031