Charla Intoductoria de SCRUM

SCRUM SCRUM –– Gestión ágil de proyectos de softwareGestión ágil de proyectos de softwareJAI 2 0JAI 2 0JAI v.2.0JAI v.2.0

Rosario 5 Dic 2006Rosario 5 Dic 2006Fabián LonghitanoFabián LonghitanoFabián LonghitanoFabián Longhitano

Objetivo

Presentar un proceso de gestión de proyectos (SCRUM) aplicable a desarrollo de productos con requerimientos que tienen alto nivel de q qincertidumbre.

Fabián Longhitano – JAI v. 2.0

Algunos problemas en la gestión de proyectos de software

Requerimientos fuera de control

No cumplimiento de los tiemposNo cumplimiento de los tiempos planificados (Desvíos)

Estimaciones deficientes

Re-trabajo excesivo

Baja calidadj

Costos excedidos

Insatisfacción del ClienteInsatisfacción del Cliente

Insatisfacción de los profesionales participantes

Etc. etc. etc.


Estrategias actuales para desarrollar softwareSin procesosSin procesosWaterfallSin documentación

Procesos compliance CMMIRUP, prototipaciónCon documentaciónSin documentación

Planificación informalEquipos no di i li d

Con documentaciónPlanificación formalEquipos disciplinados

disciplinadosEquipos no entrenados

Equipos entrenadosEtc., etc…

Etc., etc…

Ninguna metodología garantiza el éxito absoluto!!Ninguna metodología garantiza el éxito absoluto!!La clave está en saber discernir cual es la que mejorLa clave está en saber discernir cual es la que mejor


La clave está en saber discernir cual es la que mejor La clave está en saber discernir cual es la que mejor se ajusta a nuestras necesidadesse ajusta a nuestras necesidades

Nivel de ruido en los proyectos

Lejos del

Anarquia

Lejos del acuerdo

ntos

Scru

m

Complejo

eque

rimie

nS

SimpleCerca del acuerdo

Re

Cerca de la certidumbre

Lejos de la certidumbre

Tecnología

Source: Strategic Management and Organizational Dynamics by Ralph Staceyin Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.Proceso definido o empirico?


El d d d !!!!El mercado demanda !!!!

Alta calidad + diferenciación + bajo costo

se requiere

Velocidad + FlexibilidadVelocidad + FlexibilidadVelocidad + FlexibilidadVelocidad + Flexibilidad

Qué estrategia utilizamos para gestionar el Qué estrategia utilizamos para gestionar el


desarrollo?desarrollo?

Qué tienen en común cuando desarrollan sus productos?

Inestabilidad incorporada

Equipos auto - organizados

Multi aprendizajeMulti - aprendizaje

Control Sútil

Transferencia de aprendizaje a nivel organizacional

Fases de desarrollo solapadas

“Estas características son como piezas de un rompecabezas. Cada l t i i t fl ibilid d l id d C delemento por si mismo no aporta flexibilidad y velocidad. Cuando se

complementan pueden producir una poderosa dinámica que hace la diferencia.”

Hirotaka Takeuchi y Ikujiro Nonaka – The new new product


y j pdevelopment game – Harvard Business Review 1986

Estilos de administración de proyectos


The new new product development Takeuchi y Nonaka (1986)

Gestión ágil de proyectos - SCRUMProceso ágil de gestión de proyectos desarrollado por Ken Schwaber y MikeProceso ágil de gestión de proyectos desarrollado por Ken Schwaber y Mike Beedle.

Enfocado al desarrollo de productos de manera empírica.

Proceso simplesimple que requiere mucha disciplinadisciplina para que resulte exitoso.pp q q pp p qAdministración de requerimientosAdministración de riesgosPlanificación y seguimiento

Muy riguroso!!!Planificación y seguimiento

Se basa en los principios ágiles:Se basa en los principios ágiles:ColaboraciónColaboración estrecha con el clienteclientePredisposiciónPredisposición y respuesta al cambiocambioDesarrollo incremental con entregas funcionales frecuentesMotivación y responsabilidad de los equipos por la autoauto--gestióngestión,, autoauto--organizaciónorganización y compromisocompromiso


Scrum – El proceso

Daily ScrumM tiMeeting

Product Backlog

Sprint15-30díasProduct Backlog

User Story - A

días

User Story - B Tareas identificadasTareas identificadasyy estimadasestimadas

Incremento de productoIncremento de productopotencialmentepotencialmente

entregableentregable

User Story - D Source: Adapted from Agile Software Development with Scrum by Ken

User Story - C entregableentregable


User Story - ESchwaber and Mike Beedle.

Sprint – Iteraciones

Estrategia tradicional - WaterfallVentajas SprintVentajas Sprint

Los riesgos se reducen a la duración de un Sprintduración de un Sprint.

Los cambios en los requerimientos no afectan la

t ió

Estrategia ágil – Iteraciones fijas (Sprint)

construcción.

El equipo se concentra en el valor del producto no en lasvalor del producto, no en las tareas.

Entrega rápida y períodica de funcionalidad.

Feedback rápido del cliente.


Iteraciones fijas (usualmente 30 días)

Roles Scrum

66--8 personas full8 personas full--timetimeAutoAuto--organizadoorganizado

TeamTeamMembersMembers

MultiMulti--funcionalfuncionalTransforman los requerimientos en funcionalidadTransforman los requerimientos en funcionalidad

en cada incrementoen cada incremento

ProductProduct

Define funcionalidad requeridaDefine funcionalidad requeridaToma las decisiones de priorizaciónToma las decisiones de priorizaciónRepresenta a todos los interesados en el producto finalRepresenta a todos los interesados en el producto finalProductProduct

OwnersOwnersRepresenta a todos los interesados en el producto finalRepresenta a todos los interesados en el producto final

R i di tR i di t

SS

Remueve impedimentosRemueve impedimentosFacilitadorFacilitadorAsegura que se cumpla ScrumAsegura que se cumpla Scrum


Scrum Scrum MasterMaster

Asegura que se cumpla ScrumAsegura que se cumpla Scrum

Pig & Chicken?

COMPROMETIDOS EN EL PROYECTOCOMPROMETIDOS EN EL PROYECTO

Product OwnerE i

IMPLICADOS EN EL PROYECTOIMPLICADOS EN EL PROYECTO

MarketingC i l


EquipoScrum Master

ComercialEtc.

Herramientas - Product Backlog

Lista priorizada de requerimientos.

P i i d d i i dPriorizado y administrado por el Product Owner

Priorización basada en laPriorización basada en la funcionalidad que agrega mayor valor al negocio.

E ol ciona según lasEvoluciona según las condiciones de negocio y/o tecnología.

Cualquiera puede aportar nuevos requerimientos.

Es visible a todosEs visible a todos.


Reglas esenciales!! : El único que cambia las prioridadades es el PO

Sprints

Período fijoPeríodo fijo de tiempo durante el cual el equipo desarrolla un incremento de funcionalidad (no más de 30 días).

No se aceptan cambiosNo se aceptan cambios a los requerimientos acordados

El producto es diseñado, codificado y testeado durante el Sprint

Solo el Scrum Master puede cancelar el Sprint cuando;La tecnología no funcionagLas circunstancias del negocio cambiaronEl equipo tuvo interferencias

Iteraciones cortas permiten reducir riesgos !!!Iteraciones cortas permiten reducir riesgos !!!


Iteraciones cortas permiten reducir riesgos !!!Iteraciones cortas permiten reducir riesgos !!!

Sprint Planning Meeting

Daily ScrumM tiMeeting

Product Backlog

Sprint15-30díasProduct Backlog

User Story - A

días

User Story - B Tareas identificadasTareas identificadasyy estimadasestimadas

User Story - D Source: Adapted from Agile Software Development with Scrum by Ken Sprint BacklogSprint Backlog

User Story - C


User Story - ESchwaber and Mike Beedle.Priorizado yPriorizado y estimadoestimado

Sprint Planning MeetingDos reuniones:Dos reuniones:

Primera reunión:− Se establece la meta del Sprint− Se identifica la funcionalidad que se va a

construir en el Sprint

Segunda reunión:Segunda reunión:− Se identifican y estiman las tareas para

satisfacer − Se crea un Sprint Backlog

Las tareas son distribuidas por decisión de− Las tareas son distribuidas por decisión de los miembros del equipo

− Los miembros del equipo se comprometen a cumplir con la meta del Sprint

Entradas:− Product Backlog actualizado.− Feedback último Sprint.− Perfomance del equipo en los Sprint anteriores


Daily Scrum Meeting

Todoslos días

Tres preguntas: todos responden – de a uno por favor ;)

15 minutosQué trabajo realizó ayer?Qué trabajo realizará hoy?Hay algo que necesita o que impide

que realice el trabajo previsto?

Eliminar impedimentos!!Eliminar impedimentos!!

Sprint15- 30días

que realice el trabajo previsto?

Sprint Backlogdías

User Story - C

User Story - A

User Story - D

User Story - B Source: Adapted from Agile Software Development with Scrum by Ken

y


Schwaber and Mike Beedle.

Daily Scrum MeetingDuración aproximada de 15 minutos.Duración aproximada de 15 minutos. Todos los días a la misma hora y en el mismo lugarParticipa el equipo y el Scrum Master (Product Owner opcional)No hay conversaciones entre los miembros del equipoLasLas gallinasgallinas pueden asistir pero nono hablan!!hablan!!LasLas gallinasgallinas pueden asistir pero nono hablan!!hablan!!No se divagaNo se divagaEl principal objetivo es eliminar impedimentoseliminar impedimentos

BeneficiosBeneficios:

Mejor entendimiento de las interdependencias entre los miembros de equipo. (sincronización)Mejora en la comunicación.Todos conocen el estado del proyecto.Elimina la necesidad de otras reuniones.Identifica y remueve impedimentos.Promueve decisiones rápidas.


Sprint Backlog Burndown

Velocidad

100

120

Velocidad real del equipo

80

100

s

40

60

Hor

as Esfuerzo disponibleHoras Restantes

20

40

00 1 2 3 4 5 6 7 8 9 10

Días

Velocidad ideal Díasestimada


Sprint Review Meeting

Todoslos díaslos días

15 minutos

Sprint Backlog

Sprint15-30díasSprint Backlog días

User Story - C

Incremento de productopotencialmente

entregableUser Story - A

User Story - D

User Story - B

entregabley


Sprint Review Meeting (Qué construímos)Objetivo:Objetivo: Presentar al Product Owner y demás involucrados del proyecto el trabajoObjetivo:Objetivo: Presentar al Product Owner y demás involucrados del proyecto el trabajo realizado (incremento del producto) durante el Sprint

Participan:Participan: Equipo Scrum Master Product Owner todas las personas involucradas enParticipan:Participan: Equipo, Scrum Master, Product Owner, todas las personas involucradas en el proyecto

Reglas a seguir:Reglas a seguir:Reglas a seguir:Reglas a seguir:El Team no invierte más de una hora para preparar el Sprint review Las funcionalidades no finalizadas completamente no se presentanLos miembros del equipo presentan las funcionalidadesLos miembros del equipo presentan las funcionalidadesLas demostraciones se realizan en las workstations de los miembros del equipoAl finalizar la reunión se pide opiniones a los participantes, los cuales pueden sugerir cambios y mejorascambios y mejoras

Al finalizar:Al finalizar:Se actualiza y vuelve a priorizar el Product BacklogSe actualiza y vuelve a priorizar el Product BacklogEl Scrum Master anuncia el lugar y la fecha de la próxima revisión de Sprint

El Product Owner decide si la funcionalidad


presentada cumple con los objetivos del Sprint

Sprint Retrospective (Cómo contruímos)Objetivo: identificar que cosas se puedenObjetivo: identificar que cosas se pueden cambiar para hacer el trabajo más agradable y productivo en las próximas iteraciones.

Se realiza al finalizar el Sprint

Participantes: Team Scrum Master ProductParticipantes: Team, Scrum Master, Product Owner (opcional).

Dos preguntas (todos responden):Dos preguntas (todos responden):Qué cosas hicimos bien?Qué cosas podemos mejorar?

Todo aquello que afecte como el equipo construye software se debe debatir

Permite al equipo evolucionar continuamente mejorando durante el proyecto.


Herramientas – Panel de Control

Historias de usuarios(Sprint Backlog)

Tareas a realizar Tareas finalizadas

Burndown Chart

Tareas en progreso


Tareas finalizadas

ResumiendoScrum es un proceso iterativo e incremental que puede ser utilizado paraScrum es un proceso iterativo e incremental que puede ser utilizado para desarrollar cualquier producto o administrar cualquier trabajo. Sus principales atributos son:

Un enfoque orientado a que los equipos desarrollen sistemas y productos de manera iterativa e incremental cuando los requerimientos cambian de manera rápidaU t l l d fli t d i t id dUn proceso que controla el caos de conflictos de intereses y necesidadesUna manera de mejorar las comunicaciones y maximizar la cooperaciónUna manera de maximizar la productividad Escalable a múltiples proyectos y toda la organizaciónUna forma que todos se sientan bien con su trabajo, entendiendo que cada uno con sus contribuciones hizo lo mejor que podía hacer j q p

Extremadamente simple pero que requiere Extremadamente simple pero que requiere


mucha disciplina para que funcione !!mucha disciplina para que funcione !!

Referencias

www.controlchaos.comwww agilealliance orgwww.agilealliance.orgwww.jeffsutherland.com


Muchas gracias!!Muchas gracias!!Fabián Longhitano

[email protected]://mejorsoftware blogspot com/


http://mejorsoftware.blogspot.com/

Technology

Charla Intoductoria de SCRUM