Introduction to Scrum v2

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 Procesos y
Herramientas
Documentación
Exhaustiva
Negociación
Contractual
Seguimiento de
un Plan
Ágil
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


• Product Owner
• ScrumMaster
Roles • Team

• Sprint Planning Meeting
• Scrum Daily
Eventos
• Scrum Review
• Sprint Retrospective

• Product Backlog
• Sprint Backlog
Artefactos • 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/


Introduction to Scrum v2

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Introduction to Scrum v2

Similaire à Introduction to Scrum v2 (20)

Plus de Luis Eduardo Pelaez Valencia

Plus de Luis Eduardo Pelaez Valencia (20)

Introduction to Scrum v2