Metodología
Ágil
Valores Manifiesto Ágil
• Valorar a las Personas
• Valorar el Software funcionando por
sobre la documentación detallada.
• Valorar la colaboración con el cliente
por sobre la negociación de contratos
• Valorar la respuesta a los cambios por
sobre el seguimiento estricto de los
planes
Principios
• Satisfacer al cliente
• Aceptar el cambio
• Entregar software funcionando en forma
frecuente
• Expertos del negocio y desarrolladores
deben trabajar juntos diariamente durante la
ejecución del proyecto.
• Construir proyectos en torno a personas
motivadas
• Conversación cara a cara
• Simplicidad
#Scrum
Características
• Más que una metodología es un
framework (marco de trabajo) para la
gestión de proyectos complejos.
• Scrum es un enfoque ágil para el
desarrollo de software.
• Permite que los equipos auto-
organizados entreguen resultados de
alta calidad en tiempos cortos
#Scrum
Principios
• Empirismo: Se refiere al proceso continuo de inspección y
adaptación que permite tomar decisiones en tiempo real y en
base a datos reales.
• Elementos emergentes: Implica que todas las soluciones a
todos los problemas emergerán y se volverán visibles a medida
que avancemos en los proyectos.
• Auto-organización: Se refiere a la estructura de los equipos
que crean el producto. Se otorga autonomía a pequeños
equipos multidisciplinarios para que puedan tomar decisiones
importantes, necesarias para 1) crear un producto de alta
calidad y 2) manejar su propio proceso
#Scrum
Por qué Scrum?
• Optimiza el plan de entregas.
• Mejorar Colaboración y comunicación con
el cliente.
• Equipo participativo y auto-organizado.
• Integración y resultados regulares.
• Hacia la experiencia, proceso de mejora
continua.
Roles
StakeHolders
• Cliente
• Es el dueño del producto
• Usuario Final
Product Owner
• Responsable del éxito del producto
• Conoce del Negocio
• Determinar la visión del producto, hacia
dónde va el equipo de desarrollo
• Recolectar los requerimientos
• Generar y mantener el release plan:
fechas de entrega y contenidos de
cada una
• Determinar las prioridades de cada una
de las características por sobre el resto
• Cambiar las prioridades
• Aceptar/rechazar el producto construido
al final de cada Sprint y proveer
feedback valioso para su evolución
ScrumMaster
• Coach del equipo y es quien lo ayuda a alcanzar
su máximo nivel de productividad.
• Líder servil, facilitador, que acompañe al equipo
de trabajo en su día a día y garantice que todos,
incluyendo al Product Owner, comprendan y
utilicen Scrum de forma correcta.
• Detectar, monitorear y facilitar la remoción de los
impedimentos que puedan surgir con respecto al
proyecto y a la metodología
• Asegurar la cooperación y comunicación dentro
del equipo
• Su responsabilidad es asegurar que se cumpla
con el proceso de Scrum sin interferir
directamente en el desarrollo del producto final.
Team-Equipo de desarrollo
• Conformado 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.
• Lo que se espera de un miembro de un equipo de
desarrollo es que no solo realice las tareas en las
cuales se especializa sino también todo lo que esté a
su alcance para colaborar con el éxito del equipo
• Proveer las estimaciones de cuánto esfuerzo será
requerido para cada una de las características del
producto.
• Debe comprometerse al comienzo de cada Sprint a
construir un conjunto determinado de características en
el tiempo que dura el mismo.
• Es responsable por la entrega del producto terminado
al finalizar cada Sprint.
Elementos
de Scrum
Product Backlog
• Es un listado de ítems (Product
Backlog Items, PBIs) o características
del producto a construir, mantenido y
priorizado por el Product Owner.
• Esta prioridad es responsabilidad
exclusiva del Product Owner y,
aunque el equipo de desarrollo pueda
hacer sugerencias o
recomendaciones, es el Product
Owner quien tiene la última palabra
sobre la prioridad final de los ítems
del Product Backlog, teniendo en
cuenta el contexto de negocio
Prioridades-Product
Backlog
• Priorización por valor de negocio de cada PBI:
Priorizar los ítems del Product Backlog es según su
valor de negocio
• Priorización por retorno de la inversión
ROI = valor de negocio/costo
Donde el costo representa el esfuerzo necesario para
la construcción de una determinada característica de
un producto y el valor de negocio es el rédito
económico obtenido por su incorporación.
• Prioridades según la importancia y el riesgo de
cada PBI:
Priorizar por importancia
construyendo primero aquellas características
con mayor riesgo asociado y dejando las que
poseen menor riesgo para etapas posteriores
Sprint o Iteraciones
Incremento funcional potencialmente
entregable
• Sprint Se llama a construir producto
en incrementos funcionales
entregados en periodos cortos para
obtener feedback frecuente.
• Scrum recomienda una duración de
Sprint de entre 1 y 4 semanas
Sprint Backlog
• Es el conjunto de Pbi que
fueron seleccionados para
trabajar en ellos durante un
cierto Sprint, conjuntamente
con las tareas que el equipo
de desarrollo ha identificado
que debe realizar para crear
un incremento funcional y
potencialmente entregable al
finalizar el Sprint.
Sprint Planning Meeting
Esta reunión de planificación
habitualmente se divide en dos
partes con finalidades
diferentes: una primera parte
estratégica y enfocada en el
“qué”, y una segunda parte
táctica cuyo hilo conductor
principal es el “cómo”.
Daily Meetings
• Objetivos: incrementar la comunicación,
explicitar los compromisos y dar visibilidad a
los impedimentos
• Una frecuencia diaria y no deberían llevar
más de 15 minutos. Estos 15 minutos son un
timebox, es decir, que no se pueden superar.
• Esta reunión es facilitada por el ScrumMaster
• 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?
TaskBoard
Sprint Review
• Al finalizar cada Sprint se realiza
una reunión de revisión
(review/demo) del incremento
funcional potencialmente
entregable construido por el
equipo de desarrollo
• Toda la retroalimentación que el
Product Owner y los stakeholders
aporten debe ser ingresada como
PBIs en el Product Backlog.
Retrospectiva
• El equipo reflexiona sobre la
forma en la que realizó su
trabajo y los acontecimientos
que sucedieron en el sprint
pasado para mejorar sus
practicas.
Refinamiento del Product
Backlog
• Se realiza durante el Sprint y en
función de las necesidades. Su
objetivo es profundizar en el
entendimiento de los PBIs que
se encuentran más allá del
Sprint actual y así dividirlos en
PBIs más pequeños, si lo
requieren, y estimarlos.
Proceso de Análisis Agil
• Roles de usuario
• Identificación de
Funcionalidades del Software
(Herramientas)
• Identificación de MMF
Historias de Usuario
• Card (Ficha) –Debe poder describirse en una ficha
de papel pequeña. Si una Historia de Usuario no
puede describirse en ese tamaño, es una señal de
que estamos traspasando las fronteras y
comunicando demasiada información que debería
compartirse cara a cara.
• Conversación – Debe tener una conversación con el
Product Owner. Una comunicación cara a cara que
intercambia no solo información sino también
pensamientos, opiniones y sentimientos.
• Confirmación – Debe estar lo suficientemente
explicada para que el equipo de desarrollo sepa qué
es lo que debe construir y qué es lo que el Product
Owner espera. Esto se conoce también como
Criterios de Aceptación
Historias de Usuario
Estimación Ágil
• Proveer una estimación precisa en etapas
tempranas de un proyecto tiene como
consecuencia un compromiso poco probable de
ser cumplido.
• A medida que adquiramos conocimiento,
nuestras estimaciones se harán cada vez más
precisas. El problema aparece a la hora de
estimar cuando muchas de las decisiones se
toman en base a supuestos que probablemente
no sucedan o no sean los correctos.
“La propia palabra “estimación” deja en claro
que no calculamos un valor exacto,
determinístico. De hecho, toda estimación tiene
supuestos, y estos supuestos suman
incertidumbres.”
Estimación Ágil
D F
XL L M S XS
21 13 8 5 3 2 1
Poker Planning
El motivo de utilizar una serie de Fibonacci
en un planning poker es porque cuanto
más grande es el número asignado a una
historia de usuario, más probabilidad de
equivocarse en la estimación.
Definition Of Ready
Es el conjunto de características que
una Historia de Usuario debe cumplir
para que el Equipo de Desarrollo
pueda comprometerse a su entrega
Definition Of Done
Es el conjunto de características
que una Historia de Usuario debe
cumplir para que el equipo de
desarrollo pueda determinar si ha
terminado de trabajar en ella
Release plan
Burn Down Chart
Un gráfico de trabajo pendiente a lo largo del
tiempo muestra la velocidad a la que se está
completando los objetivos/requisitos. Permite
extrapolar si el Equipo podrá completar el trabajo
en el tiempo estimado
Preguntas?
