No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Estimaci贸n colaborativa

5/12
Recursos

Aportes 14

Preguntas 3

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

Esta clase me pareci贸 un poco pobre.
Hay bastantes metodolog铆as para estimar las historias de usuario y no hizo menci贸n de ninguna:

  • Poker Estimation
  • RICE estimation
  • MoSCoW Analysis
  • Kano Model
  • Opportunity model
  • Cost of Delay
    Entre otras 馃槙

Me gust贸 esa definici贸n. Estimaci贸n colaborativa es la forma en la que yo puedo mostrar mi visi贸n a los miembros del equipo y conocer, igualmente, lo que otros est谩n viendo.

Esta clase me pareci贸 bastante floja鈥 hay mas t茅cnicas de estimaci贸n colaborativa y usar ejemplos seria m谩s conveniente.

T茅cnicas de estimaci贸n: ## T茅cnicas de estimaci贸n 1. **Poker Estimation**: * Tambi茅n conocida como "Estimaci贸n de Poker" o "Estimaci贸n de Planning Poker", es una t茅cnica ampliamente utilizada en metodolog铆as 谩giles, como Scrum. El equipo de desarrollo se re煤ne y asigna un valor de esfuerzo relativo a cada historia de usuario, utilizando cartas con valores (por ejemplo, 1, 2, 3, 5, 8) de forma que representen la complejidad y el tiempo estimado para completar la historia. Esta t茅cnica fomenta la colaboraci贸n y la discusi贸n entre los miembros del equipo. 2. **RICE Estimation**: * El m茅todo RICE es una t茅cnica de priorizaci贸n y estimaci贸n utilizada para evaluar diferentes iniciativas o caracter铆sticas en funci贸n de cuatro factores: Alcance (Reach), Impacto (Impact), Confianza (Confidence), y Esfuerzo (Effort). Los equipos asignan valores a cada uno de estos factores y calculan un puntaje RICE para determinar la prioridad. 3. **MoSCoW Analysis**: * Esta t茅cnica se utiliza para clasificar elementos (como historias de usuario) en cuatro categor铆as: Must-haves (Debe tener), Should-haves (Deber铆a tener), Could-haves (Podr铆a tener) y Won't-haves (No debe tener). MoSCoW ayuda a establecer prioridades y determinar qu茅 funcionalidades son esenciales y cu谩les son opcionales. 4. **Kano Model**: * El Modelo Kano se utiliza para entender las expectativas del cliente en relaci贸n con las caracter铆sticas de un producto. Clasifica las caracter铆sticas en cinco categor铆as: B谩sicas (Basic Needs), Rendimiento (Performance Needs), Atractivas (Excitement Needs), Indiferentes (Indifferent Needs) y Inverse (Reverse Needs). Esto ayuda a determinar el valor y la satisfacci贸n del cliente con cada caracter铆stica. 5. **Opportunity Model**: * El modelo de oportunidad se enfoca en evaluar oportunidades de negocio. Ayuda a priorizar las oportunidades basadas en factores como el tama帽o del mercado, el potencial de ingresos, el costo de implementaci贸n y el tiempo necesario. Es 煤til para la toma de decisiones estrat茅gicas. 6. **Puntos de Historia (Story Points)**: Esta t茅cnica asigna valores num茅ricos abstractos a las historias de usuario para representar la complejidad y el esfuerzo requerido. Se utiliza com煤nmente en metodolog铆as 谩giles. 7. **Estimaci贸n An谩loga (Analogous Estimation)**: Consiste en basar las estimaciones en la experiencia previa con proyectos similares. Se utiliza cuando se dispone de datos hist贸ricos para hacer estimaciones. 8. **Estimaci贸n de Tres Puntos (Three-Point Estimation)**: En esta t茅cnica, se utilizan tres valores para estimar cada tarea: el mejor caso, el peor caso y el caso m谩s probable. Luego, se calcula una estimaci贸n basada en estos valores. 9. **Estimaci贸n de Expertos**: Se basa en la opini贸n de expertos en el dominio o en la tecnolog铆a. Puede ser 煤til cuando no se dispone de datos hist贸ricos o cuando se trata de proyectos altamente especializados.

Para verlo mejor utilizar x1.5

El Poker en Scrum:

Para estimar existen muchisimas tecnicas que podemos usar, sin embargo, en los equipos que participo, suelo sugerir emplear el Planning Poker, pero, en que consiste?

Consiste en una sesion de trabajo, en el marco del Sprint Planning, en donde el equipo de desarrollo realiza una estimacion de 鈥淓SFUERZO鈥 ojo NO DE HORAS, a traves de la representacion de la secuencia Fibonacci.

Esta estimacion se realiza mediante el empleo de un mazo de cartas con que se juega poker, (en fomato digital hay un monton de herramientas, al finalizar dejo el liink) las cuales se le suma una carta que indique cafe y otra carta que indique interrogacion.

Ahora bien, en la primera vuelta, se toma la Historia de Usuario se lee, y en una primera votacion, los involucrados, ponderan la HU con un numero de la carta, los numeros que se suelen usar son 1,2,3,5,8,13,20,40,100.

Siendo 1 el muy facil y 100 realmente dificil, en esta primera vuelta, se consulta al numero mas bajo y al numero mas alto el porque de su votacion, luego se realiza una segunda votacion y de ahi sale el numero estimado de esfuerzo de la Historia de Usuario.

Para el Primer Sprint se emplea o se rcomienda arrancar con 30 puntos de esfuerzo, esto va a depender del tama帽o de la celula y la madurez del equipo, sin embargo, se puede tomar numero como base, para posteriores sprints poder calibrar y aumentar o disminuir la velocidad del team.

La t茅cnica del juicio de expertos : Es la mas utilizada pero lamentablemente este experto no ejecuta todo lo del proyecto y su estimaci贸n queda por muy debajo de la realidad.

Utilizando un metodo tradicional es como ver un cubo y ver una sola cara.


Lo mas importante aca es hacerle ver a los demas que yo estoy viendo


Considerar los escenarios mas probables relacionados a complejidad

Porque cuando estamos haciendo estimaci贸n y planeaci贸n , normalmente se hace una planeaci贸n muy subjetiva y optimista. Todo puede ser factible dentro de una linea tiempo y los equipos pueden aprovechar su experiencia.

Hablar de Factibilidad

A nivel de negocio muchos temas puedes ser posible y tu como PO tu responsabilidad principal para poder cumplir el valor de negocio es escuchar y entender a tu equipo tecnico , se recomienda provocar conversaciones relacionadas a factibilidad 驴Que tanto de lo que tenemos en nuestro Backlog es posible ? y 驴como lo podemos hacer una realidad ?

Sesgos de estimaci贸n

Un sesgo muy com煤n es hacer estimaciones muy optimistas

Otro sesgo cuando consideramos el desarrollo y no consideramos la pruebas por lo que pasa que existen desarrollos muy sencillos pero para realizar las pruebas es muy complejo y viceversa.

Otro sesgo del multiproyecto , consideramos y estimamos como si estuvieramos haciendo un proyecto a la vez . Estimamos sin que tuvieramos otras cosas que realizar.


Cuando se tiene tanto el COMO como el QUE quiere decir que tu equipo esta entiendo el desarrollo del proyecto.

Un reto en las estimaciones, adem谩s de no tener presentes a las personas que construir谩n las cosas, es tambi茅n tener equipos demasiado numerosos, la comunicaci贸n se complica. Este es un recurso muy interesante se帽alando el tema del tama帽o de los equipos: https://internet80.com/blog/el-tamano-del-equipo-scrum/

think out of the box?

Muy importante que un product owner sepa que las estimaciones en las estimaciones se debe tener en cuenta la factibilidad, los sesgos y las cosas que podr铆an salir mal, adem谩s de que no se trabaja un proyecto a la vez

Slack es un canal de comunicaci贸n que trae diferentes herramientas y permite crear grupos en donde se pueden utilizar t茅cnicas de estimaci贸n de Fibonacci, y a trav茅s de la metodolog铆a Scrum se efect煤a la sesi贸n de refinamiento en donde se revisan las HU y est谩 el equipo, se revisan subtareas de la HU y posteriormente se hace la puntuaci贸n del esfuerzo.

Hola, mi ejercicio:

excelente contenido