Estimación colaborativa

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 :/

Mauricio Parada G

MoSCoW Analysis suena muy bélico Willy Bromas aparte, gracias por compartir. Yo use el Poker, pero después depende del equipo, siento que esas estimaciones así toman mucho tiempo. Aveces funciona preguntar directamente cuánto tiempo tomará

Andrea Queccara

hola me parece buena información en donde podría encontrar estas metodologías? que literatura recomiendas?. muchas gracias por sumar.

Carlos Andres Osorio Diaz

Información valiosa que esperaba encontrar en este capitulo:

Poker explanation:

RICE:

MoSCoW:

Kano Model:

TAM Model:

GEMILLE ADASSI VAZQUEZ ESTRADA

Técnicas de estimación:

Técnicas de estimación

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.
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.
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.
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.
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.
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.
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.
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.
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.

Arles A. Pinzon Molina

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.

Alexander Orellana Manayalle

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.

Lucciano Docarmo Delgado Docarmo Delgado

Esta clase me pareció bastante floja... hay mas técnicas de estimación colaborativa y usar ejemplos seria más conveniente.

Cristian Amézquita

Concuerdo contigo, las estimaciones no se debe de dejar a la ligera y no se realizan con base al conocimiento o experiencia de una sola persona.

Alexander Orellana Manayalle

Para verlo mejor utilizar x1.5

Gabriel Leonardo Vásquez Prieto

Hace 2 años

El Análisis MoSCoW es una técnica de priorización utilizada en gestión de proyectos y desarrollo de productos. Se clasifica en cuatro categorías:

Must Have (Debe tener) – Requisitos críticos e imprescindibles. Sin ellos, el proyecto falla.
Should Have (Debería tener) – Importantes pero no esenciales en la primera entrega.
Could Have (Podría tener) – Deseables, pero sin impacto si se excluyen.
Won’t Have (No tendrá por ahora) – Se descartan para esta versión, pero pueden considerarse en el futuro.

Permite al Product Owner y al equipo enfocar esfuerzos en lo realmente necesario y entregar valor de forma eficiente

Emmanuel Herrera Rios

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/

Jorge Silva Diaz

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 "ESFUERZO" 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.

Flavia Di Giorgio

Hace 2 años

NOTA:

ESTIMACION COLABORATIVA

NO COLABORATIVA (VISIOB PLANA)

CONSIDERAR LOS ESCENARIOS MAS PROBABLES RELACIONADOS A LA COMPLEJIDAD

HABLAR DE FACILIDAD

CONSIDERAR SESGOS

-ESCUCHAR Y ENTENDER A TU EQUIPO TECNICO!

-QUE TANTO DE LO QUE TENEMOS EN EL BACKLOG ES POSIBLE?

*entender el qué? Responsabilidad del PRODUCT OWNER

Y HABLAR DEL CÓMO.

Omar Aguayo

think out of the box?

Felipe Bernardo González Barranco

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

Roberto Medina

El sesgo de multiproyecto se refiere a las tareas del PO ? por que entiendo que un equipo de desarrollo scrum solo debe trabajar en un proyecto a la vez, verdad?

Vanessa Amaya

Profesor

Hola Roberto! El ideal es un proyecto a la vez, lamentablemente aún el mundo laboral no ha llegado a ese equilibrio en la mayoría de los casos.

Roberto Medina

Como se puede estimar todo un proyecto a alto nivel para poder hacer una cotizacion del desarrollo de un producto o proyecto?

Vanessa Amaya

Profesor

Hola Roberto! Te comparto estos videos donde lo explico de manera más amplia: https://www.youtube.com/watch?v=3upik9YCYQ0&t=27s

Y también te dejo este video de Javier Garzás: https://www.youtube.com/watch?v=GBC4gh7iUaM&t=572s

Nicolas Ramirez Arias

Yo tenia entendido que las estimaciones no las hacía el product owner, no se si mas bien ¿el rol del product owner en la estimación es para aclarar algún tema?

Brian David Pajares Correa

Exacto, el product owner tiene que ver con el producto.

Sandra Sierra

Correcto, la estimación se realiza con todo el equipo.

Patricio Sánchez Fernández

Hace 2 años

Coincido con la profesora que considerar sólo el mejor escenario, es un error.

¿Cuál es el escenario más probable? Se me ocurre que la respuesta está en la campana de Gauss, donde la mayor parte de las soluciones y los eventos, tiende a estar al centro de la curva, los casos excepcionales en los extremos. El peor y el mejor escenario estarían al inicio y al fin de la curva respectivamente.

¿Cómo podría ser más eficiente el trabajo del equipo de desarrollo?

Se me ocurre que un repositorio de soluciones de código, vendría bien. Podrías utilizarlas igual como lo hacen los técnicos mecánicos en los talleres automotrices.

Supongamos que un técnico necesita desmontar un neumático de un camión, ya por las dimensiones del equipo, sabe que necesita un dado de 45, también necesita una gata hidráulica de alto tonelaje y que el camión no tenga carga, sabiendo el tipo de trabajo, se puede estimar las herramientas y el tiempo de ejecución.

Me he dado cuenta que los programadores trabajan con muchas plantillas, por eso digo que tener un repositorio sería excelente. Así como un técnico sabe qué llave necesita y dónde buscarla, el programador también sería más eficiente reutilizando código y adaptándolo a la necesidad.

Yeison Henry Bayona Casas

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.

Sandra Sierra

Hola, mi ejercicio:

francisco escalante