Implantando prácticas ágiles en un contexto multiproyecto
50
Implantando prácticas ágiles en un contexto multi-proyecto Patricio Letelier Torres [email protected] Departamento Sistemas Informáticos y Computación (DSIC) Universidad Politécnica de Valencia (UPV) - España
-
Upload
chileagil -
Category
Technology
-
view
857 -
download
0
description
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.
Transcript of Implantando prácticas ágiles en un contexto multiproyecto
Implantando prácticas ágiles en un contexto
multi-proyecto
Patricio Letelier Torres [email protected]
Departamento Sistemas Informáticos y Computación (DSIC)
Universidad Politécnica de Valencia (UPV) - España
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
Agenda
Motivación
4
Diversidad Soluciones a medida
o altamente configurables
5
1
Equipo
Proyecto
Situación ideal
Un equipo trabajando solo en un proyecto
en el mismo periodo de tiempo
6
*
Equipo
Proyecto
Situación frecuente
- Desafíos en cuando a la gestión de la capacidad del equipo
- Degradación del desempeño del equipo
7
Equipo1 Proyecto1
Similar pero desde una perspectiva de supervisión
Equipo2 Proyecto2
Equipo3 Proyecto4
Equipo4 Proyecto3
Departamento X
8
Proyecto
Producto Servicio
Tipos de agrupación del trabajo
9
Proyecto
Producto/Servicio
Simplificación tipos de agrupación del trabajo
10
Definición de actividades y workflows
Limitar/Supervisar el WIP (Método) Kanban
Sprints
Medida del Esfuerzo
y Capacidad
No usar Sprints
Usar Sprints solo como agrupador
Usar Sprints como previsión o compromiso
Ninguna
Puntos
Tiempo restante
Tiempo estimado y tiempo invertido
No usar Proyectos/Releases
Usar Proyectos/Releases Proyectos/Releases
Pre-asignación y balanceo de carga
Sin pre-asignación
Pre-asignación parcial
Pre-asignación
encargados
Configuración básica para cada Producto/Servicio
Trabajo del equipo
Presenter
Presentation Notes
La siguiente imagen muestra un proceso iterativo e incremental en el cual el trabajo se organiza en iteraciones. En cada iteración se implementan funcionalidades del producto, que en nuestro caso son un conjunto de unidades de trabajo. Cada unidad de trabajo requiere un trabajo de requisitos, de diseño, de codificación y un trabajo de pruebas. Cada iteración requiere de una planificación, y como es un proceso iterativo e incremental se requiere de un testeo de regresión.
Visualización esencial → Tablero kanban
kanban elemental
To Do Doing Done
A B C
D E
F G
13
Presenter
Presentation Notes
Its goal is the efficient delivery of value. Kanban promotes the lean concept of flow ==> to continuously and predictably deliver value. The work and the workflow is made visible ==> to make activities and issues obvious. Kanban limits work in progress (WIP) ==> to promote quality, focus and finishing. Kaizen (改善, "cambio para mejorar" o "mejoramiento" en japonés; el uso común de su traducción al castellano es "mejora continua" o "mejoramiento continuo"). 改 (kai en japonés, gǎi en chino) significa 'cambio' o 'la acción de enmendar'. 善 (zen en japonés, shàn en chino) significa 'bueno' o 'beneficioso'. Lean manufacturing (Manufactura esbelta) es una filosofía de gestión enfocada a la reducción de los siete tipos de "desperdicios" (sobreproducción, tiempo de espera, transporte, exceso de procesado, inventario, movimiento y defectos) en productos manufacturados. Eliminando el despilfarro, la calidad mejora y el tiempo de producción y el costo, se reducen. Las herramientas "lean" (en inglés, "sin grasa" o "ágil") incluyen procesos continuos de análisis (kaizen), producción "pull" (en el sentido de kanban), y elementos y procesos "a prueba de fallos" (poka yoke).
…kanban elemental
To Do Doing Done
A
B
C
D E
F G
Flujo
To Do Doing Done
A
B
C
D E F
G
H
Flujo
…kanban elemental
To Do Doing Done
A
B
C
D E
F
G
H
I
Flujo
…kanban elemental
To Do Doing Done
A
B
C
D
E
F
G
H
I
J
Flujo
…kanban elemental
To Do Doing Done
A
B
C
D
E
F
G
H
I
J
Flujo
…kanban elemental
To Do Doing Done
A
B
C
D
E
F G
G H
I
J K
L
Visibilidad del estado del trabajo
Conseguir un flujo de producción “Pull”
Limitar Supervisar el WIP (Work in Progress)
…kanban elemental
kanban más especifico
Actividad 1
A
B
C
D E
F
G
G H I
J
K L
Actividad 2
Doing Done Doing Done Doing Done
Actividad n
… … …
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
Un kanban manual (de pared) es un excelente medio para motivar al equipo durante la introducción del
agilismo 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 Kanban
http://bit.ly/JBWE0U o algo más completo http://bit.ly/JoT9ou
Analizando el Flujo: Cumulative Flow Diagram (CFD)
Theory of Constraints (TOC) + Limitar Supervisar el WIP
Solución a medida =>
Workflows
Workflow “estilo” Scrum
25
Workflow “mediano” y más “tradicional”
Workflow más “complejo/completo”
“Know How” explícito en los WFs
“Multi-Kanban” visualización
uniforme e integrada
Equipo
29
Sprint
Proyecto
Producto/Servicio Agente
1.. *
*
1.. *
*
*
*
Backlog *
1.. *
1.. * 1.. *
1
1
Equipo
30
Sprint
Proyecto
Producto/Servicio Agente
1.. *
*
1.. *
*
*
*
Desafíos de visualización
Backlog *
1.. *
1.. * 1.. *
1
1
Equipo 1.. *
0.. *
Vista integrada de todo el trabajo de un
equipo o agente
Múltiples vistas del trabajo, desde
Proyecto y desde Producto/Servicio
31
Kanban, Sprints o mezcla
Sólo flujo (≅Kanban) para todo tipo de trabajo
Presenter
Presentation Notes
La siguiente imagen muestra un proceso iterativo e incremental en el cual el trabajo se organiza en iteraciones. En cada iteración se implementan funcionalidades del producto, que en nuestro caso son un conjunto de unidades de trabajo. Cada unidad de trabajo requiere un trabajo de requisitos, de diseño, de codificación y un trabajo de pruebas. Cada iteración requiere de una planificación, y como es un proceso iterativo e incremental se requiere de un testeo de regresión.
Usando Sprints
SprintX Sprintx+1 Sprintx+2
Presenter
Presentation Notes
La siguiente imagen muestra un proceso iterativo e incremental en el cual el trabajo se organiza en iteraciones. En cada iteración se implementan funcionalidades del producto, que en nuestro caso son un conjunto de unidades de trabajo. Cada unidad de trabajo requiere un trabajo de requisitos, de diseño, de codificación y un trabajo de pruebas. Cada iteración requiere de una planificación, y como es un proceso iterativo e incremental se requiere de un testeo de regresión.
Usando Sprints independientes
SprintX Sprintx+1 Sprintx+2
Sprinty Sprinty+1 Sprinty+2
Presenter
Presentation Notes
La siguiente imagen muestra un proceso iterativo e incremental en el cual el trabajo se organiza en iteraciones. En cada iteración se implementan funcionalidades del producto, que en nuestro caso son un conjunto de unidades de trabajo. Cada unidad de trabajo requiere un trabajo de requisitos, de diseño, de codificación y un trabajo de pruebas. Cada iteración requiere de una planificación, y como es un proceso iterativo e incremental se requiere de un testeo de regresión.
Tiempo Semana1 Semana2 Semana3 Semana4
Sprint1 Sprint2 Sprint3
20%
0%
40%
60%
80%
100%
Capacidad
Mezcla de tipos de trabajo con y sin Sprints
37
Usar el método Kanban, Sprints o incluso
mezcla es una decisión que debería tomarse
según características del tipo de trabajo del
equipo (es decir, para cada producto o
servicio)
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
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
Sólo flujo (Kanban) o usar Sprints
Planificación y Seguimiento
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
Desafíos ante varios Productos/Servicios y Proyectos
42
Obtención de la Capacidad
Equipo
43
Sprint
Proyecto
Producto/Servicio Agente
1.. *
*
1.. *
*
*
*
Backlog *
1.. *
1.. * 1.. *
1
1
Planificación de un Proyecto
Planificación de un Proyecto asignando WUs
al Backlog o al Sprint
Planificación de Proyecto o de Sprint
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.
Equipo
45
Sprint
Proyecto
Producto/Servicio Agente
1.. *
0.. *
1.. *
0.. *
0.. *
0.. *
Seguimiento de Sprint o Proyecto
Seguimiento del Proyecto
Seguimiento del Sprint
• Multi-kanban
• Burndown
• Trabajo Finalizado
• VPM
46
Seguimiento de 1 Sprint o 1 Proyecto
47
Hacia un“Cuadro de Mandos”
D
B
E
C
F
A
49
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
Visual Project Management - VPM
50
Definición de actividades y workflows
Limitar/Supervisar el WIP (Método) Kanban
Sprints
Medida del Esfuerzo
y Capacidad
No usar Sprints
Usar Sprints solo como agrupador
Usar Sprints como previsión o compromiso
Ninguna
Puntos
Tiempo restante
Tiempo estimado y tiempo invertido
No usar Proyectos/Releases
Usar Proyectos/Releases Proyectos/Releases
Pre-asignación y balanceo de carga
Sin pre-asignación
Pre-asignación parcial
Pre-asignación
encargados
Configuración básica para cada Producto/Servicio
Gracias por vuestra atención!!
Implantando prácticas ágiles en un contexto
multi-proyecto
agilismoatwork.blogspot.com www.tuneupprocess.com
