Continuando con las recomendaciones de libros, más específicamente en el ámbito de Ingeniería de Software y Metodologías Ágiles, he dedicado los últimos meses a la lectura de un libro que aborda tanto Scrum como XP desde una perspectiva práctica y experiencial.
A diferencia de los textos convencionales que simplemente exponen conceptos teóricos sobre estas metodologías, este libro ofrece un vistazo íntimo a las prácticas implementadas por una empresa que ha incorporado tanto Scrum como XP en su día a día.
Siguiendo el enfoque de mi publicación anterior, no me sumergiré en un resumen exhaustivo del libro, sino que optaré por compartir las citas que más han capturado mi atención y que considero destacadas.
- Prólogo de Mike Cohn
Son conscientes (equipos que aplican Scrum y XP) de que la mejor manera de encontrar dichos errores es dejar de pensar en el software a un nivel teórico de análisis y diseño y sumergirse en él, ensuciarse las manos y comenzar a construir el producto.
En lugar de mejores prácticas, lo que necesitamos conocer son mejores prácticas y el contexto en que fueron exitosas.
- Por qué la calidad no es negociable
Sacrificar la calidad interna es, prácticamente siempre, una idea terrible. El tiempo que se ahorra es mucho menor que el coste, tanto a corto como a largo plazo.
- Reuniones de planificación de Sprint que duran, y duran…
Aprende a mantener tus duraciones determinadas, aprende a establecer duraciones realistas.
- Definiendo la meta del Sprint
La meta de Sprint debería responder a la pregunta fundamental: “¿Por qué hacemos este Sprint en vez de irnos todos de vacaciones?”.
- Estimando usando cálculos de velocidad
El hecho de que Scrum (y de hecho todo el Desarrollo Ágil de Software y Lean Manufacturing en general) gira en torno al concepto de conseguir que las cosas se hagan completamente, hasta un estado de “potencialmente entregable”.
- Estimación de tiempos usando planning poker
Si pides al equipo que proporcione una estimación, normalmente la persona que entiende mejor la historia será el primero en soltar una. Desafortunadamente, esto afectará severamente a las estimaciones de los demás.
- ¡Por fin acabó la reunión de planificación de Sprint!
La reunión de planificación de Sprint es lo más importante que se hace en Scrum. Emplea una buena cantidad de esfuerzo en hacerla bien, y el resto será mucho más fácil.
- Cómo funciona el tablón de tareas
He descubierto que la simplicidad es extremadamente valiosa.
- Por qué insistimos en que todos los Sprints acaben con una demo
Sin las demos, seguimos consiguiendo enormes montones de cosas terminadas al 99%. Con las demos puede que consigamos menos cosas terminadas, pero estas están realmente terminadas, lo que (en nuestro caso) es mucho mejor que tener una enorme pila de cosas que están más o menos listas y que se pulirán en el próximo Sprint.
- Cambiar o no cambiar
En muchos casos, simplemente identificar el problema es suficiente para que se resuelva por sí mismo automáticamente en el próximo Sprint.
- Descansos entre Springs
En la vida real no puedes estar siempre esprintando. Si siempre estás esprintando, en realidad acabarás haciendo footing.
- Cómo combinamos Scrum con XP
Scrum se enfoca en las prácticas de organización y gestión, mientras que XP se centra más en las prácticas de programación. Esa es la razón de que funcionen tan bien juntas: tratan de áreas diferentes y se complementan entre ellas.
- Programación por parejas
La revisión de código es una alternativa aceptable a la programación por parejas.
- Desarrollo guiado por pruebas (TDD)
Puedes quitarme la casa, la tela y el perro, ¡pero no intentes impedirme hacer Test Driven Development (TDD)!
- TDD en código antiguo
TDD es duro, pero intentar hacer TDD sobre una base de código que no se construyó utilizando TDD desde el principio… Eso sí que es duro.
- Lecciones aprendidas
Si estás atascado con pruebas de regresión manuales y quieres automatizarlas, no lo hagas (a menos que sea realmente fácil). En lugar de eso, construye herramientas que hagan la regresión manual más sencilla.
- Diseño Incremental
Mantener el diseño simple desde el principio y mejorarlo continuamente, en lugar de conseguir que todo funcione desde el principio y entonces congelarlo.
- Integración continua
Es la solución definitiva al viejo problema de “hey, pero sí que funciona en mí máquina”.
- Propiedad colectiva del código
Los equipos que tienen un alto nivel de propiedad colectiva del código han probado ser muy robustos. Por ejemplo, sus Sprints no fallan simplemente porque una persona clave está enferma.
- Ritmo sostenible / trabajo enérgico
La gente comenzó a trabajar en horarios normales (excepto durante algunas crisis de proyecto, a veces). Y, oh sorpresa, la productividad y la calidad mejoraron notablemente.
- Probablemente no puedas renunciar a la fase de pruebas
Si la calidad tiene algún valor para ti, es necesario algún tipo de fase de pruebas de aceptación manuales.
- Incrementar la calidad haciendo menos en cada Sprint
En pocas palabras, ¡no metas demasiadas historias en el Sprint! Si tienes problemas de calidad, o ciclos de pruebas muy largos, ¡haz menos en cada Sprint!
El equipo podrá concentrarse en producir cosas nuevas en lugar de arreglar cosas antiguas que siguen rompiéndose.
- Ciclos de Sprint vs. ciclos de pruebas
Lo primero de todo, maximiza la calidad del código que el equipo Scrum libera.
- Cómo manejar múltiples equipos Scrum
Más desarrolladores = más complicaciones.
- Cuántos equipos crear
¡Haz equipos pequeños sólo cuando no necesiten interferir unos con otros!
- ¿Equipos especializados o no?
Una de las primeras cosas que hicimos al comenzar con Scrum fue disolver los equipos especializados por componentes y crear equipos multi-funcionales en su lugar.
- ¿Redistribuir equipos entre Sprints o no?
“Acoplamiento de equipo”, es decir, si un equipo llega a trabajar unido durante muchos Sprints, usualmente se volverá muy cohesionado.
Asegúrate de que todo el mundo entienda que no pasa nada si lo hacemos todo mal las primeras veces, con tal de que continuemos mejorando a partir de ahí.
- Scrum de Scrums a nivel empresa
Básicamente, los equipos quieren saber qué están haciendo los demás equipos. Así que decidimos que si íbamos a reunirnos y dedicar un tiempo a informarnos unos a otros sobre qué estaba haciendo cada equipo, por qué no dejar que todo el mundo asistiera.
- Cómo gestionamos equipos distribuidos geográficamente
Usamos todos los trucos que podemos para maximizar el “ancho de banda” de la comunicación entre los miembros de equipo separados.
Top comments (0)