Gestión basada en Metodologías Ágiles
Post on 13-Jan-2015
800 Views
Preview:
DESCRIPTION
Transcript
Presentación
Miquel RodríguezDirector de Formación y Mentoring en netmind
Master in IT Management
Executive MBA
Certified SAFe Program Consultant
Certified Scrum Master
Project Management Professional (PMP)
PRINCE2 Practitioner
miquelra@netmind.es
es.linkedin.com/in/miquelrodriguezaranda
@miquelrodriguez
@netmindIT
blog.netmind.es
www.netmind.es
En un mundo IDEAL...
Requisitos
&
Plan de Proyecto
En un mundo IDEAL...
Análisis Diseño Construcción Validación Entrega
El cliente sabe lo que quiere
El equipo sabe como hacerlo
Se documentan y aprueban los
requisitos y el Plan de Proyecto
Requisitos
&
Plan de Proyecto
En un mundo IDEAL...
Análisis Diseño Construcción Validación Entrega
Diseño
funcional
Avanzamos… todo va
bien….
Requisitos
&
Plan de Proyecto
En un mundo IDEAL...
Análisis Diseño Construcción Validación Entrega
Y seguimos avanzando…
Diseño
funcional
Diseño
técnico
Requisitos
&
Plan de Proyecto
En un mundo IDEAL...
Análisis Diseño Construcción Validación Entrega
Funciona a la primera…!
Diseño
funcional
Diseño
técnicoResultados
de las pruebas
Requisitos
&
Plan de Proyecto
En un mundo IDEAL...
Análisis Diseño Construcción Validación Entrega
El cliente
obtiene lo
que pidió.(¡A tiempo y sin
sobrecostes!)Diseño
funcional
Diseño
técnicoResultados
de las pruebas
Una causa habitual de desastre en proyectos
de desarrollo de software es que el producto
final es precisamente lo que el cliente solicitó.
The Economist. Agility counts
“”
http://www.economist.com/node/779429
9
Andar sobre el agua y construir según
requisitos es sencillo.
Solo es necesario que estén congelados.
Edward V. Berard’s Law
Edward V. Berard (1993) Essays on object-oriented software engineering
“”
Nada es veneno, todo es veneno:
la diferencia está en la dosis.
ParacelsusAlquimista y Médico Suizo
“”
Las dosis del enfoque Ágil
Personas
ProcesosTecnología
Comunicación
Colaboración
Confianza
Empowerment
Foco en End to End
Priorizar por valor
Mejora Continua
Excelencia técnica
Automatización
Rapidez
No sé porqué me dan
una cabeza cuando lo
que necesito son dos
brazos.
“
”Henry Ford
Padre de las cadenas de producción
“Un gran poder conlleva una gran responsabilidad”
Ben Parker (tío de Peter Parker)
Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros.
Esto es, aunque valoramos los elementos de la derecha,valoramos más los de la izquierda.
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
Kent BeckMike Beedle
Arie van BennekumAlistair Cockburn
Ward CunninghamMartin Fowler
James GrenningJim HighsmithAndrew HuntRon Jeffries
Jon KernBrian Marick
Robert C. MartinSteve Mellor
Ken SchwaberJeff SutherlandDave Thomas
http://agilemanifesto.org/iso/es/ © 2001
A través de este trabajo hemos aprendido a valorar:
http://agilemanifesto.org/iso/es/principles.html © 2001
Seguimos estos principios (1 de 2):
1.- Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
2.- Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3.- Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4.- Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
5.- Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
6.- El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
Principios del Manifiesto Ágil
http://agilemanifesto.org/iso/es/principles.html © 2001
Seguimos estos principios (2 de 2):
7.- El software funcionando es la medida principal de progreso.
8.- Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9.- La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10.- La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11.- Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12.- A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Principios del Manifiesto Ágil
Bueno, rápido y barato. Elija dos.
Anónimo (pero con toda la razón)
“ ”
Cambiando la orientación del Triangulo de Hierro
Constraints Requisitos Coste Tiempo
Estimación Coste Tiempo Funcionalidades
Predictivo
Waterfall
Adaptativo
Agile
Plan-Oriented
Value Oriented
Ciclo de vida tradicional vs ágil
AN
ÁL
ISIS
DIS
EÑ
O
CO
NS
TR
UC
CIÓ
N
PR
UE
BA
S
IMP
LA
NTA
CIÓ
N
tiempo
Supongamos un proyecto con
las clásicas fases en cascada
Ciclo de vida tradicional vs ágil
AN
ÁL
ISIS
DIS
EÑ
O
CO
NS
TR
UC
CIÓ
N
PR
UE
BA
S
IMP
LA
NTA
CIÓ
N Rompemos el proyecto en
pequeñas piezas que van de
inicio a fin de todo el
proceso….
tiempo
Ciclo de vida tradicional vs ágil
AN
ÁL
ISIS
DIS
EÑ
O
CO
NS
TR
UC
CIÓ
N
PR
UE
BA
S
IMP
LA
NTA
CIÓ
N
tiempo
Rompemos el proyecto en
pequeñas piezas que van de
inicio a fin de todo el
proceso….
… y las vamos ejecutando
secuencialmente, por
iteraciones.
Ciclo de vida tradicional vs ágil
AN
ÁL
ISIS
DIS
EÑ
O
CO
NS
TR
UC
CIÓ
N
PR
UE
BA
S
IMP
LA
NTA
CIÓ
N
Si por cualquier motivo nos desviamos un 10% en cada fase y tenemos comprometida la fecha de entrega,
normalmente intentamos recuperar el tiempo perdido corriendo más al final, a costa de las pruebas.
Como consecuencia, entregamos un producto incompleto, con errores y tarde.
+10% +10% +10%+10%tiempo
Ciclo de vida tradicional vs ágil
AN
ÁL
ISIS
DIS
EÑ
O
CO
NS
TR
UC
CIÓ
N
tiempo
Y si, además, nos desviamos o nos encallamos en las fases iniciales, al llegar la fecha
comprometida no tenemos más que documentos funcionales que no aportan ningún valor.
+20%Analysis paralysis!!
Ciclo de vida tradicional vs ágil
tiempo
Si nos retrasamos un 10% en un enfoque incremental…
… tenemos el 90% de
nuestro producto.
Y si hemos priorizado bien,
tenemos el 90% que aporta
más valor.
Ciclo de vida tradicional vs ágil
Y si somos realmente lentos y poco efectivos….
… como mínimo tendremos
un producto que aporta un
subconjunto del valor por el
que fue iniciado.
tiempo
Agile Process Movement
Iterative
Processes
Spiral RAD RUP…
Agile (Adaptive) Processes
Scrum, XP, Lean, Open UP, DSDM Atern, FDD, Crystal…
1970 1980 1990 2000
Predictive
Process
2010
Scaling Agility to the Enterprise
26
Agile = Iterative + Incremental
Henrik Kniberg
Don’t try to get it all rightfrom the beginning
Don’t build it all at once
cost
value
cost value
Not ”horizontal” increments
Henrik Kniberg
DB
Server
Client
1
2
3
1 2 3 4
value
”Vertical” increments!
Henrik Kniberg
DB
Server
Client 1
5
2 3
1 432
value
Keep iterations short(2-3 weeks)
Henrik Kniberg
Short iteration
Less likely to get interrupted
Less scope creep
Planning is easier with frequent releases
Henrik Kniberg
Priorización por valor y alcance
+ valor
- valor
nuevos elementos
en cualquier momento
re-priorización
continua
Seguro que podremos hacerlo
Quizás podremos incluirlo
Descartado, fuera del alcance
El primer vuelo de los
hermanos Wright no
tenía cuarto de baño ni
carrito de bebidas.
Puedes añadir
funcionalidades más
adelante.
“
”
Paul MockapetrisInventor del Sistema de Nombres de Dominio DNS
valor
Ignoramos el hecho de que muchos clientes no saben lo que quieren.
Ignoramos el hecho de que, incluso cuando saben lo que quieren, no saben cómo describirlo.
Ignoramos el hecho de que, incluso cuando puedendescribirlo, normalmente nos describen una propuesta desolución en lugar de describir sus necesidades reales.
Don ReinertsenAutor de “The Principles of Product Development Flow:
Second Generation Lean Product Development”
“
”
Detección y descripción del valor
Mi maleta pesa demasiado, por tanto
necesito una maleta más ligera.
En realidad… ¡No me importa el peso!
¡Si tiene ruedas es fácil de transportar!
Detección y descripción del valor
No me gustan los
estudios de mercado.
El cliente no sabe lo
que quiere hasta que
no lo tiene delante.
“
”Steve Jobs
Priorización
29 de junio de 2007
Lanzamiento del primer iPhone
17 de junio de 2009
Envío de MMS, copiar & pegar
Priorizar funcionalidades es un aspecto clave para entregar valor lo antes posible
El valor de una funcionalidad disminuye con el tiempo
Entr
ega d
e v
alo
r
Tiempo
Valor de mercado de
una funcionalidad
con el tiempoMargen acumulado
Margen acumulado
en Waterfall
Features have different value(and value is independent of size)
Henrik Kniberg
2 minute standup discussion (pair/trio):
• Give a real-life example of a feature that issmall and very valuable
• Give a real-life example of a feature that islarge and not very valuable.
Weight: 1 gramValue: 100 000 kr
Weight: 2000 gramsValue: 5 kr
2:001:591:581:571:561:551:541:531:521:511:501:491:481:471:461:451:441:431:421:411:401:391:381:371:361:351:341:331:321:311:301:291:281:271:261:251:241:231:221:211:201:191:181:171:161:151:141:131:121:111:101:091:081:071:061:051:041:031:021:011:000:590:580:570:560:550:540:530:520:510:500:490:480:470:460:450:440:430:420:410:400:390:380:370:360:350:340:330:320:310:300:290:280:270:260:250:240:230:220:210:200:190:180:170:160:150:140:130:120:110:100:090:080:070:060:050:040:030:020:01Done
Henrik Kniberg
Maximize Value, not Output
Velocityto know the future, you need to know the past
Henrik Kniberg
When will we get there?
We are here
Our steps so far
Velocity-based release planning
Henrik Kniberg
Backlog
Velocity-based release planning
Henrik Kniberg
Done!Jan
Velocity-based release planning
Henrik Kniberg
Done!Jan
Done!Feb
Velocity-based release planning
Henrik Kniberg
Done!Jan
Done!Feb
Done!Mar
Q2 forecastAll ofthese
Some of these
None of these
Release burnup chart
Henrik Kniberg
Delivered features
Date
Fixed scope forecast
Henrik Kniberg
Delivered features
Date
When will all of this be done?
Around week 27-30
Fixed time forecast
Henrik KnibergDate
What will be done by Christmas?
Some of these
All of these
Delivered features
Fixed time & scope forecast
Henrik KnibergDate
Can we get all of THIS
done...
Delivered features
....by Christmas?
No. That is unrealistic.
Fixed time & scope forecast
Henrik KnibergDate
Delivered features
We can get THIS much done by
Christmas
...and the rest done by February.
No. That is unrealistic.
¿…por qué seguimos utilizando
el modelo tradicional?
Eh! Un momento…!…mmmm…. …entonces….
Insanity: doing the same
thing over and over again
and expecting different
results.
“
”
La única persona que desea un cambio
es un bebé con el pañal mojado.
Anónimo(atribuido a Mark Twain)
“”
http://upload.wikimedia.org/wikipedia/commons/f/f3/Uncle_Sam_(pointing_finger).jpg
¿Qué estás haciendo TÚ para cambiar?
Un 83% de las empresas TIC usan metodologías ágiles para
el desarrollo de sus aplicaciones, ya que éstas les permiten
adaptarse mejor a los cambios del mercado.
Veamos qué están haciendo otros…
http://www.tecnologiapyme.com/movilidad/el-83-de-las-empresas-usan-metodologias-agiles-para-el-desarrollo-de-sus-aplicaciones
Metodologías ágiles
83%
17%
The United States is going to
maintain our military superiority
with armed forces that are agile,
flexible and ready for the full range
of contingencies and threats.
Barack Obama
“
”
Kanban
ScrumXP
Agile & LeanEnfoque
Product Management
Project Management
Team Management
Técnicas de desarrollo
Ingeniería
Service Management
Continuous Flow
Visual Management
El enfoque Agile
Kanban
ScrumXP
Agile & LeanEnfoque
Product Management
Project Management
Team Management
Técnicas de desarrollo
Ingeniería
Service Management
Continuous Flow
Visual Management
El enfoque Agile
¿Qué es Agile?
Agile es entrega temprana
de valor de negocio.“
”Henrik Kniberg
Consultor, Agile & Lean Coach
Lean Thinking
Una manera de pensar que permite a las organizaciones
especificar el valor, alinear las actividades que añaden
valor en la mejor secuencia posible, desarrollar estas
actividades sin interrupción cuando alguien las solicita y
desempeñarlas más y más eficientemente.
Craft Production Mass Production Toyota Production System
Proved the value of continual improvement at General Electric
Customization
Highly skilled workforce
High cost
Moving Production Line
Production Engineering
Low cost, inflexible model
Focus on quality
Just-in-time production
Continual Improvement
Taylor
Lean In Service
Services & Health
Professionals
Productivity improvement
Business process improvement
Deming
Momentos clave en la historia de Lean
1910 1920 19551887 2000
Scientific management, labour productivity
Jack Welch
A consequence of Lean is a paradigm shift
Traditional Lean
Managers have all the answers
Manager should ask the right
questions, employees should
have the answers as a team
Managers do the thinking,
workers concentrate on doing
Managers facilitate the workers
to add value
Activities are done, because
they are asked to be done
Activities are only done if they
add value
A certain rate of defects is unavoidable
Defects can be eliminated
Constancy of Purpose
Respect for the people
Perfection
Lean Principles
Contratos en proyectos ágiles
67
Colaboración con el cliente sobre negociación contractual
Más importante
Importante
….¿Es esto un contrato ágil? :-)
Money for Nothing & Changes for Free
Kanban
ScrumXP
Agile & LeanEnfoque
Product Management
Project Management
Team Management
Técnicas de desarrollo
Ingeniería
Service Management
Continuous Flow
Visual Management
El enfoque Agile
Stop Starting, Start Finishing
Pull vs Push
Kanban
Kanban es un método para gestionar el trabajo basado en
Pull, Just in Time, y limitando el trabajo en curso (WIP)
Visualiza el flujo de trabajoRompe el trabajo en piezas, representa cada una de ellas en una tarjeta y pégalo en la pared.
Utiliza columnas con nombres para ilustrar donde está cada elemento dentro del flujo.
Limita el trabajo en curso (WIP)Asigna límites explícitos para ver cuantos elementos puede haber en curso para cada estado
del flujo.
Mide el tiempo de inicio a fin (Lead Time)Optimiza el proceso para conseguir que el tiempo de inicio a fin sea el mínimo possible.
Kanban and Scrum. Making the most of both. Henrik Kniberg & Mattias Skarin
Pending Doing Done
Kanban Board
73
Pending Developing Testing Done
Problems
Kanban Board
74
Capacidad
75
Pending Developing Testing Done
Problems
Kanban Board + WIP
WIP limit = 4
Céntrate en finalizar estos antes de
añadir otro elemento
WIP limit = 3
76
Kanban kick-start example
http://www.crisp.se/file-uploads/kanban-example.pdf
Visual Management
78http://www.flickr.com/photos/yveshanoulle/
Low-tech, Multipurpose, Easy to Adapt & Understand
¿Cómo empezamos a aplicar Kanban?
Empieza con lo que ya estás haciendo
Modifícalo ligeramente para poder aplicar Pull
Utiliza un método transparente para visualizer el trabajoy organizer el equipo
Limita el WIP y coge el trabajo cuando el equipo tienesuficiente capacidad para hacerlo
Evoluciona identificando cuellos de botella, eliminandotrabajo no necesario, ajustando el WIP y analizando
como esta variabilidad afecta al rendimiento
1
4
3
2
80
5
Kanban: Successful Evolutionary Change for Your Technology Business: David Anderson
Kanban
ScrumXP
Agile & LeanEnfoque
Product Management
Project Management
Team Management
Técnicas de desarrollo
Ingeniería
Service Management
Continuous Flow
Visual Management
El enfoque Agile
Scrum
82http://www.scrumalliance.org/
Roles
• Product Owner
• Development Team Member
• Scrum Master
Artefactos
• Product Backlog
• Sprint Backlog
• Product Increment
Actividades / Reuniones
•Product Backlog Refinement•Sprint Planning•Daily Scrum•Sprint Review•Sprint Retrospective
Scrum es un método iterativo e
incremental para construir un producto
User Stories
83
User Stories Applied: For Agile Software
Development
Mike Cohn 2004
User Story Pattern
As a <user role>
I can <activity>
so that <business value>
Card, Conversation, Confirmation
85
Card
• Short statement, captured on a physical & small card
• Metaphor providing a tangible and kinaesthetic relation between the team and “this thing the user wants to do”.
• It also helps keep keeps the story lightweight and malleable
Conversation
• Conversation between the team, customer/user, the product owner, and other stakeholders.
• This is the discussion necessary to determine the more detailed behavior required to implement the intent.
• The conversation may spawn additional specificity in the form of attachments to the user story (mockup, spreadsheet, algorithm, timing diagram, etc)
Confirmation
• The stories acceptance criteria provides the precision necessary to assure that the story is implemented correctly and covers the relevant functional and non-functional requirements.
• Agile teams automate acceptance tests wherever possible, oftentimes in a business-readable, domain-specific language, thereby creating the “automatically executable specification and test” of the code
C C C
INVEST
86
Independent (of all others, as much as possible)
Negotiable (not a specific contract for features)
Valuable (to the customer)
Estimable (to a good approximation)
Small (so it can be done by a few person-days work)
Testable (in principle, even if there isn’t a test for it yet)
Estimating and Sizing with Story Points
87
A Story Point is a common name for sizing work
Arbitrary measure of relative unit of work used by teams.
It depends on the effort, the complexity and the uncertainty related to the User Story
Each team has his own “effort-translation” for a Story Point
For some teams means “1 day”
For some teams means “1 week”
For some teams means “1 ideal day”
For some teams means 4-hours
Fibonacci Sequence and other sizing methods
88
As we’re interested in row order of magnitude, we can use
several approachs:
Fibonacci: 1, 2, 3, 5, 8, 13, 21, 34,…
Pseudo Fibonacci (most common): 0, ½, 1, 2, 3, 5, 8,
13, 20, 40, 100
T-Shirts: XL, L, M, S, XS
http://www.mathsisfun.com/numbers/images/fibonacci-
spiral.gif
Planning Poker
89http://www.mountaingoatsoftware.com/agile/planning-poker
Relative sizing
90½, 1, 2, 3, 5, 8, 13, 20, 40, 100
Affinity Estimating
91
Kanban
ScrumXP
Agile & LeanEnfoque
Product Management
Project Management
Team Management
Técnicas de desarrollo
Ingeniería
Service Management
Continuous Flow
Visual Management
El enfoque Agile
eXtreme Programming Practices
Valores:
Simplicidad
Comunicación
Feedback
Corajehttp://xprogramming.com
93
Releasing must be REALLY easy
Henrik Kniberg
Req Code Test
Release!
Release = Drama!
Release = Routine
¿Por qué aplicar técnicas ágiles?
Porque funcionan… …. y es más divertido!
The Fun Theory
Ops….
x 50?
x 500?
x 5.000?
Challenges on Scaling Agile
Huge teamsDevelopment
process conflicts
Legacy systems
Different life cycles
Globally distributed
teams
Functional & technological
silos
<Please add your challenge here>
<Please add your challenge here>
<Please add your challenge here>
Cross-functional teamsare vertical
Henrik Kniberg
Client team
C C C
Test team
T T T
DB team
D D D
Server team
S S S
Feature team 1
CC
S
D
TT
C
S
D
T
Feature team 2
D
S
DB
Server
Client
User
Communitiesof interest
Spotify
Henrik Kniberg
Tribe Tribe Tribe
TribeTribe Tribe
PO PO PO
Tribe
Tribe lead
PO PO PO PO
Tribe
Chapter
Chapter
Tribe lead
PO
Chapter
Chapter Guild
Spotify
Scaled Agile Framework
Acerca de SAFe
Estructura de SAFe
Roles, ceremonias, trenes y escalabilidad
Casos de éxito y siguientes pasos
The Scaled Agile Framework (SAFe®)
Sincronización, alineación,
colaboración, entrega de valor
Consultable en libros y en la
web oficial
Puede escalarse a un gran
número de personas / equipos
Core values:
1. Calidad del código
2. Ejecución de Programas
3. Alineación
4. Transparencia
http://ScaledAgileFramework.com
Scaled Agile Framework es un marco de trabajo para aplicar técnicas
Lean y Agile a nivel empresarial
Estructura de SAFeScaled Agile Framework
Agile Teams
Empowered, self-organizing, self-managing cross-functional teams
Valuable, fully-tested software increments every two weeks
Scrum project management practices and XP-inspired technical
practices
Teams operate under program vision, system, architecture and user
experience guidance
Value description via User Stories
Code Quality
Agile Architecture
Continuous Integration
Test-First
Refactoring
Pair Work
Collective Ownership
Code Quality Provides:
Higher quality products and
services, customer
satisfaction
Predictability and integrity of
software development
Development scalability
Higher development velocity,
system performance and
business agility
Ability to innovate
You can’t scale crappy code
Iteraciones a nivel de equipo con ScrumXP
Equipos ágiles con ScrumXP
Los equipos ágiles ScrumXP están basados en equipos Scrum, con
algunas variaciones que facilitan su escalabilidad
Scale to the Program Level
Self-organizing, self-managing team-of-agile-teams
Continuous value delivery
Aligned to a common mission via a single backlog
Common sprint lengths and estimating
Face-to-face planning cadence for collaboration, alignment,
synchronization, and assessment
Value description via Features and Benefits
Develop on Cadence. Deliver on Demand.
Deliver on Demand
Major
Release Customer
Upgrade
Customer
Preview
Major
Release New
Feature
Develop on Cadence
PSI PSI PSI PSI PSI
Development occurs on a fixed cadence.
The business decides when value is released.
Program Execution
Driven by Vision and
Roadmap
Lean, economic
prioritization
Frequent, quality
deliveries
Fast customer feedback
Fixed, reliable cadence
Regular Inspect and
Adapt drives continuous
improvement
Agile Release Trains – self-organizing teams of agile teams – reliably
and frequently deliver enterprise value
Scale to the Portfolio
Centralized strategy, decentralized execution
Investment themes provide operating budgets for trains
Kanban systems provide portfolio visibility and WIP limits
Objective metrics support governance and kaizen
Value description via Business and Architectural Epics
Alignment
Clear content authority
Face-to-face planning
Aligned Team, Program
and Business Owner
objectives
Cross-team and cross-
program coordination
Architecture and UX
guidance
Match demand to
throughput
Alig
nm
en
t
Business Owners
Alignment from Portfolio to Program to Team
Roles, ceremonias, trenesy escalabilidad
Roles por cada nivel
Porfolio Level
Program Level
Team Level
Program Portfolio Management Team
Epic Owner
Enterprise Architect
Product Management
Release Management
Business Owner
System Team
DevOps
Architect
UX
Release Train Engineer
Product Owner
Developers & Testers
Scrum/Agile Master
En cada nivel encontramos un conjunto de roles, que pueden ser compartidos
en algunos casos
Agile Release Train
Un Agile Release Train es un equipo-de-equipos auto-gestionado que entrega
valor en una cadencia específica de forma continua
Agile Release Train
Un Agile Release Train es en realidad un fractal de los sprints de los equipos,
a nivel de Programa
Agile Release Train
Compartir la misma cadencia no es suficiente…..
Agile Release Train
… es necesaria una sincronización entre equipos de un mismo programa para
garantizar la entrega coordinada
How Big Agile Release Trains can be?
Release Planning Meeting
Agenda para una Release PlanningMeeting
Ubicación de la Release Planning Meeting dentro de la candencia - HIP
Entregables del Release Planning Meeting
Cada equipo tiene sus objetivos, con el valor aportado al negocio, una temporalización por sprints
de las Historias a entregar, y un plan de respuesta a riesgos.
Entregables del Release Planning Meeting
Un Program Plan con las fechas previstas de entrega y otros hitos relevantes, con dependencias
entre equipos, y una votación del nivel de confianza/compromiso de todo el programa
Votación conjunta
para poner en
común el nivel de
confianza del plan
y actualizar
objetivos
Casos de éxito –Empezando a andar
Experiencias de netmind con SAFe
netmind Agile Training & Mentoring
Lean & Agile Development & Practices
JST 291 | Lean IT Foundation
JJM 188 | PMI Agile Certified Practitioner Exam Prep
JJM 120 | Desarrollo Ágil con Scrum
JJM 125 | Introducción al Desarrollo Ágil de Software
JJM 126 | Gestión Ágil de Proyectos de Software
JJM 130 | Estimación y Planificación Ágil de Proyectos de Software
JJM 131 | Historias de Usuario para la Gestión Ágil de Requerimientos
JJM 132 | Taller Práctico de Kanban. Gestión Visual del Desarrollo
JJM 134 | Testing en el desarrollo del Software
Scaled Agile Framework
JJM 150 | SAFe ScrumXP for Teams
JJM 151 | Leading the Lean-Agile Enterprise with Scaled Agile Framework
www.netmind.es
Coaching
Definición Metodológica
Herramientas
(en proceso)
Y además….
top related