Procesos en Scrum

Planificación de sprints

La planificación de Sprint es la etapa inicial en el Sprint de Scrum. Determina el alcance y las formas de hacer el trabajo durante el sprint. Todo el equipo Scrum está involucrado en la planificación.

Un sprint es un período de tiempo claramente definido durante el cual se debe completar un trabajo específico. Un sprint necesita planificación antes de comenzar. En primer lugar, debe determinar la duración y el objetivo del sprint.

En el taller de planificación se acuerda la lista de tareas y el objetivo del sprint. Es importante cargar al equipo con la motivación adecuada para trabajar, para que cada miembro esté enfocado en el éxito.

Si el sprint está mal planificado, esto puede llevar al equipo al fracaso. Los desarrolladores no podrán hacer frente a las expectativas puestas en ellos, porque las tareas resultaron ser poco realistas.

Preguntas a tener en cuenta al planificar un sprint:

• El cliente o propietario del software anuncia el objetivo del sprint, explicando en el camino cómo lograrlo. El equipo de Scrum averigua qué tareas se pueden completar en un sprint futuro para lograr este objetivo.
• Los desarrolladores distribuyen un plan de trabajo entre ellos, que se acuerda con el cliente del software.
• El cliente (propietario) del producto siempre participa en la elaboración del plan de sprint. Él establece una meta y el equipo de programación debe averiguar si se puede lograr en un sprint.
• El plan debe utilizar una acumulación de productos, cuya información se puede agregar al plan.
• Los miembros del equipo deben finalizar la reunión de planificación con una comprensión clara de lo que necesitan para lograr el resultado. Puede mostrar el orden de las acciones futuras en el trabajo pendiente del sprint.

La planificación no debe exceder las dos horas por semana. El Scrum Master debe explicar a todos que hay límites de tiempo. Si todos los problemas de trabajo se resuelven rápidamente, la reunión puede terminar antes de lo habitual. No existe una duración mínima para dicha reunión.

Evaluación de tareas

Evaluar la complejidad del trabajo no necesita exagerar. El proceso de planificación no necesita una evaluación exacta, sino al menos aproximada, de la complejidad del desarrollo. El equipo no solo debe comprender el objetivo del sprint, sino también comparar el objetivo con las capacidades de su equipo.

Para evaluar la complejidad, puede usar las tallas de ropa habituales para todos (L, XL, XXL). Por supuesto, esto no da una garantía de precisión, pero aún así.

Para que la evaluación de la complejidad sea más precisa, se necesita un entendimiento mutuo. Los miembros del equipo deben compartir abiertamente sus opiniones y no tener miedo de hacer preguntas al propietario del producto.

Las críticas hacia el equipo una vez finalizado el trabajo pueden llevar a que a la hora de planificar el próximo sprint las previsiones sean menos optimistas. Esto ayudará al equipo a evitar repetir el error y lo protegerá de una evaluación negativa en el futuro.

Valoración de la dificultad en puntos, puntos y horas

Por lo general, los equipos de desarrollo estiman la complejidad de su trabajo a lo largo del tiempo. Pero algunos equipos ágiles eligen calificar la dificultad en puntos o puntos. Esta es una mejor indicación del costo total requerido para implementar un elemento pendiente u otra tarea asignada.

Los puntos se otorgan en función de la complejidad y el volumen del trabajo. Además, se tienen en cuenta los posibles riesgos. La puntuación con este método ayuda a dividir el trabajo de manera eficaz en pequeños pasos.

Al utilizar regularmente el método de puntuación (puntos) al planificar, los equipos tienen una mejor y más precisa comprensión de cuánto tiempo necesitarán para completar el trabajo. Además, también hay otras ventajas.

• La estimación de tiempo no tiene en cuenta el trabajo que no está directamente relacionado con el proyecto, aunque seguramente aparecerá. Discutir problemas de trabajo a través de un mensajero, celebrar reuniones: todo esto también lleva tiempo para los miembros del equipo.
• Las emociones pueden influir en la elección de las fechas. La puntuación al evaluar el trabajo elimina este factor.
• La evaluación de la complejidad del trabajo y, en consecuencia, la velocidad de realización de las tareas puede ser diferente para cada uno de los equipos. El trabajo con puntos realizados no puede ser considerado como ningún indicador de velocidad. Es decir, no hay presión psicológica en el equipo.
• Al distribuir correctamente los costos de mano de obra y la complejidad, puede dividir rápidamente y sin conflictos los puntos del trabajo realizado entre los participantes.
• La cantidad de puntos recibidos por completar una tarea depende de su complejidad y no del tiempo empleado. Por lo tanto, los programadores pensarán en mejorar su eficiencia y no en cuánto tiempo llevará.

La desventaja de la estimación de la complejidad es que a menudo se utiliza incorrectamente. Por ejemplo, este método no se puede utilizar para evaluar empleados.

Los equipos deben usar un sistema de puntuación para comprender mejor la cantidad de trabajo que se les asigna y priorizar correctamente.

Reunión diaria de Scrum

Los talleres son importantes: en ellos, los miembros del equipo comparten sus opiniones, se comunican y acuerdan acciones futuras. También se necesitan reuniones diarias de scrum para aumentar el espíritu de equipo y anunciar noticias actuales.

Stand-up es una breve reunión de los participantes clave del proyecto: el propietario del software, los programadores y el scrum master. La estructura del stand-up consta de tres preguntas.

• ¿Qué pudimos hacer ayer?
• ¿En qué estamos trabajando hoy?
• ¿Qué nos impide lograr resultados?

Hacer estas preguntas estimula el desarrollo y ayuda a identificar problemas dentro del equipo. Cuando cada participante comunica cómo ayuda a lograr un objetivo común, se mejora el entendimiento mutuo dentro del equipo.

Es importante recordar que no existe una plantilla única sobre cómo realizar stand-ups. Cada equipo realiza reuniones según su propio modelo, en función de las características del equipo.

Y ahora hablemos de lo que se necesita para el stand-up perfecto y familiarícese con ejemplos de stand-ups efectivos.

Primero debe elegir un momento que se adapte a todos. Por lo general, los stand-ups para equipos de la misma oficina se realizan al comienzo de la jornada laboral, entre las 9 y las 10 de la mañana. Esto le da tiempo para planificar mejor su horario para el día. Si los miembros del equipo trabajan en diferentes regiones, se elige un horario que se adapte a todos. Por ejemplo, si algunos miembros del equipo viven en California y Sídney, el stand-up comienza a las 15:30 hora de California. Por supuesto, levantarse después de la cena no es conveniente para todos, pero permite mantenerse en contacto con colegas al otro lado del océano.

Realice un seguimiento de la productividad de pie. No mantenga la reunión por mucho tiempo: la concentración de atención debe permanecer en su mejor momento. Si es posible, realice reuniones de pie que no superen los 15 minutos.

Usa la pelota. Se puede lanzar el uno al otro a su vez. Entonces todos estarán involucrados en la discusión. Este juego ayuda a mantener la atención en el grupo. Utilice la retrospectiva del equipo. Los stand-ups se utilizan en muchas metodologías ágiles, esto no nos impide discutir la efectividad de los stand-ups en las retrospectivas. Alguien se reúne todos los días, otros equipos, un par de veces a la semana. Si es difícil para el equipo beneficiarse del stand-up, encuentre las razones y cambie algo.

Revisión de sprint

La revisión de primavera se lleva a cabo en la etapa final del sprint. Es necesario verificar el incremento de producto y adaptar el backlog. Todo el equipo Scrum y todas las partes interesadas participan en la revisión de los resultados del sprint. La reunión se lleva a cabo en un formato relajado para mejorar la interacción de los participantes del proyecto.

La Revisión de Resultados del Sprint incluye los siguientes elementos:

• El propietario del software muestra lo que se ha completado del trabajo pendiente y lo que no.
• Los programadores discuten qué salió bien, dónde aparecieron las dificultades y cómo se eliminaron.
• El equipo de desarrollo muestra los resultados de su trabajo durante el sprint y qué incremento de producto recibieron.
• El propietario del producto comparte sus pensamientos sobre el trabajo pendiente actual. También da un pronóstico para el próximo objetivo y la fecha límite para su implementación.
• Todos discuten qué es lo mejor que se puede hacer a continuación en función de la evaluación del mercado y los intereses de los usuarios.
• Hay un intercambio de puntos de vista sobre el tiempo, el presupuesto y las perspectivas para aumentar la cartera de pedidos.

El resultado es un backlog actualizado con nuevos objetivos para los siguientes sprints. El backlog se puede cambiar si la situación lo requiere.

Retrospectiva de Sprint

La Retrospectiva de Sprint es un taller que analiza cómo mejorar su flujo de trabajo. También crea un plan de mejora para el próximo sprint. La reunión suele tener lugar después de la revisión del sprint y no dura más de tres horas. Liderando la reunión está el Scrum Master.

Los principales objetivos de la Retrospectiva del Sprint incluyen:

• Análisis de Sprint (trabajo de los participantes, resultados y problemas).
• Analice posibles soluciones para mejorar el flujo de trabajo en sprints posteriores.
• Creación de un plan para la implementación de mejoras por parte de los miembros del equipo durante la implementación del proyecto.

El Scrum Master invita a los miembros del equipo a hacer sugerencias sobre cómo mejorar la eficiencia del desarrollo. El equipo discute las propuestas y sugiere ciertas formas y técnicas para su implementación.

Al final de la Retrospectiva del Sprint, el equipo debe resaltar algunas sugerencias de mejora para implementar en el próximo Sprint. Las sugerencias se pueden implementar en cualquier momento, pero Sprint Retrospective brinda la oportunidad de profundizar en su posible adaptación desde el punto de vista del equipo.

Aquí es donde terminamos nuestra discusión sobre la metodología Scrum. Puede obtener más información al respecto en la documentación temática o en su primer lugar de trabajo.