Mes: agosto 2020

Cierre del Seminario de Software Delivery, primera edición

Recientemente completamos la primera edición del Seminario de Postgrado en Software Delivery que organizamos en UNTreF.

El seminario constó de 6 encuentros (virtuales, obviamente) de 2 horas cada uno. Participaron del seminario unos 14 profesionales pero menos de la mitad completaron el trabajo final. A algunos directamente no les interesó hacerlo, algunos otros lo intentaron pero por una u otra razón lo llegaron a completarlo. Sin embargo creemos que los trabajos completados fueron muy buenos.

Inicialmente, en una época pre-pandemia, el curso estaba planteado en una modalidad mixta de encuentros presenciales y virtuales, con lo cual el cambio a modalidad 100% virtual no fue tan difícil.

Como herramientas de soporte para el dictado de curso utilizamos Jitsi para los encuentros virtuales y Canvas como campus virtual. Esta última herramienta yo ya la venía utilizando para el dictado de mis materias de grado con muy buen resultado.

Todo el contenido del seminario estuvo regido por las temática descriptas en el libro Accelerate de Forsgren, Humble y Kim.

Una de las cuestiones que varios de los participantes destacaron como muy positiva fue la frecuencia de los encuentros. Dado que el curso tenía una carga importante de trabajo fuera de las clases, decidimos espaciar los 6 encuentros a los largo de 14 semanas se la siguiente forma:

  • Semana 1
  • Semana 5
  • Semana 6
  • Semana 10
  • Semana 11
  • Semana 14

Viendolo en retrospectiva creo que fue una buena decisión aunque para una próxima edición posiblemente ajustemos la distancia entre los encuentros.

Quedamos muy conformes con el seminario y ya tenemos decidido repetirlo, en principio el primer cuatrimestre del 2021. Aquellos interesado en particular en futuras ediciones puede contactarme por este medio.

Experimento: universidad para todos y todas

Resumen: ¿te interesaría cursar la materia Ingeniería de Software de UNTreF que dictamos con @diemarcet aún sin ser alumno de UNTreF? Entonces completá este formulario indicando porque te intersaría cursar la materia.

La historia completa

La dinámica de cursada con la que está armada la materia implica que en los alumnos trabajen equipo para hacer un desarrollo porque el trabajo en equipo es uno de los temas de la materia. Creemos que lo optimo es que sean equipos de 3 alumnos. Obviamente la cantidad de alumnos que se anotan en la materia no siempre es múltiplo de 3. De hecho, en base a la información que tenemos, este segundo cuatrimestre de 2020 no lo será.

Entonces se nos ocurrió que dado que la materia se dictará en forma completamente online podríamos aceptar como alumnos a gente externa a la carrera o incluso externa a la universidad. Algunos puntos importantes a considerar para aquellos que estén interesados:

  • La materia se dictará los miércoles de 18 a 22 en forma online
  • Adicionalmente al tiempo de clase, la materia requiere una dedicación de unas 6 horas semanales para estudiar y hacer tareas
  • Respecto de los temas, vemos los temas del SWEBook con un enfoque adaptativo y muy «hands-ons». En términos concretos podríamos decir que estudiamos y practicamos lo que podría denominarse como «Extreme Programming Moderno»
  • Aquí, aquí y aquí comparto algunos links para que tengan una mejor idea de la materia

De Subversion a Git, el problema no es la herramienta

Luego de varios años volví a encontrarme en un cliente con Subversion y la decisión de migrar a Git.

La principal dificultad que he encontrado en este tipo de migraciones viene dado por un uso incorrecto de Subversion. Este uso incorrecto creo que es consecuencia de varias cuestiones:

  1. Desconocimiento de prácticas básicas de configuración management
  2. La flexibilidad (o permisividad) de Subversion en lo referente a la estructura de directorios
  3. La «tentación» de usar el Subversion como si fuera simplemente un file-system compartido

Es a partir de estas cuestiones que es factible encontrarse con repositorios Subversion sin una linea base y/o con una cantidad de sin sentido de branches. A esto se suma el hecho de utilizar un único repositorio Subversion para todos los proyectos de la organización.

Como suele ocurrir, el problema no radica en la herramienta sino en la forma en la que utilizamos. Un martillo no parece ser una herramienta apropiada cuando lo queremos utilizar para revolver el té.

Por otro lado Git ya tiene incluido en su diseño algunas cuestiones que «obligan» a tener ciertas prácticas básicas de configuration management o que al menos limitan ciertas barbaridades que el usuario pueda tentarse de hacer.

En mi experiencia cuando se utiliza Subversion de acuerdo a las recomendaciones del SvnBook la migración a Git resulta bastante simple. Al mismo tiempo, si bien existen herramientas para migrar de Subversion a Git la estrategia que más he utilizado es «congelar el Subversion», mantenerlo como almacenamiento de versiones históricas y arrancar con un repositorio Git con tan solo la versión de la línea base.

Finalmente un detalle importante al empezar con Git es hacer el esfuerzo de entender mínimamente como funciona. Si lo usamos integrado con un IDE, corremos el riesgo de utilizar Git como si fuera Subversion y comprarnos así varios problemas o simplemente desperdiciar ciertas capacidades de Git. Luego de trabajar en varios proyecto de migración, en 2015 grabé una serie de videos sobre Git para explicar algunos principios básicos de su funcionamiento, los pueden encontrar aquí.

Implementando Feature Toggles en C# con Microsoft.FeatureManagement

Se conoce como Feature Toggles (o feature flags) a la capacidad/funcionalidad de disponibilizar (prender/apagar) una funcionalidad en base a un determinado criterio. En mi proyecto veníamos usando esta técnica casi desde que empezamos y en particular la usamos para habilitar funcionalidades gradualmente a distintos grupos de usuarios. De entrada hicimos nuestra propia implementación de feature toggles, la cual ofrecía ciertas capacidades acotadas pero que para nuestro escenario resultaban suficientes.

Nuestro Product Owner se entusiamó con esta capacidad de «togglear» funcionalidades y entonces decidimos analizar una solución de toggles más robusta y flexible. Es así que comenzamos a analizar las opciones listadas en el sitio FeatureFlags.io. Por otro lado nos encontramos con el componente Microsoft.FeatureManagement. A simple vista este componente nos resultó el más atractivo de los que habíamos visto y por ello decidimos probarlo.

El resultado fue contundente, nos llevó aproximadamente 1 hora reemplazar nuestro componente casero por el componente de Microsoft y lo que pensábamos que sería una prueba de concepto terminó completamente integrado en nuestra aplicación.

En forma resumida el uso de este componente requiere de los siguientes pasos.

1. Agregar el paquete

Agregar la referencia al paquete Microsoft.FeatureManagement.AspNetCore

2. Agregar la configuración

La configuración se puede poner en un archivo json o directamente se puede incluir en el archivo de configuración de la aplicación (appsettings.json).

"FeatureManagement": {
   "funcionalidad1":true,
   "funcionalidad2": false,
   "funcionalidad3": {
      "EnabledFor": [
         {
            "Name": "Targeting",
            "Parameters": {
            "Audience": {
              "Users": [
                "juan",
                "maria"
               ]
            }
          }
        }
  }

Este fragmento de configuración indica que la «funcionalidad1» está encendida, que la funcionalidad2 está apagada y que la funcionalidad3 está encendida solo para los usuarios juan y maria.

3. Agregar los toggle points

Los toggle points son los lugares en nuestro código donde se consultan los toggles para verificar si una funcionalidad está activa o no. Esto es: en el punto de entrada a la funcionalidad1 tengo que ver si la misma está disponible o no. Para esto utilizamos la clase featureManager 

if(featureManager.IsEnabledAsync("funcionalidad1"))
{
   ....
}

Dependiendo de cómo esté definido el toogle puede que tengamos que adicionalmente darle al FeatureManager información contextual para que pueda consultarse la funcionalidad.
El componente de Microsoft ofrece también featureGates que pueden ser utilizados en los controllers/actions de una aplicación web y así evitar la ejecución en caso que la funcionalidad indicada no esté habilitada.

[FeatureGate("funcionalidad1)]
public class MyController : Controller
{
    …
}

Este componente ofrece out-the-box la capacidad para definir evaluación de toggles dependindo de rangos horarios, usuarios y grupos de usuarios. En caso que esto no sea suficiente también es posible crear extensiones para definir criterios propios de evaluación.

Generación de reportes de cobertura con ReportGenerator

Hace un tiempo escribí sobre medición de cobertura en Net Core utilizando Coverlet. Como indiqué en ese artículo Coverlet tiene la capacidad de medir la cobertura y generar reportes al respecto en distintos formatos. Pero hay una limitación: cuando nuestra cobertura no es del 100% querremos saber puntualmente que métodos/líneas no están cubiertos y si bien Coverlet genera reportes con esta información, los mismos no son en formatos «amistoso para humanos» sino que son en formatos particulares para ser procesados por otras herramientas. Es aquí donde entra en juego ReportGenerator.

ReportGenerator es una herramienta que a partir de un reporte de cobertura en formato «no amistoso para humano» (opencover, cobertura, jacoco, etc) genera reportes en formatos «amistoso para humanos» (csv, html, etc). Esta herramienta está construida en .Net y puede instalarse de varias formas diferentes dependiendo de la plataforma en la que uno pretenda utilizarla. Más aún, la propia herramienta provee una página donde a partir de completar un conjunto de opciones se generan las instrucción de instalación y ejecución correspondientes.

Ahora bien, para poder generar un reporte con ReportGenerator a partir de una medición de cobertura generada con Coverlet hay que indicarle a Coverlet que genere el resultado en un formato que sea compatible con ReportGenerator, por ejemplo formato OpenCover. A continuación comparto un ejemplo.

dotnet test Domain.Tests/Domain.Tests.csproj /p:CollectCoverage=true /p:CoverletOutput=../coverage.info /p:CoverletOutputFormat=opencover

reportgenerator -reports:coverage.info -targetdir:"coverage"

Preparando Ingeniería de Software UNTreF 2020

Ya está definido que este año tendremos que dictar la materia en modalidad completamente a distancia y por ello tendremos que hacer algunos ajustes en la dinámica de las clases y de la materia en general. Al mismo tiempo tenemos ciertas dudas sobre la cantidad de alumnos que cursarán.

Por esto es que hemos habilitado este formulario para llenen que los alumnos interesados en cursar Ingeniería de Software este segundo cuatrimestre de 2020 y de esta forma poder hacer una planificación con menos incertidumbre. Quisiéramos que llenen este formulario todos los alumnos que tengan intención de cursar la materia incluso cuando no reúnan todas las correlativas necesarias.

De paso compartimos aquí algunos detalles de la forma en que dictamos la materia:

  • Intentamos cubrir los temas de la materia con materiales de estudio actualizados y herramientas de uso de frecuente en la industria
  • Para las cuestiones de programación utilizamos Ruby
  • Como herramienta de soporte para las tareas de programación y el trabajo grupal utilizamos GitLab
  • La materia requiere una dedicación semanal de entre 4 y 6 horas adicionales al tiempo de clase
  • La dinámica de evaluación es continua, con tareas semanales que incluyen lecturas, videos, ejercicios de programación y cuestionarios.
  • Este artículo describe formalmente la dinámica de la materia
  • Aquí pueden encontrar varios sobre el dictado de la materia en cuatrimestres anteriores

Enseñanza de Métodos Ágiles en Argentina

Corté el título porque quedaba demasiado largo, pero para ser preciso debería haber puesto: Enseñanza de Métodos ágiles de Desarrollo de Software en Argentina. Estado del Arte. Este es el título formal del trabajo con el que completé mi carrera de Especialista en Tecnología Informática Aplicada en Educación (UNLP).

Este trabajo es un estudio formal y sistemático basado en métodos empíricos de investigación. El trabajo completo tuvo 3 fases.

La primera fase, a fines de 2018, fue incluso antes de comenzar formalmente con el trabajo de especialización. Hice una encuesta entre estudiantes en CONAIISI 2018. El resultado de esa encuesta fue un artículo titulado en «Initial Assessment of Agile Development in theUndergraduate Curricula» que fue publicado en el Workshop Brasilero de Métodos Agiles que se llevó a cabo en el contexto de Agile Brazil 2019.

La segunda fase, ya en el contexto de la especialización, consistió en un mapeo sistemático de literatura que fue publicado en el XXV Congreso Argentino de Ciencias de la Computación con el título «Introducing Agile Methods in Undergraduate Curricula, a Systematic Mapping Study«

Hasta este punto, toda la información recolectada no resultaba suficiente para tener un entendimiento lo suficientemente certero sobre el estado de la enseñanza de métodos ágiles en Argentina. Entonces ya en la fase 3 realicé una encuesta a docentes de Ingeniería de Software, que es el área donde típicamente se estudian métodos ágiles. Para esto contacte en forma personalizada a los docentes de Ingeniería de Software de la universidades pertenecientes a la Red de Universidades Nacionales con Carreras de Informática, un organismo que agrupa tanto a instituciones públicas como privadas.
Logré así recolectar respuestas de 69 cursos pertenecientes a 44 instituciones distintas. Según los datos provistos por de la Secretaría de Políticas Universitarias del Ministerio de Educación de la Nación , las instituciones relevadas en mi estudio «generaron» en ~77 % de los egresados de las carreras universitarias de informática en el país en el 2017. Esto da cuenta de la representatividad de la muestra analizada.

Entre los resultados encontrados, destacan:

  • Los métodos ágiles son enseñados en el 97.7 % de las carreras de grado relevadas. Más aún, en el 54,5 % de los casos, los métodos ágiles se estudian en el contexto de varias materias que también abordan otros temas.
  • La gran mayoría de los encuestados (83.8 %) dicta sus materias de forma completamente presencial. Este hecho puede estar influido por cuestiones de regulaciones ya que muchas instituciones no admiten alternativas de educación no presencial y exigen asistencia física a las clases. Sin embargo, el 70 % de los encuestados utiliza en sus materias un campus virtual, lo cual representa una extensión del aula y por ende cierto grado de hibridación en la modalidad de enseñanza.
  • El 77 % de los encuestados indicó enseñar Scrum, pero tan solo el 53 % indicó enseñar Retrospectivas, que sin duda es una de las prácticas más importantes de Scrum. Iteration Planning, Iteration Review y Daily Standup son todas prácticas centrales de Scrum y su porcentaje de enseñanza es bastante menor al de Scrum
  • Respecto de las prácticas ágiles; User Stories, Iteration Planning, Planning Pocker, Retrospectives e Iteration Review son las cinco prácticas más enseñadas, las cinco por encima del 50 %. Cabe destacar que estas cinco prácticas pertenecen todas a la categoría “Practicas de gestión”.

Los interesados en leer el trabajo completo lo pueden descargar desde este link.

El próximo lunes 17 a las 19.00 hs voy a hacer un sesión online para compartir los resultados de este estudio y debatir al respecto. Si estas interesado en participar, puedes registrarte aquí.