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 😕
Prácticas básicas
Historias de usuario
Esquematización de elementos de trabajo
Descomposición
Prototipado como medio de especificación
Prácticas de estimación y priorización
Estimación colaborativa
Talleres de requisitos
Priorización de elementos de trabajo
Prácticas centradas en el usuario
Principios de orientación al usuario
Técnica de Buyer Persona
Técnica de Value Proposition Canvas
Técnica User Journey
Cierre
¿Por dónde empiezo?
You don't have access to this class
Keep learning! Join and start boosting your career
If you already have an account,
Contributions 17
Questions 3
Sort by:
Información valiosa que esperaba encontrar en este capitulo:
Poker explanation:
https://www.youtube.com/watch?v=TxSzo3lwwWQ&t=59s
RICE:
https://www.youtube.com/watch?v=miI6KvwFHLI
MoSCoW:
https://www.youtube.com/watch?v=NJ2JM_PKXjk
Kano Model:
https://www.youtube.com/watch?v=Z3Zw6LPggQQ
TAM Model:
https://www.youtube.com/watch?v=M_RMTC2YmXY
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.
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.
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.
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 “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.
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
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:
1. **Must Have** (*Debe tener*) – Requisitos críticos e imprescindibles. Sin ellos, el proyecto falla.
2. **Should Have** (*Debería tener*) – Importantes pero no esenciales en la primera entrega.
3. **Could Have** (*Podría tener*) – Deseables, pero sin impacto si se excluyen.
4. **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
<u>NOTA:</u>
<u>ESTIMACION COLABORATIVA</u>
<u>NO COLABORATIVA (VISIOB PLANA)</u>
<u>CONSIDERAR LOS ESCENARIOS MAS PROBABLES RELACIONADOS A LA COMPLEJIDAD</u>
<u>HABLAR DE FACILIDAD</u>
<u>CONSIDERAR SESGOS</u>
<u>-ESCUCHAR Y ENTENDER A TU EQUIPO TECNICO!</u>
<u>-QUE TANTO DE LO QUE TENEMOS EN EL BACKLOG ES POSIBLE?</u>
<u>\*entender el qué? Responsabilidad del PRODUCT OWNER</u>
<u>Y HABLAR DEL CÓMO.</u>
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.
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
Want to see more contributions, questions and answers from the community?