Agilismo at work
Descargar como PPTX, PDF0 recomendaciones265 vistas
Este documento describe el uso de un tablero kanban multi-proyecto para equipos ágiles que trabajan en múltiples proyectos simultáneamente. Explica que un contexto multi-proyecto es común cuando un equipo pequeño está a cargo de varios proyectos o productos al mismo tiempo debido a oportunidades de negocio o demanda continua. Propone usar un tablero kanban que permita administrar los backlogs, sprints y flujo de trabajo de cada proyecto de manera independiente pero integrada para el mismo equipo.
Agilismo at work
- 2. Integrantes Doris Quiroz Sonia Posligua Sergio Bravo Pedro Ostaiza
- 3. Agilismo at work (Agilismo en el trabajo)
- 4. Multi-kanban un tablero kanban para contextos multiproyecto
- 5. Antes de empezar, es importante puntualizar que con "multi-proyecto" se refiere a la situación en la cual un equipo ágil (pequeño) está encargado de varios (muchos) proyectos
- 6. Multi-kanban, en este último caso ya hay bastante información bajo la etiqueta "Scrum de Scrums",
- 7. Es decir, dividir un proyecto de gran tamaño (y con muchas personas involucradas) en áreas y equipos, de forma que cada equipo esté dedicado a cada área del producto/servicio.
- 8. Un escenario multi-proyecto no es un tema usualmente abordado en la bibliografía ágil de referencia (escrita por los gurús del agilismo).
- 9. Parece que se asume como normal que un equipo en un contexto multi-proyecto, tenga que por ejemplo, trabajar con varios tableros kanban a la vez, O que de manera artificial se tienda a incluir en un Backlog o sprint ítems que corresponden a diferentes productos/servicios.
- 10. ¿Por qué un contexto multi-proyecto es una realidad difícil de cambiar?
- 11. Porque existen oportunidades de negocio y no se cuenta con suficiente personal para abordarlas cada una de forma exclusiva
- 12. Porque los productos/servicios resultantes de un proyecto seguirán teniendo demanda mientras estén en producción.
- 13. Multi-kanban
- 14. Un agente (miembro) participa en equipos.
- 15. Un equipo tiene agentes.
- 16. Un equipo está encargado de productos o servicios.
- 17. Un producto o servicio tiene un Backlog (que contiene el trabajo pendiente priorizado y no incluido aun en sprints).
- 18. Un producto o servicio tiene definidos sprints con trabajo que se ha movido desde el Backlog.
- 19. En caso que un producto o servicio no trabaje con sprints (por ejemplo, porque su demanda no es planificable), todo el trabajo estará en el Backlog y directamente allí se abordará.