Gestión basada en Metodologías Ágiles

F O C U S Q U A L I T Y E X P E R I E N C E

Presentación
Miquel Rodríguez
Director 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

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
Diseño
funcional
Avanzamos… todo va
bien….

Requisitos
&
Plan de Proyecto
Y seguimos avanzando…
Diseño
funcional
Diseño
técnico

Requisitos
&
Plan de Proyecto
Funciona a la primera…!
Diseño
funcional
Diseño
técnico
Resultados
de las pruebas

Requisitos
&
Plan de Proyecto
El cliente
obtiene lo
que pidió.
(¡A tiempo y sin
sobrecostes!)Diseño
funcional
Diseño
técnico
Resultados
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

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.
Paracelsus
Alquimista 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 Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave 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ÁLISIS
DISEÑO
CONSTRUCCIÓN
PRUEBAS
IMPLANTACIÓN
tiempo
Supongamos un proyecto con
las clásicas fases en cascada

ANÁLISIS
DISEÑO
CONSTRUCCIÓN
PRUEBAS
IMPLANTACIÓN
Rompemos el proyecto en
pequeñas piezas que van de
inicio a fin de todo el
proceso….
tiempo

ANÁLISIS
DISEÑO
CONSTRUCCIÓN
PRUEBAS
IMPLANTACIÓ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.

ANÁLISIS
DISEÑO
CONSTRUCCIÓN
PRUEBAS
IMPLANTACIÓ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

ANÁLISIS
DISEÑO
CONSTRUCCIÓ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!!

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.

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

Agile = Iterative + Incremental
Henrik Kniberg
Don’t try to get it all right
from 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 Mockapetris
Inventor 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 pueden
describirlo, normalmente nos describen una propuesta de
solución en lugar de describir sus necesidades reales.
Don Reinertsen
Autor 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
Entregadevalor
Tiempo
Valor de mercado de
una funcionalidad
con el tiempo
Margen 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 is
small and very valuable
• Give a real-life example of a feature that is
large and not very valuable.
Weight: 1 gram
Value: 100 000 kr
Weight: 2000 grams
Value: 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

Velocity
to 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

Henrik Kniberg
Done!
Jan

Henrik Kniberg
Done!
Jan
Done!
Feb

Henrik Kniberg
Done!
Jan
Done!
Feb
Done!
Mar
Q2 forecast
All of
these
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 Kniberg
Date
What will be done
by Christmas?
Some of
these
All of
these
Delivered
features

Fixed time & scope forecast
Henrik Kniberg
Date
Can we get
all of THIS
done...
Delivered
features
....by
Christmas?
No. That is
unrealistic.

Fixed time & scope forecast
Henrik Kniberg
Date
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 & Lean
Enfoque
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
Colaboración con el cliente sobre negociación contractual
Más importante
Importante

….¿Es esto un contrato ágil? :-)


Money for Nothing & Changes for Free

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 trabajo
Rompe 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

Pending Developing Testing Done
Problems
Kanban Board

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

Kanban kick-start example
http://www.crisp.se/file-uploads/kanban-example.pdf

Visual Management
http://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 trabajo
y organizer el equipo
Limita el WIP y coge el trabajo cuando el equipo tiene
suficiente capacidad para hacerlo
Evoluciona identificando cuellos de botella, eliminando
trabajo no necesario, ajustando el WIP y analizando
como esta variabilidad afecta al rendimiento
1
4
3
2
5
Kanban: Successful Evolutionary Change for Your Technology Business: David Anderson

Scrum
http://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
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
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
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
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
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-

Planning Poker
http://www.mountaingoatsoftware.com/agile/planning-poker

Relative sizing
½, 1, 2, 3, 5, 8, 13, 20, 40, 100

eXtreme Programming Practices
Valores:
Simplicidad
Comunicación
Feedback
Coraje
http://xprogramming.com

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!

Challenges on Scaling Agile
Huge teams
Development
process
conflicts
Legacy
systems
Different life
cycles
Globally
distributed
teams
Functional &
technological
silos
<Please add your challenge
here>
here>
here>

Cross-functional teams
are 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
C
C
S
D
T
T
C
S
D
T
Feature team 2
D
S
DB
Server
Client
User
Communities
of 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 SAFe

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
Alignment
Business
Owners
Alignment from Portfolio to Program to Team

Roles, ceremonias, trenes
y 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?

Agenda para una Release Planning
Meeting

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
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)

Créditos







F O C U S Q U A L I T Y E X P E R I E N C E


Gestión basada en Metodologías Ágiles

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Gestión basada en Metodologías Ágiles

Similar a Gestión basada en Metodologías Ágiles (20)

Más de netmind

Más de netmind (20)

Último

Último (19)

Gestión basada en Metodologías Ágiles