Este artículo es una mini-guía y una guía del método Scrum, creado como resultado de la lectura del libro de Sutherland, artículos de Internet y una aplicación práctica.
Es necesario distinguir entre Agile y Scrum. Agile es una metodología (ciencia), y Scrum es un método para lograr un objetivo.
Con Scrum, es importante contar con un verdadero equipo de profesionales, observar las condiciones de transparencia, apertura y confianza.
Los miembros del equipo deben estar contentos con sus actividades, ser felices en su trabajo. Un estado de felicidad lleva a las personas a excelentes resultados.
Las personas felices tienen un 50% más de éxito. Entonces son 50% más productivos si son felices y encuentran significado en su trabajo. Además, son un 88% más leales, porque entienden que no trabajan en vano, dedicando la mitad de su tiempo al desarrollo de este negocio.
- Dra. Corrie Block, experta en estrategia empresarial en evaluación de la felicidad.
Mini guía Scrum
Scrum - Scrum, un método flexible de gestión de proyectos. El término proviene de un juego de rugby.
Propietario del producto: propietario del producto, el vínculo entre el cliente y el equipo de desarrollo. La responsabilidad más importante del propietario del producto es la creación y el control de la cartera de productos.
Las principales responsabilidades y responsabilidades del propietario del producto en la gestión de la cartera de productos son:
- definir elementos de la cartera de pedidos para un producto;
- la disposición correcta de elementos para optimizar el logro de la meta;
- Asegurar la claridad y transparencia de la cartera de productos;
- garantizar la transparencia y la comprensión de los requisitos en los que todo el equipo Scrum tendrá que trabajar;
- optimización general para lograr el mayor valor del trabajo del Equipo de Desarrollo;
- responsabilidad de comprender el trabajo atrasado por el equipo de desarrollo.
Scrum Team (Scrum Team): una imagen colectiva de un equipo compuesto por un equipo de desarrollo, Scrum Master y propietario del producto. El equipo es completamente autosuficiente y no depende de especialistas externos o clientes.
Scrum Master (scrum master): un árbitro que organiza y celebra reuniones, supervisa el cumplimiento de todos los principios de scrum, resuelve contradicciones y protege al equipo de distracciones, facilita reuniones, es responsable de la contabilidad, el almacenamiento y la emisión de equipos SCRUM. Este rol no implica nada más que el proceso de scrum correcto.
Scrum Master no da tareas, pero elimina los problemas que aparecen dentro del equipo.
Un equipo multifuncional de desarrolladores de proyectos, compuesto por especialistas de diferentes perfiles: programadores, evaluadores, analistas, arquitectos, etc.
Equipo de desarrollo (equipo de desarrollo): un equipo de desarrollo, un equipo multifuncional de desarrolladores de proyectos, compuesto por especialistas en diversos campos: programadores, evaluadores, analistas, arquitectos, etc. El tamaño del equipo es de 5 a 9 personas (5 es óptimo). El equipo es el único participante en el desarrollo totalmente involucrado y es responsable del resultado en su conjunto. Esta unidad de trabajo es autosuficiente, autónoma y autoorganizada. Es como un organismo único que consta de elementos separados.
Partes interesadas : literalmente accionistas, personas que inician el proyecto (clientes comerciales), a quienes el proyecto scrum les traerá beneficios. Solo participan en el scrum durante la Revisión de Sprint.
Usuario : usuario del producto.
Producto atrasado (producto atrasado) - o requisitos de producto atrasados, deseos del cliente por funcionalidad y diseño, todo “Lista de deseos”; se clasifican en orden de importancia y valor para el cliente.
Epic es una de varias características globales del producto. La epopeya puede contener una Historia de usuario, por ejemplo, un paquete de deseos de un usuario o una lista de tareas (Tarea) para la implementación de Epic.
User Story - o Story, una trama que contiene los deseos del usuario.
Tarea (tarea): una tarea, un fragmento que debe completarse para lograr el objetivo del proyecto.
Sprint (sprint): un período de tiempo de 1 a 4 semanas, durante el cual el equipo crea una parte del producto, listo para la demostración y valioso para el cliente. La duración óptima del sprint es de 1-2 semanas. Esto se hace para que la información recibida al comienzo de la primera semana no se olvide al final de la segunda semana y no se requiera tiempo para restaurar las comunicaciones.
Sprint Goal (
Sprint Goal ): el objetivo del sprint.
Reunión de planificación de Sprint (Sprint Planin Mitin): planificación de Sprint, reunión de Scrum, donde participa el equipo Scrum. Se seleccionan las tareas pendientes que se pueden completar en el sprint.
Scrum Poker es una forma rápida y precisa de recolectar puntajes usando un mazo de cartas con números de Fibonacci (1,2,3,5,8,13). Puedes usar aplicaciones móviles para Scrum Poker. Las tareas con una evaluación de 13 deben dividirse en otras más pequeñas.
Puntos de historia : una unidad para evaluar la dificultad de completar una tarea. Tiene sentido aplicar Story Points si el proyecto consta de 3 o más sprints, ya que el equipo acumula estadísticas y experiencia en la evaluación de tareas. En un proyecto de uno o dos sprints, no tiene sentido usar Story Points, si no es para practicar.
Reunión diaria de Scrum (Daily Scrum Mitin): una reunión diaria de no más de 15 minutos, que se celebra al mismo tiempo. Tim Scrum participa, todos pueden observar. Realizado por un scrum master. El propósito de la manifestación es el rápido intercambio de información, todos están al tanto de lo que está sucediendo, no hay brechas de comunicación. Se hacen tres preguntas: ¿qué hiciste ayer? que harás hoy ¿Cuáles son los obstáculos en el camino hacia la meta?
Revisión de Sprint (revisión de Sprint) - revisión de Sprint, todos los involucrados, la reunión está abierta. El equipo cuenta lo que se ha hecho y demuestra las partes del proyecto que finalmente están listas.
Reunión retrospectiva de Sprint (retrospectiva de sprint Mitin): un scrum tim retrospectivo e involucrado. Encuentro en la mesa redonda. Se discuten preguntas: ¿qué salió bien y qué salió mal? ¿Qué se podría hacer mejor? ¡Lo principal es no condenar a nadie! Se está considerando el flujo de trabajo. El objetivo es mejorar el flujo de trabajo, convertirse en un "super" equipo.
La definición de Hecho (DoD) es el criterio que determina el grado de preparación de una tarea. Se utiliza en aquellos casos en que finalmente es imposible verificar la preparación de la tarea, por ejemplo, si el elemento funcional está en otro equipo o en el scrum de la compañía. La descripción del DoD comienza con la línea "done =", por ejemplo, done = la funcionalidad se implementa en un entorno de prueba, se requiere la descarga y verificación en el entorno principal.
Velocidad (Velocidad) - velocidad del equipo; Para el análisis, se construye un gráfico de velocidad, donde el eje X cuenta sprints y los puntos de historia del eje Y. En base a estos indicadores, se construyen los puntos promedio de velocidad e historia.
Burndown Chart - gráfico de la combustión de tareas. La dirección del gráfico es de arriba a abajo. Diseñado para rastrear la cantidad restante de trabajo, donde en el eje X el número de días de sprint, y en el eje Y el número de Story Points. El primer día del sprint corresponde al número máximo de puntos de historia.
Burnup Chart - Burnup Chart. La dirección del gráfico es de abajo hacia arriba. Diseñado para rastrear la cantidad de trabajo, donde en el eje X el número de días de sprint, y en el eje Y el número de Story Points. El último día del sprint corresponde al número máximo de puntos de historia.
Terminación anormal (terminación de abnormol): parada de sprint, acción anormal. La detención la inicia el propietario del producto. Se está llevando a cabo una concentración para discutir las causas de la terminación anormal. Entonces Sprint comienza de nuevo.
Guía Scrum
Producto atrasadoSe forma durante una reunión general o entrevistas individuales con todas las partes interesadas (partes interesadas, usuarios). La historia del usuario, los requisitos y los deseos se registran.
- Los campos principales en la tarjeta: identificación, nombre, importancia, calificación, publicación, descripción, autor, artista;
- Campos adicionales en la tarjeta. Por ejemplo, el campo "Asunto": la calificación del producto en la tienda en línea no es necesaria ahora, y la calificación incluye un par de tareas. Entonces puede cambiar la "importancia" de todas las tareas con este tema;
- Las tareas se dividen mejor en los mismos tipos.
Las tareas con componentes como: 3IIIC, 5VE son más complicadas y requieren más tiempo.
123, ABC es más rápido porque el cerebro no necesita cambiar entre diferentes tipos de tareas.
Historia del usuario- Recibir un objetivo comercial de un cliente. Redactamos el Mapa de Impacto para cada objetivo comercial: ¿Por qué? -> ¿Quién? -> ¿Cómo? -> ¿Qué? (¿Por qué? -> ¿Quién? -> ¿Cómo? -> ¿Qué hay que hacer?);
- Texto de la historia del usuario:
Como usuario <...> quiero hacer <...> para obtener <...>.
Como gerente de almacén, recibo un informe de balance de existencias para tomar una decisión MÁS RÁPIDA;
Redacción sin TO (es mejor).
Como <usuario>, <quiero obtener algo>, <para tal propósito>.
Como gerente de almacén, recibo un informe de balance de existencias MÁS RÁPIDO. - La división de "actores" en grupos: objetivo, importante, menos importante, etc. Asignación de nombres únicos a los actores en estos grupos, incluso si hay roles idénticos para los "Usuarios del sistema";
- Escribir una historia desde el punto de vista de estos actores con nombres únicos;
- Como resultado, puede ver qué historias se necesitan para los actores del grupo objetivo, un grupo importante, etc. Por lo tanto, puede priorizar;
- Acción. Es importante describir la historia al nivel de "¿Qué?" , en lugar de "¿Cómo?", describe el problema, no su solución. "¿Cómo?" está con el equipo;
- Valor. Rechazo de la redacción "A". Para algunas historias, puede indicar el valor de la historia en el formato "Para", pero no para la mayoría;
- La transición del concepto de "valor" (valor) al concepto de "impacto" (impacto). La historia no tiene que tener valor, pero debe tener un impacto en el actor que se indica en la historia. Esta influencia finalmente conduce a la meta;
- Las Historias de usuarios se desglosan por importancia y funcionalidad y se desglosan en tareas en la cartera de pedidos.
Refinación y evaluación de la cartera de productosOcurre en conjunto con el equipo de Desarrollo. El equipo debe evaluar cada tarea: ¿es factible en principio? ¿Hay suficiente información para ejecutar?
Formado por Sprint. Reunión de planificación de Sprint. Scrum pokerLa duración de la reunión no es más de 8 horas. Para un sprint de 2 semanas, el rally dura 2 horas. Para visualizar la ejecución de tareas en el sprint, es conveniente usar un tablero Kanban.
- La primera parte de la reunión está abierta a todos.
Derechos de voto con el propietario del producto y el equipo de desarrolladores. Selección de historia de usuario y tareas desde la cartera de productos hasta la cartera de Sprint;
Formulación de objetivos de Sprint - Objetivo de Sprint. Determinación del valor comercial. Una breve descripción del objetivo comercial para el cual se lleva a cabo este sprint. Ayuda al equipo a tomar decisiones informadas de negocios o decisiones alternativas. - La segunda parte del rally involucró solo al Equipo Scrum. Relleno de Sprint Backlog.
Determinar cómo se implementará el alcance del trabajo. Discusión de detalles técnicos;
Scrum Poker (Planning Poker).
Story Points (basado en la serie Fibonacci - 1,2,3,5,8,13). Las tareas de 13 o más puntos deben dividirse en otras más pequeñas. La fecha límite para completar una tarea por un desarrollador no es más de un día u 8 horas. Si el proyecto solo tiene un sprint, entonces no tiene sentido establecer Story Points, porque no habrá estadísticas y, en consecuencia, no habrá precisión en la determinación de las calificaciones.
Para asignar correctamente Story Points, puede mantener estadísticas, como en la siguiente tabla:
- Scrum Master dirige la reunión;
- El propietario del producto proporciona breves descripciones de cada tarea;
- Hay una discusión, se hacen preguntas;
- Los miembros del Equipo de Desarrolladores seleccionan una tarjeta, luego voltean;
- Si como resultado de la votación hay una gran dispersión en los puntos, escuche a dos que han entregado las tarjetas con el valor mínimo y máximo;
- Luego votan nuevamente y asignan Story Points a la tarea.
Reunión diaria de scrumSe lleva a cabo todos los días. Todos pueden mirar. Solo habla el equipo Scrum. Realizado por Scrum Master.
- Se lleva a cabo al mismo tiempo;
- Dura estrictamente no más de 15 minutos. La solución de problemas se lleva a cabo más allá del marco de la manifestación y como parte de las personas directamente afectadas por este obstáculo;
- Todos responden solo tres preguntas, se responden entre sí, no Scrum Master: ¿Qué hice ayer? ¿Qué haré hoy? ¿Qué problemas tengo y el equipo camino a la meta?
Reunión de revisión de SprintTodos están involucrados. Aumento significativo en la funcionalidad del producto. Demostración del producto terminado o funcionalidad.
Duración del rally: una hora por cada semana del sprint (2 horas de revisión de Sprint = 2 semanas de sprint). La preparación para esta reunión no debe exceder las 2 horas.
Reunión retrospectiva de Sprint. RetrospectivaSe celebra el último día del sprint.
Diseñado para evaluar el resultado del equipo. Se hacen preguntas: ¿qué se puede mejorar? como ¿Cómo aumentar la efectividad del equipo?
El tiempo retrospectivo para un sprint de 2 semanas no es más de 2 horas.
El concepto de kaizen y felicidad. Kaizen - mejora continua. Gente feliz = equipo de alto rendimiento.
Puedes hacer preguntas: ¿Qué puede hacerte más feliz en el próximo sprint? ¿Qué te hace más feliz?