Metodologías Agiles Scrum

Jhon Alexander Holguín Barrera
jhon.holguin@gmail.com

 “En enfoque de „carrera de relevos‟ en el desarrollo de productos ...
puede entrar en conflicto con los objetivos de máxima velocidad y
flexibilidad. En su lugar, un enfoque holístico o estilo „rugby‟ - donde
un equipo intenta ir a la distancia como una unidad, pasando la
pelota hacia adelante y hacia atrás -pueden servir mejor a los
actuales requisitos competitivos".
Hirotaka Takeuchi and Ikujiro Nonaka,
“The New New Product Development Game”,
Harvard Business Review, J
anuary 1986.
Introducción a Scrum

 Piensa antes de Construirlo! , Escribe todo! , sigue un
plan!, mantén todo lo mas organizado posible!.
 Las buenas ideas solo pueden ocurrir al inicio del
proyecto.
 Una buena idea luego de iniciado el
proceso es una amenaza!!!
 Escribir todo como el principal método
de comunicación.

“Los requerimientos no serán completamente
conocidos hasta después que los usuarios
hayan usado el producto terminado”
Watts S. Humphrey 2005

Ágil Individuos e
Interacción
Software que
funciona
Colaboración
con el Cliente
Respuesta al
Cambio
Sobre Sobre Sobre Sobre
No
Ágil
Procesos y
Herramientas
Documentación
Exhaustiva
Negociación
Contractual
Seguimiento de
un Plan
Fuente: www.agilemanifesto.org

 Proceso Ágil que permite centrarse en ofrecer un mayor
ROI en el menor tiempo
 Permite la rápida y en repetidas ocasiones inspeccionar
el avance real del producto de software
 El negocio fija las prioridades de tal manera que el
equipo se auto-organiza para determinar la mejor
manera de entregar funcionalidades de alta prioridad
 Cada dos semanas o un mes cualquiera puede ver el
software real funcionando y decidir liberarlo o seguir
mejorando el Sprint.
Fuente: Intro to Scrum Ernesto Grafeuille

 Jeff Sutherland
 Easel Corp en 1993
 Ken Schwaber
 Presenta como Scrum metodología formalizada en
OOPSLA (Object-Oriented Programming, Systems,
Languages & Applications) 95
 Ken Schwaber and Mike Cohn
 Fundaron Scrum Alliance 2002

 El avance del proyecto se da a través de los Sprint
 Duración de 2 a 4 Semanas
 El producto se diseña, desarrolla y testea en el Sprint
 Al final de cada Sprint se obtiene un incremento del
producto para el usuario final.
 No sufre cambios durante su desarrollo

Roles
• Product Owner
• ScrumMaster
• Team
Eventos
• Sprint Planning Meeting
• Scrum Daily
• Scrum Review
• Sprint Retrospective
Artefactos
• Product Backlog
• Sprint Backlog
• Burndown Charts

 Toma las entradas provenientes de los Stakeholders del
producto y los convierte en una visión.
 Es responsable por el ROI del producto.
 Encargado de construir la lista priorizada de las
funcionalidades del producto (Product Backlog)
 En algunos casos el Product Owner es el Cliente.

 Encargado de gestionar lo necesario para lograr el éxito del
equipo.
 No se toma como el jefe del equipo todo lo contrario es un
servidor del mismo quien quita cualquier obstáculo que
impida el avance del equipo.
 Es el encargado de realizar el entrenamiento de Scrum
dentro del equipo como de igual manera proveer soporte
sobre el mismo.
 En algunos casos este rol lo desempeña una sola persona en
equipos pequeños lo desempeña un miembro del equipo.

 Permite la estrecha colaboración entre los diferentes
roles del equipo.
 Maneja Disciplinas como:
 Gestión de Proyectos
 Ingeniería
 Diseño
 Testing
 Debe lograr identificar que iteraciones realizadas dentro
del proceso son o no útiles para ayudar a maximizar el
valor del producto.

 Compuesto de 2 a 10 miembros en empresas demasiado
grandes 15 miembros.
 Poseen conocimientos suficientes para poder cumplir
con los requerimientos del producto.
 Incluye todos los perfiles involucrados en la producción
del producto (Programadores, Diseñadores, Testers,
Investigadores, otros)
 Aportan ideas que permitan incrementar dar mayor
valor al negocio.

 Búsqueda de técnicas para garantizar la mejor gestión
del Product Backlog.
 Comunicar con claridad la visión y metas de los ítems del
Product Backlog al Equipo.
 Enseñar al equipo como construir un Product Backlog
con ítems concisos y claros.
 Permitir que se generen todos los eventos de Scrum si
son solicitados o necesitados.

 Entrenamiento al equipo para que pueda auto gestionarse.
 Enseñar y liderar al equipo para crear productos de alto valor.
 Quitar cualquier obstáculo que impida para que el equipo
progrese en su trabajo
 Dar cumplimiento a que se generen todos los eventos de
Scrum que se soliciten o necesiten.
 Entrenar al equipo desarrollador en ambientes de la
organización en el cual Scrum no ha sido adoptado o
entendido completamente.

 Liderar y Entrenar a la organización para la adopción y
entendimiento de Scrum.
 Planear la implementación de Scrum junto a la organización.
 Ayudar a los empleados y StakeHolders a entender y
promulgar Scrum.
 Causar el cambio que permita incrementar la productividad
del Equipo de Scrum.
 Trabajar de la mano con otros ScrumMasters para aumentar
la efectividad de Scrum dentro de la organización.

 El equipo selecciona los ítems del product Backlog
que puede lograr.
 Duración de 8 horas en Sprints de 4 Semanas a
menor tiempo disminuye proporcionalmente.
 Dentro del Sprint Planning Meeting se responden las
siguientes preguntas:
 Que va a ser entregado en el resultado del Sprint por
venir?
 Como será el trabajo necesario para poder lograr
entregar el resultado deseado?

 Reunión que se realiza diariamente durante el desarrollo del Sprint
con duración de 15 minutos.
 Todos los integrantes del Equipo deben estar de pie.
 Se responden las siguientes Preguntas:
 Que hice ayer?
 Que voy a hacer hoy?
 Que impedimentos están impidiendo mi avance?
 Solo se responden estas preguntas, en la reunión no se da solución
a los impedimentos que se presenten estos se realizan
posteriormente

 A través de este se puede evaluar la efectividad del
Sprint.
 Aumenta la posibilidad de lograr la Meta de Sprint.
 Omiten reuniones innecesarias
 El equipo obtiene un nivel de conocimiento superior del
estado del proyecto.

 Se realiza al finalizar el Sprint, tiene una duración 4
horas.
 Inspecciona el incremento del que se tuvo del producto y
se actualiza el Product Backlog de ser necesario.
 Interviene el Equipo y los Stakeholders con el fin de
establecer si estuvo listo.

 El Product Owner establece que estuvo listo y que no.
 El equipo de desarrollo discute que estuvo bien durante
el Sprint, que cosas no anduvieron bien y como estos
problemas fueron solucionados.
 El equipo presenta el resultado del incremento del
producto que se produjo por el Sprint y resuelve
cualquier inquietud que se presente.
 El Product Owner se encarga de actualizar el estado del
proyecto.

 El equipo se auto inspecciona y planea mejoras para los próximos
Sprint.
 Duración de 4 horas.
 Ocurre después del Srint Review y el Sprint Planning.
 Analizar el comportamiento de la Personas, Herramientas,
Procesos en el ultimo Sprint.
 Identificar aquellos ítems que deben ser mejorados con prioridad.
 Establecer un plan para poder implementar estas mejoras para el
Equipo de Scrum.

 Lista de todos los requerimientos o necesidades para el
producto, presentados de manera priorizada.
 A cargo del Product Owner.
 Nunca esta completo, solo hasta que el producto salga
de funcionamiento.
 Esta constantemente cambiando, adaptándose a las
necesidades del cliente.

 Se puede encontrar:
 Características del Producto
 Funcionalidades
 Requerimientos
 Mejoras
 Correcciones

 Entregas funcionales del producto constantes para el
Cliente.
 Constante Feedback con el Cliente.
 Los costos en términos de Gestión y Proceso son
mínimos, llevando a un resultado mas rápido y barato.
 Permite que se desarrollen requerimientos en donde en
el inicio del proyecto no hay la suficiente claridad.
 Existe una alta posibilidad de detección y corrección
temprana de problemas en el proyecto.

 Permite medir y mejorar la productividad individual de los
miembros del equipo.
 Alta motivación en el equipo de desarrollo por permitir la
autogestión.
 Posibilidad de Ajustar la funcionalidad del producto
conforme a la necesidad del negocio del cliente.
 Radiografía constante del Estado del Proyecto.
 Alta flexibilidad al Cambio.

 Si no se delimita claramente el proyecto es posible
que se pueda alargar el mismo a un tiempo no
deseado.
 Tareas no definidas claramente repercuten en
aumento de costos y tiempo.
 Requiere un alto nivel de experiencia del equipo.
 Falta de documentación o evidencia generado por
otras metodologías

 Falta de disciplina para cumplir con los eventos de
Scrum.
 Falta de Claridad en el Product Backlog
 Requerimientos de liberar versiones con pocos
intervalos de tiempo.
 Entender la metodología e interiorizarla.
 Iniciar a definir procesos claros en la organización.

 Mayor integración del Equipo de desarrollo, aumento de
confianza entre los miembros del equipo
 Comprometimiento de la Organización a mejorar los
procesos de desarrollo.
 Corrección de los problemas encontrados a través de las
retrospectivas de Scrum
 Interrupciones en el Desarrollo (Teléfono, Soporte otros)
 Falta de Disciplina para ejecutar los eventos de Scrum.
 Planificación de Raleases de los aplicativos.
 Entender la metodología e interiorizarla.

Fuente: www.proyectosagiles.org

 http://www.scrum.org
 http://www.proyectosagiles.org
 http://www.mountaingoatsoftware.com/

Metodologías Agiles Scrum

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (7)

Similar a Metodologías Agiles Scrum

Similar a Metodologías Agiles Scrum (20)

Más de Jhon Barrera

Más de Jhon Barrera (20)

Último

Último (15)

Metodologías Agiles Scrum