Scrum: Principios giles

Por recorrer

www.lemondata.com.ar

Un recorrido por la historia

Eliminar los desperdicios: Todo aquello que no produce valor agregado en el proceso. Respetar a las personas: Dejar que las personas piensen y decidan por su cuenta, ellos conocen como mejorar el proceso en el que trabajan. Postergar los compromisos: Retardar las decisiones hasta que se disponga de mayor informacin no se pueda esperar ms. Crear Conocimiento: Mantener una cultura de mejora continua. Entregas rpidas: Permitir que el cliente pueda aprovechar con anticipacin los beneficios del proyecto. Desarrollar con calidad interna: De manera que el producto pueda ir creciendo con una velocidad sostenida. Optimizar la totalidad del proceso: Mejorar el proceso de creacin del producto, desde la idea hasta su entrega.
www.lemondata.com.ar

Un recorrido por la historia Los inicios de Scrum:

1986: se public en el Hardvard Bussiness Review el artculo

The New New Product Development Game (por Hirotaka Takeuchi y Ikujiro Nonaka).

1993: Jeff Sutherland, form el primer equipo Scrum para el

desarrollo de Software.

1995: Jeff Sutherland y Ken Schwaber presentaron

formalmente el marco de trabajo Scrum, en OOPSLA 95.

2001: Ken Schwaber y Mike Beedle, presentaron el primer libro: Agile Software development with Scrum
www.lemondata.com.ar

Un recorrido por la historia Manifiesto para el Desarrollo gil de Software

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A travs de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentacin extensiva Colaboracin con el cliente sobre negociacin contractual Respuesta ante el cambio sobre seguir un plan Esto es, aunque valoramos los elementos de la derecha, valoramos ms los de la izquierda.
http://agilemanifesto.org/
www.lemondata.com.ar

Caractersticas
Propsito: No es un proceso o una tcnica para desarrollar o crear productos, sino que es un marco trabajo en el que se pueden emplear diversos procesos y tcnicas. Se basa en la teora del control emprico de procesos, empleando un enfoque iterativo e incremental para optimizar la previsibilidad y controlar los riesgos.
Atributos y valores: La Transparencia La Inspeccin Compromiso Enfoque Respeto Coraje

La Adaptacin
www.lemondata.com.ar

Caractersticas
TIME- BOX: Ayuda a crear regularidad en las actividades: Sprint Planning Scrum Daily meeting Sprint Review Sprint Retrospective. Sprint SPRINT: Son iteraciones de 2 a 4 semanas, los cuales se inician inmediatamente despus del anterior. Son de duracin fija: terminan en una fecha especfica, aunque no se haya terminado el trabajo, y nunca se alargan. La duracin debe ser constante Sprint a Sprint, para producir predictibilidad y un paso sostenido. www.lemondata.com.ar

Ciclo de trabajo de Scrum

www.lemondata.com.ar

ROLES: Product Owner

Cliente o representante del mismo (con enfoque al Cliente).

Crea la visin de producto y es responsable de mantener actualizada y priorizada la lista de requerimientos (Product Backlog).
Sprint a Sprint reprioriza y refina el Product Backlog, de acuerdo al valor de negocio. Acepta o rechaza los resultados del trabajo de un Sprint. Decide fechas del release. Puede cancelar un Sprint.
Consejos: Para que el PO tenga xito, todos en la organizacin deben respetar sus decisiones. El PO es una persona, no un comit. www.lemondata.com.ar El PO nunca debe ser el Scrum Master.

ROLES: Scrum Master

Responsable de asegurar el cumplimiento de las reglas y prcticas de Scrum. Facilitador, no Project Manager, es decir, no asignan tareas. Elimina los impedimentos del Equipo.

Se asegura que el Equipo funcione correctamente, reafirmando los principios de Scrum (auto-organizados y funcionales).
Protege al Equipo, de nuevos requerimientos durante el Sprint.
Consejos: Puede ser un miembro del Equipo. Sin embargo, esto conduce frecuentemente a conflictos cuando el SM tiene que elegir entre eliminar obstculos o realizar las tareas. El SM nunca debe ser el PO. NO CONFUNDIR: Scrum Master = Project Manager www.lemondata.com.ar

ROLES: Team
Tpicamente 72 integrantes. Responsables del desarrollo del producto.

Auto-organizados, sin lideres.

Deciden que pueden hacer en un Sprint, como lo harn y proveen la estimacin de cada User Story.

Son multidisciplinarios.
Los miembros deberan ser fulltime para evitar demoras por multitasking. Van tomando las tareas que deseen y las van cumpliendo.
Consejos: Ubicarse en el mismo espacio de trabajo, para una mayor sinergia. Buscar actividades/tcnicas para fomentar el espritu de colaboracin y/o la www.lemondata.com.ar autonoma del equipo.

ARTEFACTOS: Product Backlog

Es una lista requerimientos priorizada por el valor de negocio.
Compuesta por los items que se pretenden para elaborar el producto: - User Story (2 4 semanas) - Feature (3 6 meses) - EPIC (1 2 aos) Esta siempre visible a todos los interesados. El PO, es el responsable de mantener su contenido y priorizacin. El Product Backlog es dinmico, y evoluciona a medida que lo hace el producto y su entorno.
www.lemondata.com.ar

ARTEFACTOS: Product Backlog

PBI Product Backlog Item:
Especifica el qu, no el cmo, de una funcionalidad centrada en el usuario.

Poseen criterio de aceptacin (definicin de hecho).

Escrita en trminos del negocio. Se suelen dividir en varias tareas. El esfuerzo es estimado por el Equipo. El valor de negocio es estimado por PO.

www.lemondata.com.ar

ARTEFACTOS: Sprint Committed Backlog

Contiene los PBI que negociaron el Equipo y el PO, durante el Sprint Planning. Los PBI del Product Backlog, se desglosan en tareas para el Sprint Backlog (de duraciones no menores a 4 horas ni mayores a 16 horas.) Los PBI que se convertirn en un incremento de Producto. Los PBI a realizar, deben ser los posibles a desarrollar en un Sprint. Siempre visible para el Equipo. Es actualizado Inmediatamente despus del Daily Scrum.
www.lemondata.com.ar

ARTEFACTOS: Burndown Chart

Grfico que muestra por da, cuanto trabajo resta para finalizar las tareas del Sprint. Muestra el progreso hacia el objetivo, en trminos del esfuerzo pendiente y story points, ms que el esfuerzo realizado. Se actualiza da a da, luego de que cada miembro del Equipo estima cuanto tiempo resta para finalizar cada tarea en el Sprint Backlog. Facilita la auto-organizacin del Equipo. No es un reporte para la administracin o gerencia del proyecto.

www.lemondata.com.ar

CEREMONIAS: Sprint Planning

CARACTERISTICAS
Frecuencia Duracin

DESCRIPCION
Al comienzo de cada Sprint. 4 hs, para un Sprint de 2 Semanas. 8 hs, para un Sprint de un mes.
Se obtiene el Sprint Backlog Sprint COMMITTED Backlog.

PARTICIPANTES

Objetivo

- PO - EQUIPO - SM

Composicin

www.lemondata.com.ar

Primera parte: Se discute el Qu se har durante el Sprint (hasta completar la velocidad del Equipo). Se definen el Objetivo del Sprint, y definiciones de hecho. Segunda parte: El Equipo determina el Cmo se va a convertir una funcionalidad en Producto potencialmente entregable.

Primera parte : - PO - EQUIPO - SM Segunda parte : -EQUIPO

CEREMONIAS: Daily Standup

CARACTERISTICAS
Frecuencia Duracin Objetivo

DESCRIPCION
Una vez al da (a la misma hora y en el mismo lugar). 15 minutos. Comunicacin y Sincronizacin: Observar el estado de avance de las tareas tomadas del Sprint Backlog, y los obstculos existentes.
Se contesta tres preguntas: 1. Qu hice desde la ltima reunin? 2. Qu har hasta la prxima reunin? 3. Encontr obstculos/impedimentos? No se puede llegar tarde. Los Interesados no pueden interrumpir. Se actualiza tareas del Sprint Backlog y grficos de Burndown.

PARTICIPANTES

Composicin

- EQUIPO - SM - Interesados

www.lemondata.com.ar

CEREMONIAS: Sprint Review

CARACTERISTICAS
Frecuencia Duracin Objetivo

DESCRIPCION
Una vez, al final el Sprint. 1 a 4 hs. Mostrar el incremento de producto que el Equipo se comprometi a trabajar durante el ltimo Sprint.
El Equipo muestra el trabajo realizado.
El PO verifica la realizacin del Sprint Backlog segn la definicin de hecho, y puede aceptar o rechazar. Todo feedback se debe plasmar en el Product Backlog. Al final, se acuerda la fecha para la prxima reunin.

PARTICIPANTES

Composicin

- EQUIPO - SM - PO - Interesados

www.lemondata.com.ar

CEREMONIAS: Sprint Retrospective

CARACTERISTICAS
Frecuencia Duracin Objetivo Composicin

DESCRIPCION
Una vez, al final del Sprint Review. 3 a 4 hs. Se analiza como se trabaj durante el Sprint anterior y se revisa el Proceso.
Lo facilita el SM. Se centran en: Qu se hizo bien? Qu funcion mal? En qu se puede mejorar? Finalmente se identifican y priorizan las soluciones, para aplicar en el prximo Sprint.

PARTICIPANTES

- EQUIPO - SM

www.lemondata.com.ar

Cmo llevarlo acabo?

www.lemondata.com.ar

Cmo llevarlo acabo?

Pequeas Entregas: El equipo entrega software funcionando ( un incremento del mismo que agrega valor al negocio), al PO, al final de cada Sprint. Pruebas de Usuarios: Pruebas de Aceptacin: cada User Story necesita una o ms Pruebas de Aceptacin (Las cuales el Equipo debera automatizarlas). Estndares de Codificacin: Buscar que todo cdigo en el sistema, pareciera que fue escrito por un nico individuo. Los estndares de codificacin ayudan a la propiedad colectiva.
www.lemondata.com.ar

Cmo llevarlo acabo?

Propiedad Colectiva: No existe dueos de determinadas partes de cdigo. Cualquiera puede modificar cualquier parte, en cualquier momento. Difundir el conocimiento entre el Equipo. Esto se Respalda: por Pruebas Unitarias y /o Programacin de a Pares Integracin Continua: El sistema est integrado todo el tiempo. El sistema se compila varias veces por da. Repositorio nico de cdigo fuente. Automatizar el Build. Compilacin Auto Verificable (pruebas automatizadas) Commits diarios (es una manera de comunicar al resto y anticiparse de futuros conflictos)
www.lemondata.com.ar

Cmo llevarlo acabo?

Diseo Simple: Debe ser lo ms sencillo posible. Suficientes para cubrir los requerimientos actuales. No hacer cosas por las dudas. El diseo gil es evolutivo, no una actividad para realizar anticipadamente Programacin de a Pares: Todo cdigo productivo es revisado por alguien ms, en tiempo real. Se produce un cdigo de mayor calidad, cuando estamos codo a codo, que si programamos de forma aislada. - No es fcil programar de a Pares, lleva unas semanas ver los resultados.

www.lemondata.com.ar

Cmo llevarlo acabo?

Diseo dirigido por Pruebas: Desarrollo en ciclos cortos (aplicamos TDD): Primero se codifica una Prueba de lo que se desea construir. Luego se debe verificar su fallo (si No falla, no es bueno) Luego se codifica y verifica la ejecucin exitosa de la Prueba. Refactorizar hasta que se termine el fragmento que quiero construir (manteniendo las pruebas exitosas). Las Pruebas estn vinculadas a la IC. Refactorizacin: Es la Mejora continua del Diseo. Los procesos de Refactorizacin se enfocan en: Remover duplicaciones. Incrementar la cohesin. Disminuir el acoplamiento.
www.lemondata.com.ar

Cerrando

La agilidad requiere una forma diferente de pensar y de ver las cosas, se trata sobre todo de valores y principios. No miremos a Scrum como un conjunto ms de prcticas y reglas a seguir, sino como una gua de valores y principios, que podr hacer que en EQUIPO, con ganas de aprender, mejorar, colaborar y estando comprometidos, desarrollemos Software con un gran Valor agregado y de Calidad. www.lemondata.com.ar

Preguntas?

www.lemondata.com.ar

MUCHAS GRACIAS!!!
REFERENCIAS: http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf http://www.agilemanifesto.org/ http://softwareagil.blogspot.com.ar/ http://es.wikipedia.org/wiki/Lean_software_development
www.lemondata.com.ar