scrum

 
ROLES SCRUM

ROLES SCRUM

Son 3 roles: Product Owner, Scrum Master, Equipo de Desarrollo.

SCRUM

SCRUM

El contexto scrum es fácil de comprender, pero difícil de implementar.

REFINAR EL PRODUCT BACKLOG

REFINAR EL PRODUCT BACKLOG

Refinar el product backlog es responsabilidad del product owner y es lo que determina la capacidad de adaptación del proyecto.

SPRINT PLANNING

SPRINT PLANNING

Una sesión de no más de cuatro horas en la que el equipo define el alcance del sprint.

PRODUCTO INCREMENTAL

PRODUCTO INCREMENTAL

Al terminar el sprint tenemos un producto incremental con potencial de ser entregado y que tiene valor para el PO.

DAILY SCRUM

DAILY SCRUM

Todos los días, 15 minutos. Sincronizar, medir el estado del proyecto, encontrar impedimentos.

 

Esto es scrum

Scrum es fácil de entender pero complejo de implementar

Scrum es un marco de trabajo, el cual permite definir, desarrollar e implementar productos que requieren ser construidos de manera iterativa y adaptativa, con el fin de entregar el máximo valor posible y creativamente a los clientes y a las organizaciones.

Scrum se basa en un enfoque empírico, en el cual se fomenta continuamente el desarrollo, la inspección y adaptación, para ello se soporta una serie de prácticas, eventos y artefactos que facilitan la elaboración de productos y servicios. Por último, Scrum se basa en tres Tres pilares que soportan toda la implementación del control de procesos empírico: transparencia, inspección y adaptación.

SCRUM FRAMEWORK.png
 

Roles scrum

Scrum requiere de tres roles esenciales para poder funcionar correctamente, mismos que se describen a continuación.

Product Owner (PO)

Este rol es el responsable de la definición de la visión del producto y por tanto de las historias de usuario requeridas para poder completar la visión, por lo tanto, es responsable del Product Backlog. Cabe resaltar que el PO también cuenta con la perspectiva del Cliente, por lo que constantemente tiene que asegurar que el producto y las historias corresponden al valor que esperan los diferentes tipos de clientes y stakeholders del producto.

PRODUCT OWNER.png
SCRUM MASTER.png

Scrum Master (SM)

El Scrum Master es el responsable de que el contexto de Scrum se lleve a cabo, además de atender y resolver los impedimentos que se presenten en el equipo de desarrollo. El Scrum Master debe ejercer un liderazgo servicial a fin de desarrollar las habilidades y capacidades del equipo

Equipo de desarrollo

El equipo de desarrollo es responsable de definir, construir, probar e implementar las historias de usuario, comprometiéndose a entregar en un sprint.

EQUIPO DE DESARROLLO.png
 

Sprint Planning

La idea del Sprint

La forma en cómo se inicia el desarrollo del producto es a través de las iteraciones que en Scrum se llaman Sprints.

 

Los Sprints se llevan en un tiempo determinado que el equipo y/o la organización decide; puede variar entre dos y hasta seis semanas, aunque la recomendación como buena práctica es de dos.

Una vez iniciado un Sprint, se debe concluir sin interrupciones y de acuerdo a las metas establecidas de resultados durante ese periodo de tiempo, además que se recomienda que siempre sean del mismo tiempo, esto para asegurar la cadencia en la entrega de un producto potencialmente a usar por el cliente.

SPRINT PLANNING.png

Planeación del Sprint

 

En la planeación del Sprint se define la capacidad del equipo para poder desarrollar el producto, con base en ésta se determinan las historias que se podrán ejecutar y que no excedan la capacidad del equipo; las historias a su vez se descomponen en tareas; con estas definiciones entre el equipo y el Product Owner determinarán las metas a cumplir en ese Sprint y el equipo se compromete al desarrollo de éstos, mismos que se plasmarán en el Sprint Backlog.

El Sprint backlog será monitoreado para su ejecución a través del Scrum Board, donde se visualizan diferentes estados en los que las historias y tareas durante la ejecución del Sprint se les dará seguimiento hasta su conclusión.

Sprint backlog

El Sprint backlog será monitoreado para su ejecución a través del Scrum Board, donde se visualizan diferentes estados en los que las historias y tareas durante la ejecución del Sprint se les dará seguimiento hasta su conclusión.

SPRINT BACKLOG.png
 

Daily Scrum

Este evento en Scrum sirve para que se visualice el trabajo que está desarrollando el equipo, así como cualquier obstáculo que tengan para el cumplimiento de las metas del Sprint.

Este evento tiene las siguientes características

  1. 15 minutos, todos los días.

  2. Tres preguntas:

    • ¿Qué hice ayer?

    • ¿Qué voy a hacer hoy?

    • ¿Qué obstáculos me impiden avanzar?

  3. NO es una sesión de solución de problemas, ni de planeación, coordinación o temas misceláneos.

  4. La coordina el Scrum Master.

  5. Puede asistir el Product Owner y otras personas pero solo escuchan.

DAILY SCRUM.png
 

Potentialy Shippable Product Increment

PRODUCT VISION.png

Uno de los objetivos de Scrum es que, en un solo Sprint, el equipo sea capaz de desarrollar historias que den el máximo valor a través de un producto potencialmente a entregar.

Por lo general los primeros Sprints están orientados a trabajar sobre la arquitectura y definir la infraestructura en la que se desarrollará el producto, o bien demostrar la viabilidad técnica del producto, para asegurar que se ha tomado la decisión sobre el máximo valor requerido.

POTENTIALY SHIPPABLE PRODUCT.png
 

Refinamiento del Product Backlog

PRODUCT BACKLOG REFINING.png

A fin de lograr la visión del producto, ésta  se descompone en historias de usuario, las cuales se integra en una lista ordenada misma que se le conoce como Product Backlog.

 

Este artefacto es responsabilidad del Product Owner y debe asegurar su correcto mantenimiento para asegurar que este priorizado de acuerdo al VALOR, costo, riesgo y complejidad.

El product backlog es un artefacto que debe ser actualizado constantemente, respondiendo a la entrega de valor durante la ejecución, mayor detalle en la visión o bien de algunos elementos nuevos que se deben integrar. Esta actividad es responsabilidad del Product Owner y el Scrum Master debe estar asegurando que este en mantenimiento, a fin de que el contecto de Scrum funcione adecuadamente.