1- ¿Cómo determinas la capacidad de un sprint, especialmente del primer sprint (no tienes anteriores para basarte en ellos)?
2- ¿Como cuantificas el esfuerzo de una historia? Esto para mi tiene relación directa con la medida que se tomo para calcular el sprint.
Repasando apuntes de Scrum me encuentro con que:
1- Los equipos en el sprint planning meeting estiman "esfuerzo" o puntos de historia. ¿Y entonces quién da la duración de una historia? (Nosotros no estamos haciendo esto, creo que siempre tocábamos la duración)
2- El esfuerzo no esta relacionado directamente con el tiempo. Pero la mayoría de ejemplos que encuentro si calculan la capacidad en base al tiempo y dedicación (eficacia) de los recursos disponibles, por lo que, ¿el esfuerzo no queda inmediatamente asociado al tiempo?
[[ Y le he respondido ]]
(…) A mí me costó entenderlo también.
Te lo explico en breves pautas que suelo seguir, aunque el segundo punto que has encontrado sobre apuntes de Scrum lo resume bien:
- Los storypoints dan un valor al esfuerzo necesario para realizar una historia de usuario.
- La carga de trabajo de la historia, como bien dices, no queda asociada de forma directamente proporcional al tiempo real del que dispones.
- El esfuerzo estimado en puntos se asocia de forma relativa al tiempo. Esa relatividad la das tú.
- Si asumimos que una persona hábil, a capacidad normal, puede hacer dos puntos cada 8 horas (lo tengo demostrado), puedes hacer una estimación aproximada de cuánto va a tardar en realizarse esa historia.
- A partir de ahí, si sabes que esa persona tiene constantes interrupciones, entonces el esfuerzo en realizar 2 puntos, en vez de 8 horas, será de 10 o 12 horas.
- Lo mismo pasa si la persona no es muy hábil o no conoce el entorno de trabajo, que el tiempo que tarde en desarrollar esos dos puntos será mayor que el tiempo ideal.
- Finalmente las horas asignadas van a ir llenando el sprint, dependiendo de las horas que tengas configuradas como horas de jornada de trabajo (horas diarias) y los días que le tengas asignado al sprint, quitando los días festivos, de descanso u otras excepciones que pongas en el sistema con el que scrumices todo.
Hay algunos documentos que dicen que el desarrollo tope de un programador son dos puntos diarios, pero no lo creo. Un desarrollador ágil, dedicando 8 horas al día a programar, menos media hora de café y media de interrupciones, es decir, 7 horas al día, es capaz de hacer 2 puntos y medio de esfuerzo.
Estimar menos para programadores ágiles dedicados full time a un proyecto será estimar holgadamente. Obsérvalo tú mismo.
(…)
¿Estáis de acuerdo conmigo? Porque quizá soy yo el que anda estimando mal las historias…
Un saludo a tod@s.
3 comentarios:
Yo veo que lo que llena un Sprint es el esfuerzo que pongas en cada historia, no las horas.
He definido la capacidad en CC, según el calculo que creo por ahora fiable, en base a la eficacia (%) y disponibilidad (días) de cada programador. El cual por supuesto evolucionará con cada Sprint, según la velocidad obtenida.
Tengo una historia estimada en 16 horas, ¿cuánto es su esfuerzo, en condiciones ideales? 4?
En la teoría esto se hace con el equipo. Dada una historia te dicen el esfuerzo. Sin embargo al dividir en tareas, se habla de tiempo para completar una tarea. Lo que dará casos como que una historia con esfuerzo 4 (supuestamente 16 horas) al dividirse en tareas acabe teniendo 24 horas. El esfuerzo se debería incrementar ¿no?
Ya… pero al crear el sprint ya defines su capacidad dependiendo de los días que dure y la velocidad del equipo en anteriores sprints. --- ahí podrás poner la capacidad según la velocidad del equipo.
Según la velocidad, porque también defines unos días --- por ejemplo: un sprint de 24 días hace una capacidad aproximada de 42 puntos (2 cada día de 8 horas).
Esa capacidad se irá llenando con el esfuerzo que hayas puesto a cada tarea.
Pero fíjate: 24 días es un mes de trabajo. Se supone que son 160 horas aprox., sin embargo, sumando las horas asignads a las historias de usuario que hemos metido en el sprint, podemos obtener 137 horas.
¡No llega a las 160! Eso es porque he estimado 2 puntos por día y no 2puntos y medio, como te digo, que hubiera sido más real teniendo a Alan trabajando en el proyecto, que no fuma (más tiempo para programar) y conoce el proyecto al dedillo (más rapidez). Entonces no estoy haciendo caso a la velocidad, no?
PREGUNTA: Tengo una historia estimada en 16 horas, ¿cuánto es su esfuerzo, en condiciones ideales? 4?
RESPUESTA: En mi caso, de 4 a 5 puntos (8h – 2.5 ptos) en el tuyo, ya irás viendo. Te recomiendo 2 puntos por 8horas y luego ajustas.
El equipo te podrá decir cuántas horas o días tarda en hacerlo, pero no el esfuerzo que supondrá, porque esta valoración la obtienes de: 1 – el historial de trabajo de cada persona del equipo 2 – las posibles interrupciones que sepas (o imagines) que tendrá el equipo 3 – tu experiencia como “estimador”.
La estimación inicial debe hacerse con el equipo, como bien dices. Ellos te dicen horas o días y tú lo traduces a puntos.
La división en tareas y horas por tarea también, pero si eres listo, en la estimación inicial, aunque te digan: bahh eso está en 2 días, tú pondrás o uno, o dos o tres días. Lo recomendable es explicar en detalle la tarea y que la estimación la pongan todos, por votación.
Toma como base los tres puntos que te he dicho antes: historial, planificación que conozcas o preveas y tu experiencia en programación, planificación, etc.
No te comas el coco, porque sprintar una y otra vez es lo que te dará la experiencia para estimar.
Un año despues de comentar esto, de ir probando el esfuerzo de las personas, hemos demostrado lo que le comenté a "el ñaco" en su día.
Un programador hábil es capaz de hacer 2 puntos y medio en una jornada de 8 horas. De 2 puntos que conseguíamos al principio, la capacidad de las personas que hemos trabajado en equipos de Scrum ha subido medio punto más, poniéndonos en 2 y medio.
Contando con un framework y un set de utilidades de programación, el esfuerzo para realizar determinadas historias, por supuesto, se reduce; esto hay que tenerlo en cuenta cuando se realiza el sprint planning.
Si se estima que se tendrán interrupciones o que esa persona estará dedicada a otros temas parte de la jornada, entonces hay que reducir el esfuerzo diario que es capaz de dedicar al sprint, siempre de forma relativa, y nunca asociando de forma rígida los puntos a las horas de trabajo.
Un programador junior es capaz de hacer 1 punto de esfuerzo por jornada de trabajo. Si se le presta la suficiente atención a la persona y cada sprint lo usamos también como herramienta de aprendizaje, esa persona necesitará menos esfuerzo para hacer las mismas cosas, y será capaz de llegar a 2 puntos en pocos sprints, puidiendo alcanzar 2 puntos y medio en un año.
Entonces habremos alcanzado una de las metas de la gestión ágil de proyectos, que es poner el foco del esfuerzo en las personas, que es donde yace el conocimiento.
Todos los que hemos participado en proyectos gestionados con Scrum hemos adquirido habilidades que de otra forma no hubiéramos conseguido:
> centrarnos en tareas específicas, tanto en el desarrollo, como en las pruebas posteriores
> reutilizar
> mejorar la comunicación entre nosotros y con los clientes
> estimar mejor los proyectos
> aprovechar el tiempo en las reuniones
> conocer todo el tiempo por dónde vamos, cuánto (y qué) nos falta
> centrarnos no tanto en terminar todo lo acordado en el plazo "firmado" en el contrato, sino en entregar al cliente lo que más valor tiene para su negocio
> y tener actualizado ese manual del producto que no sabíamos dónde meter el tiempo para redactarlo - ahora va dentro del sprint, en cada historia de usuario - de modo que cada incremento de valor va con su manual actualizado
Nos queda lograr implantar otros tipos de contrato de proyecto diferentes a los contratos de proyectos "tradicionales", los ágiles, que encajan mejor en este tipo de desarrollo.
No ha sido un camino de rosas, pero tampoco de espinas.
Os recomiendo tomarlo.
Publicar un comentario