Ingeniería de Software: materiales de estudio

Hace un par de semanas un colega docente me hizo una consulta porque tenia que comenzar a dictar una materia de Ingeniería de Software. Hicimos una llamada vía skype y le conté sobre el enfoque que suelo usar en mis materias sobre dicha temática. Al final de la charla quedamos en que le compartiría los materias de estudio que utilizo y de ahí la idea de este post.

En primer lugar un poco de contexto. Yo dicto dos materias de Ingeniería de software una en UNTREF y otra en UBA (Facultad de Ingeniería). La materia de UNTREF se llama efectivamente Ingeniería de Software mientras que la de UBA se llama Métodos y Modelos en la Ingeniería de Software 2 (memo2). Más allá de las diferencias de nombres, el contenido de ambas materias es muy parecido y la dinámica de cursada y aprobación es la misma (está descripta en este paper).  Al mismo tiempo hay que destacar que en ambos casos los alumnos llegan luego de haber cursado previamente alguna otra materia de Ingeniería de Software más introductoria, con lo cual ya tienen cierta idea de un proceso de desarrollo y han leído/estudiado algunos de los clásicos como No Silver Bullet y el SWEBoK.

Explicado el contexto vamos al contenido. En ambos casos tomamos como base el libro Construcción de Software: una mirada ágil (aunque no lo leemos completo). Complementariamente tenemos los siguientes materiales (no todos son de “consumo obligatorio” y en algunos casos se referencia un libro, pero no pedimos leerlo completo sino algunos capítulos en particular):

Adicionalmente tenemos algunos material de nivelación sobre temáticas que se supone vieron en materias anteriores:

Debo mencionar que esta lista de materiales está en constante evolución.

Cierre de cuatrimestre en MeMo2 @ FIUBA

La semana pasada finalizamos el segundo cuatrimestre de la materia con dos diferencias muy importante respecto de cuatrimestre anterior:

  • Se sumó Emilio Gutter al equipo docente.
  • Hubo un total de 20 alumnos (el primer cuatrimestre hubo solo 3)

Comparto algunos números frios:

  • 20 inscriptos: 3 abandonos, 17 aprobados
  • Nota promedio de aprobación: 8,1
  • 3 visitas de la industria
  • 1 clase especial
  • 2 invitados de la industria
  • 8 cuestionarios
  • 8 katas/ejecicios

Algunos otros números surgidos de la encuesta interna de la materia:

  • Cantidad de respuestas: 16
  • Evaluación general de la materia: 8,25 / 10
  • Claridad de los docentes: 4,25 / 5
  • Dinámica de clases: 4,4 / 5
  • Materiales de estudio: 4,3 / 5
  • Dedicación semanal promedio fuera de clases (horas): 7.8

Finalmente están los números resultantes de la encuesta oficial del departamento de computación:

  • Cantidad de respuesta: 14
  • Opinion general de la materia: 4,14 / 5
  • Dificultad de la materia: 3,57 / 5
  • Nivel de las clases: 4,2 / 5

Personalmente estoy muy contento con este resultado aunque sabemos que tenemos algunas cuestiones a mejorar:

  • Rearmar algunas clases: generar más videos para poder incorporar actividades más interactivas en las clases presenciales
  • Ajustar las fechas de los TPs
  • Clarificar al comienzo del cuatrimestre los criterios de aprobación/evaluación

Para cerrar dejo algunas fotos tomadas en algunas clases:

Cierre de cuatrimestre AyDOO 2018 @ UNTREF

La semana pasada cerramos el curso 2018 de Análisis y Diseño Orientado a Objetos en UNTREF. Personalmente creo que en términos organizativos fue una de las mejores ediciones. Estos son los puntos destacados del cuatrimestre:

  • 12 inscriptos: 7 aprobados, 2 abandonos, 1 desaprobado y 2 con final pendiente
  • La nota promedio de cierre de cursada fue 6,6/10
  • La evaluación general de la materia realizada por los alumnos (vía encuesta anónima) fue de 8,3/10.
  • El tiempo promedio semanal dedicado por los alumnos a la materia fuera del aula fue de 10 hs
  • El equipo docente estuvo conformado por Diego Marcet, Lucas Campaner y yo

Entre los puntos a mejorar los alumnos destacaron:

  • Necesidad de mayor claridad en la consigna de los ejercicios
  • Necesidad de unificar algunos criterios de corrección.

Casi con seguridad este fue el último cuatrimestre de esta materia, ya que la misma pertenece al viejo plan de estudios que está siendo reemplazado. Es por esto que me parece interesante aprovechar para compartir algunas estadísticas históricas a lo largo de los últimos 3 años:

  • La evaluación general de la materia evolucionó constantemente en forma positiva, al igual que la claridad de los contenidos y la dinámica de clases.
  • Al mismo tiempo la cantidad de inscriptos y la nota formal de aprobación muestran una disminución.
  • Al cabo de 3 años la evaluación general de los fue 7,9 (promedio) mientras que la nota promedio de aprobación fue 7.5.
  • El promedio general de aprobados de la materia fue de 75% (en el 25 % restante están los que no aprobaron durante la cursada y que tal vez aprobaron en un fecha posterior o en un examen libre).

Gestión de ambientes y Diseño de Infraestructura para DevOps

EL próximo Jueves 26 estaré dando una charla abierta sobre esta temática:

El manejo de ambientes de desarrollo y tests es un tema relevante a la hora de intentar optimizar el flujo de valor de todo proyecto de desarrollo de software. En este contexto la práctica de Self-Service Infrastructure puede ayudar a una organización a simplificar el manejo de estos ambientes, dando más libertad a sus equipos de desarrollo sin sacrificar estabilidad. En esta charla veremos los principios, beneficios y desafíos de esta práctica, junto con algunos patrones y herramientas para su implementación. Entre otras cuestiones hablaremos de modelos de infraestructura, continuous delivery, infraestructura como código y chatops.

La cita es este Jueves 26 a las 19.00 hs en Facultad de Ingeniería de la UBA (Paseo Colón 850), aula 319. Interesados por favor registrarse en este Meetup.

Agile por Kilo

El año pasado me contactó un directivo de una empresa multinacional que estaba interesado en empezar a trabajar con métodos ágiles. Me reuní con él para entender su necesidad. Una vez comenzada la reunión le pregunté sobre la motivación que lo llevaba a los métodos ágiles, o sea, yo quería entender qué problema se esperaba resolver o que situación se esperaba mejorar a partir del uso de métodos ágiles. La respuesta fue muy concreta: a nivel global la organización había decidido adoptar una “forma de trabajo ágil combinada con DevOps” y por ello este directivo quería contratar a la brevedad 5 coaches/scrum masters para generar un “shock de agilidad” que se tradujera en una mejora notable de productividad. De esta forma esperaba contagiar al resto de los equipos de la subsidiaria local para que se subieran “al tren ágil”. Esta estrategia distaba mucho de lo que yo hubiera hecho y en un punto hasta podría considerársela “anti-ágil”. En enfoque ágil implicaría crecimiento orgánico y sustentable lo cual es muy distinto a “un shock”. En vano intenté convencerlo de utilizar un enfoque distinto y la cuestión no pasó de esa reunión.

Estos son los tiempos que vivimos. Del mismo modo que hay organizaciones que desde hace años pretenden “comprar programador por kilo” hoy en día, con agile siendo mainstream, hay organizaciones que pretenden “comprar agile coaches por kilo”.

Pero en cierto modo creo que lo más triste no es la intención de los que quieren comprar, sino que hay organizaciones dispuestas a satisfacer esos pedidos :-(.

Ya lo decía mi abuela: la culpa no es del chancho sino de quien le da de comer 😦

Lecciones aprendidas automatizando pruebas en ambientes corporativos (parte 2)

En el artículo anterior me centré en los desafíos técnicos. Ahora quiero centrarme en los desafíos humanos, los cuales en ocasiones son aún más complejos: las máquinas hacen lo que uno les dice, pero no las personas no, ¡ja!

El primero de los desafíos humanos aparece en la concepción misma de la iniciativa de automatización. En la mayoría de los casos que he participado la motivación de automatizar ha surgido de una gerente/jefe/líder, pero no de la gente que realiza el desarrollo de los sistemas (developers), ni tampoco de la gente que realiza las pruebas manualmente (testers).

Por lado las iniciativas en las que he participado han caído en manos de equipos incompletos y/o grupos con muy poco compromiso. Gente a la que “se le endosa” la obligación de colaborar en esta iniciativa pero para la cual esta iniciativa no reviste de mayor interés.

Luego de haber participado en varias iniciativas de este estilo solo puedo reconocer 2 de ellas como exitosas (aún cuando los clientes han quedado conformes con lo realizado en casi todos los casos). Los puntos que identifico comunes en esos mencionados casos de éxito son:

  • En ambos casos se contó con una persona en el rol de Software Engineer in Test, alguien que se encarga de proveer/desarrollar herramientas, guías y ayuda en general para facilitar el trabajo de todos aquellos que deban realizar tests.
  • La dedicación pro-activa, comprometida y explícita (en términos de asignación y planificación) de un desarrollador/implementador del sistema core para que asista en el setup de los set de datos necesarios en el sistema core.

En breve estaré empezando un nuevo proyecto de este estilo, por ello en un próximo artículo contaré lo que lo tenemos planeado.

Lecciones aprendidas automatizando pruebas en ambientes corporativos (parte 1)

En los últimos años he participado en un par de iniciativas para automatizar pruebas en “ambientes corporativos”. Cuando digo ambientes corporativos me refiero a organizaciones cuyo core de sistemas está implementado por algún  tipo de enlatado con cierto grado de customización (ERP, CRM, Core bancario, etc). Alrededor de este core la organización desarrolla aplicaciones satelitales que suelen actuar como canales implementado alguna funcionalidad complementaria al core. Estas aplicaciones satelitales/canales suelen tener una gran cantidad de requerimientos y cambios ya que son uno de los medios principales en la actualidad para permitir la innovación del negocio. A la hora de desarrollar estas aplicaciones aparece la necesidad de poder testearlas y que dicha prueba sea (al menos en parte) automatizada.

En particular he tenido la oportunidad de trabajar en contextos de instituciones bancarias y también del ámbito de las telecomunicaciones y en ambos casos he detectado situaciones/desafíos comunes que me parece son habituales en entornos corporativos.

En mi experiencia he identificado dos tipos de desafíos: los técnicos y los humanos.

En lo que respecta a desafíos técnicos el principal pasa por la dificultad de contar con un ambiente de pruebas sobre el cual uno pueda tener control de estados/datos.  En el escenario ideal yo quisiera poder contar con una instancia exclusiva y on-demand del core, cuyo estado pueda manipular a mi gusto sin impactar en otros equipos. Esto no es simple, ya que muchas veces el setup de estos sistemas core es bastante complejo y poco automatizado. Lamentablemente en ninguno de los casos que he trabajo he tenido esta posibilidad, lo cual me ha llevado a buscar soluciones alternativas.

Una situación que me he encontrado en todos los casos que participé es la presencia de un de ESB (enterprise service bus) que funciona como orquestador/integrador de mensajes entre los diversos sistemas de la organización incluido el core. De hecho es común que la interacción de los canales/satélites con el core se haga por medio de un ESB.  Si bien esto puede interpretarse como una complejización de la arquitectura, se supone que en general la simplifica. Al mismo tiempo representa una posible salida al problema del testing.

Escenario corporativo

Entonces ante la imposibilidad de contar con un core para las pruebas (y también para el desarrollo) tenemos dos opciones. Una primera opción es mockear “a la salida” las interacciones con el core.

Opción 1. Mock “a la salida”

La otra opción sería hacer que el ESB devuelva respuestas mockeadas.

Opción 2. Mock en el ESB

Algunos puntos a tener presente independientemente de la estrategia utilizada:

  • Al utilizar una estrategia de mocking en este contexto es necesario tener algún mecanismo para detectar potenciales cambiamos en el sistema que estamos mockeando/emulando. Una estrategia posible es hace contract testing del sistema que estamos mockeando de manera que los tests de contrato se ejecuten periódicamente y nos alerten de eventuales cambios.
  • En algún punto, previo al pasaje al ambiente productivo es necesario poder correr algún tests contra una instancia del core real.  En uno de los casos que me toco participar, la instancia de test del sistema core era tan inestable y distinta al core productivo que lo que se decidió hacer un despliegue canary a un servidor productivo, accesible solo internamente, y de esa forma probar directamente en producción.  Una vez realizada la validación, entonces se completaba el despliegue al resto de los servidores habilitando la aplicación al público en general.

Continuará…..
(en un futuro artículo me referiré a los “desafíos humanos de esta problemática”)