Curso Practico Scrum

Agile Expert Certified Training
Dirección de Proyectos y Ejecución de la Estrategia

La información contenida en este documento, es propiedad intelectual de
Alpha Consultoría de Proyectos. Se ha proporcionado para el uso exclusivo
de los participantes del Curso de preparación para el Examen PMP.
Queda prohibida su reproducción o transmisión parcial o total, por ningún
medio, sin la autorización expresa y por escrito de Alpha Consultoría de
Proyectos.
El PMI ® no participó en la elaboración del presente documento y no ha

revisado la precisión de su contenido. El PMI no patrocina en ninguna forma
el presente documento y no garantiza o representa su contenido de forma
implícita o explícita. El PMI no tiene ningún interés económico en la
presente publicación, ni ha contribuido económicamente en su elaboración.
www.alpha-consultoria.com 2
Legal
La información contenida en este documento, es propiedad intelectual de Alpha Consultoría de Proyectos.

Se ha proporcionado para el uso exclusivo de los participantes de este curso.
Todo el material, definiciones y gráficas que aparecen en este material, contenidas originalmente en “A
Guide to the Project Management Body of Knowledge” (PMBOK® Guide), son reproducidas con autorización
del Project Management Institute mediante el convenio de registro de Alpha Consultoría como Registered
Education Provider (PMI R.E.P.)
El PMI ® no participó en la elaboración del presente documento y no ha revisado la precisión de su

contenido. El PMI no patrocina en ninguna forma el presente documento y no garantiza o representa su
contenido de forma implícita o explícita. El PMI no tiene ningún interés económico en la presente
publicación, ni ha contribuido económicamente en su elaboración.
Queda prohibida su reproducción o transmisión parcial o total, por ningún medio, sin la autorización expresa
y por escrito de Alpha Consultoría de Proyectos.
3
AGIL
MEDE Francisco Vaca
fvaca@alpha-consultoria.com
Estructura del curso
¿Por qué AGIL?

Mis clientes demandan:
Los resultados que damos:
Entonces Agil.
El manifiesto.
Conceptos de SCRUM
Es un contexto no una metodología.
Valores, procesos y herramientas.
Organización.
Iteraciones e incrementos.
Control.
Práctica SCRUM
Poner en práctica los conceptos básicos.
Objetivo de curso
1. Entender la filosofía ágil y sus principales prácticas.

2. Adquirir un conocimiento sobre las diversas metodologías
ágiles.
3. Tener la habilidad para comparar y elegir qué metodología
es apropiada para cada situación.
Contenido Temático
• Introducción
• Fundamentos de la “Filosofía Agile”
• Dominios de prácticas ágiles
• Scrum
• Lean kanban
• Extreme Programming (XP)
• Test-Driven Development (TDD)
• Dynamic Systems Development Method (DSDM)
• Crystal
• Feature-Driven Development (FDD)
• Comparación de metodologías ágiles
El entorno obliga a responder de manera diferente
El reloj competitivo de las empresas e instituciones se

ha adelantado.
 INDITEX transforma la industria de la moda … y H&M no puede seguirle el
paso
 APPLE tiene (¿tenía?) algunos años (meses) de ventaja … antes Nokia …
ahora Samsung … mañana ¿Huawei?
 Wal-Mart contra Amazon (Global – México)
¿Cuál es la percepción que tienes del entorno

competitivo de tu industria?
La torre con más puntos … gana.
Realizar una torre en la que se maximice la puntuación en solo 18

minutos.
 Puntos = (Base x 2) + Altura.

 Gana el equipo que logre más puntos.
 Al completar el plan se piden los materiales.
 No se permiten cambios ni ”sorpresas”.
 Se debe caer el 80% de las piezas después de seleccionar una ”pieza
clave”.
 La torre debe mantenerse durante el proceso de medición y
aceptación.
Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo formas mejores de desarrollar software

tanto por nuestra propia experiencia como ayudando a terceros.
A través de este trabajo hemos aprendido a valorar:
• Individuos e interacciones sobre procesos y herramientas.
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,

valoramos más los de la izquierda.
http://agilemanifesto.org/iso/es/principles.html
Ágil VS Tradicional
Enfoque Ágil Tradicional
Énfasis Personas Procesos
Dominio Impredecible/Exploratorio Predecible
Documentación Mínima requerida Exhaustiva
QA Centrada en el cliente Centrada en el proceso
Estilo de proceso Iterativo Lineal
Organización Auto-organizado Administrado
Intensidad de planeación Baja Alta
Perspectiva hacia el cambio Adaptabilidad Sostenibilidad
Priorización de requisitos Basado en valor al negocio Fijo en el plan del proyecto
Estilo de gestión Descentralizado Autocrático
Liderazgo Colaborativo, servicial Comando y control
Medición del desempeño Valor al negocio Conformidad con el plan
Retorno de la Inversión Desde temprano en el proyecto Al final del proyecto
Distintos contextos Ágiles
SCRUM
EXTREME
KANBAN
PROGRAMMING
FDD CRYSTAL
LEAN
DSDM
DEVELOPMENT
AGILE UP OPEN UP
Principios Agiles
Principio 1. Control de Procesos Empíricos
• Scrum propone gestionar proyectos a través de la toma de decisiones basada en la
observación y experimentación.
• Sólo hay dos maneras de controlar cualquier proceso. A través de procesos definidos y a
través de procesos empíricos.
• En la gestión de proyectos tradicional se propone utilizar planeación detallada a largo

plazo.
• Los procesos empíricos están basados en las tres ideas principales de:
o Transparencia
o Inspección
o Adaptación
Principios Agiles
Principio 2. Auto-Organización
• El estilo de management en el enfoque tradicional es el de “Comando y Control”.
• Scrum enseña que los trabajadores de hoy tienen mucho más conocimiento que
ofrecer que solamente la experiencia técnica y que liberan más valor cuando ellos
mismos se auto-organizan.
• Esto viene de una nueva corriente de management enfocada a las empresas de la

era del conocimiento, y es llamada Knowledge Management.
Principios Agiles
Principio 3. Colaboración
• La colaboración se basa en que la creación de un producto es un proceso de
creación de valor compartida.
• La colaboración sólo se da a través de la interacción de los integrantes del equipo de

desarrollo como también los stakeholders afectados.
• La colaboración se da cuando un equipo trabaja junto para generar valor.
• Las dimensiones del trabajo colaborativo son:

o Awareness
o Articulation
o Appropiation
Principios Agiles
Principio 4. Priorización Basada en Valor

• Scrum se enfoca en generar valor lo más pronto posible en un proyecto. Esto solo
puede hacerse a través de la priorización.
• De esta forma, en un proyecto Scrum se genera valor en pequeños incrementos

desde muy temprano en el proyecto.
• Este valor es en forma de software funcionando que se entrega al cliente como un

subconjunto de todo el sistema.
• Para la priorización de la funcionalidad a entregar (user stories), el Product Owner se

basa en los siguientes factores:
o Valor
o Riesgo o incertidumbre
o Dependencias
Principios Agiles
Principio 5. Time-boxing
• Este principio de Scrum se basa en considerar al tiempo como una restricción del
proyecto.
• A lo que se refiere el time-boxing es en asignar a los procesos y actividades de

Scrum un tiempo predeterminado para su realización.
• De esta manera se puede planear mejor los tiempos de las fases de un proyecto
para que el equipo no se tarde ni mucho más ni mucho menos de lo que debería
durar cada proceso o fase.
Principios Agiles
Principio 6. Desarrollo Iterativo
• Desde los años 70s se supo que el desarrollo en cascada no es adecuado para
proyectos grandes y complejos.
• Como una necesidad a esto surgieron los primeros métodos iterativos de desarrollo
de software que fueron conocidos como métodos iterativos e incrementales.
• Este principio permite que los cambios en scrum se manejen de una manera muy
flexible debido al nivel de adaptación que llegan a alcanzar los proyectos.
Inducción a SCRUM
“The New New Product

Development Game” (Takeuchi
and Nonaka 1986)
En 1993, Jeff Sutherland y su

equipo en la Easel
Corporation crearon el
proceso SCRUM
En 1995, Ken Schwaber publicó el

primer ensayo técnico sobre Originalmente pensado para
SCRUM en la conferencia OOPSLA software se ha utilizado para otros
1995 muy diversos fines
El contexto SCRUM
• Imágenes obtenidas en http://www.innolution.com/resources/val-home-page

El equipo SCRUM
EQUIPO DE
SCRUM PRODUCT DESARROLLO
MASTER OWNER Hace
Remueve Define la visión estimanciones
obstáculos Establece Construye las
Facilita prioridades historias de
procesos Aporta recursos usuario
Asegura el valor Asegura la calidad
El Scrum Master
¿De qué manera agrega valor?

¿Solo remover obstáculos y procesos?
¿Qué habilidades clave?
¿Es posible convertir un PM en SM?
¿En cuántos proyectos puede participar?
¿Puede ser SM, PO y Desarrollo?
El product Owner
¿Qué valor agrega al proceso?

¿Es el líder?
¿Qué cualidades se necesitan para ser éxitoso?
¿Por qué es el rol “más difícil” de desarrollar?
¿Del negocio o de TI?
¿Cuántos proyectos puede dirigir?
¿Cuál es el alcance de su responsabilidad?
El equipo de desarrollo
¿Quién controla el avance?

¿Qué hacemos con ”los especialistas”?
¿Qué hacemos con el tiempo “muerto”?
¿Qué habilidades son críticas?
¿Qué responsabilidad?
¿Cómo agregan valor al proceso?
¿Cómo se desarrolla a un participante de un
equipo de desarrollo?
El product Backlog Priorizado
1. Responsabilidad del Product

Owner.
2. Al ser terminado la VISION del
PO se hará realidad.
3. Está expresado en términos de
TEMAS, EPICAS e HISTORIAS
DE USUARIO.
4. Priorizado por VALOR, costo,
Definir riesgo, complejidad.
Priorizar
Estimar
La idea del SPRINT
1. Duración fija (2-4-semanas).

2. Desarrollo iterativo e
incremental.
3. Release = Conjunto de
Sprint`s.
4. Iniciado el sprint:
• No hay cambios.
• El PO se queda fuera.
• El equipo toma el
“mando”.
5. Obtenemos un Producto
Potencialmente Embarcable.
SPRINT planning
SP Sprint 1 SP Sprint 2 El equipo de desarrollo y el

product owner deciden que
historias de usuario se van
construir:
• La prioridad.
• La capacidad.
• Si una historia no cabe se
descompone.
Las Las tareas El equipo de desarrollo define

historias las tareas para cada construir
del sprint. cada historia de usuario
elegidas.
SPRINT Backlog
Tareas Esfuerzo
Codificar 8
Escribir prueba 4
Realizar prueba 2
Validar flujo 2
• Es responsabilidad de equipo de desarrollo.

• Define la estrategia de desarrollo del Sprint.
• Contiene tareas y esfuerzos.
• Incluye TODAS las tareas para hacer que la historia se
considere HECHA.
• Incluye las tareas para integrar y probar el conjunto de
historias del SPRINT.
El daily SCRUM
• 15 minutos, todos los días.
• Tres preguntas:
• ¿Qué hice ayer?
• ¿Qué voy a hacer hoy?
• ¿Qué obstáculos me
impiden avanzar?
• NO es una sesión de solución
de problemas, ni de
planeación, coordinación o
temas misceláneos.
• La coordina el SCRUM
MASTER.
• Puede asistir el Product Owner
y otras personas pero solo
escuchan (PIGS).
Potentially Shippable Product
• Potentially Shippable NO ES
IGUAL a Shippable..
• Generalmente en los primeros

sprint´s se construye
arquitectura.
• Demuestra la viabilidad
técnica del equipo y del
proyecto.
Sprint Review
• Mostrar a los diferentes

stakeholders que se logró al
termino del sprint.
• Dura de 2 a 3 horas.
• El objetivo es demostrar
avance, validar
funcionalidad, aumentar la
confianza con el equipo de
desarrollo.
• Pueden surgir nuevas ideas.
Sprint Retrospective
• Inspeccionar y adaptar el
proceso.
• El objetivo es proponer
mejoras que aumentan la
velocidad, reduzcan el riesgo,
mejoren la colaboración.
• ¿Una nueva herramienta?
• ¿Un ajuste en la manera
relacionarnos con algo?
• ¿Adecuar alguna política o
estándar?
• ¿Algún recurso adicional?
Historia de usuario
Historia de usuario es la herramienta clave para

conversar con el product owner.
• Una manera de expresar el valor de negocio esperado a

través de una conversación entre roles técnicos y de negocio.
• Comprensible para ambas partes.
• Justo a tiempo y justo lo necesario.
• Las 3 C´s (Card, conversation, confirmation).
• Estructura INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)
Estructura y ejemplo de una historia de usuario
Como <usuario del
gimnasio> quiero
Como <rol de <programar mis rutinas de
usuario> deseo, entrenamiento> para
quiero, necesito <estar listo para mi
<objetivo> para competencia de los
<obtener un valor> 10km>
Criterios de
aceptación Elegir tipo de rutina
Criterio 1 .. Criterio Elegir calendario
n Elegir aparato / actividad
www.alpha-consultoria.com
Elegir intensidad 34
Diferentes niveles de detalle
• Horas.
• Tarea
• Días.
• Historia de usuario.
• Semanas.
• Tema.
• Epica. • Meses.
Concepto: Puntos por historia
• Es una unidad adimensional que representa el tamaño de

un historia en relación al resto de las historias.
“Esta historia es más grande que esta otra historia”
• Es un acuerdo del equipo que considera la valoración de:
• Esfuerzo.
• Complejidad.
• Riesgo.
• Se utiliza la serie de Fibonacci para asignar puntos a las
historias.
• La precisión y exactitud es muy costosa.
Técnica de estimación: Planning Poker
• Elegir la historia más simple.

• Comparar cada historia con la
historia inicial.
• ¿Cuántas veces es más grande
ésta historia comparada con
ésta?
Técnica de Estimación: Tamaño relativo
• Utilizamos como analogía las tallas de una camisa: xp, p,

m, g, xg, xxg.
• ¿Qué tan grande es ésta historia en relación a las otras?
• Una historia xxg tiene que descomponerse en historias
más pequeñas.
• Una historia xp o p posiblemente se puede estimar a
nivel de tareas-horas.
• Tenemos que estimar 200 historias … con frecuencia.
Tablero SCRUM
PRODUCT HECHO
SPRINT EN
BACKLOG BACKLOG PROCESO
Ejercicio: Construir la ciudad LEGO
• La visión del producto.
• Desarrollar el product backlog.

• Valor.
• Estimar tamaños relativos.
• Sprint planning.
• Ejecución del sprint.
• Sprint review.
Product Backlog, Planeación de las liberaciones.
(Size, velocidad, duración)

PRODUC SIZ
T E
Velocidad
BACKLO
G
P1 8
P2 3
P3 5
P4 13 Liberación 1 Si procesamos 40 puntos promedio por SPRINT
P5 3 200 PUNTOS necesitamos 5 SPRINT´s para completar la
P6 5 liberación 1.
P7 21
.. Si cada SPRINT es de 3 semanas la duración
P21 3 estimada será de 15 semanas.
P22
P23
Esfuerzo, riesgo,
complejidad
Priorización basada en el valor.
Esquemas Simples
Esquemas Simples implica etiquetear elementos como prioridad "1", "2", "3" o "Alto",
"Medio" y "Bajo" y así sucesivamente.
Priorización MoSCoW
El esquema Priorización MoSCoW deriva su nombre de las primeras letras de las frases
"Must have" (debe tener), "Should have” (debería tener), "Could have” (podría tener),
y "Won’t have” (no tendrá).
Dinero Falso o Dinero de Monopoly

Se da dinero falso o de monopoly igual a la cantidad del Presupuesto del Proyecto y
pedirle que lo distribuya entre los Historias de Usuarios bajo consideración. De esta
manera, el Cliente prioriza basado en lo que está dispuesto a pagar por cada Historia de
usuario.
Gráfica de desgaste del PBL
Gráfica de control de desgaste
Burndown Chart
Definición de Hecho (DoD).
Al final de cada Sprint , la calidad técnica del producto cumple con los
criterios de calidad establecidos para el lanzamiento del producto.
Este estado significa , por ejemplo :
• El producto ha sido probado adecuadamente y no hay errores o fallas

conocidos.
• El producto ha sido integrado con su entorno.
• El código está limpio y refactorizado
• La documentación está actualizada.
• El P.O. lo ha validado.
Spike
Son un tipo especial de historia utilizados para disminuir el

grado de riesgo e incertidumbre en una historia de usuario
u otro aspecto del proyecto.
• Estimar próximas funciones.

• Realizar análisis de viabilidad técnica.
• Realizar investigación básica para familiarizar al equipo
con una nueva tecnología o dominio del negocio.
• Valorar y estimar el nivel de riesgo técnico o funcional
significativo.
• Analizar el comportamiento implícito que puede tener
una historia cuando es demasiado grande al dividir la
historia en piezas estimables.
Escalamiento del contexto SCRUM
cuando la complejidad es muy alta.
Ejercicio: Bodega de vinos “La valenciana”
1. Proponer la visión.
2. Definir el Product Backlog.
• Definir historias.
• Priorizar.
• Estimar.
3. Inicar Sprint:
• Duración de 20 minutos.
• Todas las actividades dentro del Sprint.
• 5 minutos para las Review´s
Los mejores libros sobre SCRUM que te puedo recomendar.
KANBAN
Kanban
• Significa “Sistema de Tarjetas”.

• Es un sistema para controlar la fabricación de los productos necesarios en la
cantidad y tiempo necesarios en cada uno de los procesos que tienen lugar tanto
en la fábrica como en distintas empresas.
Kanban
Valores Clave
Kaizen: “Good Change”, se refiere a la mejora continua.
Kanban
Valores Clave
Muda: Se refiere a las actividades consideradas un desperdicio porque no agregan
ningún valor.
Kanban
Valores Clave
• Mura: Se refiere a inconsistencia, desigualdad, altibajos en el proceso. Ni hacer de
más ni hacer de menos para evitar desperdicios o sobreproducción. Se enfoca mucho en
el JIT (Just-In-Time).
• Muri: Se refiere a sobrecarga, sobreprocesamiento, no razonable.
Kanban
Valores Clave
• Muda, Mura y Muri
Lean Software Development
Principios Valores
• Optimización a nivel sistema • Valorar las necesidades del
• Eliminación de desperdicio cliente
• Valorar lo que el cliente está
• Calidad
dispuesto a pagar
• Compromiso
• Valorar lo que se desea
• Respeto y reconocimiento a la gente construir para el cliente
• Crear conocimiento
• Entrega rápida
Lean Software Development
Prácticas Desarrollo Iterativo

• Identificar desperdicios • Cada fase es Time-boxed
• Value stream mapping • Probar temprana y
repetidamente
• Set-based development
• Entregas tempranas y frecuentes
• Pull systems
• Mantener alta calidad
• Queuing theory
• Motivación
• Mediciones
Kanban Software Development
Prácticas Centrales Filosofías

1. Visualizar 1. Comience con lo que hace ahora
2. Limitar el WIP 2. Se acuerda perseguir el cambio
incremental y evolutivo
3. Dirigir y gestionar el flujo
3. Respetar el proceso actual, los
4. Hacer explícitas las políticas del roles, las responsabilidades y los
proceso
cargos
5. Utilizar modelos para reconocer 4. Liderazgo en todos los niveles
oportunidades de mejora
colaborativamente
Kanban Software Development
Prácticas Específicas
• Mapear flujos de valor
• Definir el punto de inicio y fin para control
• Tipos de work items
• Disponer de una pared y dibujar las columnas para las tarjetas
• Análisis de la demanda
• Asignar el trabajo basado en la capacidad
KANBAN
KANBAN
• Posiblemente • Tener un estado

4
tenemos de HECHO
personas permite reducir
desocupadas. la variabilidad
del flujo.
• ¿Es
conveniente? • En el paso
siguiente no
• Focalización. hay capacidad.
Lean Kanban
1. Optimización como un todo

2. Eliminación del desperdicio
o Desperdicio al desarrollar el producto incorrecto
o Desperdicio al no aprender
o Desperdicio al hacer prácticas que no aportan nada al proceso o desarrollo
3. Calidad
o Lidiar con los problemas en las primeras pruebas
o Evitar dependencias, diseñar la arquitectura para que sea flexible
o Asegurar que la verificación final no tenga defectos
Lean Kanban
4. Aprendizaje constante
o Desarrollar un sistema que responda rápido al cambio
o Hacer tolerante el mantenimiento al código
o Los equipos y el cliente deben estar conscientes del impacto de los cambios
o Aprender de los errores
o Mejorar continuamente, porque lo de hoy puede ser obsoleto mañana
o Usar técnicas empíricas o cuantitativas para generar conclusiones
5. Generar compromiso en todos
o Fomentar la autonomía en los equipos
o Fomentar el dominar temas a través de retos y feedback
o Comunicar el propósito de cada proyecto a cada miembro del equipo
XP (Extreme programming)
XP
• Creado por Kent Beck en 1996 mientras trabajaba en

un proyecto en Chrysler.
• En 1999 Kent Beck publicó el primer libro de XP.
• Tomó las mejores prácticas existentes para crear XP.
• TDD (llamado antes Test-First Development era
usado en la NASA desde los años 60’s.
XP
XP
Valores Clave
1. Comunicación
2. Feedback
3. Simplicidad
4. Coraje/Carácter
XP
Roles
1. Customer
2. Developer
3. Supplementary roles
4. Tracker
5. Coach
XP
Prácticas
• Coding Practices
1. Coding and designing
2. Refactoring
3. Developing coding standards
4. Developing a common vocabulary
• Developer Practices
5. TDD
6. Pair Programming
7. Collective code ownership
8. Continuous integration
• Business Practices
9. Adding a customer
10. Regular release
11. Planning Game
12. Sustainable pace
XP
Planning/Feedback Loops
XP
Pair Programming
TDD (Test-driven development)
TDD
TDD
Proceso
DSDM
(Dynamic Systems development methods)
DSDM
DSDM
• Creado en 1994 como una posible solución al poco

estructurado RAD.
• Sigue un enfoque iterativo e incremental.
• DSDM fija el costo, tiempo y la calidad y ajusta el alcance o

entregables usando una priorización con la técnica MoSCoW.
• En 2007 se crea una nueva versión llamada DSDM Atern (Artic

Tern) que incorpora una fuerte colaboración del cliente/usuario.
• Esta nueva versión está inspirada en el Artic Tern (Charrán)

porque representa la libertad, robustez y actitud colaborativa
haciendo un framework de desarrollo de software centrado en
el desarrollador para entregas a tiempo y bajo el presupuesto y
la calidad estimadas.
DSDM
Valores Clave
1. Se enfoca en la necesidad
2. Entrega a tiempo
3. Colaboración
4. Nunca comprometer la calidad
5. Construir incrementalmente a partir de fundamentos firmes
6. Desarrollar iterativamente
7. Comunicación continua y clara
8. Demostrar control
DSDM
Roles
1. Executive Sponsor
2. Visionary
3. Ambassador User
4. Advisor User
5. Project Manager
6. Technical Coordinator
7. Team Leader
8. Developer
DSDM
Prácticas
1. Pre-project phase
2. Feasibility phase
3. Foundations phase
4. Exploration and engineering phase
5. Deployment phase
6. Post-project phase
Métodos Crystal
Métodos Crystal
Métodos Crystal
Valores Clave
1. People are the most important
2. Lightweight methodology
3. Easy to adapt approach
4. Incremental development of features
5. Flexibility and fluidity
6. Team size is an important deciding factor
7. Active user involvement
8. Osmotic communication
9. Frequent tracking of progress
Métodos Crystal
Roles
• Executive Sponsor • Architect
• Lead designer • Coordinator
• Designer/programmer • Requirements gatherer
• Experienced user • Business expert
• Business analyst
• Architect • Project manager
• Coordinator • Design mentor
• Requirements gatherer • Usage expert
• Business expert • Lead design programmer
• Business analyst • UI designer
• Project manager • Technical facilitator
• Design mentor • Technical writer
Métodos Crystal
Prácticas
Strategies Techniques
• Exploratory 360 • Methodology shaping
• Early Victory • Reflection workshop
• Walking Skeleton • Blitz planning
• Incremental re-architecture • Delphi estimation
• Information radiators • Daily stand-up meetings
• Essential interaction design
• Process miniature
• Side-by-side programming
• Burn charts
Métodos Crystal
Proceso
1. Chartering
2. Delivery cycle
3. Wrap up
FDD
(Feature driven development)
FDD
Valores Clave
1. Un sistema para construir sistemas es necesario para escalar a proyectos mas
grandes.
2. Un proceso simple y bien definido funciona mejor.
3. Los pasos del proceso deben ser lógicos y ser valiosos de manera inmediata para
cada miembro del equipo.
4. El “orgullos del proceso” puede evitar que el trabajo real suceda.
5. Los buenos procesos son el marco para que los miembros del equipo se puedan
enfocar en los resultados.
6. Son mejores los ciclos de vida cortos, iterativos y dirigidos por las características
(feature-driven).
FDD
Roles
• Project manager • Testers
• Chief architect
• Deployers
• Development manager
• Technical writers
• Chief programmers
• Class owners
• Domain experts
• Domain manager
• Release manager
• Language guru
• Build engineer
• Toolsmith
• System administrator
FDD
Prácticas
1. Domain object modeling
2. Developing by feature
3. Individual class ownership
4. Feature teams
5. Inspections
6. Regular builds
7. Configuration management
8. Reporting/visibility of results
FDD
Proceso
1. Developing an overall model
2. Building a features list
3. Planning by feature
4. Designing by feature
5. Building by feature

Curso Practico Scrum

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Curso Practico Scrum

Cargado por

Copyright:

Formatos disponibles

Agile Expert Certified Training

Dirección de Proyectos y Ejecución de la Estrategia

El PMI ® no participó en la elaboración del presente documento y no ha

La información contenida en este documento, es propiedad intelectual de Alpha Consultoría de Proyectos.

El PMI ® no participó en la elaboración del presente documento y no ha revisado la precisión de su

¿Por qué AGIL?

1. Entender la filosofía ágil y sus principales prácticas.

El reloj competitivo de las empresas e instituciones se

¿Cuál es la percepción que tienes del entorno

Realizar una torre en la que se maximice la puntuación en solo 18

 Puntos = (Base x 2) + Altura.

Estamos descubriendo formas mejores de desarrollar software

Esto es, aunque valoramos los elementos de la derecha,

• En la gestión de proyectos tradicional se propone utilizar planeación detallada a largo

• El estilo de management en el enfoque tradicional es el de “Comando y Control”.

• Esto viene de una nueva corriente de management enfocada a las empresas de la

• La colaboración sólo se da a través de la interacción de los integrantes del equipo de

• La colaboración se da cuando un equipo trabaja junto para generar valor.

• Las dimensiones del trabajo colaborativo son:

Principio 4. Priorización Basada en Valor

• De esta forma, en un proyecto Scrum se genera valor en pequeños incrementos

• Este valor es en forma de software funcionando que se entrega al cliente como un

• Para la priorización de la funcionalidad a entregar (user stories), el Product Owner se

• A lo que se refiere el time-boxing es en asignar a los procesos y actividades de

Principio 6. Desarrollo Iterativo

“The New New Product

En 1993, Jeff Sutherland y su

En 1995, Ken Schwaber publicó el

• Imágenes obtenidas en http://www.innolution.com/resources/val-home-page

¿De qué manera agrega valor?

¿Qué valor agrega al proceso?

¿Quién controla el avance?

1. Responsabilidad del Product

1. Duración fija (2-4-semanas).

SP Sprint 1 SP Sprint 2 El equipo de desarrollo y el

Las Las tareas El equipo de desarrollo define

• Es responsabilidad de equipo de desarrollo.

• Generalmente en los primeros

• Mostrar a los diferentes

Historia de usuario es la herramienta clave para

• Una manera de expresar el valor de negocio esperado a

• Es una unidad adimensional que representa el tamaño de

• Elegir la historia más simple.

• Utilizamos como analogía las tallas de una camisa: xp, p,

• La visión del producto.

• Desarrollar el product backlog.

• Ejecución del sprint.

(Size, velocidad, duración)

Dinero Falso o Dinero de Monopoly

Este estado significa , por ejemplo :

• El producto ha sido probado adecuadamente y no hay errores o fallas

Son un tipo especial de historia utilizados para disminuir el

• Estimar próximas funciones.

• Significa “Sistema de Tarjetas”.

• Muri: Se refiere a sobrecarga, sobreprocesamiento, no razonable.

Prácticas Desarrollo Iterativo

Prácticas Centrales Filosofías

• Posiblemente • Tener un estado

1. Optimización como un todo

• Creado por Kent Beck en 1996 mientras trabajaba en

• Creado en 1994 como una posible solución al poco

• Sigue un enfoque iterativo e incremental.

• DSDM fija el costo, tiempo y la calidad y ajusta el alcance o