Implantando prácticas ágiles en un contexto multiproyecto

1,092 views
986 views

Published on

Si bien existe abundante material y oferta de cursos de formación para iniciarse en el agilismo, la implantación exitosa en un ámbito industrial sigue siendo un aspecto poco tratado y no resuelto satisfacoriamente.

Un cambio en la forma de trabajo de un equipo conlleva los desafíos evidentes asociados a, por ejemplo, la introducción de una sistematización del trabajo, el cambio de actitud de los integrantes de equipo, el liderazgo necesario para impulsar la iniciativa de implantación, el apoyo de la dirección, la selección de herramientas, etc.

Obviamente todos estos aspectos son claves para una implantación exitosa, sin embargo, hay otro, de carácter más técnico, que ha sido poco atendido y que resulta clave en el proceso de implantación de prácticas ágiles. Cada equipo tiene un contexto particular en cuanto al tipo de productos, servicios o proyectos en los cuales trabaja.

Es bastante usual que un equipo deba gestionar de forma efectiva no sólo un producto, servicio o proyecto sino varios, posiblemente una mezcla de estos tipos y varios a la vez. Cada producto, servicio o proyecto tiene características específicas, con lo cual, aunque se trate de un mismo equipo, si se ignoran dichas diferencias y se aplica un solo enfoque para todo los tipos de trabajo probablemente el desempeño no será el más satisfactorio. Además, aparece un inconveniente adicional cuando se intenta dar una solución especial a cada tipo de trabajo, ¿como gestionar de forma integrada diversos tipos de trabajo y abordados con un mismo equipo?. Finalmente, otra dimensión que complica aún más la implantación de prácticas ágiles es la selección e implantación progresiva de prácticas.

Si bien siempre existe la posibilidad de producir una "revolución" en cuanto a la forma de trabajo del equipo, en la mayoría de los casos el cambio debe hacerse más bien como una "evolución", es decir, el proceso de implantación es un punto de partida para lo que inmediatamente debe constituirse como un proceso de mejora continua, el cual extienda en el tiempo dicha selección y refinamiento estratégico de las prácticas aplicadas.

En este taller comentaremos estos desafíos y estableceremos pautas que permitan ayudar en la implantación del agilismo en un equipo de trabajo con dicha diversidad de tipos de trabajo.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,092
On SlideShare
0
From Embeds
0
Number of Embeds
168
Actions
Shares
0
Downloads
38
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Implantando prácticas ágiles en un contexto multiproyecto

  1. 1. Implantando prácticas ágiles en un contexto multi-proyecto Patricio Letelier Torres letelier@dsic.upv.es Departamento Sistemas Informáticos y Computación (DSIC) Universidad Politécnica de Valencia (UPV) - España
  2. 2. Agenda Motivación Visualización esencial => Tablero kanban Solución a medida => Workflows “Multi-kanban” visualización uniforme e integrada Kanban, Sprints o mezcla Planificación y Seguimiento Visual Project Management Conclusiones
  3. 3. Motivación
  4. 4. Soluciones a medidaDiversidad o altamente configurables 4
  5. 5. Situación ideal 1 Proyecto Equipo Un equipo trabajando solo en un proyecto en el mismo periodo de tiempo 5
  6. 6. Situación frecuente * Proyecto Equipo - Desafíos en cuando a la gestión de la capacidad del equipo - Degradación del desempeño del equipo 6
  7. 7. Similar pero desde una perspectiva de supervisión Departamento X Proyecto1 Equipo1 Proyecto2 Equipo2 Proyecto3 Equipo4 Proyecto4 Equipo3 7
  8. 8. Tipos de agrupación del trabajo Proyecto Producto Servicio 8
  9. 9. Simplificación tipos de agrupación del trabajo Proyecto Producto/Servicio 9
  10. 10. Configuración básica para cada Producto/Servicio Definición de actividades y workflows (Método) Kanban Limitar/Supervisar el WIP Pre-asignación y balanceo de carga Pre-asignación Sin pre-asignación encargados Pre-asignación parcial Ninguna Medida del Esfuerzo Puntos y Capacidad Tiempo restante Tiempo estimado y tiempo invertido No usar Sprints Sprints Usar Sprints solo como agrupador Usar Sprints como previsión o compromiso No usar Proyectos/Releases Proyectos/Releases Usar Proyectos/Releases 10
  11. 11. Trabajo del equipo
  12. 12. Visualización esencial →Tablero kanban
  13. 13. kanban elemental To Do Doing Done A B C D E F G 13
  14. 14. …kanban elemental To Do Doing Done A C D E B F G Flujo
  15. 15. …kanban elemental To Do Doing Done A C D F E H B G Flujo
  16. 16. …kanban elemental To Do Doing Done A C D E I H B F G Flujo
  17. 17. …kanban elemental To Do Doing Done J A C G I E H B F D Flujo
  18. 18. …kanban elemental To Do Doing Done H C J G A I E B F D Flujo
  19. 19. …kanban elemental To Do Doing Done C H G K A E J L G F I D B Visibilidad del estado del trabajo Conseguir un flujo de producción “Pull” Limitar Supervisar el WIP (Work in Progress)
  20. 20. kanban más especifico Actividad 1 Actividad 2 … Actividad n Doing Done Doing Done … Doing Done C H … K L G I J D E A G F B Las columnas corresponden a las actividades del workflow que sigue cada unidad de trabajo Las WUs son cogidas en orden desde las actividades precedentes, desde la columna “Done” pasándolas a “Doing” en la actividad que se inicia Se podría establecer un límite para el WIP en cada columna Doing o Done de cualquier actividad  Kanban
  21. 21. Un kanban manual (de pared) es un excelente medio para motivar al equipo durante la introducción delagilismo pero a medio y largo plazo es cuestionable como forma de trabajo escalable/sostenible(http://bit.ly/ABKlOW), ¿debería ser soportado por una herramienta software? Solo Kanbanhttp://bit.ly/JBWE0U o algo más completo http://bit.ly/JoT9ou
  22. 22. Analizando el Flujo: Cumulative Flow Diagram (CFD) Theory of Constraints (TOC) + Limitar Supervisar el WIP
  23. 23. Solución a medida =>Workflows
  24. 24. Workflow “estilo” Scrum
  25. 25. Workflow “mediano” y más “tradicional” 25
  26. 26. Workflow más “complejo/completo”
  27. 27. “Know How” explícito en los WFs
  28. 28. “Multi-Kanban” visualizaciónuniforme e integrada
  29. 29. Equipo * 1.. *Proyecto * Backlog 1.. * * 1.. * * 1.. * * 1.. 1Agente Producto/Servicio1 * Sprint 29
  30. 30. Desafíos de visualización Vista integrada de todo el trabajo de un equipo o agente Equipo * 1.. 0.. *Proyecto * Backlog 1.. * 1..* * Múltiples vistas del trabajo, desde * 1.. * * 1.. 1 Proyecto y desde Producto/Servicio Agente Producto/Servicio1 * Sprint 30
  31. 31. 31
  32. 32. Kanban, Sprints o mezcla
  33. 33. Sólo flujo (≅Kanban) para todo tipo de trabajo
  34. 34. Usando Sprints SprintX Sprintx+1 Sprintx+2
  35. 35. Usando Sprints independientes SprintX Sprintx+1 Sprintx+2 Sprinty Sprinty+1 Sprinty+2
  36. 36. Mezcla de tipos de trabajo con y sin SprintsCapacidad 100% Sprint1 Sprint2 Sprint3 80% 60% 40% 20% 0% Semana1 Semana2 Semana3 Semana4 Tiempo
  37. 37. Usar el método Kanban, Sprints o inclusomezcla es una decisión que debería tomarsesegún características del tipo de trabajo del equipo (es decir, para cada producto o servicio) 37
  38. 38. Sólo flujo (Kanban) o usar Sprints Recomendaciones Usa Kanban si no existe un compromiso inflexible de plazos ni de alcance. Usa Kanban si tienes poco control sobre la demanda (puedes priorizar pero no se suele aplazar el trabajo, existen SLAs). No uses Sprints previamente definidos si continuamente se estaría cambiando su contenido, o úsalos pero no los consideres un compromiso. (Forecast versus Commitment) Usa Sprints previamente definidos para realizar un seguimiento con respecto de estimaciones del trabajo (debes estimar) y de acuerdo a un compromiso. 38
  39. 39. Sólo flujo (Kanban) o usar Sprints …Recomendaciones Puedes usar Kanban mezclado con Sprints posteriormente definidos o implícitos, éstos solo para estudiar la Capacidad invertida en Sprints vistos como intervalos de tiempo que agrupan trabajo terminado (no sería necesario estimar). Si usas Sprints previamente definidos debes planificar en base a una previsión de Capacidad disponible y restante con respecto a la que te dejarían otros productos o servicios. 39
  40. 40. Planificación y Seguimiento
  41. 41. Desafíos ante varios Productos/Servicios y Proyectos Limitar el número de productos/servicios y/o proyectos en marcha Reservar Capacidad para cada producto o servicio, o proyecto Activación/Desactivación de Proyectos Priorización de Proyectos Acuerdo de Niveles de Servicio (para servicios) Políticas explicitas para orientar al equipo en la selección de trabajo 41
  42. 42. Obtención de la Capacidad 42
  43. 43. Planificación de Proyecto o de Sprint Backlog * Equipo * 1.. *Proyecto Planificación de un 1.. * * 1.. * Proyecto asignandoun Planificación de WUs Proyecto al Backlog o al Sprint * 1.. * 1.. * 1 Agente Producto/Servicio1 * Sprint 43
  44. 44. El trabajo de un proyecto, según corresponda,bien se incluye directamente en el kanban como trabajo pendiente y ordenado, o se asigna en Sprints o Backlog de los correspondientes productos o servicios. 44
  45. 45. Seguimiento de Sprint o Proyecto • Multi-kanban • Burndown Seguimiento • Trabajo Finalizado del Proyecto • VPM Equipo *Proyecto 0.. * 1.. 0.. * Seguimiento del Sprint * 0.. * 1.. Agente Producto/Servicio * 0.. Sprint 45
  46. 46. Seguimiento de 1 Sprint o 1 Proyecto 46
  47. 47. Hacia un“Cuadro de Mandos” A B C D E F 47
  48. 48. Visual Project Management - VPM Holt, J. R., & Srinivasan, M. M., (2011, February). How to Get Things Done, Visual project management shows the way, http://bus.utk.edu/cba/news_articles/2011/documents/JF11_Reprint_Srinivasan_Holt.pdf 49
  49. 49. Configuración básica para cada Producto/Servicio Definición de actividades y workflows (Método) Kanban Limitar/Supervisar el WIP Pre-asignación y balanceo de carga Pre-asignación Sin pre-asignación encargados Pre-asignación parcial Ninguna Medida del Esfuerzo Puntos y Capacidad Tiempo restante Tiempo estimado y tiempo invertido No usar Sprints Sprints Usar Sprints solo como agrupador Usar Sprints como previsión o compromiso No usar Proyectos/Releases Proyectos/Releases Usar Proyectos/Releases 50
  50. 50. Implantando prácticas ágiles en un contexto multi-proyectoGracias por vuestra atención!! www.tuneupprocess.com agilismoatwork.blogspot.com

×