Materias interesantes del nuevo plan de Lic. en Sistemas @ FIUBA

Como parte del trabajo de preparación de MeMo2 estuve revisando el nuevo plan completo de la Licenciatura en Análisis de Sistemas @FIUBA para tener una visión global y entender como MeMo2 encaja en esa visión.

Como su nombre formal lo indica, MeMo1 y MeMo2 son materias de Ingeniería de Software. Pero no son las únicas materias de dicha temática en el nuevo plan, hay algunas otros como ser:

  • Algoritmos y Programación 3
  • Administración y Control de Proyectos Informáticos 1
  • Estándares de Calidad y Modelos de referencia
  • Diseño, Operación y Gestión de Servicios Informáticos

Las dos primeras materias de la lista precedente son materias existentes en el plan anterior y cuyo contenido no ha sufrido modificaciones relevantes en el nuevo plan.

Estándares de Calidad y Modelos de referencia (95.30) es una materia nueva en cuanto al nombre, pero su contenido coincide bastante con una materia existente: Modelos de Procesos de Desarrollo (75.57).

Finalmente Diseño, Operación y Gestión de servicios Informáticos (95.59), es una materia totalmente nueva, tanto a nivel nombre como de contenidos. Personalmente creo que esta materia representa una de las principales mejoras en el nuevo plan de estudio y al mismo tiempo es en cierto modo una innovación a nivel académico pues no conozco en el país otro carrera que incluya cuestiones de gestión de servicios que resultan muy relevantes para la actualidad de la industria informática en nuestro país.

Meetup Agiles@BAires: Infrastructure Patterns for Continuous Delivery

El próximo jueves 20 de Julio en el Meetup de Agiles Argentina estaré dando esta sesión. El título está en inglés porque la sesión la preparé originalmente para darla en la conferencia Agile 2017 y darla ahora en Buenos Aires me sirve en cierto modo como un ensayo.

Comparto algunos datos de esta sesión que pueden resultar de interés para la audiencia:

  • Formato: charla tradicional, basada en diapositivas, condimentada con algunas actividades interactivas.
  • Duración: ~80 minutos
  • Audiencia: gente de perfil técnico sin ningún conocimiento previo en particular
  • Palabras clave: continuous-delivery, devops, automation, infrastructure as code

La sesión está estructurada en 2 bloques:

  • un primer bloque introductorio donde repasamos algunos conceptos básicos de continuous delivery/devops
  • un segundo bloque dedicado a presentación de diversos patrones entre los que se incluyen: incremental environments, automation layers, multi-versioning y split pipeline entre otros.

La cita es en la Facultad de Ingeniería de la UBA (Paseo Colón 850), en el aula 403 a partir de las 19 horas (puntual). Obviamente es totalmente gratis pero por favor los interesados registrarse en la página del Meetup.

Programa analítico de MeMo2 @ FIUBA #nuevaMateria

Como mencioné hace un tiempo en otro artículo, estoy trabajando junto a Sergio Villagra en preparar una de las nuevas materias de la licenciatura. El nombre formal de la materia es Métodos y Modelos en la Ingeniería de Software 2 (95.21) aunque informalmente es posible que termine siendo MeMo2 o Ingeniería 2.

Hace un par de semanas cumplimos con la formalidad de presentar el programa analítico que obviamente esperamos ajustar a medida que corra el cuatrimestre. Comparto a continuación lo presentado:

  • Semana 1: presentación del materia. El desarrollo de software: ingeniería vs. artesanía.
  • Semana 2: Breve historia de los movimientos de calidad. Ciclo de vida del software (procesos típicos) Más allá del software: operaciones, servicios, gestión y gobierno.
  • Semana 3: Proyectos, programas y portafolios. Por qué los proyectos de software son diferentes ¿De dónde vienen los proyectos?: ideas y oportunidades.
  • Semana 4: Modos de contratación: fix-price vs. time&materials. Visual Story Mapping, Impact Mapping, Técnicas de particionamiento de User Stories. Planificación basada en control de alcance. Iniciativa #NoEstimates.
  • Semana 5: Técnicas de priorización de requerimientos. Lean Startup.
  • Semana 6: Conceptos de arquitectura. Atributos de calidad. Modelización, diseño e implementación de los atributos de calidad. Métodos de evaluación de la arquitectura. Walking Skeleton y otras técnicas de arquitectura emergente. Diagrama UML para presentar la arquitectura.
  • Semana 7: Herramientas de soporte al proceso de desarrollo. Control de la configuración. Ambientes. Modelos de branching. Técnicas avanzadas de branching: branch-by-abstraction, feature-branching, feature toggling
  • Semana 8: Especificación con ejemplos. Ciclo BDD+TDD. Domain Driven Design.Tipos de TDD.  Estrategias de integración de aplicaciones. Definición de interfaces.Protocolo REST.
  • Semana 9: Control de calidad. Tipos de pruebas. Pirámide de pruebas de Cohn. Cuadrantes de prueba de Marick. Automatización de pruebas.Arquitectura de prueba. Dobles de prueba.
  • Semana 10: Pruebas de performance. Pruebas A/B
  • Semana 11:Infraestructura como código. Tecnologías de virtualización y conteinerización. Plataformas cloud. X as a Service: IaaS, PaaS, SaaS.
  • Semana 12: Integración y despliegue continuo. Pipeline de deployment. Estrategias de deployment: blue-green, canaries.
  • Semana 13: Monitoreo, Auto-Scaling y Failover. Antifragile
  • Semana 14: Evaluación e implantación de software de terceros.
  • Semana 15: Presentación y puesta en común de trabajos prácticos finales
  • Semana 16: Cierre y conclusiones

SECM Workshop @ ICSE 2017

Art by Nayla Portas

I recently participated in this workshop. It started with a talk by my colleague and friend Diego Fontdevila: Tales from an Agile Journey: Designing Curricula from Millennials in Industry and Academia. While Diego was talking,  Nayla Portas took care of graphics facilitation, great work!

The rest of the morning was dedicated to present all the submitted papers and the afternoon was for debating following a fishbowl-like dynamic.

During the afternoon some students join the session to participate in the debate. I am not sure about the exact number of participants but I think we were around 15, including people from Argentina, Brazil, USA, Sweden, Uruguay, Chile, Rusia, Spain, Italy and China.

After the workshop some of the participants went to a near restaurant to share the dinner. It was the earliest dinner I had in my whole life,  I was eating meat at the 7 pm!

I want to thank Hakan and Cécile for organising this workshop. It was a really valuable activity, it was great to see people from so different contexts sharing their experiences.

There are some more pictures of workshop in its website.

ICSE 2017, my notes from Technical Briefings

ICSE 2017, my notes from Technical Briefings

I recently had the chance to attend to this conference. It was organised in 3 parallel tracks with session of 90 minutes length. I started my journey in the session by Barry Boehm, yes that guy, the one that created COCOMO and wrote those classical books about software cost estimation. The title of the session was: Software cost estimation meets software diversity. The session was fine, the content was not innovative in my opinion but beyond that, it was incredible to see Barry, who is 82 years old, presenting it.

Next, I went to the session by Damian Tamburri that was called DevOps: Introducing Infrastructure as Code. The session started with a brief introduction to DevOps foundations and then it focused on the Infrastructure as Code practice by presenting an standard specification for defining infrastructure as code. I didn’t know about this spec, it is called Tosca and seems very promising. In a certain way this specification standardises some of the feature currently supported by Terraform.

In the afternoon I went to the session Analyzing Software Engineering Experiments: Everything You Always Wanted to Know but Were Afraid to Ask by Sira Vegas. I expected this session to be interactive, but it wasn’t, it was a lecture, where Sira shared several common mistakes in Software Engineering Experiments and also how to prevent/avoid them.

To close the journey I attended to the session Detecting and Quantifying Architectural Debt: Theory and Practice by Yuanfang Cai and Rick Kazman. It was really interesting, it was focused on how to measure the debt in terms of money because that is a simply way for business people to understand its relevance. After this motivation the authors presented an initiative they are involved. The slides of the session are available here.

All the sessions I attended had between 10 and 30 participants, which in my opinion was too few given the relevance of the speakers.

One thing I would change is the length of the session, 90 minutes for “lecture-like” session is too much in my opinion. So I would propose to do shorter sessions or make them more interactive. Beyond these details, it was a really valuable journey for me.

Sobre la Reunión de Revisión (Iteration Review)

Sobre la Reunión de Revisión (Iteration Review)

Allá por 2015 escribí una serie de artículos sobre esta reunión y este artículo me quedó a medio escribir en la carpeta de borradores. Ayer por la tarde una consulta de una colega me motivó a completar el borrador y publicarlo. Espero resulte útil.

Las reviews de mis proyectos suelen tener 2 partes a las que suelo denominar PPT y Demo.

La parte de Demo es donde se muestra el resultado del trabajo realizado. En términos de Scrum es el incremento de producto, en términos de desarrollo más genérico es el working software. Algunos puntos importantes: esta demostración del software se hace en un ambiente de Test/QA (o como gusten llamarle) es una ambiente con bastante estabilidad y definitivamente no es la máquina de un developer. Incluso en algún caso muy particular he hecho la demo directamente en el ambiente productivo.  Como mencioné en un artículo anterior, la Demo no puedo fallar pues no hay razón para que fallé: la estamos corriendo en un ambiente controlado, tenemos tiempo para prepararla y definir exactamente el flujo de acciones. Es cierto, puede haber algún imprevisto como que se caiga la red y por eso es que debemos tener un plan B. Dicho plan B puede ser correr la demo en otro ambiente o bien tener la demo grabada en video. Lo que el equipo considere necesario para asegurar poder mostrar el producto funcionando.

Por otro lado está la parte que suelo denominar PPT en referencia a las diapositivas que se suelen utilizar para guiar esta parte de la reunión. En esta parte de la review repasamos el compromiso, comentamos los eventos relevantes ocurridos durante la iteración y vemos algunas métricas. Finalmente cerramos con una sugerencia sobre los siguientes pasos. En algunos casos, dependiendo de la dinámica del proyecto, puede que también repasemos el estado de los riesgos del proyecto. Todas estas cuestiones se traducen en los siguientes slides:

  1. Portada: nombre del proyecto, número de iteración, fecha
  2. Slide 1: bullets con los hitos relevantes de la iteración y su estado (completo / incompleto)
  3. Slide 2: Burdown chart
  4. Slide 3: Detalle del backlog
  5. Slide 4: Sugerencia de siguientes pasos

Si la iteración incluyó algún entregable que no fuera código (como por ejemplo un spike o algún documento técnico) entonces hay un slide dedicado a esto.

Básicamente considero 3 alternativas para articular estas dos partes:

  1. Primero PPT y luego Demo
  2. Primero Demo y luego PPT
  3. PPT – Demo – PPT

Generalmente utilizo la variante 3.

Dependiendo de la dinámica del proyecto, puede que la demo la ejecute algún developer o directamente el producto owner.

AOC Chile 2017, reflexiones personales

AOC Chile 2017, reflexiones personales

La organización me pareció muy bien. La instalaciones muy apropiadas. Por suerte el azar quiso que mis compañeros de habitación no fueran roncadores. El tiempo acompaño. Me reencontré con gente que aprecio y también conocí nuevas personas.

Por otro lado el contenido de la sesiones surgidas del open space no me resultó atractivo. Tan solo un puñado de sesiones resultaron de mi interés. Pero no me resulta preocupante porque en gran medida ya sabía que esto era muy probable. Como le comenté a algunos de mis colegas, creo que la temática del evento y mis temas de interés son caminos que cada vez se separan más. Al mismo tiempo este poco interés en la sesiones del open space me llevo a que utilizara ese tiempo para tener algunas conversaciones con personas con las que no suelo tener contacto cotidiano.

Resumiendo: creo que en gran medida los AOC van evolucionando en un sentido donde el valor relativo de las sesiones del open space va disminuyendo porque el valor relativo de todo lo demás que ocurre en ese contexto aumenta en cada edición.

Repito por este medio, una vez más, mis agradecimientos infinitos para todo el equipo organizador.