Planificación en Gitlab-Pesos

En la empresa donde me encuentro actualmente, utilizamos mucho esta herramienta para la estimación de Scrum, sobretodo por que en muchos casos hay desarrolladores que no se encuentran fisicamente en la sala donde realizamos las reuniones, espero les sirva:
https://scrumpoker.online

No Confundir esfuerzo con tiempo.

El peso se refiere al esfuerzo requerido y de este modo podría también sugerir el tiempo que pueda requerirse, pero, el esfuerzo requerido también depende de quien tenga a cargo el issue; un desarrollador junior podría requerir más tiempo que un desarrollador con más experiencia. Como se podría manejar este tipo de escenario?

Hay que aprender a planificar el esfuerzo.

Planning-poker

Super importante esta lectura, me quedó sonando lo de las tallas de las camisetas como sistema de estimación. Comparto esta otra lectura que también me gustó https://eamodeorubio.wordpress.com/2011/05/16/estimacion-3-tecnicas-agiles/

Al estimar usando poker planning, y asignar puntos historia, esto también puede usarse para medir el progreso real del equipo en términos de trabajo realizado.

En mi caso en varios equipos en los que he participado se realiza la definición de un Pivote, una Historia de Usuario o Issue que todos conozcan muy bien y hayan solucionado. Se le asignan un peso y esta se utiliza como referencia para estimar el esfuerzo de los futuros Issues.

Yo les cuento que en unos procesos en los que aprendí algo de Scrum, nos mostraron apps como: “Scrum Poker” y “Scrum Time”.
Muy interesantes por la posibilidad de definir las escalas o rangos a usar.

En mi experiencia, es una practica que va tomando sentido conforme se va desarrollando experiencia en varios proyectos.
De entre los cuales es posible obtener un factor comparador de scopes de acuerdo a la problemática general a resolver, como saber que la integración con algún servicio en particular suele ser una tarea compleja vs alguna otra como agregar una validación en un input.
En otras palabras, es posible acercarse a la realidad conforme se vaya recolectando patrones neuronales de resolución de issues. Lo cual haría que progresivamente seas mas eficiente en relacion a issues relacionados.

Pero no hay que confundir el esfuerzo con el tiempo

Lo del poker ayuda mucho cuando se integra personas con distintos niveles de conocimiento, en algunos casos ayuda a redefinir los equipos de trabajo.

Con respecto a las estimaciones, hay varios puntos que puente generar grandes desviaciones para los puntos estimativos.

1. La experiencia de los devs es importante. Un junior tardaría más en resolver un problema que un semi-senior y a su vez que un senior.
2. La cantidad de desarrolladores que intervienen en el proceso podría complicar la repartición de las tareas y la interacción entre estos mismos.
3. El tamaño de desarrollo y construcción de la tarea asignada. A veces se crea un Sprint que resulta muy cargado de procesos que engloban una tarea y conviene antes de crear un issue fraccionar en partes y luego reunir los procesos para dicho sprint.
4. Los problemas que pueden surgir durante el desarrollo y la construcción del software, que pueden crear bloqueos importantes en el progreso de los procesos y peor aún, si estos procesos son contiguos y correlativos los unos de los otros.

Mi crítica:
Supongo que deben haber más puntos. Una cosa que critico enérgicamente de Agile y Scrum, es que no poseen cálculos o determinaciones para obtener el “camino crítico” durante un sprint. Tan solo los proyectos basados en Peart lo poseen mientras que Gann y otros no. El camino crítico es ideal para corregir potenciales desviaciones en los progresos de los procesos de desarrollo. Es algo que veo que los ingenieros no resuelven o no pueden resolverlo con estos métodos.

Una de las cuestiones importantes a la hora de estimar y que por lo menos he visto poco en los equipos en los que estuve es que el SCRUM master no hace que el PO este presente en la planning. Para mi es importante ya que puede aclarar muchas dudas al momento de estimar o dudas de alguna feacture en particular.

Es muy útil la estimación. En donde trabajo lo usamos hace unos años y ayuda muchísimo a ser más objetivos y a no pensar por sobre el compañero de trabajo subestimando o sobrestimando su capacidad de trabajo.

Las estimaciones, siempre son útiles a la hora de entregar resultados, son las que te indican la velocidad de tu equipo

Ahora si se viene lo chido!

Es preciso tener buena base de comunicacion en el equipo para trasladar un sistema de estimaciones

Jajaj la idea del poker esta genial!

Venga que Agile anda en todo 😕 , pero que mas darle que si no duele no sirve

Gracias, no sabia que era el “Estimation poker”

No me queda claro el uso del peso, basados en este ¿vamos a definir el orden de ejecución de las tareas?, o ¿cual es su objeto?

¿Por qué no se usa la estimación en horas de trabajo? o ¿este peso puede ser lo que uno quiera que sea en cada proyecto?

Siento que este tema merece un vídeo y algunos ejemplos reales de uso.

Gracias

Vi algo como esto en donde trabajo, ponían a los desarrolladores involucrados en una sala, las reglas eran evaluar del 1 al 10 la dificultad y considerar el estimado de tiempo que llevaría completar algún modulo especifico o la integración de algún servicio tercero, posterior a esto nos preguntaban porque elegimos el valor para ver nuestros puntos de vistas, en lo particular me dio gusto ya que hubo muy pocas discrepancias en el valor que elegías vs el de tu colega, y en los casos donde había discrepancia muy notoria, nos deteníamos, mostrábamos nuestra postura y volvíamos a retomar esta pregunta para encontrar un equilibrio en el peso de la estimación del punto a desarrollar, me gusto ya que ves la perspectiva de la otra persona, te hace tener un panorama amplio y una proyección de lo que estarás desarrollando

Tener un Histórico de esas estimaciones puede ser fuente para un control para siguientes issues

aprendiendo!

Este paso es de suma importancia. El equipo debe tener claro cuántas horas / ingeniero equivale 1 peso o “punto de historia”.

lo de la estimación poker es muy utilizado en las metodologias agiles (scrum) y muy recomendable gracias por el aporte.

Gracias por el aporte. Son muy buenos tus consejos

La estimación de poker, es una buena forma en la que el equipo pueda realizar la estimación de los pesos de los issues.