CURSO SCRUM QUE ES AGIL

CURSO SCRUM

QUE ES AGIL

JIM HIGHTSMITH

1. Poseer la habilidad de crear y responder al cambio para producir ganancias en un ambiente laboral turbulento

1. Equilibrar la flexibilidad y la estabilidad

1. Adaptarse al cambio, ser flexible y ser capaz de hacer frente a los cambios

CUAL ES LA NECESIDAD

• Reducción de tiempos de mercadeo de los productos
• Aumento de innovación por parte del cliente
• Buscar métodos adaptivos para la gestión de proyectos

QUIEN PUEDE SER AGIL

• Cualquier proyecto sin importar la complejidad

MANIFIESTO AGIL

Febrero 2001 17 Gurús De Informática Crearon El Manifiesto

Estamos descubriendo formas mejores para desarrollar software por experiencia propia como ayudando a terceros

Se aprendió a valorar

INDIVIDUOS E INTERACCIONES (SON MAS VALORADOS) MAS IMPORTANTES

• Software funcionando
• Colaboración con el cliente
• Respuesta ante el cambio

PROCESOS Y HERRAMIENTAS

• Documentación Extensiva
• Negociación Contractual
• Seguir un Plan

PUNTOS DEL MANIFIESTO (4 Contrapartes)

1. Individuos e interacciones sobre procesos y herramientas.
2. Software funcionando vs documentación extensiva (Enfoque proyecto funciones)
3. Colaboración con el cliente sobre negociación contractual (El cliente pasa a ser del equipo, colaborador directo durante todo el proyecto).
4. Responder ante el cambio sobre seguir un plan (Cambio vs Plan) Abierto al cambio

PRINCIPIOS DEL MANIFIESTO AGIL

1. Satisfacer al cliente mediante la entrega temprana y continua de software valioso.
2. Aceptar que los requisitos cambien incluso en etapas tardías. Se aprovecha el cambio para dar ventaja competitiva al cliente.
3. Entregar software funcional frecuentemente máximo en 8 semanas, pero lo ideal es 2.
4. Responsables del negocio y desarrolladores trabajan cotidianamente juntos.
5. El proyecto se desarrolla entorno a individuos motivados, con apoyo en lo que necesitan y confiando en el trabaja de cada uno.
6. Método efectivo colaboración y de comunicar información transparentemente al equipo de desarrollo y entre sus miembros.
7. El software funcional es la medida principal del progreso.
8. Promueve el desarrollo paulatino y sostenible.
9. La atención continua conlleva a la excelencia técnica, al buen diseño y mejora la agilidad.
10. La simplicidad, el arte de maximizar el trabajo no realizado es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto organizados.
12. Analizar cómo ser más eficaz para después ajustar y perfeccionar según corresponda.

PRINCIPIOS SCRUM

1. Control de proceso empírico.

TIA Transparencia - Inspección - Adaptación.

1. Auto - organización.

Alto nivel de organización.

1. Colaboración.

Apropiación del equipo de trabajo.

1. Priorización.

Basa en valor.

1. Bloque de Tiempo

Máximo tiempo por evento.

• Sprints
• Daily StandUps
• Reuniones de planificación del Sprint
• Reuniones de revisión del Sprint
• Reuniones de retrospectiva del Sprint

1. Desarrollo Iterativo

Repetir procesos para adaptar cambios

Aspectos

1. Organización

1. Roles Centrales necesarios y obligatorios

• Product Owner voz del cliente, maximizar valor del producto, prioriza la necesidad del cliente. Revisa el trabajo de equipo SCRUM y aprueba los incrementos de producto para entregar al cliente.
• Scrum Master, Facilitar y quitar impedimentos equipo SCRUM,
• Equipo Scrum Desarrollo o Developer en base  al producto owner

1. Roles no Centrales

• Cliente
• Stakeholder
• Usuario
• Patrocinador
• Vendedores
• Scrum Guidance Body Equipo de Expertos o Documentación de lineamientos del proyecto

1. Justificación de Negocio

1. Value driven Delivery

1. Calidad

1. Criterios de Aceptación Incrementos de productos
2. Stakeholders
3. Pasar por standares

1. Cambio

1. Stakeholder cambian de opinion

1. Riesgo

1. Oportunidades

• Identificados
• Evaluados
• Atendidos

1. Amenazas

• Identificados
• Evaluados
• Atendidos

PROCESOS DE SCRUM SON ADAPTABLES AL PROYECTO

FASES

1. INICIO

1. Crear visión del proyecto (se defino el producto Owner)
2. Identificar al Scrum Master y los Stakeholders lo hace el producto Owner
3. Formar el Equipo Scrum con ayuda el Scrum Master y el porduct Owner
4. Desarrollo de las épicas (Sale el Product Backlog)
5. Crear el Producto backlog
6. Realizar la planificación de los ítems del backlog producto

1. PLANEACIÓN Y ESTIMACIÓN

1. Crear historias de usuario en base a las épicas.

• Como “<rol/prototipo de cliente>” yo debería “<requerimientos>” a fin de “<beneficio>”

1. Estimar historias de usuario con base al riesgo y complejidad
2. Comprometer las historias de usuario
3. Las historias de usuario se descomponen en tareas y se estiman y se pueden reestimar las historias.
4. Crear sprint backlog.

1. IMPLEMENTACIÓN

1. Crear Entregables
2. Daily Standup (Qué hecho, qué voy hacer, qué impedimentos tengo) 15min
3. Refinamiento del Product Backlog

1. RETROSPECTIVA

1. Demostrar y validar el Sprint al Producto Owner
2. Retrospectiva del Sprint (bueno y malo del Sprint) para buscar mejorar

1. LANZAMIENTO

1. Enviar Entregables
2. Retrospectiva del proyecto Oportunidades Amenazas del proyecto

...