Sobre el WORP & QSconf

Empiezo por el final.

El viernes estuve participando de la Quality Sense Conference. Resulta que Federico Toledo (socio fundador de Abstracta) tiene una podcast llamado Quality Sense. Dado que a raíz del WORP habría en Montevideo varios referentes de temas de calidad, aprovechó para hacer esta conferencia y de esa forma ofrecer de forma abierta y gratuita una oportunidad de aprendizaje y networking para la comunidad.

Por restricciones personales de agenda no pude participar de toda la conferencia pero pude escuchar algunas charlas e incluso dar una charla yo mismo. En el canal de YouTube de Abstracta está disponible todo el stream de las charlas en castellano y en inglés.

Pero antes de la Quality Sense conf estuve participando del WOPR: Workshop On Performance and Reliability. Este workshop tiene un formato reducido y cerrado, o sea: el número de participantes puede variar levemente pero suele rondar las 25 personas y la participación es por postulación e invitación (ya escribí sobre esto en un post anterior). ¡Brutal! (dirían mis colegas Venezolanos). Fui en un modo muy «exploratorio» y completamente entregado a experimentar con un formato nuevo para mi. Y sinceramente todo estuvo muy por encima de mis expectativas, tanto formato como contenido.

A nivel de contenido me traje un montón de cuestiones para investigar y probar. Hay que destacar aquí que todo el contenido en el WORP (salvo algunas excepciones) es presentado en formato de experiencia, o sea: la gente no va contar una idea, ni a explicar conceptos, sino que los participantes van a contar una experiencia. Entonces todas las interacciones y el contenido compartido se desprenden de las experiencias compartidas por los participantes.

En cuanto al formato hay varias cuestiones interesantes:

  • En primer lugar el formato reducido habilita a explorar los temas con bastante profundidad al mismo tiempo que simplifica la logística de organización.
  • El hecho de que sea cerrado les da a los organizadores la oportunidad de seleccionar a los participantes y a partir de ello tener cierto control sobre el contenido pudiendo así asegurar diversidad y alineamiento en los temas.
  • La dinámica de interacción en el evento es en parte posible también por la cantidad reducida de participantes (aunque el facilitador comentó que utilizó la misma dinámica en reuniones con cientos de personas). La dinámica me gustó tanto que estoy considerando armar otro workshop con esta misma dinámica (en breve más novedades al respecto).

Luego de pasar mis notas sobre las experiencias presentadas escribiré otros post al respecto.

Continuará…

Pair Programming: prejuicios y beneficios

Sensación: pair-programming es un práctica muy popular en el sentido de que mucha gente (cree que) la conoce

Sensación: gran parte de los que dicen conocer la práctica, no la han puesto en práctica, o no la han practicado correctamente y hablan desde el desconocimiento y el prejuicio.

Dato: es una práctica muy poco usada (hay varios estudios que lo así lo indican, uno de ellos el trabajo sobre prácticas ágiles que hicimos en untref)

Lo curioso es que es una práctica que ha sido ampliamente estudiada hace ya bastante tiempo. Los estudios han dejando en claro los beneficios de esta técnica pero parece que las evidencias no han resultado suficientes para que la industria deje de lado sus prejuicios de «pérdida de productividad». Pero creo que también hay otro componente: a algunos programadores (no pocos) no les gusta hacer pair-programming pues prefieren hacer «solo-programming».

En fin, comparto algunos artículos sobre pair-programming que han resultado muy interesantes:

Si aún dudan sobre la efectividad y beneficios de Pair-Programming no duden en leer estos artículos.

Argenzuela: semana 8

Completamos la séptima semana/iteración de proyecto y creo que ya estamos acomodados como equipo. Venimos haciendo unos 6 o 7 ítems por iteración, lo cual equivale a unos 13 puntos. Estamos haciendo un buen slicing de ítems a punto tal que casi podríamos hablar de cantidad de ítems por iteración en lugar de puntos. El siguiente gráfico muestra la cantidad de puntos planificados (gris) vs. la cantidad de puntos entregados (verde). La primera iteración se ve como fuera de lugar porque se entregaron varios ítems que un miembro del equipo había estado trabajando unos días antes del inicio del proyecto.

Las piezas centrales de la arquitectura y el walking skeleton ya están construidos, parte de la solución ya está productiva y la próxima semana ejecutaremos las pruebas de performance.

Esta semana ya comencé gradualmente a desvincularme del equipo para en breve pasar a trabajar con otra célula del mismo producto.

WOPR, QSConf y Testing 3.0

Del 5 al 10 de diciembre voy a estar en Montevideo para participar de estos dos eventos.

El Workshop on Performance and Reliability (WOPR) es una evento cerrado que se accede por postulación/invitación y que tiene ~25 cupos por edición. Hay un grupo de organizadores que asegura la continuidad del evento (esta será la edición 29), luego hay una empresa del rubro (performance & reliability) que «hostea» el evento y se encarga de las cuestiones logísticas. Los interesados en participar envían una propuesta, la misma es evaluada por los organizadores y en base a eso se envían las invitaciones. En esta edición la empresa host es Abstracta, pueden encontrar más información al respecto del WORP en este post de Federico Toledo.

A continuación del WORP y organizado también por Abstracta, tendrá lugar el viernes 9 de diciembre en la torre Antel, la Quality Sense Conf. Esta conferencia será gratuita y en formato híbrido. En este contexto voy a estar dando una charla que he titulado «Testing 3.0» :

Las estrategias de testing y el rol de tester ha ido cambiando a lo largo del tiempo influenciado, entre otras cuestiones, por los avances tecnológicos y metodológicos. Desde los procesos «cascadosos» y las aplicaciones mainframes, pasando por los métodos ágiles, las aplicaciones de escritorio, a las aplicaciones web, mobile y el auge de DevOps. Los desafíos que enfrenta la industria del software en la actualidad han generado importantes desafíos y oportunidades para quienes trabajan en cuestiones de testing y calidad en general. En esta charla veremos algunas de esas oportunidades y cómo prepararnos para sacarle el mayor provecho. 

Temas centrales de la enseñanza de la Ingeniería de Software

La facultad de Ingeniería de Universidad de Buenos ofrece dos carreras en el área de sistemas: Ingeniería en Informática y Licenciatura en Análisis de Sistemas. Son dos carreras distintas en el sentido que la licenciatura no es un paso intermedio de la ingeniería. Pero obviamente hay ciertas materias que son «compartidas» por ambas carreras, típicamente las materias de algoritmia, estructura de datos, sistemas operativos y algunas materias de ciencia básica.

En mí época de alumno (allá por comienzos del siglo) ambas carreras compartían dos materias de ingeniería de software que se llamaban: Análisis de Información y Técnicas de Diseño. Tal como los nombres lo sugieren, una estaba centrada en cuestiones de requisitos y la otra en cuestiones de diseño y ambas se cursaban secuencialmente. En el año 2015 la licenciatura modificó su plan de estudio y entre otras cuestiones cambio estas materias reemplazándolas por Métodos y Modelos de la Ingeniería de Software 1 y 2 (comúnmente conocidas como MeMo1 y MeMo2). Por su parte la ingeniería continua aún hoy en día con las mismas dos materias que cursé yo hace 20 años.

Las dos nuevas materias introducidas por la licenciatura están pensadas en línea con la forma en que se desarrolla el software actualmente: de manera iterativa e incremental. Esto implica que en ambas materias se estudia «lo mismo» con distinto pero con distinto foco/profundidad. Ambas materias cubren las distintas actividades del desarrollo de software (requisitos, análisis, diseño, gestión, programación, prueba, etc, etc).

La primera materia (MeMo1) tiene más foco en las primeras actividades del proceso de desarrollo pero cubriendo también cuestiones de diseño, programación y despliegue. La segunda materia (MeMo2) tiene más foco en las cuestiones «del tramo final» incluyendo programación testing, gestión de ambientes y despliegues. Obviamente que hay cierta superposición teórica de temas y es intencional: cuestiones que en una materia tal vez se ven en solo teoría en la otra se ven en la práctica.

A partir de la iniciativa de la Facultad de Ingeniería de rehacer los planes de estudio de todas las carreras, junto a Carlos Fontela y Sergio Villagra comenzamos a trabajar en un propuesta para la enseñanza de la Ingeniería de Software de cara a determinar una estrategia unificada para las 2 carreras. Dado que ambas carreras tienen un perfil distinto, el desafío estaba en determinar el núcleo mínimo común para ambas carreras permitiendo que luego cada carrera acorde a su perfil pueda profundizar contenidos/materias adicionales según considere necesario. En lo que resta de este artículo voy a compartir algunos de los puntos que me parecen más importantes de la propuesta en la que trabajamos.

Antes de hablar de potenciales materias y sus contenidos, hay 2 premisas que tomamos como puntos de partida:

  1. Hay contenidos de ingeniería de software que deben ser abordados en forma temprana y transversalmente en todo el plan de estudio. Ejemplos de esto son prueba unitaria automatizada y versionado.
  2. La ingeniería de software debe cubrir todo el proceso de desarrollo, desde la formulación de la idea hasta la puesta en producción. Lo primero es algo muy aceptado y muy presente en la bibliografía, podríamos incluso llamarlo Ingeniería de Requisitos. Lo segundo es algo un poco más polémico y menos habitual en la academia pues incluye cuestiones como despliegues, ambientes, infraestructura y hasta algunas cuestiones operación, lo que comúnmente se engloba bajo el término «DevOps».

Continuará….

Libro: Modern Software Engineering

Hace un par de semanas terminé de leer este libro escribo por David Farley. Me gustó. Mucho. Ofrece fundamentos acompañados con ejemplos concretos, teoría y práctica muy bien combinada. Industria y academia complementadas en la medida justa.

Por momentos el libro se torna bastante filosófico y a continuación baja el nivel de abstracción a cuestiones muy concretas. Son muy pocos los libros que visto haciendo oscilación. Al compararlo con otro libros que llevan el término «software engineering» como los clásicos de Pressman (o Sommerville), siento que algunos de los dos tiene un título incorrecto.

Tal vez el hecho de que el libro me haya gustado tanto esté levemente influenciado porque describe las cuestiones que intento transmitir en mis materias, ¡ja!

Sin embargo, no es un libro que utilizaría para una materia introductoria de Ingeniería de Software, creo que para poder sacarle buen provecho y poder seguir algunos los argumentos es necesario ya tener asimiladas ciertas cuestiones fundamentales de la disciplina.

Prácticas técnicas para Scrum Masters

Desde 2006 vengo trabajando con equipos desarrollo que intentan trabajar en una dinámica «tipo Scrum». Sin embargo son contadas con los dedos de una mano las ocasiones que he trabajado con un Scrum Master que aporte valor al equipo desarrollo más allá de los rituales estrictos de Scrum. Lo que ocurre es que a medida que el equipo va ganando experiencia en Scrum el aporte del Scrum Master se va diluyendo si el Scrum Master se limita a aportar estrictamente desde Scrum.

Sin embargo, los equipos de desarrollo afrontan diversos desafíos que van más allá de las reglas de Scrum y de las cuestiones de programación. Muchos de esos desafíos representan oportunidades para que un Scrum Master agregue valor al equipo. Pero para eso es necesario que el Scrum Master se familiarice con algunas cuestiones de indole técnica que típicamente no forman parte del camino de formación de un Scrum Master. A esto se suma una situación cada vez más habitual: gente desempeñándose en rol de Scrum Master que no viene del mundo IT. No resulta extraño hoy en día encontrarse con equipos de desarrollo cuyo rol de Scrum Master es ocupado por una persona con formación en psicología, arte, marketing o ciencias sociales.

Es por esto que hace un tiempo, junto a Martín Alaimo, comencé a trabajar en el diseño de un entrenamiento para Scrum Masters de cara a ayudarlos adquirir conocimientos y habilidades para poder sumar valor a sus equipos de desarrollo más allá de lo que propone Scrum.

El curso está pensado para personas en el rol de Scrum Master (o facilitador de equipo en términos más generales). No es necesario tener formación el IT/programación pero sí es necesario tener experiencia de campo trabajando con un equipo de desarrollo.

El curso será en modalidad online, con 4 encuentros en vivo (uno por semana) y varias actividades semanales a lo largo de las 4 semanas del curso. Pueden encontrar más información aquí.

Nuevo proyecto a la XP: Argenzuela

Hace unas dos semanas comencé a trabajar en un nuevo proyecto. Yo en Argentina y el resto del equipo en Venezuela y de ahí el «Argenzuela», ¡ja!. En el equipo somos 3 Devs, 1 tester, «proxy» Product Owner (que está en el día a día) y un Product Owner con participación más esporádica.

Al margen del (mal) chiste el proyecto consiste en desarrollar la integración de una aplicación con un Sistema CRM (Customer Relationship Management).

En términos de tecnología estamos trabajando con Ruby y RabbitMQ. En términos de infraestructura la aplicación Ruby la corremos dockerizada en Heroku y para el Rabbit usamos el servicio de Amazon. Como herramientas de gestión/desarrollo estamos utilizando el stack de Atlassian: Jira, Confluence y Bitbucket.

Trabajamos «a la XP», iteraciones semanales, TDD, CI/CD, diseño simple, refactoring, mucho pairing y otras yerbas varias.

El proyecto tiene un par de desafíos técnicos y de negocio interesantes pero al margen de eso me gusta la dinámica que equipo que estamos construyendo. Continuará…

Sobre la formación de un Scrum Master

El trabajo de Scrum Master es uno de los que ha experimentando una gran demanda de parte de la industria en los últimos y también un gran interés de parte de los profesionales. Los cursos certificados de Scrum Master ofrecidos por la Scrum Alliance son muy requeridos, tengo varios colegas que se dedican a dictar estos cursos y desde hace años llenan cada uno de los cursos que dictan e incluso tienen gente en lista de espera.

Sin embargo, al margen de la popularidad y lo bien que puedan dictarse los cursos de Scrum Master, no resulta factible formar un Scrum Master con un curso de 2 días. De hecho los varios trainers que dictan estos cursos están de acuerdo con esto. El curso es un punto de partida ¿y luego qué? ¿otro curso? No lo sé. Yo no hice el curso y no me considero un especialista en Scrum. Estudié Scrum por mi cuenta y lo he utilizado muchas veces durante años. Incluso he llegado alguna vez a ocupar el rol de Scrum Master (si si, con mi estilo particular, pero Scrum Master al fin, !ja!).

Para alguien que viene trabajando en desarrollo de software, imagino que su formación como Scrum Master comienza siendo parte de un equipo que utiliza Scrum y que cuenta con un Scrum Master. Entonces uno va aprendiendo de la mano de su Scrum Master, tomando gradualmente algunas tareas y haciendo una transición gradual de su rol.

Para alguien que no viene trabajando en desarrollo de software imagino que el camino debería comenzar sumándose a un equipo que utiliza Scrum y que ya tiene un Scrum Master. Entonces el aspirante a Scrum Master (¿Scrum apprentice?) trabaja junto al del equipo Scrum Master inicialmente como observador y gradualmente tomando tareas que le delega el Scrum Master. Esto es básicamente el modelo tradicional/medieval de formación de oficios. Me consta de varias empresas que utilizan este modelo para la formación de desarrolladores y testers pero ¿habrá alguna que lo use para la formación de Scrum Masters?

Un modelo de branching con «condimentos»

Desde hace años en mis desarrollos hago Trunk-Based Development (TBD) y también «evangelizo» en esta técnica. Pero lamentablemente me suelo encontrar que en muchos casos los equipos no se encuentran en condiciones para trabajar de esta forma. TBD requiere del uso simultáneo de un conjunto de técnicas complementarias sin las cuales su utilización resulta impracticable (o demasiado riesgosa). Obviamente que también están los «detractores» que creen que TBD «no funciona» o que «no es bueno», resulta curioso que muchos de estos detractores nunca probaron TBD seriamente.

En fin, el tema es que si no utilizamos TBD hay que buscar otra alternativa. Dos técnicas bastante populares en la actualidad son Gitflow y GitHub flow. Adicionalmente hay una práctica que he visto bastante difundida de asociar branches a ambientes la cual está bien para proyectos chicos/triviales pero que personalmente me parece inconveniente para proyectos más grandes/complejos.

Actualmente estoy colaborando con un equipo que digamos no está en condiciones de hacer TBD (o dicho de otra forma: al cual aún no logré convencer de hacer TBD). Sin embargo el modelo de branching que hemos acordado me resulta bastante convincente. La cuestiones es así:

  1. Para desarrollar cada funcionalidad se crear un branch (feature branch) a partir de la rama principal(main).
  2. En cada commit+push se ejecuta el linter y un conjunto de pruebas «unitarias/de componentes» automatizadas.
  3. Una vez el developer completa la funcionalidad (code complete), se genera un tag, una imagen docker y la misma es desplegada a un ambiente de prueba (existen varios ambientes de prueba) donde se realizan pruebas manuales.
  4. Al mismo tiempo se instancia un arnés de prueba armado con docker, donde se ejecutan un conjunto de pruebas de aceptación automatizadas.
  5. Si la prueba manual y las pruebas de aceptación automatizadas resultan exitosas, la rama es integrada en la rama principal, la imagen docker es promovida (no se la vuelve a buildear) y es desplegada a un ambiente de staging.
  6. En staging se realizan otro conjunto de pruebas (con datos más parecidos a los productivos) y todo está ok, la imagen se vuelve a promover y queda lista para ir a producción.

Si, es un clásico esquema de feature branch pero con «condimentos» que en muchos equipos no están presentes. Destaco aquí las pruebas automatizadas, el arnés de prueba «portable» creado con docker y el hecho de que la imagen docker se crea una única vez y es promovida a medida que pasa de un ambiente a otro.