Tamaños de las tareas a la hora de planificar

[Mónica Izquierdo Briones]

Buenos días,

 

A raiz de un proceso de mejora que está surgiendo dentro de la empresa donde trabajo, me surge una duda que no he sabido justificar adecuadamente, a ver si me podéis ayudar.

 

La cuestión es muy sencilla, ¿Existe alguna buena práctica que diga cuál es el tamaño máximo que debería tener una tarea en las metodologías tradicionales? Cuando se siguen médolologías ágiles está más claro.

 

Muchas gracias de antemano

 

Un saludo

Mónica

[JJG]

Mónica, por curiosidad, ¿cómo medís las tareas? Un saludo.

El jueves, 18 de abril de 2013 13:05:30 UTC+2, Mónica Izquierdo Briones escribió:

...

[Mónica Izquierdo Briones]

Hola,

 

Creo que me he explicado poco en el corerreo anterior.  Se está intentando estandarizar el tamaño de las tareas en las que se planfica un proyecto.  La unidad de medida son horas.

 

Yo creo que el nivel de granularidad que deben de tener las tareas depende mucho del grado de seguimiento que se quiera hacer sobre ellas.  Quiero decir, que si utilizas metodologías ágiles donde el seguimiento de las tareas es diario y la duración de un sprint es menos de un mes, está claro que la granularidad de las tareas debería ser pequeño (1 tarea= máximo 8 horas, es decir el trabajo que puedes hacer en un día, por ejemplo).

 

Si sobre esa planificación vas a hacer un seguimiento semanal o quincenal (porque tu proyecto dura un año, porque se hace un seguimiento a otra nivel más exhausitvo por ejemplo) a lo mejor ese nivel de detalle es excesivo o no aporta mucho en ese tipo de seguimientos.

 

Pero mi pregunta es, ¿hay alguna pauta de tamaño para las tareas? ¿Depende del tipo de seguimiento que quieras hacer sobre ellas? ¿Hay alguna best practice?

 

Creo que si tienes una tarea por ejemplo 150 horas sobre la que va a trabajar sólo una persona, la posibilidad de que la estimación no sea adecuada es mayor que si tienes una de 30 horas sobre la que van a trabajar 2 personas.  Pero, ¿hay alguna referencia o alguna buena práctica que aconseje algo respecto a estos tamaños?

 

Espero haberme explicado bien.

 

Muchas gracias!

 

 

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/mqewlYMjstQJ.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Alfredo Casado]

Una tarea de 150 horas!, con ese nivel de detalle podrías decir que la tarea estará lista el día 8 de agosto a las 14:00 horas (hora peninsular claro).

Quiero decir, lo absurdo en si es tener tareas tan grandes y por si fuera poco medirlas con precisión de horas. Esto te puede dar ilusión de control al principio y unos cuantos disgustos al final.

La granularidad de las tareas no depende de la metodología que uses, supongo que la intención es tener exito en tus proyectos, y la mejor forma de tener exito es teniendo tareas lo más pequeñas posibles. Los beneficios de las tareas cortas no tienen que ver sólo con el seguimiento, dividir en tareas cortas tiene otros beneficios igual o más importantes:

 - A más pequeña la tarea más corto el ciclo de feedback, a más corto el ciclo de feedback menor tiempo empleado en solucionar problemas.

 - Tener tareas más cortas ayuda a priorizar lo realmente importante, las tareas grandes suelen contener muchas cosas que en realidad no son "imprescindibles".

 - Las tareas cortas ayudan a que el equipo entienda mejor el problema a resolver, el equipo participa claro esta en esta división de tareas.

[Mónica Izquierdo Briones]

Totalmente de acuerdo. 

 

Pero entiendo entonces que si quieres tener ese nivel de granularidad, la planificación deberian ser incremental. 

 

Quiero decir, que si tienes un proyecto que dura un año, no puedes tener al principio del proyecto ese nivel de detalle de tareas.  Tendría que ir detallando las tareas a medida que fuera avanzando el proyecto, tal y como proponen las metodología ágiles en su planficacion a varios  niveles (releases, sprints, tareas), no?

 

¿qué tamaño de tarea consideras cortas?

 

Gracias

[Alfredo Casado]

Claro las tareas las vas definiendo según se acerca la hora de hacerlas, mientras estarán pendientes como historias o incluso sólo como epicas. Incluso si necesitas tener una estimación a largo plazo porque se trata de un proyecto con coste/plazo cerrado lo puedes hacer estimando esas historias o epicas "a groso modo", en el fondo la probabilidad de que aciertes es la misma (casi ninguna) y te ahorras el trabajo de definición exahustiva inicial, así que como empiezas antes maximizas tus oportunidades de llegar a tiempo.

Sobre que esto corto y que es largo, eso prefiero que sea el equipo el que lo decida en función del proyecto su experiencia etc,etc, simpre recomendandoles que intenten hacerlas los más cortas posibles e incluso ayudandoles a hacer esta separación si no tienen experiencia (a veces a la gente le cuesta mucho ver esas tareas más pequeñas si no tienen experiencia). Pero no me gusta la idea de las imposiciones o las recomendaciones a titulo general, prefiero decir "lo más cortas posibles" que dar un número que limite la libertad de decisión del equipo.

[Harringer]

Si hago un WBS la granularidad es de maximo 5 jornadas de esfuerzo por tarea y minimo 1 jornada. Si subiria el maximo acumulas demasiado riesgo de haberte equivocado. Si bajas el minimo sube demasiado el overhead en gestion.

Otra metrica es que cada miembro del equipo en funcion de su experiencia y capacidad pueda hacer tareas de 5 jornadas. Menos experiencia = tareas menos grandes.

Un saludo,

Harald

[Mónica Izquierdo Briones]

Muchas gracias por la orientación.  Creo que el error de planteamiento que están teniendo no es tanto por el hecho de intentar establecer un tamaño máximo a las tareas sino al hecho de tener que tener esa granularidad en todas las actividades del proyecto desde el principio.

El tamaño que se está proponiendo se ajusta mucho a lo que me comentas.

Saludos,

--

[Alfredo Casado]

Por lo que dices monica da la impresión de que quienes proponen algo así tienen un problema que poco tiene que ver con las practicas concretas y los detalles y tiene mucho más que ver con los principios.

Si se propone hacer un división inicial en tareas con granularidad de un día o similar basicamente lo que se esta proponiendo es hacer una "ingeniería de requisitos" clásica, lo puedes llamar "tarea" o "historia" en lugar de "requisito" pero esa división inicial va a necesitar de un fase de análisis de requisitos muy larga (para proyectos grande) y lo peor, va a restringir la capacidad de adaptarse a las verdades necesidades, que suelen ser muy distintas de las que inicialmente se plantean. Quien proponga algo así no tiene en mente los principios ágiles o puede que sencillamente no los comparta. Pero con ese planteamiento IMHO vais de cabeza a la cascada.

Creo que antes de seguir debatiendo sobre detalles y practicas concretas necesitáis sentaros y poner en claro vuestros principios, si queréis un modelo predictivo o adaptable, si confias en las personas o en los procesos, etc,etc. A veces me a la sensación de que nos perdemos en detalles y se nos olvida lo más importante, ya sabes, aquello de que los árboles no dejan ver el bosque.

[José Manuel Beas]

Gracias, Alfredo, imposible mejorar el diagnóstico. Por favor, Mónica, reconsiderad el tamaño de proyectos con los que aprender a aplicar Scrum.

Un saludo,
José Manuel Beas

[Daniel Ceillan]

Están muy buenas las respuestas. 

Hay que aceptar que el futuro no se puede predecir, quizás si adivinar (siendo esto un juego peligroso). Y que todavía no podemos viajar en el tiempo. 

Pero aún así seguimos necesitando responder las preguntas sobre costos y para cuando... 

Tanto en metodologías ágiles o no ágiles las estimaciones se hacen en medidas abstractas (puntos, story points, kilos, conejos, nueces, y puedes inventarte la que te guste) en lugar concretas (horas). 

Los días viene bien usarlos, porque sigues asumiendo que no es posible la precisión. Cosa importante. Ademas las personas trabajan por jornadas, asi que se hace muy fácil encontrar una analogía. Pero es importante entender de que la estimación no es un compromiso. 

La conversión de la medida abstracta a concreta sólo sirve para estimar costes, pero no para predecir cuánto va a ocupar operativamente. Porque además luego cambie la relación entre unidad abstracta y tiempo, y si no lo tienes medido abstractamente te será difícil cambiar y reajustar la trazabilidad. 

El cambio de paradigma vendría bien, pero llevaría meses. Y en meses si no logras algún resultado positivo posiblemente nada tenga sentido y será tarde. Para comenzar alcanza con aceptar que el delorean sólo funcionó en una peli de ficción. 

Hacer un detalle exahustivo al principio del proyecto me parece un total desperdicio. Alcanza con definir los objetivos funcionales a grandes rasgos, y sentarse a identificar riesgos técnicos. Cuanto más riesgo técnico, engordar más las estimaciones. 

Cuanto más preciso y perfecto el plan... Menos probable que tenga éxito. 

Ahora caigo en cuenta de que quizás tengas un management muy cinéfilo. 

Si creen en los planes perfectos, deben mirar brigada A.

Si creen en las predicciones, quizás son fans de volver al futuro. 

Y asi sigue la lista... James bond, rambo... 

Es importante reconocer que esto es la vida real. Y separar la estimación de los compromisos. 

La estimación intenta resolver la incógnita de un modo realista. Pero si tu le metes los compromisos, la degeneras. Deja de ser consecuente con la realidad. Y se vuelve intrazable. 

Una vez que tengas estimaciones honestas, luego analizas que compromisos puedes asumir. 

Corto para que no se haga demasiado largo, puedes leerte el libro "agile estimating and planning" de mike cohn. 

Saludillos!

Daniel 

http://www.agile-patterns.com

Enviado desde mi iPad

El 19/04/2013, a las 00:35, Alfredo Casado <casado....@gmail.com> escribió:

Por lo que dices monica da la impresión de que quienes proponen algo así tienen un problema nque poco tiene que ver con las practicas concretas y los detalles y tiene mucho más que ver con los principios.

[Adrian Listo Quilez]

Muy buenas todas las respuestas, muy interesante lo que se está comentando..

De hecho yo tengo deberes este fin de semana para replanificar con un mayor nivel de detalle un proyecto que arrancamos la semana que viene.. me acordaré de todos vosotros.

;-)

Saludos,

-Adrián

Aviso: La información contenida en este mensaje es confidencial, quedando totalmente prohibida por la ley su reproducción, publicación y divulgación total o parcial.

Mediante la remisión y/o contestación del presente correo electrónico usted consiente expresamente para que sus datos, recogidos en el mismo, sean tratados y pasen a formar parte de un fichero cuyo responsable de tratamiento es ENZYME ADVISING GROUP, S.L. siendo su finalidad cumplir correctamente con lo dispuesto en la relación contractual con ENZYME ADVISING GROUP. 

Asimismo, mediante la remisión y/o contestación del presente correo electrónico está dando su consentimiento para que, en caso de ser necesaria la cesión de sus datos a un tercero para el cumplimiento de fines directamente relacionados con nuestras funciones legítimas, estemos actuando conforme a Derecho. 

En atención a lo establecido en la Ley Orgánica de Protección de Datos de Carácter Personal 15/1999, de 13 de diciembre, el tratamiento de los datos de carácter personal se hará exclusivamente para las finalidades con las que han sido recabados. Asimismo, le informamos de que goza de un derecho de acceso, oposición, rectificación y cancelación de los mismos, que podrá hacer efectivo en cualquier momento mediante la remisión de una comunicación escrita a "ENZYME ADVISING GROUP, S.L., Rambla Catalunya, número 111, 3º-1ª, 08008 Barcelona" o contactando con nosotros en el correo electrónico lopd@enzymeadvisinggroup.com.

Si ha recibido este mensaje por error, le rogamos que, elimine el mismo y lo comunique a su remitente. Gracias por su colaboración.