Me dedico a la gestión de proyectos desde hace ya diecisiete años. He llevado a cabo proyectos de desarrollo de software para banca, para ingenieros civiles y para gestión documental.
He aplicado las prácticas de
Rational Unified Process (RUP)
Método de Valor Ganado
PMBoK
CMMI™
Gestión de proyecto ágil (basada en Scrum)
Aunque siempre estaba tratando de aplicar correctamente los métodos, identificar y abordar los riesgos adecuadamente, hablar con el equipo a diario (la comunicación nunca ha sido un problema en nuestros proyectos), comunicar con el cliente a menudo, he sufrido los problemas de:
Estimaciones inexactas
Tener que trabajar largas horas y los fines de semana para cumplir fechas
“Todo es urgente” y se tiene que implementar en la iteración en curso
Tener que parar todo el proyecto para corregir un error en el diseño de la arquitectura
Subir a producción sin haber hecho todas las pruebas por falta de tiempo.
No saber cómo exactamente actuar para eliminar una desviación de plazo o de presupuesto y volver el proyecto a lo estimado
Hasta que aprendí Kanban y asistí al curso Kanban Coaching Professional con David Anderson, ninguno de los métodos me había enseñado que para que fuese bien el trabajo en los proyectos tenía que enfocarme también en lo siguiente:
Asegurar un flujo de trabajo suave
Aplicar la Ley de Little para equilibrar la demanda de trabajo y la capacidad del equipo
Resolver los cuellos de botella para mejorar el flujo de trabajo
Conocer la variación de los procesos y los efectos de esta.
Hoy me pregunto ¿por qué nadie me enseñó esto antes?
Si tuviera estos conocimientos antes, mis proyectos hubieran ido mucho más suave…
En fin, la máquina del tiempo todavía existe sólo en las películas.
De todos modos, si eres Jefe de proyecto, Team leader o Scrum Master, cuando tengas un rato, échales un vistazo a estos temas. Te ahorrarán algún que otro fuego.
Empecé a trabajar como jefe de proyectos de desarrollo de software en 1996. Éramos un equipo de 5 personas, jóvenes y motivados, y desarrollábamos un sistema de gestión de instalaciones (inglés: facility management) para un banco.
Sólo para darte una idea de aquel tiempo, teníamos acceso a Internet en un solo ordenador, por lo que comprobábamos el correo electrónico de todo el equipo (no el personal) dos o tres veces al día. Los teléfonos móviles eran como ves en la foto, es decir, no SMS, no WhatsApp, ni nada de este estilo.
Este fue el único proyecto sobre que trabajábamos, no compartíamos recursos con otros proyectos y los otros desarrollos tampoco nos impactaban tanto.
¿Tu también te acuerdas de ese tiempo? :-)
Como jefe de proyecto era responsable de planificar, dar seguimiento y reportar el progreso del proyecto.
El cliente esperaba un producto de alta calidad, sin embargo, fue lo suficientemente paciente para trabajar con nosotros en los requisitos y dejarnos el tiempo necesario para implementarlos y hacer las pruebas.
Está chupado, ¿verdad?
Aun así, antes de cada entrega teníamos que trabajar largas hora para asegurarnos que todo funcionaba bien. Es decir, las estimaciones no se ajustaban a los números reales.
Las estimaciones y los datos reales son diferentes valores del mismo parámetro.
No fuerces (manipules) los reales para que coincidan con las estimaciones.
La supervivencia y la sostenibilidad requieren pragmatismo
Menos de 20 años después, pocos jefes de proyectos, más bien ninguno, se puede imaginar llevar un único proyecto, con un equipo totalmente dedicado a este, sin interacciones con otros desarrollos, casi sin interrupciones, con algunos cambios de requisitos manejables, y problemas relacionados sobre todo con la tecnología.
Lo interesante es que la complejidad de los métodos de gestión de proyectos ha aumentado en paralelo con el aumento de la complejidad del desarrollo de software, mientras que el tiempo para hacer las decisiones correctas es cada vez más corto y las expectativas de los clientes cada vez superiores.
Revisé mis apuntes de los últimos años. Los jefes de proyecto comparten los siguiente acerca de su trabajo:
Es difícil manejar la variedad de factores que influyen en un proyecto: la claridad de los requisitos, la estabilidad de las tecnologías, el nivel de conocimientos y habilidades de los miembros del equipo, los riesgos, las dependencias de otros proyectos, etc
Cuanto más sofisticado sea el método de estimación, más esfuerzo (y tiempo) se necesita para hacer un buen plan de proyecto. De todos modos este tiene una vida muy corta hasta que cambie de nuevo
Estimación, planificación, seguimiento y re-planificación es una carga administrativamuy alta, difícil de vender a los clientes, y por lo tanto sostener
Hay mucha presión para dar estimaciones rápidamente y después cumplirlas
Difícil coordinación de los proyectos.
En una situación como esta, ¿no deberíamos de revisar las prácticas de gestión de proyectos bien establecidas y buscar algunas más pragmáticas?
Aplicar métodos complejos a situaciones
complejas las complica aún más.
Enfoque Kanban de gestión de proyectos
¿Cuál es el propósito de gestión de proyectos? – Asegurarse que el proyecto se ajusta a los criterios de sus interesados (clientes y organización). ¿Correcto?
Aquí los tienes:
Aptitud del trabajo: Perspectivas
Cliente
Entregar rápidamente (tiempo)
Entregar a tiempo (previsibilidad)
Precio competitivo
Calidad (obtener el producto/servicio correcto)
Organización
a. Nivel de proyecto
Estimaciones (tiempo, coste)
Previsibilidad
Calidad
Coordinación de los proyectos
b. Nivel de negocio *
Sostenibilidad
Orientación a servicio
Supervivencia
* Ver la charla de David J Anderson sobre las 3 agendas de Kanban.
Entonces, las dimensiones de la aptitud de un proyecto y las herramientas analíticas correspondientes se pueden resumir de la siguiente manera:
Aptitud del trabajo: Dimensiones
Tiempo de entrega
Tiempo de entrega (inglés: Lead time)
Rendimiento (inglés: throughput)
Coste
Coste de las actividades de valor añadido, transaccionales y de coordinación>
Coste de los desperdicios (corrección de defectos, re-trabajo, espera)
Perseverancia del flujo de trabajo (Diagrama de flujo acumulado, DFA)
Cumplimiento de ANS (historgrama, gráfico de control)
Pincha en los enlaces para ver cómo se utiliza cada una de las herramientas y la valiosa información que aporta a tu proyecto.
Si te fijas en las herramientas que necesitas para gestionar la aptitud del trabajo de tu proyecto con respecto a cualquier criterio, cliente o organización, te darás cuenta que lo que necesitas fundamentalmente es suficiente y, por supuesto, buenos datos reales. (En cuanto a los datos, siempre tenemos que recordar que si entra basura – sale basura).
El poder de los datos reales, no las estimaciones especulativas, te da confianza
en tus compromisos y te permite dormir tranquilo, porque
reduce los riesgos de no cumplir tus promesas.
Además, ahorras todo el esfuerzo para inventar y actualizar un método de estimación formal y tratar de adaptarlo a las características únicas de cada proyecto.
Para las empresas CMMI:
El tiempo de entrega se recoge principalmente en proyectos orientados a los servicios (por las necesidades de la gestión los ANS). Sin embargo este es un dato valioso para los proyectos de desarrollo de software también.
En los proyectos de desarrollo de software por lo general se registra el esfuerzo de realización de la tarea, pero no el tiempo de entrega (el Lead time) de un requisito o historia. Esfuerzo y duración no es lo mismo. Conocer la distribución del Lead time para los tipos de trabajo o las clases de servicios ayuda a conseguir una planificación más realista.
Conociendo el Rendimiento permite (a través de la ley de Little) dar una estimación rápida y fiable del tiempo de entrega necesario para implementar un conjunto de historias / requisitos.
La visualización del trabajo en curso facilitan enormemente la coordinación de los proyectos.
El DFA es quizás el mejor indicador en tiempo real del ritmo del trabajo (proyecto) y los riesgos.
«Si no atacas los riesgos activamente, ellos te atacarán activamente» – Tom Gilb
Lo que suelo ver en las tablas de riesgos de los planes de proyecto o servicio es «retraso de la entrega», «sobrepasar el presupuesto», o «problemas en la aceptación del cliente debido a requisitos poco claros».
Al mismo tiempo, los equipos más a menudo se quejan de no poder cumplir los plazos, y superar los presupuestos.
Obviamente estamos más atacados que atacando los riesgos. (más…)
En 1992 Bill Clinton eligió un lema interesante para su campaña política:
Por supuesto, había muchos otros temas importantes para el país y una gran cantidad de factores que estaban influyendo su resolución. Sin embargo el mensaje clave de Bill Clinton se centró en el punto central para el país, la economía.
Yo me encuentro frecuentemente con empresas que se enfrentan con la necesidad de reducir el tiempo de entrega de sus proyectos y servicios, ofrecer precios más competitivos, y adaptarse mejor a las necesidades cambiantes de sus clientes.
Es difícil introducir cambios drásticos en las organizaciones donde las estructuras y responsabilidades jerárquicas llevan establecidas largos años y cualquier interrupción asusta a la gente y la hace resistir. Para estas organizaciones, la necesidad de cambio es, sin duda, reconocida. Cómo enfocar y llevarlo a cabo, sin embargo, no está bien claro.
Aunque yo personalmente no llamaría a nadie «estúpido», si tengo que resumir al estilo de Bill Clinton lo que he visto que las empresas hacen para estar en forma, diría:
Se trata de hacer el trabajo fluir, estúpido.
¿Cómo? – A través de unos pasos sencillos:
Visualizar y centrarse en una cantidad limitada de trabajo en curso
Hacer lo que aporta valor para el cliente. No hacerlo que no es necesario.
Aprender a ver y eliminar los desperdicios de los procesos. Simplificar los procesos.
Gestionar el flujo de trabajo, no el plan
Hacer que las personas resuelvan los problemas en colaboración, dentro y entre los equipos
Visualización
La visualización te ahorra esfuerzo esencial para:
entender la situación actual del trabajo – lo ves directamente en el tablero, no tienes que deducirlo de los números
tomar decisiones efectivas sobre los impedimentos en el flujo de trabajo y los riesgos – los detectas en cuanto aparezcan, no tienes que esperar ningún informe, y tienes de inmediato la imagen de la situación real que se tiene que resolver (otro trabajo afectado, personas que pueden estar involucradas)
decidir cómo adaptar el proceso estándar; lo defines con tu equipo teniendo en cuenta el proyecto real o la situación de servicio
comunicar información y llegar a una visióny comprensión compartida del trabajo – todo está en el tablero y hablar de los detalles delante de la imagen completa del trabajo que se tiene que realizar, es la manera más eficaz de comunicación
Visualizar los defectos y re-trabajo fortalece la conciencia de los miembros del equipo acerca de la necesidad de buenos procesos y les ayuda a identificar cómo mejorar las prácticas actuales. Recuerda que
«El tipo de desperdicio más peligroso es el desperdicio que no reconocemos.»
Shigeo Shingo
Limitar el trabajo en curso
Limitar el trabajo en curso en un sistema kanban hace el trabajo fluir (segunda práctica de Kanban). Centrarse en el valor y tiempo de entrega provoca naturalmente preguntas como «¿por qué hacemos esto?», «¿El cliente lo necesita?», «¿Cómo podemos obtener el mismo resultado más rápidamente?». Estas dudas a su vez llevan a simplificar y aligerar los procesos.
Además, la necesidad de auditorías y controles por el departamento de calidad se reduce porque el equipo las realiza en los momentos adecuados. Esto permite a los responsables de calidad concentrarse en resolver los problemas que afectan a varios procesos y proyectos / servicios, trabajo que corresponde a su perfil y que realmente les gusta.
Gestionar el trabajo, no las personas
Gestionar el trabajo en lugar de las personas o el plan es la clave para lograr buenos resultados. ¡Esta es la parte difícil! Puedes encontrar las métricas y técnicas más importantes en la serie de artículos sobre Analíticas Kanban. Gestión centrada en los clientes, de tiempo real y compartida por todos los miembros del equipo, disminuye la carga del director de proyecto y le proporciona más tiempo para hacer mejor su trabajo.
Todos los modelos y estándares sugieren colaboración. Pocos proporcionan medios para realmente conseguirla. Un grupo de personas con unas tareas asignadas en un proyecto común no es un equipo y no necesariamente colabora. La colaboración se produce cuando las personas se reúnen regularmente y hablan acerca de cómo lograr objetivos comunes, resolver problemas juntos, y ayudarse uno a otro cuando sea necesario. La visibilidad tiene un papel importante en la creación de un equipo y hacerle avanzar hacia una meta.
Para resumir, el entorno de negocio está cambiando constantemente y las organizaciones tienen que aprender a adaptarse y responder rápidamente a esto. Hay muchas prácticas que ayudan a las empresas satisfacer mejor las necesidades de sus clientes, pero la vital es hacer el trabajo fluir. La visualización, la gestión centrada en la entrega de valor al cliente de forma rápida, y la involucración de las personas en simplificar y aligerar los procesos son muy importantes para hacer que esto suceda.
Teodora Bozheva
Accredited Kanban Trainer & Consultant
Co-autora del Kanban Maturity Model
www.berriprocess.com
Este mes tuve un servicio interesante para el departamento TI de un banco. Digo interesante porque me contactaron para visitarles,ver cómo llevaban a cabo y gestionaban sus proyectos y decirles cómo les veía. Nada de problemas que quieren resolver, objetivos que están buscando, mejoras que les gustaría introducir o método que aplicar. Simplemente venir – ver – y darnos tu opinión.
Fui con una buena dosis de curiosidad y también con algo de preocupación porque no sabía con qué me iba a encontrar ahí.
El contexto
Para entender el contexto les pedí tanto al equipo de desarrollo de software como al de los usuarios que me describiesen su flujo de trabajo asó como todas las dificultades que tenían en su día a día (un problema por post-it).
En resumen la situación actual se puede dibujar así:
Los dolores que necesitan una cura urgente según la priorización de ambos equipos son los siguientes:
Pobres requisitos de los usuarios (definidos a nivel de idea)
Insuficiente análisis de negocio
Problemas con las estimaciones de las tareas – los usuarios no entienden qué hacen los desarrolladores tanto tiempo; existe presión por reducir las estimaciones; luego aparecen los problemas de no cumplirlas
Frecuentes cambios de prioridades
Alta carga de trabajo e incapacidad por parte del equipo de desarrollo de responder rápidamente a las peticiones de los usuarios.
Falta de gestión de riesgos
El análisis de los problemas se puede resumir así, leyendo el árbol desde abajo hacia arriba.
Se buscan “quick wins”, es decir soluciones que lleven a resultados positivos en corto plazo.
¿Qué vitaminas les receto para que noten mejoría en poco tiempo?
Definir un método de estimación vendría bien, establecer criterios y reglas de gestión de los cambios a los requisitos y de los riesgos también, pero todo esto requiere su tiempo y esfuerzo. Además, después hay que asegurarse que se acepte bien por las personas en ambos equipos – los usuarios y los desarrolladores.
Escuchando a los dolores y los miedos de los dos lados la siguiente imagen apareció en mi mente:
En el fondo de todo está el problema del mapeo (el encaje) entre los requisitos de los usuarios, en su idioma de negocio, y el trabajo del equipo de desarrollo, con todos sus aspectos creativos y técnicos.
La comunicación y la visibilidad compartida en el trabajo son
las vitaminas para las empresas TIC.
Ninguna tecnología o método formal dará resultados positivos en corto tiempo, si falla la comunicación entre las personas y falta visibilidad en el trabajo que se está llevando a cabo.
Verifiqué esta idea con el equipo y juntos llegamos a los siguientes dos elementos de la solución “quick win”:
Trabajar en equipos multidisciplinares
Usar a un tablero kanban compartido para tener visibilidad en el trabajo en curso y facilitar su entendimiento y gestión.
Ahora volvamos a los dolores que necesitan una cura urgente. Todos estarán positivamente afectados de esta solución sencilla ¿verdad?
Por lo menos en esto estamos convencidos el equipo de la organización y yo.
¿Qué tal lo ves tú?
Si crees que esta experiencia puede servir a algún amigo tuyo, re-envíale el mensaje. Te devolverá el gesto en otro momento importante para tí.
De los últimos proyectos o servicios que hayas terminado, ¿cuántos entregaste completos y en el plazo esperado? Por supuesto, sin la necesidad de trabajar horas extra o los fines de semana.
Hace 4 años empecé a coleccionar fotos de los problemas de las organizaciones de desarrollo de software, independientemente del método de trabajo que utilizan. El año pasado comencé a ampliar mi colección con fotos de empresas industriales.
¿Sabes cuál es dolor más recurrente?
– Los retrasos de los proyectos / servicios. Que a su vez llevan a sobrecostes.
Lo que aumenta la amargura de la persona responsable para un retraso es que ha hecho todo lo posible para evitarlo: ha intentado de desglosar bien el trabajo, de evaluar los riesgos, ha añadido colchón a las estimaciones, etc, etc.
Aun así se ha cumplido la ley de Murphy, “todo lo que pudo perjudicar al proyecto ocurrió en los peores mementos posibles”, como p.ej:
Uno de los compañeros se puso malo y su trabajo se tuvo que distribuir entre las otras personas del equipo
Surgieron dos proyectos nuevos, importantes, que se tenían que compaginar con el resto del trabajo
Algunas de las tareas resultaron más complejas que lo esperado. Por tanto se tardó más en hacerlas y esto afectó a otros trabajos.
La aprobación del cliente / la entrega del proveedor llegó fuera del plazo previsto
Hubo un día loco cuando todo el mundo llamaba por teléfono para pedir algo, y se terminó la jornada sin prácticamente avanzar el trabajo planificado
Etc, etc.
¿Te suenan estos motivos para los retrasos?
¿Te imaginas una semana en la que te dedicas a lo que tienes pensado, disponiendo de toda la información que necesitas, ordenando tus tareas sin la presión de terminar alguna antes que otra, sin interrupciones, completando todo bien y profesionalmente como a ti te gusta?
¡5 días volviendo a casa satisfecho con el trabajo cumplido y teniendo tiempo y ánimo para disfrutar la tarde-noche con los tuyos!
¿Qué causa los retrasos?
La primera razón que se nos ocurre son las estimaciones.
Las estimaciones ¿de qué?
Los métodos tradicionales como CMMI y PMBoK incluyen prácticas acerca de la elaboración del calendario de un proyecto / servicio.
Para poder definir el calendario estos métodos sugieren lo siguiente:
Desglosar y definir el trabajo en suficiente detalle
Secuenciar las tareas
Estimar el tamaño de las tareas y de ahí el esfuerzo para su ejecución
Tener en cuenta la disponibilidad de los recursos para el trabajo
Tener en consideración los niveles de experiencia y capacitación de los recursos
Identificar y evaluar el impacto de los riesgos para el proyecto
Los métodos tradicionales estiman el tamaño y el esfuerzo, pero no estiman el tiempo de los trabajos (el hecho se estima que una tarea requiere 5 horas de trabajo no significa que se va a terminar en un tiempo de 5 horas).
Los métodos ágiles utilizan sprints (iteraciones) de una duración fija (de dos semanas habitualmente) y estiman el alcance (las historias de usuario) que se puede implementar en este time-box en base a la velocidad del equipo. Es decir, los métodos ágiles no estiman el tiempo de ejecución de los trabajos.
Si tenemos problemas con la desviación en plazo, ¿por qué estimamos esfuerzo y no tiempo?
El primer enemigo al cumplimiento de los plazos es confundir tiempo y esfuerzo
Desde que empecé a estudiar a fondo el problema de los retrasos, los datos de las diferentes empresas donde hemos medido estos dos parámetros muestran que el esfuerzo ronda entre 7% y 20% del tiempo de ejecución de un trabajo. Por ejemplo, si el tiempo que pasa entre empezar y cerrar una tarea es 10 días naturales, el esfuerzo que se imputa a esta es menos de 2 días. El resto del tiempo la tarea está parada por diferentes motivos: espera a información adicional, otra tarea más urgente, etc.
En Lean Kanban France-2012 Zholt Fabok presentó datos aún más preocupantes: 95% del tiempo de ejecución pasa en espera. Ver Measure and Manage Flow in Practice para más detalles.
Tiempo y esfuerzo son dos medidas diferentes.
Separa sus estimaciones, si quieres reducir los retrasos.
Cuando dejamos una tarea para [volver a] empezar otra, a veces tenemos la sensación que están avanzando las dos.
¡MENTIRA!
Las multi-tareas solo ralentizan la terminación de los trabajos y reducen la productividad un 40%. (Samsung Business)
El segundo enemigo al cumplimiento de los plazos es el volumen de trabajo en curso
Consulta la Ley de Little para que entiendas que cuánto más trabajo tenemos entre manos, tanto más tardamos en terminar cada uno de ellos.
Un ejemplo: en abril Ander fue padre por primera vez. ¡Un momento feliz en su vida! Antes de salir de baja de paternidad se concentró en terminar lo máximo trabajo posible para que los dos compañeros de su equipo no se quedasen parados mientras él disfrutaba de la llegada de su hijo. Dejó una pila de diseños empezados y no terminadas (faltaba completar lo que correspondía a las otras dos personas). Consecuencia: el tiempo promedio de terminación de un trabajo por el equipo aumento de 13 a 21 días (un 60% de aumento).
Ya sé que esto es contra-intuitivo. Por eso te invito a experimentarlo tú mismo haciendo el ejercicio que te dejo abajo.
Resumen
No distinguir tiempo y esfuerzo y el volumen del trabajo en curso son dos enemigos ocultos que siempre atacan el cumplimiento de los plazos.
Si queremos reducir los retrasos, tenemos que controlar el tiempo de ejecución de los trabajos.
Para que reflejes y sientes el placer de entregar a tiempo sin estrés, haz el siguiente ejercicio:
Durante una semana recoge los siguientes datos por cada tarea que haces: fecha inicio, fecha cierre, esfuerzo dedicado
Por cada tarea calcula el Lead time = Fecha cierre – Fecha inicio +1
Refleja sobre lo siguiente:
Ratio entre Esfuerzo dedicado y Lead time
Relación entre el promedio(Lead time) y el promedio(Trabajo en curso) (el número de tareas abiertas) por día
La métrica rendimiento (tasa de entrega) es relativamente poco conocida en las empresas de gestión de proyectos tradicional (basadas en PMBOK, PRINCE2, CMMI). Sin embargo, con la difusión de los conceptos Lean, creo que empezará a ganar más respeto en el futuro próximo.
El rendimiento es la cantidad de elementos de trabajo entregados en un período determinado de tiempo (p.ej. semana, mes, trimestre).
Cuando decimos ‘entregado’ nos referimos realmente a trabajo terminado y, posiblemente, entregado al cliente. Es decir, al final del proceso se cobra.
Para entender el concepto de rendimiento, vamos a suponer que durante las últimas cinco semanas un equipo ha entregado respectivamente 4, 6, 4, 2, y 3 historias de usuario (requisitos) por semana. Si hay historias empezadas, pero no terminadas, estas no forman parte de los cálculos.
El rendimiento promedio del equipo durante estas cinco semanas es (4 +6 +4 +2 +3) / 5 = 4 historias / semana (redondeado). La desviación estándar se redondea a 1 historia / semana.
El rendimiento se basa en datos reales de la capacidad del equipo de terminar/entregar trabajos. La variabilidad del rendimiento refleja el impacto de factores como el tamaño de las historias, su complejidad, urgencia, así como las habilidades de la personas.
El rendimiento se puede utilizar para planificar un proyecto. Por ejemplo, siguiendo con el ejemplo anterior, el equipo puede estimar que su rendimiento (capacidad de la entrega) será de 4 ± 1 historias por semana sin hacer ninguna estimación detallada de los requisitos individuales.
En Kanban, sin embargo, el rendimiento se utiliza principalmente para dar seguimiento al ritmo de producción (entrega) del equipo. Lógicamente, el objetivo es mejorar continuamente.
El rendimiento es una medida del número de elementos de trabajo que el equipo es
capaz de producir en un determinado período de tiempo (por ejemplo, semanas,
meses), siempre y cuando se mantenga una carga de trabajo uniforme.
Rendimiento y velocidad
El rendimiento es similar a la métrica ágil velocidad, sin embargo, se utiliza de manera diferente.
La velocidad se utiliza en eXtreme Programming y Scrum. Muestra la cantidad de trabajo que un equipo puede completar en una iteración o sprint. El trabajo se mide en puntos de la historia (story points).
Volviendo al ejemplo del equipo anterior, supongamos que los cinco casos de uso completados durante las últimas dos semanas, son de 3, 4, 1, 5 y 3 puntos de historia respectivamente.
Entonces, el número total de puntos de la historia que el quipo puede completar en un sprint de 2 semanas es 3 +4 +1 +5 +3 = 16. Es decir, la velocidad del equipo es de 16 puntos de la historia por sprint.
La velocidad también varía debido a factores como la complejidad de las historias, su tamaño, los cambios, el nivel de habilidades de equipo, etc.
Los equipos ágiles utilizan la velocidad promedia para estimar cuántas historias serán capaces de implementar en los sprints futuros. A pesar de todo, tienen que estimar los casos de usuario individuales con el fin de definir el backlog (el alcance) de un sprint.
Así que, aunque la métrica velocidad se asocia con rapidez, de hecho se trata de la carga, (medida habitualmente en puntos de historia) que un equipo puede llevar a cabo durante un período de tiempo determinado (iteración, sprint).
Rendimiento y estimación de los recursos
El rendimiento se puede utilizar para estimar los recursos necesarios para realizar un desarrollo o servicio.
Según la Ley de Little:
Si un equipo mantiene a un ritmo constante de trabajo, el tiempo promedio de entrega (lead time) para un determinado tipo de trabajo o una clase de servicio puede considerarse como una constante.
El rendimiento (throughput) es el objetivo que debe lograrse con el fin de cumplir la fecha fin definida por el cliente.
Aplicando la ley de Little calculamos el número de elementos de trabajo que hay que procesar en el tiempo determino.
Ejemplo: supongamos que el tiempo de entrega de una historia es de 0,25 semana. El rendimiento objetivo es de 20 historias/semana.
Entonces, El trabajo en curso (WIP) = 20*0,25 = 5 historias.
Asumiendo que una persona sólo puede trabajar sobre un único requisito, deducimos que necesitamos un mínimo de 5 personas para la implementación de todo el trabajo a tiempo. Por si acaso (no hay fórmulas precisas para esto), estaría mejor contar con un equipo de 6 personas. :-)
La ley de Little y el rendimiento permiten estimar los recursos necesarios
para llevar a cabo un trabajo.
En resumen, el rendimiento es fácil de recoger. Es una medida valiosa, ya que mantiene el foco centrado en la capacidad productiva del equipo. Asimismo, conociendo el rendimiento del equipo disminuye el esfuerzo para la estimación de las historias (requisitos), siempre y cuando estas se desglosan a trozos relativamente pequeños. Además, a través de la ley de Little, el rendimiento permite estimar los recursos necesarios para completar un trabajo determinado en el tiempo esperado por el cliente.
La eficiencia es indicador de cuánto de lean es vuestra organización.
En cuanto a las empresas TIC:
Eficiencia de flujo de unos 2% ha sido reportada [Zsolt Fabok, Lean Agile Scotland, Sep 2012].
Eficiencia de 5% a 15% es normal
Eficiencia de > 40% es buena!
Como bien se explica en el libro «This is Lean», existen tres fuentes principales de la baja eficiencia:
¿Qué causa la eficiencia baja?
Largo tiempo de entrega
Esperar demasiado tiempo para obtener un producto o servicio genera necesidades adicionales para el cliente. Estos también deben ser abordadas, y por lo tanto suelen causar retrasos adicionales.
Para dar un ejemplo: cuánto más espera un cliente la aplicación o el servicio que haya solicitado, tanto mayor será la probabilidad de pedir cambios o incluso cancelar la petición. Además, la gestión de los cambios aumenta el tiempo de entrega aún más.
De aquí…
Los equipos ágiles son más eficientes porque utilizan iteraciones de corto tiempo.
Disminuir el tiempo de entrega es uno de los medios para aumentar la eficiencia.
Una manera de reducir el tiempo de entrega es reduciendo el tamaño de las unidades de trabajo y los lotes. Por eso, cuando veo requisitos de 500-1000+ persona-horas cada uno e iteraciones de 3+ meses, siempre recomiendo reducir tanto el tamaño de los requisitos como la duración de la iteración.
Reducir el tamaño de los requisitos para aumentar la eficiencia.
Demasiados unidades de trabajo en curso
Trabajando sobre muchos requisitos / servicios / peticiones en paralelo
requiere esfuerzo, tiempo y recursos adicionales para su gestión: saber que se ha hecho en cada uno de ellos, dónde se almacena, que está pendiente, etc
lleva amultitareas (cambio frecuente de tareas) – otra fuente principal de ineficiencia. Aquí puedes ver un buen resumen del alto coste de las multitareas
oculta problemas porque cuando hay muchas unidades de trabajo abiertas, es difícil de detectar y corregir los problemas de calidad
causa ansiedad y estrés. Esto reduce la calidad del trabajo, aumenta el tiempo de corrección de problemas y, como consecuencia, reduce la eficiencia.
Por lo tanto,
Reduciendo el trabajo en curso en un sistema kanban aumenta
la eficiencia del flujo de trabajo.
Demasiados traspasos
Piensa cómo te sientes cuando llamas, por ejemplo, a tu proveedor de telefonía móvil y te pasan de un operador a otro, y cada vez tienes que volver a explicar tu problema desde el principio. Des de la perspectiva del cliente los traspasos generan frustración ¿verdad?
Desde la perspectiva del proveedor de servicio el traspaso de un trabajo a otra persona siempre conlleva el riesgo de pérdida de información y generación de defectos. Además, cualquier traspaso de trabajo requiere esfuerzo y tiempo adicional para explicar, de forma oral o por escrito, el estado actual del trabajo y lo que ha de tener en consideración en las etapas posteriores.
Los traspasos no siempre se pueden evitar, sin embargo el trabajo en equipos
multidisciplinarios reduce sus efectos negativos.
(Tiempo de entrega, Tiempo de ejecución, Tiempo de entrega del sistema)
Lead time es el tiempo que transcurre desde el principio hasta el final del procesamiento de un elemento de trabajo.
Ejemplos:
Decides comprar por internet un billete de avión para tus vacaciones. El Lead time de adquirir el billete empieza a correr en el momento en el que te sientas en frente al ordenador y abres un navegador, y termina cuando tienes tu billete electrónico en tu buzón.
Quieres ver a tu médico. El Lead time de la obtención de tu diagnóstico es el tiempo entre el momento de llamar para pedir una cita y el de salir de la consulta con tu diagnóstico en mano.
El tiempo de ejecución para el desarrollo de un requisito de cliente es el tiempo desde el momento en que tu equipo empieza a trabajar en él hasta el momento en que la funcionalidad está lista para subirla en producción. Es decir, el tiempo que transcurre entre el momento en que el requisito entre y salga del sistema kanban (alcanza una columna con límite WIP infinito).
Para medir bien y consistentemente el Lead time, es importante establecer los límites del sistema kanban.
¿Por qué el Lead time es importante para ti?
El tiempo de entrega es un indicador del valor. Cuanto más rápido ofreces valor a tus clientes, mejor. Sin embargo, hay que tener en cuenta las expectativas del cliente también. Entregando demasiado rápido no siempre aporta valor. Por ejemplo impartiendo una clase de 8 horas en solo 6 horas no hará los alumnos más contentos.
El plazo de ejecución es crucial para las empresas orientadas a servicios, porque ayuda a establecer ANS realistas, así como gestionar el cumplimiento de estos.
Conocer la distribución del tiempo de entrega proporciona previsibilidad. Desde luego, es importante conocer la distribución del tiempo de entrega por tipo de trabajo o clase de servicio.
Si además del plazo de ejecución del sistema, observas el tiempo que cada unidad de trabajo pasa en una columna (un estado), podrás reducir la espera y de esta manera, acelerar el desarrollo o el servicio y mantenerse lean (la espera es una forma de desperdicio).
Te podría resultar útil comparar el tiempo de valor añadido y el tiempo de ejecución. En otras palabras, comprobar la eficiencia de vuestro trabajo. Un momento esencial para un cliente mío fue cuando se dieron cuenta que el trabajo desarrollado en 6-10 horas se entregaba a sus clientes en 35-52 días!
En un sistema kanban estable conocer el trabajo en proceso (WIP) y el tiempo de ejecución permite calcular el rendimiento (aplicando la ley de Little). El rendimiento es similar a la métrica Ágil velocidad. Observar su tendencia te da una indicación del rendimiento general de tu equipo.
Herramientas para analizar el Tiempo de entrega
Histograma
Conociendo la variación del tiempo de entrega para requisitos de tamaño Pequeño, y teniendo entendimiento del contexto (claridad del requisitos a desarrollar, el nivel de experiencia del equipo, tecnología, riesgos) puedes prever más fácilmente el tiempo que le llevará a tu equipo implementar una funcionalidad concreta.
Los datos reales ya incluyen información del impacto de los factores que influyen en el desarrollo de esta clase de requisitos. Por lo tanto, no necesitas una fórmula estricta para estimar el tiempo de desarrollo de un nuevo requisito.
Asegúrate que conoces la distribución del tiempo de entrega de los tipos
de trabajo y clases de servicios y deja de preocuparte por tus compromisos.
Algo importante. Si obtienes un histograma como éste, con dos modas, esto significa que has mezclado datos de diferentes tipos. Continuando con el ejemplo anterior, esto probablemente significa que mezclado datos de requisitos de tamaño Pequeño y Mediano.
Estratificar los datos para hacer conclusiones sólidas.
Gráfico de control
El gráfico de control es otra forma de visualizar los mismos datos que ves en el histograma, juntos con su media y los límites de control superior e inferior.
Analiza las causas para los puntos que quedan fuera de los límites de control. Estas causas se denominan causas especiales o causas asignables. Si no estás satisfecho con la distancia entre los límites de control, puedes analizar las causas comunes para la variación y abordarlas para reducir la variación. De esta manera mejorarás laprevisibilidad.
Uso de los gráficos para tomar decisiones
Estos gráficos son particularmente útiles cuando tienes que estimar el riesgo de cumplir las expectativas del cliente.
Imagínate que tu cliente espera una nueva funcionalidad pequeña en un día sólo (teóricamente 8 horas de trabajo :-)).
¿Con qué confianza te comprometerás entregársela a tiempo?
¿Y si el cliente espera tenerla en 6 horas?
Herramientas
Las herramientas Kanban suelen construir estos gráficos de los datos en el sistema.
Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos.
Más información
