Trabajando con Scrum

Historia del usuario

Las historias de usuario son una forma efectiva de establecer los requisitos para el software en desarrollo. Tales historias contienen breves consejos en nombre del usuario del software.

Dado que en la metodología Scrum, el establecimiento de objetivos suele ser una prerrogativa del cliente o propietario del software, se consideran la principal forma de influir en el proceso de desarrollo. Cada historia de usuario tiene una limitación en la cantidad de texto y la complejidad de la presentación. La historia se suele escribir en una hoja pequeña, lo que en sí mismo limita el volumen.

Gracias a las historias de usuario, puede documentar los deseos del cliente y responder rápidamente a las demandas del mercado.

La historia de usuario debe considerarse una medida simplista de los requisitos porque no incluye un procedimiento de prueba de aceptación. La compilación de la historia de usuario debe cumplir con el procedimiento de admisión. Esto asegurará que la historia de usuario logre su objetivo.

La estructura de la historia se ve así: "Como usuario <tipo de usuario>, quiero realizar <acción> para obtener <resultado>" (Como propietario del producto quiero...). Tal estructura no solo es simple, sino también comprensible para todos.

Beneficios de usar historias de usuario:

• Las historias son pequeñas y fáciles de crear.
• Ayude a todas las partes interesadas a discutir el trabajo en el proyecto y su apoyo.
• No requieren mantenimiento constante.
• Relevante solo cuando se usa.
• Mejorar la interacción con el cliente.
• Gracias a ellos, puedes dividir el proyecto en pequeñas etapas.
• Facilitar el trabajo en proyectos con requisitos mal entendidos.
• Simplifique la evaluación de tareas.

Desventajas de las historias de usuario:

• Sin un acuerdo previo, los procedimientos pueden dificultar su uso como base para un acuerdo.
• Su uso requiere un estrecho contacto con el cliente a lo largo de todo el proyecto, lo que en ocasiones dificulta el flujo de trabajo.
• Tienen desventajas al escalar en grandes proyectos.
• Directamente relacionado con el nivel profesional de los desarrolladores.
• Se utiliza para iniciar una discusión, pero no puede finalizar una discusión y no se utiliza para la documentación del sistema.

Reserva

La cartera de productos son las tareas actuales en forma de lista, compiladas en orden de prioridad. La lista se forma sobre la base de la hoja de ruta (roadmap) del proyecto y los puntos establecidos en el mismo. Las tareas más importantes suelen estar al principio de la lista. Esto es necesario para entender qué trabajo debe hacerse primero.

El equipo de desarrollo elige la velocidad para completar las tareas atrasadas independientemente de los deseos del cliente, pero en función de sus calificaciones y experiencia de sprints anteriores. Es extremadamente indeseable "ajustar" a los programadores. El propio equipo elige las tareas del trabajo pendiente de acuerdo con sus propias consideraciones y capacidades. La ejecución tiene lugar sin interrupción (Kanban) o varias iteraciones (Scrum).

Dos condiciones importantes de retraso

El núcleo de una cartera de productos consiste en una hoja de ruta, propuestas y condiciones de ejecución. Las epopeyas contienen condiciones e historias de usuario. Echemos un vistazo de cerca a un ejemplo típico de hoja de ruta.

La creación del sitio web “Teams in Space” es la primera propuesta de la hoja de ruta. Debe dividirse en épicas (en la figura se muestran en colores verde, azul y turquesa) y una historia de usuario para cada épica.

El cliente de software forma una lista a partir de varias historias de usuario. Si es necesario, puede cambiar el orden en que se ejecutan las historias, de modo que los desarrolladores se ocupen primero de una de las epopeyas más importantes (izquierda) o comprueben cómo funciona la reserva de entradas con descuento. Para hacer esto, debe implementar historias de epopeyas (derecha). Ambas opciones se pueden ver a continuación.

¿En base a qué factores debe priorizar el cliente?

• Relevancia para los usuarios.
• La presencia de retroalimentación.
• Complejidad del desarrollo.
• La relación entre tareas (para completar "B", primero debe hacer "A").

Las prioridades en el trabajo las determina el cliente, pero otras partes pueden expresar su opinión al respecto. El éxito del backlog depende, entre otras cosas, de las opiniones de los clientes y programadores. Juntos, pueden lograr mejores resultados y garantizar la entrega oportuna del producto terminado.

Cómo mantener un backlog

Si el trabajo pendiente ya se ha creado, luego de eso, debe cambiarlo periódicamente en el curso del trabajo adicional. El cliente de software debe asegurarse de que el backlog se compile correctamente antes de planificar cada nueva iteración. Esto ayudará a aclarar prioridades o cambiar algo después del análisis de la última iteración. El ajuste de la acumulación en Agile a veces se denomina "preparación" o "refinamiento" o "mantenimiento de la acumulación".

Si la cartera de pedidos ya es relativamente grande, entonces el cliente necesita agrupar las tareas por ejecución a corto y largo plazo. Las asignaciones a corto plazo deben examinarse antes de que se les otorgue este estatus. Tendrás que componer una historia de usuario, descubrir todos los matices dentro del equipo.

En cuanto a las tareas a largo plazo, es muy deseable que los desarrolladores les den su valoración. Esto hará que sea más fácil priorizar. Quizás algo cambie, pero el equipo mejorará su comprensión de las tareas y hará el trabajo más rápido.

El backlog es un componente importante entre el cliente y el equipo de programación. El cliente siempre puede cambiar las prioridades en función de los comentarios del cliente, las previsiones o los nuevos requisitos.

Se recomienda evitar realizar cambios directamente durante el funcionamiento. Esto tiene un efecto negativo en el flujo de trabajo y el estado emocional de los programadores.

pique

Un sprint es un período corto durante el cual se debe completar una cantidad de trabajo previamente acordada. Los Sprints se basan en metodologías Scrum y Agile. Elegir los sprints correctos ayuda a un equipo ágil a desarrollar software de calidad.

“Usando Scrum, puedes desarrollar un producto en varias iteraciones con una duración clara: sprints. Ayuda a dividir grandes proyectos en tareas más pequeñas”, dice Megan Cook, líder de Jira en Atlassian.

¿Cómo planifica y ejecuta Scrum los sprints?

Según los autores de la metodología Scrum, para planificar el sprint futuro, todos deben reunirse en una reunión separada. En este evento, los miembros del equipo deben encontrar respuestas a dos preguntas principales: ¿qué se debe hacer en este sprint y cuál es la mejor manera de hacerlo?

El cliente de software, el maestro Scrum y los programadores están involucrados en la determinación de la lista de tareas de trabajo. El cliente explica el objetivo del sprint y las tareas del backlog.

Luego, el equipo desarrolla un plan según el cual se completarán las tareas del sprint. Este plan, junto con los elementos de trabajo seleccionados, se denomina acumulación de sprint. Después de la reunión de planificación, el equipo se pone a trabajar. Los desarrolladores seleccionan tareas del backlog, a medida que se completa el trabajo, el estado de cada tarea cambia de "En progreso" a "Listo".

Durante el sprint, el equipo realiza reuniones Scrum diarias (stand-ups) para discutir los problemas actuales y el progreso. Estas reuniones son necesarias para identificar las dificultades que pueden afectar la finalización del sprint.

Si se completa el sprint, el equipo muestra los resultados de su trabajo en la revisión de los resultados (demostración). Cada participante del proyecto puede familiarizarse con los resultados. La familiarización debe hacerse antes de que el código terminado se fusione con el entorno de producción.

La retrospectiva completa el ciclo de sprints. En él, el equipo identifica áreas que deben mejorarse en un sprint futuro.

A qué prestar atención y qué no hacer

A la mayoría de los equipos jóvenes les resulta difícil introducir sprints en su flujo de trabajo por primera vez. Para evitar problemas, le recomendamos que revise la lista de acciones que requieren atención prioritaria.

Qué tenemos que hacer:

• Verifique que el equipo comprenda el propósito del sprint y cómo tendrá éxito. Esto es necesario para que todos avancen juntos hacia un resultado exitoso.
• Debe tener un backlog claro y comprensible. Si el backlog no se mantuvo correctamente, esto puede convertirse en un problema que puede dañar el flujo de trabajo.
• Asegúrate de que tu estimación del ritmo de trabajo sea correcta, teniendo en cuenta las vacaciones de verano y otros factores.
• Participa activamente en la planificación del sprint. Anime a los miembros del equipo a expandir el plan para historias, errores y tareas.
• Rechace tareas durante las cuales los desarrolladores no podrán resolver problemas de dependencia.
• Después de que se apruebe el plan, designe a un empleado que será responsable de ingresar los datos en el programa de gestión de proyectos (tarjetas Jira, etc.).

Que evitar:

• No abusar de una gran cantidad de historias, evaluar con seriedad el ritmo de trabajo y no asignar tareas que serán difíciles de completar en un sprint.
• Sea consciente de la calidad de su trabajo. Compruebe si tiene suficiente tiempo para el control de calidad y la corrección de errores en el código.
• Asegúrese de que todos los miembros del equipo comprendan claramente el contenido del sprint. No persigas la velocidad. Todo el equipo debe moverse junto.
• No sobrecargue a los desarrolladores con trabajo adicional. Próximamente otro sprint.
• Si el equipo expresa preocupación por la carga de trabajo o el plazo, debe tener en cuenta su opinión. Abordar los problemas y corregirlos si es necesario.

tablero de melé

El Tablero Scrum es una herramienta que muestra cómo se realiza el trabajo del Equipo Scrum. Puede mostrar información en dicho tablero en papel, en la pared o en formato electrónico (JIRA, Trello).

Un tablero de Scrum tiene al menos tres columnas: Por hacer, En progreso y Terminado. Aquí hay un tablero de ejemplo:

El tablero de Scrum contiene toda la información del backlog, previamente aprobado para la planificación. Como regla general, las tarjetas de tareas comerciales se fijan en el tablero por prioridad de arriba a abajo. Puede dividirlos en tipos específicos de trabajo (trabajo en código, diseño y otros).

Una vez que se completa parte del trabajo, la tarjeta se mueve a través del tablero a la siguiente columna. Para mostrar la visibilidad del progreso del trabajo del equipo, ayuda el "trabajo restante" por día en el Burndown Chart.

También puede utilizar una pizarra de rotafolio. En él se escriben los nombres de las obras en pegatinas de papel y se pegan a la pizarra. Tan pronto como se completa el trabajo, las pegatinas se mueven a otra columna.

cuadro de incendio

El gráfico de quemado muestra la cantidad de trabajo realizado y la cantidad de trabajo restante. Se actualiza todos los días y está disponible para todas las partes interesadas. El gráfico es necesario para mostrar el progreso en el trabajo del sprint.

Hay dos tipos de gráficos:

• Gráfico Burndown que muestra el progreso del trabajo en un sprint.
• Burndown chart que muestra el progreso del trabajo hasta el lanzamiento del producto (los datos se resumen de varios sprints).

Ejemplo de gráfico:

Este ejemplo utiliza la psicología: el gráfico no muestra el número de tareas completadas, sino el número de tareas restantes (no realizadas).

Es decir, si el equipo ha realizado 90 tareas de 100, entonces puede haber una falsa sensación de que todo está listo. Después de todo, el progreso de 90 a 100 tareas en realidad no cambia nada.

Si muestra la cantidad de tareas restantes, entonces no puede evitar notar cómo cada vez son menos y menos. Esto estimula inconscientemente a los participantes del proyecto a lograr el objetivo más rápido: no debe quedar ninguna tarea sin terminar en el tablero.