5.3 - Técnicas y herramientas útiles para los Developers
5.3.1 - Para el desarrollo ágil
Programación por parejas – Pair programming
- En la programación por parejas, 2 Developers trabajan en un solo PC.
- La programación por parejas mejora notablemente la calidad del incremento, sin impactar el tiempo de entrega.
- Una sola persona sola agrega más funcionalidad, pero con menos calidad.
- La calidad alta puede ahorrar costes futuros en un proyecto.
5.3.2 - Para estimar el trabajo
La estimación consiste en definir entre todos una suposición lo más precisa posible, de lo que se puede lograr y en cuanto tiempo. La estimación permite: Analizar dependencias Organizar las actividades prioritarias Definir las mejores técnicas de trabajo para ese Sprint Pronosticar diferentes escenarios (predecir tiempos y fechas de entrega)
Nota: El momento en que se realiza la estimación es durante la Planificación del Sprint.
Estimar con Planning Poker
El póker de planificación consiste en un conjunto de tarjetas numéricas que sirven para realizar la estimación de tareas o historias de usuario.
El póker puede ir numerado de 1 a 10 o utilizando la sucesión de Fibonacci
Estimar por afinidad
Consiste en encontrar las similitudes de las Historias de Usuario y tareas que se van a estimar. Lo que hace el equipo es agrupar los elementos que son similares. La mejor manera de “encontrar similitudes” es visualizar el panorama completo y luego agrupar elementos.
Estimar con Tallas de camiseta (t-shirt)
Se asigna una talla de camiseta a cada Historia de Usuario o tarea (desde XS hasta XXL) que representará el esfuerzo relativo de ese trabajo.
Con esta técnica se elimina la necesidad de la precisión de un modelo numérico, por lo que el equipo puede pensar de manera más abstracta en las estimaciones del trabajo a estimar.
¿Qué pasa cuando se Subestima/Sobreestima un Sprint?
Cuando los equipos Scrum son nuevos, o tienen poca experiencia es típico que sucedan las siguientes 2 situaciones:
Sobreestimación: Cuando los Developers proponen demasiado tiempo para el trabajo del Sprint y acaban mucho antes de la Revisión del Sprint. En este caso el Product Owner agregará más trabajo al Sprint en curso (para que la Revisión no se cambie de fecha).
Subestimación: Cuando los Developers proponen muy poco tiempo para el trabajo del Sprint, lo que puede causar que el incremento no esté completamente terminado. En este caso la Revisión se hace sobre los elementos que se hayan completado y los demás quedan pendientes para ser terminados en el próximo Sprint (la revisión NO se aplaza).