Prácticas Técnicas para Scrum Masters y Product Owners

Por Nahuel Garbezza y Federico Zuppa

Introducción

¿Es posible hacer Scrum para el desarrollo de software sin usar prácticas técnicas? ¿Cuáles son las principales que usan los equipos de alto rendimiento actualmente? ¿Cuánto deben saber acerca de éstas, las personas, sin un background técnico, que trabajan en el equipo (Scrum Masters y Product Owners)? Intentaremos esbozar nuestras recomendaciones al respecto en este breve post.

Scrum sin Prácticas Técnicas

Vemos muchos equipos que trabajan con Scrum correctamente, es decir, parten su trabajo en pequeños incrementos que priorizan en un Backlog de Producto, limitan la complejidad y el wip con Sprints, inspeccionan y adaptan pero no prestan atención al aspecto técnico: no realizan tests automatizados, no tienen tiempo para refactorizar, no programan de a pares y tampoco revisan el código antes de mergearse. ¿Es posible desarrollar código limpio (1), que genere valor, de manera sustentable trabajando así? Creemos que no.

En nuestra experiencia, los equipos que lo consiguen usan un conjunto de prácticas técnicas de manera muy disciplinada. La combinación de estas prácticas genera una sinergia que permite aumentar la calidad del código resultante. Por el contrario, los equipos que no las usan se topan con la pared de Scrum (2). Sus implementaciones son flácidas (3) y esto, muchas veces, repercute en la colaboración, en la confianza y en la moral del equipo.

¿De qué Prácticas Técnicas hablamos?

Las prácticas técnicas mencionadas anteriormente (también llamadas prácticas de ingeniería) fueron originalmente introducidas (debería decir popularizadas porque ya existían) con la Metodología de eXtreme programming de Beck/Cunningham/Jeffries. Mencionamos algunas que consideramos importantes:

• Integración Continua: consiste en poner a disposición todos los cambios que los desarrolladores vayan haciendo con frecuencia en un repositorio. Esa frecuencia idealmente debe ser diaria.

• Refactor: Acción de modificar un programa sin alterar su funcionalidad, con el fin de mejorar aspectos no funcionales como su robustez, legibilidad, adaptabilidad, simplicidad.

• Tests automatizados: son pruebas ejecutables que permiten verificar el funcionamiento del código. Permiten tener la mejor velocidad y desarrollar sustentablemente. Representan la mejor documentación del sistema y adicionalmente soportan el resto de las prácticas de ingeniería que permiten alcanzar la excelencia técnica que buscamos.

• Test Driven Development: Técnica de desarrollo basada en el feedback inmediato por parte de tests automatizados para lograr un diseño simple en pequeñas iteraciones (en XP se llamó a la práctica test-first. Luego Beck la popularizó con el nombre de TDD).

Estas son algunas, las que personalmente consideramos más relevantes. Es importante destacar que estas prácticas requieren maestría, lleva tiempo dominarlas. También que se potencian entre ellas. Por ejemplo, tener tests automatizados nos permite refactorizar con confianza (podríamos decirlo de manera opuesta: si no tuviéramos tests, sería imposible refactorizar con la misma confianza).

Finalmente, es importante destacar que estas prácticas no van a tener éxito si el equipo no adopta los valores por detrás (ejemplo: colaboración) y principios (ejemplo: feedback rápido).

¿Cuánto deben conocer los Product Owners y Scrum Masters?

Consideramos que resulta importante que las personas no-técnicas, que trabajan en equipos de desarrollo de software, conozcan de qué se trata el trabajo técnico. Por supuesto no con el nivel de detalle como para poder realizarlo ellas mismas, pero sí para poder comunicarse, entender de qué se trata y colaborar eficientemente.

Es vital entender por qué es importante ser sólido técnicamente y qué hacen los equipos ágiles modernos para lograrlo. Este entendimiento les permitirá, por ejemplo, darles tiempo para refactorizar (o decidir cuándo es el mejor momento) o darse cuenta si el equipo está realmente integrando continuamente (y los problemas que pueden llegar a surgir en caso de no hacerlo). Como equipo, tenemos que tomar diariamente decisiones que involucran aspectos técnicos, de negocios y usabilidad. Poder comprender correctamente a los expertos técnicos permitirá que la comunicación sea mucho más efectiva y las decisiones, mejores.

Referencias:

1) Código limplio - LINK LIBRO 10 Pines por Federico Zuppa

2) Topar con pared con Scrum - LINK LIBRO 10 Pines por Federico Zuppa

3) Implementaciones flácidas de Scrum - Martin Flower