Articulo de Opinion de @abarros "Cuando lo Agil no es tan Agil"

Alejandro Barros, conocido consultor en la industria chilena TI escribió sobre Agilidad con orientación al sector público
Les comparto el articulo
http://www.alejandrobarros.com/cuando-lo-agil-no-es-tan-agil

¿Opiniones?
Agustin

No identificar el esfuerzo por parte de las áreas funcionales (product owners), no se visualiza que la dedicación en una metodología de desarrollo ágil es muy demandante a todo lo largo del proyecto. Esto es consustancial a este tipo de desarrollo, y si bien en los métodos tradicionales la dedicación de tiempo también era necesaria, al no cumplirla se notaba menos.

It’s not a bug. It’s a feature.

Muy de acuerdo con lo expresado con respecto sobre todo a la declaración de proyectos ágiles con una lógica de pago o de gestión en cascada ¿ como tarificar lo ágil ?..

Sin embargo, lo que me llama profundamente la atención es ver todo este glamour y esnobismo de lo ágil lleno de scrums master, sin que nadie hable de Test Driven Development, que es algo connatural si no más “Escencial de lo ágil”: Red , Green, Refactor, AAA: Arrange, Act, Assert. Sin tests el software no puede cambiar y por lo tanto va a tener todo ágil pero menos el código… lo cual es un absurdo o por lo menos muy deficiente ya que finalmente lo único que ejecutan los computadores es el código. Es claro que en Chile es algo cultural, la metafora de un campeonato de remo en Chile se jocosamente: 9 dirigiendo y sólo uno remando.

Lo que es peor aún es que he visto proyectos con Scrum Master y todo, pero programados en PHP de modo procedural sin orientación a objetos, entendiendo el bajo nivel de refactorización que prestan los lenguajes dinámicos, que de ágil puede tener esto.

Tampoco el uso de Java garantiza algo, en Chile no se enseña y no se usa programación orientada a objetos, ni en instituos o universidades, lo más que he visto es Java estilo procedural, para que hablar del uso de otras herramientas como Mocks o BDD, para lo cual nos falta un montón.

2 Me gusta

Hola Hans

(Espero verte en SoCraTes!)

Siguiendo tu linea de pensamiento es que evalúe al sector privado mucho más
bajo que Alejandro con respecto a Agilidad. Ni todos los CSMs del mundo ni
postits ni meetings salvarán en el mediano y largo plazo a los equipos que
no logren excelencia técnica.

Tuve la suerte de meterme en la Agilidad con Extreme Programming, y siempre
la mirada algo simplista (y a la vez más compleja de lo necesario) de Scrum
me quedó corta. Tengo un workshop en mente para abordar esto llamado
tentativamente “Upgrading from Scrum to full Agility”

Saludos
Agustin Villena

Agustín,

Hola, desarrollo hace 27 años, hace 10 que tengo una empresa de desarrollo
Welinux S.A: http://www.welinux.cl, hoy además tengo a 3 ingenieros
trabajando. Usamos hace 5 años play framework 1.4.x:
https://www.playframework.com/documentation/1.4.x/home del cual hice un
tutorial hace años:http://www.welinux.cl/wordpress/alawelinux/ .

TDD: Lo cierto es que me tomó bastante agarrarle la mano al TDD, tanto casi
como a la Programación Orientada a Objetos.

Llevaba varios años leyendo e intentando hacer TDD y hace poco más de un
año, es que lo estoy haciendo de manera regular y productiva, es muy bueno.
Podemos juntarnos si deseas, y por lo pronto avísame donde es el socratest
para ir.

Atte,
Hans Poo, Welinux S.A.
Bombero Ossa #1010, oficina 800,
+56-22-3729770, Movil: +56-9-93199305
Santiago, Chile

Hola Hans

Genial tu experiencia.
Toda la información de SoCraTes está disponible en
www.socrates-conference.cl y se realizará este viernes 1 de julio

Saludos!
Agustin

En mi experiencia, ningún proyecto en Chile parte sin un flujo de caja esperado, sin un cliente que tenga una carta Gantt en la mano y con algún jefe de proyecto “motivado” por los bonos de productividad: Si esto termina a tiempo, toma 100 lucas.

Esto es tan así, que incluso cuando eres gerente, tienes un presupuesto para aumentos. Mientras más le das a tus empleados, menos queda para ti. Así de simple.

Imagina que eres el inversor. Tu plata está ahí para pagar los costos: puestos, máquinas, internet, la luz, los sueldos.

El mayor costo son los sueldos. Y las empresas meten y meten gente, pero por ningún motivo te dejan gastar en computadores. ¿Dónde metes el servidor de hg? ¿El servidor de integración contínua? ¿La máquina donde de hace el testing manual? ¿La máquina donde se hace el testing de aceptación automatizado? ¿La máquina de staging donde se hace el testing lo más parecido a producción? ¿La máquina de producción? ¿La máquina donde se guardan los respaldos de la BD? ¿La máquina donde se recuperan los respaldos?.. ¿porqué de qué me sirve hacer respaldos si no estoy continuamente probándolos?

Todo requiere brain, y automatización. Acá en Chile se opta por contratar un tremendo equipo (de personas) para hacer diferentes tareas de manera manual, y después se preguntan porqué el proceso es lento y engorroso, y siempre todo termina mal.

¿Cómo tarificar lo ágil?

¿Te imaginas ir al banco para pedir un préstamo para empezar el proyecto y contarles que el proyecto no termina nunca?

Suerte con eso. No va a funcionar. El banco quiere cosas reales, como un contrato que dice que te van a pagar 4 millones de dólares por terminar el proyecto que está planificado para costar medio millón. Te prestan medio millón, pero tienes 4 hitos de pago, ¿no? De un millón cada uno, de modo que vas a gastar 125 mil al principio, te prestan los 125 mil de la primera etapa, luego ya veremos como se dan las cosas.

Ah… y debes dejar 125 mil en garantía, en caso de que no pagues… ¿porqué estoy pidiendo un crédito?

Una cosa es que el cliente reconozca que te debe la primera etapa, que la entregaste bien, y que te firme la factura, otra cosa es que aparezca ese dinero en tu cuenta. Pueden pasar 3 meses antes de que eso pase… y eso si todo fue bien.

Suele pasar que una vez que se firma el contrato hay una carta Gantt y luego el cliente no se peude contactar, cambiaron a la gente, se fueron de vacaciones, están en reuniones en el extranjero y eso va a tomar meses, etc. La cantidad de problemas es infinito porque la carta Gantt afecta tus entregas, no las de ellos, en el contrato no está bien especificado lo que ellos quieren, parte de tu pega es descubrirlo.

¿Se te hace conocido?

Luego vienen las multas por retraso, que hacen que al cliente algunos proyectos le salgan gratis.

Y si entregas a tiempo, eso hace que el cliente no te quiera más, porque cobraste el cheque completamente. Eso les huele a traición.

Como está organizado todo, suerte con eso de hacer proyectos ágiles.

En el caso de XP, la lógica era que en Silicon Valley las empresas tratan de captar individuos… como Google… una vez que captaste individuos, las puertas de los inversionistas de riesgo están abiertas de par en par, y se calcula cuál es tu potencial económico basado en el número de personas que podría llegar a usar tu producto multiplicado por lo que esa persona potencialmente vale para tu empresa.

Estamos hablando de miles de millones de dólares.

Eso implica que los inversionistas consideran quedarse con el 1% de tu empresa a cambio de 1 millón de dólares y consideran que es un excelente negocio.

Una empresa que ya está en ese proceso y tiene unos 5 millones de dólares, tal vez más, decide contratar a tu equipo ágil. Tú cobras 4 veces lo que vale cada empleado y armas tu equipo, multiplicando tu dinero inicial por 4, mes a ames. No es dificil de imaginar.

Ganancia = 3 veces los que invertiste el mes 1. No está mal.

De hecho como negocio, te diría que ahí no está el negocio. Es cosa de ver lo que pasó con los XPers.

Con Scrum hubiera pasado lo mismo si no hubieran creado la certificación de CSM: Certified Scrum Master.

Estoy de acuerdo contigo respecto del refactoring. Mencionas la técnica de refactoring, pero creo que te falta algo muy importante ¿qué estamos tratando de lograr con el refactoring?

Para mi gusto: aplicar patrones de diseño para lograr que el código sea SOLID. Ese es como el nivel más bajo. En realidad la búsqueda interesante es que el c´digo esconda los mecanismos en bibliotecas, ya que los mecanismos pueden cambiar, pero lo importante es que el código de tu proyecto diga el qué, mientras las bibliotecas dicen el cómo, lo que es muy probable que cambie.

Alan Kay lo lleva al extremeo y dice que debemos programar sólo el qué y que el lenguaje debe automáticamente encontrar el cómo, da incluso ejemplos y muestra cómo funcionan:

Lo que dices respecto de OOP, me pasó hasta el año 2000, a partir de entonces me encuentro con que la gente ya sabe OOP en Java, quizás no en PHP porque PHP no es OO, hasta dónde yo sé.

Lo que tienes que hacer es enseñarles JUnit y refactoring y pair programming y mocks y BDD, etc. Dale un par de semanas para cada uno de ellos.

Guillermo,

Me parece muy valioso lo que dices, sería ideal poder escuchar tu experiencia en persona, por lo pronto voy a asistir al Socrates y a lo mejor podemos conversar ahí.

Saludos,
Hans

Hans,

Sería interesante.

Nos vemos,
Guillermo.