Estimación colaborativa
Clase 5 de 12 • Curso de Herramientas y Frameworks Intermedias para Product Owners
Contenido del curso
Clase 5 de 12 • Curso de Herramientas y Frameworks Intermedias para Product Owners
Contenido del curso
Willy Jauregui Vera
Mauricio Parada G
Andrea Queccara
Carlos Andres Osorio Diaz
GEMILLE ADASSI VAZQUEZ ESTRADA
Arles A. Pinzon Molina
Alexander Orellana Manayalle
Lucciano Docarmo Delgado Docarmo Delgado
Cristian Amézquita
Alexander Orellana Manayalle
Gabriel Leonardo Vásquez Prieto
Emmanuel Herrera Rios
Jorge Silva Diaz
Flavia Di Giorgio
Omar Aguayo
Felipe Bernardo González Barranco
Roberto Medina
Vanessa Amaya
Roberto Medina
Vanessa Amaya
Nicolas Ramirez Arias
Brian David Pajares Correa
Sandra Sierra
Patricio Sánchez Fernández
Yeison Henry Bayona Casas
Sandra Sierra
francisco escalante
Esta clase me pareció un poco pobre. Hay bastantes metodologías para estimar las historias de usuario y no hizo mención de ninguna:
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á
hola me parece buena información en donde podría encontrar estas metodologías? que literatura recomiendas?. muchas gracias por sumar.
Información valiosa que esperaba encontrar en este capitulo:
Poker explanation:
RICE:
MoSCoW:
Kano Model:
TAM Model:
Técnicas de estimación:
Técnicas de estimación
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.
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.
Esta clase me pareció bastante floja... hay mas técnicas de estimación colaborativa y usar ejemplos seria más conveniente.
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.
Para verlo mejor utilizar x1.5
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:
Permite al Product Owner y al equipo enfocar esfuerzos en lo realmente necesario y entregar valor de forma eficiente
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/
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.
<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>
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 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?
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.
Como se puede estimar todo un proyecto a alto nivel para poder hacer una cotizacion del desarrollo de un producto o proyecto?
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
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?
Exacto, el product owner tiene que ver con el producto.
Correcto, la estimación se realiza con todo el equipo.
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