Crea tu mapa de proyecto para llegar a buen puerto
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Crea tu mapa de proyecto para llegar a buen puerto

on

  • 2,786 views

Técnica de visualización del alcance de proyecto y planificación basada en diversos mapas de producto. ...

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

Statistics

Views

Total Views
2,786
Views on SlideShare
2,716
Embed Views
70

Actions

Likes
10
Downloads
165
Comments
0

5 Embeds 70

http://www.scoop.it 40
http://www.linkedin.com 11
https://www.linkedin.com 10
http://www.slashdocs.com 5
https://twitter.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Crea tu mapa de proyecto para llegar a buen puerto Presentation Transcript

  • 1. Crea tu mapa de proyecto para llegar a buen puertoSesión CAS 2012Octubre 2012V 1.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óncontinua, wikis, etc.) para que los clientes pudiesen dirigir suspropios proyectos. Actualmente, desde el Agile Excellence Centerde everis, se dedica a ayudar a grandes organizaciones a mejorarsu efectividad y eficiencia bajos principios Agile y Lean, así comoa entrenar a equipos en Scrum y Kanban.Xavier Albaladejo es fundador de proyectosagiles.org, coordinadordel Postgrado en Métodos ágiles de La Salle, Certified ScrumMaster, colaborador de Agile Barcelona y miembro de la Juntadirectiva de Agile-Spain.Contacto: xavier dot albaladejo dot ezequiel at everis dot com AGILE EXCELLENCE CENTER Gobierno TI – UN Tecnología 2
  • 3. Índice Actividades para la creación de un roadmap de proyecto Técnica de la que se ha derivado la presente técnica User Story de Mapa de Producto Técnicas de Mappingconceptualización deproducto, de usuarios y creatividad Elaboración de mapas de la solución Planificación Mapa de producto Determinar Priorización Calendarización alcance Inception Identificar Product personas clave Backlog Mapas de empatía Caracterizar Stakehol- Modelo der requisitos de Mapping Dominio Estimar Design Thinking Mapa de Identificar arquitec- riesgos y tura mitigaciones 3
  • 4. Índice1. Qué NO vamos a explicar ahora 1. Inception 2. Mapas de empatía 3. Design Thinking 4. User Story Mapping2. Mapas 1. Mapa de producto 2. Mapa de arquitectura 3. Mapa de información3. Planificación4. Bonus track 1. Stakeholder mapping 2. Videos de la técnica 4
  • 5. Índice1. Qué NO vamos a explicar ahora 1. Inception 2. Mapas de empatía 3. Design Thinking 4. User Story Mapping2. Mapas 1. Mapa de producto 2. Mapa de arquitectura 3. Mapa de información3. Planificación4. Bonus track 1. Stakeholder mapping 2. Videos de la técnica 5
  • 6. Qué NO vamos a explicar ahoraInception 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 6
  • 7. Qué NO vamos a explicar ahoraMapas de empatía http://www.bigvisible.com/2012/06/what-is-an-empathy-map/ 7
  • 8. Qué NO vamos a explicar ahoraDesign thinkingPensamiento creativo en acción 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. 8
  • 9. Qué NO vamos a explicar ahora User Story MappingMenos necesario / opcional La técnica de Mapas que explicaremos está inspirada en User Story Mapping time The backbone + time first release The walking skeleton second releaseNecessity - third release www.agileproductdesign.com/blog/the_new_backlog.html 9
  • 10. Índice1. Qué NO vamos a explicar ahora 1. Inception 2. Mapas de empatía 3. Design Thinking 4. User Story Mapping2. Mapas 1. Mapa de producto 2. Mapa de arquitectura 3. Mapa de información3. Planificación4. Bonus track 1. Stakeholder mapping 2. Videos de la técnica 10
  • 11. MapasDescubrir el puzzleDado que vamos a desarrollar unproducto de manera iterativa eincremental, el primer paso esdescubrir cuales son las piezasfuncionales y técnicas de que estácompuesto y cuáles son las másimportantes desde el punto de vistadel cliente/usuario/consumidor.Este descubrimiento se puede realizaren formato workshop en laconceptualización del proyecto(Inception), en la Fase 0 de Scrum.Las modificaciones sobre este puzle(cambios de prioridades, nuevaspiezas, piezas a quitar) se vanrevisando en las reuniones deProduct Backlog Refinement (oGrooming).Para ello se pueden elaborar demanera colaborativa “mapas” omodelos a alto nivel según lasperspectivas anteriores. 11
  • 12. Mapa de productoDeterminar el alcanceComo ayuda para determinar el alcance Ejemplo:del producto o proyecto, puede ser útildisponer los requisitos en un “marco”que permita visualizar las diferentes ÁREApartes del producto (o el alcance del FUNCIONAL Aproyecto). Esto permite identificar elgrado de cobertura o impacto delproyecto en cada zona, así como ver SUBÁREA SUBÁREA FUNCIONAL FUNCIONALcuáles no están cubiertas. A1 A1Es conveniente que este “marco” esté Requi Requi sito Requisito sitoexpresado desde la visión de los básediferentes usuarios / consumidores. Requi Requi RequiPor ejemplo: áreas funcionales, mapa sito sito sito Requi sitode navegación de una web, partes deun producto, servicios al cliente, etc. Requi Requi Requi Requi Requi sito sito sito sito sitoSe puede utilizar una distribución Requisitosespacial en dos dimensiones para especializados Requi Requiindicar, por ejemplo, división o sito sitoºrefinamiento de requisitos (más allá dela funcionalidad básica), de manera que Requi Requi sito sitopuedan ser estimados y priorizadosindependientemente, para serdesarrollados en momentos diferentesdel tiempo (desarrollo incremental). 12
  • 13. Mapa de productoIdentificar personas claveEs conveniente identificar a las Ejemplo:personas clave de la organización Stakeholders y usuarios clave quecliente que deberán participar durante proporcionaránel proyecto para proporcionar la ÁREA información dedirección, alineamiento, información FUNCIONAL A STAKE HOLDER 1 KEY USER Y priorización,de priorización, detalle y feedback detalle y feedback de los requisitosnecesario (stakeholders, usuarios de esta áreafinales y personal técnico del cliente). SUBÁREA SUBÁREA funcional FUNCIONAL FUNCIONALTambién puede ser de interés identificar A1 A1personas clave en la organización Requi Requi sito sitoproveedora que proporcionarán apoyoal proyecto durante su ejecución. Requi Requi Requi sito RequiComo resultado, se asocian personas sito sito sitoconcretas a las partes del productodonde tienen más conocimiento o es Requi Requi Requi Requi Requi sito sito sito sito sitonecesaria su participación. Requi Requi sito sitoº Requi Requi sito sito 13
  • 14. Mapa de productoCaracterizar los requisitosPueden utilizarse colores diversos para Ejemplo:clasificar los requisitos en: Tipos de funcionalidades: ÁREA capacidades “out-of-the-box” FUNCIONAL A STAKE KEY USER Y respecto necesidades de desarrollo HOLDER 1 a medida, etc. Comportamientos funcionales: SUBÁREA SUBÁREA Requisito poco básicos vs refinamientos / FUNCIONAL FUNCIONAL maduro o A1 A1 sobre el cual el especializaciones / cursos Requi Producto out-of-the- equipo tiene alternativos. Esto facilitará el sito box, sólo necesita Requi que investigar sito desarrollo iterativo e incremental del parametrización. más, por producto, de manera transversal a ejemplo para Requi Requi Requi sito Requi conocer su diversas áreas funcionales, con la sito sito sito viabilidad idea de comenzar con un “walking skeleton” e ir añadiendo nuevas Requi Requi Requi Requi Requi sito sito sito sito sito piezas (músculos) al puzle, en Desarrollo a medida función de su retorno de inversión o Requi Requi de riesgos a resolver. sito sitoº Tipos de usuario (las “Personas” de la técnica de User eXperience). Requi Requi sito sito Requisitos sobre los que falta información o es necesario investigar. Etc. 14
  • 15. Mapa de productoEstimarConforme se van identificando Ejemplo:requisitos, el equipo realiza preguntasde dimensionamiento al ProductOwner / stakeholders / usuarios ÁREAfinales, con el objeto de hacer una FUNCIONAL A STAKE HOLDER 1 KEY USER Yprimera y sencilla cuantificación de lacomplejidad de cada elemento. SUBÁREA SUBÁREAPara ello, se puede realizar una primera FUNCIONAL FUNCIONALestimación relativa, por ejemplo A1 A1utilizando “gomets” (pegatinas): a Requi Requi sito sitomayor número, mayor complejidad,mayor “talla” del requisito (S, M, L XL). Requi Requi Requi sito RequiDe esta manera, todos los participantes sito sito sitoen el workshop comparten la mismavisión a alto nivel de qué hay que hacer Requi Requi Requi Requi Requi sito sito sito sito sitoen el proyecto, del valor que aporta Muchos gometscada requisito, del funcionamiento de azules: requisito Requi costoso Requilas diferentes partes del producto y de sito sitoºla complejidad asociada: “Cuando dicesque en este requisito tiene que suceder Requi Requi sitoX, ¿estás pensando en “esto” y “esto”? sito¿o bien “esto” no es necesario (con locual sería menos costoso)? 15
  • 16. Mapa de productoIdentificar riesgos y mitigacionesEs conveniente identificar sobre qué Ejemplo:requisitos va a existir algún tipo deriesgo. En este punto, el equipo detrabajo y el cliente indican los ÁREAobjetivos/requisitos donde creen que FUNCIONAL A STAKE HOLDER 1 KEY USER Ypuede haber más dificultad para suconsecución (por dependencias depersonas concretas en la organización SUBÁREA SUBÁREA FUNCIONAL FUNCIONALcliente, por complejidad de los A1 A1requisitos, por posibles dificultades Requi Requitecnológicas, etc.) y realizan un primer sito sitoplanteamiento de mitigaciones. Requi Requi Requi sito sito sito Requi sito Requi Requi Requi Requi Requi sito sito sito sito sito Requi Requi Riesgo X Mitigación sito sitoº Requi Requi sito sito Muchos gomets Descrip rojos: requisito ción Mitigación arriesgado riesgo 16
  • 17. Mapa de productoPriorizarDe manera muy sencilla se puede Ejemplo:realizar una primera priorización, por Separamosejemplo realizando al Product Owner las espacialmentesiguientes preguntas : los post-its según ÁREA sean de alta o FUNCIONAL A STAKE KEY USER Y1. Qué requisitos son especialmente baja prioridad HOLDER 1 importantes para su empresa / departamento / usuarios finales / SUBÁREA SUBÁREA consumidor, qué requisitos requiere FUNCIONAL FUNCIONAL Alta “tocar” antes, o para qué requisitos A1 Alta A1 prioridad prioridad quiere asegurar con suficiente tiempo Requi Requi sito sito que el equipo ha entendido lo que se necesita. De este modo, cuando se Requi Requi Requi esté a mitad del proyecto la parte más sito sito sito Requi sito importante del producto ya estará desarrollada, sólo quedará ir Requi Baja añadiendo piezas de menor sito prioridad Baja importancia sobre un producto ya prioridad estable, testeado y revisado. Requi Requi Requi Requi Requi sito sito sito sito2. Qué requisitos no son tan sito relevantes en el proyecto.Con estas dos sencillas preguntas Baja Bajaautomáticamente aparecen tres grupos prioridad prioridad Requide requisitos, a partir de los cuales se Requi Requi sitoº Riesgo X Mitigación sito sitopuede refinar la priorización (utilizandotécnicas más complejas si es necesario). 17
  • 18. Mapa de producto Visión global 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. ÁREA ÁREA FUNCIONAL ÁREA FUNCIONAL A FUNCIONAL STAKE HOLDER 1 KEY USER Y B STAKE HOLDER 1 C STAKE HOLDER 1 SUBÁREASUBÁREA SUBÁREA SUBÁREA FUNCIONAL A1FUNCIONAL A1 FUNCIONAL A1 SUBÁREA SUBÁREA FUNCIONAL A1 FUNCIONAL A1 FUNCIONAL A1 Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisitoº Riesgo X Requisito Mitigación Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisito Requisitoº Requisito Requisito Requisito Mitigación Requisito Riesgo x Requisito Requisito Requisito Requisito Requisito Requisito Requisito 18
  • 19. Mapa de arquitecturaComponentes, riesgos y dependencias no eludiblesEn paralelo a la elaboración del mapafuncional (el “qué”) se puede ir creandoun mapa de técnico o mapa dearquitectura (el “cómo”) indicando SISTEMA 1también las dependencias eintegraciones entre componentes,así como los riesgos que puedan SUBSISTEMA SUBSISTEMA A Bexistir asociados a algunoscomponentes, sistemas o integraciones. Compo Compo Compo Compo nente Compo Compo CompoEn principio, el orden de desarrollo de nente nente nente nente nente nentelos componentes técnicos de lasolución estará alineado con lanecesidad de cumplir con la priorizaciónde los objetivos / requisitos del Relaciones o integracionesproyecto. Sin embargo, hay queconsiderar que también el plan de Compo Compo Compo Riesgo Mitigación Compo nente nente nente A nenteobjetivos / requisitos podrá estarcondicionado por las dependenciastécnicas que sean difíciles dedesacoplar, por lo cual deberán serrespetadas en la planificación de SISTEMA 2objetivos / requisitos. 19
  • 20. Mapa de informaciónModelo del dominioSi 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/usuariosfinales, un modelo sencillo (a alto nivel) de las entidades de información y sus relaciones (Modelo delDominio).Notar que, como los modelos anteriores, este mapa de información se puede ir modificando y ajustando cadaiteración y/o release (por ejemplo en los los workshops de toma detallada de requisitos y de ReleasePlanning. 20
  • 21. Índice1. Qué NO vamos a explicar ahora 1. Inception 2. Mapas de empatía 3. Design Thinking 4. User Story Mapping2. Mapas 1. Mapa de producto 2. Mapa de arquitectura 3. Mapa de información3. Planificación4. Bonus tracks 1. Stakeholder mapping 2. Videos de la técnica 21
  • 22. PlanificaciónCalendarización en Sprints y ReleasesComo primer paso para elaborar el Product Backlog y el roadmap de arquitectura, los requisitos y susolución técnica se pueden distribuir sobre una línea temporal, a través de diferentes iteraciones yreleases, 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: Walking skeleton Release 1 Tiempo SUBÁREA Requisito Requisito FUNCIONAL A1 Requisito Requisito Requisito Requisito Requisito Requisito ÁREAFUNCIONAL A SUBÁREA Requisito Requisito Requisito Requisito Requisitoº Riesgo X STAKE FUNCIONAL A1 Product HOLDER 1 KEY USER Y Requisito Requisito Mitigación Backlog Requisito Requisito Requisito Requisito ÁREA Requisito Requisito Requisito Requisito SUBÁREA Requisito FUNCIONAL A1FUNCIONAL B STAKE HOLDER 1 SUBÁREA Requisito Requisito Roadmap SISTEMA 1 Requisito Requisito Requisito Requisito Riesgo X FUNCIONAL A1 Requisito de Requisito Mitigación STAKE arquitectura HOLDER 1 STAKE HOLDER 1 22
  • 23. PlanificaciónEjemplo real Iteraciones, cuatrimestres o releases (en columnas) Alta prioridad Baja prioridad Carril por área funcional, equipo Áreas funcionales de trabajo, etc. Áreas arquitectónicas Riesgo Mitigación Requisito costoso 23
  • 24. Planificación Carriles y relaciones 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 Infraestructuras necesariasEventos que suceden al margen del proyecto pero quepueden impactar en él Compromisos, dependencias con terceros, vacaciones www.enthiosys.com/agile-roadmaps 24
  • 25. PlanificaciónVisibilidad de la lógica de las decisiones y de las relaciones Cuerdas www.enthiosys.com/agile-roadmaps 25
  • 26. PlanificaciónVisibilidad de la lógica de las decisiones y de las relacionesColores para identificardependenciasentre carriles www.enthiosys.com/agile-roadmaps 26
  • 27. PlanificaciónVisión global compartidaEl uso de diferentes mapas (funcionales, técnicos y de información) y la aplicación sistemática de pasos paraestimación, priorización e identificación de riesgos, proporcionan una visión global del proyecto. Losprincipales beneficios se derivan de realizar este trabajo en modo workshop colaborativo, ya que facilita quetodos los participantes (parte cliente incluyendo stakeholders y equipo proveedor) puedan mantenerconversaciones, compartir, alinear y consensuar una misma visión del alcance inicial del proyecto, susprioridades, 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) 27
  • 28. PlanificaciónSeguimiento del progreso y gestión de cambiosEl 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:  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 Requisitos baseline ya aceptados por el cliente Requisitos baseline pendientes Requisitos añadidos o cambiados Relación entre requisitos 28
  • 29. Índice1. Qué NO vamos a explicar ahora 1. Inception 2. Mapas de empatía 3. Design Thinking 4. User Story Mapping2. Mapas 1. Mapa de producto 2. Mapa de arquitectura 3. Mapa de información3. Planificación4. Bonus tracks 1. Stakeholder mapping 2. Videos de la técnica 29
  • 30. Stakeholder mappingQuié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). 30
  • 31. Videos de la técnicaVideos cortos donde se indica cómo realizar en una planificación de proyecto utilizando esta técnica (encastellano, con subtítulos en inglés) .Video Descripción1 - 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). 31
  • 32. Crea tu mapa de proyecto para llegar a buen puertoPreguntas 32
  • 33. everis.com