Hace unos meses, hablando con Rufino Contreras, de Computing, me comentó la idea de escribir un artículo sobre “Agilidad” para dicha revista, pensando siempre en que el lector objetivo del mismo fueran directivos, CIOs, CEOs y similares, que, en muchas ocasiones, por desgracia, son desconocedores que lo que el movimiento ágil está suponiendo para el mundo tecnológico.
Me puse manos a la obra y, dándolo todo (como siempre), escribí de manera altamente sintetizada las dos hojas que puedes descargar íntegramente en pdf aquí o que puedes leer sin descargar al final de este post, y que, si quieres aún más resumidas, repasan, siempre sin olvidar el publico al que se orienta el artículo, desde los problemas históricos de querer encajar la creación de tecnología en modelos de creación de “carreteras”, “edificios” o “industria”, qué es la agilidad, pasando a entrar en las grandes áreas que todo buen desarrollo tecnológico ágil, y no ágil, debe contemplar: el equipo humano, el proceso y la calidad del producto.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
Hola, me parece un buen articulo, entre otras cosas por pensar en que también es importante que entendamos que es el desarrollo ágil los que estamos en el mundo de software, pero en «negocio», muchas veces incomprendidos y infravalorados.
Des de el punto de vista de desarrollo esta forma de trabajar me parece fantástica. Incluso desde el punto de vista de la empresa también. De hecho, los proyectos internos que llevamos a cabo los hacemos así. Pero no podemos decir lo mismo de los proyectos para clientes.
El principal problema es que cliente acostumbra a tener un objetivo a cumplir, necesidad a satisfacer, problema a solucionar, etc. y un presupuesto limitado (como todos). Por lo tanto, no queda mas remedio que tanto el software como los costes estén acotados. Para acotarlos, se ha de hacer un importante trabajo de toma de requisitos y valoración previa.
Como podemos compaginar entonces estas dos problemáticas con el desarrollo ágil? Ahora mismo solo se me ocurre vender un proyecto como provisión de fondos, con una valoración estimada, pero en ningún caso cerrada. Con los vicios que este sistema también trae, tipo cárnica.
Bueno, espero poder compartir impresiones!
Buenas tardes a todos,
Primero felicitar a Javier, un gran artículo orientado a quien está orientado. Un primer párrafo impactante, y posteriores párrafos describiendo los puntos más importantes de una práctica ágil. Me gusta el de “Qué es la agilidad” y “el la deuda técnica”, concepto este último muy importante y al que casi nadie le da importancia.
Álvaro, pdte te conteste Javier, me parece que te pasa lo que a muchos que hemos desarrollado con metodologías basadas en cascada y nos cuesta “cambiar” el chip a esta nueva cultura / valores. Javier dice en alguno de sus artículos que hay proyectos más “propicios” a ser gestionados con cascada y otros con agilidad. Es dicha decisión basada en diferentes variables / características la que debe determinar el “método” para desarrollar el proyecto. Lo que desde luego es imprescindible que tu cliente y que la dirección de Tecnología entienda las ventajas / características de cada “método”. Tienes que implicar a dichos roles en la decisión del “método” a usar. Una vez entendidas las ventajas / características de cada método, creo en mi humilde opinión, la decisión es mucho más sencilla.
Saludos a todos. Gabriel
Buenas tardes Gabriel.
Precisamente considero que Javier contesto con otro gran articulo hace unos dias, que abordaba esta cuestion, titulado «Clausulas Agiles para contratos tradicionales».
Algunos vemos las ventajas de este tipo de metodologia de trabajo, y como comento, la utilizamos para proyectos internos propios, pero es muuuuuy complicado con cliente, y segun cuales mas.Pero como bien dices, hemos de hacer mucha pedagogia, que bien explicado se comprenden los beneficios para ambas partes. Una de las formulas intermedias que intentamos aplicar es una formula mixta, de precio cerrado, pero ademas con una bolsa de horas para «imprevistos» (si hay algo previsible, es que habra imprevistos).
Seguiremos intentando todo lo posible para poder hacer los proyectos de software cada vez mejor, cumpliendo con los objetivos del cliente, adaptandonos a sus recursos, y por supuesto, rentables!
Gracias y saludos