Mi equipo trabaja en un sprint de 3 semanas y, en consecuencia, calculamos la capacidad del miembro del equipo en función de sus vacaciones planificadas y las vacaciones de la empresa.
Pero no podemos negar ninguna licencia no planificada / enfermedad, reuniones no planificadas y capacitación. Diferentes comunicaciones Inter e Intra del equipo que pueden ser importantes para mi propio proyecto o para otros equipos. El intercambio de conocimientos es un valor central importante de una organización en crecimiento que fomenta las interacciones abiertas entre equipos.
Las diferentes Ceremonias de Sprint también toman algo de tiempo de los miembros del equipo durante estas 3 semanas. Qué puntos son importantes a considerar para calcular la Capacidad de los miembros del Equipo considerando que pasan 8 horas en la oficina.
Estoy deduciendo que su equipo usa puntos de historia para una estimación inicial y luego, en la reunión de planificación, divide las historias en tareas y las estima a nivel de horas.
Primero, algunas sugerencias generales:
Nunca programes 8 horas al día. Las interrupciones suceden. Solo programe unas 6 horas al día para tareas de desarrollo.
Asegúrese de eliminar esos días libres planificados de la capacidad del equipo. Del mismo modo, asegúrese de eliminar también los horarios de reunión conocidos de la capacidad.
Pero parece que ya lo sabes. Quiere saber cómo manejar las ausencias inesperadas.
Deje un poco de holgura en su planificación.
Los humanos somos muy malos estimando. Por lo general, las cosas tardan más en hacerse de lo que estimamos. Dejar un poco de holgura en tu horario te permite absorber tanto las malas estimaciones como algunas ausencias. Si el equipo cumple con su objetivo de iteración antes de tiempo, entonces tiene algo de tiempo para pagar algunas deudas técnicas.
Acepte que cualquier estimación dada probablemente será incorrecta y no siempre terminará todas las historias, incluso si todas aparecen todos los días.
Básicamente, no te preocupes por eso. Tómese un tiempo para recordar que los desarrolladores son personas, que usted es una persona y no máquinas generadoras de código. Acepte la incertidumbre del desarrollo de software y encuentre formas de ser flexible. ¿Podemos soltar una historia de esta iteración? Joe hizo sus tareas temprano, ¿puede recoger las de Susy mientras ella está fuera? ¿Podemos extender esta iteración una semana más? Aprende a ser flexible (me atrevo a decir, ágil ) y reacciona ante lo desconocido con gracia.
Entonces, ¿fallaste en entregar todas las historias en la iteración? Vaya cosa. Sucede. Tráigalo en retro, deje que el equipo hable sobre por qué y cómo pueden disminuir el impacto de los días libres no planificados. Tendrán ideas mucho mejores que los extraños en Internet.
Deja de hacer estimaciones de nivel de horas.
Es en gran medida una pérdida de tiempo que genera una falsa sensación de saber, en mi experiencia personal. En su lugar, utilice el número histórico de puntos de historia completados como la capacidad de su equipo. En cualquier caso específico, será incorrecto, pero también lo será la planificación de la capacidad a nivel de horas. A veces harán más, a veces menos, sin embargo, en promedio , es una buena indicación de cuánto puede lograr el equipo en una iteración.
El objetivo no es el rendimiento bruto de las tareas. El objetivo es una iteración de una pieza de software valiosa y funcional. Haga lo más importante primero, y tendrá eso ya sea que alguien en el equipo se enferme por unos días o no.
La Guía Scrum dice esto sobre las cosas a tener en cuenta al determinar los compromisos para el próximo sprint.
La entrada a esta reunión es el Product Backlog, el último Incremento del producto, la capacidad proyectada del Equipo de Desarrollo durante el Sprint y el desempeño anterior del Equipo de Desarrollo. El número de elementos seleccionados del Product Backlog para el Sprint depende únicamente del Equipo de Desarrollo. Solo el Equipo de Desarrollo puede evaluar lo que puede lograr durante el próximo Sprint.
Lo más importante a tener en cuenta es la evidencia real del trabajo que ha realizado en el pasado . La medida de cuánto puede hacer su equipo en una iteración generalmente se llama Velocidad .
No importa si los miembros del equipo están allí durante 8 horas. No importa que a veces haya reuniones. No estamos interesados individualmente en estas cosas, y es mucho mejor medir directamente lo que nos importa, nuestra velocidad.
Tenga en cuenta que el equipo de desarrollo es responsable de decidir los compromisos (no el scrum master) y que el desempeño se mide como equipo, no como individuos .
Mientras que la guía de Scrum deja el "Cómo" el equipo de desarrollo estima las historias como un ejercicio para el lector, la mayoría de los equipos exitosos usan algo como Puntos de historia .
Por ejemplo, digamos que mi equipo tiene algunas historias de tamaño (en puntos, la izquierda es la prioridad más alta) { 1, 5, 8, 3 }. Si en el último sprint logramos 6 puntos, el equipo sabe asumir 1y 5solo. Si logramos 9 puntos, sabemos que puedo enfrentarme a 1, 5y 3. Lo que impulsa las decisiones del equipo es la evidencia de iteraciones anteriores. Un "punto" no está vinculado a ninguna cantidad de tiempo que no sea a través de nuestra medida de velocidad basada en evidencia.
Los equipos que usan estimaciones de horas en la práctica no hacen un buen uso de la velocidad y, por lo tanto, planifican mal.
Así que para resumir,
Calcule la capacidad de su equipo como un rango agregado basado en el rendimiento histórico, en lugar de como una suma de las horas ideales disponibles para cada individuo. Además, debe considerar cuidadosamente lo que espera lograr con dicho cálculo y determinar si un enfoque más ágil para la productividad y la estimación estadística podría no ser una mejor opción.
Mi equipo trabaja en un sprint de 3 semanas y, en consecuencia, calculamos la capacidad del miembro del equipo en función de sus vacaciones planificadas y las vacaciones de la empresa.
En Scrum, la velocidad o la capacidad de un individuo nunca se calcula. En su lugar, calcula la capacidad proyectada de todo el equipo en función de las medidas empíricas del rendimiento anterior y espera que las variaciones menores en la capacidad individual o de iteración se equilibren con el tiempo.
Más importante aún, si bien puede usar varias técnicas para estimar las horas ideales disponibles para el equipo, esto no le dará una buena previsibilidad con respecto a la cantidad de trabajo que puede realizar en un Sprint. A menos que sea su primer Sprint, es mucho mejor usar el tamaño relativo (por ejemplo, puntos de la historia) y estimar cuánto trabajo podrá realizar en cualquier iteración dada en función de datos empíricos sobre cuánto trabajo ha podido hacer el equipo. cumplir en el pasado.
Incluso si elige usar horas ideales en lugar de puntos de historia, calcularía la capacidad de un equipo. Por ejemplo:
Entonces, un equipo de cinco personas tiene 60-90 horas-hombre ideales disponibles en un Sprint de tres semanas. Podría detenerse allí y dejar que la variación estadística se solucione por sí sola.
Como alternativa, puede aplicar un factor de fudge para ajustar los problemas conocidos en un próximo Sprint. Por ejemplo, podrías:
Pragmáticamente, tiendo a aplicar factores de elusión para grandes posibles frenos en la velocidad, pero generalmente los ignoro para perturbaciones menores como citas planificadas con el dentista.
Parece probable que su problema real no sea la falta de estimación de precisión, sino que está tratando a los miembros del equipo como recursos individuales y se esfuerza por optimizar la utilización en lugar del rendimiento. Si bien no lo dijo explícitamente, la forma en que está formulada su pregunta al menos implica que las tareas se asignan a individuos, en lugar de que el equipo sea el propietario colectivo y, por lo tanto, la ausencia o la capacidad reducida de cualquier miembro del equipo pueden crear cuellos de botella. o exponga dependencias dentro de su canal de entrega.
No hagas eso.
En su lugar, asegúrese de que los elementos de la cartera de pedidos sean propiedad de todo el equipo y que el equipo esté trabajando en colaboración para completar las historias en lugar de secuencialmente o en paralelo. Además, los elementos del backlog deben ser tan independientes entre sí como sea posible, de modo que la imposibilidad de completar uno debido a limitaciones de recursos o de tiempo no "detenga la fila" para otros elementos del backlog también.
Incluso si no está cometiendo los errores que acabo de describir, tómese un tiempo para considerar realmente por qué está tratando de rastrear las métricas de capacidad a nivel individual, en lugar de adoptar el enfoque basado en el equipo que sustenta la mayoría de las metodologías ágiles. Es posible que se sorprenda al descubrir que hacerlo es innecesario, e incluso contraproducente, en muchas circunstancias.
Intente adoptar la idea LEAN de 'desperdicio'
Haga que el equipo registre sus horas contra tareas, reuniones, administración, etc. para que pueda calcular exactamente cuánto tiempo dedica a tareas 'no laborales' cada semana.
Esto le dará un porcentaje promedio de tiempo "desperdiciado" que puede tener en cuenta en la capacidad de las personas Y le permitirá identificar cosas que puede eliminar para aumentar la capacidad.
En lugar de tratar de planificar reuniones, capacitaciones o días de enfermedad no planificados, programe un conjunto de horas cada día para actividades centradas en el equipo, como:
Además, cree una historia de reserva que capture un porcentaje de la capacidad de cada miembro del equipo en cada sprint para manejar elementos de acción previsibles, como:
Referencias
anurudh singh
nathan cooper
nathan cooper