Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Ingeniería de Software. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Ingeniería de Software. Mostrar todas las entradas

sábado, abril 12, 2025

¿El fin de la Ingeniería de Software como la conocemos?

🧠 ¿El fin de la Ingeniería de Software como la conocemos?


Hace unos días mi amigo Jorge Abad publicó en sus Lecciones Aprendidas un artículo premonitorio, se trata de su De lo complejo a lo simple: Cómo la IA está reinventando el desarrollo de software. En este, Jorge sostiene que la llegada de la inteligencia artificial ha transformado el proceso de desarrollo de software, llevando ciertas tareas de un entorno de alta complejidad –como era tradicionalmente– a un dominio en el que, gracias a la automatización, se puede hablar de mayor simplicidad. Invoca el marco de Cynefin, de Dave Snowden, para clasificar los problemas en simples, complicados, complejos o caóticos, y sugiere que, con la IA, el desarrollo se mueve hacia lo “simple” o al menos hacia lo “complicado” y predecible.

Pueden leer el artículo completo aquí:

Lecciones Aprendidas por Jorge Abad: De lo Complejo a lo Simple: Cómo la IA Está Reinventando el Desarrollo de Software

El artículo sirvió de base para una sesión de Castor sin filtro (del viernes 12 de abril de 2025) con Juan Andrés Ochoa y compañía, donde discutimos animadamente el asunto. Uno de mis puntos de debate fue otra presentación también de hace pocos días de Jan Bosch, director del Software Center, una colaboración estratégica financiada por socios entre más de 15 grandes empresas europeas (incluidas Ericsson, Volvo Cars, Volvo Trucks, Saab Defense, Scania, Siemens y Bosch) y cinco universidades centradas en la digitalización, que diera en The Future of Software Conference celebrada en Londres y donde expuso sus ideas sobre el estado actual y futuro de la ingeniería de software, destacando la rápida evolución de la ingeniería de software y del mundo en general.

Pueden ver la conferencia de Bosch en

The end of Software Engineering (as we know it) | Jan Bosch | Chalmers University of Technology

Pero antes de contarles en qué estoy de acuerdo con Bosch y en qué no, haré un resumen sucinto de su charla. Bosch contrasta el modelo tradicional de ingeniería de software —basado en requisitos, diseño, codificación y despliegue (que suena a cascada)— con una nueva dinámica donde los agentes de IA interpretan intenciones humanas, las traducen en requisitos, arquitecturas y código, reduciendo drásticamente el rol humano en la programación directa. Empresas como la alemana con la que Bosch trabajó ya han reemplazado desarrolladores por arquitectos de software que dirigen agentes de IA.

Bosch critica fuertemente la eficacia actual de la ingeniería de software. Con datos empíricos, aunque antiguos, afirma que entre el 50 % y 66 % de las funcionalidades desarrolladas nunca se usan, representando un despilfarro enorme. Esto era cierto hace más de dos décadas y una observación heurística nos puede mostrar que sigue siendo así o peor. Más grave aún: entre el 70 % y 90 % del presupuesto de I+D se destina a funcionalidades commodity que los clientes dan por sentadas. Bosch ilustra el problema con su modelo de tres capas: funcionalidad commodity, diferenciadora e innovadora. La mayor parte del esfuerzo se destina a la primera, con poco impacto en valor.

La causa central de esta ineficiencia, según Bosch, es la dependencia de "requisitos" en lugar de "resultados deseados". Propone una transición hacia un modelo basado en resultados cuantificables, donde cada funcionalidad se justifique por su impacto en KPI de negocio. Modelos como HYPEX y técnicas como el A/B testing permiten medir el impacto de pequeños incrementos funcionales antes de invertir completamente en ellos.

En paralelo, Bosch propone una madurez progresiva hacia organizaciones guiadas por IA. Describe cinco niveles: desde el uso puntual de herramientas como ChatGPT, pasando por la automatización de procesos, hasta organizaciones completamente rediseñadas con un enfoque "AI-first", donde agentes superan en productividad a equipos humanos enteros. En productos también se refleja esta transformación. Las etapas van desde el uso de IA como soporte, hasta productos completamente autónomos y autorregulados mediante aprendizaje por refuerzo.

Finalmente, concluye que la ingeniería de software actual es poco efectiva y necesita una reinvención radical. Reemplazar requisitos por resultados y adoptar la IA tanto en el producto como en el proceso de desarrollo son, para él, pasos imprescindibles. Más allá del entusiasmo técnico, Bosch hace un llamado a que ingenieros, Product Managers y líderes organizacionales asuman con responsabilidad esta transición urgente.

Puntos de acuerdo

1. El modelo tradicional está quedando atrás

Bosch argumenta que la cadena tradicional —donde se parte de los requisitos para llegar al despliegue— resulta insuficiente ante la velocidad y la incertidumbre del mercado actual.

Acuerdo: Es evidente que en muchos entornos, el enfoque lineal ya no permite responder de manera ágil a los cambios en los requerimientos del negocio ni a la complejidad de los sistemas modernos. De hecho, hace muchos años dejamos de hacerlo así en pro de un enfoque iterativo e incremental, de experimentación y prototipado rápido.

2. La revolución de la inteligencia artificial

La irrupción de herramientas y agentes inteligentes en el desarrollo de software abre la puerta a automatizar tareas que antes eran exclusivamente humanas.

Acuerdo: La utilización de LLM, agentes especializados y técnicas de aprendizaje por refuerzo ya está transformando la manera en la que concebimos el desarrollo, mejorando la eficiencia y permitiendo experimentar con nuevos modelos de negocio. En este sentido ver el artículo Experimentum Entre la eficiencia y el despojo: La inevitable mutación del desarrollo de software por la IA en el que analizo el más reciente reporte DORA sobre el impacto de la Gen AI en el desarrollo de software.

3. Desperdicio de funcionalidades

Según Bosch, una gran parte de las funcionalidades desarrolladas acaba siendo infrautilizada, lo que implica un desperdicio considerable de recursos.

Acuerdo: La realidad en muchas empresas respalda este punto: se invierte tiempo y dinero en features que, en última instancia, no aportan el valor esperado al cliente.

4. El cambio de requisitos a resultados

El enfoque en resultados de valor —o como les gusta a muchos: “outcomes”—, más allá de cumplir con un conjunto predefinido de requisitos, representa un cambio de paradigma fundamental.

Acuerdo: En un mundo donde la agilidad y la medición de impacto son esenciales, orientar el desarrollo hacia objetivos medibles permite alinear mejor las inversiones de I+D con los resultados de negocio.

5. La necesidad de una Ingeniería de Software madura

La transformación digital exige una mayor integración entre tecnología y negocio, elevando el rol de la ingeniería de software a un nivel estratégico.

Acuerdo: La apuesta por modelos iterativos, basados en la experimentación y en la medición de resultados clave, es una tendencia que ha demostrado su eficacia en empresas líderes.

Puntos de desacuerdo o matización

1. La desaparición del código humano

Bosch sugiere que pronto los agentes de IA podrían eliminar la necesidad de codificar manualmente.

Desacuerdo: Aunque la automatización avanza, los agentes aún carecen de un entendimiento profundo del contexto y las implicaciones éticas o sistémicas, por lo que el juicio humano sigue siendo crucial, especialmente en aplicaciones complejas y reguladas.

2. Transformación del rol del ingeniero

El discurso de Bosch tiende a minimizar el rol de los desarrolladores tradicionales.

Matización: Más que desaparecer, el rol del ingeniero se transformará. Los profesionales pasarán a actuar como orquestadores, validadores y supervisores de sistemas automatizados, aportando su criterio en áreas como la ética algorítmica y la experiencia de usuario.

3. Subestimación de los factores culturales y organizacionales

El cambio hacia modelos AI-first implica no solo una actualización tecnológica, sino también una revolución cultural en las empresas.

Desacuerdo: La resistencia al cambio y la necesidad de transformar estructuras organizativas son aspectos complejos que requieren una adaptación gradual y el compromiso de todos los niveles jerárquicos.

4. Enfoque exclusivamente económico

Medir el éxito de cada sprint en términos estrictamente económicos puede resultar reduccionista.

Matización: es muy importante cuantificar el retorno de inversión, pero también debemos tener en cuenta intangibles como la experiencia de usuario, la reducción de la deuda técnica y el aprendizaje continuo, que a largo plazo generan valor y competitividad.

5. Un discurso algo alarmista

La crítica a la “atrocidad” en la eficacia de la ingeniería actual puede resultar desalentadora para quienes trabajamos día a día en mejorar procesos y productos.

Desacuerdo: Aunque es vital reconocer las ineficiencias existentes, es igualmente necesario reconocer los avances que ya se han conseguido y fomentar una cultura de mejora continua, donde los retos se aborden de forma colaborativa y constructiva.

Mis conclusiones

Han pasado dos décadas desde que publiqué mis dos primeros libros Asuntos de la Ingeniería de Software Volumen I y Volumen II, pero tanto el artículo de Jorge, como la presentación de Bosch nos desafían a repensar la forma en que concebimos y practicamos la ingeniería de software. Sus propuestas, basadas en el aprovechamiento de la IA y en el enfoque en resultados, ofrecen una hoja de ruta para transformar radicalmente el sector. Sin embargo, la implementación de estos cambios debe considerar cuidadosamente la responsabilidad permanente del factor humano, la complejidad de las transformaciones culturales y la necesidad de una visión equilibrada que vaya más allá de los criterios económicos.

Comparto la urgencia de evolucionar hacia modelos más ágiles y eficientes, que resuelvan los problemas actuales y futuros de los usuarios (y clientes) y que solucionen de una vez por todas y para siempre los males del mundo, de lo contrario habremos fallado como humanidad; pero también reconozco que la innovación debe ir acompañada de un enfoque pragmático y humano, así que aún debemos afinar la integración de la IA en nuestra práctica diaria para convertirla en ese continuum que necesitamos y no solo reaccionar a los picos virales (“hype”) a los que nos tienen acostumbrados como este último de la “ghiblilización” o el anterior de DeepSeek.

Seguiré creyendo que el inminente final de la ingeniería de software tal como la conocemos no es un cierre, sino el amanecer de una era donde la perspicacia humana se fusionará con la inteligencia artificial: ya no escribiremos software, esculpiremos futuros, transformando lo imposible en nuestra nueva realidad digital. ¿Qué opinas? Déjamelo saber en el foro.

martes, abril 01, 2025

Entre la eficiencia y el despojo: La inevitable mutación del desarrollo de software por la IA

 

Entre la eficiencia y el despojo: La inevitable mutación del desarrollo de software por la IA


Alerta de espóiler: este artículo se basa y contiene datos e imágenes del más reciente reporte DORA sobre el impacto de la Gen AI en el desarrollo de software.

El reciente reporte sobre “The Impact of Gen AI in Software Development” ofrece una visión amplia y matizada sobre la transformación que la inteligencia artificial generativa (IA) está provocando en el mundo del desarrollo de software. El informe no solo destaca los beneficios tangibles y las oportunidades que surgen al integrar estas tecnologías en el ciclo de desarrollo, sino que también plantea desafíos, paradojas y riesgos que deben abordarse de forma estratégica. Así que vamos a analizar los aspectos positivos, negativos y las áreas de incertidumbre (“lo bueno, lo malo, lo feo”) que emergen del estudio, para finalmente responder una pregunta: ¿qué dirección pueden tomar las organizaciones respecto a la adopción de IA en el desarrollo de software?

Entremos en materia.

Lo bueno: Beneficios para los desarrolladores y la organización

Uno de los principales hallazgos del reporte es que la adopción de IA se asocia con mejoras en la productividad, el flujo de trabajo y la satisfacción laboral de los desarrolladores. El medir el impacto en el éxito y el bienestar individual, se encontró que un incremento del 25 % en la adopción de IA se vincula con aumentos en la productividad, mayor frecuencia en el estado de “flow”, es decir, los desarrolladores experimentan más momentos de concentración intensa y productividad continua en su trabajo, y un incremento en la satisfacción con el trabajo. Estos beneficios se deben, en parte, a lo que sabemos: la IA permite automatizar tareas repetitivas y liberar tiempo para que los desarrolladores se concentren en actividades más creativas y de mayor valor, como la resolución de problemas complejos, lo que genera una experiencia laboral más fructífera.

Article content
Figura 1: Impactos de la adopción de IA en el éxito y el bienestar individual. Fuente: DORA Impact of Gen AI in Software Development Report.

En el perímetro organizacional, la adopción de IA también tiene impactos positivos evidenciados en mejoras en la calidad del código, la velocidad de revisión y aprobación, y la optimización de la documentación. Al aumentar el uso de IA, se logra un incremento de aproximadamente un 7.5 % en la calidad de la documentación y mejoras de entre 1.3 % y 3.4 % en la calidad del código y los procesos de revisión. Estas mejoras no solo permiten reducir la deuda técnica y la complejidad del código (aunque de manera modesta, con reducciones del -0.8 % y -1.8 % respectivamente), sino que también posibilitan una respuesta más rápida en la identificación y corrección de errores, lo que puede contribuir a una mayor eficiencia en el ciclo de desarrollo.

Son datos que evidencian las hipótesis que teníamos en cuanto a la innovación: la capacidad de generar código a gran escala y de forma automatizada fomenta la experimentación y la adopción de nuevas formas de hacer las cosas, lo que a largo plazo puede impulsar la competitividad de las organizaciones en los mercados actuales.

Article content
Figura 2: Impactos de la adopción de IA en el código producido. Fuente: DORA Impact of Gen AI in Software Development Report.

Datos, datos, datos

A continuación, presentamos una tabla que resume algunos de los hallazgos clave del reporte, junto con la métrica asociada y una calificación del impacto:

Hallazgos e Impacto de la IA en el Desarrollo de Software
Fuente: DORA Impact of Gen AI in Software Development Report

La tabla sintetiza los datos más relevantes del informe, permitiendo identificar claramente las áreas en las que la adopción de IA genera beneficios, así como los aspectos que requieren atención o mitigación.

Lo malo: Desafíos y paradojas en la integración de IA

Uno de los hallazgos más sorprendentes es la disminución del tiempo dedicado a tareas que los desarrolladores consideran valiosas, a pesar de la mejora en indicadores como productividad y satisfacción. Esta paradoja, denominada en el estudio como la “vacuum hypothesis”, sugiere que, al aumentar la eficiencia mediante la IA, los desarrolladores terminan completando las tareas de alto valor más rápidamente, lo que se traduce en una reducción del tiempo invertido en ellas. Este fenómeno plantea interrogantes sobre la percepción de valor en el trabajo y sobre si la automatización puede, en ciertos casos, limitar el potencial de profundización o perfeccionamiento de actividades que, de otro modo, aportarían un mayor significado profesional.

Otro aspecto negativo que resalta el documento es el impacto adverso sobre la estabilidad en la entrega de software. Aunque la velocidad de entrega sufre una leve disminución (alrededor de -1.5 %), la estabilidad se ve afectada de manera más significativa (-7.2 %). Esto podría deberse a que la facilidad para generar grandes volúmenes de código mediante IA lleva a la implementación de cambios de mayor tamaño, lo que históricamente se ha asociado a un incremento en los errores y en la inestabilidad del producto final. La adopción de IA, por lo tanto, no garantiza por sí sola una mejora en la calidad de las entregas, sino que exige una atención especial a las prácticas tradicionales de ingeniería, como el mantenimiento de pequeños lotes de cambios y la implementación rigurosa de pruebas automatizadas.

Asimismo, se evidencian riesgos relacionados con la confianza en los sistemas de IA. A pesar de que los desarrolladores que utilizan estas herramientas reportan un aumento en su productividad, la confianza en la calidad del código generado puede ser baja. Ya lo habíamos imaginado mucho antes del reporte: como con cualquier otra tarea en la que usemos la IA, la dependencia excesiva en las sugerencias de la IA sin la adecuada verificación humana podría derivar en problemas de calidad a mediano y largo plazo, afectando no solo el producto final, sino también la reputación y la eficiencia operativa de la organización.

Article content
Figura 3: Impactos de la adopción de IA en el rendimiento y la estabilidad de la entrega. Fuente: DORA Impact of Gen AI in Software Development Report.

Lo feo: Incertidumbres y riesgos estratégicos

Más allá de los aspectos positivos y negativos, el reporte también señala “lo feo” en términos de incertidumbres y riesgos estratégicos que aún deben ser abordados. Uno de estos riesgos es la posible disrupción en el rol de los desarrolladores. La adopción de IA plantea la inquietud de que, a medida que las herramientas se vuelven más sofisticadas, se pueda desvalorizar la experiencia y el conocimiento humano, generando temores sobre el desplazamiento laboral o la reducción de las horas remuneradas. Este escenario, aunque no se presenta como una consecuencia directa e inmediata, exige que las organizaciones desarrollen estrategias para reestructurar el rol del desarrollador, enfocándolo en actividades que complementen la automatización y potencien las habilidades humanas, como la resolución de problemas complejos, la toma de decisiones estratégicas y la innovación.

Otro riesgo es la carencia de políticas claras y consistentes en el uso de IA. El reporte destaca la importancia de que las organizaciones establezcan directrices transparentes sobre el uso y las limitaciones de estas tecnologías. La ausencia de un marco regulatorio interno puede derivar en usos irresponsables o incluso en vulnerabilidades de seguridad, afectando tanto la integridad de los datos como la confianza de los empleados y clientes. La elaboración de políticas de uso aceptable y de estrategias de gobernanza robustas se vuelve, por tanto, un imperativo para minimizar los riesgos y asegurar que la adopción de IA se traduzca en beneficios sostenibles a largo plazo.

Direcciones estratégicas para las organizaciones

Frente a este escenario complejo, ¿qué dirección pueden tomar las organizaciones respecto a la adopción de IA en el desarrollo de software? El reporte sugiere que la clave está en una estrategia equilibrada que combine la innovación tecnológica con la solidez de las prácticas tradicionales de ingeniería.

En primer lugar, es fundamental que las organizaciones adopten un enfoque gradual y responsable. La implementación de IA debe acompañarse de programas de capacitación que permitan a los desarrolladores familiarizarse con las nuevas herramientas, comprendiendo tanto sus potencialidades como sus limitaciones. Al invertir en formación y en la creación de comunidades de práctica, las empresas pueden fomentar un entorno de aprendizaje continuo, donde la experimentación y el intercambio de conocimientos potencien la adopción de la tecnología de forma segura y controlada.

En segundo lugar, es imprescindible establecer políticas claras que definan el uso y los límites de la IA. Estas directrices no solo deben contemplar aspectos técnicos, sino también éticos y de seguridad, garantizando que la automatización no comprometa la calidad del código ni la integridad de los procesos. La transparencia en la comunicación de estas políticas ayudará a mitigar los temores relacionados con la pérdida de empleo o la desvalorización del trabajo humano, reforzando la idea de que la IA es una herramienta que potencia, y no sustituye, las capacidades de los desarrolladores.

Otro aspecto crucial es la integración de la IA en un ecosistema de prácticas de desarrollo sólidas. La experiencia demuestra que la automatización de tareas repetitivas y la generación de código de calidad pueden ser muy beneficiosas, siempre que se mantengan mecanismos de control como la revisión de código, las pruebas automatizadas y la gestión de pequeños lotes de cambios. Estas prácticas permiten compensar los riesgos asociados a la generación masiva de código y aseguran que los beneficios de la IA se traduzcan en una entrega de software más estable y confiable.

Además, las organizaciones deben estar preparadas para replantear los roles y responsabilidades dentro de los equipos de desarrollo. La adopción de IA puede generar la necesidad de nuevos perfiles, como el de “prompt engineer” o especialista en la integración y verificación de herramientas automatizadas. Redefinir las funciones y potenciar la colaboración entre los expertos en IA y los desarrolladores tradicionales permitirá que ambas competencias se complementen, impulsando la innovación y la eficiencia.

Finalmente, es inaplazable que las organizaciones adopten un enfoque basado en la medición continua y la retroalimentación. El reporte enfatiza la importancia de utilizar métricas y sistemas de retroalimentación para evaluar el impacto de la IA en diferentes niveles: individual, de equipo y organizacional. Al monitorear indicadores clave, como la productividad, la estabilidad de las entregas y la calidad del código, las empresas pueden ajustar sus estrategias de adopción de forma dinámica, aprendiendo de la experiencia y corrigiendo el rumbo cuando sea necesario.

El desafío real no es la IA, sino cómo la usamos

Para cerrar, la IA representa una herramienta poderosa que, bien implementada, puede potenciar el rendimiento y la creatividad de los desarrolladores, mejorar la calidad del código y acelerar la entrega de software. Sin embargo, sus beneficios no son automáticos ni exentos de riesgos. Si tu organización quiere estar mejor posicionada para liderar el cambio en el mundillo tecnológico vigente, hazte acompañar para que logres equilibrar la innovación con la disciplina técnica y una visión estratégica orientada a la transformación cultural.

En Experimentum ya lo estamos haciendo.

Puedes descargar el DORA Impact of Gen AI in Software Development Report completo en:

DORA | Accelerate State of DevOps Report 2024

https://dora.dev/research/2024/dora-report/

jueves, junio 16, 2016

Purga ágil de producto




Nuestro backlog del producto puede no tener una “buena salud”. Es decir, puede contener elementos que lo oscurezcan o que disminuyan su transparencia. Por lo general estos elementos tienden a ir hasta el fondo del backlog y muchas veces no son detectados hasta que es muy tarde en el proyecto, trayendo como consecuencia la extensión innecesaria del esfuerzo de desarrollo y la desmotivación del equipo debido a la gran capacidad energética que sus miembros invierten en estos elementos de poco o ningún valor para el producto y para el negocio.
Una de las técnicas que podemos aplicar al backlog y, por consiguiente, al producto, es esta de la purga del producto. Los detalles de cómo hacerlo lo encuentran en mi artículo en Pulse de LinkedIn:

martes, abril 26, 2016

Del triángulo de hierro al triángulo ágil extendido


Las empresas en período de transformación organizacional se enfrentan a la dicotomía de seguir paradas sobre el triángulo de hierro en lo que se refiere a planificación y gestión de proyectos de software o moverse a una zona que en principio se les parece más al Triángulo de las Bermudas que al área de confort por donde han transitado durante las últimas décadas.

De lo más valioso que hemos aprendido en el desarrollo de software es que muchas de las prácticas y técnicas usadas desde aquella histórica reunión del Comité Científico de la OTAN en 1968 en la ciudad de Garmisch, Alemania y que diera inicio a la Ingeniería de Software como profesión, fueron tomadas a manera de préstamo de otras áreas de la ingeniería y de otras ciencias aplicadas.

Algunas de esas prácticas influyeron directamente en la forma de realizar estimaciones y de planificar proyectos de software. Específicamente, hemos aprendido que no podemos estimar ni planificar proyectos de software como lo hacen en proyectos de la industria de la construcción… ¡a no ser que vayamos  a usar piezas de Lego® para construir ciudades!


Afortunadamente ya sabemos con certeza que la ingeniería de software tiene su propia personalidad. Se trata de un sello que la hace única y que hace que sus practicantes se distingan del resto de profesionales de la ingeniería y de otros cuerpos de conocimiento. Por ejemplo, en su libro Agile Project Management, Jim Highsmith[1] sugirió que si aplicamos el enfoque Ágil al Triángulo de hierro encontraríamos los siguientes vértices:
  • Valor, para el usuario en términos de un producto que se pueda distribuir y cuyo uso genere beneficios para la organización.
  • Calidad, para entregar continuamente valor al usuario en términos de un producto confiable y adaptativo.
  • Restricciones, los ya tradicionales alcance, tiempo y costo, en donde, si movemos uno, usualmente el primero, se mueven los otros dos.
Como dice el mismo Highsmith [2], las restricciones siguen siendo parámetros importantes de un proyecto pero no constituyen el objetivo del mismo. En cambio, el Valor y la Calidad establecen la meta del proyecto y las restricciones mencionadas se ajustan a medida que el proyecto incrementa el valor para el usuario. En particular, El tiempo podría seguir siendo una restricción fija pero entonces el alcance debería ajustarse para entregar el valor más alto posible dadas las restricciones impuestas.


Como nos gusta lo visual, esta otra versión del triángulo ágil de Highsmith nos llega más:


Más allá de este enfoque de planificación y de gestión de proyectos (ágiles), quienes ya hemos trasegado algunos años por los vericuetos, subido a los riscos y caminado por los valles complejos del desarrollo ágil de software, sabemos que todo momento es una oportunidad de mejorar: de mejorar como personas y como profesionales, de mejorar los procesos y las técnicas, de mejorar la calidad de los productos y de incrementar el valor que estos entregan a nuestros usuarios. ¡Es la mejora continua!

Ahora bien, la mejora continua junto al valor y a la calidad forma otro vértice del triángulo, el del resultado. A los agilistas no nos interesa simplemente crear un producto, por más disruptivo o benéfico que este sea. Nos interesa pensar en lo que viene, en lo que llevará al cliente al próximo nivel de optimización, satisfacción y felicidad.

Pero lo más importante en todo proyecto, en todo proceso de innovación o mejoramiento, en todo plan que tenga como propósito el diseño y la construcción de productos (de software), son las personas: la comunicación cara a cara entre ellas, la motivación de todos los individuos que intervienen en el proyecto, la atención continua a la excelencia técnica, la autogestión del equipo y la confianza que la organización deposite en ellas se constituyen en las bases del éxito de cualquier iniciativa que requiera generar nuevos productos o servicios.

Las cosas así, podríamos entonces encontrarnos con esta nueva versión del triángulo ágil:



Referencias:

[1] Highsmith es uno de los 17 firmantes del Manifiesto Ágil

jueves, junio 11, 2015

Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo? (V1.6.0)


El ecosistema ágil está formado por un conjunto de organismos “vivos” llamados “marcos de trabajo y prácticas ágiles” (biocenosis) y el medio físico donde se relacionan, llamados Organizaciones (biotopo). Estas últimas están conformadas por personas y estas personas usan distintas clases de biocenosis, es decir, de marcos de trabajo y prácticas ágiles, según sus necesidades.
Como todo ecosistema, el ágil tiene barreras que a veces impiden su normal evolución. Barreras físicas, como la falta de entornos adecuados dentro de las Organizaciones para albergar equipos que respiren “agilidad”. Barreras culturales y hasta emocionales, arraigos y miedos que se dan entre las personas, quienes experimentan temores muchas veces infundados debido a la falta de información o de acompañamiento efectivo por parte de expertos, de conocedores de ese ecosistema ágil en formación.
Pero, ¿cuáles son esos marcos de trabajo y prácticas ágiles? ¿Para qué sirve cada uno de ellos? En esta sesión exploraremos, a manera de introducción, los marcos de trabajo más usados, como ScrumeXtreme Programming (XP), KanbanLean; y algunas de las técnicas necesarias en un primer esfuerzo por implementar la Cultura Ágil en una Organización: User Story MappingProduct Vision BoardUser PersonaUser Stories, TDD, BDD, para mencionar solo algunas.
Y lo más importante, ¿para qué sirve cada uno de estos especímenes ágiles? ¿Alguno de ellos es adecuado para el proyecto que inicio mañana? ¿Varios de estos? ¿Son complementarios? ¿Qué problemas puedo encontrar si elijo mal? Y en el fondo, ¿cuáles son las razones por las que debo permitir el nacimiento y expansión de un nuevo ecosistema aun si el actual me está rindiendo beneficios? Y hablando de utilidades, ¿cuáles puedo obtener al implementar la “agilidad” en mi Organización?

Finalmente, sabemos que los ecosistemas están gobernados principalmente por eventos estocásticos (azar), por las reacciones que estos eventos ocasionan en sus componentes y por las respuestas de los organismos a las condiciones que los rodean. ¿Cómo controlar estos eventos y sobrevivir en el intento? Una mirada Darwiniana nos ayudará a entender cómo, mediante la inspección y la adaptación, nos iremos adecuando a los cambios que ocurren en todo proceso de evolución y entenderemos que la cultura ágil es el siguiente paso en la evolución de la inteligencia.
Nota:
Esta presentación, actualizada, la hice durante el Primer Agile Open Space en la ciudad de Pasto, Colombia, el 6 de junio de 2015.
Nivel: Principiante

Título: Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo?

Resumen:

Uno de los impedimentos más grandes a la hora de implementar Ágil se origina en el desconocimiento que tienen las personas sobre lo que harán a continuación. ¿Por cuál de los marcos de trabajo o prácticas empiezo? ¿Uno solo es suficiente? La respuesta corta a esta última pregunta es “no”. Entonces, ¿qué debo saber para dar el salto de aquí hasta ágil? ¿De qué me “agarro” para no caer en el abismo? Estos son los asuntos que abordaré en esta sesión introductoria.
Con definiciones simples y ejemplificadas, basado en hechos históricos de los cuales he sido protagonista, le contaré a la audiencia de qué se trata toda esta jerigonza ágil, a manera de Gazafatonario.

Esta es la presentación completa y el enlace para descargar:


miércoles, mayo 13, 2015

Ágil es algo que eres

Foto de http://pixshark.com
Para implementar una verdadera Cultura Ágil se requiere un nivel más alto de confianza de lo que es necesario en los enfoques tradicionales.  Responsabilidad y transparencia son dos de los beneficios clave de tener una Cultura Ágil. Más sobre Cultura Ágil en “Cultura Ágil: ese oscuro objeto del deseo
Para alcanzarla, para establecer una verdadera Cultura Ágil, debemos revisar las ideas que tenemos de los enfoques tradicionalistas e iniciar un camino que quizás sea o se vea poco confortable para muchos en la organización, puesto que ese camino hacia la cultura ágil expone las debilidades existentes no solo en la estructura sino en el comportamiento organizacional, es como si el ojo del Gran Hermano se posara sobre todos los miembros de la organización y les permitiera observarse a sí mismos, como en un espejo virtual, y al resto del entorno: clientes, proveedores, socios de negocio y mercado potencial, a observarlos desde el exterior.
Por ejemplo, respuesta ante el cambio sobre seguir un plan, uno de los valores del Manifiesto Ágil, es apenas una de las divergencias filosóficas cardinales entre los enfoques enraizados desde siempre en el desarrollo de software y esta visión emergente que significa ser ágil. Sobre este valor en particular, pueden leer mi artículo relacionado aquí. Más sobre el Manifiesto ágil en este enlace.
La Cultura Ágil es un continuum:
  • Empieza con la persona, se irradia primero hacia los equipos y luego a toda la organización, y termina en la persona.
Cuando hablamos de los productos, además de los atributos de excelencia que deben tener, es relevante interiorizar que:
  • El responsable de la calidad de un producto es Todo el Equipo Ágil. Además, una vez que el equipo entregue el producto, que este deje la sala de desarrollo, es porque está preparado para salir a producción.
  • Un error, una falla, no se ve como un evento crítico sino como una oportunidad de aprender acerca de los componentes del producto (el código, por ejemplo), del proceso y de cada uno de los miembros del equipo.
En su libro, “Being Agile”, Mario Moreira nos dice que “crear o adoptar una cultura ágil no se hace por accidente” y yo agrego: tampoco se hace por decreto. Moreira enumera algunas actividades que te ayudarán a moverte a una cultura ágil:
  • Reconocer que moverse a Ágil es un cambio cultural
  • Compartir los Valores y Principios Ágiles (continuamente)
  • Establecer y compartir objetivos y motivaciones
  • Obtener retroalimentación continua de los empleados. (Podemos extrapolar esto a conseguir retroalimentación de los socios de negocio, de los clientes, de los proveedores, es decir de todo el ecosistema organizacional)
  • Adaptar el sistema de recompensas para alinearlo con la nueva cultura
  • Identificar técnicas para ayudar a mitigar la resistencia de manera agradable
  • Evaluar a la administración y ver si los empleados tienen una personalidad que les permita alinearse con la nueva cultura
  • Comenzar a vivir los valores y principios que te ayuden a alcanzar la cultura que estás buscando
  • Proporcionar mecanismos de comunicación que se alineen con la cultura que quieres
  • Identificar y aplicar los procesos, métodos, prácticas y herramientas ágiles que estén alineados con tus objetivos
  • Aplicar un enfoque de inspeccionar y adaptar para medir el progreso
Debo insistir en que la vía hacia una transformación ágil, más que adopción, es un salto en la evolución, en el sentido de los saltos que ha dado la naturaleza durante millones de años, solo que aquí no tenemos tanto tiempo, pero un cambio de este nivel puede llevar un quinquenio, quizás una década, sobre todo para organizaciones que llevan 30 o 40 años usando enfoques y técnicas tradicionales.
Es decir, no se trata simplemente de cambiar un proceso por otro e institucionalizarlo, no se trata estrictamente de pasar de “manual” a “automatizado”, o de ir de integración bajo demanda a integración continua. Estas apenas son señales de que “lo estás haciendo ágil” y, en últimas, ágil no es solo algo que haces, ágil también es algo que eres.
-----------------------------------------------------------------------------
*La imagen interior es de [http://kidskidskids.tumblr.com/]