Agiles RD comparte esta presentación como símbolo de agradecimiento a todos los interesados en el tema de agilidad y por su grata asistencia al taller de Scrum.
2. Manifiesto Agil
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
9. Estamos descubriendo formas mejores de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
15. Principios
1. Nuestra mayor prioridad es satisfacer al cliente a través de entregas tempranas y frecuentes de software con valor.
2. Aceptar el cambio incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan los cambios para darle al
cliente ventajas competitivas.
3. Entregar software funcionando en forma frecuente, desde un par de semanas a un par de meses, prefiriendo el periodo
de tiempo más corto.
4. Expertos del negocio y desarrolladores deben trabajar juntos diariamente durante la ejecución del proyecto.
5. Construir proyectos en torno a personas motivadas, generándoles el ambiente necesario, atendiendo sus necesidades y
confiando en que ellos van a poder hacer el trabajo.
16. Principios
6. La manera más eficiente y efectiva de compartir la información dentro de un equipo de desarrollo es la conversación cara
a cara.
7. El software funcionando es la principal métrica de progreso.
8. Los procesos ágiles promueven el desarrollo sostenible. Los sponsors, desarrolladores y usuarios deben poder mantener
un ritmo constante indefinidamente.
9. La atención continua a la excelencia técnica y buenos diseños incrementan la agilidad.
10. La simplicidad –el arte de maximizar la cantidad de trabajo no hecho- es esencial.
11. Las mejores arquitecturas, requerimientos y diseños emergen de equipos auto organizados.
12. A intervalos regulares, el equipo reflexiona acerca de cómo convertirse en más efectivos, luego mejora y ajusta su
comportamiento a adecuadamente.
18. Scrum
El product Owner crea y prioriza la lista deseada llamada Product Backlog
Durante la Sprint Planning el equipo elige pequeñas piezas de trabajo para
implementarla
El equipo tiene una caja de tiempo llamada Sprint que usualmente es de dos a tres
semanas para completar el trabajo comprometido
El Scrum Master mantiene el equipo enfocado en la meta
Al final del Sprint el equipo muestra a los interesados y clientes un producto
potencialmente funcional.
El Sprint termina con la reunion de Review y la Retrospectiva
Y el equipo vuelve a seleccionar el trabajo a implementar para el próximo sprint
19. Principios de Scrum
Las cualidades de apertura, honestidad y coraje son fomentadas en todos los niveles, y el
beneficio individual se vuelve secundario ante el avance colectivo. Un ambiente Scrum es
aquel que prioriza a la gente, donde las personas de todos los niveles muestran respeto y
confianza entre ellos. Las decisiones se toman por consenso, antes que por imposición de
alguien de mayor jerarquía y todo el conocimiento es compartido de una manera
transparente y sin recelos.
20. Roles Scrum
Se saben el cuento de la gallina y el cerdito?
Scrum Master
Scrum Team
Product Owner
Gerentes
Usuarios
Interesados
21. Product Owner
Responsable del ROI
Provee la Visión
Prioriza el backlog
Asegura la calidad de las historias
Está disponible para el equipo
Inspira al equipo
Acepta o rechaza el producto construido
22. Scrum Master
Cualidades de un buen Scrum Master:
Ingeniosos: Le sirve para remover impedimentos con creatividad
Solidario: Le encanta ayudar a otros
Táctico: Es diplomático con las personas
Inspirador: Genera entusiasmo en los individuos para ayudarlos a crecer
Empatía: Genera sensibilidad hacia los demás
Inquieto: Busca nuevas formas para que el equipo haga mejor su trabajo
Influencia: Tiene influencia en la organización
Protector: Protege al equipo de todas las amenazas que puedan frenar su
productividad
23. Scrum Master
Responsabilidad:
1. Facilita todas las ceremonias
2. Ayuda al Product Owner con la priorización
3. Ayuda al equipo a mejorar continuamente
4. Se encarga de que el equipo se convierta en Ágil y sea
auto organizado
5. Remueve los impedimentos utilizando sus influencias
24. Scrum Team
Equipo de Desarrollo
El equipo de desarrollo está formado por todos los individuos necesarios
para la construcción del producto en cuestión. Es el único responsable por
la construcción y calidad del producto.
• El equipo de desarrollo es auto-organizado
• Responsable de transformar las funcionalidades comprometidas en
software funcionando y con calidad productiva, o en otras palabras,
producir un incremento funcional potencialmente entregable.
• Es recomendable que un equipo de desarrollo se componga de hasta
nueve personas
25. Scrum Team
Responsabilidades del Equipo:
1. Proveer las estimaciones de cuánto esfuerzo será requerido para cada una de las características del
producto
2. Comprometerse al comienzo de cada Sprint a construir un conjunto determinado de características en
el tiempo que dura el mismo
3. Entregar del producto terminado al finalizar cada Sprint
29. Sprint Planning Meeting
Que?
El Product Owner le indica al equipo que quiere
Como?
El equipo decide cómo hará el trabajo
Estima las solucione
Y decide cuánto trabajo tomará para completar en el Sprint
30. StandUp Meeting
Reuniones diarias
Uno de los beneficios de Scrum está dado por el incremento de la comunicación
dentro del equipo de proyecto.
Duracion Maxima: 15 Min
Todos responden tres preguntas:
1. ¿Qué hice desde la última reunión diaria hasta ahora?
2. ¿En qué voy a estar trabajando desde ahora hasta la próxima reunión diaria?
3. ¿Qué problemas o impedimentos tengo?
31. Review
Un Beneficio es recibir feedback temprano y aumentar valor al negocio, por eso se se lleva a cabo
esta ceremonia.
✓ El Product Owner evalúa en tiempo real las funcionalidades construidas y provee su feedback.
✓ Los stakeholders del proyecto también pueden participar en esta reunión para aportar sus
impresiones, que pueden ser acerca de cambios en la funcionalidad construida o bien nuevas
funcionalidades que surjan de ver el producto en acción.
32. Retrospectiva
En un método empírico como Scrum, la retrospección del equipo es el corazón de la mejora
continua. Mediante el mecanismo de retrospección, el equipo reflexiona sobre la forma en la
que realizó su trabajo y los acontecimientos que sucedieron en el Sprint que acaba de
concluir para mejorar sus prácticas.
La retrospectiva convencional se hace contestando dos preguntas:
1- Que debes mantener haciendo?
2- Que debo mejorar
De ahí se determina que se implementara para el próximo sprint para mejorar.