Este sitio ha sido mi hogar web desde finales de 2010. Gracias por tomarte el tiempo para visitar y leer mi blog sobre la gestión y la mejora de procesos.
En 2011 empecé a trabajar como consultora y formadora independiente, así que ya es hora de lanzar una nueva presencia web. Puedes encontrar mis últimos posts e información sobre mis actividades actuales en Berriprocess.
Espero verte allí.
Teodora
23 de enero de 2013
17 de octubre de 2012
Kanban en una organización tradicional: Primeros pasos
Estoy trabajando con una empresa con las siguientes características:
En esta situación la empresa está interesada en establecer una forma ligera de gestión de proyectos que le permite:
Por lo tanto, he sugerido aplicar algunos principios de Kanban como un medio para implementar las prácticas del área de proceso de Gestión Integrada de Proyectos de CMMI, relacionadas con la gestión del proyecto y la coordinación y colaboración entre las partes implicadas.
El tablero
Para empezar hemos diseñado los siguientes tableros para visualizar el flujo de trabajo de un proyecto individual y el estado del proyecto grande:
Las columnas tienen el siguiente significado:
En la columna izquierda presentamos
Las tarjetas amarillas representan Requisitos de Usuario. Las tarjetas moradas indican trabajos bloqueados por alguna razón. Las naranjas están reservadas para las peticiones de cambios a los requisitos. A nivel de proyecto individual hemos designado una fila especial para las peticiones de cambios a los requisitos con el fin de controlarlos mejor.
Límites de Trabajo-En-Curso (WIP: Work-In-Progress)
Con respecto a los límites WIP, los vamos a establecer paulatinamente. Empezamos con la simple política que una persona puede trabajar sobre una sola tarea en un proyecto. Por lo tanto los límites WIP de una columna se establecen en base al número de los miembros del equipo. En el tablero del proyecto grande los límites WIP están establecidos por columna y por proyecto.
Pros y contras
Vemos varias ventajas asociadas con esta solución inicial, así como algunos problemas pendientes a resolver. Los resumo en la siguiente tabla:
Bueno, esto es lo que tenemos hasta ahora.
Te agradecería tus comentarios.
Y, en cuanto obtengamos algún resultado, bueno o malo, que merece la pena compartir, lo conocerás a través de este blog.
Otros artículos relacionados:
- Desarrolla sistemas de software complejos.
- Actualmente está en curso un proyecto estratégico, que consiste en varios proyectos relacionados entre ellos
- Cada proyecto involucra a equipos de distintas funciones y la coordinación entre los equipos no es fácil. Los desarrolladores están sobrecargados, a veces participan en más de un proyecto y trabajan horas extras.
- Los Jefes de Proyectos están tan sobrecargados que hace varios meses la empresa decidió contratar asistentes para ayudarles con las tareas administrativas
- Los retrasos en los proyectos no son excepciones
- El proyecto estratégico se gestiona proyecto por proyecto. Aunque en el sistema de gestión de la empresa se recopila una variedad de datos de los proyectos individuales, determinar el estado real del proyecto grande no es sencillo.
- La empresa está implementando CMMI® nivel de madurez 3.
- La gente ve cualquier metodología como una carga adicional de trabajo
En esta situación la empresa está interesada en establecer una forma ligera de gestión de proyectos que le permite:
- Controlar el flujo de las actividades de desarrollo
- Reducir los retrasos
- Resolver los problemas de los proyectos a tiempo
- Facilitar la colaboración entre los equipos funcionales dentro de un proyecto, así como las entre varios proyectos.
Por lo tanto, he sugerido aplicar algunos principios de Kanban como un medio para implementar las prácticas del área de proceso de Gestión Integrada de Proyectos de CMMI, relacionadas con la gestión del proyecto y la coordinación y colaboración entre las partes implicadas.
El tablero
Para empezar hemos diseñado los siguientes tableros para visualizar el flujo de trabajo de un proyecto individual y el estado del proyecto grande:
Tablero de un proyecto
Tablero del proyecto grande
Las columnas tienen el siguiente significado:
- Pendiente: Requisitos que están por empezar a trabajar en ellos
- AF: Análisis Funcional
- Code & Pru: Códificación y Pruebas
- VAL: Validación. El equipo de Validación, en este caso, se dedica explícitamente a validar los desarrollos de todos los proyectos
- En Prod: Requisitos que ya están implementados y subidos a producción
- Hecho es una columna-colchón que se utiliza para recopilar los requisitos desarrollados antes de pasarlos a Validación o antes de subirlos a Producción.
En la columna izquierda presentamos
- <Nombre de proyecto>: <número de la iteración en curso>
- Esfuerzo: <%Planificado> • <%Actual>
- Fecha fin: <Planificada> • <Actual>
Las tarjetas amarillas representan Requisitos de Usuario. Las tarjetas moradas indican trabajos bloqueados por alguna razón. Las naranjas están reservadas para las peticiones de cambios a los requisitos. A nivel de proyecto individual hemos designado una fila especial para las peticiones de cambios a los requisitos con el fin de controlarlos mejor.
Límites de Trabajo-En-Curso (WIP: Work-In-Progress)
Con respecto a los límites WIP, los vamos a establecer paulatinamente. Empezamos con la simple política que una persona puede trabajar sobre una sola tarea en un proyecto. Por lo tanto los límites WIP de una columna se establecen en base al número de los miembros del equipo. En el tablero del proyecto grande los límites WIP están establecidos por columna y por proyecto.
Pros y contras
Vemos varias ventajas asociadas con esta solución inicial, así como algunos problemas pendientes a resolver. Los resumo en la siguiente tabla:
Bueno, esto es lo que tenemos hasta ahora.
Te agradecería tus comentarios.
Y, en cuanto obtengamos algún resultado, bueno o malo, que merece la pena compartir, lo conocerás a través de este blog.
Otros artículos relacionados:
12 de octubre de 2012
Kanban para la gestión de portfolio de proyectos
El uso de un tablero Kanban para la gestión del portfolio de proyectos facilita el conocimiento del estado real de los proyectos, la resolución de los asuntos relacionados con los proyectos y la asignación de los recursos, y la priorización de los trabajos (requisitos, casos de uso, servicios) pendientes.
Una forma de visualizar la información de varios proyectos es la siguiente:
Las columnas son las siguientes:
Este es el tablero que utilizamos a nivel interno. No obstante, cuando presentamos el estado de los proyectos a nivel ejecutivo utilizamos una forma más resumida, porque el objetivo de las reuniones con la Dirección de la empresa es de comunicar el progreso de los proyectos, los asuntos bloqueantes y el estado de los proyectos en términos de esfuerzo y cumplimiento de las fechas:
En la columna izquierda presentamos
Como cada proyecto se desarrolla por un equipo particular, una opción de visualizar los límites WIP en el tablero ejecutivo es al lado del nombre del proyecto porque se refieren sólo a la columna “En Desarrollo”. En el tablero interno, visualizamos los límites WIP en la columna correspondiente al proyecto porque estos límites dependen del número de las personas que perteneces al equipo.
Se pueden diseñar otros formatos del tablero Kanban que permiten gestionar el portfolio de proyectos. El diseño también evoluciona a medida que se utiliza el tablero en los proyectos. Así que aprovecha estas ideas para empezar y ajústalas al flujo de tus proyectos y al nivel de detalle de la información que tienes que controlar.
Si te puedo ayudar en algo, cuenta conmigo.
Otros artículos relacionados:
Una forma de visualizar la información de varios proyectos es la siguiente:
Las columnas son las siguientes:
- Pendiente: Requisitos que están por empezar a trabajar en ellos
- AF: Análisis Funcional
- Code & Pru: Códificación y Pruebas
- VAL: Validación. El equipo de Validación, en mi caso, se dedica explicitamente a validar los desarrollos de todos los proyectos
- En Prod: Requisitos que ya están implementados y subidos a producción
- Hecho es una columna-colchón que se utiliza para recopilar los requisitos desarrollados antes de pasarlos a Validación o antes de subirlos a Producción.
Este es el tablero que utilizamos a nivel interno. No obstante, cuando presentamos el estado de los proyectos a nivel ejecutivo utilizamos una forma más resumida, porque el objetivo de las reuniones con la Dirección de la empresa es de comunicar el progreso de los proyectos, los asuntos bloqueantes y el estado de los proyectos en términos de esfuerzo y cumplimiento de las fechas:
En la columna izquierda presentamos
- Esfuerzo: <%Planificado> • <%Actual>
- Fecha fin: <Planificada> • <Actual>
Como cada proyecto se desarrolla por un equipo particular, una opción de visualizar los límites WIP en el tablero ejecutivo es al lado del nombre del proyecto porque se refieren sólo a la columna “En Desarrollo”. En el tablero interno, visualizamos los límites WIP en la columna correspondiente al proyecto porque estos límites dependen del número de las personas que perteneces al equipo.
Se pueden diseñar otros formatos del tablero Kanban que permiten gestionar el portfolio de proyectos. El diseño también evoluciona a medida que se utiliza el tablero en los proyectos. Así que aprovecha estas ideas para empezar y ajústalas al flujo de tus proyectos y al nivel de detalle de la información que tienes que controlar.
Si te puedo ayudar en algo, cuenta conmigo.
Otros artículos relacionados:
19 de septiembre de 2012
Si no lo ves, no lo puedes controlar
Hace un par de meses me comentaron que una empresa que estaba implementando nivel de madurez 3 de CMMI quería introducir la función de Asistente de Jefe de Proyecto con la responsabilidad de "apoyar a los jefes de proyectos (JP) en su trabajo administrativo, más precisamente en la preparación de los datos para los informes mensuales, el seguimiento de los riesgos, los asuntos (problemas) de los proyectos, escribir actas de reuniones, etc ". Justifican esta decisión con la necesidad de los JPs de tener más tiempo para "el trabajo real en los proyectos".
Una de las reglas de Kanban, la primera, es Visualisar el flujo de trabajo.
Esto puede ser muy natural y fácil de aplicar para los equipos acostumbrados a trabajar con Post-its en una pizarra blanca / tableros. Sin embargo, las organizaciones que utilizan sistemas de gestión centralizada para recopilar y analizar los datos de los proyectos, tienen dificultades para manejar un tablero Kanban juntos con la herramienta de gestión corporativa. Un cliente mío incluso me dijo que veía el tablero como un paso atrás en el tiempo cuando utilizaban formularios de papel para reportar el trabajo realizado.
Así que, ¿cuáles son las ventajas de Visualizar el flujo de trabajo? y ¿cómo se puede realizar esto cuando la empresa ya utiliza otro sistema de gestión?
Un dicho bien conocido es que una imagen vale más que 1000 palabras.
Y, si las palabras tratan del estado de un proyecto, las métricas de su progreso, el uso de los recursos, e implican una serie de cifras, ¿cómo se pueden presentar todos estos aspectos en una imagen?
Un tablero Kanban ofrece las siguientes ventajas a la vez:
Con respecto a la automatización de la visualización del flujo, la recopilación de datos y la integración con el sistema de gestión corporativo, puedes considerar las siguientes ideas:
Recursos de interés:
¿Cuánto esfuerzo de gestión de proyectos es aceptable desde el punto de vista de negocio?
¿Se puede dejar el seguimiento de los asuntos y los riesgos de un proyecto a un asistente administrativo?
¿No se tienen que resolver estos temas lo más rápido posible para que el trabajo pueda ir sin problemas?
¿Puede un JP esperar que su asistente le informe de un riesgo o un problema en su proyecto?
¿Existe alguna manera fácil de que el JP y todo el equipo estén continuamente al tanto del estado del proyecto?
¿Se puede dejar el seguimiento de los asuntos y los riesgos de un proyecto a un asistente administrativo?
¿No se tienen que resolver estos temas lo más rápido posible para que el trabajo pueda ir sin problemas?
¿Puede un JP esperar que su asistente le informe de un riesgo o un problema en su proyecto?
¿Existe alguna manera fácil de que el JP y todo el equipo estén continuamente al tanto del estado del proyecto?
Una de las reglas de Kanban, la primera, es Visualisar el flujo de trabajo.
Esto puede ser muy natural y fácil de aplicar para los equipos acostumbrados a trabajar con Post-its en una pizarra blanca / tableros. Sin embargo, las organizaciones que utilizan sistemas de gestión centralizada para recopilar y analizar los datos de los proyectos, tienen dificultades para manejar un tablero Kanban juntos con la herramienta de gestión corporativa. Un cliente mío incluso me dijo que veía el tablero como un paso atrás en el tiempo cuando utilizaban formularios de papel para reportar el trabajo realizado.
Así que, ¿cuáles son las ventajas de Visualizar el flujo de trabajo? y ¿cómo se puede realizar esto cuando la empresa ya utiliza otro sistema de gestión?
Un dicho bien conocido es que una imagen vale más que 1000 palabras.
Y, si las palabras tratan del estado de un proyecto, las métricas de su progreso, el uso de los recursos, e implican una serie de cifras, ¿cómo se pueden presentar todos estos aspectos en una imagen?
Un tablero Kanban ofrece las siguientes ventajas a la vez:
- Visión explícita de la realidad actual del proyecto: ver cuántos y qué tareas se están ejecutando, están bloqueadas, en la cola de entradas, o acabadas.
- Información sobre el trabajo de los miembros del equipo: quién está trabajando en qué tarea, quién está libre o bloqueado.
- Políticas explícitas y Límites del Trabajo-En-Curso (WIP)
- Tiempo de ejecución de las diferentes tareas (inglés: lead time, cycle time)
- Las reuniones de pie (stand-up), originalmente celebradas a diario en los equipos de Scrum, cambian su enfoque de "¿qué he hecho? - ¿qué voy a hacer?” a los impedimentos y las posibles mejoras del flujo de trabajo. Por lo tanto, se pueden celebrar cuando sea necesario.
- La visión compartida del estado del proyecto, naturalmente facilita la colaboración y la resolución de los problemas
- Los límites de WIP reducen las multi-tareas y el cambio entre tareas
- Mejora la calidad del producto
Con respecto a la automatización de la visualización del flujo, la recopilación de datos y la integración con el sistema de gestión corporativo, puedes considerar las siguientes ideas:
- Revisar los indicadores actuales y asegurar que ofrecen información útil sobre el estado del proyecto
- Revisar las herramientas de Lean Kanban que podrían resultar útiles. Puedes encontrar una lista aquí. Algunas de ellas ya proporcionan interfaces con otras herramientas.
- Empezar con la visualización de las tareas para la próxima iteración
Recursos de interés:
- David Anderson: Kanban: Cambio Evolutivo Exitoso Para su Negocio de Tecnología
- Kenji Hiranabe, Visualizing Agile Projects Using Kanban Boards
- Alisson Vale, Memes for Work Visualization in Kanban Boards
10 de septiembre de 2012
Cómo Kanban puede ayudarte a mejorar los procesos en tiempos de crisis
Ya se conoce el impacto de la crisis económica sobre la inversión en la mejora de procesos: esta se limita a realizar sólo las actividades indispensables y en muchas empresas está en la parte inferior de las prioridades de los Directores o prácticamente cortada.
Yo puedo entender la razón para este tipo de decisiones: lo esencial es la supervivencia y las empresas tienen que centrarse en aumentar el rendimiento y realizar actividades productivas que generen ingresos rápidamente.
¿Cómo abordar este objetivo?
Algunas alternativas conocidas son reorganizar los recursos o trabajar horas extra, mientras que el enfoque correcto es de asegurar que el flujo de trabajo sea continuo y óptimo, produciendo resultados de calidad. Si compartes este punto de vista, tienen que conocer Kanban.
La esencia de Kanban consiste en lo siguiente:
Yo puedo entender la razón para este tipo de decisiones: lo esencial es la supervivencia y las empresas tienen que centrarse en aumentar el rendimiento y realizar actividades productivas que generen ingresos rápidamente.
¿Cómo abordar este objetivo?
Algunas alternativas conocidas son reorganizar los recursos o trabajar horas extra, mientras que el enfoque correcto es de asegurar que el flujo de trabajo sea continuo y óptimo, produciendo resultados de calidad. Si compartes este punto de vista, tienen que conocer Kanban.
La esencia de Kanban consiste en lo siguiente:
- Visualiza el Work-In-Progress (WIP)
- Establece un sistema de trabajo “pull”
- Limita el WIP asegurando un flujo de actividades manejable
- Mide el tiempo realización del trabajo (en inglés “lead time”, "cycle time"), que permite gestionar el rendimiento del flujo de trabajo y la obtención de resultados predecibles
- Hace explícitas las políticas de proceso
- Es menos destructivo en comparación con otros métodos de mejora de procesos. No define nuevos procesos y roles. Más bien ayuda a agilizar y optimizar los actuales
- Ayuda a identificar cuellos de botella y hacerlos visibles para todo el equipo, no sólo para el líder del proyecto. Esto hace que la gente colabore en la resolución de problemas
- Proporciona una ruta de transición natural para el desarrollo ágil de software sin la necesidad de adoptar nuevas normas o métodos.
- Proporciona visibilidad en el proceso de desarrollo para todos los implicados: clientes, equipo de proyecto, dirección y comerciales. Esto facilita la colaboración y la toma de decisiones.
- De hecho Kanban está previsto para ser utilizado junto con otros procesos basados en SCRUM, CMMI u otro modelo o método.
Consulta "Kanban y Scrum - sacar el máximo partido de ambos" de Henrik Kniberg y Skarin Mattias para una buena comparación de Kanban y Scrum, y cómo se pueden utilizar juntos. - Kanban facilita la identificación de los cuellos de botella en el proceso y su adaptación con el fin de equilibrar la demanda del cliente y la capacidad del equipo de proyecto. Este es un enfoque basado en Lean y la Teoría de las Restricciones que se puede aplicar a cualquier proceso
- David Anderson, Kanban: Successful Evolutionary Change for your Technology Business
- limitedwipsociety.ning.com/ - el sitio web principal de la comunidad global que abarca Kanban para el desarrollo de software
- http://www.agilemanagement.net/
31 de julio de 2012
Transformación a una organización ágil
¡Las empresas (en España) están evolucionando!
Sé que esto es un desarrollo natural, sin embargo, me alegro que hoy en día esté recibiendo más preguntas acerca de cómo transformar a una organización en una ágil, mientras que los últimos años típicamente me preguntaban qué era necesario hacer para alcanzar nivel de madurez 2 o 3 de CMMI®.
Por ejemplo, el Director general de un cliente mío me dijo en el comienzo de nuestro proyecto "Lo importante para nosotros es que la empresa siga inscrita en el Registro Mercantil y que nuestros clientes estén contentos. Este es el mejor certificado para nuestro negocio."
Los métodos ágiles están ganando intereses hoy en día porque han demostrado que funcionan. No es uno u otro método en particular, más bien la mentalidad ágil es el factor que hace la diferencia.
Si estás trabajando en la transformación de tu organización a un ágil, el último libro de David Anderson, " Lessons in Agile Management - On the Road to Kanban " te resultará útil. El libro es una colección de publicaciones en el blog de David que te darán ideas pragmáticas sobre los siguientes temas:
Disfruta el libro y déjame saber tus comentarios.
Por ejemplo, el Director general de un cliente mío me dijo en el comienzo de nuestro proyecto "Lo importante para nosotros es que la empresa siga inscrita en el Registro Mercantil y que nuestros clientes estén contentos. Este es el mejor certificado para nuestro negocio."
Los métodos ágiles están ganando intereses hoy en día porque han demostrado que funcionan. No es uno u otro método en particular, más bien la mentalidad ágil es el factor que hace la diferencia.
Si estás trabajando en la transformación de tu organización a un ágil, el último libro de David Anderson, " Lessons in Agile Management - On the Road to Kanban " te resultará útil. El libro es una colección de publicaciones en el blog de David que te darán ideas pragmáticas sobre los siguientes temas:
- Cómo gestionar temas de actitud y la resistencia al cambio
- Cómo gestionar a los ingenieros de software
- Por qué los managers siguen siendo importantes en organizaciones ágiles
- Cómo gestionar el flujo de trabajo y la variabilidad
- Cómo medir y controlar el rendimiento de proceso
- La esencia de desarrollar y entregar valor
- Cuáles son las condiciones adecuadas para la adopción de prácticas ágiles
Disfruta el libro y déjame saber tus comentarios.
23 de abril de 2012
Día de Lean Six Sigma para Ingeniería de Software y TI
Reserva en tu agenda: 17 de mayo, Madrid, DÍA DE LEAN SIX SIGMA
Visión pragmática para ejecutivos y profesionales
La mejora de los procesos software y TI es una inversión en términos de esfuerzo, tiempo y coste. Las iniciativas de mejora de procesos a menudo requieren un profundo cambio cultural y tienen riesgos. ¿Se ha obtenido retorno de la inversión? O, por lo menos ¿se ha evaluado la rentabilidad de la iniciativa cuando ésta ha empezado?¿Están identificados y evaluados los riesgos asociados con la mejora de los procesos? ¿Se entienden estos riesgos?
Al contrario de muchos enfoques de mejora de procesos, Lean Six Sigma no ofrece soluciones a priori, sino es una metodología de resolución de problemas. Lean Six Sigma destaca la importancia de partir desde un problema bien definido y relacionado con el negocio.
Este seminario práctico mostrará cómo los métodos y las técnicas de Lean Six Sigma se pueden aplicar a TI y a la ingeniería de software y proporcionará una tipología de problemas que se pueden resolver a través de estas técnicas. Se enseñarán ejemplos prácticos de implementaciones de Lean Six Sigma en la industria de software y de TI y se abordará la relación entre Lean Six Sigma y otros marcos de calidad, como (CMMI®
, ITIL, los Métodos Ágiles, etc). En particular Radouane Oudhiri de Systonomy, Master Black Belt, ofrecerá una visión pragmática en la metodología Lean Six Sigma y su interpretación y aplicación al dominio de la Ingeniería del Software y los Servicios TI. Al final del día conocerás:
- El flujo principal de la metodología Lean Six y sus principios
- ¿Cómo interpretar y aplicar correctamente Lean Six Sigma para la mejora de los procesos de ingeniería de software y servicios TI
El seminario proporcionará ejemplos, consejos y una experiencia sintetizada en base a cientos de proyectos reales de Lean Six Sigma en el dominio de software. También entenderás cómo aplicar Lean Six Sigma para acelerar la mejora de procesos y obtener beneficios económicos de ella.
El día de Lean Six Sigma está dirigido tanto a ejecutivos de empresas Software, como a profesionales. El día comenzará con una introducción a la metodología, seguida de una presentación de los resultados de proyectos reales. La última parte del día está reservada para preguntas abiertas y consultas.
La participación en el evento es gratuita.
Si estás interesado en asistir, por favor, confirma tu participación por correo electrónico a
teodora@berriprocess.com.
Si deseas alcanzar y demostrar beneficios reales de la mejora de procesos, tienes que asistir a este evento.
Suscribirse a:
Entradas (Atom)