Lecciones de Aquiles sobre Agilidad

Vídeo

Agilidad…  ¿Qué es ser ágil?¿para que sirve? Viene mi mente esta escena de la película “Troya” del año 2004. Por eso voy a escribir algunas de las reflexiones sobre agilidad desde esta escena.

Para resumir la escena Aquiles apuñala a un enorme soldado conocido como Boagrius en el trapecio izquierdo, penetrando su corazón y causando su muerte en segundos. Sin embargo son los detalles de la escena lo realmente interesantes. La escena completa dura aproximadamente 2 minutos y 30 segundos y lo que es el enfrentamiento en si mismo ocupa apenas 40 segundos en la escena.

En esos 40 segundos Aquiles derrota a un adversario que le supera en masa muscular, alcance y cantidad de armas. Además lo logra en un único ataque.

La motivación

Cuando el héroe actúa correctamente sus hombres llenan de dolor al enemigo, pero cuando se equivoca son sus hombres los que reciben el dolor.

Si prestamos atención a la discusión en la primera parte de la escena, Aquiles parecía renunciar a la batalla, no tenia que librarla; pero acepta el reto por una motivación que esta más allá de su persona (los soldados los que puede ahorrar la muerte en esa batalla en particular). ¿De donde viene la motivación? ¿cómo afectan nuestras decisiones las deferencias con otros?

Cuando trabajamos en un equipo debemos tener presente siempre que nuestras acciones y decisiones tienen efectos en los demás miembros del equipo, de forma positiva o negativa según sea nuestro actuar.

La Preparación

Además de ser combatiente con mucha preparación, según el mito el origen de la invulnerabilidad de Aquiles proviene de haber sido expuesto bien al fuego o a las aguas del Estigia (río del odio). Es decir había sido curtido desde pequeño. Esta preparación en el campo laboral es siempre importante, por eso una buena parte de la preparación la constituyen las experiencias que puedan resultar dolorosas pero que a la larga nos confieren de cierta forma esa invulnerabilidad.

Sin embargo Aquiles pese a ser invulnerable era mortal. La mortalidad la es esa noción que nos mantiene alertas ante la posibilidad de la muerte y el fracaso. Pese a todas las destrezas ya sea como persona, equipo u organización no somos infalibles y los errores pueden tener un costo muy alto.

Ni más ni menos, lo justamente necesario

En la escena Aquiles no usa la lanza, en lugar de esto utiliza solamente su escudo y su espada. Yo suelo ver esto de forma constante como desarrollador y como persona. Por esta razón siempre es bueno preguntarnos ¿realmente necesito esta herramienta? ¿me será de alguna utilidad en estas circunstancias o para este reto en específico?

Plan de acción y ajustes sobre la marcha

En la escena es claro que Aquiles tiene pensado realizar un taque a corta distancia. Aquiles no usa la lanza mientras su adversario utiliza dos. Sin embargo pese a que tiene un plan de acción no parece saber exactamente detalles de las capacidades del adversario como el alcance, potencia y velocidad de los proyectiles que lanza. Quizá por esa razón decide llevar su escudo.

Siempre es necesario cierto nivel de prevención un margen de seguridad (el escudo) sin embargo al igual que Aquiles debemos tener claro que nuestra maniobrabilidad y velocidad serán mucho mayores sin el. Por eso no debemos dudar en dejarlo a tras una vez que a cumplido su cometido.

achilles_vs_boagrius_by_dark_king_rayleigh-d6co8am

Programando como en los 80 con este terminal vintage retro

Estándar

Una adaptación del artículo “Code Like Its The 80s With This Vintage Retro Terminal

Coo-Retro-Term-IBMDOSLa línea de comando puede parecer bastante monótona en ocasiones. Es un entorno de trabajo funcional para hacer las cosas, sin verse bonito.

Para muchos de nosotros, agregar algún esquema de colores como solarized es lo más sofisticado que llegamos a hacer.

Pero solo porque la línea de commandos tenga bien ganada la reputación de ser visualmente austera, no significa que tengamos que usarla tal cual.

Cool Retro Term, un terminal de cátodos para Linux

Para aquellos días en los que te sientes nostálgico, quieres probar algo diferente, o un programar como los de la década de 1980 y 1990, prueba este emulador de terminal retro gratuito.

Se llama (apropiadamente) “Cool Retro Term” y es un emulador de terminal orientado a “imitar el aspecto y la sensación de las antiguas pantallas de tubo de catódicos”.

Incorpora un conjunto de plantillas pre-configuradas que replican magníficamente el aspecto visual vintage de la informática de antaño. Hay varios efectos de monitor (y defectos) que incluyen líneas de exploración, parpadeo y curvatura y brillo de la pantalla, y todos los esquemas de color que cabría esperar (sí, incluido el texto verde sobre fondo negro).

Una sección de preferencias my completa te permite personalizar o ajustar varias configuraciones diferentes, incluyendo brillo, contraste, fuente y opacidad.

Usa este emulador de terminal y pretende que tu computadora portátil System76 súper elegante es en realidad una antigua estación de trabajo IBM. También puedes crear tus propios perfiles o bien importar perfiles creados y disfrutar de aspectos personalizados que te agraden más.

Instalar Cool Retro Term

Cabe destacar que Cool Retro Term no es un tema para la Terminal GNOME ni para ninguna otra herramienta terminal existente. Es una aplicación de terminal separada que se puede usar (y no usar) cuando y cuando le apetezca.

crt256Cool Retro Term se basa en Konsole, y requiere Qt 5.2 o posterior para funcionar.

Si quieres contactar con tu Tomas A. Anderson interno (y sentirte como Neo en The Matrix), Cool Retro Term te ofrece una manera fielmente estilizada de hacer precisamente eso.

La mejor manera de instalarlo es compilarlo. Encontraras las instrucciones para su instalación vía manejador de paquetes y bien descarga y compila para tu sistema operativo desde el repositorio de la aplicación.

Cool-Retro-Term – https://github.com/Swordfish90/cool-retro-term

 

El paradigma de la educación en Nicaragua

Estándar

Este año varias noticias me han fijado en las cabeza varias cosas relacionadas con la educación que van resultado mal, pero muy mal, con consecuencias desastrosas para Nicaragua. Y es que para ninguna de nosotros dentro del país es novedad que el sistema educativo esta mal a todos los niveles desde la educación básica hasta la educación “superior”.

UNAN-Managua, examen de admision para el ano lectivo 2015Iniciando por la punta de iceberg, la educación superior. En Nicaragua una serie de circunstancias históricas y políticas han contribuido al deterioro vertiginoso de la calidad de la educación universitaria.

Lo primero es que hemos intentado,… perdón ya no se ni siquiera que es lo que pretendemos en realidad, ni se si hay alguna meta a nivel nacional de lo que pretendemos conseguir con la educación superior. Pero en términos generales puedo decir que estamos cometiendo el error de orientar la educación superior con mecanismos de mercado. Sí, hemos transformado la educación en un mercado el sentido más vulgar.

Lo que se ha logrado es tener un gran número de universidades muchas privadas y otras que combinan capital privado y fondos públicos (son controles, ni distinciones muy claras sobre estas dos fuentes de capital) lo que pudiera llevarnos a resultados como los de Corea del sur, si no fuera porque nos hemos olvidado de poner la calidad como un objetivo fundamental.

Como resultado lo que tenemos un número elevado de universidades que prestan servicios a costos bajos, maximizando sus ganancias, destinadas a atender a un número creciente de egresados de los sistemas de educación básica, con un enfoque muy pobre o ningún enfoque en la calidad (ni de la educación, ni delos egresados). Los mismos que luego caen en el desempleo o sub-empleo, porque el mercado no puede absorber la gran cantidad de profesionales que se producen y que tampoco tiene esperanza de encontrar empleo (al menos para lo que se supone que se formaron) fuera del país, porque la baja calidad, el nulo prestigio y la falta de acreditación de los centros de educación superior del país impide que puedan ser reconocidos al nivel siquiera regional.

censo1Esta triste realidad, la educación superior es un conjunto de universidades y centros (empresas al fin) enfocados en lograr ganancias y proveer “educación” a bajo costo, para un mercado creciente (jóvenes de recurso limitados) ansiosos de mejorar sus condiciones de vida, con la promesa una profesión que les abrirá las puertas de un mercado laboral, desconociendo que contrataran a unos pocos, porque no hay suficientes puestos.

Y no es que a la educación básica le vaya mejor, porque la baja calidad de la educación, la falta de inversión, sumada el mal uso de los fondos destinados para educación, provoca que la mayoría carezca de competencias básicas no solo para pasar a la educación superior, sino para su vida cotidiana. Todo esto sin sumar las paupérrimas condiciones en que los educadores deben desempeñarse, los bajos salarios y la falta de reconocimiento social. La falta de participación (o interés) de los padres en la formación de los hijos, les juega en contra a niños y jóvenes (como si no tuviesen ya suficiente), esta estocada no es la final si no a penas la primera que recibirán.

En resumen la receta del desastre para un país como Nicaragua, porque no podemos aprovechar el potencial de nuestros ciudadanos en el futuro cercano, ni hablar siquiera de innovación y desarrollo.

Voy a cerrar parafraseando la publicación “Reformando la educación: lecciones de Estados Unidos, Finlandia, Corea del Sur, Brasil y Chile”

“Las reformas educativas deben ser sostenibles, capaces de mantener su impulso transformador en el complejo proceso de su despliegue. Esa sostenibilidad depende de las condiciones iniciales inducidas en el sistema, y de la fuerza de la iniciativa descentralizada puesta en marcha. Una reforma transformadora requiere de una interacción positiva entre igualdad y coherencia en la educación. Igualdad no es equivalente a mayor cobertura. Supone que todos los niños tienen derecho a la mejor educación básica posible, no a cualquier educación. La coherencia entre todos los niveles del sistema educativo requiere de la igualdad, y la igualdad solo es posible garantizando la coherencia del conjunto del sistema desde los niveles más básicos. El ideal de la excelencia solo es factible si está presente desde el punto de entrada al sistema educativo. Es el impulso generado en los niveles básicos del sistema el que garantizará el momento necesario para que los niveles superiores crezcan en forma armónica. Más y mejores estudiantes no aceptarán una educación mediocre.”

Nosotros no usamos UML, nosotros somos ágiles

Estándar

Para algunos usar modelos UML y ser ágiles simplemente no puede darse al mismo tiempo. No voy a argumentar sobre si esto es cierto o no. La cierto es que el título de este artículo contiene dos enunciados independientes. Tu grupo no usa UML, un hecho. Son ágiles, otro hecho.  El problema es que usualmente agregamos un “porque” implícitamente entre ambos enunciados. Si tu intentas decir “no usamos UML porque somos ágiles”, entonces surge un problema, porque es posible usar utilizar UML y ser ágil al mismo tiempo.

Siempre me ha parecido que este problema deriva de una mala interpretación de los principios del agilismo. Cuando el segundo principio dice:

Software funcionando sobre documentación extensiva

avoid_the_dark_side_of_gileNo quiere decir que se deba desechar la documentación, lo que el principio dice es que el principal foco de interés es el “software funcionando”. Al igual que los otros tres principios no dicen que se desechen los procesos y herramientas, se deje de lado u evada la negociación contractual o que no tiene que haber planes o algún tipo de planificación. Los principios expresados en el manifiesto ágil simplemente nos invitan a poner el énfasis en los individuos he interacciones, software funcionando, colaboración con el cliente y la adaptación al cambio por encina de los otros aspectos.

Incluso si estas siguiendo un proceso ágil, harás modelado en algún grado – simplemente no será tanto como si estuvieses siguiendo un proceso tradicional. También el grado de formalidad será diferente probablemente… La falta de formalidad en UML ágil no significa que tu no estas modelando – sólo significa que es probable que te centres en obtener los beneficios del modelado sin los inconvenientes de documentos extraños.

Terry Quatrani

Porque UML puede ser Ágil.

La experiencia nos dice que el ejercicio de modelado reúne a los equipos de dos maneras: Comunicación y Análisis. Dado que los equipos Ágiles ya realizan algún tipo de modelado, el valor proviene meramente del ejercicio de realizar algún grado de modelado (Story telling, modelado de arquitectura, wireframes de diseño, pruebas UX, etc.). Haz lo que tenga sentido para su equipo. Uno solo quiere crear los diagramas suficientes para ayudarle a comunicarse y pensar en su problema.

Terry Quatrani

Acá comparto con ustedes algunas razones por las que UML puede ser ágil.

Posibilita una mejor comunicación con los Interesados del Proyecto

revision_de_planos_1Utilizar modelos UML para explicar a los clientes como ha de funcionar un software incentiva la participación de los interesados y su interacción con el equipo de desarrollo. Esta comunicación entre los grupos da lugar a un software que responde mejor a las necesidades del cliente. En caso de encontrarse un conflicto o malentendido sobre un elemento, este puede ser corregido durante la siguiente interacción o versión.

Facilita la colaboración

La realidad es que la comunicación para ser buena tiene que ser colaborativa. En este sentido UML constituye una referencia común. Los modelos ayudan al equipo a trabajar juntos, ya que pueden ser utilizados por los miembros del equipo para visualizar, compartir y discutir ideas y soluciones a los problemas.

Los modelos pueden ayudar a los nuevos miembros del equipo a entender la visión de alto nivel y participar rápidamente, dado que una representación visual puede ser más fácil y más clara de entender y analizar que el texto.

Una  imagen vale más que mil palabras.

Ayuda a enfocarse en lo importante

gafas_enfocarPor supuesto que si nos enfocamos en los modelos y la documentación, no estamos siendo ágiles; pero si usamos los modelos para enfocarnos en el problema a resolver, entonces son artefactos valiosos.

Los modelos pueden utilizarse como fuente de documentación actualizada, dado que la arquitectura general de un sistema usualmente no cambia a lo largo de varias iteraciones.  Por ello los modelos pueden reutilizarse en fases posteriores.

UML Realista

Por otro lado los equipos de desarrollo enfrentan otros problemas al utilizar herramientas de modelado de escritorio:

  1. Las herramientas son bastante complejas de usar, toman mucho tiempo en instalar y configurar.
  2. Compartir modelos es complicado.
  3. Trabajar juntos en el mismo modelo sigue siendo poco práctico.
  4. Generar código es tedioso ya veces inútil.
  5. Persisten varias interrogantes alrededor de la sincronización “código – modelo”.
  6. No existe una herramienta sencilla dedicada a hospedar y administrar versiones de modelos.

En casa de herrero, el cuchillo es de palo

El modelado en la nube es una parte de la solución. La colaboración en tiempo real, una herramienta de modelado alojada en el navegador y el intercambio parecen ser las características clave en las que se basará el modelado ágil. Parece que las cosas se están moviendo en la dirección correcta. ¿Qué piensas?

Dilbert-and-team-discuss-collaboration

UML Ejecutable

Crear modelos que se pudiesen ejecutar es una idea que me ha atraído desde que estaba en la universidad. Quisiera dibujar algunos diagramas, presionar un botón, y tener un software funcionando ¿Suena como la magia? Pero eso es una parte importante de la visión UML Ejecutable.

La idea básica es que usaremos una herramienta CASE para desarrollar diagramas UML detallados y luego complementarlos con especificaciones escritas en un lenguaje formal, probablemente el lenguaje de restricción de objetos (OCL) de OMG. La idea básica detrás de UML Ejecutable es que los sistemas se pueden modelar a un nivel más alto de abstracción que el código de fuente, simulado para apoyar la validación de tu trabajo, y después ser traducido en código eficiente.

Este alto nivel de abstracción debería contribuir a evitar el diseño prematuro, permitiendo cambiar el sistema a medida que sus necesidades evolucionan y retrasar las decisiones de implementación hasta el último minuto. Todo esto suena muy bien en teoría, desafortunadamente existen varios problemas para llevar esto a la práctica:

  1. UML es claramente insuficiente para el desarrollo de aplicaciones empresariales. Esto implica que los proveedores de herramientas tendrán que agregar sus propias extensiones propietarias al UML para que esto funcione, lo cual es exactamente lo que hacen los proveedores de herramientas existentes. Pero entonces ya no serían modelos ejecutables, sino de modelado de ejecutables (xModeling) en su lugar.
  2. La integración de una colección de herramientas para soportar UML ejecutable es actualmente difícil. Supongamos que uno o más proveedores de herramientas deciden implementar la visión de UML ejecutable y llenar los agujeros abiertos inherentes al UML. ¿Cómo harían que funcione? Idealmente, algunas empresas se centrarían estrictamente en la construcción de una buena herramienta de modelado y otras se centrarían en sacar el resultado de esas herramientas para producir un ejecutable de trabajo en una plataforma determinada. Algunos vendedores producirían plug-ins para entornos J2EE, otros para entornos .NET y otros. Para soportar esto, necesitaríamos un estándar común para compartir información entre herramientas, el estándar de intercambio de metadatos XML de OMG (XMI) me viene a la mente, aunque debido a que XMI se basa en el UML de OMG y Common Warehouse Metamodel (CWM) Tampoco es suficiente para especificar completamente el software de extremo a extremo. Aunque el CWM proporciona información para especificar la información relacionada con la persistencia, todavía necesitamos especificar otros aspectos de un sistema, como su interfaz de usuario.  Si bien como en el caso de la interfaz de usuario tenemos iniciativas como UWE – UML based Web Engineering; no hay un estándar completo en el lugar de los vendedores diferentes para agregar sus propias extensiones únicas que hacen la integración de herramientas de varios proveedores difícil.
  3. Es probable que un enfoque de proveedor único sea demasiado estrecho. Otro enfoque puede sera un proveedor por herramienta, que  soportase tanto el modelado como las características de generación de código en su herramienta, algo perfectamente razonable en teoría. Pero, debido a la amplia gama de plataformas, y la gama de opciones de diseño dentro de esas plataformas, los proveedores de herramientas tendrá que centrarse en un nicho único. Tal vez un proveedor se especializará en la generación de desarrollo J2EE que soporte Java Server Pages (JSP), servlets, Enterprise JavaBeans (EJBs) y bases de datos relacionales. Tal vez otro se especializará en la generación de aplicaciones cliente basado en Java, mientras que otro genera aplicaciones cliente para Windows. Esto implica que las organizaciones que desarrollan para varias plataformas necesitarán varias herramientas de desarrollo, herramientas que deben ser compradas y soportadas a menudo a costo alto. Además, la amplia gama de funcionalidad que se requiere de una herramienta como esta dificulta que los vendedores se especialicen y se enfoquen en un solo aspecto de la visión de UML Ejecutable, lo que produciría una mejora muy lenta de los entornos de desarrollo en general.

No tengo dudas de que empezaremos a ver surgir algunas herramientas interesantes en los próximos años basadas en la visión de UML Ejecutable. Pero los desarrolladores tendremos que seguir trabajando sin ellas por un buen tiempo.