Agile


Estimación ágil con la técnica Planning Poker 2

Estimación ágil con la técnica Planning Poker

Sin entrar en el tema de si se debe estimar o no en el desarrollo de software, es cierto que tener una estimación aunque sea a alto nivel nos será útil para tomar mejores decisiones a la hora de ordenar y priorizar el backlog. Por ejemplo si tenemos historia A y B, y la historia A aporta valor 100 con esfuerzo 100 y la historia B aporta valor 90 pero esfuerzo 10, seguramente sea más interesante hacer primero B antes que A. La estimación ágil En la estimación ágil perseguiremos los siguientes objetivos: Tener diferentes puntos de vista. Está claro […]


medir la productividad en un equipo de software

Como medir la productividad en un equipo de software

Dice Peter Drucker que “Lo que se puede medir se puede mejorar”. Yo puntualizaría que para poder mejorar algo primero debes tener claro qué estás intentando mejorar, y entender cuál es el objetivo real y las consecuencias de mejorarlo antes de siquiera plantearte cualquier medición. La productividad de un equipo de desarrollo de software es muy difícil de medir, entendiendo productividad no solo como eficiencia (cantidad de trabajo) sino también como efectividad (el sentido y la idoneidad del trabajo). Eficiencia en un equipo de software Para medir eficiencia primero tenemos que saber qué eficiencia queremos medir, si eficiencia de flujo […]


Eficiencia de recursos y eficiencia de flujo

Eficiencia de recursos y eficiencia de flujo en el software

La eficiencia es una palabra que siempre se ha utilizado de cara a buscar mejoras en equipos y departamentos, especialmente en el mundo del software. A priori cualquier persona pensará que maximizar la eficiencia es positivo. Existe un pequeño problema con la eficiencia, y es que la hay de varios tipos. Principalmente tenemos la eficiencia de recursos y eficiencia de flujo, y no siendo del todo opuestas, no es posible maximizar una sin penalizar la otra. Eficiencia de recursos La eficiencia de recursos es el modelo que impera en las grandes corporaciones, organizada en departamentos y con una serie de […]


Reducir tiempos de desarrollo

Reducir tiempos de desarrollo es una mala idea

Existe un principio llamado Ley de Parkinson, muy aplicado en el trabajo del conocimiento en general y en el mundo del software en particular, que dice que el trabajo tiende a expandirse hasta llenar el tiempo disponible para terminarlo. Como ya comenté en este post titulado Vicios peligrosos en la gestión de proyectos, esta ley no es universal y no es aplicable en equipos altamente cualificados y comprometidos con su trabajo. A pesar de ello es inevitable pensar en el hecho de que sí es posible alargar deliberadamente una tarea más de la cuenta. Lo mostraré en el siguiente gráfico: […]


El mito de la desviación en proyectos de software

El mito de la desviación en proyectos de software

En el mundo del desarrollo de software está muy extendida la palabra desviación aplicada al proyecto. Cuando un proyecto se desvía quiere decir que se planificó inicialmente en un tiempo determinado y con un presupuesto acotado y que actualmente ese tiempo y/o presupuesto se ha superado. En gestión de proyectos, como en todo, las palabras y el lenguaje importa, por lo que me gustaría escribir y reflexionar sobre este aspecto tan interiorizado y aceptado que creo que merece la pena una revisión. Por qué se desvían los proyectos (el mito) Tengo un proyecto en mente: comprar un pez para mi […]


goals22

Vicios peligrosos en la gestión de proyectos

Quiero hablar de algo que he oído al 99% de directores de proyecto, jefes de proyecto, gerentes de proyecto, e incluso a Scrum Masters. Como los gases tienden a ocupar el 100% del volumen disponible, una tarea asignada a una persona tenderá a ocupar el 100% del tiempo asignado para ella, o incluso más. Por eso, “lo que hay que hacer” es asignar un poco menos de tiempo y así en el mejor de los casos lo tendremos antes, y en el peor lo tendremos a tiempo. Esto puede tener un corolario, la Ley de Parkinson, que dice que si […]


formula12

La mal llamada “Velocidad del Equipo”

En las metodologías ágiles se utiliza una medida para calcular el ritmo en el que el equipo es capaz de ir avanzando en las tareas, mal llamada velocidad del equipo. Voy a intentar explicar por qué lo veo un mal nombre. La idea es que el equipo mide su velocidad para poder hacer previsiones. Las tareas se estiman bien en horas o en puntos de historia y cuando se van completando, se mide el número de horas o puntos por unidad de tiempo. Así por ejemplo podríamos decir que la velocidad del equipo es de 18 puntos de historia por […]