Scrum y principios ágiles

Salvador A. Celí[email protected]

http://facebook.com/salvador.celia

http://twitter.com/salvadorcelia

Scrum: Principios Ágiles

mailto:[email protected]

https://www.facebook.com/salvador.celia

http://twitter.com/salvadorcelia

www.lemondata.com.ar

Por recorrer…


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 información ó no se

pueda esperar más. Crear Conocimiento:• Mantener una cultura de mejora continua.

Entregas rápidas:• Permitir que el cliente pueda aprovechar con anticipación 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 creación del producto, desde la idea hasta su entrega.

Un recorrido por la historia…



Los inicios de Scrum:

1986: se publicó en el Hardvard Bussiness Review el artículo “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”



Manifiesto para el Desarrollo Ágil de SoftwareEstamos descubriendo formas mejores de desarrollarsoftware tanto por nuestra propia experiencia comoayudando a terceros. A través de este trabajo hemos

aprendido a valorar:

Individuos e interacciones sobre procesos y herramientasSoftware funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractualRespuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,valoramos más los de la izquierda.

http://agilemanifesto.org/


Características

Propósito:• No es un proceso o una técnica para

desarrollar o crear productos, sino que es un marco trabajo en el que se pueden emplear diversos procesos y técnicas.

• Se basa en la teoría del control empírico de procesos, empleando un enfoque iterativo e incremental para optimizar la previsibilidad y controlar los riesgos.

Atributos y valores:

La Transparencia

La Inspección

La Adaptación

Compromiso Enfoque Respeto Coraje


Características

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

después del anterior.

• Son de duración fija: terminan en una fecha específica, aunque no se haya terminado el trabajo, y nunca se alargan.

• La duración debe ser constante Sprint a Sprint, para producir predictibilidad y un paso sostenido.


Ciclo de trabajo de Scrum


ROLES: Product Owner

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

• Crea la visión 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 organización deben respetar sus decisiones.• El PO es una persona, no un comité.• El PO nunca debe ser el Scrum Master.


ROLES: Scrum Master

• Responsable de asegurar el cumplimiento de las reglas y prácticas 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 obstáculos o realizar las tareas. • El SM nunca debe ser el PO. • NO CONFUNDIR: Scrum Master = Project Manager


ROLES: Team

• Típicamente 7±2 integrantes.

• Responsables del desarrollo del producto.

• Auto-organizados, sin lideres.

• Deciden que pueden hacer en un Sprint, como lo harán y proveen la estimación de cada User Story.

• Son multidisciplinarios.

• Los miembros deberían 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/técnicas para fomentar el espíritu de colaboración y/o la autonomía

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 años)

• Esta siempre visible a todos los interesados.

• El PO, es el responsable de mantener su contenido y priorización.

• El Product Backlog es dinámico, y evoluciona a medida que lo hace el producto y su entorno.


ARTEFACTOS: Product Backlog

PBI – Product Backlog Item:

•Especifica el qué, no el cómo, de una funcionalidad centrada en el usuario.

• Poseen criterio de aceptación (definición de hecho).

• Escrita en términos del negocio.

• Se suelen dividir en varias tareas.

• El esfuerzo es estimado por el Equipo.

• El valor de negocio es estimado por PO.


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 convertirán 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 después del Daily Scrum.


ARTEFACTOS: Burndown Chart

• Gráfico que muestra por día, cuanto trabajo resta para finalizar las tareas del Sprint.

• Muestra el progreso hacia el objetivo, en términos del esfuerzo pendiente y story points, más que el esfuerzo realizado.

• Se actualiza día a día, luego de que cada miembro del Equipo estima cuanto tiempo resta para finalizar cada tarea en el Sprint Backlog.

• Facilita la auto-organización del Equipo.

• No es un reporte para la administración o gerencia del proyecto.


CEREMONIAS: Sprint Planning

CARACTERISTICAS DESCRIPCION PARTICIPANTESFrecuencia Al comienzo de cada Sprint.

- PO- EQUIPO- SM

Duración 4 hs, para un Sprint de 2 Semanas.8 hs, para un Sprint de un mes.

Objetivo Se obtiene el Sprint Backlog ó Sprint COMMITTED Backlog.

Composición 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 Cómo se va a convertir una funcionalidad en Producto potencialmente entregable.

Primera parte :- PO- EQUIPO- SM

Segunda parte :- EQUIPO


CEREMONIAS: Daily Standup

CARACTERISTICAS DESCRIPCION PARTICIPANTES

Frecuencia Una vez al día (a la misma hora y en el mismo lugar).

- EQUIPO- SM- Interesados

Duración 15 minutos.

Objetivo Comunicación y Sincronización: Observar el estado de avance de las tareas tomadas

del Sprint Backlog, y los obstáculos existentes.Composición Se contesta tres preguntas:

1. ¿Qué hice desde la última reunión?2. ¿Qué haré hasta la próxima reunión? 3. ¿Encontré obstáculos/impedimentos?

No se puede llegar tarde. Los Interesados no pueden interrumpir. Se actualiza tareas del Sprint Backlog y gráficos de Burndown.


CEREMONIAS: Sprint Review


Frecuencia Una vez, al final el Sprint.

- EQUIPO- SM

- PO- Interesados

Duración 1 a 4 hs.

Objetivo Mostrar el incremento de producto que el Equipo se comprometió a trabajar durante el último Sprint.

Composición El Equipo muestra el trabajo realizado.

El PO verifica la realización del Sprint Backlog según la “definición de hecho”, y puede aceptar o rechazar.

Todo feedback se debe plasmar en el Product Backlog.

Al final, se acuerda la fecha para la próxima reunión.


CEREMONIAS: Sprint Retrospective


Frecuencia Una vez, al final del Sprint Review.

- EQUIPO- SM

Duración 3 a 4 hs.

Objetivo Se analiza como se trabajó durante el Sprint anterior y se revisa el Proceso.

Composición 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 próximo Sprint.


¿Cómo llevarlo acabo?



Pequeñas 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 Aceptación: cada User Story necesita una o más Pruebas

de Aceptación (Las cuales el Equipo debería automatizarlas).

Estándares de Codificación:• Buscar que todo código en el sistema, pareciera que fue escrito por

un único individuo.• Los estándares de codificación ayudan a la propiedad colectiva.



Propiedad Colectiva:• No existe dueños de determinadas partes de código.• Cualquiera puede modificar cualquier parte, en cualquier momento.• Difundir el conocimiento entre el Equipo.

“Esto se Respalda: por Pruebas Unitarias y /o Programación de a Pares”

Integración Continua:• El sistema está integrado todo el tiempo.

El sistema se compila varias veces por día.Repositorio único de código fuente.Automatizar el Build.Compilación Auto – Verificable (pruebas automatizadas)Commits diarios (es una manera de comunicar al resto y

anticiparse de futuros conflictos)



Diseño Simple:• Debe ser lo más sencillo posible.• Suficientes para cubrir los requerimientos actuales.• No hacer cosas “por las dudas”.

“El diseño Ágil es evolutivo, no una actividad para realizar anticipadamente”

Programación de a Pares:• Todo código productivo es revisado por alguien más, en tiempo real.

Se produce un código de mayor calidad, cuando estamos codo a codo, que si programamos de forma aislada.- No es fácil programar de a Pares, lleva unas semanas ver los resultados.



Diseño 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 ejecución exitosa de la Prueba.Refactorizar hasta que se termine el fragmento que quiero

construir (manteniendo las pruebas exitosas).“Las Pruebas están vinculadas a la IC.”

Refactorización:• Es la Mejora continua del Diseño. • Los procesos de Refactorización se enfocan en:

Remover duplicaciones.Incrementar la cohesión.Disminuir el acoplamiento.


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 más de prácticas y reglas a seguir, sino como una guía 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.


¿Preguntas?


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

http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

http://www.agilemanifesto.org/

http://www.agilemanifesto.org/

http://softwareagil.blogspot.com.ar/



http://es.wikipedia.org/wiki/Lean_software_development

http://es.wikipedia.org/wiki/Lean_software_development

Education

Scrum y principios ágiles