The Dark Side of Scrum (SGBA2012)
•Als PPT, PDF herunterladen•
0 gefällt mir•978 views
Presentacion de Federico Zuppa en el Scrum Gathering de Buenos Aires (Mayo de 2012)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie The Dark Side of Scrum (SGBA2012)
Ähnlich wie The Dark Side of Scrum (SGBA2012) (20)
Mehr von Federico Zuppa
The Dark Side of Scrum (SGBA2012)
- 1. The Dark Side of Scrum – SGBA 2012 Federico Zuppa
- 2. Porque nos gusta tanto? Que problemas surgen en la práctica?
- 3. Scrum ScrumMaster Scrum Diario Product Owner Retrospectiva 24 horas de Sprint Planificación de Release Sprint Incremento de 1-4 semanas funcionalidad Product Backlog Sprint Backlog Visión + ROI Demo Planificación de Sprint de Sprint Equipo
- 4. Auto-Organización “Los equipos en Scrum son auto-organizados. Nadie les dice como convertir el backlog en un incremento de funcionalidad” La auto-organización es el proceso donde una estructura o patrón aparece en un sistema sin una autoridad central. ▶ Un sistema auto-organizado no es inherentemente bueno (chequeen esto sino) – Dirección – Restricciones – Guias ▶ Alinear Restricciones (Jurgen Appelo)
- 5. Auto-Organización [problemas] ▶ No ha sido claro el rol del manager – El rol del manager en Scrum es el de un “Servant Leader” ▶ La auto-organización no encaja con ciertos tipos de caracteres
- 6. Colocation No es una práctica de Scrum per se (es más bien una práctica de XP open workspace) ▶ Comunicación – El equipo trabaje en un contexto donde fluya la información ▶ En un equipo distribuido se pierde (Cory Foy): – Gestos corporales – Conversaciones de cafe-mate – Introspección instantanea – Ayuda instantanea
- 8. Colocation [problemas] ▶ Equipos Grandes – Subdividir en equipos ▶ Equipos Distribuidos – Aumentar el bandwith de comunicación – Tener una buena herramienta – Tener equipos cross funcionales en todas las ubicaciones y minimizar las dependencias
- 9. Capacidad de Batch Limitada “El corazón de Scrum es el Sprint, una iteración acotada donde se crea un incremento de producto potencialmente listo para salir a producción” Scope box o Time box?
- 10. Por que time boxes? Timeboxes traen estos beneficios al desarrollo de software: ▶ Timeboxing fuerza un cierre, fuerza al equipo a entregar algo concreto ▶ Time boxes son aventuras de corto plazo. Entender la capacidad – Permite realizar una estimación más precisa del backlog ▶ Permite generar una cadencia
- 11. Time boxes [problemas] ▶ Las User Stories son muy grandes – Existen técnicas para dividir las US ▶ Fluctuaciones – Termina antes – No llega y toma atajos para llegar a la demo ▶ El mismo equipo tiene otras responsabilidades (soporte de producción) – Dejar un buffer ▶ La capacidad del equipo fluctua – Abandonar los time boxes?
- 12. Contacto con el cliente El product owner es el encargado en Scrum de crear un backlog de requerimientos priorizado y de asegurar que el equipo de desarrollo lo entienda. ▶ El equipo tiene que entender el problema. – El desarrollo de software es un problema de comunicación! Pregunta a los expertos: Tiene que ser el PO alguien del cliente?
- 13. Contacto con el cliente [problemas] ▶ El PO no tiene tiempo – Un BA puede ayudar ▶ El PO no tiene la capacidad para llevar a cabo esta tarea ▶ El PO no esta colocado con el equipo de desarrollo
- 14. Equipo Multidisciplinario “Los equipos en Scrum son multidisciplinarios con todas las habilidades necesarias para crear un incremento del producto.”
- 15. Equipo Multidisciplinario [problemas] ▶ La carga entre las diferentes especializaciones no esta balanceada – Escoger las stories de acuerdo a la carga
- 16. Planificación “El product backlog es una lista priorizada de items necesarios en el producto final. Los items en el tope de la lista estan más detallados y mas precisamente estimados”
- 17. Planificación [problemas] ▶ Cuanta planificación debemos hacer? – Dividir en releases ▶ Cuanto tiempo debemos invertir en esta planificación? – Estimaciones time boxed
- 18. Cuanto invertir en la estimación?
- 19. Estimaciones [problemas] ▶ Son usadas para presionar a los desarrolladores
- 20. User Stories ▶ Una User Story es una descripción corta y simple de un feature visto desde el punto de vista de un cliente – Las user stories son escritas en fichas o sticky notes, lo cual facilita la planificación y alienta la discusión
- 21. User Stories [problemas] ▶ Se pierde el big picture – Story Maps ▶ Se filtra diseño – Que se necesita y no como se logra ▶ En muchos contextos, las US no son la manera más adecuada de expresar los requerimientos – No usar US!
- 22. Roles Scrum tiene 3 roles: ▶ Scrum Master – Vela por el proceso y elimina impedimentos ▶ Product Owner – Es el responsable del Product Backlog ▶ Equipo de Desarrollo – Es el responsable de construir el producto
- 23. Roles [problemas] ▶ Una persona comparte 2 roles – Nunca los roles de PO y SM!
- 24. Retrospectiva “Es una oportunidad para que equipo inspeccione y cree un plan para mejorar en el próximo Sprint” El proposito de la retrospectiva es: ▶ Inspeccionar como anduvo el Sprint respecto a la gente, relaciones, procesos y herramientas ▶ Identificar y ordenar los items que anduvieron bien y las potenciales mejoras ▶ Crear un plan para implementar estas mejoras
- 25. Retrospectiva [problemas] ▶ Se vuelven aburridas – Varias las actividades ▶ No existe confianza entre los integrantes del equipo
- 26. Prácticas Técnicas Las prácticas técnicas no son parte de Scrum Que pasa cuando hacemos Scrum sin tener tests, CI y sin refactoring continuo?
- 27. The Scrum Wall “You can’t keep your commitments, you can’t release software, your customers get annoyed and angry, it looks like Scrum is broken.”
- 28. Muchas gracias…
Hinweis der Redaktion
- Scrum no es un proceso o una tecnica. Es un framework dentro del cual se pueden incluir diferentes procesos y tecnicas. El framework consiste de los diferentes scrum teams, junto con sus roles, eventos, artefactos y reglas. Cada componente sirve un proposito y es esencial para el exito en el uso de Scrum.
- Un sistema organizado esta compuesto de agentes inteligentes, que interactuan entre si. La solución emerge de estos sistemas. Es decir, no puede ser traceada a componentes individuales, sino que es el resultado del comportamiento del sistema. Un sistema auto organizado no es inherentemente bueno. Como aseguramos que el equipo se autoorganizara hacia la creacion de valor? Si leemos la guia de Scrum, se puede hacer una vista demasiado ingenua. Scrum especifica que el equipo se auto organiza en respuesta a la presion de un deadline (de la iteracion, cada 2-3 semanas). Esta vision es un tanto utopica, segun muchos autores. Jim Highsmith especifica que se debe setear una direccion, un conjunto de restricciones y guias para que el equipo se auto organice dentro de un contexto. Jurgen Appelo, dentro de su modelo de Management 3.0, habla de alinear restricciones
- Un sistema organizado esta compuesto de agentes inteligentes, que interactuan entre si. La solución emerge de estos sistemas. Es decir, no puede ser traceada a componentes individuales, sino que es el resultado del comportamiento del sistema. Un sistema auto organizado no es inherentemente bueno. Como aseguramos que el equipo se autoorganizara hacia la creacion de valor? Si leemos la guia de Scrum, se puede hacer una vista demasiado ingenua. Scrum especifica que el equipo se auto organiza en respuesta a la presion de un deadline (de la iteracion, cada 2-3 semanas). Esta vision es un tanto utopica, segun muchos autores. Jim Highsmith especifica que se debe setear una direccion, un conjunto de restricciones y guias para que el equipo se auto organice dentro de un contexto. Jurgen Appelo, dentro de su modelo de Management 3.0, habla de alinear restricciones
- La guia de Scrum nunca habla de un equipo colocado. Si habla de un equipo chico, que no requiere grandes mecanismos de coordinacion y de un proceso transparente a todos los miembros del equipo, pero nunca de colocacion. Sin embargo, cuando hablamos de Scrum y sobre todo en una transición, uno de los primeros puntos que tocamos es que el equipo necesita estar colococado (en el mismo lugar) y en un open space (un espacion abierto)
- La guia de Scrum nunca habla de un equipo colocado. Si habla de un equipo chico, que no requiere grandes mecanismos de coordinacion y de un proceso transparente a todos los miembros del equipo, pero nunca de colocacion. Sin embargo, cuando hablamos de Scrum y sobre todo en una transición, uno de los primeros puntos que tocamos es que el equipo necesita estar colococado (en el mismo lugar) y en un open space (un espacion abierto)
- La guia de Scrum nunca habla de un equipo colocado. Si habla de un equipo chico, que no requiere grandes mecanismos de coordinacion y de un proceso transparente a todos los miembros del equipo, pero nunca de colocacion. Sin embargo, cuando hablamos de Scrum y sobre todo en una transición, uno de los primeros puntos que tocamos es que el equipo necesita estar colococado (en el mismo lugar) y en un open space (un espacion abierto)
- Timeboxes bring these benefits software development: - "Timeboxing forces closure, it forces the team to deliver something concrete" (Highsmith). When exploring, it is very difficult to scope a feature. Teams are discovering and therefore, times can expand indefinitely. This contrasts with the date constraints that projects always have. Timeboxes force a date constrained exploration and it forces the development team to focus on delivering something. - Timeboxes are short term adventures, marked by decision points at the beginning and at the end. These decisions points allow the business to take decisions. The word "short" is important here. Timeboxes are short while scope-boxes tend to be larger. - Timeboxes create a cadence. The team enters a cycle that repeats every 2/3 weeks. After that period, the team review how it performed, adapts and recommits for the next iteration.
- Timeboxes bring these benefits software development: - "Timeboxing forces closure, it forces the team to deliver something concrete" (Highsmith). When exploring, it is very difficult to scope a feature. Teams are discovering and therefore, times can expand indefinitely. This contrasts with the date constraints that projects always have. Timeboxes force a date constrained exploration and it forces the development team to focus on delivering something. - Timeboxes are short term adventures, marked by decision points at the beginning and at the end. These decisions points allow the business to take decisions. The word "short" is important here. Timeboxes are short while scope-boxes tend to be larger. - Timeboxes create a cadence. The team enters a cycle that repeats every 2/3 weeks. After that period, the team review how it performed, adapts and recommits for the next iteration.
- The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Ensuring the value of the work the Development Team performs; Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, Ensuring the Development Team understands items in the Product Backlog to the level needed
- The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Ensuring the value of the work the Development Team performs; Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, Ensuring the Development Team understands items in the Product Backlog to the level needed