Esta presentación incluye una introducción de Scrum en Proyectos que hemos realizado en tecnología Microsoft. Usando herramientas que nos permite llevar todo el ciclo de vida del proyecto con la metodología ágil como SCRUM. Herramientas como Visual Studio Team Services (VSTS) permiten facilitar el trabajo del equipo desde la planeación del sprint hasta la entrega del producto.
Agenda:
1. Manifiesto Ágil
2. Scrum
3. Valores Scrum
4. Roles Scrum
5. Actividades Scrum
6. Logros Scrum en iTS y proximos pasos
2. AGENDA
01 02
03 04
Manifiesto Agil
Valores Scrum
Scrum
Roles Scrum
06
Logros Scrum en iTS y
Próximos Pasos05Actividades Scrum
3. 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:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
Fuente: http://agilemanifesto.org/iso/es/manifesto.html
Objetivo | Capacitación de <bajo/alto> nivel
Manifiesto por el Desarrollo Ágil de Software
4. Principios del Manifiesto Ágil
03
0201
06
04
05
Aceptamos que los requisitos cambien
incluso en etapas tardías del desarrollo. Los procesos Ágiles
aprovechan el cambio para proporcionar ventaja
competitiva al cliente.
Entregamos software
funcional frecuentemente
entre dos semanas y dos meses, con preferencia al
periodo de tiempo más corto posible.
Los proyectos se desarrollan en torno a individuos
motivados
Hay que darles el entorno y el apoyo que
necesitan, y confiarles la ejecución del trabajo
Los responsables de negocio y los desarrolladores
trabajamos juntos
de forma cotidiana durante todo
el proyecto.
Nuestra mayor
prioridad es
satisfacer al cliente
mediante la entrega temprana
y continua de software
con valor.
El método más eficiente y
efectivo de comunicar
información
es la conversación cara a cara.
5. Principios del Manifiesto Ágil
09
0807
12
10
11
Los procesos Ágiles promueven el desarrollo sostenible
Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.
La atención continua a la excelencia técnica
y al buen diseño
mejora la Agilidad
Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados
La simplicidad, o el arte de maximizar la cantidad de
trabajo no realizado
Es esencial
El software
funcionando
es la medida principal de
progreso.
A intervalos regulares el equipo
reflexiona
Sobre cómo ser más efectivo para a continuación
ajustar y perfeccionar su comportamiento en
consecuencia
6. Scrum es el más conocido de los frameworks Ágiles. Es la fuente de
gran parte del pensamiento que se encuentra detrás de los principios
y valores del Manifiesto Ágil.
Scrum es un framework pensado para construir productos: todo
comienza cuando tenemos stakeholders que necesitan uno.
Revisión de Roles, Artefactos y Actividades
Que es Scrum
7. Valores Scrum
01
05
04 03
02 Coraje
Porque no estamos solos, nos
sentimos apoyados y tenemos
más recursos a nuestra
disposición. Esto nos da el coraje
para enfrentar desafíos más
grandes.
Apertura
Durante el trabajo en conjunto
expresamos cotidianamente cómo nos
va y qué problemas encontramos.
Aprendemos que es bueno manifestar
las preocupaciones, para que éstas
puedan ser tomadas en cuenta
Respeto
A medida que trabajamos juntos,
compartiendo éxitos y fracasos,
llegamos a respetarnos los unos a
los otros, y a ayudarnos
mutuamente a convertirnos en
merecedores de respeto.
Compromiso
Porque tenemos gran control sobre
nuestro destino, nos comprometemos
más al éxito
Foco
Porque nos enfocamos en sólo unas
pocas cosas a la vez, trabajamos bien
juntos y producimos un resultado
excelente. De este modo logramos
entregar ítems valiosos antes
8. Roles Scrum
Product
Ownertiene la responsabilidad de
decidir qué trabajo deberá ser
realizado de acuerdo a las
necesidades y prioridades del
negocio.
Scrum
Master
actúa como líder servicial,
ayudando al equipo y a la
organización a hacer el mejor
uso de Scrum.
Equipo de
Desarrollo
construye el producto en forma
incremental, en una serie de
períodos cortos de tiempo
llamados Sprints.
9. Roles Scrum – Product Owner
Product Owner
• Es la única persona responsable de delinear el
producto más valioso posible para la fecha deseada.
• El PO mantiene el Product Backlog y asegura que
todos sepan qué hay en él y cuáles son las
prioridades.
• El PO no es responsable de todo. El Equipo Scrum
completo es responsable de ser lo más productivo
posible, de mejorar sus prácticas, de hacer las
preguntas correctas, de ayudar al Product Owner.
• El Equipo de Desarrollo es responsable de
determinar cuánto trabajo puede ser tomado en un
Sprint, y de producir un Incremento de Producto al
finalizar el mismo
• El PO lleva adelante esta tarea mediante la gestión
del Product Backlog y asegurándose que el Product
Backlog y el avance contra éste se mantengan
visibles.
• El PO, al decidir sobre qué debe hacer y qué debe
posponer el Equipo de Desarrollo, toma las
decisiones de alcance versus fechas que llevan al
mejor producto posible.
10. Roles Scrum – Scrum Master
Scrum Master
• El ScrumMaster es un "líder servicial", que ayuda al
resto del equipo Scrum a seguir su proceso. Debe
tener una buena comprensión de Scrum y la
habilidad de capacitar a otros en sus sutilezas.
• El ScrumMaster trabaja junto al Product Owner para
que éste logre crear y mantener el Product Backlog.
• El ScrumMaster también es responsable de velar por
la remoción de los impedimentos al avance del
equipo. Estos impedimentos pueden ser externos al
equipo, como por ejemplo la falta de apoyo de otro
equipo, o internos, como ser que el Product Owner
no sepa preparar el Product Backlog de forma
adecuada.
• El ScrumMaster fomenta la auto-organización. Los
problemas deben ser resueltos por el equipo
siempre que sea posible.
• El ScrumMaster actúa como coach para el Equipo
Scrum, ayudando a sus miembros a ejecutar el
proceso Scrum.
• El ScrumMaster es responsable de asegurar que
Scrum sea comprendido e implementado, tanto
dentro como fuera del equipo. Ayuda a personas
fuera del equipo a entender el proceso y a
comprender qué interacciones con el equipo son
valiosas y cuáles no. El ScrumMaster ayuda a todos
a mejorar para que el equipo Scrum sea más
productivo y valioso.
11. Roles Scrum – Equipo de Desarrollo
Equipo de
Desarrollo
• Está compuesto por los profesionales que hacen el
trabajo necesario para poder entregar el Incremento
de Producto.
• Se auto-organizan para realizar su trabajo.
• Scrum requiere que el Equipo de Desarrollo esté
conformado por un grupo interdisciplinario de
personas que, entre todos, reúnan las habilidades
necesarias para entregar cada incremento del
producto.
• Los miembros del Equipo de Desarrollo tienen la
responsabilidad de auto-organizarse para lograr el
objetivo del Sprint, produciendo cada nuevo
Incremento de Producto siguiendo el Plan del
Sprint.
• El Product Owner crea una lista ordenada de lo que
hay que hacer. Los miembros del Equipo de
Desarrollo hacen un pronóstico de cuánto pueden
realizar en un Sprint y deciden cómo lo van a llevar
a cabo.
12. Artefactos Scrum
Incremento del
Producto
El artefacto más importante en Scrum es el
Incremento de Producto. Cada Sprint produce un
Incremento de Producto. Éste debe ser de calidad lo
suficientemente alta como para ser entregado a
usuarios finales.
El Incremento de Producto debe cumplir con la
Definición de Hecho (Done) actual del Equipo Scrum
y cada parte del mismo debe ser aceptable para el
Product Owner
Sprint Backlog
El Sprint Backlog es la lista de ítems del Product
Backlog refinados que han sido elegidos para ser
desarrollados en el Sprint actual, junto al plan del
equipo para poder realizar el trabajo. Refleja el
pronóstico de qué trabajo puede ser completado.
Generado el Sprint Backlog, comienza el Sprint y el
Equipo de Desarrollo desarrolla el nuevo
Incremento de Producto definido por el Sprint
Backlog.
Product Backlog
Es una lista ordenada de ideas para el producto, mantenida
en el orden en que esperamos llevarlas a cabo.
Toda idea de funcionalidad, mejora, bug fix, requerimiento
de documentación, todas y cada una de las tareas que llevan
a cabo se deriva de un ítem de Product Backlog. Cada ítem
en el Product Backlog incluye una descripción y una
estimación.
13. Actividades Scrum
01
05
04 03
02 Sprint Planning
• Comprender el trabajo a realizar por el equipo
de trabajo.
• Acuerdo del equipo sobre el trabajo necesario
• Duración de 2 a 4 horas.
• Se determina el qué y el cómo se va a realizar y
entregar al cliente.
Daily Meeting
Cada miembro del equipo cuenta tres cosas:
• Qué he logrado desde el último scrum diario.
• Qué pienso lograr entre este momento y el próximo scrum
diario.
• Qué está impidiendo mi avance.
Sprint
Retrospective
Revisión de:
• El proceso
• Relación entre las personas
• Potenciales mejoras
• Duración de 1 hora
Sprint Review
• Duración máxima de 1 hora.
• Discusión del incremento del
producto logrado.
• Se realiza por lo general demo del
producto. No ppt.
• Se actualiza el backlog como parte
de la revisión del sprint.
Refinamiento del
Product Backlog
Esta actividad se limita a:
• Mantener el Product Backlog Ordenado
• Eliminar items que no sean importantes
• Agregar items, dividir, unir y estimar items
14. Logros SCRUM en iTS
03
0201
06
04
05
Alineación de procesos internos con SCRUM y DevOps
Alineación de los procesos internos de Ingeniería con
prácticas SCRUM y DevOps.
Participación en Proyectos SCRUM externos
Para observar las mejores prácticas, personalizarlas y
aplicarlas en iTS.
Incorporación de Actividades SCRUM en los Proyectos
Se empieza a utilizar Dailys, Revisión de Sprint
y Retrospectivas en los proyectos
Estándar para Levantamiento de Información
en Historias de Usuario
Se construye desde los proyectos de PS y
Super Sociedades.
VSTS como
herramienta de
proyectos
Para cualquier tipo de
proyecto en iTS: Infra,
desarrollo, BI, migración, etc.
Proyecto Interno de Centro de
Excelencia iTS.
Para apoyar las nuevas metodologías y prácticas que
soportan la base de la Transformación Digital en iTS
15. • Estimaciones por Puntos
• Estados de Flujos
• Ejecución de las actividades de scrum
Políticas en iT Synergy con Scrum
16. Puntos de Historia de Usuario
La unidad de estimación preferida en el agilísimo se denomina Puntos de
Historia de Usuario (Story Points). Es una unidad que tiene en cuenta el tamaño
y la complejidad de la tarea, y mide el peso relativo de cada una de las historias
en estimación.
Estimaciones en Scrum
En la figura se muestra el tamaño relativo de
dos cilindros comparados con el cilindro base
(1x). Para el ser humano es más fácil utilizar
medidas relativas que absolutas. ¿Cuántas
onzas tiene una gaseosa grande? ¿Si no lo sabe
por qué la pide? Porque conoce el tamaño
relativo de las grandes y las pequeñas.
17. Para planificar un proyecto de software y realizar un seguimiento de los bugs mediante Scrum, los
equipos usan el Product BackLog Item (PBI) y bug work ítems Type (WIT). Para obtener
información en el portafolio de features, escenarios o experiencias de usuario, los Product Owners
y los program manager pueden asociar PBI y Bugs a los features. Cuando los equipos trabajan en
sprints, definen tareas que se vinculan automáticamente a los PBI y Bugs.
Portafolio del Backlog
18. Estados en los Flujos de Scrum
Product Backlog Item Bug Task
19. Sprint Review: Se debe realizar al finalizar el sprint
pero dentro de las fechas del Sprint.
Sprint Retrospective: Se debe realizar al finalizar el
sprint, no necesariamente debe realizarse dentro de
las fechas del Sprint.
Sprint Planning: Se debe realizar antes de iniciar el
Sprint, no necesariamente debe realizarse dentro de
las fechas del Sprint
Daily Scrum: Se debe realizar diario
Ejecución de Actividades de Scrum
El manifiesto ágil es un documento que resume en cuatro valores y doce principios las mejores prácticas para el desarrollo de software, basados en la experiencia de 17 industriales del software, en procura de desarrollos más rápidos conservando su calidad. Este artículo presenta de manera general la evolución de las metodologías para el desarrollo de software y una reseña de los valores y principios del manifiesto ágil.
Seguimos estos principios:
Nuestra mayor prioridad es satisfacer al clientemediante la entrega temprana y continua de softwarecon valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechanel cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dossemanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladorestrabajamos juntos de forma cotidiana durante todoel proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuariosdebemos ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad detrabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseñosemergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobrecómo ser más efectivo para a continuación ajustar yperfeccionar su comportamiento en consecuencia.
A través del uso del trabajo en equipo y la mejora continua, Scrum tanto crea como depende de estos valores
El Product Backlog puede comenzar como una lista extensa o breve. Puede estar descrito de forma
detallada o muy vaga. Típicamente empieza siendo breve e impreciso y se va convirtiendo en más extenso
y concreto con el correr del tiempo. Aquellos ítems del Product Backlog que estén programados para ser
implementados en breve serán "refinados": es decir clarificados, definidos en mayor detalle, divididos en
fracciones más pequeñas, como parte de la actividad de Refinamiento del Product Backlog.
El Product Owner es responsable de mantener el Product Backlog, aunque puede y
deberíarecibir
ayuda
para construirlo y mantenerlo actualizado. Los ítems del Product Backlog pueden surgir del Product Owner,
los miembros del Equipo de Desarrollo o incluso de otras partes interesadas.