Compartir vía

Scrum y procedimientos recomendados

  • Artículo

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Reuniones de planificación de sprint

Gran parte de la planificación de sprint implica una negociación entre el propietario del producto y el equipo para determinar el enfoque y el trabajo que se va a abordar en el próximo sprint. Resulta útil para calcular el tiempo de la reunión de planificación, lo que lo restringe a 4 horas o menos.

En la primera parte de la reunión, el propietario del producto se reúne con su equipo para analizar los casos de usuario que podrían incluirse en el sprint. El propietario del producto comparte información y responde a cualquier pregunta que su equipo tenga sobre esos casos. Esta conversación puede revelar detalles como orígenes de datos y diseño de la interfaz de usuario. O bien, podría revelar las expectativas del tiempo de respuesta y las consideraciones para la seguridad y la facilidad de uso. El equipo debe capturar estos detalles dentro del formulario de elementos de trabajo pendiente. Durante esta parte de la reunión, el equipo aprende lo que debe crear.

A medida que planee los sprints, puede detectar otros requisitos para capturar y agregar al trabajo pendiente. Asegúrese de que está bien definido y en orden de prioridad.

Además, establecer un objetivo de sprint como parte de los esfuerzos de planificación puede ayudar al equipo a centrarse en lo más importante para cada sprint.

Después de planificar el sprint, se recomienda compartir el plan con las partes interesadas claves.

Puede obtener más información gracias a estos recursos:

Establecer objetivos de sprint

Los equipos de Scrum usan objetivos de sprint para centrar sus actividades de sprint. A menudo establecen este objetivo durante su reunión de planificación de sprints. El objetivo resume lo que el equipo quiere lograr al final del sprint. Al indicar explícitamente el objetivo, se crea una comprensión compartida dentro del equipo del propósito principal. El objetivo del sprint también puede ayudar a guiar al equipo cuando surgen conflictos en torno a las prioridades.

Sugerencias de las trincheras: Definir objetivos de sprint

El objetivo de sprint define lo que el propietario del producto y el equipo consideran como el objetivo final para lograr ese sprint. No es una selección aleatoria de elementos de trabajo pendiente que realmente no tienen una relación, sino un fragmento corto de texto que captura lo que el equipo debe intentar lograr. Normalmente, el propietario del producto aparece con el objetivo de sprint antes de seleccionar muchos elementos para el siguiente sprint. Los elementos de ese sprint deben ajustarse a ese objetivo común.

Los objetivos de sprint pueden estar orientados a características, pero también pueden tener un componente de proceso grande, como la automatización de la implementación o la automatización de pruebas.

Por ejemplo:

  • En este sprint nos centraremos en un caso de usuario sencillo. Lo usaremos para demostrar que la solución propuesta funciona.
  • Este sprint gira en torno a la implementación de las características de seguridad que protegen correctamente la sección de administración del sitio web.
  • Este sprint consiste en integrar las puertas de enlace de pago más importantes para que podamos empezar a cobrar dinero.

Establecer los objetivos de sprint ayuda al equipo a mantenerse centrado. Facilita la definición de la prioridad de las tareas dentro de un sprint y es probable que contribuya a limitar el número de partes interesadas y usuarios finales implicados.

Durante la revisión del sprint, la pregunta más importante que debe formularse es si ha logrado lograr el objetivo del sprint. El número de casos que completó viene en segundo lugar. Si se logra el objetivo, el sprint se realiza correctamente, aunque no se hayan terminado todos los casos.

Colaboración de Jesse Houwing, Visual Studio devops Ranger y consultor sénior que trabaja para Avanade Netherlands.

Sugerencias para reuniones de evaluación de prioridades correctas

La corrección de errores representa un equilibrio con otro trabajo. Use la reunión de evaluación de prioridades para determinar la importancia de corregir cada error en comparación con otras prioridades relacionadas con el ámbito del proyecto, el presupuesto y la programación.

  • Establezca los criterios del equipo para evaluar qué errores corregir y cómo asignar prioridad y gravedad. Los errores asociados a características de valor significativo (o costo significativo de retraso de oportunidad) u otros riesgos del proyecto deben tener asignada mayor prioridad y gravedad. Almacene los criterios de evaluación de prioridades con otros documentos del equipo y actualice según sea necesario.
  • Utilice los criterios de evaluación de prioridades para determinar qué errores se van a corregir y cómo establecer los campos Estado, Prioridad, Gravedad y otros.
  • Ajuste los criterios de evaluación de prioridades en función de dónde se encuentra en el ciclo de desarrollo. Al principio, puede decidir corregir la mayoría de los errores que se evalúan. Sin embargo, más adelante en el ciclo, puede aumentar los criterios de evaluación de prioridades para reducir el número de errores que necesita corregir.
  • Una vez que haya evaluado un error, asígnelo a un desarrollador. Después, el desarrollador puede investigar y determinar cómo implementar una corrección.

Administración de la deuda técnica

Considere la posibilidad de administrar la barra de errores y la deuda técnica como parte del conjunto general de actividades de mejora continua de su equipo. Puede encontrar estos recursos de interés:

Sugerencias de las trincheras: Administración de errores

Administración de errores ágiles: no un Oxymoron
por Gregg Boer, administrador de programas principal, Visual Studio Cloud Services en Microsoft

Solucionar cualquier deuda de errores conocida en cada sprint

En cada sprint, el equipo examina los errores restantes en el trabajo pendiente de errores y dedica capacidad para obtener ese conjunto conocido de errores en cero o cerca de cero. Ya sea un día, una semana o todo el sprint, corrigen primero los errores. Los errores encontrados más adelante, dentro del sprint, no se consideran parte de ese compromiso inicial. A menos que sean de alta prioridad, se colocan en el trabajo pendiente de errores para el siguiente sprint.

Muchos equipos trabajan en una organización basada en compromisos. A menudo, la administración pone un alto valor en la capacidad de un equipo para cumplir sus compromisos. El planeamiento de la capacidad en un conjunto conocido de errores hace que la planificación de sprint sea más determinista, lo que aumenta su posibilidad de cumplir los compromisos. Los nuevos errores detectados durante el sprint no forman parte del compromiso inicial y pueden ser abordados en el siguiente sprint.

Administración de la deuda de errores en una empresa

Una organización que realiza la transición a una cultura en la que la deuda se elimina continuamente es probable que se esté preguntando lo siguiente: ¿cómo se consigue que los equipos reduzcan su recuento de errores sin decirles exactamente qué hacer? El liderazgo quiere que el equipo cambie, y además ofrece a los equipos autonomía para determinar cómo cambian. Una opción es usar un límite de errores.

Por ejemplo, considere un límite de tres errores por ingeniero. Por lo tanto, un equipo de 10 personas no debe tener más de 30 errores en su trabajo pendiente de errores. Si el equipo está por encima de su límite, se espera que detenga el trabajo en las nuevas características y que esté bajo el límite de errores. Se espera que un equipo esté bajo su límite siempre, pero es el equipo el que decide cómo quiere hacerlo. El límite de errores garantiza que los equipos no lleven consigo la deuda de errores durante demasiado tiempo. El equipo puede aprender de los fallos que hacen que se produzcan los errores en primer lugar.

Recuerde que el límite de errores representa los errores en el trabajo pendiente de errores. No incluye errores encontrados y corregidos dentro del sprint en el que se desarrolla una característica. Esos errores se consideran trabajos sin terminar, no una deuda.

Aunque los errores contribuyen a la deuda técnica, es posible que no representen toda la deuda.

Un diseño de software deficiente, código mal escrito o correcciones a corto plazo pueden contribuir a la deuda técnica. La deuda técnica refleja un trabajo de desarrollo adicional que surge de todos estos problemas.

Realice un seguimiento del trabajo para abordar la deuda técnica como PBI, casos de usuario o errores. Para realizar un seguimiento del progreso de un equipo en la ejecución y el direccionamiento de la deuda técnica, se recomienda considerar cómo clasificar el elemento de trabajo y los detalles que desea seguir. Puede agregar etiquetas a cualquier elemento de trabajo para agruparla en una categoría de su elección.

Rol del falicitador (Scrum Master)

Los facilitadores (Scrum Masters) ayudan a crear y mantener equipos saludables mediante el empleo de procesos de Scrum. Guían, entrenan, enseñan y ayudan a los equipos Scrum en el empleo adecuado de los métodos Scrum. Los facilitadores (Scrum Masters) también actúan como agentes de cambio para ayudar a los equipos a superar los impedimentos y a impulsar al equipo hacia aumentos significativos de la productividad.

Entre las responsabilidades principales de los facilitadores (Scrum Masters) se incluyen:

  • Apoyar al equipo para adoptar y seguir los procesos Scrum. Por ejemplo, no debería dejar que la reunión Scrum diaria se convierta en una discusión abierta que dura 45 minutos.

  • Evite que el propietario del producto o los miembros del equipo agreguen trabajo después de que comience el sprint.

  • Borre los problemas de bloqueo que impiden que el equipo avance. Este trabajo puede requerir que complete tareas pequeñas, como aprobar un pedido de compra para un equipo de compilación nuevo o resolver un conflicto del equipo.

  • Ayude al equipo a trabajar para resolver conflictos e incidencias que surgen y a aprender del proceso.

  • Haga preguntas que revelen incidencias ocultas y confirmen que todo el equipo entiende bien lo que las personas están comunicando.

  • Identifique y proteja al equipo frente a posibles problemas que se estén convirtiendo en problemas importantes. Al igual que es más barato corregir un error poco después de que se detecte, también es más fácil y menos perjudicial corregir un problema de equipo cuando es pequeño y manejable.

  • Impedir que el equipo presente casos de usuario incompletos durante una reunión de revisión de sprint.

  • Recopile, analice y presente datos a las partes interesadas empresariales para demostrar cómo crece y mejora el equipo. Por ejemplo, si el equipo ha aumentado la cantidad de valor que ha entregado al generar menos errores, haga que el valor sea visible a través de comunicaciones regulares a las partes interesadas de la empresa.

Los buenos facilitadores (Scrum Masters) tienen o desarrollan excelentes habilidades de comunicación, negociación y resolución de conflictos. Escuchan activamente las palabras que la gente dice y escribe. También prestan atención a la manera en la que entregar sus mensajes, por ejemplo, su lenguaje corporal, expresiones faciales, ritmo vocal y otra comunicación no verbal.

Al igual que es más barato corregir un error poco después de que se detecte, también es más fácil y menos perjudicial corregir un problema de equipo cuando es pequeño y manejable, antes de que se convierta en un problema mayor.

Reuniones Scrum diarias

Las reuniones Scrum diarias ayudan a que un equipo se mantenga centrado en lo que hay que hacer al día siguiente. Mantener el foco ayuda al equipo a maximizar su capacidad para cumplir los compromisos de sprint. Su facilitador (Scrum Master) debe aplicar la estructura de la reunión y asegurarse de que comienza a tiempo y finaliza en 15 minutos o menos.

Tres aspectos de las reuniones Scrum exitosas:

  • Todos se levantan. Levantarse ayuda a mantener las reuniones centradas y cortas.
  • Comienzan y finalizan a la hora, y se producen al mismo tiempo y en la misma ubicación cada día.
  • Todos participan; cada miembro del equipo responde a las tres preguntas Scrum:
    • ¿Qué he logrado desde el último Scrum?
    • ¿Qué puedo lograr antes del próximo Scrum?
    • ¿Qué problemas de bloqueo o impedimentos pueden afectar a mi trabajo?

Nota:

El objetivo de las reuniones Scrum es el estado del trabajo que debe pasarse de un miembro del equipo a otro miembro del equipo.

Los miembros del equipo deben esforzarse por responder a sus preguntas de forma rápida y concisa. Por ejemplo:

"Ayer, actualicé la clase para reflejar el nuevo elemento de datos que extraímos de la base de datos y he conseguido que aparezca en la interfaz. Ha completado la tarea. Hoy, me aseguro de que el nuevo elemento de datos se calcule correctamente con el procedimiento almacenado y los demás elementos de datos de la tabla. Creo que puedo llevar a cabo esta tarea hoy. Necesito que alguien revise mis cálculos. No tengo impedimentos ni problemas de bloqueo".

Esta respuesta transmite lo que el miembro del equipo ha logrado, lo que planear lograr, y en lo que el miembro del equipo desea recibir ayuda para examinar el código.

Compare con este ejemplo siguiente:

"Ayer, trabajé en la clase, y funciona. Hoy trabajo en la interfaz. No hay problemas de bloqueo".

El miembro del equipo no proporciona suficientes detalles sobre la clase en la que trabajó ni sobre los componentes de interfaz que completará. De hecho, no ha mencionado la palabra "logrado".

Es importante que nadie interrumpa durante el informe. Cada persona debe tener tiempo suficiente para responder a las tres preguntas.

Se deben realizar discusiones más detalladas y de seguimiento después de la reunión, ya que las personas vuelven a sus escritorios o, si es necesaria una cantidad significativa de conversación, en una reunión de seguimiento.

Muchos equipos retrasan las discusiones mediante el método "estacionamiento virtual". Cuando surgen temas en los que un miembro del equipo piensa que es necesario ahondar más , pueden caminar silenciosamente hasta una pizarra o un gráfico de volteo y apuntar el asunto en el estacionamiento de temas pendientes. Al final de la reunión, el equipo determina cómo controlarán los elementos enumerados.

Reuniones de revisión de sprint

Realice las reuniones de revisión del sprint el último día del sprint. El equipo muestra cada elemento de trabajo pendiente de producto que completó en el sprint. El propietario del producto, los clientes y las partes interesadas aceptan los casos de usuario que cumplen sus expectativas e identifican los nuevos requisitos. Los clientes suelen comprender mejor sus necesidades después de ver las demostraciones y pueden identificar los cambios que desean.

En función de esta reunión, algunos casos de usuario se aceptan como completados. Los casos de usuario incompletos permanecen en el trabajo pendiente del producto. Se agregan nuevos casos de usuario al trabajo pendiente. Ambos conjuntos de casos se clasifican y se calculan o se vuelven a calcular en la siguiente reunión de planificación de sprints.

Después de esta reunión y la reunión retrospectiva, el equipo planificará el siguiente sprint. Dado que las necesidades empresariales cambian rápidamente, puede aprovechar esta reunión con el propietario del producto, los clientes y las partes interesadas para volver a revisar las prioridades del trabajo pendiente del producto.

Reuniones retrospectivas de sprint

Las retrospectivas, cuando se realizan bien y a intervalos regulares, respaldan la mejora continua.

Normalmente, la reunión retrospectiva del sprint se lleva a cabo el último día del sprint, después de la reunión de revisión del sprint. En esta reunión, su equipo explora su ejecución Scrum y todo aquello que podría necesitar ajustes.

En función de las discusiones, el equipo podría cambiar uno o varios procesos para mejorar su propia eficacia, productividad, calidad y satisfacción. Esta reunión y las mejoras resultantes son fundamentales para el principio ágil de organización automática.

Nota:

Para admitir la retrospectiva de su equipo, considere la posibilidad de instalar la extensión Retrospectivas de Marketplace. Esta extensión admite la recopilación de comentarios sobre los hitos del proyecto, la organización y la priorización de los comentarios, y la creación y el seguimiento de tareas accionables para ayudar al equipo a mejorar con el tiempo.

Busque abordar estas áreas durante las retrospectivas del sprint del equipo:

  • Incidencias que afectaron a la eficacia general, la productividad y la calidad de su equipo.

  • Elementos que afectaron a la satisfacción general del equipo y al flujo del proyecto.

  • ¿Qué ha ocurrido para causar elementos de trabajo pendiente incompletos? ¿Qué acciones puede realizar el equipo para evitar estos problemas en el futuro?

    Por ejemplo, imagine un equipo que tenía varias tareas que solo un individuo del equipo podía realizar. La experiencia aislada creó una ruta crítica que amenazaba el éxito del sprint. El miembro del equipo individual trabajó horas extra mientras que otros miembros del equipo se frustraron porque no podían hacer más para ayudar. En el futuro, el equipo decidió practicar la programación extrema para ayudar a corregir este problema con el tiempo.

Como equipo, trabaje para determinar si debe adaptar uno o varios procesos para minimizar la aparición de problemas durante el sprint.

Es posible que el equipo tenga que realizar algún trabajo para implementar una mejora. Por ejemplo, un equipo que se vio afectado negativamente por demasiadas compilaciones erróneas decidió implementar la integración continua. Dado que no quería interrumpir el proceso, tardaron unas horas en configurar una compilación de prueba antes de activarla en su compilación de producción. Para representar este trabajo, crearon un pico y organizaron el trabajo en comparación con el resto del trabajo pendiente del producto.