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...
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 ...
Requisitos
&
Plan de Proyecto
En un mundo IDEAL...
Análisis Diseño Construcción Validación Entrega
Diseño
funcional
Avanza...
Requisitos
&
Plan de Proyecto
En un mundo IDEAL...
Análisis Diseño Construcción Validación Entrega
Y seguimos avanzando…
D...
Requisitos
&
Plan de Proyecto
En un mundo IDEAL...
Análisis Diseño Construcción Validación Entrega
Funciona a la primera…!...
Requisitos
&
Plan de Proyecto
En un mundo IDEAL...
Análisis Diseño Construcción Validación Entrega
El cliente
obtiene lo
q...
Una causa habitual de desastre en proyectos
de desarrollo de software es que el producto
final es precisamente lo que el c...
Andar sobre el agua y construir según
requisitos es sencillo.
Solo es necesario que estén congelados.
Edward V. Berard’s L...
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
...
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 nuestr...
http://agilemanifesto.org/iso/es/principles.html © 2001
Seguimos estos principios (1 de 2):
1.- Nuestra mayor prioridad es...
http://agilemanifesto.org/iso/es/principles.html © 2001
Seguimos estos principios (2 de 2):
7.- El software funcionando es...
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 Funcionalidad...
Ciclo de vida tradicional vs ágil
ANÁLISIS
DISEÑO
CONSTRUCCIÓN
PRUEBAS
IMPLANTACIÓN
tiempo
Supongamos un proyecto con
las ...
Ciclo de vida tradicional vs ágil
ANÁLISIS
DISEÑO
CONSTRUCCIÓN
PRUEBAS
IMPLANTACIÓN
Rompemos el proyecto en
pequeñas pieza...
Ciclo de vida tradicional vs ágil
ANÁLISIS
DISEÑO
CONSTRUCCIÓN
PRUEBAS
IMPLANTACIÓN
tiempo
Rompemos el proyecto en
pequeña...
Ciclo de vida tradicional vs ágil
ANÁLISIS
DISEÑO
CONSTRUCCIÓN
PRUEBAS
IMPLANTACIÓN
Si por cualquier motivo nos desviamos ...
Ciclo de vida tradicional vs ágil
ANÁLISIS
DISEÑO
CONSTRUCCIÓN
tiempo
Y si, además, nos desviamos o nos encallamos en las ...
Ciclo de vida tradicional vs ágil
tiempo
Si nos retrasamos un 10% en un enfoque incremental…
… tenemos el 90% de
nuestro p...
Ciclo de vida tradicional vs ágil
Y si somos realmente lentos y poco efectivos….
… como mínimo tendremos
un producto que a...
Agile Process Movement
Iterative
Processes
Spiral RAD RUP…
Agile (Adaptive) Processes
Scrum, XP, Lean, Open UP, DSDM Atern...
Agile = Iterative + Incremental
Henrik Kniberg
Don’t try to get it all right
from the beginning
Don’t build it all at once...
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...
El primer vuelo de los
hermanos Wright no
tenía cuarto de baño ni
carrito de bebidas.
Puedes añadir
funcionalidades más
ad...
Ignoramos el hecho de que muchos clientes no saben lo que
quieren.
Ignoramos el hecho de que, incluso cuando saben lo que
...
Mi maleta pesa demasiado, por tanto
necesito una maleta más ligera.
En realidad… ¡No me importa el peso!
¡Si tiene ruedas ...
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 ...
El valor de una funcionalidad disminuye con el
tiempo
Entregadevalor
Tiempo
Valor de mercado de
una funcionalidad
con el t...
Features have different value
(and value is independent of size)
Henrik Kniberg
2 minute standup discussion (pair/trio):
•...
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
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 forecast
All of
these
Some of
these
None o...
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. Th...
Fixed time & scope forecast
Henrik Kniberg
Date
Delivered
features
We can get THIS
much done by
Christmas
...and the rest ...
¿…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
adap...
The United States is going to
maintain our military superiority
with armed forces that are agile,
flexible and ready for t...
Kanban
ScrumXP
Agile & Lean
Enfoque
Product Management
Project Management
Team Management
Técnicas de desarrollo
Ingenierí...
Kanban
ScrumXP
Agile & Lean
Enfoque
Product Management
Project Management
Team Management
Técnicas de desarrollo
Ingenierí...
¿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ñad...
Craft Production Mass Production Toyota Production System
Proved the value of
continual improvement
at General Electric
Cu...
A consequence of Lean is a
paradigm shift
Traditional Lean
Managers have all the answers
Manager should ask the right
ques...
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
Kanban
ScrumXP
Agile & Lean
Enfoque
Product Management
Project Management
Team Management
Técnicas de desarrollo
Ingenierí...
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)
V...
Pending Doing Done
Kanban Board
Pending Developing Testing Done
Problems
Kanban Board
Capacidad
Pending Developing Testing Done
Problems
Kanban Board + WIP
WIP limit = 4
Céntrate en finalizar estos antes de
añadir otro...
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
Util...
Kanban
ScrumXP
Agile & Lean
Enfoque
Product Management
Project Management
Team Management
Técnicas de desarrollo
Ingenierí...
Scrum
http://www.scrumalliance.org/
Roles
• Product Owner
• Development Team Member
• Scrum Master
Artefactos
• Product Ba...
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
tangib...
INVEST
Independent (of all others, as much as possible)
Negotiable (not a specific contract for features)
Valuable (to the...
Estimating and Sizing with Story
Points
A Story Point is a common name for sizing work
Arbitrary measure of relative unit ...
Fibonacci Sequence and other sizing
methods
As we’re interested in row order of magnitude, we can use
several approachs:
F...
Planning Poker
http://www.mountaingoatsoftware.com/agile/planning-poker
Relative sizing
½, 1, 2, 3, 5, 8, 13, 20, 40, 100
Affinity Estimating
Kanban
ScrumXP
Agile & Lean
Enfoque
Product Management
Project Management
Team Management
Técnicas de desarrollo
Ingenierí...
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!
The Fun Theory
Ops….
x 50?
x 500?
x 5.000?
Challenges on Scaling Agile
Huge teams
Development
process
conflicts
Legacy
systems
Different life
cycles
Globally
distrib...
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
Featu...
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 ...
The Scaled Agile Framework (SAFe®)
Sincronización, alineación,
colaboración, entrega de valor
Consultable en libros y en...
Estructura de SAFe
Scaled Agile Framework
Agile Teams
 Empowered, self-organizing, self-managing cross-functional teams
 Valuable, fully-tested software increment...
Code Quality
Agile
Architecture
Continuous
Integration
Test-First
Refactoring
Pair Work
Collective
Ownership
Code Quality ...
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 facilita...
Scale to the Program Level
 Self-organizing, self-managing team-of-agile-teams
 Continuous value delivery
 Aligned to a...
Develop on Cadence. Deliver on Demand.
Deliver on Demand
Major
Release Customer
Upgrade
Customer
Preview
Major
Release New...
Program Execution
 Driven by Vision and
Roadmap
 Lean, economic
prioritization
 Frequent, quality
deliveries
 Fast cus...
Scale to the Portfolio
 Centralized strategy, decentralized execution
 Investment themes provide operating budgets for t...
Alignment
 Clear content authority
 Face-to-face planning
 Aligned Team, Program
and Business Owner
objectives
 Cross-...
Roles, ceremonias, trenes
y escalabilidad
Roles por cada nivel
Porfolio Level
Program Level
Team Level
Program Portfolio Management Team
Epic Owner
Enterprise Archi...
Agile Release Train
Un Agile Release Train es un equipo-de-equipos auto-gestionado que entrega
valor en una cadencia espec...
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 coordi...
How Big Agile Release Trains can be?
Release Planning Meeting
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 temporaliz...
Entregables del Release Planning Meeting
Un Program Plan con las fechas previstas de entrega y otros hitos relevantes, con...
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 C...
Y además….

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
Gestión basada en Metodologías Ágiles
Gestión basada en Metodologías Ágiles
Gestión basada en Metodologías Ágiles
Gestión basada en Metodologías Ágiles
Gestión basada en Metodologías Ágiles
Gestión basada en Metodologías Ágiles
Gestión basada en Metodologías Ágiles
Upcoming SlideShare
Loading in...5
×

Gestión basada en Metodologías Ágiles

1,262

Published on

Presentación elaborada por Miquel Rodríguez, nuestro director de Formación y Mentoring, para su conferencia en la Xunta de Galicia

Published in: Technology
1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,262
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
105
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide

Gestión basada en Metodologías Ágiles

  1. 1. F O C U S Q U A L I T Y E X P E R I E N C E
  2. 2. 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
  3. 3. En un mundo IDEAL...
  4. 4. 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
  5. 5. Requisitos & Plan de Proyecto En un mundo IDEAL... Análisis Diseño Construcción Validación Entrega Diseño funcional Avanzamos… todo va bien….
  6. 6. 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
  7. 7. 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écnico Resultados de las pruebas
  8. 8. 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écnico Resultados de las pruebas
  9. 9. 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
  10. 10. 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 “ ”
  11. 11. Nada es veneno, todo es veneno: la diferencia está en la dosis. Paracelsus Alquimista y Médico Suizo “ ”
  12. 12. 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
  13. 13. No sé porqué me dan una cabeza cuando lo que necesito son dos brazos. “ ” Henry Ford Padre de las cadenas de producción
  14. 14. “Un gran poder conlleva una gran responsabilidad” Ben Parker (tío de Peter Parker)
  15. 15. 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:
  16. 16. 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
  17. 17. 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
  18. 18. Bueno, rápido y barato. Elija dos. Anónimo (pero con toda la razón) “ ”
  19. 19. 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
  20. 20. 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
  21. 21. Ciclo de vida tradicional vs ágil 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
  22. 22. Ciclo de vida tradicional vs ágil 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.
  23. 23. Ciclo de vida tradicional vs ágil 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
  24. 24. Ciclo de vida tradicional vs ágil 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!!
  25. 25. 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.
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. Not ”horizontal” increments Henrik Kniberg DB Server Client 1 2 3 1 2 3 4 value
  30. 30. ”Vertical” increments! Henrik Kniberg DB Server Client 1 5 2 3 1 432 value
  31. 31. Keep iterations short (2-3 weeks) Henrik Kniberg Short iteration Less likely to get interrupted Less scope creep
  32. 32. Planning is easier with frequent releases Henrik Kniberg
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. No me gustan los estudios de mercado. El cliente no sabe lo que quiere hasta que no lo tiene delante. “ ”Steve Jobs
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. Henrik Kniberg Maximize Value, not Output
  42. 42. 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
  43. 43. Velocity-based release planning Henrik Kniberg Backlog
  44. 44. Velocity-based release planning Henrik Kniberg Done! Jan
  45. 45. Velocity-based release planning Henrik Kniberg Done! Jan Done! Feb
  46. 46. Velocity-based release planning Henrik Kniberg Done! Jan Done! Feb Done! Mar Q2 forecast All of these Some of these None of these
  47. 47. Release burnup chart Henrik Kniberg Delivered features Date
  48. 48. Fixed scope forecast Henrik Kniberg Delivered features Date When will all of this be done? Around week 27-30
  49. 49. Fixed time forecast Henrik Kniberg Date What will be done by Christmas? Some of these All of these Delivered features
  50. 50. Fixed time & scope forecast Henrik Kniberg Date Can we get all of THIS done... Delivered features ....by Christmas? No. That is unrealistic.
  51. 51. 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.
  52. 52. ¿…por qué seguimos utilizando el modelo tradicional? Eh! Un momento…! …mmmm…. …entonces….
  53. 53. Insanity: doing the same thing over and over again and expecting different results. “ ”
  54. 54. La única persona que desea un cambio es un bebé con el pañal mojado. Anónimo (atribuido a Mark Twain) “ ”
  55. 55. http://upload.wikimedia.org/wikipedia/commons/f/f3/Uncle_Sam_(pointing_finger).jpg ¿Qué estás haciendo TÚ para cambiar?
  56. 56. 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%
  57. 57. 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 “ ”
  58. 58. 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
  59. 59. 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
  60. 60. ¿Qué es Agile? Agile es entrega temprana de valor de negocio. “ ”Henrik Kniberg Consultor, Agile & Lean Coach
  61. 61. 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.
  62. 62. 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
  63. 63. 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
  64. 64. Contratos en proyectos ágiles Colaboración con el cliente sobre negociación contractual Más importante Importante
  65. 65. ….¿Es esto un contrato ágil? :-)
  66. 66.  Money for Nothing & Changes for Free
  67. 67. 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
  68. 68. Stop Starting, Start Finishing Pull vs Push
  69. 69. 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
  70. 70. Pending Doing Done Kanban Board
  71. 71. Pending Developing Testing Done Problems Kanban Board
  72. 72. Capacidad
  73. 73. 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
  74. 74. Kanban kick-start example http://www.crisp.se/file-uploads/kanban-example.pdf
  75. 75. Visual Management http://www.flickr.com/photos/yveshanoulle/
  76. 76. Low-tech, Multipurpose, Easy to Adapt & Understand
  77. 77. ¿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
  78. 78. 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
  79. 79. 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
  80. 80. User Stories User Stories Applied: For Agile Software Development Mike Cohn 2004
  81. 81. User Story Pattern As a <user role> I can <activity> so that <business value>
  82. 82. 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
  83. 83. 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)
  84. 84. 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
  85. 85. 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-
  86. 86. Planning Poker http://www.mountaingoatsoftware.com/agile/planning-poker
  87. 87. Relative sizing ½, 1, 2, 3, 5, 8, 13, 20, 40, 100
  88. 88. Affinity Estimating
  89. 89. 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
  90. 90. eXtreme Programming Practices Valores: Simplicidad Comunicación Feedback Coraje http://xprogramming.com
  91. 91. Releasing must be REALLY easy Henrik Kniberg Req Code Test Release! Release = Drama! Release = Routine
  92. 92. ¿Por qué aplicar técnicas ágiles? Porque funcionan… …. y es más divertido!
  93. 93. The Fun Theory
  94. 94. Ops…. x 50? x 500? x 5.000?
  95. 95. 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> <Please add your challenge here> <Please add your challenge here>
  96. 96. 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
  97. 97. Spotify Henrik Kniberg Tribe Tribe Tribe TribeTribe Tribe
  98. 98. PO PO PO Tribe Tribe lead PO PO PO PO Tribe Chapter Chapter Tribe lead PO Chapter Chapter Guild Spotify
  99. 99. Scaled Agile Framework  Acerca de SAFe  Estructura de SAFe  Roles, ceremonias, trenes y escalabilidad  Casos de éxito y siguientes pasos
  100. 100. 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
  101. 101. Estructura de SAFe Scaled Agile Framework
  102. 102. 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
  103. 103. 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
  104. 104. Iteraciones a nivel de equipo con ScrumXP
  105. 105. Equipos ágiles con ScrumXP Los equipos ágiles ScrumXP están basados en equipos Scrum, con algunas variaciones que facilitan su escalabilidad
  106. 106. 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
  107. 107. 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.
  108. 108. 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
  109. 109. 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
  110. 110. 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
  111. 111. Roles, ceremonias, trenes y escalabilidad
  112. 112. 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
  113. 113. 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
  114. 114. Agile Release Train Un Agile Release Train es en realidad un fractal de los sprints de los equipos, a nivel de Programa
  115. 115. Agile Release Train Compartir la misma cadencia no es suficiente…..
  116. 116. Agile Release Train … es necesaria una sincronización entre equipos de un mismo programa para garantizar la entrega coordinada
  117. 117. How Big Agile Release Trains can be?
  118. 118. Release Planning Meeting
  119. 119. Agenda para una Release Planning Meeting
  120. 120. Ubicación de la Release Planning Meeting dentro de la candencia - HIP
  121. 121. 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.
  122. 122. 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
  123. 123. Casos de éxito – Empezando a andar
  124. 124. Experiencias de netmind con SAFe
  125. 125. 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)
  126. 126. Y además…. 
  127. 127. Créditos      
  128. 128. F O C U S Q U A L I T Y E X P E R I E N C E 
  1. ¿Le ha llamado la atención una diapositiva en particular?

    Recortar diapositivas es una manera útil de recopilar información importante para consultarla más tarde.

×