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í.

Y un día no separamos (una historia de crecimiento orgánico)

Hasta aquí…

Comenzamos el proyecto con un equipo completamente nuevo. Según pasaron las iteraciones nos fuimos consolidando como equipo a la vez que sumamos nuevos miembros. De esta forma llegamos a completar la iteración 12 siendo 14 personas. Suficiente, hora de separarnos.

Previamente, allá por la iteración 7, había contado de la previsibilidad de este equipo, un propiedad que el equipo logró mantener a pesar de seguir creciendo. En términos generales, analizando las 12 iteraciones, vemos que la diferencia de trabajo planificado vs trabajo completado no supera el 18%. Esto significado que si este equipo planifica entregar 10 ítems, hay altas probabilidades que al final de la iteración haya completado al menos 8 ítems. El siguiente gráfico muestra el trabajo planificado vs. el trabajo completado para las últimas 3 iteraciones.

Creo que esta característica de previsibilidad es en gran medida consecuencia de un trabajo disciplinado y un crecimiento orgánico.

Algunas métricas de lo realizado hasta aquí:

  • 45 releases a producción
  • 6 meses de trabajo iterativo
  • 382 casos de prueba automatizados que incluyen pruebas unitarias, de integración y aceptación
  • Una cobertura de código superior al 80%

De aquí en más…

Separamos el equipo y separamos el código para permitir que cada equipo sea lo más autónomo posible, pudiendo regular su velocidad delivery sin dependencias. Cada equipo trabajará enfocado en su (sub)producto con sus propios repositorios, infraestructura, microservicio y microfrontend.

Ahora el gran desafío es ver si podemos lograr que ambos equipos mantengan el nivel de efectividad y desempeño logrado hasta el momento.

En un par de meses les cuento.

Adaptación online del Kanban Pizza Game

El Kanban Pizza Game es una actividad tipo simulación, utilizada para enseñar los principios Kanban e implica el trabajo con materiales de librería (papel, tijeras, pegamento, etc). Usualmente utilizamos esta actividad en la clase Lean/Kanban en MeMo2.

Ayer dimos esta clase y ante la imposibilidad de hacerla en forma presencial, debido a la situación de pandemia, decidimos adaptarla para hacerla en forma online. Para ello utilizamos la herramienta Miro.

La actividad salió muy bien, los alumnos dieron feedback muy positivo. Para los interesados aquí publicamos una breve guía de como preparar y facilitar la actividad.

No más cursos de TDD

Estaba escribiendo una respuesta a un tweet en un hilo sobre developer testing y espontáneamente tuve esta revelación: no dictar más cursos de Test-Driven Development.
Si bien no lo tenía listado en mi catálogo de cursos, tenía un curso de TDD que venia dictando en forma privada a pedido de algunas empresas. Pero ya no más. La cuestión es simple: TDD es muy difícil de aplicar en proyectos de complejidad no trivial para gente que recién empieza con TDD y no creo que un curso de 1 o 2 días pueda bastar para que alguien aprenda la técnica y esté en condiciones de aplicarla en un proyecto no trivial apenas terminado el curso. Pero ojo, esto no significa que vaya a dejar de enseñar TDD. No, de ninguna manera. Simplemente voy a cambiar de estrategia: voy compartir gratuitamente un par de videos explicando la técnica (o incluso tal vez recomiende cursos de colegas) y luego ofreceré a los interesados trabajar conjuntamente en su proyecto para aplicar TDD.

Si bien yo uso TDD en mis proyectos, me llevó años y mucha perseverancia poder hacerlo una forma fluida y eficiente. Pero como he dicho más de una vez no considero TDD como una práctica de “efectividad universal”, a mi me resulta eficiente programar haciendo TDD, pero no significa que vaya a resultarle igual a todo el mundo. A mis alumnos les exijo que hagan TDD cuando programan para la materia porque es parte del plan de estudio. A mis compañeros de trabajo les sugiero que hagan TDD si es lo que hemos acordado como equipo, pero dependiendo del contexto me parece completamente válido que agreguen los tests a posteriori si no gustan hacer TDD.

Dicho esto, si quieren aprender TDD conmigo, no me consulten por cursos, contáctenme en privado y coordinemos directamente para hacer un par de sesiones de TDD sobre su proyecto.

DevOops! tal vez igual sirve

Hace un tiempo escribí sobre algunos malentendidos de DevOps en la práctica, hoy quiero compartir algunas otras situaciones a la luz de una definición formal.

De acuerdo a Len Bass y sus colegas del SEI DevOps tiene 5 pilares fundamentales:

  1. Operaciones como ciudadano de primera categoría en el proceso de software delivery
  2. Involucramiento de los desarrolladores en los incidentes productivos
  3. Un proceso formal de deployment
  4. Continuous Delivery
  5. Infrastructure as Code

Pero en la práctica veo que muchas organizaciones que:

  • Pasan completamente por alto los dos primeros puntos, son cuestiones casi “culturales” que no son triviales de cambiar.
  • Van directo al punto 5, incorporan herramientas para la automatización de infraestructura para lo cual contratan algunas nuevas personas, típicamente bajo del rol de “Ingenieros DevOps”. Hacer esto es muy más simple que pretender cambiar una estructura organizacional o un mindset.
  • El punto 4 lo toman solo parcialmente, invierten en la automatización de pipelines de despliegue (tarea que hacen los recientemente incorporados “Ingenieros DevOps”) pero ni noticia de la automatización de pruebas (claro, los DevOps no automatizan pruebas)
  • El punto 3 lo logran como un efecto colateral de la automatización de los despliegues.

El resultado dista bastante de la idea de DevOps de Bass, pero no es tan malo porque a pesar de ello representa una mejora radical respecto de la situación previa.