the dark side of scrum (sgba2012)

28
The Dark Side of Scrum – SGBA 2012 Federico Zuppa

Upload: federico-zuppa

Post on 13-Jul-2015

896 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: The Dark Side of Scrum (SGBA2012)

The Dark Side of Scrum – SGBA 2012

Federico Zuppa

Page 2: The Dark Side of Scrum (SGBA2012)

Porque nos gusta tanto?

Que problemas surgen en la práctica?

Page 3: The Dark Side of Scrum (SGBA2012)

Scrum

Scrum Diario

24 horas

Sprint1-4 semanas

Planificación de Sprint Demode Sprint

Retrospectiva de Sprint

Product Backlog Sprint Backlog

Incremento de funcionalidad

Visión + ROI

Planificación de Release

Product Owner

ScrumMaster

Equipo

Page 4: The Dark Side of Scrum (SGBA2012)

Auto-Organización

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)

“Los equipos en Scrum son auto-organizados. Nadie les dice como convertir el backlog en un incremento de funcionalidad”

Page 5: The Dark Side of Scrum (SGBA2012)

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

Page 6: The Dark Side of Scrum (SGBA2012)

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

Page 7: The Dark Side of Scrum (SGBA2012)

Colocación [Comunicación]

Page 8: The Dark Side of Scrum (SGBA2012)

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

Page 9: The Dark Side of Scrum (SGBA2012)

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?

Page 10: The Dark Side of Scrum (SGBA2012)

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

Page 11: The Dark Side of Scrum (SGBA2012)

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?

Page 12: The Dark Side of Scrum (SGBA2012)

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?

Page 13: The Dark Side of Scrum (SGBA2012)

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

Page 14: The Dark Side of Scrum (SGBA2012)

Equipo Multidisciplinario

“Los equipos en Scrum son multidisciplinarios con todas las habilidades necesarias para crear unincremento del producto.”

Page 15: The Dark Side of Scrum (SGBA2012)

Equipo Multidisciplinario [problemas]

▶ La carga entre las diferentes especializaciones no esta balanceada

– Escoger las stories de acuerdo a la carga

Page 16: The Dark Side of Scrum (SGBA2012)

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”

Page 17: The Dark Side of Scrum (SGBA2012)

Planificación [problemas]

▶ Cuanta planificación debemos hacer?

– Dividir en releases

▶ Cuanto tiempo debemos invertir en esta planificación?

– Estimaciones time boxed

Page 18: The Dark Side of Scrum (SGBA2012)

Cuanto invertir en la estimación?

Page 19: The Dark Side of Scrum (SGBA2012)

Estimaciones [problemas]

▶ Son usadas para presionar a los desarrolladores

Page 20: The Dark Side of Scrum (SGBA2012)

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

Page 21: The Dark Side of Scrum (SGBA2012)

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!

Page 22: The Dark Side of Scrum (SGBA2012)

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

Page 23: The Dark Side of Scrum (SGBA2012)

Roles [problemas]

▶ Una persona comparte 2 roles

– Nunca los roles de PO y SM!

Page 24: The Dark Side of Scrum (SGBA2012)

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

Page 25: The Dark Side of Scrum (SGBA2012)

Retrospectiva [problemas]

▶ Se vuelven aburridas

– Varias las actividades

▶ No existe confianza entre los integrantes del equipo

Page 26: The Dark Side of Scrum (SGBA2012)

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?

Page 27: The Dark Side of Scrum (SGBA2012)

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.”

Page 28: The Dark Side of Scrum (SGBA2012)

Muchas gracias…