Introducción al marco ágil: Scrum.

Dinámica con la gestión de proyectos.

• Principios
– Respetar a las personas, porque el equipo es quien conoce cómo mejorar el proceso en que
trabaja.
– Eliminar los desperdicios que se producen en el proceso, todo aquello que no produce valor
añadido en el producto.
– Aplazar el compromiso, retardar las decisiones hasta que se disponga de toda la información o no
se pueda esperar más.
– Crear conocimiento, tener feedback regular con el cliente para alinearse con sus expectativas.
– Hacer entregas rápidas, para permitir que el cliente pueda
aprovechar antes los beneficios que le aporta el proyecto.
– Desarrollar con calidad interna, de manera que el producto
pueda ir creciendo con una velocidad sostenida.
– Optimizar la totalidad del proceso, mejorar el proceso de
creación del producto, desde la idea hasta su entrega
 ¿Cuando un método es ágil?
• Simple pero duro. No se basa en el seguimiento de un plan sino en
la adaptación continua a la evolución del proyecto. El desarrollo
de software es:
– Incremental
• liberaciones pequeñas y ciclos rápidos.
– Cooperativo
• clientes y desarrolladores trabajando juntos.
– Simple y Directo
• el método es fácil de aprender y modificar.
– Adaptativo
• es posible realizar cambios de último momento.
Diferencias entre metodologías
Metodologías Ágiles
• Basadas en heurísticas
provenientes de prácticas de
producción de código
• Especialmente preparados para
cambios durante el proyecto
• Impuestas internamente (por el
equipo)
• Proceso mucho más controlado,
con numerosas
políticas/normas
• No existe contrato tradicional o
al menos es bastante flexible
Metodologías tradicionales
• Basadas en normas
provenientes de estándares
• Seguidos por el entorno de
desarrollo
• Cierta resistencia a los
cambios
• Impuestas externamente
• Proceso menos controlado,
con pocos principios
• Existe un contrato prefijado
Metodologías Ágiles Metodologías tradicionales
• El cliente interactúa con el • El cliente es parte del equipo de
desarrollo mediante reuniones
equipo de desarrollo   • Grupos grandes y posiblemente
• Grupos pequeños (<10 distribuidos
integrantes) y trabajando en el • Más artefactos
mismo sitio • Más roles
• • La arquitectura del software es
Pocos artefactos esencial y se expresa mediante
• Pocos roles modelos
• Menos énfasis en la  
arquitectura del software
 
 Introducción a SCRUM
• La palabra SCRUM procede del vocabulario del rugby y significa melé; es
decir, que los compañeros del equipo se amontonan, forman una piña y
empujan todos en la misma dirección.
• SCRUM es una estrategia de gestión donde se aplican de manera regular
un conjunto de prácticas para mejorar el trabajo colaborativo y obtener el
mejor resultado posible en la gestión de un proyecto software.
Scrum
• Scrum es un proceso ágil que nos permite
centrarnos en ofrecer el más alto valor
de negocio en el menor tiempo.
• Nos permite rápidamente y en repetidas
ocasiones inspeccionar software real de
trabajo (cada dos semanas o un mes).
• El negocio fija las prioridades. Los
equipos se auto-organizan a fin de
determinar la mejor manera de entregar
las funcionalidades de más alta
prioridad.
• Cada dos semanas o un mes, cualquiera
puede ver el software real funcionando y
decidir si liberarlo o seguir mejorandolo
en otro sprint.
• El Manifesto Ágil – una declaración de valores. Aunque los elementos a la derecha tienen
valor, nosotros valoramos por encima de ellos los que están a la izquierda.
Individuos e Sobre Procesos y herramientas
iteraciones

Sobre Documentacion
Software funcionando extensiva

Colaboracion con el Sobre Negociación contractual

cliente

Respuesta ante el Seguir un plan

Sobre
cambio
– Al individuo y las interacciones del equipo de desarrollo sobre el
proceso y las herramientas.
• Es más importante construir un buen equipo.

– Desarrollar software que funciona más que conseguir una buena

documentación.
• No producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante.

– La colaboración con el cliente más que la negociación de un contrato.

• Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración
entre ambos será la que marque la marcha del proyecto y asegure su éxito.

– Responder a los cambios más que seguir estrictamente un plan.

• Se debe ser hábil en responder a los cambios y a los fracasos, la planificación no debe ser estricta sino flexible y
abierta.
• Scrum es un proceso iterativo e incremental que puede ser utilizado para
desarrollar cualquier producto o administrar cualquier trabajo. Sus principales
atributos son:
– Un enfoque orientado a que los equipos desarrollen productos de manera iterativa e
incremental cuando los requerimientos cambian de manera rápida
– Un proceso que controla el caos de conflictos de intereses y necesidades
– Una manera de mejorar las comunicaciones y maximizar la cooperación
– Una manera de maximizar la productividad
– Escalable a múltiples proyectos y la organización
– Una forma que todos se sientan bien con su trabajo, entendiendo que
cada uno con sus contribuciones hizo lo mejor que podía hacer
 Principios
• Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de
software con valor.
• Aceptamos requisitos cambiantes, incluso en etapas avanzadas.
• Entregamos software frecuentemente.
• Los responsables de negocio y los desarrolladores deben trabajar juntos permanentemente.
• Construimos proyectos con profesionales motivados.
• Conversación cara a cara.
• Software que funciona es la principal medida de progreso.
• Los procesos ágiles promueven el desarrollo sostenible.
• La atención continua a la excelencia técnica y los buenos diseños
mejoran la agilidad.
• Simplicidad es esencial.
• Las mejores arquitecturas, requisitos y diseños surgen de
equipos que se auto-organizan.
• A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo.
 Características
• Equipos auto-organizados
• El producto progresa en una serie de “sprints” que duran un mes
• Los requerimientos se encuentran en el “product backlog” reunidos en una lista
• No contiene practicas de ingeniería pre-descriptas
• Utiliza reglas generales para crear un ambiente ágil para la liberación de los proyectos
• Usado para proyectos complejos con requerimientos cambiantes
• Basado en un control de proceso empírico
• No hay prácticas de ingeniería prescritas
• Metodología de trabajo ágil
• Diseñada para acortar el ciclo de desarrollo
• Conseguir una mejor aproximación entre las funcionalidades del software y los requerimientos del cliente
• Evitar la burocracia innecesaria
• Mayor versatilidad frente a los cambios
• Comenzar el trabajo lo más rápidamente posible
• Manejo más eficiente de los requerimientos cambiantes en un proyecto
• Mejorar la comunicación entre el cliente y el equipo desarrollador
• No dice Qué hacer sino Cómo hay que hacer las cosas
• Trazabilidad
– Establece de forma precisa e inequívoca el seguimiento de un producto y/o servicio
durante todo su ciclo de vida.
– Formado por un conjunto de acciones, medidas y procedimientos técnicos que permite
identificar y registrar cada requerimiento de manera que se pueda seguir su ciclo de vidas
tanto para atrás, desde su origen, como hacia delante, en la entrega del producto.
– Toda la documentación, códigos y guiones de prueba deberán apuntar a su fuente de
origen para permitir saber en todo momento el origen, la implementación y las pruebas
que se hagan a cualquier requerimiento
– Bidireccional: A partir de un requisito se llega al código que lo implementa y a partir de
un determinado código saber el o los requisitos a los que corresponde.
– Vertical: Garantiza que todos los requerimientos serán diseñados y que todos los diseños
serán codificados y probados.
– Horizontal: Permite detectar si hay conflictos entre requerimientos, diseño, lógica de
codificación y/o casos de prueba
 Practica SCRUM
• Scrum es una a practica de desarrollo muy simple, no se basa en el
seguimiento de un plan, sino en la adaptación continua a las circunstancias
de la evolución del proyecto.
Es un modo de
desarrollo de Orientado a las
carácter adaptable personas más que
más que a los procesos.
predictivo.

incremental
Emplea la
basada en
estructura de
iteraciones y
desarrollo ágil
revisiones.
Roles Reuniones
Responsable del •Planificación del
producto: “Product Daily Scrum Sprint
Owner” 24 horas •Seguimiento del
Responsables del Sprint
desarrollo: “Scrum •Revisión del
Team” Sprint
Responsable del Sprint •Scrum diario
Incremento en
funcionamiento de 2-4 semanas
el Producto
Scrum:Objetivo del Sprint
“ScrumMaster”

Sprint
Return Backlog Artefacto
s
Gift wrap •Product Backlog
Cancel •Sprint Backlog
Product •Incremento
Incremento del producto
Backlog •Graficos “Burndown”
potencialmente entregable
 Propietario del Producto
• Persona conocedora del entorno de negocio del cliente y de la visión del producto .
Representa a todos los interesados en el producto final. Sus responsabilidades son:
– Define las funcionalidades del producto
– Decide sobre las fechas y contenidos de los releases
– Es responsable por la rentabilidad del producto (ROI)
– Prioriza funcionalidades de acuerdo al valor del mercado/negocio
– Ajusta funcionalidades y prioridades en cada iteración si es necesario 
– Acepta o rechaza los resultados del trabajo del equipo
– Financiación del proyecto
– Define funcionalidad requerida
– Retorno de la inversión del proyecto
– Lanzamiento del proyecto
– Representa a la gestión del proyecto
– Toma las decisiones de priorización
– Representa a todos los interesados en el producto final
 El Scrum Master
• Sus responsabilidades son:
– Responsable de promover los valores y prácticas de Scrum
– Se asegura de que el equipo es completamente funcional y productivo
– Permite la estrecha cooperación en todos los roles y funciones
– Escudo del equipo de interferencias externas
– Garantiza el funcionamiento de los procesos y metodologías que se emplean. Formación y entrenamiento de
procesos.
– Incorporación de Scrum en la cultura del equipo
– Garantía de cumplimiento de roles y responsabilidades
– Remueve impedimentos. Facilitador.
– Es un role flexible:
• Dirección de la empresa, con el conocimiento de gestión y desarrollo ágil y facilitando los recursos necesarios
• Responsables del Departamento
• Responsables del área de gestión de proyectos
 El Equipo
• Responsable de transformar la pila del sprint en un incremento de la
funcionalidad del software. Sus características son:
– Equipo multidisciplinar que cubre todas las habilidades necesarias para generar el
resultado
– Se auto-gestiona y auto-organiza
– Dispone de atribuciones suficientes para toma de decisiones sobre cómo realizar su
trabajo
– Típicamente de 5 a 9 personas
– Los miembros deben ser preferentemente full-time.
– Los equipos son Auto – gestionado y Auto – organizado
– Solo puede haber cambio de miembros entre los
sprints
– Transforman los requerimientos en funcionalidad en
cada incremento
 Interdependencias de los roles
Interesados PO PM SM Equipo
>> Asegura que el proyecto cumple objetivos
>> Administra al equipo Auto-organizado
>> Administra el alcance y el presupuesto
>> Administra la comunicación entre involucrados
>> Gestiona riesgos y elimina obstáculos
>> Administra el proceso
>> Gestiona la visión Mejora continua
>> Investigación de mercado. Visión, Voz del Cliente
<< Asegura que el proyecto logra los objetivos
<< Negocia el trabajo con el equipo
<< Gestiona el alcance, cronograma, y presupuesto
<< Gestiona la comunicación con los interesados
>> Visualiza y distribuye información
>> Remueve impedimentos
• Otros roles:
– Propietario de la arquitectura: es el encargado de realizar las decisiones de la arquitectura para el
equipo.
– Especialista: en la mayoría d equipos agiles no existe especialistas, sin embargo en
– proyectos a gran escala es necesario de conocimientos específicos.
– Experto de dominio: es parte del equipo de trabajo del propietario del producto, el cual ayudara a
definir los requerimientos del sistema.
– Expertos técnicos: Son parte del equipo de manera temporal, los cuales ayudan a superar problemas
con altas dificultades, así mismo transfieren parte de sus habilidades a los desarrolladores.
– Tester independiente: En algunas ocasiones se utilizan equipos de pruebas independientes, para
ayudar a validar el trabajo realizado a lo largo del ciclo de vida.
– Integrador: es en el cargado de adaptar y construir todo el sistema desde los diversos subsistemas.
 Historias de usuario
Historia de Personas (1) Contexto (4)
Usuario (2) Personas, Usuarios Necesidad origen, Escenarios de uso de la historia, Dominio del
Como <Tipo de o consumidores negocio, qué áreas del negocio usan o se impactan por la historia,
Usuario>, Quiero, finales, Reglas del negocio que afectan la historia, Épica origen. No todas las
<Hacer algo>, Para Interesados, historias provienen de una épica en particular pero si es así, es bueno
<Propósito> Patrocinadores, conocerla, Alcance de la historia
Equipo de
desarrollo, Equipo Definición de Preparado (5) Definición de Terminado (6)
de soporte Que se debe cumplir para que la Condiciones de Terminado
historia se pueda construir? especificas a la historia

Criterios de
Aceptación (3)
• El acrónimo INVEST para describir las características de una buena historia:
– Independiente: las historias pueden completarse en cualquier orden.
– Negociable: los detalles de la historia son co-creados por los programadores y los clientes durante el
desarrollo.
– Valiosa: la funcionalidad es valiosa para los clientes o los usuarios del software.
– Estimable: los pgoramadores pueden encontrar una estimación razonable para construir la historia.
– Pequeña: las historias deberían construirse en poco tiempo, generalmente alrededor de
"días/persona". Se tienen que poder construir muchas historias en una iteración.
– Testeable: se debe poder escribir pruebas que verifiquen que el software de la historia funcione
adecuadamente.
• Una forma habitual de escribir las historias es "Como <rol>.... Quiero <característica>...
Para <valor>". La parte del "Como..." se refiere a la persona que quiere la historia. La
parte "Quiero..." describe la funcionalidad de la historia, y la parte "Para..." describe el
motivo por el cual se pide esa funcionalidad.
• Técnicas de priorización de historias de usuario:
– MoSCoW se basa únicamente en dividir las funcionalidades en cuatro grupos en función de su
prioridad. Es conveniente que el número de funcionalidades esté equilibrado en cada grupo.
MoSCoW es un pseudo-acrónimo formado por las cuatro categorías en las que se tienen que dividir
todas las funcionalidades:
• Must Have (Imprescindibles): son funcionalidades que deben ser incluidas antes de que el producto pueda ser
puesto en producción. En el contexto de gestión lean, se denomina Mínimo Producto Viable (MVP por sus
siglas en inglés) a aquel que contiene únicamente este conjunto de características. Sin alguna de ellas, el
producto no tendría sentido.
• Should Have (Importantes): son funcionalidades importantes y de gran valor para el usuario pero que no
impiden poner el proyecto en marcha si no se tienen. Obviamente, son las siguientes en la lista de prioridad y
deberían incluirse justo después de haber finalizado el Mínimo Producto Viable.
• Could Have o (Buenas): son funcionalidades que sería deseable tener y podrían incluirse en caso de que
hubiese recursos para ello. No obstante, en caso de que sea necesario, se podrían descartar.
• Won’t Have o (Excluidas): son funcionalidades que el cliente ha solicitado inicialmente pero que se descartan
por falta de recursos (tiempo, dinero, etc). Como la priorización debe realizarse de forma iterativa a lo largo del
proyecto, algunas de estas funcionalidades pueden considerarse en el futuro.
– Theme Scoring es una técnica que permite determinar la prioridad de las funcionalidades como una combinación de
diferentes criterios, a los que se puede dar diferente importancia. A cada historia de usuario se le asigna un peso de 1
a 5 en cada una de las características. Para ello, por cada característica se elige una historia de usuario de referencia,
que tenga un valor medio de 3. A las demás historias de usuario se les asigna el peso en cada característica en
comparación con la historia de usuario de referencia. La estimación de una característica por comparación es siempre
mucho más sencilla y rápida que la estimación de una medida absoluta.
– WSJF es una técnica que prioriza en función del valor, coste y riesgo equitativamente y de forma sencilla. Consiste en
sumar el valor al usuario, el valor de tiempo (necesidad de un plan B) y la reducción del riesgo que aporta la historia y
dividirlo por el tiempo que llevaría realizarla. Es un algoritmo optimizado económicamente para la priorización y
programación del trabajo en un ambiente en el que el coste de la demora y la duración de los elementos de trabajo
varían.
• WSJF = (Valor de Negocio/Usuario + Valor del Tiempo + Reducción de Riesgo & Valor de Oportunidad) /
Tamaño del trabajo
• Donde los anteriores significan…
– Valor de Negocio/Usuario: Es el valor que da la empresa o el usuario. Aquí también hay que incluir los
costes de penalización si los hubiera así como los ingresos. Para darle un valor podemos escoger una
escala de 1,2,3,5,8,13, siendo 1 lo más bajo y 10 lo más alto.
– Valor de tiempo: En esta medida, lo que intentamos medir es la necesidad de un “plan B” por si las
cosas salen mal, ya sea por la pérdida de contratos, clientes o ingresos. Podemos usar la misma escala
de antes, en la que 1 sea una necesidad baja de este plan b, y el 13 una necesidad total el tenerlo.
– Reducción de Riesgo & Valor de Oportunidad: En esta parte damos un valor a la necesidad de la
empresa de reducir riesgos o el potencial de las nuevas oportunidades de negocio que se derivan del
trabajo actual. Como antes, usaremos la misma escala.
– Tamaño del trabajo: Estimación del tiempo necesario para poner una nueva característica o función del
producto en producción. Podemos usar como antes la misma escala, o tomar una que sea en semanas,
por ejemplo.
– El resultado que nos de la fórmula con los datos anteriores nos prioriza las tareas, pasando a hacer
primero las de un valor más alto.
 Product Backlog
• Listado con los requisitos del sistema. Una lista de todos los trabajos deseados en el proyecto
– Priorizadas
– Documento "vivo"
– Accesible a todos los roles
– Todos pueden contribuir y aportar elementos
– El propietario del producto es su responsable:
• Representa los intereses del cliente dentro de la empresa.
• Es el nexo entre el cliente y el equipo.
• Tiene la visión global del producto buscado.
• Es el encargado de armar y priorizar el Product Backlog (Lista priorizada de
requerimientos).
• Cada tema tiene valor para el usuarios o el cliente (desde el punto de vista del
negocio)
• Repriorizada al comienzo de cada Sprint
• Es dinámico.
• Mientras exista un producto, el Product Backlog también existe.
 Pila del sprint Nueva
funcionalidad

Selección de la
Pila de producto
(Product Backlog)
-- Funcionalidades

Pila de producto
-- Requisitos priorizados.
-- Listado con los requisitos
del sistema.
• Product Owner
(modificar cuidando la
inversión).
• Stakeholders (usuario,
soporte técnico,
administradores,etc )
 Sprint
• Cada iteración se llama sprint y se realiza una revisión de los requisitos con todas las personas
involucradas en el proyecto
• Dentro de cada sprint, SCRUM gestiona la evolución del proyecto mediante reuniones breves
de seguimiento en las que se revisa el trabajo realizado desde el hito anterior y los planes para
el hito siguiente
• Las reuniones de seguimiento de cada sprint deben ser diarias
• La duración típica es 2–4 semanas o a lo sumo un mes calendario
• La duración constante conduce a un mejor ritmo
• El producto es diseñado, codificado y probado en el Sprint
• No hay cambios en un sprint. Planee la duración del sprint en
torno a cuánto tiempo usted puede comprometerse a
mantener los cambios fuera del sprint.
• El objetivo del Sprint. Una breve declaración de cual será el
foco del trabajo durante el sprint.
 Planificación del Sprint
• El equipo selecciona los temas a partir del Product Backlog que pueden
comprometerse a completar
• Los Sprints duran, idealmente, menos de un mes.
• Se seleccionan los requerimientos del Product Backlog que entrarán en el sprint.
• Se hace un listado de todas las tareas necesarias para terminar el sprint backlog,
indicando el esfuerzo de cada una.
• Se asignan responsables a las tareas
• El diseño de Alto Nivel es considerado
Capacidad del
Sprint Planning
Equipo meeting
Priorización
Product • Analizar y evaluar el Objetivo del
Backlog Product Backlog Sprint
• Seleccionar el objetivo
del Sprint
Condiciones
del Negocio Planificación
• Decidir como alcanzar
Producto el objetivo del Sprint
Sprint
Actual (diseño)
• Crear el Sprint Backlog Backlog
(tareas) en base a los
temas del Product
Tecnología
Backlog (user stories /
features)
• Estimar Sprint Backlog
en horas
• Primera reunión (Las primeras cuatro horas se dedican al Product Owner):
– Se establece la meta del Sprint
– Se identifica la funcionalidad que se va a construir en el Sprint
• Segunda reunión (Las segundas cuatro horas el equipo planea su propio Sprint):
– Se identifican y estiman las tareas para satisfacer
– Se crea un Sprint Backlog
– Las tareas son distribuidas por decisión de los miembros del equipo
– Los miembros del equipo se comprometen a cumplir con la meta del Sprint
• Entradas:
– Backlog del producto actualizado
– Retorno del ultimo Sprint
– Rendimiento del equipo en los Sprints anteriores
• Salida:
– Pila del sprint (Sprint Backlog)
• Pila del sprint (Sprint Backlog)
– Trabajo o tareas determinadas por el equipo para realizar en un sprint
y lograr al final del mismo un incremento de la funcionalidad.
– Se recomienda que las tareas reflejadas tengan una duración
comprendida entre las 4 y las 16 horas de trabajo.
– Las de mayor duración deben intentar descomponerse en sub-tareas
de ese rango de tiempo.
• Gestión del Sprint Backlog
– Los individuos eligen las tareas
– El trabajo nunca es asignado
– La estimación del trabajo restante es actualizada diariamente
– Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint
Backlog
– El trabajo para el Sprint emerge
– Si el trabajo no está claro, definir un tema del Sprint Backlog con una
mayor cantidad de tiempo y subdividirla luego.
– Actualizar el trabajo restante a medida de que más se conoce
 Estimación de póquer
• La estimación no la realiza el cliente / Product Owner, por que no es él quien se va
a “ensuciar las manos” y luchar por cumplir con fechas.
• Todo el equipo realiza la estimación para:
– Reforzar el compromiso de todo el equipo respecto a las fechas que dan al cliente.
– Reforzar el compromiso de cada miembro del equipo respecto al resto.
– Hacer que todo el mundo se sienta oído.
• Estimar usando una unidad:
– Días ideales: los días necesarios para que el equipo
pueda completar un objetivo, sin considerar
interrupciones. Para pasar a días reales hay que aplicar
un factor de corrección que puede ir del 60 % al 70 %
de dedicación real al proyecto. Asimismo, habrá que
tener en
cuenta un margen para imprevistos.
 – Puntos de historia de usuario: la complejidad que tiene cada historia de usuario. Un equipo en un
proyecto determinado es capaz de completar un número semi-regular de puntos de historia cada
iteración (“velocidad”).
• Es una práctica ágil, para conducir las reuniones en las que se estima el esfuerzo y la duración
de tareas. El modelo consta de 8 cartas: ½, 1, 2, 3, 5, 6, 7 e infinito.
• El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la
estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo
estimado.
• Cuando se considera que éste es mayor de x horas ideales (el tamaño máximo considerado
por el equipo para una tarea), se levanta la carta “infinito”. Las tareas que exceden el tamaño
máximo deben descomponerse en sub tareas de menor tamaño
• Cada equipo u organización puede utilizar un juego de cartas con las numeraciones
adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se
va a estimar.
• Procedimiento
– Cada participante de la reunión tiene un juego de cartas.
– Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que
se va a estimar) el cliente, moderador o propietario del producto expone la descripción
empleando un tiempo máximo.
– Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las
posibles preguntas del equipo.
– Cada participarte selecciona la carta, o cartas que representan su estimación, y las
separa del resto, boca abajo.
– Cuando todos han hecho su selección, se muestran boca arriba.
– Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido, la tarea
debe dividirse en sub-tareas de menor tamaño.
 – Si las estimaciones resultan muy dispares, quien asume la responsabilidad de gestionar
la reunión, con su criterio de gestión, y basándose en las características del proyecto,
equipo, reunión, nº de elementos pendientes de evaluar, puede optar por:
• Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por
qué crees que es necesario tan poco tiempo? Tras escuchar las razones, repetir la estimación.
• Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado
pendientes.
• Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las
funcionalidades resultantes.
• Tomar la estimación menor, mayor, o la media.
• Este protocolo de moderación, evita en la reunión los atascos de análisis circulares en ping-pong entre diversas
opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora
de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin
discusiones, y además resulta divertido y dinamiza la reunión.
• Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por
las razones que sean, no se puede precisar una estimación. También es posible incluir otra
carta con alguna imagen alusiva, para indicar que se necesita un descanso
 Ejecución del Sprint
• Periodo fijo de tiempo durante el cual el equipo desarrolla un
incremento de funcionalidad (no mas de 30 dias)
• No se aceptan cambios a los requerimientos acordados.
• El producto es diseñado, codificado, probado durante el Sprint.
• Solo el Scrum Master puede cancelar el Sprint cuando:
– La tecnologia no funciona
– Las circunstancias del negocio cambiaron
– El equipo tuvo interferencias
• Las iteracciones cortas permiten reducir los riesgos
• Es el periodo de tiempo durante el que se desarrolla un incremento de funcionalidad.
Constituye el núcleo de Scrum, que divide de esta forma el desarrollo de un proyecto en
un conjunto de pequeñas “carreras”.
• Duración máxima: 30 días.
• Durante el sprint no se puede modificar el trabajo que se ha acordado en el Backlog.
• Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede hacer el Scrum
Master si decide que no es viable por alguna de las razones siguientes:
– La tecnología acordada no funciona.
– Las circunstancias del negocio han cambiado.
– El equipo ha tenido interferencias.
• Diariamente se realiza una reunión diaria llamada Daily Scrum, y al final del Sprint, se
realiza una reunión de revisión de Sprint, llamada Sprint Review
 Fin del sprint: Sprint review
• Reunión donde se presenta al product owner y a los implicados todas las funcionalidades implementadas.
• Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente
– Informal
– Duracion de 4 horas. Regla de 2 hs preparación.
– No usar diapositivas
– Todo el equipo participa
– Se invita a todo el mundo
• El Product owner trata con los asistentes y con el team las posibles modificaciones en la pila de producto.
• Al final de la reunión se interroga individualmente a todos los asistentes para
recabar impresiones, sugerencias de cambio y mejora, y su relevancia.
• Después del  Sprint review y antes de la proxima Sprint planning meeting,
el ScrumMaster convoca a una Sprint retrospective del Sprint con el Team.
• Objetivo:
– Presentar el Product Owner y demas involucrados del proyecto el trabajo realizado (incremento del producto) durante el Sprint.
• Participan:
– Equipo, Scrum Master, Product Owner, todas las personas involucradas en el proyecto.
• Reglas:
– El Equipo no invierte mas de una hora en preparar el Sprint Review
– Las funcionalidades no finalizadas completamente no se presentan
– Los miembros del equipo presentan las funcionalidades
– Las demostraciones se realizn en el equipamiento de los miembros del equipo
– Al finalizar la reunion se piden opiniones a los participantes, los cuales pueden sugerir cambios y mejoras.
• Al finalizar:
– El Product Owner decide si la funcionalidad presentada cumple con los objetivos del Sprint
– Se actualiza y vuelve a priorizar el Product Backlog
– El Scrum Master anuncia el lugar y la fecha de la proxima revision del Sprint.
 Sprint retrospective
• Periódicamente, se echa un vistazo a lo que funciona y lo que no.
• Normalmente 30 a 90 minutos
• Se realiza luego de cada sprint
• Todo el equipo participa: ScrumMaster, Product owner, Equipo, Posiblemente
clientes y otros
• El ScrumMaster hace que el Team  revise, su proceso de desarrollo Scrum, para
hacerlo más eficaz y eficiente para el próximo Sprint.
• El ScrumMaster no proporciona respuestas, sino que ayuda al equipo a encontrar
la mejor forma de trabajar con Scrum.
• En conjunto, Sprint planning meeting, Daily Scrum, Sprint review, y el Sprint
retrospective, constituyen la inspección empírica y prácticas de la adaptación del
Scrum.
• Objetivo:
– Identificar que cosas se pueden cambiar para hacer el trabajo mas agradable y productivo en las proximas iteraciones.
– Se realiza al finalizar el Sprint
• Participan:
– Team, Scrum Master, Product Manager (opcional)
• Reglas:
– Dos preguntas que todos deben responder:
• Que cosas hicimos bien?
• En que cosas podemos mejorar?
– Todo aquello que afecte como el equipo construye se debe debatir.
– Permite al equipo evolucionar continuamente mejorando durante el proyecto.
• Al finalizar:
– Lista de oportunidades de mejora.
 Daily Scrum (Comenzar / Parar / Continuar)
• Breve reunión diaria para repasar cada una de las tareas y el trabajo previsto de la jornada.
Dura 15 minutos
• Sólo interviene el equipo de desarrollo
• No para la solución de problemas. No es dar un reporte de estado al Scrum Master, se trata
de compromisos delante de pares
– Todo el mundo está invitado
– Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar
– Ayuda a evitar otras reuniones innecesarias
• Cada miembro responde a tres questiones: Trabajo realizado desde la reunión anterior,
Trabajo que se va a realizar hasta la próxima reunión de seguimiento, Problemas que se deben
solucionar para realizar el trabajo propuesto
• Todo el equipo se reúne y discute lo que les gustaría: Comenzar a hacer, Dejar de hacer,
Continuar haciendo
 Incremento
• Demostración de los objetivos alcanzados en cada sprint
• Asistencia de todos los roles, “Product Owner” e incluso usuarios
• Sólo el Scrum Master puede abortar un Sprint debido a una de las
siguientes razones:
– La tecnología seleccionada no funciona o es incompatible con los objetivos
definidos
– Han cambiado las circunstancias de negocio
– El Scrum Team ha tenido inferencias
 Prácticas para la gestión del proyecto
• Revisión de las iteraciones: al final de cada sprint
• Desarrollo incremental: Al final de cada sprint debe haber una parte del
producto operativa que se pueda inspeccionar y evaluar
• Desarrollo evolutivo: No se define la estructura final, la arquitectura o el diseño
final del producto ya que los requisitos son cambiantes. Se utilizan técnicas de
refactorización en las fases de diseño y codificación
• Auto-organización: Los equipos son auto-organizados con márgenes de decisión
suficientes para tomar las decisiones que se consideren oportunas en los
sucesitos sprint
• Colaboración: Se apuesta por una colaboración abierta entre todos los
integrantes según sus conocimientos y capacidades, no según su rol o puesto.
• Veremos como estructurar un proyecto ágil …
• Estudio de viabilidad y de negocio. Las dos primeras fases son secuenciales.
– Estudio de viabilidad:
• Calcular los costes
• Ver si es técnicamente viable
• Asegurarse de que DSDM sea el enfoque adecuado
– Estudio de negocio:
• Modelado del proceso del negocio
• Fuerte colaboración cliente-equipo de desarrollo.
• Iteración funcional del modelo e Iteración de diseño y construcción:
– Iteración funcional del modelo:
• Refinar aspectos funcionales del negocio.
– Iteración de diseño y construcción:
• El producto se vuelve apto para los usuarios.
 – Las dos fases consisten en ciclos de 4 actividades:
• Identificación
• Planificación
• Producción
• Validación
• Implementación:
– Implementación, entrenamiento, revisión y aceptación de usuarios y revisión del negocio.
– Al final puede ocurrir:
• Falta una parte técnica
– Iteración de diseño y construcción
• Se ha descubierto una nueva funcionalidad
– Estudio del negocio
• Falta una funcionalidad secundaria
– Iteración funcional del modelo
• Todos los requerimientos cumplidos
– Fin
• Control empírico: interactivo e incremental
Participación del cliente, Hacer entregas cortas y regulares del
transparencia para que pueda guiar producto final (2-4s) para obtener feedback e
de manera regular los resultados del irse acercando a las expectativas del cliente.
proyecto.

ntal
me
re
i nc
o e
rativ
Cliente Ite
l
radi ciona
T
Equipo
• La planificación ágil parte de
la idea de planificar en
función de objetivos de
negocio en lugar de tareas (a
diferencia de la planificación
tradicional), priorizando los
que aportan más valor, y
esperando a dar detalle a
objetivos y tareas conforme
se va acercando el momento
de construcción de estos
objetivos, cuando la
indeterminación se va
reduciendo, de manera que
se amortiza el esfuerzo de
planificar de manera
detallada.
• La planificación ágil toma
como base el 
control empírico de la
construcción de producto
(inspección y adaptación)
• Priorización por valor de negocio
Proporcionar resultados Orientar el proyecto a objetivos para el cliente, no a
anticipados (“time to tareas, priorizando según el valor de negocio vs
market”) esfuerzo y riesgo.

                  

Cliente Entregas de los

objetivos más Entrega final
importantes
Equipo
• Herramientas: Gráfico Burn-Up. Utilizado por el Product Owner. Muestra: las versiones
previstas de un producto, funcionalidades de cada una de ellas, velocidad estimada, fechas
probables para cada versión, margen de error previsto en las estimaciones, y avance real
• Herramientas: Gráfico Burn-Down. Utilizado por el Scrum Team para
seguimiento del trabajo de cada Sprint
• Pruebas
– Test Driven Development
• Diseño e implementación de las pruebas antes de programar la funcionalidad
• El programador crea sus propios tests de unidad
– Integración continua (Integración diaria, Disponer de una máquina para integración)
– Tests funcionales (Cliente)
• Semana de 40 horas
– El desarrollo de software es un ejercicio creativo
• hay que estar fresco y descansado
– Sin “héroes”
– Se reduce la rotación de personal
– Mejora la calidad del producto
– Se permiten excepciones, con cuidado
• más de una semana de horas extra: problema
• Propiedad colectiva del código
– Cualquier integrante del grupo tiene autoridad para cambiar cualquier parte del código fuente
– Todos son dueños del código
– Siempre se utilizan estándares
– Los tests siempre deben funcionar al 100%
– Se integra con todo el sistema permanentemente
– Manejo de configuración
• Diseño simple, entregas pequeñas
– Se debe mantener el diseño lo mas simple posible (YAGNI): “No vas a necesitarlo”
– Tarjetas CRC
– Design for change vs Design for today
• Características útiles en términos del negocio
• No implementar características que no son necesarias
– Poner en producción lo antes posible
– Unas pocas semanas por entrega
• Refactorización
– Si el código se está volviendo complicado
• modificar el diseño, volver a uno más simple
– Refactoring: modificar la forma del código sin cambiar su funcionamiento
• Ejemplos: extraer método, renombrar (clase, método, variable, etc.), reemplazar
– Hay herramientas
• C#Refactory (Xtreme Simplicity)
• Conciliar el enfoque ágil y contratos de precio fijo. Es posible ofrecer al Cliente: a) cambio de
alcance dinámico gratis, b) generación de valor y c) riesgo compartido (evitando juego de suma
cero). Simultáneamente, la organización mejora su flujo de caja, contiene sobre costos y el disparo
del alcance.
– Aceptar cambios, de la siguiente forma
• Sobre lo no desarrollado, de lo contrario tiene costo
• Sobre lo no desarrollado, substituir requerimientos registrados por los nuevos, que tengan una
estimación de esfuerzo similar, o de lo contrario tiene costo
– Aplicar tarifas diferenciales
• Aplicable por cumplimiento de cronograma: 100%
• Aplicable por incumplimiento de cronograma: 90%
• Aplicable por mejora de cronograma: 115%
– Permitir la cancelación anticipada
• Penalidad del +20% luego de que el 85% del proyecto sea entregado.
• Luego de que avance el proyectos, y se podrá re estimar los sub entregables en base a cambios,
riesgos descubiertos.
– Armado y entrega de paquete por funcionalidad
• Descomponer SOW en sub entregables, y pagar por paquete
• Considerar fijar dos alcances: a) prueba de concepto, al que se le aplica un metodología ágil y b)
desarrollo, el que se realiza de forma también ágil o a través de un contrato fijo.
• Dividir las historias
– Datos
– Casos especiales
– Operaciones (ABM “Altas, Bajas y Mantenimiento” o CRUD “Crear, Leer, Actualizar y Borrar”)
– Temas transversales y no funcionales: seguridad, log, manejo de errores, performance, volumen
– Prioridad
• No dividir
– Por debajo de 2/5 días
– En tareas
– Y no agregar trabajo no priorizado…
• Sprint 0, permite identificar los objetivos y reducir la incertidumbre respecto al alcance,
definir viabilidad, o plataforma tecnológica. El objetivo último es obtener una visión clara de:
– Qué queremos implementar, en forma de Product Backlog y prototipos.
– Cómo lo queremos implementar, en forma de Arquitectura técnica.
– Y cuánto (tiempo y dinero) aproximadamente nos va a costar llegar a cada una de las posibles fases
principales de la implementación del proyecto.
Dentro de ese Product Backlog es habitual encontrar clasificadas las Épicas en estos tres grupos:
MVP (Producto Mínimo Viable), MMP (Producto Mínimo Comercializable) y Funcionalidades futuras.
Evidentemente, las Épicas de los dos primeros grupos se habrán descompuesto en Historias de Usuario y
se habrá estimado su complejidad lo que ha permitido priorizarlas, apoyadas además por Prototipos y
Propuesta Gráfica (desde el punto de vista de Usabilidad) y por una Arquitectura propuesta e,
incluso, Pruebas de Concepto de aquellos elementos tecnológicos más innovadores.
Pero, dado que en este punto ya se tiene una orientación de alcance (MVP y MMP) lo que permite a
“Negocio” obtener una visión muy aproximada de cuál será el resultado del proyecto, también es posible
minimizar las inquietudes tanto de la Gerencia (orientación en cuanto a Costes y Plazos), como de los
equipos de Tecnología (cuándo se estima que deberán estar disponibles los entornos y equipos que
sustenten el nuevo producto, qué personas formarán el equipo, que recursos harán falta, qué nuevos
productos o frameworks se introducen en el ecosistema a mantener, etc).
 Prácticas para la gestión del producto
• Técnica para entender y planear una entrega incremental de MVPs. La técnica organiza ideas y
recursos en un modelo que busca entender la finalidad principal del producto, considerando las
jornadas de los usuario para realizar las entregas incrementales de productos viables. Como un
libro de recetas, con una secuencia de actividades, rápidas y eficaces, la técnica va a permitir que el
equipo:
– Describa la visión del producto. El producto Es - No es - Hace - No hace
– Priorize los objetivos del producto. Entendiendo los trade-offs.
– Describa los principales usuarios, sus perfiles y sus necesidades
– Entienda las principales funcionalidades
– Comprenda los niveles de incertidumbre, esfuerzo y valor de negocio por
uncionalidad
– Describa las jornadas más importantes de los usuarios
– Cree un plan de entrega incremental del producto, impulsado
por el concepto de MVP
– Estime el esfuerzo por muestreo
– Calcule los costos y especifique fechas en el cronograma de entrega
22:52 69
• El Canvas MVP
– Es una herramienta para validar ideas de productos. Es un marco visual que ayuda a los empresarios
para alinear y ajustar la estrategia del MVP (Minimum Viable Product, en inglés). Se divide en siete
bloques:
• MVP Visión general – ¿Cuál es la visión de este MVP?
• Métricas para validar el modelo de negocio – ¿Cómo podemos medir los resultados de este MVP?
• Resultado esperado – ¿Qué esperamos como aprendizaje o resultado de este MVP?
• Características – ¿Qué vamos a construir en este MVP? ¿Qué acciones se simplificarán / mejorarán en este MVP?
• Personas y Plataformas – ¿Para quién es el MVP? ¿En qué plataforma estará disponible?
• Historias – ¿Qué historias se cumplen o mejoran con este MVP?
• Costo y horario – ¿Cuál es el costo y la fecha prevista para la entrega de este MVP?
– Al usar el Canvas MVP, ​ponemos los dos bucles uno al lado del otro. De “Lean startup”, el bucle de
construir-medir-aprender. Del Design Thinking, el bucle de usuario-journey-acción. En ambos bucles,
la respuesta a qué construir: las funcionalidades del MVP.

22:52 70
• Cuando una composición de funcionalidades alcanza una versión simple del producto que podría estar
disponible? Usted debe planear una secuencia de ondas para agrupar las funcionalidades de manera que lo ayude
a organizar la producción, considerando limites de funcionalidad, nivel de riesgo, esfuerzo y valor de negocio.
• El MVP debe de ser factible, usable, valioso. El Canvas MVP, permite validar ideas de productos. Es un marco
visual que relaciona dos bucles. De “Lean startup”, el bucle de construir-medir-aprender. Del Design Thinking, el
bucle de usuario-journey-acción. En ambos bucles, la respuesta a qué construir: las funcionalidades del MVP.
Personas y plataformas Visión de MVP Resultado Esperado
Usuario Aprender
 
  Funcionalidad
Usuario Acción Construir Aprende
r

 
Experiencia  
Medir
  
 
Jornadas de usuario Costo y Cronograma de Métrica (validación hipótesis)
Entrega
22:52 71
 Proceso de desarrollo del producto por etapas
Evaluación de Valida ideas, planifica y Desarrollo Evaluación y pruebas Lanzamiento
conceptos especifica

Prospección. Construir el modelo Desarrollo Pruebas y validación. Lanzamiento.

Investigación de negocio. Establece el Se efectúa una Como inicio de la
preliminar de cada Mediante una diseño y prueba extensa del producción y
uno de los proyectos investigación minuciosa desarrollo de nuevo producto en el comercialización se
o ideas generados en por parte de los equipos nuevo producto y mercado, en el establecen revisiones
la fase de técnicos y comerciales el plan de laboratorio, o en la periódicas de post –
descubrimiento y se definiendo y justificando producción y planta. lanzamiento.
selecciona un el producto desarrollando lanzamiento al
subconjunto de ellos. el plan de proyecto. mercado.

Visión Producto e Fundación Estructura del MVP MMP

EPICs técnica/negocio. proyecto. Funciones básicas y Retorno primario.
Experiencia del usuario. validación UX. Mejoras dirigidas por
Priorización de funciones. Supuestos validados. la visión del usuario.
  UAT. Adopción continúa.
 Infraestructura requerida
• Plataforma para la implementación de tableros KAMBAN, fomentar el
trabajo colaborativo, gestión de incidencias y automatización de QA/QC.
• Lugar de trabajo
– Sala amplia (mejor, sin divisiones)
• Centro: pares de programadores
• Periferia: máquinas individuales
– Ventajas del espacio abierto:
• Mayor comunicación
• Agenda dinámica
• Cliente en el sitio
– Interacción continua
– No siempre se consigue
• muy junior, no sirve
• muy senior, no quiere
– Actualmente se pide un “analista”
 Fortalezas de SCRUM
Gestión regular de expectativas del cliente
Resultados anticipados (“time to market”)
Flexibilidad y adaptación
Retorno de inversión (ROI)
Mitigación de riesgos
Productividad de calidad
Alineamiento entre cliente y equipo
Equipo motivado
Priorización de requisitos
Demostración del proyecto en cada Sprint
Priorización de requisitos por valor/coste
Re planificación en el inicio de cada iteración
Priorización de requisitos
Desarrollo iterativo e incremental
Mejora continua
Comunicación diaria del equipo
TimeBoxing
Equipo multidisciplinar
Estimación de esfuerzo conjunta
Compromiso del equipo
Demostración de resultados
Reuniones en cada itinerario (Sprint)
Equipo autosugestionado
Reuniones diarias y en cada Sprint
 Reflexiones
• Highsmith & Cockburn 2001
– “lo que es nuevo en los procesos ágiles no son las prácticas que usan, sino que
reconozcan a las personas como primeros implicados en el éxito de un proyecto,
además de un intenso foco en la efectividad y la manejabilidad. Esto genera una
nueva combinación de valores y principios que definen una visión ágil del mundo.”
• Hawrysh & Ruprecht 2000
– Una sola metodología no puede funcionar para todo el espectro de proyectos, en vez
de eso el administrador de cada proyecto debería identificar la naturaleza especifica
de cada proyecto y seleccionar la mejor metodología de desarrollo aplicable.
• McCauley 2001
– Hay una necesidad de ambos métodos [ágiles y orientados a procesos] ya que no hay
un modelo de desarrollo que se ajuste a todos los propósitos imaginables.
• El equipo se reune para estimar el coste de cada historia de la
pila de producto.
• En este caso utilizan Planning Poker.

Equipo
• El cliente, una vez aprobado el presupuesto, reordena la pila de producto
para que el equipo vaya trabajando según la prioridad del cliente.
Menos imporantes

Cliente

Urgentes
• El equipo comienza su trabajo desglosando la primera historia de la pila de
producto, la cual subdividen en tareas menores para crear la pila de sprint.
• La pila de sprint tiene como utilidad fraccionar el trabajo de un periodo de
15 días en tareas mas pequeñas, que tarden como mucho dos días.
• Estas tareas se colocan en una pila, la cual prioriza el Dueño de Producto,
que ha consultado con el cliente, antes de comenzar el sprint.
Menos imporantes

Dueño de Producto

Urgentes
• El equipo comienza el sprint tomando las tareas priorizadas.
• Una vez concluida una se toma la siguiente de la lista.
• Se convoca todos los días una reunión del equipo donde se cuenta las tareas realizadas el día
anterior y cuales se van a realizar ese día.
• Una vez finalizado el sprint, el Dueño de Producto le muestra al cliente el
resultado del trabajo realizado.
• El cliente ya tiene el primer contacto con su encargo y además puede
volver a priorizar la pila de producto antes de que comience otro sprint.

Buen trabajo

Dueño de Producto Cliente

• El equipo de trabajo celebra su buen hacer con una reunión de
retrospectiva, donde se analiza lo ocurrido durante el sprint.