SCRUMFundamentos y principios

Manifiesto ágil

¿qué es scrum?

“Es un marco de trabajo ágil por el cual las personas pueden acometer problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente”.

Scrum es:

• Ligero• Fácil de entender• Extremadamente difícil de llegar a dominar

¿Qué es scrum?

• Scrum se basa en la teoría de control de procesos empírica o empirismo.

• Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.

¿Qué es scrum?

evolución

(15 min.)

(Hasta 8 hrs.)(1-3 hrs.)

(2-4 hrs.)

1 Día

Cómo funciona

Tradicional vs. ágil

componentes

Roles en scrum

Cerdos Gallinas¿Quién?• Product Owner• Scrum Master• Equipo de Desarrollo

Comprometido en:• El proyecto y el proceso Scrum.• Construir software de manera

regular y frecuente.• Tiene el “tocino en el sartén”.

¿Quién?• Usuarios • Stakeholders• Expertos

Cualquiera que esté involucrado e interesado en el proyecto.

No son parte del proceso Scrum.Sus ideas, deseos y necesidades son tomadas en cuenta, pero no en un sentido en que puedan afectar o distorsionar el projecto Scrum.

Roles en scrum

Mapenado los roles

El equipo de desarrolloDeberes

• El equipo debe ser auto-organizado. Los propios miembros del equipo establecerán la forma de hacer su trabajo.

• Tiene que ser multifuncional.• Todos los miembros deben trabajar con sus habilidades para cumplir el sprint goal.• Los equipos de desarrollo deben ser pequeños, de 3 -7 personas.• Junto con el Scrum Master, se encargan de establecer los ítems del Sprint Backlog, de planificar

el sprint.• Estimar las historias de usuario y tareas.• Hacer la demo.• Implementar pruebas de aceptación y pruebas unitarias.• Trabajo de calidad y mejora continua de la calidad (refactorización, por ejemplo)• Participar en los Daily meeting, Sprint Planning Meeting, Sprint Review y Sprint Retrospective.• Estar motivados.• Saber buenas prácticas de programación: pair programming, TDD, integración continua,

refactorización, malos olores, patrones de diseño, etc.• Identificar posibles obstáculos y comunicárselos al Scrum Master.• Actualizar el trabajo en progreso (burndown chart) (es responsabilidad tanto del equipo de

desarrollo como del Scrum Master)

El equipo de desarrollo

Derechos

• La organización tiene que animar al equipo a auto-organizarse, sin entrometerse en su forma de trabajar.

• A que sólo bajo contadas y controladas circunstancias, las tareas del sprint sean modificadas una vez que este ha comenzado.

Equipo ágil auto-organizado

Scrum developer

• Actitud mosquetero

• Todo el equipo es responsable de la construcción del producto

• Habilidades “T”

Scrum: artefactos

Product backlog

• Lista priorizada y secuencial de características o “historias de usuario”.

• Basada en la visión de producto del PO.

• Responsabilidad del PO.

• Siempre el trabajo más valioso va primero, y va más detallado.

Sprint backlog

• Lista prevista de desarrollo o ejecución para un (1) Sprint.

• Items primeros en el PB, con estimación acorde al Sprint.

• Desagregado de los items del PB en tareas específicas y asignadas en el DT.

• Items susceptibles de ser afrontados con KANBAN.

Producto potencialmente entregable• Una parte o sección de

producto construida o “hecha”.

• Parte o sección dispuesta a ser liberada.

• La liberación es una decisión de negocio, no es imperativo.

Scrum: actividades

Scrum: actividades

sprint

Sprint planning

• Reunión de revisión de PB para llegar a acuerdos (PO, SM, DT).• Selección de común acuerdo de X cantidad de items del PB al

SB.• Estimación de items (generalmente horas)• Item > Tareas > Llenar la capacidad

Daily scrum

• Revisión de inspección y adaptación. - SM, DT, PO (pasivo)• “Daily stand-up”• Generalmente:

- ¿Qué logré desde el último Daily?- ¿Cuál es mi plan para el siguiente Daily?- ¿Qué obstáculos enfrento?

• Gallinas y cerdos

Sprint execution

Sprint review

Sprint retrospective

Backlog gromming

Tres maneras de fracasar en un proyecto ágil1 – El contrato, el cliente y el modelo de negocio.

• Decía el manifiesto ágil que aquello de que la agilidad requería de “Colaboración con el cliente sobre negociación contractual”. Pero claro, si tu cliente es de los que te entrega al principio del proyecto un documento enorme lleno de requisitos, clausulas y posibles penalizaciones y no vuelves a verlo hasta el último día de proyecto… olvídate de la agilidad, en serio, no va a funcionar.

• La agilidad pretende obtener software que cumpla lo que los usuarios necesitan no que cumpla lo que pone en un documento de requisitos.

2 – La calidad software.• Antes de ser ágil, hazte las siguientes preguntas…• ¿Tenemos un robusto control de versiones? ¿programamos con

calidad? ¿hacemos código espagueti? ¿copy paste? ¿complejidad ciclomática disparada? ¿pruebas unitarias? ¿diseño mantenible? ¿refactorizas? etc., etc., etc. Supongo que saber por dónde voy, no es cuestión de seguir con la lista.

• Los anteriores son tan necesarios en un proyecto ágil, como en cualquier proyecto software, pero en uno ágil, por lo cortas que son las iteraciones… tiene el doble de impacto…si no las tienes a la perfección… dudo que la agilidad te dure más de 5 iteraciones.

• Como decía Fowler, “If you’re afraid to change something it is clearly poorly designed”.

3 – La documentación

• Volviendo al manifiesto ágil… “Software funcionando sobre negociación extensiva”. Lo que no es lo mismo que “Software funcionando Y NO documentación comprensiva”.

• Que en agilidad la documentación es menor, cierto. Que ocupa otro rol, cierto. Que se crea de otra manera, también. Pero no que no hay documentación.

• Recuerda aquello de cómo lograr que tus clientes nunca puedan sustituirte y tenerlos atados para la eternidad.