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.

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/]

lunes, mayo 04, 2015

Libro: ‘La práctica de inteligencia de negocios: guías para lograr proyectos exitosos’

“El escritor escribe su libro para explicarse a sí mismo lo que no se puede explicar.”
[Gabriel García Márquez, escritor colombiano]

Siempre me da mucho placer realizar este tipo de anuncios. Conozco a Mauricio hace casi dos décadas y hemos tenido la oportunidad de trabajar juntos en distintos proyectos, incluyendo algunos de Inteligencia de Negocios, y de compartir más allá de la práctica profesional. Sé de su pasión por la lectura, por los hechos de la Historia y conozco también del esfuerzo monumental que es escribir y más si se trata de un libro como este. Por eso sé que para Mauro escribir este volumen se convirtió en una osadía, pero finalmente está aquí, el fruto de muchísimas horas de desvelo y estudio.

En el libro, Mauro nos embarca en una lectura amena que inicia con los conceptos generales de la práctica de la Inteligencia de Negocios, pasando por el propósito y los elementos de la práctica, los métodos y las herramientas usadas, lo que él llama ‘la hoja de ruta de un proyecto de Inteligencia de Negocios’ y dedica capítulos enteros a temas vitales como las pruebas y la calidad del producto, el despliegue, gestión de cambios y actividades posteriores a la implantación, hasta llegar a la infraestructura requerida en los proyectos de inteligencia de negocios.

De todo esto, el capítulo VI es mi favorito, porque habla de las personas y de la relación cliente – proveedor, asunto natural cuando se trata de una organización orientada a los servicios de tecnología de la información. Mauro habla de los roles principales a tener en cuenta cuando se trata de tener éxito en los proyectos y en particular dedica una sección a los roles típicos en las organizaciones con iniciativas de Inteligencia de Negocios.

Y a través de todo el texto, Mauro también aborda el tema de cómo se implementan todos estos elementos con métodos y prácticas ágiles como Scrum. De tal suerte que este es un compendio sensato de lo que cualquier interesado, persona u organización, debe tener en cuenta al momento de llevar a cabo proyectos de Inteligencia de Negocios.

Contraportada de 'La práctica de inteligencia de negocios' de Mauricio Cotes
Una de mis partes favoritas en todo el libro tiene que ver con el uso de las metodologías. El pensamiento de Mauro no se circunscribe a un método en particular, permitiendo la elección al lector. Eso es excelente, porque no entra y no promueve  o siembra elementos dogmáticos en el texto, es una apertura sistémica.

De hecho, su ‘conclusión en relación con el uso de las metodologías’ es algo que no solo es aplicable a proyectos de Inteligencia de Negocios. Mauro nos dice:
 “Finalmente, es ideal que el proveedor tenga la posibilidad de configurar la metodología de manera tradicional o ágil dependiendo de las condiciones, premisas y la negociación hecha con el cliente. El cuerpo metodológico seleccionado debe ser configurable, debe estar documentado, los practicantes deben aprehenderlo y ser conscientes del propósito de cada uno de los elementos que lo constituyen.
Los practicantes de los roles encargados de la contratación y negociación deben tener en cuenta las premisas mencionadas y ofrecer la modalidad apropiada de trabajo según el caso.”
En definitiva, en ‘La práctica de inteligencia de negocios’, Mauro saca a relucir sus veinte años de experiencia en el tema. Es un libro escrito desde la pragmática del autor, con el suficiente soporte teórico, pero sobre todo, con la idiosincrasia nuestra, la del trópico, con la visión de nuestra economía y de nuestra forma de hacer proyectos, lo que lo convierte en un documento valioso para cualquier estudiante y profesional y para cualquier organización que piense en serio acerca de la práctica de la inteligencia de negocios.

Es un trabajo minucioso, que te ha costado encorvarte durante muchísimas y largas horas, pero finalmente tú y todos nosotros tenemos la mejor recompensa: un sumario de todo tu fogueo en el asunto. ¡Enhorabuena, Mauro, felicidades por este gran logro!

¿Quieres conseguir el libro?

Escríbanle un mensaje electrónico a Mauro a la dirección: rmcotes@hotmail.com. Él les dará más detalles de cómo obtenerlo.

jueves, abril 23, 2015

Sobre medir y controlar o de cómo Tom DeMarco admitió su equivocación

“El Control conduce al cumplimiento; la autonomía conduce al compromiso”
Daniel H. Pink (Autor de “A Whole New Mind: Why Right-Brainers Will Rule the Future”)

Imágen tomada del artículo de Computer.org
En 1982, Tom DeMarco escribió su renombrado libro “Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982). La primera frase del libro, su primerísima idea, quedó ensamblada en los anales de la industria de software durante las siguientes décadas y nos ha llegado intacta hasta esta era. Se trata de su: “No puedes controlar lo que no puedes medir”.

Este pensamiento influyó de manera certera en los modelos de calidad, procesos de producción, enfoques de mejora* y herramientas de construcción de software, quizás como ninguna otra idea de aquellos tiempos. Pero incluso Tom DeMarco cambió de opinión. En 2009 publicó este artículo en la IEEE Computer Society: “Software Engineering: An Idea Whose Time Has Come and Gone?”  (Ingeniería de Software: ¿una idea cuyo momento ha pasado?)” que pueden encontrar haciendo clic aquí.

En el artículo, DeMarco reflexiona sobre si este consejo era correcto en ese momento, sobre si todavía era relevante (al momento de escribir ese artículo en 2009) y que si todavía creía que las métricas eran un deber ser para cualquier esfuerzo exitoso de desarrollo de software. Sus propias respuestas fueron unos tajantes no, no y no.

Es bien conocida la historia de que los enfoques rígidos más tradicionalistas adhirieron completamente a este precepto y crearon áreas de proceso y de conocimiento dedicadas en su totalidad al establecimiento, gestión y control de métricas en los proyectos (de software). A partir de allí, se empezó a medir el éxito o fracaso de los proyectos, en principio, con tres de esas medidas: el tiempo, el presupuesto y la calidad, siendo esta última un poco más abstracta y más subjetiva si se quiere. Después, con muchas otras que no vale la pena mencionar aquí.
Esa institucionalización de métricas derivó a su vez en algo que con el tiempo se convirtió en uno de los mayores desincentivos para quienes trasegamos por los laberintos azarosos de la construcción de productos de software: el trabajo intensivo, esas largas jornadas de trabajo de doce, dieciséis y más horas diarias durante largos períodos de tiempo previos a la entrega del producto. Mi amigo y colega Jorge Abad dice en su blog Lecciones-Aprendidas.info que eso trajo como consecuencia la destrucción de hogares, de familias enteras y yo le creo.

Esta forma de trabajo extrema, cuya consecuencia principal, además de la citada por Jorge, era la de un bajón en productividad, acompañado de una entrega de producto con mala o malísima calidad, con el tiempo degeneró en algo mucho más grave que es de todos conocido: desmotivó a las nuevas generaciones a estudiar carreras relacionadas con la TI: Ingeniería Informática, de Sistemas, de Software y afines. El mismo Tom DeMarco (¡otra vez!) enunció en su otro libro, “Peopleware : Productive Projects and Teams” (2ª edición, 1999), que “no trabajamos horas extras en demasía para terminar el trabajo a tiempo sino para protegernos de culpa cuando inevitablemente no conseguimos hacer el trabajo a tiempo.” En efecto, lo hacíamos simplemente para cumplir, no para ser más productivos, ni para mejorar la calidad del producto. Y a eso nos llevó la fuerza ejercida por el modelo de Comando y Control y de la medición de cosas que no reflejaban la realidad del proyecto, al menos no la realidad de las personas que ejecutaban el proyecto.

La reflexión de DeMarco en el artículo que ya he citado termina también de manera asombrosa para quienes seguimos sus cánones durante casi tres décadas: “Consistencia y predictibilidad aun son deseables, pero nunca han sido las cosas más importantes. En los últimos 40 años, por ejemplo, nos hemos torturado con nuestra incapacidad de terminar proyectos de software a tiempo y en el presupuesto. Pero esta nunca ha sido la meta suprema. La meta más importante es transformación, creando software que cambie el mundo o que transforme una compañía o cómo esta hace negocios.”

Bien sabemos ya que lo más importante en los proyectos de software es la entrega continua y frecuente de Valor al negocio, desde el inicio del proyecto. Y que nunca más apostaremos o usaremos artes adivinatorias para establecer la fecha de entrega, ni qué parte del producto entregaremos en ese momento, ni cuánto será su costo. En cambio, empezaremos con planes y alcance iniciales y nos enfocaremos en la revisión continua de esas restricciones a medida que vamos avanzando. Finalmente, nuestra meta será siempre entregar el mejor producto posible, teniendo presente que ningún método con el enfoque de receta de cocina (léase métodos tradicionalistas) hará mejor lo que es mejor. Esta es la filosofía ágil.

Coletilla

Aquella aciaga prescripción de DeMarco sobre lo que se puede medir y controlar derivó en procesos rígidos, tradicionalistas, que dieron poder solo a algunas personas en la organización; pero lo realmente hermoso, lo humanamente divino, es que los métodos y las prácticas ágiles dan poder a todo el mundo… o a nadie.



--------------------------------------------------
* Por ejemplo, H. James Harrington, reconocido autor de libros sobre mejora de procesos, calidad, desempeño y gestión del conocimiento, y fundador del laureado Instituto Harrington, extendió el pensamiento de DeMarco, diciendo: “Medir es el primer paso hacia el control y eventualmente hacia la mejora. Si no puedes medir algo, no puedes entenderlo. Si no puedes entenderlo, no puedes controlarlo. Si no puedes controlarlo, no puedes mejorarlo.”

miércoles, noviembre 05, 2014

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

 Ecosistema de Métodos y Prácticas Ágiles (Parcial)
Ecosistema de Métodos y Prácticas Ágiles (Parcial)
El ecosistema ágil está formado por un conjunto de organismos “vivos” llamados “métodos 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 métodos 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 métodos y prácticas ágiles? ¿Para qué sirve cada uno de ellos? En esta sesión exploraremos, a manera de introducción, las metodologías más usadas, como Scrum, eXtreme Programming (XP), Kanban, Lean; y algunas de las técnicas necesarias en un primer esfuerzo por implementar la Cultura Ágil en una Organización: User Story Mapping, Product Vision Board, User Persona, User 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 fue la presentación que hice durante el marco de las VII Jornadas Latinoamericanas de Metodologías Ágiles - Ágiles 2014, en Medellín, Colombia. Del 23 al 25 de octubre de 2014.
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 métodos 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.

La presentación completa la pueden descargar aquí:




lunes, junio 02, 2014

Libro: Asuntos de la Ingeniería del Software- volumen II

Portada del libro
Portada del libro
Este no es el primer libro sobre temas de la Ingeniería de Software y está lejos de ser el último; acaso sea el primero en español escrito sobre las bases de nuestra propia práctica de campo, en nuestra propia economía, con nuestra propia idiosincrasia, aunque con el suficiente equipaje teórico proveniente de la academia y de los expertos en los temas citados.
Escribí el libro originalmente como una serie de artículos en mi Gazafatonario IT y cada artículo siempre tuvo su fuente precisamente en tres aspectos primordiales: la industria del software (y por Industria quiero decir Intergrupo), la academia (léase la Universidad) y los especialistas en distintas áreas de la ingeniería de software.
El libro cubre algunos de los temas fundamentales que sirven de base al trabajo diario de los profesionales del software y que son de vital importancia para los desarrolladores actuales: el lenguaje de modelado unificado o UML, los procesos de software, la orientación a objetos y la ingeniería de requisitos con casos de uso, principalmente.
Los conceptos de ingeniería provienen necesariamente de la teoría formal de los lenguajes de modelado de sistemas, las técnicas orientadas a objetos de modelado de software, los métodos de construcción de software y la identificación, especificación y administración de requisitos de software con casos de uso, entre algunos otros. Desarrollé esos conceptos a través de cada capítulo en un estilo riguroso pero informal, más bien práctico, siempre pensando en poner de manifiesto lo que me ha funcionado a mí y a mis colegas, principalmente de Intergrupo, pero también de otras compañías del medio.
Parte 1 – Algunos Aspectos Esenciales de la Ingeniería de Software
El libro está dividido en dos secciones mayores. La primera parte del libro la dedico a explicar algunos de los asuntos que acusan recibo en la comunidad de ingenieros de software: UML, la notación estándar para modelar sistemas de software y otros sistemas que no son software; En lo que se constituye como los prolegómenos del libro, de manera sucinta describo la gran mayoría de los diagramas del lenguaje, con ejemplos breves pero suficientemente explicativos y desmitifico algunas de las creencias sobre la herramienta.
En el capítulo 2, hago una presentación general de los procesos de software y de cómo estos son usados por los practicantes de la industria, es decir, nosotros. Aquí empiezo a develar las prácticas más recurrentes para adoptar y adaptar procesos de software en una organización, tal y como lo hicimos en Intergrupo en una serie de incrementos que llevaron a convertirnos en una compañía CMMI nivel 5.
En los capítulos 3, 4 y 5 del libro, hago una vasta exposición del Proceso Unificado de Software, desde su marco general en el capítulo 3, hasta los detalles de la fase de Inicio o Concepción en los capítulos 4 y 5. En el primero de los apartados presento los conceptos inherentes al proceso y sus características: las fases y las disciplinas, las iteraciones, los roles y responsabilidades, las actividades y los artefactos. En los dos capítulos restantes, ya con miras a la segunda parte del libro, hablo profusamente de la etapa de inicio del proceso, sus principales hitos y el resultado esperado. Es aquí donde comienzo a hablar de la disciplina de ingeniería de requisitos y de casos de uso, asuntos que ocupan toda la segunda sección del libro.
Luego, en el capítulo 6, concluyo este primer segmento del libro con un tema que verdaderamente me apasiona, la orientación a objetos. Tardé muchos años en encontrar el enfoque justo para esta pieza, teórico-práctico, pero actualizado a las necesidades incesantes de los desarrolladores profesionales de este siglo 21. El capítulo contiene una serie extensa de conceptos aplicables al análisis, diseño y desarrollo de sistemas de software, incluso me atrevo a hacer una analogía en lo que he dado en llamar la Biología Informática, para que todos entendamos mejor y de una vez por todas y para siempre lo que es una clase (objetualmente hablando) y su enorme utilidad durante el ciclo de vida de construcción de software. Sobre objetos, siempre recuerdo lo que decía Edward Yourdon sobre ello: “las metodologías de la ingeniería de software orientada a objetos son la cosa más grande desde el pan tajado. En términos relacionados con computación, las técnicas orientadas a objetos son el desarrollo más importante desde la invención de las técnicas estructuradas durante las décadas de 1970 y 1980.”[1] Hoy lo siguen siendo.
Parte 2 – Ingeniería de Requisitos con Casos de Uso: Volumen 1
La segunda parte está dedicada completamente al asunto de los casos de uso como mecanismo de primera categoría para identificar, capturar, organizar, documentar y gestionar requisitos de sistemas de software. En el capítulo 7 hago una presentación concisa del tema, defino qué es un caso de uso y además establezco las diferencias sutiles que existen con los escenarios de uso de un sistema; también explico de qué se tratan los así llamados casos de uso esenciales como noción capital en la especificación de requisitos y también los distingo de los casos de uso descompuestos funcionalmente. El capítulo finaliza con el ejemplo de caso de uso más simple de todo, el caso de uso “¡Hola, Mundo!”.
En el capítulo 8 abordo el tema de los casos de uso del negocio y sus actores del negocio relacionados. También hablo de la fuente de los casos de uso, de donde provienen y hacia donde van a lo largo del ciclo de vida del software, para terminar con un ejemplo del cual luego hago un análisis exhaustivo.
En el capítulo 9 hago una descomposición de la estructura de un caso de uso y exhibo cada una de sus partes principales: la descripción breve, las precondiciones y poscondiciones del caso de uso, la secuencia básica y las alternativas y los requisitos especiales. Ya en los capítulos previos había tratado el tema del nombre y el actor del caso de uso.
Más adelante, en el capítulo 10, bajo el manto de un ejemplo representativo, enuncio mi Ley de la Terminación de un Caso de Uso, que me sirve para explicar uno por uno los puntos de una lista de verificación para saber si un caso de uso cuenta con los atributos mínimos requeridos para ser considerado un buen caso de uso. Las listas de verificación deben verse como instrumentos o herramientas de apoyo en el proceso de administración de la calidad de los productos que construimos, nunca como un documento que se debe “diligenciar”. También sirven para disminuir el nivel de subjetividad con que se revisa un producto de software o parte de este, o un artefacto relacionado con el software. Al menos, este es el mensaje que llevo implícito en esta sección del libro.
El capítulo 10 sirve como entrada al tema que abordo en el capítulo 11, este del análisis y diseño de los casos de uso, mejor conocido en el ámbito de los diseñadores de software como realización de casos de uso. Aquí evidencio la necesidad de contar con el conocimiento de conceptos tan importantes como las técnicas orientadas a objeto, que trato al final de la primera parte del libro, y donde hago un uso extenso del lenguaje de modelado unificado que trato en detalle en los prolegómenos del libro (capítulo 1). En este capítulo empiezo con una disertación sobre los problemas de comunicación existentes entre los miembros de un equipo de desarrollo de software y que son inherentes a la naturaleza humana. A continuación, con un ejemplo característico y práctico, hago una exposición detallada de los diagramas de interacción de UML, en general, y de los diagramas de secuencia, en particular, que sirven como mecanismos fundamentales para llevar a cabo estas realizaciones de casos de uso.
En el capítulo 12 cierro uno de los ciclos del libro sobre modelado de casos de uso y presento el no menos espinoso asunto de las relaciones entre actores y casos de uso y entre casos de uso. La generalización entre actores, una práctica poco usada entre los analistas de software, o muchas veces mal usadas, inicia este apartado. Luego continúo con la típica relación de inclusión de casos de uso, donde hablo de factorización de requisitos y de reusabilidad de requisitos; más adelante hago una disertación sobre la relación de extensión y sus diferencias principales con la anterior. Al final también hablo de la generalización entre casos de uso, aunque no la recomiendo mucho. Este capítulo aporta el enfoque sistémico de toda la segunda parte del libro y hace énfasis en cuando debemos usar una u otra relación, o todas ellas.
El capítulo 13 entra en el terreno de las buenas prácticas mostrando los errores más comunes que se cometen a la hora de usar casos de uso, algo que he dado en llamar “los casos de abuso”, es un juego de palabras pero ilustra a la perfección el punto al que quiero llegar. Enumero y explico una serie de dieciséis casos frecuentes de mal uso de los casos de uso, desde la mala práctica de usarlos en todo momento y en cualquier contexto, pasando por los errores habituales de documentar detalles técnicos o de la interfaz de usuario en el caso de uso, hasta la costumbre perfeccionista de solo presentar el caso de uso cuando está “felizmente” terminado, solo cuando contiene todos los detalles que se han acordado con el usuario. ¿Quién diría que lo perfecto siempre es mejor que lo bueno? Pues bien, aquí sucede exactamente lo contrario: lo acabado, lo ideal, lo absoluto es enemigo acérrimo de lo bueno, de lo que proporciona valor. Es una de las conclusiones que obtendremos al final del capítulo. Incluso muchos de nosotros hemos llegado a pensar que el analista de requisitos y otros miembros del equipo de desarrollo son síquicos y que pueden leer nuestros pensamientos y saber lo que queremos sin habérselos dicho. De todo esto se trata este estudio al que clasifico de patológico y de forense, fueron situaciones que discutí mucho con algunos de mis colegas en Intergrupo.
El último capítulo del libro fue otro de los que siempre quise escribir en mi Gazafatonario: se trata de diez más uno consejos útiles y simples para escribir efectivamente casos de uso efectivos. La aliteración en el título me sirve para abordar dos asuntos importantes: el problema de la comunicación efectiva entre las personas y el problema de la calidad y utilidad de los artefactos de software, en este caso, de los casos de uso. Me parecía razonable, después de la descripción sintomática que hago en el capítulo anterior, sobre los errores más pronunciados que cometemos a la hora de modelar sistemas de software con casos de uso, traerles algunas propuestas para remediar nuestro trabajo, hacerlo más productivo y de mejor calidad. De eso se tratan estos consejos.
Dónde conseguir el libro
El libro lo pueden conseguir en:



[1] Yourdon, Edward. Object-Oriented System Design, an integrated approach. Prentice Hall. 1994.