Enfrentando al “Agile Industrial Complex”

Enfrentando al “Agile Industrial Complex”

En los últimos años “el mundo agile” ha sido invadido por lo que Martin Fowler ha denominado como el “Agile Industrial Complex” y de la mano de ello las prácticas técnicas han quedado de lado. Mucho post-it y poco TDD, mucho “agile coach” y poca excelencia técnica. Esta situación desdibuja (o incluso viola) la ideas expresadas inicialmente en el manifiesto ágil.

Esto ha sido advertido por varios referentes de la industria mucho antes de que Fowler acuñara este título y ha generado a mi entender 2 corrientes:

  • Por un lado están lo que “luchan” con el “Agile Industrial Complex” intentando “reencauzar” el movimiento ágil.
  • Por otro lado están quienes en cierto modo han cortado por lo sano, inaugurando nuevos movimientos como Heart of Agile, Modern Agile, y Software Craftsmanship

Personalmente creo que yo también soy parte de este Agile Industrial Complex y no me gusta. Me incomoda. No estoy en contra de que se hagan negocios a partir de Agile pero me molesta cuando esos negocios se hacen utilizando el nombre/marca Agile sin respetar las cuestiones esenciales. No se puede hablar/vender Agile Software Development dejando de lado la excelencia técnica, la auto-organización, la entrega de valor y la mejora continua.

En un momento pensé en dejar de utilizar el término “Agile/Ágil” y en su lugar hablar de “Desarrollo Adaptativo” o “Ingeniería de Software centrada en el Valor” pero esas alternativas (al igual que algunas otras) no terminaron de convencerme pues si bien son correctas conceptualmente, no resultan cómodas. Finalmente decidí intentar evitar el término “Agile” y hablar de prácticas más concretas como Continuous Delivery, TDD y Planificación Adaptativa.

Continuará…

DevOps: un camino bottom-up

Actualmente estoy trabajando en una institución bancaria colaborando entre otras cosas en una iniciativa DevOps. En forma resumida la iniciativa surgió a partir de varios equipos de desarrollo trabajando en paralelo de forma independiente. Cada equipo fue trazando “su propio camino a producción” con la colaboración de algunos miembros del equipo de infraestructura. Luego, por iniciativa de un gerente de desarrollo, representantes de cada equipo y algunos miembros del equipo infraestructura comenzaron a reunirse para compartir lo hecho por cada uno.

De esta forma, con un esquema de reuniones periódicas, vamos generando acuerdos a partir de las experiencias concretas de cada equipo. Las primeras reuniones fueron un poco caóticas, pero gradualmente van mejorando y agregando más valor. 

A mi parece el uso de un enfoque bottom-up en una institución bancaria es algo novedoso porque tradicionalmente este tipo de organización tienen más a los enfoques top-down. En dicho enfoques top-down hay generalmente un equipo/grupo/gerencia que define/diseña/toma decisiones y luego baja linea al resto de la organización imponiendo dinámicas y políticas que suelen no convencer a la gente que concretamente hace el trabajo de desarrollo/operación.

En los enfoques bottom-up como el que menciono aquí, el trabajo suele ser más lento pero a mi parecer más efectivo ya que se le da voz a los equipos y se construye a partir de su experiencias.

Notas de mi Taller de TDD en CONAIISI 2018

La semana pasada estuve en Mar del Plata participando del sexto Congreso Nacional de Ingeniería en Informática y Sistemas de Información. En ese contexto hice mi Taller Introductorio de Test-Driven Development.

Del taller participaron unas 15 personas de 7 universidades distintas. La evaluación general del taller fue 4.6/5.

Comparto aquí los materiales de estudio que recomendé a los participantes para profundizar en los temas vistos:

Agradezco a la organización del CONAIISI por haberme dado la posibilidad de dar este taller en el contexto de la conferencia.

Mis notas de BETCON 2018

La semana pasada estuve participando del Congreso Boliviano de Tecnología e Ingeniería (BETCON) 2018 que se realizó en la Universidad Católica Boliviana, regional Cochabamba.

Más allá de mi rol de orador, pude escuchar varias disertaciones interesantes pero como me suele pasar en todas las conferencias, lo más atractivo para mi fueron las oportunidades de networking. En este sentido tuve la oportunidad de hablar con diversos investigadores y profesionales de la disciplina.

Agradezco a Frank Chirapa, chair de Computer Society de Bolivia, quien me invitó a participar de este evento y felicito a todo el equipo organizador por tan lindo evento.

Aquí y aquí están las diapositivas que utilicé en mis disertaciones.

Taller de TDD (gratuito para estudiantes)

En nuestro proyecto de investigación en UNTREF trabajamos en el estudio de prácticas y procesos de desarrollo. En ese contexto hemos armado un taller prácticas de desarrollo ágiles enfocado en Test-Driven Development, Continuous Integration y Pair-Programming. El siguiente video explica brevemente la dinámica de taller.

Si hay alguna universidad que esté interesada en realizar este taller en sus instalaciones solo tienen que ponerse en contacto conmigo.

#camino-docker: elección de la plataforma

#camino-docker: elección de la plataforma

Cuando una organización decide adoptar Docker debe decidir de qué runtime utilizará. En forma simplificada y a muy grandes rasgos podríamos decir que hay 2 estrategias posibles:

  1. Correr directamente docker-machine/docker-compose en sus servers
  2. Correr una plataforma de administración/orquestación de contenedores

Entre estos dos extremos hay algunas otras opciones que están a mitad de camino como ser Nomad, que combinándose con otras herramientas puede proveer funcionalidades comparables con las de un administrador/orquestador.

Personalmente la opción 1 me parece medio precaria y no aplicable a algunos escenarios ya que implica tener que resolver N cuestiones adicionales que en la opción 2 ya vienen resueltas como ser escalabilidad y disponibilidad.

Entonces, suponiendo que uno elige la opción 2 aparece otra decisión a tomar: qué plataforma de administración de contenedores utilizar. En este sentido Kubernetes, la plataforma de administración de contenedores open source desarrollada por Google, viene con un crecimiento muy importante. Este crecimiento está evidenciado por el hecho de que varios vendors (Microsoft, RedHat, IBM, Amazon, etc) han generado productos/servicios basados en Kubernetes. Un punto a tener presente para tomar esta decisión es si uno pretende correr on-premises o en la nube pues a partir de ello uno tendrá ciertas opciones para correr su propio cluster de Kubernetes o podrá directamente utilizar “Kubernetes as a  Service” transfiriendo el costo de administración del cluster a un proveedor.

Personalmente, en términos de cloud he estado en proyectos utilizando el servicio de Kubernetes de Google, mientras que en escenarios on-premises he estado en proyectos utilizando OpenShift. Actualmente estoy en un proyecto que utiliza la solución on-promises de IBM que está basada en Kubernetes. Hay dos opciones bastante populares con las que aún no he tenido oportunidad de trabajar: Amazon EKS y Azure AKS.