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á…