Scrum
Descargar como PPTX, PDF0 recomendaciones688 vistas
El documento describe los principios y prácticas del framework ágil de desarrollo de software, incluyendo los derechos de programadores y propietarios de productos, así como las reuniones diarias, de planificación y retrospectivas. Se enfoca en la importancia de la comunicación, confianza y trabajo en equipo para entregar valor al cliente de manera iterativa.
Scrum
- 1. Agile software development framework
- 2. Somos un único equipo Tenemos una misma obsesión
- 3. Confianza en el otro Conseguir una relación de confianza entre todos los miembros del equipo
- 4. Programador, tienes derecho a: • Tienes el derecho a conocer que se necesita hacer, por orden de prioridad.
- 5. Programador, tienes derecho a: • Tienes el derecho a conocer que se necesita hacer, por orden de prioridad. • Tienes el derecho a producir siempre código de alta calidad.
- 6. Programador, tienes derecho a: • Tienes el derecho a conocer que se necesita hacer, por orden de prioridad. • Tienes el derecho a producir siempre código de alta calidad. • Tienes el derecho de pedir y recibir ayuda de compañeros, superiores y clientes.
- 7. Programador, tienes derecho a: • Tienes el derecho a conocer que se necesita hacer, por orden de prioridad. • Tienes el derecho a producir siempre código de alta calidad. • Tienes el derecho de pedir y recibir ayuda de compañeros, superiores y clientes. • Tienes el derecho de hacer y modificar tus propias estimaciones.
- 8. Programador, tienes derecho a: • Tienes el derecho a conocer que se necesita hacer, por orden de prioridad. • Tienes el derecho a producir siempre código de alta calidad. • Tienes el derecho de pedir y recibir ayuda de compañeros, superiores y clientes. • Tienes el derecho de hacer y modificar tus propias estimaciones. • Tienes el derecho de aceptar tus responsabilidades, en lugar de ser impuestas.
- 9. Product Owner, tienes derecho a: • Tienes el derecho a una planificación general, a conocer que se puede cumplir, cuando y a qué coste.
- 10. Product Owner, tienes derecho a: • Tienes el derecho a una planificación general, a conocer que se puede cumplir, cuando y a qué coste. • Tienes el derecho a recibir el máximo valor posible de cada semana de programación.
- 11. Product Owner, tienes derecho a: • Tienes el derecho a una planificación general, a conocer que se puede cumplir, cuando y a qué coste. • Tienes el derecho a recibir el máximo valor posible de cada semana de programación. • Tienes el derecho de ver evolución en un sistema funcionando.
- 12. Product Owner, tienes derecho a: • Tienes el derecho a una planificación general, a conocer que se puede cumplir, cuando y a qué coste. • Tienes el derecho a recibir el máximo valor posible de cada semana de programación. • Tienes el derecho de ver evolución en un sistema funcionando. • Tienes el derecho a cambiar de opinión, a cambiar funcionalidades y a cambiar las prioridades sin tener que pagar un precio exhorbitante.
- 13. Product Owner, tienes derecho a: • Tienes el derecho a una planificación general, a conocer que se puede cumplir, cuando y a qué coste. • Tienes el derecho a recibir el máximo valor posible de cada semana de programación. • Tienes el derecho de ver evolución en un sistema funcionando. • Tienes el derecho a cambiar de opinión, a cambiar funcionalidades y a cambiar las prioridades sin tener que pagar un precio exhorbitante. • Tienes el derecho a estar informado de los cambios de planificaciones, con el tiempo para poder elegir el scope para restaurar la fecha original.
- 14. Planning meeting
- 15. De esta reunión sale el objetivo del sprint
- 16. Planning meeting • El Product Backlog ya está ordenado y el equipo lo tiene revisado.
- 17. Planning meeting • El Product Backlog ya está ordenado y el equipo lo tiene revisado. • Los clientes resolverán las dudas que pueda tener el equipo.
- 18. Planning meeting • El Product Backlog ya está ordenado y el equipo lo tiene revisado. • Los clientes resolverán las dudas que pueda tener el equipo. • El equipo estima el valor de las historias usando las Planning Poker Cards.
- 19. Planning meeting • El Product Backlog ya está ordenado y el equipo lo tiene revisado. • Los clientes resolverán las dudas que pueda tener el equipo. • El equipo estima el valor de las historias usando las Planning Poker Cards. • El equipo decide las cantidad de puntos que se compromete a entregar al finalizar el Sprint.
- 21. “¿Cuánto se tarda?” Es una pregunta técnica y necesita ser respondida por gente técnica
- 23. Puntos
- 24. Si nos hemos equivocado, te lo haremos saber lo antes posible
- 25. Todo esto va de comunicación, no tanto de estimación Y por supuesto no de negociación
- 27. Conocer el estado del progreso del Sprint Solucionar los posibles impedimentos que surjan
- 28. Daily stand-up meetings • Conocer el estado del progreso del Sprint • Mejorar • Motivar • Foco • Hacer equipo
- 29. La reunión pertenece al equipo La conduce el equipo, no el SM
- 30. Daily stand-up meetings • Qué hice ayer.
- 31. Daily stand-up meetings • Qué hice ayer. • Qué haré hoy.
- 32. Daily stand-up meetings • Qué hice ayer. • Qué haré hoy. • Qué obstáculos impiden mi progreso.
- 33. Debe durar 15 minutos o menos
- 34. Si es demasiado baja: El SM buscará y propondrá alternativas al PO para volver a marcar un objetivo alcanzable. Si es demasiado alta: El SM puede proponer añadir nuevas historias al Sprint.
- 36. Trabajar de forma más eficiente tras cada sprint
- 37. No debería durar más de 1 hora Una reunión larga hace que la gente se canse, se aburra y se distraiga
- 38. Sprint Retrospective • El SM presenta los KPIs del Sprint. (Ha sido o no ha sido un buen sprint)
- 39. Sprint Retrospective • El SM presenta los KPIs del Sprint. (Ha sido o no ha sido un buen sprint) • Acciones ya implementadas del anterior plan de acción.
- 40. Sprint Retrospective • El SM presenta los KPIs del Sprint. (Ha sido o no ha sido un buen sprint) • Acciones ya implementadas del anterior plan de acción. • Cada persona expone “3 cosas que han funcionado bien” y “3 cosas a mejorar”.
- 41. Sprint Retrospective • El SM presenta los KPIs del Sprint. (Ha sido o no ha sido un buen sprint) • Acciones ya implementadas del anterior plan de acción. • Cada persona expone “3 cosas que han funcionado bien” y “3 cosas a mejorar”. • De la lista completa, cada persona reparte 3 a cada lista.
- 42. Sprint Retrospective • El SM presenta los KPIs del Sprint. (Ha sido o no ha sido un buen sprint) • Acciones ya implementadas del anterior plan de acción. • Cada persona expone “3 cosas que han funcionado bien” y “3 cosas a mejorar”. • De la lista completa, cada persona reparte 3 a cada lista. • De lo más votado a mejorar, se propondrá un plan de acción y un responsable que lo llevará a cabo.