Durante los días 29 y 30 de noviembre se realizará en Mar Del Plata el Congreso Nacional de Ingeniería Informática y Sistemas de Información (CONAIISI) y en ese contexto estaré realizando mi taller de Test-Driven Development. El taller es gratuito para los participantes del CONAIISI pero requiere inscripción (aquí).
Si analizamos los trabajos prácticos que suelen hacerse en las carreras de informática como si fueran proyectos, veríamos que en general están planteados en términos de:
Alcance fijo: el docente define todo lo que hay que hacer y no negociable
Tiempo fijo: el docente indica la fecha de entrega, la cual generalmente tampoco es negociable
Esfuerzo variable: el docente no fija el esfuerzo que debe invertirse para completar el trabajo. Esto suena razonable, ya que habiendo fijado las otras dos variables es de esperar que esta sea ajustable.
Todos los trabajos prácticos que hice durante mi carrera de grado y postgrado fueron así y por lo que suelo hablar con mis alumnos, esto sigue siendo así. Duramente mucho años en las materias que estuve como docente también usábamos esta estrategia pero desde hace unos años hemos cambiado.
Actualmente en las dos materias de ingeniería de software que dicto utilizamos una estrategia distinta:
Esfuerzo fijo: les pedimos a los alumnos una dedicación semanal de 6 horas efectivas, extra clase por persona
Tiempo fijo: trabajamos durante 3 iteraciones, cada una de 1 semana de duración
Alcance variable: hay una lista de ítem/funcionalidades priorizadas y cada equipo estima y asume un compromiso en base a lo que consideran que podrán completar. Incluso si llegan a completar el compromiso, no tienen “penalización” de nota
Y particularmente en este cuatrimestre hicimos un primer trabajo práctico con las modalidad previamente descripta y tenemos un segundo trabajo práctico planteado de forma distinta:
Alcance fijo: está definido el conjunto de funcionalidades a completar
Tiempo variable: cada equipo decide cuando tiempo tomará para completar las funcionalidades. Trabajamos en iteraciones de duración fija, pero equipo decide la cantidad de iteraciones que utilizará. Idealmente creemos que el trabajo puede completarse 2 iteraciones, pero les damos a los alumnos la posibilidad de utilizar 4 o incluso 5 iteraciones
Esfuerzo variable: cada equipo elige cuanto esfuerzo pondrá en cada iteración. De esa forma en una iteración dada que coincida con fecha de examen de otra materia podrían poner poco esfuerzo y luego compensarlo en una iteración posterior.
Personalmente estoy muy convencido y contento con la estrategia TEfAv (tiempo y esfuerzo fijos, alcance variable). Y tengo mucha expectativa con este nuevo experimento de AFTEV (alcance fijo, tiempo y esfuerzo variable).
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
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:
Correr directamente docker-machine/docker-compose en sus servers
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.
Docker vino para quedarse. Los grandes vendors lo vieron, le dieron su visto bueno y se sumaron al negocio. Microsoft, IBM,Google, Amazon y RedHat son algunos de los vendors que están ofreciendo productos y/o servicios para correr Docker ya sea en la nube como también On-Premises.
En lo que va de este año he trabajado con 3 organizaciones en su camino de adopción de Docker y esta semana participé de una reunión en la que se debatió este tema. A partir de eso es que se ocurrió escribir una serie de artículos compartiendo algunas de las lecciones que he aprendido al trabajar con distintas organizaciones en su camino de adopción de Docker.
Por el momento tengo en mente escribir sobre los siguientes temas:
Elección de la plataforma
Creación de contenedores / Dockerfiles
Manejo de configuración
El proceso de despliegue
A modo de introducción comparto algunos artículos de terceros para ir entrando en tema:
Hace unos días me notificaron que mi paper Versioning Strategy for DevOps Implementations fue aprobado para ser presentado en Congreso Argentino de Ciencias de la Informática y Desarrollos de la Investigación (CACIDI2018). Comparto aquí el resumen de este trabajo:
DevOps is one of the most popular approaches for software delivery nowadays. Even though there is no unified definition of DevOps, there is wide consensus about the set of practices that are part of it. Two of those practices areInfrastructure as Code and Continuous Delivery, which bring new artifacts into the Software Development lifecycle. These new artifacts have direct impact on Software ConfigurationManagement, which is a well-known practice that has been around for decades in the Software Engineering discipline. In particular, these new practices have a direct impact on VersionControl. This article describes a Version Control Strategy to manage these new artifacts introduced by DevOps initiatives.The proposed strategy covers the identification of artifacts, versioning tools, version naming conventions and traceability between different artifacts versions. The strategy was validated in three cases of real world projects where it was successfully applied. Each case corresponds to a different kind of organization and in each case a different set of tools where used. Based on these cases, benefits and possible improvements are identified.
El nombre del libro es “Facilitador de Equipos Ágiles”, y es el primer libro de la serie “Chief Agility Officer, El camino de un Coach hacia la Agilidad Empresarial“. Su autor es Martin Alaimo. Lo terminé de leer hace más o menos un mes y el lunes pasado me reuní con Martín para hablar sobre libro: en parte le dí feedback y en parte hablamos sobre algunas cuestiones que se mencionan en el libro y que me interesaba conocer la opinión de Martin con mayor profundidad.
EL libro me gustó, tiene un muy buen mix de teoría/práctica y está complementado con experiencias de campo. Me parece un libro fundamental para que aquellos que quieran desempeñarse como facilitadores.
Si bien en ciertos puntos es un libro introductorio se asume que el lector ya está familiarizado con métodos ágiles en general. A lo largo del libro se utiliza la terminología de Scrum, lo cual me parece acertado incluso cuando el libro no es específico de Scrum. Una característica que me gustó mucho es que algunos capítulos tienen ejercicios.
El libro está disponible en Amazon en diversos formatos y para los que estén en Buenos Aires pueden comprar su ejemplar en papel en las oficinas de Kleer.
