.

¿Como se desarrolla un proyecto con scrum?

En nuestra última lección sobre la planificación de los sprints aprendimos que un proyecto gestionado con Scrum se desarrolla a partir de un número de sprints consecutivos. Recuerda que sprint es el término que empleamos en Scrum para referirnos a las iteraciones, y que estas son ciclos de trabajo en los que nos centramos en un subconjunto de características del producto final y creamos un producto utilizable. Además, el número de sprints que integran cada proyecto dependerá del propio proyecto.

Los elementos del sprint

Un proyecto que sigue Scrum se gestiona siguiendo cinco eventos:

eventos scrum

1.- El Sprint: cada proyecto Scrum es un conjunto de Sprints. Un Sprint contiene, tal y como muestra el diagrama de arriba, los otros cuatro eventos o rituales, el esfuerzo de desarrollo, y el mantenimiento del Backlog de Producto

2.- La Planificación del Sprint: es el primer evento dentro de un Sprint. El Equipo Scrum planea los artículos que se van a entregar en el Sprint y cómo se hará.

3.- El Scrum Diario: durante el Sprint, el equipo de desarrollo tiene una reunión diaria de 15 minutos, durante la cual se coordinar el trabajo de las próximas 24 horas. Esta reunión se llama Scrum Diario.

4.- Revisión del Sprint: antes del final del Sprint el equipo de Desarrollo demuestra el resultado del Sprint al cliente y recibe retroalimentación (feedback). Esta reunión se llama Revisión del Sprint, también se conoce como Demostración del Sprint.

5.- Retrospectiva del Sprint: después de la revisión de Sprint y justo antes de que finalice el Sprint, el equipo de desarrollo tiene una reunión interna para revisar el Sprint y mejorar el proceso (lecciones aprendidas) en el próximo Sprint. Esta reunión se conoce como Retrospectiva del Sprint.

Desarrollar un proyecto con scrum

Tan pronto como la reunión de Planificación del Sprint se ha celebrado, no podremos añadir, eliminar o modificar ningún elemento del Backlog del Sprint. De esta manera, evitando modificaciones en el Backlog del Sprint, queremos mantener la concentración del Equipo de Desarrollo para completen los artículos planificados.

Los desarrolladores empiezan a trabajar en los artículos de la parte superior del Backlog de Producto, y los completan al 100% antes de pasara a los siguientes artículos. Así mismo, diseñan, programan, integran y prueban todos y cada uno de los artículos.

La “prueba” incluye todos los tipos de prueba. La razón es que al finalizar el sprint debemos estar completamente seguros de que el artículo se ha desarrollado completamente, al 100%. Solo de esa manera podremos obtener un feedback efectivo al presentárselo al cliente.

Por lo tanto, las pruebas de aceptación del usuario son también parte del concepto de prueba. Tan pronto como todo está preparado los desarrolladores solicitan una prueba de aceptación de los nuevos artículos desarrollados durante el sprint. Las pruebas se realizan a lo largo de todo el sprint; no es necesario esperar y realizarlas al final del sprint.

La colaboración entre todos los desarrolladores es fundamental: todos deben estar en “la misma página”, pero ¿cómo lograrlo? Lo veremos en nuestro siguiente post.

Saludos y hasta pronto.

JLVG

QuieresCursoGratisImagen700X150_3

Otras lecciones de este curso

01. Curso Gratis de Introducción a Scrum

02. Entonces… ¿qué son los sistemas predictivos y adaptativos?

03. El Backlog de Producto

04. El scrum team: el Dueño del Producto

05. Los sprints

06. La estimación de los elementos de Backlog de Producto

07. Puntos de historia y velocidad

08. Póker de Planificación

09. El scrum team: el Scrum Máster

10. ¿Quien es el Project Manager en scrum?

11. ¿Cómo se desarrolla un sprint?

12. El desarrollo del sprint: medición y cancelación

13. Eventos scrum: el Scrum Diario

14. Eventos scrum (II): la Retrospectiva del Sprint

15. Artefactos scrum (I)

16. Artefactos scrum (II)

17. La “definición de completo”

18. ¿Cómo funciona scrum?

19. Certificaciones scrum

20. Referencias

6 respuestas a “¿Como se desarrolla un proyecto con scrum?”

  1. Rafael de la Osa Diaz dice:

    Excelente curso, excelentes comentarios y excelente estrategia pedagogica. No recuerdo nada tan claro, preciso y corto sobre un tema tan técnico sobre el que cada cual tiene su propio “librito”. Me quedan muchas dudas pero más ganas de probar en la práctica cuan bien funciona. Felicitaciones.

    • Juan Luis Vila Grau dice:

      Hola Rafael! Muchas gracias por tus comentarios; así da gusto trabajar en la elaboración de nuevos contenidos.
      Ya sabes que cualquier duda al respecto no tienes más que escribirnos, estaremos encantado de ayudarte.

  2. Pedro dice:

    Hola,
    No tengo claro cuando se hace la estimacion. Si se hace en la reunión de refinamiento, en el sprint planning o en ambas?.
    Siempre he oído que los ítems con la prioridad mas alta del Product Backlog deben estar estimados. Entiendo que esto se hace en las reuniones de refinamiento, asi como cuando se añadrn ítem nuevos al PB. Es correcto?
    Pero por otro lado, cuando se hace el Sprint Planning, la reunión suele dividirse en 2 partes, una primera donde se estima las Historias que el PO querria incluir en el Sprint(el PO debería llevar preparadas historias cuyos story points estén por encima de la velocidad media del equipo) y la segunda parte donde se hace el tasking.
    Pero esto seria estimar 2 veces. Cual es el punto de hacerlo?
    Como haceis el Sprint Planning? podríais detallarlo? Como esta el PB (trabajado, priorizado, estimadas las primeras US), partes, etc… porque todo el mundo lo explica a grandes rasgos, pero cuando te poner en ello, muchas veces no sabes por donde tirar.
    Varias cosas que he buscado por todas partes y apenas he encontrado nada son
    Agenda (alguna hay, pero poco)
    Y una cosa que parecerá una tontería, pero al menos para mi no lo es… Ya se que cada uno dice y hace las cosas a su manera, pero no he encontrado ni un solo ejemplo de video, ni texto en el que se transcriba una reunión de planificación. Que diría el Scrum master en cada momento en un caso de ej.

    Saludos

    • Juan Luis Vila Grau dice:

      Hola Pedro,

      Gracias por escribir, y por leer el blog.

      Vamos a la cuestión que nos planteas respecto a cuando tienen lugar las estimaciones.

      1. Las estimaciones en puntos de historia por parte del equipo de desarrollo tienen lugar principalmente durante la reunión de refinamiento del Backlog del Producto. Estas reuniones pueden considerare como preparatorias para la Planificación del Sprint. Llegar a esta última reunión sin haber trabajado previamente los ítems del Backlog de producto que se espera desarrollar durante el siguiente Sprint implicará que la reunión no de planificación se desarrolle de manera adecuada. Al respecto la reunión de planificación sirve para revisar o confirmar las estimaciones realizadas previamente, y comenzar a desgranar las historias de usuario en tareas para que el equipo se las distribuya entre sus miembros.

      Puedes leer más respecto a la importancia del refinamiento del Backlog del Producto en el siguiente post: http://managementplaza.es/blog/mejorar-la-planificacion-scrum/

      2. Respecto a la estimación que se lleva a cabo sobre os nuevos ítems que se añaden al Backlog de Producto, hay que tener en cuenta su “prioridad”. Es decir, de poco servirá el equipo trabajar en la estimación detallada de aquellos ítems que no sean prioritarios, y no se prevea incluirlos en el próximo o próximos sprints. Al respecto tambien existen diferentes métodos de estimación que permiten hacerlo de manera más rápida, pero menos detallada. Por ejemplo, la estimación por afinidad.

      3. Tomo nota sobre tu interés en profundizar sobre la reunión de planificación y en breve haremos una publicación al respecto. De momento permite que te recomiende revisar los siguientes posts:
      http://managementplaza.es/blog/los_sprints_y_su_planificacion/
      http://managementplaza.es/blog/acontecimiento-2-planificacion-del-sprint/
      http://managementplaza.es/blog/5-errores-frecuentes-la-planificacion-del-sprint/

      Cualquier otra cuestión o comentario al respecto, por aquí estamos.

      Saludos cordiales,

      JLVG

  3. Pedro dice:

    Muchas gracias por tu respuesta y espero que por las futuras ;). Me surgen las siguientes preguntas.
    Cuando dices que el planning es pare revisar o confirmar las estimaciones previas, si no ha habido cambio en el alcance de la historia, siempre se estima en el planning?
    Si realizamos sesiones de grooming para que las historias lleguen trabajadas y estimadas al planning, tengo varias preguntas al respecto.
    1. La primer parte del planning donde el PO presenta la historia y el equipo hace preguntas, se sigue manteniendo? o es un trámite en el que se pregunta si ha habido algún cambio en el alcance?
    2. El timebox del planning sigue siendo el mismo? o se reduce al tener que invertir mucho menos tiempo en esta primer parte de la reunion?

    • Juan Luis Vila Grau dice:

      Hola Pedro,

      Una vez más gracias por tu interés, y por escribir a través del blog.
      Respecto a la aplicación de scrum es conveniente recordar que:

      1. Se trata de un marco de trabajo y como tal no contiene todos los detalles que, en ocasiones nos gustaría, para tomarlo como referencia en su aplicación.

      2. Cada cual aplica scrum a su manera, dentro de los límites establecidos por el marco de trabajo. Aquí estriba una de las principales dificultades pero también beneficios de scrum al permitir su adaptación.

      3. El equipo scrum debe ser “auto gestionado”, y por ello tiene capacidad de gestión no solo sobre el contenidos, también sobre el proceso. Al respecto es conveniente recordar la utilidad de las retrospectivas.

      Dicho lo anterior te comento respecto tus dudas:

      1. Respecto a la estructura de la reunión de planificación yo la mantendría siempre que esta fuera de útil al equipo. Sin embargo, el equipo es libre de plantear cualquier modificación al respecto. Lo importante no es en sí mismo el evento, sino cumplir con sus propósitos.

      2. Ten en cuenta que el concepto de timebox para todos los eventos scrum, excepto para el sprint, implica una duración máxima de tiempo. Es decir, si hemos cumplido con el propósito de la reunión antes de agotar el tiempo máximo, debemos concluir la reunión y poner el equipo a trabajar.

      Saludos cordiales,

      JLVG

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  Juan Luis Vila Grau

SAFe® 4 Certified Agilist, PRINCE2® Practitioner, Scrum Product Owner (PSPO I), Scrum Master (PSMI), EXIN Agile Scrum Foundation, AgilePM® Foundation, Management_of_Risk (M_o_R®) Foundation. and an enthusiastic of Agile management. Especialistas en técnicas participativas para la gestión de proyectos, y en el Enfoque del Marco Lógico (EML). Faclilitador certificado en el método LEGO® Serious Play®

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR