Crea tu mapa de proyecto para llegar a buen puerto
Octubre 2012
V 1.3
Sesión CAS 2012
2
Xavier Albaladejo - Agile-Lean Coach y experto en Gobierno TI,
empezó a utilizar prácticas eXtreme Programming en 2002
(...
3
Índice
Mapa de
producto
Inception
Design Thinking
Mapas de
empatía
User Story
MappingTécnicas de
conceptualización de
pr...
4
Índice
1. Qué NO vamos a explicar ahora
1. Inception
2. Mapas de empatía
3. Design Thinking
4. User Story Mapping
2. Map...
5
Índice
1. Qué NO vamos a explicar ahora
1. Inception
2. Mapas de empatía
3. Design Thinking
4. User Story Mapping
2. Map...
6
Qué NO vamos a explicar ahora
Inception
1. Why Are We Here?
2. Elevator Pitch
3. Product Box
4. NOT List
5. Meet Your Ne...
7
Qué NO vamos a explicar ahora
Mapas de empatía
http://www.bigvisible.com/2012/06/what-is-an-empathy-map/
8
Qué NO vamos a explicar ahora
Design thinking
Empatía para el contexto del problema, creatividad en la
generación de con...
9
Qué NO vamos a explicar ahora
User Story Mapping
Menosnecesario/opcional
time
Necessity
The backbone
The walking skeleto...
10
Índice
1. Qué NO vamos a explicar ahora
1. Inception
2. Mapas de empatía
3. Design Thinking
4. User Story Mapping
2. Ma...
11
Mapas
Descubrir el puzzle
Dado que vamos a desarrollar un
producto de manera iterativa e
incremental, el primer paso es...
12
Mapa de producto
Determinar el alcance
Requi
sito
Como ayuda para determinar el alcance
del producto o proyecto, puede ...
13
Mapa de producto
Identificar personas clave
Requi
sito
STAKE
HOLDER 1
KEY USER Y
Es conveniente identificar a las
perso...
14
Mapa de producto
Caracterizar los requisitos
Requi
sito
ÁREA
FUNCIONAL A
Pueden utilizarse colores diversos para
clasif...
15
Mapa de producto
Estimar
Requi
sito
ÁREA
FUNCIONAL A
SUBÁREA
FUNCIONAL
A1
SUBÁREA
FUNCIONAL
A2
Requi
sito
Requi
sitoº
R...
16
Mapa de producto
Identificar riesgos y mitigaciones
Requi
sito
ÁREA
FUNCIONAL A
SUBÁREA
FUNCIONAL
A1
SUBÁREA
FUNCIONAL
...
17
Mapa de producto
Priorizar
De manera muy sencilla se puede
realizar una primera priorización, por
ejemplo realizando al...
18
Mapa de producto
Visión global
Requisito
SUBÁREA
FUNCIONAL A1
Requisito
Requisito
Requisito
Requisito
Requisito
Requisi...
19
Mapa de arquitectura
Componentes, riesgos y dependencias no eludibles
En paralelo a la elaboración del mapa
funcional (...
20
Mapa de información
Modelo del dominio
Si se está desarrollando un Sistema de Información, como complemento a los mapas...
21
Índice
1. Qué NO vamos a explicar ahora
1. Inception
2. Mapas de empatía
3. Design Thinking
4. User Story Mapping
2. Ma...
22
Planificación
Calendarización en Sprints y Releases
Como primer paso para elaborar el Product Backlog y el roadmap de a...
23
Planificación
Ejemplo real
ÁreasfuncionalesÁreasarquitectónicas
Alta prioridad
Riesgo Mitigación
Baja prioridad
Requisi...
24
Planificación
Carriles y relaciones
www.enthiosys.com/agile-roadmaps
También pueden ser interesantes poner carriles adi...
25
Planificación
Visibilidad de la lógica de las decisiones y de las relaciones
Hilos,
cintas de
colores
www.enthiosys.com...
26
Planificación
Visibilidad de la lógica de las decisiones y de las relaciones
Colores para
identificar
dependencias
entr...
27
Planificación
Visión global compartida
El uso de diferentes mapas (funcionales, técnicos y de información) y la aplicac...
28
Planificación
Seguimiento del progreso y gestión de cambios
El uso de estos mapas durante el proyecto también permite:
...
29
Índice
1. Qué NO vamos a explicar ahora
1. Inception
2. Mapas de empatía
3. Design Thinking
4. User Story Mapping
2. Ma...
30
Stakeholder mapping
Quién está impactado y quién podría poner “palos en las ruedas”
 Flechas entre stakeholders.
 Col...
31
Videos de la técnica
Videos cortos donde se indica cómo realizar en una planificación de proyecto utilizando esta técni...
32
Crea tu mapa de proyecto para llegar a buen puerto
Preguntas
everis.com
Upcoming SlideShare
Loading in...5
×

[es] Crea tu mapa de proyecto para llegar a buen puerto - CAS2012

3,822

Published on

Técnica de visualización del alcance de proyecto y planificación basada en diversos mapas de producto.
Videos cortos (5'-10') donde se explica la técnica en detalle: http://www.proyectosagiles.org/videos-cortos-planificacion-agil

English version: http://www.slideshare.net/xalbaladejo/cas2012-create-yourprojectmap14

Published in: Technology

[es] Crea tu mapa de proyecto para llegar a buen puerto - CAS2012

  1. 1. Crea tu mapa de proyecto para llegar a buen puerto Octubre 2012 V 1.3 Sesión CAS 2012
  2. 2. 2 Xavier Albaladejo - Agile-Lean Coach y experto en Gobierno TI, empezó a utilizar prácticas eXtreme Programming en 2002 (entregas rápidas de producto, tests unitarios con integración continua, wikis, etc.) para que los clientes pudiesen dirigir sus propios proyectos. Actualmente, desde el Agile Excellence Center de everis, se dedica a ayudar a grandes organizaciones a ser más rápidas y efectivas bajos principios Agile y Lean, así como a entrenar a equipos en Scrum y Kanban. Xavier Albaladejo es coordinador del Postgrado en Métodos ágiles de La Salle, fundador de proyectosagiles.org, Certified Scrum Practicioner, colaborador de Agile Barcelona y miembro de la Junta directiva de Agile-Spain. Contacto: xavier dot albaladejo dot ezequiel at everis dot com AGILE EXCELLENCE CENTER Gobierno TI – UN Tecnología
  3. 3. 3 Índice Mapa de producto Inception Design Thinking Mapas de empatía User Story MappingTécnicas de conceptualización de producto, de usuarios y creatividad Determinar alcance Identificar personas clave Stakehol- der Mapping Caracterizar requisitos Estimar Identificar riesgos y mitigaciones Modelo de Dominio Elaboración de mapas de la solución Mapa de arquitec- tura Planificación Priorización Calendarización Técnica de la que se ha derivado la presente técnica de Mapa de Producto Product Backlog Actividades para la creación de un roadmap de proyecto
  4. 4. 4 Índice 1. Qué NO vamos a explicar ahora 1. Inception 2. Mapas de empatía 3. Design Thinking 4. User Story Mapping 2. Mapas 1. Mapa de producto 2. Mapa de arquitectura 3. Mapa de información 3. Planificación 4. Bonus track 1. Stakeholder mapping 2. Videos de la técnica
  5. 5. 5 Índice 1. Qué NO vamos a explicar ahora 1. Inception 2. Mapas de empatía 3. Design Thinking 4. User Story Mapping 2. Mapas 1. Mapa de producto 2. Mapa de arquitectura 3. Mapa de información 3. Planificación 4. Bonus track 1. Stakeholder mapping 2. Videos de la técnica
  6. 6. 6 Qué NO vamos a explicar ahora Inception 1. Why Are We Here? 2. Elevator Pitch 3. Product Box 4. NOT List 5. Meet Your Neighbors – project community 6. Show the Solution 7. What Keeps Us Up at Night 8. Size It Up 9. What‟s Going to Give 10. What It’s Going to Take Esta presentación tratará de aspectos relacionados con los puntos en verde
  7. 7. 7 Qué NO vamos a explicar ahora Mapas de empatía http://www.bigvisible.com/2012/06/what-is-an-empathy-map/
  8. 8. 8 Qué NO vamos a explicar ahora Design thinking Empatía para el contexto del problema, creatividad en la generación de conocimiento y soluciones y racionalidad para analizar y adecuar soluciones al contexto. Pensamiento creativo en acción
  9. 9. 9 Qué NO vamos a explicar ahora User Story Mapping Menosnecesario/opcional time Necessity The backbone The walking skeleton time first release second release third release- + www.agileproductdesign.com/blog/the_new_backlog.html La técnica de Mapas que explicaremos está inspirada en User Story Mapping
  10. 10. 10 Índice 1. Qué NO vamos a explicar ahora 1. Inception 2. Mapas de empatía 3. Design Thinking 4. User Story Mapping 2. Mapas 1. Mapa de producto 2. Mapa de arquitectura 3. Mapa de información 3. Planificación 4. Bonus track 1. Stakeholder mapping 2. Videos de la técnica
  11. 11. 11 Mapas Descubrir el puzzle Dado que vamos a desarrollar un producto de manera iterativa e incremental, el primer paso es descubrir cuales son las piezas funcionales y técnicas de que está compuesto y cuáles son las más importantes desde el punto de vista del cliente/usuario/consumidor. Este descubrimiento se puede realizar en formato workshop en la conceptualización del proyecto (Inception), en la Fase 0 de Scrum. Estos “mapas” o modelos a alto nivel funcionales y técnicos se elaboran de manera colaborativa. Las modificaciones sobre este puzle (cambios de prioridades, nuevas piezas, piezas a quitar) se realizan en las reuniones de Product Backlog Refinement (o Grooming).
  12. 12. 12 Mapa de producto Determinar el alcance Requi sito Como ayuda para determinar el alcance del producto o proyecto, puede ser útil disponer los requisitos en un “marco” que permita visualizar las diferentes partes del producto (o el alcance del proyecto). Esto permite identificar el grado de cobertura o impacto del proyecto en cada zona, así como ver cuáles no están cubiertas. Es conveniente que este “marco” esté expresado desde la visión de los diferentes usuarios / consumidores. Por ejemplo: áreas funcionales, mapa de navegación de una web, partes de un producto, servicios al cliente, etc. Se puede utilizar una distribución espacial en dos dimensiones para indicar, por ejemplo, división o refinamiento de requisitos (más allá de la funcionalidad básica), de manera que puedan ser estimados y priorizados independientemente, para ser desarrollados en momentos diferentes del tiempo (desarrollo incremental). SUBÁREA FUNCIONAL A1 SUBÁREA FUNCIONAL A1 Requi sito Requi sitoº Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requisito báse Requisitos especializados Requi sito Requi sito Requi sito Ejemplo: ÁREA FUNCIONAL A
  13. 13. 13 Mapa de producto Identificar personas clave Requi sito STAKE HOLDER 1 KEY USER Y Es conveniente identificar a las personas clave de la organización cliente que deberán participar durante el proyecto para proporcionar la dirección, alineamiento, información de priorización, detalle y feedback necesario (stakeholders, usuarios finales y personal técnico del cliente). También puede ser de interés identificar personas clave en la organización proveedora que proporcionarán apoyo al proyecto durante su ejecución. Como resultado, se asocian personas concretas a las partes del producto donde tienen más conocimiento o es necesaria su participación directa. SUBÁREA FUNCIONAL A1 SUBÁREA FUNCIONAL A2 Requi sito Requi sitoº Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Stakeholders y usuarios clave que proporcionarán información de priorización, detalle y feedback de los requisitos de esta área funcional Requi sito Requi sito Requi sito Ejemplo: ÁREA FUNCIONAL A
  14. 14. 14 Mapa de producto Caracterizar los requisitos Requi sito ÁREA FUNCIONAL A Pueden utilizarse colores diversos para clasificar los requisitos en:  Tipos de funcionalidades: capacidades “out-of-the-box” respecto necesidades de desarrollo a medida, etc.  Comportamientos funcionales: básicos vs refinamientos / especializaciones / cursos alternativos. Esto facilitará el desarrollo iterativo e incremental del producto, de manera transversal a diversas áreas funcionales, con la intención de comenzar creando un “walking skeleton” e ir añadiendo nuevas piezas (músculos) al puzle, en función de su retorno de inversión o de riesgos a resolver.  Tipos de usuario (las “Personas” de la técnica de User eXperience).  Requisitos sobre los que falta información o es necesario investigar.  Etc. SUBÁREA FUNCIONAL A1 SUBÁREA FUNCIONAL A2 Requi sito Requi sitoº Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Producto out-of-the- box, sólo necesita parametrización. Desarrollo a medida Requisito poco maduro o sobre el cual el equipo tiene que investigar más, por ejemplo para conocer su viabilidad STAKE HOLDER 1 KEY USER Y Requi sito Ejemplo:
  15. 15. 15 Mapa de producto Estimar Requi sito ÁREA FUNCIONAL A SUBÁREA FUNCIONAL A1 SUBÁREA FUNCIONAL A2 Requi sito Requi sitoº Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Muchos gomets azules: requisito costoso STAKE HOLDER 1 KEY USER Y Conforme se van identificando requisitos, el equipo realiza preguntas de dimensionamiento al Product Owner / stakeholders / usuarios finales, con el objeto de hacer una primera y sencilla cuantificación de la complejidad de cada elemento. Para ello, se puede realizar una primera estimación relativa, por ejemplo utilizando “gomets” (pegatinas): a mayor número, mayor complejidad, mayor “talla” del requisito (S, M, L XL). De esta manera, todos los participantes en el workshop comparten la misma visión a alto nivel de qué hay que hacer en el proyecto, del valor que aporta cada requisito, del funcionamiento de las diferentes partes del producto y de la complejidad asociada: “Cuando dices que en este requisito tiene que suceder X, ¿estás pensando en “esto” y “esto”? ¿o bien “esto” no es necesario (con lo cual sería menos costoso)? Ejemplo:
  16. 16. 16 Mapa de producto Identificar riesgos y mitigaciones Requi sito ÁREA FUNCIONAL A SUBÁREA FUNCIONAL A1 SUBÁREA FUNCIONAL A2 Requi sito Requi sitoº Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito STAKE HOLDER 1 KEY USER Y Es conveniente identificar sobre qué requisitos va a existir algún tipo de riesgo. En este punto, el equipo de trabajo y el cliente indican los objetivos/requisitos donde creen que puede haber más dificultad para su consecución (por dependencias de personas concretas en la organización cliente, por complejidad de los requisitos, por posibles dificultades tecnológicas, etc.) y realizan un primer planteamiento de mitigaciones. Muchos gomets rojos: requisito arriesgado Mitigación Mitigación Ejemplo: Riesgo X Descrip ción riesgo
  17. 17. 17 Mapa de producto Priorizar De manera muy sencilla se puede realizar una primera priorización, por ejemplo realizando al Product Owner las siguientes preguntas : 1. Qué requisitos son especialmente importantes para su empresa / departamento / usuarios finales / consumidor, qué requisitos requiere “tocar” antes, o para qué requisitos quiere asegurar con suficiente tiempo que el equipo ha entendido lo que se necesita. De este modo, cuando se esté a mitad del proyecto la parte más importante del producto ya estará desarrollada, sólo quedará ir añadiendo piezas de menor importancia sobre un producto ya estable, testeado y revisado. 2. Qué requisitos no son tan relevantes en el proyecto. Con estas dos sencillas preguntas automáticamente aparecen tres grupos de requisitos, dentro de los cuales se puede refinar la priorización (utilizando técnicas más complejas si es necesario). Requi sito ÁREA FUNCIONAL A SUBÁREA FUNCIONAL A1 SUBÁREA FUNCIONAL A2 Requi sito Requi sitoº Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Requi sito Ejemplo: STAKE HOLDER 1 KEY USER Y Requi sito Alta prioridad Alta prioridad Baja prioridad Baja prioridad Baja prioridad Separamos espacialmente los post-its según sean de alta o baja prioridad MitigaciónRiesgo X Baja prioridad
  18. 18. 18 Mapa de producto Visión global Requisito SUBÁREA FUNCIONAL A1 Requisito Requisito Requisito Requisito Requisito Requisito ÁREA FUNCIONAL A STAKE HOLDER 1 KEY USER Y Requisito SUBÁREA FUNCIONAL A1 Requisito Requisito Requisito Requisito Requisito Requisito Requisito SUBÁREA FUNCIONAL A1 Requisitoº Requisito Requisito Requisito Requisito Requisito Requisito Mitigación Requisito ÁREA FUNCIONAL B STAKE HOLDER 1 Requisito SUBÁREA FUNCIONAL A1 Requisito Requisito Requisito Requisito Requisito Requisito Requisito ÁREA FUNCIONAL C STAKE HOLDER 1 Requisito SUBÁREA FUNCIONAL A1 Requisito Requisito Requisito Requisito Requisito Requisito Requisito SUBÁREA FUNCIONAL A1 Requisito Requisito Requisito Requisito Requisitoº Requisito Requisito Riesgo x Riesgo X Mitigación Como resultado de los pasos anteriores, en este momento ya se dispone de una visión del alcance del proyecto, dentro de un marco de producto y que no es “plana”, dado que se ha identificado prioridades de manera transversal a todas las áreas o secciones del producto. Esto facilitará la elaboración de un plan de desarrollo iterativo e incremental.
  19. 19. 19 Mapa de arquitectura Componentes, riesgos y dependencias no eludibles En paralelo a la elaboración del mapa funcional (el “qué”) se puede ir creando un mapa de técnico o mapa de arquitectura (el “cómo”) indicando también las dependencias e integraciones entre componentes, así como los riesgos que puedan existir asociados a algunos componentes, sistemas o integraciones. El orden de desarrollo de los componentes técnicos de la solución debería estar alineado con la necesidad de cumplir con la priorización de los objetivos / requisitos del proyecto. Sin embargo, hay que considerar que también el plan de objetivos / requisitos podrá estar condicionado por las dependencias técnicas que sean difíciles de desacoplar, por lo cual deberán ser respetadas en la planificación de objetivos / requisitos. Compo nente SISTEMA 1 SUBSISTEMA A SUBSISTEMA B Compo nente Compo nente Compo nente Compo nente SISTEMA 2 Compo nente Compo nente Compo nente Compo nente Compo nente Compo nente Mitigación Relaciones o integraciones Riesgo A
  20. 20. 20 Mapa de información Modelo del dominio Si se está desarrollando un Sistema de Información, como complemento a los mapas funcionales y técnicos (y en paralelo a su elaboración), es conveniente diagramar, junto con el cliente/stakeholders/usuarios finales, un modelo sencillo (a alto nivel) de las entidades de información y sus relaciones (Modelo del Dominio). Notar que, como los modelos anteriores, este mapa de información se puede ir modificando y ajustando cada iteración y/o release (por ejemplo en los los workshops de toma detallada de requisitos y de Release Planning).
  21. 21. 21 Índice 1. Qué NO vamos a explicar ahora 1. Inception 2. Mapas de empatía 3. Design Thinking 4. User Story Mapping 2. Mapas 1. Mapa de producto 2. Mapa de arquitectura 3. Mapa de información 3. Planificación 4. Bonus tracks 1. Stakeholder mapping 2. Videos de la técnica
  22. 22. 22 Planificación Calendarización en Sprints y Releases Como primer paso para elaborar el Product Backlog y el roadmap de arquitectura, los requisitos y su solución técnica se pueden distribuir sobre una línea temporal, a través de diferentes iteraciones y releases, manteniendo los swimlines (carriles) por área funcional y por sistema técnico). Esto también permite:  Visualizar cómo a nivel técnico se va a ir dando solución a los objetivos/requisitos del proyecto a lo largo del tiempo, explicitando dependencias si es necesario.  Establecer el walking skeleton, el Minimum Viable Product (MVP) y el orden en que se irán añadiendo “piezas” en las diferentes áreas funcionales y técnicas. Ejemplo: Requisito SUBÁREA FUNCIONAL A1 Requisito Requisito Requisito Requisito Requisito Requisito ÁREA FUNCIONAL A RequisitoSUBÁREA FUNCIONAL A1 Requisito Requisito Requisito Requisito Requisito Requisito Requisito SUBÁREA FUNCIONAL A1 RequisitoºRequisito Requisito Requisito Requisito Requisito Requisito Riesgo X Mitigación Requisito ÁREA FUNCIONAL B STAKE HOLDER 1 Requisito SUBÁREA FUNCIONAL A1 Requisito Requisito Requisito RequisitoRequisito Requisito Requisito Requisito STAKE HOLDER 1 KEY USER Y Tiempo Riesgo X Mitigación SISTEMA 1 STAKE HOLDER 1 STAKE HOLDER 1 Product Backlog Roadmap de arquitectura Walking skeleton Release 1
  23. 23. 23 Planificación Ejemplo real ÁreasfuncionalesÁreasarquitectónicas Alta prioridad Riesgo Mitigación Baja prioridad Requisito costoso Carril por área funcional, equipo de trabajo, etc. Iteraciones, cuatrimestres o releases (en columnas)
  24. 24. 24 Planificación Carriles y relaciones www.enthiosys.com/agile-roadmaps También pueden ser interesantes poner carriles adicionales a los ya vistos funcional y técnico: A qué tipo de usuario o mercado se está llegando Eventos que suceden al margen del proyecto pero que pueden impactar en él Compromisos, dependencias con terceros, vacaciones Infraestructuras necesarias
  25. 25. 25 Planificación Visibilidad de la lógica de las decisiones y de las relaciones Hilos, cintas de colores www.enthiosys.com/agile-roadmaps
  26. 26. 26 Planificación Visibilidad de la lógica de las decisiones y de las relaciones Colores para identificar dependencias entre carriles www.enthiosys.com/agile-roadmaps
  27. 27. 27 Planificación Visión global compartida El uso de diferentes mapas (funcionales, técnicos y de información) y la aplicación sistemática de pasos para estimación, priorización e identificación de riesgos, proporcionan una visión global del proyecto. Los principales beneficios se derivan de realizar este trabajo en modo workshop colaborativo, ya que facilita que todos los participantes (parte cliente incluyendo stakeholders y equipo proveedor) puedan mantener conversaciones, compartir, alinear y consensuar una misma visión del alcance inicial del proyecto, sus prioridades, riesgos/dificultades y mitigaciones desde el primer momento, de una manera muy visual y explícita. Workshop de planificación ágil donde participan stakeholders (funcionales y técnicos) de cliente y un equipo de desarrollo de everis, con el soporte de su Agile Excellence Center (Gobierno TI, Tecnología)
  28. 28. 28 Planificación Seguimiento del progreso y gestión de cambios El uso de estos mapas durante el proyecto también permite:  Hacer un seguimiento del progreso respecto al alcance global (entender fácilmente qué queda pendiente de desarrollar).  Visualizar mejor los cambios e incrementos sobre el alcance (por ejemplo señalizando estas situaciones con etiquetas de colores).  Ayudar en la gestión de cambios, dado que evidencian el impacto de un cambio en un “marco” de alcance de producto (a nivel funcional y técnico), lo cual facilita:  Controlar el “scope creep” y tomar mejores decisiones, balancear el impacto de la inclusión de cambios respecto a la consecución en un tiempo razonable de un producto con suficiente coherencia y valor. La visualización del impacto de los cambios ayuda a considerar su oportunidad frente a la incursión en retrasos sobre la fecha inicialmente planificada.  Utilizar el concepto de “change for free” que se utiliza en algunos tipos de contratos ágiles, en el que cuando se introduce una nueva pieza en el puzle se retiran piezas por un tamaño equivalente. Mapa de Producto – Seguimiento del alcance Requisitos baseline pendientes Requisitos añadidos o cambiados Requisitos baseline ya aceptados por el cliente Relación entre requisitos Mapa de producto – Inception
  29. 29. 29 Índice 1. Qué NO vamos a explicar ahora 1. Inception 2. Mapas de empatía 3. Design Thinking 4. User Story Mapping 2. Mapas 1. Mapa de producto 2. Mapa de arquitectura 3. Mapa de información 3. Planificación 4. Bonus tracks 1. Stakeholder mapping 2. Videos de la técnica
  30. 30. 30 Stakeholder mapping Quién está impactado y quién podría poner “palos en las ruedas”  Flechas entre stakeholders.  Colores para tipos de stakeholders/ áreas/departamentos.  Indicar quién es amigo de quién (círculos de influencia/confianza).
  31. 31. 31 Videos de la técnica Videos cortos donde se indica cómo realizar en una planificación de proyecto utilizando esta técnica (en castellano, con subtítulos en inglés) . Video Descripción 1 - Identificar el alcance del proyecto (7„) Identificación de manera ágil el alcance de un proyecto a nivel funcional y técnico, su complejidad y sus riesgos, en un workshop conjuntamente con el cliente. 2 - Planificación ágil (I) – Ordenación (3') Ordenación de los requisitos de un proyecto en función de su valor, coste y riesgo, en un workshop conjuntamente con el cliente. 3 - Planificación ágil (II) – Product Backlog (4') Planificación de un proyecto de manera ágil, iterativa e incremental, en un workshop conjuntamente con el cliente. Como resultado, se crea una visión a alto nivel de iteraciones y entregas (Product Backlog).
  32. 32. 32 Crea tu mapa de proyecto para llegar a buen puerto Preguntas
  33. 33. everis.com
  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.

×