Metodologias desarrollo Agiles

Introducción
 Buenas prácticas para trabajar colaborativamente.
 Se realizan entregar parciales y regulares del
producto final.
 Indicado para proyectos en entornos complejos,
donde se necesita obtener resultados pronto,
donde los requisitos son cambiantes o poco
definidos, donde la innovación, la competitividad,
la flexibilidad y la productividad son fundamentales.
 Que es agilidad
Conjunto de valores, principios y prácticas para el desarrollo de
proyectos, también llamados métodos ágiles o metodologías ágiles.
Su prioridad es la entrega de valor al cliente y/o organización, de forma
incremental .
Algunos métodos son más prescriptivos que otros .
Todos los métodos están alineados alrededor de los valores comunes.
Todos los métodos se basan en la interacción de las personas .
Todos los métodos ágiles están fundamentados en el Manifestó Ágil .
Más que una metodología, es una forma de pensar y actuar (mindset).
Que es agilidad
El manifiesto Ágil surge el 17 de febrero del 2001, cuando se reunieron diecisiete
críticos del desarrollo de software, y acuñaron el término “metodología Ágil”
para definir a los métodos que estaban surgiendo como alternativa a las
metodologías formales.
El manifiesto Ágil está conformado por 12 principios asociados a 4 aspectos o
pilares.
Se trabaja con mayor velocidad y eficiencia. En las metodologías ágiles se
trabaja realizando entregas parciales pero funcionales del producto. De ese
modo, es posible entregar en el menor intervalo de tiempo mayor valor.
 Que es agilidad
El enfoque ágil ataca el problema desde otra dirección; el punto de partida es el Tiempo y
el Costo: Cuánto dinero se quiere invertir durante cuento tiempo? Esto da como resultado
un equipo durante una tiempo predeterminado, y el compromiso de entregar la mayor
cantidad de software funcionando posible.
 Un Costo fijo: El equipo en sí (horas de trabajo).
 Un Tiempo fijo: Time boxes, iteraciones, releases.
 Un Alcance variable: El alcance es el lado variable del triángulo, los cuales inyectado
iteración tras iteración y transformado en requerimientos funcionando.
Que es un proyecto exitoso
Que es un proyecto exitoso
POR QUE METODOLOGIAS
AGILES?
El 80% de todos los proyectos emplearán
Métodos Ágiles en los próximos años (Gartner)
Proyectos que usan metodologías Ágiles son
mas exitosos que los proyectos que usan
metodologías en cascada (Standish Group
2010)
Valores agiles
1. Individuos e interacciones sobre
procesos y herramientas.
2. Software (producto) que funciona sobre
documentación exhaustiva.
3. Colaboración con el cliente sobre
negociación de contratos.
4. Responder al cambio sobre seguimiento
a un plan.
 12 PRINCIPIOS AGILES
1. Satisfacción del cliente. Es la base de todo. Se alcanza a través de la entrega de
productos de valor que cubran una necesidad. La principal prioridad es satisfacer
al cliente a través de la entrega temprana y continua de software de valor.

2. Bienvenidos los nuevos requisitos. Son bienvenidos los requisitos cambiantes,

incluso si llegan tarde al desarrollo. Cambiar sobre la marcha no es dar un paso
atrás. Cualquier sugerencia o solución es bienvenida si se trata de mejorar el
producto. Los procesos ágiles se doblegan al cambio como ventaja competitiva
para el cliente.

3. Entregas por semanas. La división del trabajo en fases productivas es la base de

la metodología. En lo posible, ejecutar una cada semana. Entregar con
frecuencia software que funcione, en periodos de un par de semanas hasta un
par de meses, con preferencia en los periodos breves
 12 PRINCIPIOS AGILES
4. Es posible medir el progreso. La evolución de los procesos no es un elemento
subjetivo. Se puede medir con indicadores concretos. Las personas del negocio y
los desarrolladores deben trabajar juntos de forma cotidiana a través del
proyecto.

5. Desarrollo sostenible. La forma de ejecutar los proyectos debe garantizar en sí

misma su continuidad. No es una cuestión de hacer por hacer.

6. Trabajo cercano. Los líderes de los proyectos deben ejercer su labor en el mismo
terreno donde tienen lugar las tareas y no desde los despachos.

7. Conversación cara a cara. El gestor responsable debe comunicar de forma eficaz

sus mensajes, mejor si se hace de forma presencial. Se recomiendan reuniones
periódicas tanto con el cliente como con sus colaboradores. La forma más
eficiente y efectiva de comunicar información de ida y vuelta dentro de un
equipo de desarrollo es mediante la conversación cara a cara.
 12 PRINCIPIOS AGILES
8. Motivación y confianza. Los procesos sólo tendrán éxito si quienes los llevan a cabo son
personas motivadas y que interactúan en climas de confianza y solidaridad.
9. Excelencia técnica y buen diseño. Las formas nunca deben perderse, así como tampoco la
calidad del trabajo. Todo es un conjunto. La atención continua a la excelencia técnica
enaltece la agilidad.
10. Simplicidad. Las tareas han de ser lo más sencillas posible. Si alguna no puede ser
ejecutada en esos términos, debe ser dividida en iteraciones hasta que se reduzca su nivel
de complejidad. La simplicidad como arte de maximizar la cantidad de trabajo que se hace,
es esencial.
11. Autogestión de los equipos. Si bien debe existir una figura que monitorice los equipos de
trabajo , éstos deben ser capaces de organizarse por sí mismos. El exceso de jerarquías crea
dependencia entre los colaboradores. Las mejores arquitecturas, requisitos y diseños
emergen de equipos que se autoorganizan.
12. Adaptación circunstancias cambiantes. Los proyectos no suelen terminar de la misma
forma en que empezaron. Es indispensable que quienes los ejecutan puedan adaptarse a
las distintas circunstancias que puedan surgir. En intervalos regulares, el equipo reflexiona
sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.
 VALORES DE INTERDEPENDENCIA
La Declaración de interdependencia en la gestión de proyectos fue escrita a principios del
2005 por un grupo de 15 líderes de proyectos como un suplemento al “Manifiesto Ágil”.

1. Aumentamos el retorno de inversión, al enfocarnos en el flujo continuo de valor.

2. Ofrecemos resultados fiables mediante la participación del cliente en las iteraciones
frecuentes, donde también son responsables por el trabajo.
3. Asumimos que habrá incertidumbre y las superamos a través de iteraciones, anticipación
y adaptación.
4. Damos rienda suelta a la creatividad y la innovación al reconocer que las personas son la
fuente máxima de valor y creamos un entorno en el que puedan tener un impacto
positivo.
5. Aumentamos el rendimiento a través de la rendición de cuentas por parte del grupo en
cuestión de resultados y eficacia del equipo, responsabilidades que todos comparten.
6. Mejoramos la eficacia y la fiabilidad a través de estrategias situacionalmente específicas,
procesos y prácticas.
 EQUIPOS AGILES. CARACTERISTICAS
• Autónomo y multidisciplinario.
• Tamaño de equipo de 3 a 9 personas.
• Estable y dedicado.
• Se auto-organizan, tienen responsabilidad compartida y piensan juntos.
• Están motivados.
• Están sentados juntos.
• Interaccionan con Stakeholders(Interesados).
 Manifiesto ágil
• Valoramos más a los individuos y su interacción que a
los procesos y las herramientas.
• Valoramos más el software que funciona que la
documentación exhaustiva.
• Valoramos más la colaboración con el cliente que la
negociación contractual.
• Valoramos más la respuesta al cambio que el
seguimiento de un plan
 Equipos ágiles - Valores:
Coraje
 El equipo debe tener coraje para hacer lo correcto. 
 Hay que tener coraje para ser capaz de desarrollar el producto sin
mirar al futuro más de lo necesario, centrándose en lo que sabemos
que es importante ahora, en lugar de en lo que podría (o no) ser
importante en el futuro.
 El equipo debe tener coraje para resolver los impedimentos
 El equipo debe tener coraje para mejorar la aplicación de Scrum
 Foco
 El enemigo número uno de la productividad es la multitarea, la
dispersión y la falta de concreción en los objetivos que se pretenden
alcanzar.
 Scrum proclama que todos los miembros del equipo deben enfocarse
en el trabajo planificado.
 El equipo debe enfocarse en lo que es más importante ahora, sin
preocuparse en exceso por el futuro, que puede ser muy incierto y
cambiante. 
 El equipo no debe dedicar tiempo a tareas que puede que no sean necesarias
en el futuro, eso sería tirar tiempo y dinero a la basura
Compromiso
 Cada miembro del equipo Scrum  hará el máximo esfuerzo
posible y será completamente transparente sobre el
progreso del proyecto.
 Compromiso significa dedicación y se refiere a las acciones
y el esfuerzo, no al resultado final.
 Respeto
 Los miembros de un equipo Scrum respetan el conocimiento,
habilidades y experiencia profesional no solo del resto de miembros
del equipo, sino también de aquellas personas con las que se
relacionan, sean de su propia organización o de otra.
 Los miembros de un equipo Scrum se respetan entre ellos
compartiendo información, fomentando un espíritu colaborador,
aprendiendo y tomando decisiones juntos.
 Los miembros de un equipo Scrum se respetan entre ellos
comprendiendo sus roles Scrum y la responsabilidad de cada uno
dentro del equipo.
Apertura - Franqueza

 Scrum defiende la transparencia como un pilar básico del empirismo

sobre el que se sustenta. 
 Sin transparencia es imposible llevar a cabo la Inspección y la
Adaptación.
 El equipo de desarrollo debe ser transparente con el trabajo que
realiza, con el progreso del mismo, y con el conocimiento que
adquiere (documentación)
 Todos los miembros del equipo deben facilitar la transparencia en las
comunicaciones y la compartición de información que facilite la
colaboración dentro y fuera del equipo.
Proactividad
 Ser responsable de nuestras decisiones.
 Nuestro comportamiento depende de nuestras
decisiones, no de las condiciones
 QUÉ ES SPRINT?
El corazón de Scrum es un Sprint, es un intervalo prefijado
durante el cual se crea un incremento de producto utilizable,
potencialmente entregable. A lo largo del desarrollo hay
Sprints consecutivos de duración constante.

Cada Sprint se puede considerar un mini-proyecto de no más

de un mes. Al igual que los proyectos, los Sprint se utilizan
para lograr algo. Cada Sprint cuenta con una definición de lo
que se va a construir, un diseño y un plan flexible que guiará
la construcción del plan, el trabajo, y el producto resultante.
RADIADORES DE INFORMACION
Colaboración y comunicación continua con el cliente de modo que en
todo momento conozca la situación actual del equipo y del proyecto.
Es una serie de información colocada estratégicamente en un lugar de
paso para que cualquiera que pase cerca del equipo pueda ver en un
vistazo la situación de su trabajo sin preguntar al equipo directamente.
Historias de usuario
• Son pequeñas descripciones de los requerimientos de un cliente.
• Al redactar las historias de usuario se debe tener en cuenta describir el
Rol, la funcionalidad y el resultado esperado en una frase corta.
• Debe venir acompañada (al reverso) de los criterios de aceptación,
hasta un máximo de 4 por historia, redactado también en una frase
que indique el contexto, el evento y el comportamiento esperado ante
ese evento.
• Es deseable que las historias de usuario sean escritas por el usuario, en
una frase corta.
• Debe describir el rol desempeñado por el usuario de forma explícita e
indicar el beneficio para el área de negocio que representa esta
funcionalidad. 
HISTORIAS DE USUARIO
Es un instrumento que describe una funcionalidad de algún producto o software
que es útil para un usuario. Ellas especifican la funcionalidad que será
desarrollada, pero no cómo se desarrollará. Generalmente usamos post-it para
escribirlas y compartirlas entre el equipo.
Modelo INVEST:
"I" ndependent (Independiente)
"N" egotiable (Negociable)
"V" aluable (Valiosa)
"E" stimable (Estimable)
"S" mall (Pequeña)
"T" estable (Comprobable)

|j
HISTORIAS DE USUARIO
Generalmente para elaborar las historias de usuarios se utiliza el siguiente formato, el
cual incluye el Rol del usuario que la solicita, la funcionalidad que requiere y el beneficio
que obtendría si la misma se desarrolla.

Yo como <Tipo de Usuario>,

necesito/quiero o deseo <Descripción de objetivo o funcionalidad>,
con la finalidad de <Consecuencia o beneficio>

Ejemplo: Como Vendedor, quiero registrar los productos y cantidades que me solicita un

cliente para crear un pedido de venta.
Historias de usuario

Como comprador de la tienda online quiero ordenar por precio los

productos para escoger el gel más barato y comparar bien calidad/precio
Historias de usuario
 Historias de usuario
• Descripción de una funcionalidad que debe incorporar un sistema de
software, y cuya implementación aporta valor al cliente.
• La estructura de una historia de usuario está formada por:
• Nombre breve y descriptivo.
• Descripción de la funcionalidad en forma de diálogo o monólogo del
usuario describiendo la funcionalidad que desea realizar.
• Criterio de validación y verificación que determinará para considerar
terminado y aceptable por el cliente el desarrollo de la funcionalidad
descrita.
• Y adicionalmente por la información que resulte necesaria por el
modelo de implementación: Prioridad, Riesgo, Tamaño, etc.
Historias de usuario
Historias de usuario
EPICAS
Es una historia de usuario que es
demasiado grande para caber en un
sprint. A menudo, éste término se utiliza
para describir una gran historia de usuario
que tendrá que ser dividido en historias
más pequeñas.
 Tareas
Unidad de trabajo gestionada por los miembros del Development Team
(DT). Una tarea tiene asignada una persona para su realización, y es
recomendable que el esfuerzo para llevarla a cabo sea como máximo el
equivalente a una jornada de trabajo.

Características modelo SMART:

• S: Specific (Especifico)
• M: Measurable (Medible)
• A: Achievable (Alcanzable)
• R: Relevant (Relevante)
• T: Time-boxed (Tiempo-caja)
PRODUCT BACKLOG
El product backlog (o pila de producto) es un listado
de todas las tareas que se pretenden hacer durante el
desarrollo de un proyecto.
Todas las tareas deben listarse en el product backlog,
para que estén visibles ante todo el equipo y se pueda
tener una visión panorámica de todo lo que se espera
realizar. El 20% de los requisitos brinda el 80% del
valor (Pareto).
Sprint BACKLOG
Lista de pendientes del sprint, es el conjunto de
tareas seleccionadas del product backlog durante
el sprint planning para el Sprint actual, es decir, las
tareas necesarias para realizar un incremento de
producto.
El sprint backlog, es una imagen «en tiempo real»
del trabajo que se planea realizar durante el
Sprint, es un plan que hace visible todo el trabajo
que el equipo de desarrollo identifica como
necesario para cumplir con el objetivo del Sprint.
Time Boxing
Todos los eventos son bloques de tiempo (time-
boxes), de tal modo que todos tienen una
duración máxima.
Una vez que comienza un Sprint, su duración es
fija y no puede acortarse o alargarse. Los demás
eventos pueden terminar siempre que se
alcance el objetivo del evento, asegurando que
se emplee una cantidad apropiada de tiempo sin
permitir desperdicio en el proceso.
 Scrum
Es un proceso en el que se aplica un conjunto de buenas prácticas para
trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto.
Se realizan entregas parciales y regulares del producto final, priorizadas
por el beneficio que aportan al receptor del proyecto, está
especialmente indicado para proyectos en entornos complejos, donde se
necesita obtener resultados pronto, donde los requisitos son cambiantes
o poco definidos, donde la innovación, la competitividad, la flexibilidad y
la productividad son fundamentales.
 Scrum también se utiliza:
• Para resolver situaciones en que no se está entregando al
cliente lo que necesita,
• Cuando las entregas se alargan demasiado, 
• Los costes se disparan o la calidad no es aceptable,
• Cuando se necesita capacidad de reacción ante la
competencia,
• Cuando la moral de los equipos es baja y la rotación alta,
• Cuando es necesario identificar y solucionar ineficiencias
sistemáticamente 
• Cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto.
PILARES SCRUM
Conocer los valores y principios de Scrum es mucho más importante que
seguir ciegamente la mecánica de Scrum, cuando falta ese conocimiento.
Sí las cosas se ponen difíciles, o surgen dudas, siempre debe volverse a
los valores.
 Principios SCRUM

Confianza
Colaboración
Responsabilidad
Excelencia Técnica
Empirismo
REUNIONES O CEREMONIAS
SCRUM
Planificación del Sprint o Sprint Planning
• La planificación del sprint, tiene lugar al comienzo de cada
sprint. Para ello se reune al equipo scrum al completo, y los
integrantes deben ponerse de acuerdo sobre el trabajo a
realizar durante el sprint. El Product Owner selecciona y
prioriza los elementos más importantes del Product Backlog,
explicando cada uno de los elementos seleccionados y su
importancia al equipo Scrum.
 CEREMONIAS SCRUM
Reuniones Scrum Diarias o Daily Meetings
• El también conocido como Daily Stand-Up, requiere también de la presencia del
equipo scrum al completo, se reunirán durante nunca más de 15 minutos. Se alienta
al equipo a reunirse de pie, para que la reunión no tarde más de lo necesario. En este
tipo de reunión se pretende informar de manera rápida al resto del equipo sobre el
progreso de cada miembro del equipo. Cada persona debe de forma concisa y
concreta responder las siguiente preguntas:
¿Qué hiciste ayer?
¿En qué trabajarás hoy?
¿Qué obstáculos han surgido?
• Estas reuniones ayudan a incrementar la responsabilidad dentro del grupo scrum, a
elevar la eficiencia, y el progreso del equipo. Además, mediante estas reuniones el
Scrum Master, puede conocer las necesidades y los obstáculos a los que se enfrenta
el equipo. Es importante que todos los miembros escuchen a los demás, y no
desviarse del tema, ni sobrepasar el tiempo máximo.
CEREMONIAS SCRUM
Sprint review
• El Sprint Review, sucede al final de cada sprint, y requiere como las
demás ceremonias, de la presencia de todo el equipo. La diferencia
radica, en que a esta ceremonia, también pueden asistir otras partes
interesadas. En esta ceremonia se comparte lo que se ha completado
durante el sprint que justo ha terminado, esto se puede compartir con
las otras partes interesadas (como puede ser el cliente o el usuario).
Este momento es especialmente importante, para recibir retro-
alimentación del cliente y del usuario, feedback, del que el Product
Owner a su vez tomará nota, para incorporarlo en el Product Backlog (y
así incoporarlo al siguiente sprint).
CEREMONIAS SCRUM
Retrospectiva
• La Retrospectiva del sprint, también tiene lugar al final de cada sprint.
Los que asisten a esta ceremonía son: el equipo de desarrollo y el Scrum
Master. El Product Owner puede atender, pero no es obligatorio. El foco
de atención de esta ceremonía es revisar la forma de trabajo del equipo
durante el sprint que acaba de finalizar. Así los miembros se dan
feedback entre sí, e intentan conjuntamente pensar en soluciones para
sobrepasar los obstáculos, y pensar en mejoras en cuanto a la forma de
trabajar. La ceremonía Retrospectiva se debería celebrar siempre al final
de cada sprint, aunque el sprint haya ido perfectamente y el equipo sea
feliz, el sprint se debe celebrar.
REUNIONES O
CEREMONIAS
Scrum emplea una serie de reuniones clave para estructurar el
trabajo del equipo:
• Sprint (2 a 4 semanas)
• Daily Standup Meeting (15 minutos).
• Sprint Planning Meeting (8 horas por un sprint de 1 mes).
• Sprint Review Meeting (4 horas por un sprint de 1 mes).
• Sprint Retrospective (3 horas por un sprint de 1 mes).
Roles
Scrum
Roles Scrum
Scrum master: Persona que lidera al equipo guiándolo para que cumpla las reglas y procesos
de la metodología. Gestiona la reducción de impedimentos del proyecto y trabaja con el
Product Owner para maximizar el ROI.
Product owner (PO): Representante de los accionistas y clientes. Se focaliza en la parte de
negocio y el es responsable del ROI del proyecto (entregar un valor superior al dinero
invertido). Traslada la visión del proyecto al equipo, formaliza las prestaciones en historias a
incorporar en el Product Backlog y las reprioriza de forma regular.
Team: Grupo de profesionales con los conocimientos técnicos necesarios y que desarrollan el
proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al inicio
de cada sprint.
Tamaño development team
• Se deben cumplir dos condiciones:
• Debe ser lo suficientemente pequeño como para seguir siendo
ágil.
• Debe ser lo suficientemente grande como para completar un
trabajo significativo dentro de un Sprint, sin otras dependencias.
• Menos de 3 miembros disminuyen la interacción y la productividad,
pudiendo surgir limitaciones de habilidades durante el Sprint, lo que se
traslada a una menor entrega de producto potencialmente acabado.
• Más de nueve miembros implica demasiada coordinación, ya que se
genera demasiada complejidad en el proceso de gestión.
STAKEHOLDERS
(INTERESADOS)
Cliente: El cliente es la persona o la organización que adquiere el producto del
proyecto, servicio o cualquier otro resultado.
Usuarios: El usuario es el individuo o la organización que utiliza directamente
el producto del proyecto, servicio, o cualquier otro resultado;
también, en algunas industrias el cliente y los usuarios puede ser lo
mismo.
Patrocinador: El patrocinador es la persona o la organización que provee re
cursos y apoyo para el proyecto, el patrocinador también es el
Stakeholder a quien todos le deben rendir cuentas al final.
Proceso Scrum
 El desarrollo se realiza de forma iterativa e incremental.
 Cada iteración, denominada Sprint, tiene una duración preestablecida
de entre 2 y 4 semanas, obteniendo como resultado una versión del
software con nuevas prestaciones listas para ser usadas.
 En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y
se añaden nuevas prestaciones priorizándose siempre aquellas que
aporten mayor valor de negocio
Proceso Scrum
proceso
Product Backlog: 
• Conjunto de requisitos denominados historias descritos en un lenguaje
no técnico y priorizados por valor de negocio, o lo que es lo mismo,
por retorno de inversión considerando su beneficio y coste.
• Los requisitos y prioridades se revisan y ajustan durante el curso del
proyecto a intervalos regulares.
Sprint Planning: 
• Reunión durante la cual  el Product Owner presenta las historias del
backlog por orden de prioridad.
• El equipo determina la cantidad de historias que puede
comprometerse a completar en ese sprint, para en una segunda parte
de la reunión, decidir y organizar cómo lo va a conseguir.
 proceso
• Sprint: Iteración de duración prefijada durante la cual el equipo trabaja
para convertir las historias del Product Backlog a las que se ha
comprometido, en una nueva versión del software totalmente
operativo.
• Sprint Backlog:  Lista de las tareas necesarias para llevar a cabo
las historias del sprint.
• Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la
que el equipo se sincroniza para trabajar de forma coordinada. Cada
miembro comenta que hizo el día anterior, que hará hoy y si hay
impedimentos.
• Demo y retrospectiva: 
• Reunión que se celebra al final del sprint y en la que el equipo
presenta las historias conseguidas mediante una demonstración
del producto.
• Posteriormente, en la retrospectiva, el equipo analiza qué se hizo
bien, qué procesos serían mejorables y discute acerca de cómo
perfeccionarlos.
SCRUM BOARD (TABLERO
SCRUM)
La lista de objetivos a completar en la iteración (Product Backlog
Items) se puede gestionar mediante un tablero o pizarra de tareas
(Scrum Taskboard) que actúa como radiador de información. (KANBAN
BOARD)
Que Woody me representa hoy?