Cómo Scrum: una guía práctica

En la industria de TI actual, el concepto de Agile se ha vuelto bastante popular. Todo el mundo está hablando. Casi todas las empresas de TI han adoptado algún nivel de agilidad.

También hay muchos métodos bajo el paraguas del desarrollo ágil, que incluyen Extreme Programming (XP), Scrum, Crystal Methods, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development (DSDM) y ligero. RUP, desarrollo dirigido por pruebas (TDD) y más. Entre los muchos métodos de desarrollo ágil, la implementación de Scrum es más popular.

¿Ágil o cascada? Ver las figuras

El informe más reciente de Standish Group cubrió los proyectos que estudiaron entre 2013 y 2017. Para este período de tiempo, el desglose general de éxito, desafío y fracaso se muestra a continuación para ágil y cascada, con proyectos ágiles que tienen aproximadamente 2 veces más probabilidades de éxito. y 1/3 menos probabilidades de fallar.

(Fuente: vitalitychicago.com —  Comparación de las tasas de éxito de los proyectos ágiles y en cascada )

Este artículo comparte principalmente la comprensión de Scrum, el proceso de implementación de Scrum y los cambios que trajo la implementación de Scrum, y explica qué es un Scrum en ejecución.

¿Qué es Scrum?

Scrum es un marco para desarrollar y mantener productos complejos y es un proceso de desarrollo incremental e iterativo. En este marco, todo el proceso de desarrollo consta de varios ciclos de iteración cortos, un ciclo de iteración corto llamado Sprint, y cada Sprint tiene una duración de 2 a 4 semanas.

En Scrum, utilice el Backlog del producto para administrar las necesidades del producto. La cartera de productos se clasifica de acuerdo con la prioridad de la implementación, con el valor comercial como el principio principal de la clasificación. En el Sprint, el equipo de Scrum seleccionó los requisitos de mayor prioridad del Backlog del producto para el desarrollo. Los requisitos seleccionados se discuten, analizan y estiman en la reunión de planificación de Sprint para obtener una lista de tareas denominada acumulación de Sprint. Cuando el equipo de Scrum completa todas las tareas en la lista de pendientes del Sprint, el Sprint finaliza y continúa con el siguiente ciclo de iteración del Sprint.

Por qué Scrum fracasó en algunas empresas

Scrum tiene un gran valor. Sin embargo, es difícil implementar Scrum en algunas empresas. Algunas personas dicen que Scrum no tiene un efecto sustancial en su organización. ¿Por qué tienen tal resultado? Las razones principales podrían ser:

• Agile es más rápido  : el equipo del proyecto carece de una comprensión correcta de ágil. Simplemente piensa que la agilidad es rápida, es decir, ponerse al día con el progreso, y puede estar libre de cualquier restricción del sistema.
• Agile es más rápido, o necesitamos trabajar horas extras  . He oído que algunas empresas tienen que desarrollar una nueva función. Debido a la implementación de scrum, el equipo del proyecto debe trabajar horas extra y las tareas de desarrollo de 2 semanas o más se publicarán en una semana. Implementar Scrum significa que el equipo del proyecto está trabajando horas extras, lo que lleva a un “miedo” en la agilidad del equipo del proyecto;
• La cartera de productos no se mantiene bien  : el PO no puede ser calificado para el trabajo, no puede dividir las historias de usuario efectivas, o la división de la historia del usuario no es razonable, no puede realizar un desarrollo de generación incremental;
• Problema de formación de equipos  : Scrum tiene una gran demanda de equipos autoorganizados, pero muchos miembros del equipo sienten que no están a la altura de los estándares de autoorganización;
• Falta de cultura ágil  : Scrum aboga por la transparencia del trabajo, la finalización del proyecto en tiempo real y el reconocimiento de la tarea de cada persona. El Sprint Board y el diagrama de trabajo pendiente del proyecto no están obstruidos, y muchas personas no se sienten cómodas con él;
• Inspección y adaptación no en su lugar  : en el proceso de iteración, el problema no se puede descubrir a tiempo, o se encuentra el problema, y ​​el problema no se puede resolver de manera efectiva, lo que hace que el equipo del proyecto se sienta frustrado. y muchos más.

Si el conocimiento de Scrum solo está atascado en:

“Tengo una idea por la mañana, se realizará por la tarde y estará en línea por la noche”.

es inapropiado En mi opinión, Scrum es definitivamente valioso. Las principales funciones de Scrum incluyen:

• Scrum puede asegurar priorizar el desarrollo de la cartera de productos que tiene un alto valor para los clientes y satisfacer mejor las necesidades de los usuarios.
• En comparación con el método de desarrollo bajo el proceso de cascada, al implementar Scrum, el equipo puede duplicar la eficiencia del desarrollo y maximizar el rol del equipo;
• Scrum puede acortar los ciclos de desarrollo y aumentar la eficiencia de entrega de proyectos.

Sin embargo, implementar Scrum no significa que no esté sujeto a reglas y restricciones del proyecto. Entonces, ¿cuál es la postura correcta para implementar Scrum?

Pasos para implementar Scrum

1. Asignar una orden de compra

PO es el propietario del producto, que es un rol, y PO es el único propietario de la lista de tareas pendientes del producto de gestión. Por supuesto, en algunas empresas, el PO ya existe como organización; por ejemplo, nuestra empresa ha implementado el PO como organización en la implementación de Scrum.

Como propietario, debe tener un panorama general; comprender profundamente la información y la dirección de la industria; ser capaz de captar la dirección del producto, hacerse cargo de la planificación y gestión del producto a corto, mediano y largo plazo; ser capaz de realizar investigaciones de usuarios y planificación de funciones de productos de acuerdo con los requisitos estratégicos de la empresa, rastrear las necesidades en constante cambio y continuar innovando productos.

Además, si usa PO como una organización, en un proyecto de desarrollo de software, el equipo de PO puede incluir otras partes interesadas, como gerentes de productos, usuarios finales.

2. Forme un equipo de desarrollo

El equipo es el implementador del producto y es responsable de entregar incrementos de envío potenciales e incrementos de producto «completados» al final de cada Sprint.

El equipo incluye principalmente personal de desarrollo y prueba, y el equipo debe ser capaz de implementar la visión del producto del PO.

El tamaño del equipo debe ser de alrededor de 5 a 9 personas.

El equipo Scrum también debe tener funciones cruzadas y los miembros con la capacidad de «pila completa» son más preferibles, incluso  si puede ser difícil de implementar en la mayoría de las empresas.

3. Seleccione Scrum Master

El Scrum Master es responsable del proceso Scrum y sirve al PO y al equipo de desarrollo. El Scrum Master debe tener un sentido del ritual y puede organizar de manera efectiva y eficiente la reunión del plan iterativo, la reunión permanente diaria, la reunión de demostración de funciones y la reunión de revisión retrospectiva; el Scrum Master debe tener un alto grado de ejecución y mantener la credibilidad para ayudar al equipo. Concéntrese en las metas de entrega y los objetivos de calidad para garantizar que los equipos entreguen productos de alta calidad de manera eficiente; impulsar equipos para construir procesos eficientes, guiar equipos sobre valores ágiles, principios y prácticas ágiles; ser responsable de capacitar a otros miembros del equipo para garantizar que Scrum se use correctamente; Comunicación, gestión de problemas, resolución de conflictos, ayudar al equipo a eliminar todos los obstáculos.

4. Mantener la acumulación de productos

El Product Backlog es una recopilación de todos los elementos del backlog y se basa en la estrategia y la visión del producto de la empresa. PO clasifica todos los elementos en la cartera de productos según el orden de prioridad de acuerdo con los valores comerciales y forma una lista de elementos priorizados. La  cartera de pedidos del producto puede servir como el «mapa de ruta» del desarrollo del producto. Para comprender el contexto del producto, los elementos de la cartera de productos son la mejor referencia.

Todos los días nos enfrentamos a nuevas demandas de nuevos competidores, lo que significa que PO debe optimizar continuamente el diseño de su producto y ajustar las prioridades de la cartera de productos para hacer frente a los nuevos cambios.

En este proceso, la OP debe consultar con todas las partes interesadas y los equipos para asegurarse de que la acumulación de productos refleje las verdaderas afirmaciones del usuario.

5. Estimación ágil utilizando Story Point

La estimación relativamente ágil generalmente se realiza en la planificación del sprint o se retoca durante un sprint y el equipo evalúa la acumulación de productos junto con el responsable del trabajo real de desarrollo y prueba.

Para llevar a cabo la planificación del sprint de manera más eficiente en la práctica, el PO y el Scrum Master harán una estimación aproximada antes de la reunión de planificación del sprint. Necesitan hacer este tipo de preguntas como:

• ¿Ver si el plan de sprint es factible?
• ¿Hay suficiente información para completar estos asuntos?
• ¿Es razonable la división de elementos de la cartera de productos?

Cuando el equipo de desarrollo realiza una estimación, se recomienda abandonar el método tradicional (es decir, cuántas horas se asignarán a la tarea) y utilizar un enfoque de estimación ágil utilizando el punto de la historia: el número de Fibonacci (1, 2, 3, 5 , 8, 13, 21…) Formulario para evaluar el esfuerzo requerido para la implementación de un ítem.

En el momento de la estimación, el equipo primero debe identificar un elemento pendiente que podría estar en forma de historia de usuario como referencia para la estimación. Además, es importante tener en cuenta que  cuando el punto de la historia única de la evaluación es mayor que 21, la historia del usuario debe dividirse nuevamente, y el punto de la historia del usuario único no es más de 8 es el estado ideal.

6. Reunión de planificación de Sprint

Esta es la primera reunión real de Scrum. El equipo, Scrum Master y PO se sientan juntos para planificar el contenido del sprint. Como proyecto de desarrollo de software, al ingresar la historia de usuario del sprint de planificación, la historia de usuario debería haberse dividido y el diseño visual completado.

El ciclo de sprint generalmente es fijo, principalmente de 2 a 4 semanas. El equipo comienza con la historia de usuario con la prioridad más alta en la lista de tareas pendientes del producto para ver cuánto se puede hacer en un sprint.

Si el equipo ya ha realizado múltiples sprints, por referencia a:

• Los «puntos de la historia» completados en las iteraciones anteriores,
• El equipo puede estimar los puntos aproximados de la historia para esta iteración.
• Los “puntos de historia” equivalen a la velocidad del equipo.

Scrum Master y el equipo deben esforzarse por aumentar este número en cada iteración de sprint.

Todos los miembros del equipo deben formar un consenso sobre el objetivo de un sprint, es decir, lo que debe lograrse en una iteración de sprint. En la reunión de planificación del sprint, el PO debe indicarle al equipo el orden de prioridad de la implementación de la historia de usuario. El equipo promete cuántas historias podrán completar en la próxima iteración del sprint. En el proceso de sprint, nadie puede cambiar unilateralmente el contenido del sprint sin autorización.

7. Reunión diaria de pie

Daily Stand-up es la fuente de vitalidad para Scrum. Los participantes generalmente incluyen PO, Scrum Master y equipo. El equipo se comunica internamente en una ubicación fija ya una hora fija todos los días. El  horario suele ser de mañana, la duración no supera los 15 minutos, y de pie. El Scrum Master hace a los  miembros del equipo las siguientes preguntas:

• ¿Qué hiciste ayer?
• ¿Qué trabajo piensas hacer hoy?
• ¿Qué son los impedimentos y obstáculos?

La importancia de esto es que todo el equipo sepa claramente el progreso de cada tarea durante este ciclo de sprint y si todas las tareas se pueden completar a tiempo.

Las tareas del equipo no se asignan de arriba hacia abajo, sino que se deciden por iniciativa propia y de forma voluntaria. Si la tarea anterior no se completa, no puede solicitar la siguiente tarea y no puede reclamar dos tareas que no se pueden completar el mismo día.

El Scrum Master es responsable de eliminar los obstáculos que enfrentan los miembros del equipo.

8. Realice un seguimiento del progreso del proyecto con el tablero de tareas de Scrum

En Scrum, el trabajo debe ser transparente y la práctica más común es implementar un tablero de tareas de Scrum.

Algunos equipos son buenos para usar herramientas de terceros para usar el tablero electrónico Scrum, como Visual Paradigm o Jira; algunos equipos están felices de usar grandes pizarras físicas sin conexión.

Independientemente de si utiliza una pizarra Scrum electrónica o una pizarra física, las columnas de Kanban generalmente incluyen tres partes: la lista de tareas pendientes, los elementos en curso y los elementos completados. A medida que avanza la iteración, el equipo actualizará rápidamente el asunto en la columna Scrum Kanban correspondiente todos los días.

9. Seguimiento del progreso con tablas de quemado

Otra herramienta para hacer que el trabajo sea transparente es el gráfico de quemado. En la siguiente figura, un eje representa la carga de trabajo y el otro representa el tiempo. Todos los días, Scrum Master registra los puntos restantes por completar y luego los dibuja en el gráfico de agotamiento. Idealmente, el gráfico es una curva descendente, que se reduce a cero a medida que se completa el resto del trabajo.

10. Demostración del producto

La sección de demostración de la Guía Scrum se llama Sprint Review Meeting, que establece que debe incluir una demostración del trabajo realizado por el equipo de desarrollo y responder preguntas sobre el incremento del producto. La reunión generalmente se lleva a cabo antes del lanzamiento de esta iteración. El trabajo más importante de esta reunión es verificar los escenarios de implementación de las historias de usuario con la aceptación de evaluaciones con cada uno de los elementos completados para cumplir con la definición de hecho.

Esta reunión es donde cualquiera puede ser participante, no solo PO, Scrum Master y equipo, sino también partes interesadas, negocios y gerentes, e incluso clientes.

Esta es una reunión abierta en la que cualquiera puede participar, no solo PO, Scrum Master y equipo, sino también partes interesadas, negocios y gerentes, e incluso clientes.

Los equipos deben mostrar solo aquellos elementos que cumplan con la definición de hecho, es decir, los resultados que se pueden entregar sin tener que hacer más trabajo. Es posible que este resultado no sea un producto completo, pero al menos es una función completa y útil para el usuario final.

11. Retrospectiva de Sprint

La reunión retrospectiva del Sprint generalmente se lleva a cabo el segundo día después del final de este Sprint.

La reunión retrospectiva del sprint debe revisar cuidadosamente las siguientes preguntas:

• Lo que ha pasado a ser mejorado;
• ¿Por qué sucedió?
• ¿Por qué lo ignoramos en ese momento?
• ¿Cómo podemos acelerar el trabajo?

Como equipo, para que este proceso retrospectivo de sprint sea efectivo, el equipo debe confiar el uno en el otro. Debemos recordar la discusión y los argumentos basados ​​en el proyecto y las cuestiones técnicas:

• No existe el bien, el mal y la preocupación absolutos,
• Fomentar las colisiones técnicas;
• No puede involucrar discusiones sobre ataques personales;
• Resiste a la gente con gafas de colores para ver a la gente,
• Guíe a todos a una discusión racional;
• Acepta con valentía los desafíos de los demás,
• Aceptar sus propias imperfecciones.
• Responsable de sus propios procesos y resultados,
• lluvia de ideas y búsqueda de soluciones a los problemas. Esto es crucial.

Finalmente, el equipo identifica una de las mejoras más valiosas y la establece como la máxima prioridad para el próximo sprint. Debe definir qué es «exitoso» de una manera concreta y procesable para que pueda determinar rápidamente si se han realizado las mejoras en la próxima reunión de revisión del sprint.

Después de que termine el último sprint, comience a ingresar la nueva iteración del sprint.

Resumen

Scrum  es una combinación de 3355. Los conceptos básicos del marco Scrum se pueden memorizar simplemente como 3.3.5.5 de la siguiente manera:

3 roles

• Dueño del producto
• Equipo de desarrollo
• Maestro Scrum

3 artefactos

• Pila de Producto
• Sprint Backlog  : lista de tareas pendientes de Sprint
• Incremento de producto — Incremento potencial de producto para envío

5 eventos

• pique
• Reunión de planificación de Sprint
• Reunión diaria de Scrum
• Reunión de revisión de sprint
• Reunión retrospectiva de Sprint

5 valores

• Abierto
• Respeto
• Coraje
• Enfocar
• Compromiso

Los objetivos de 3355 están detrás de los tres Pilares Scrum

• Transparente
• Inspección
• Adaptación

La Definición de “Terminado” (DoD) se logra cumpliendo los 3 pilares a través de 5 eventos del  equipo Scrum .

• Algunos artículos y referencias de Scrum traducidos al chino