![\"\"](\"https:\/\/lafilosofiadelsoftware.files.wordpress.com\/2021\/08\/190924_blog_feature_time_estimation-1600x900-1-1.jpg?w=300\")
<\/figure><\/li><\/ul>Estimar es para dar un aproximado, jam\u00e1s para dar una exactitud de cuanto tardara una actividad<\/figcaption><\/figure>\n\n\n\n Debemos empezar por entender que en las estimaciones \u00e1giles es que no se hacen con base a tiempo, el tiempo no es la medida para dar los valores (puntuaciones) de la estimaci\u00f3n. Para hacer estimaciones \u00e1giles usamos una t\u00e9cnica de comparaci\u00f3n en la que las actividades del backlog son comparadas unas con otras y as\u00ed ir determinando su peso. <\/p>\n\n\n\n
Para empezar a comparar lo primero que debemos definir es un pivote y \u00bfQue es un pivote? Un pivote es un item del backlog en el que todos los miembros del equipo se ponen de acuerdo y se da un peso, con este pivote definido se procede a comparar a otras actividades y determinar si es menor,mayor o igual que el pivote. Para definir el valor del pivote es criterio 100% del equipo y puede ser el valor que ellos deseen darle (Tip: no elegir una actividad muy grande que no exista algo m\u00e1s grande que ella, ni una actividad muy peque\u00f1a que luego no haya algo m\u00e1s peque\u00f1o, se debe elegir una actividad que sea entre mediana-peque\u00f1a para que el ejercicio funcione bien; veamos un ejemplo un poco tonto:<\/p>\n\n\n\n
Tenemos las siguientes items en el backlog:<\/p>\n\n\n\n
- Hervir agua<\/li>
- Preparar arroz blanco<\/li>
- Lavar el arroz<\/li>
- Preparar arroz con pollo<\/li>
- Preparar arroz con coco<\/li>
- Preparar paella<\/li><\/ul>\n\n\n\n
Ahora lo que debemos hacer es elegir un item del backlog (recuerden: ni muy grande ni muy peque\u00f1o) para este ejemplo voy a elegir Preparar arroz blanco <\/em>y le voy a dar una estimaci\u00f3n de 3 (Las estimaciones se recomienda hacer con la t\u00e9cnica fibonacci, m\u00e1s adelante explico la raz\u00f3n). \u00bfPor qu\u00e9 3? \u00bfPor qu\u00e9 no un 2? la respuesta: Porque SI.<\/p>\n\n\n\n
Cuando tengamos ya cual es la actividad pivote podemos empezar hacer las comparaciones (estimar no es m\u00e1s sino un proceso de comparaci\u00f3n), empecemos:<\/p>\n\n\n\n
\u00bfCu\u00e1nto puede ser la estimaci\u00f3n para hervir agua? Si alguien piensa en un 5 o un 8, entonces no ha entendido el ejercicio. En este caso MI<\/strong> estimaci\u00f3n es un 1 porque es mucho m\u00e1s f\u00e1cil hervir agua qu\u00e9 hacer arroz.<\/p>\n\n\n\n
\u00bfCu\u00e1nto puede ser la estimaci\u00f3n para hacer arroz con pollo?. En este caso MI<\/strong> estimaci\u00f3n es un 8, \u00bfpor qu\u00e9? porque hacer arroz con pollo es m\u00e1s que solo hacer solo arroz.<\/p>\n\n\n\n
Terminemos el ejercicio:<\/p>\n\n\n\n
- Hervir agua : 1 <\/li>
- Preparar arroz blanco: 3<\/li>
- Lavar el arroz: 2<\/li>
- Preparar arroz con pollo: 8<\/li>
- Preparar arroz con coco: 5<\/li>
- Preparar paella: 21<\/li><\/ul>\n\n\n\n
Para hacer la estimaci\u00f3n en equipos, se recomienda usar la t\u00e9cnica de planning poker.<\/p>\n\n\n\n
Planning Poker<\/h2>\n\n\n\n
Esta t\u00e9cnica consiste en que todos los miembros ocultan su votaci\u00f3n hasta el final y todos los miembros revelan al mismo tiempo su votaci\u00f3n.<\/p>\n\n\n\n
Se recomienda usar esta t\u00e9cnica debido a la influencia que se puede dar en las votaciones si una persona dice su votaci\u00f3n antes que los otros miembros. Veamos el siguiente ejemplo:<\/p>\n\n\n\n
Pepito es una programador junior que acaba de llegar al equipo y Sutanita es una programador Senior que lleva 1 a\u00f1o en el proyecto y llega el momento de votar, el PO (product owner) presenta la historia y Pepito est\u00e1 pensando que es un 3 o m\u00e1ximo un 5 por la raz\u00f3n X y Z, antes de que pueda decir su opini\u00f3n Sutanita dice que es 13 y no da razones.<\/p>\n\n\n\n
\u00bfCreen ustedes que Pepito va a decir algo diferente a Sutanita? por supuesto que no, su opini\u00f3n ya fue nublada por la votaci\u00f3n de Sutanita y posiblemente Pepito ten\u00eda raz\u00f3n y callar\u00e1 su opini\u00f3n por miedo a quedar mal.<\/p>\n\n\n\n
Con esta t\u00e9cnica todos sacan su votaci\u00f3n al mismo tiempo y en caso de haber divergencias (y las habr\u00e1) exponen sus argumentos de la votaci\u00f3n m\u00ednima las dos personas que tuvieron las dos votaciones m\u00e1s diferentes. Una vez se exponen los argumentos de parte y parte se procede a votar nuevamente en caso de haber divergencias nuevamente se elige la votaci\u00f3n con m\u00e1s votos. Es mejor parar en la segunda votaci\u00f3n habr\u00e1n casos donde sea imposible llegar a una votaci\u00f3n un\u00e1nime y para no quedarse votando infinitamente se para a la segunda vez de la segunda votaci\u00f3n. <\/p>\n\n\n\n
\u00bfPor qu\u00e9 usar fibonacci?<\/h2>\n\n\n\n
La raz\u00f3n para usar fibonacci es para que las estimaciones entre mas grandes mas se alejan una de otra y evitar discusiones bizantinas, pongamos el caso de la comida nuevamente sin fibonacci Fulanito piensa que para hacer arroz con pollo es un 6 y Sutanita un 7, ambas puede tener un argumento v\u00e1lido para su votaci\u00f3n pero eliminando el 6 y 7 de sus posibilidades tendr\u00e1n que coincidir en un 5 o un 8. \u00a1Evitemos las tibiezas!<\/p>\n\n\n\n
\u00bfDe qu\u00e9 se compone un punto?<\/h2>\n\n\n\n
Ya di mi visi\u00f3n de c\u00f3mo generar las comparaciones de las historias del backlog, ahora explicare que es un punto de historia; Para dar el valor de un punto de historia debe tener en cuenta 3 variables: <\/p>\n\n\n\n
- Complejidad<\/li>
- Esfuerzo<\/li>
- Incertidumbre<\/li><\/ul>\n\n\n\n
Imaginemos un par de historias para poder entender esto:<\/p>\n\n\n\n
- Fulanito debe escribir una plana en 100 hojas, \u00bfcuanto incertidumbre tiene esta tarea? Para m\u00ed un cero, pero debe ser un esfuerzo terrible hacer esa tarea \u00bfno?.<\/li>
- Sutanita debe conectarse con un microservicio X para consumir los datos Y y transformarlos en Z para luego ser enviados a trav\u00e9s de email. Tremendo problema de tarea donde la incertidumbre es alt\u00edsima, no sabemos el esfuerzo, pero s\u00ed que la incertidumbre es muy alta.<\/li><\/ul>\n\n\n\n
Con los ejemplos anteriores un poco irrisorios dan a entender que para dar el valor de un historia se debe tener en cuenta las 3 variables y no una ni dos de ellas, las 3.<\/p>\n\n\n\n
Tips<\/strong>:<\/p>\n\n\n\n
- Escoger una historia pivote que todos o la mayor\u00eda del equipo conozcan c\u00f3mo realizar para facilitar las comparaciones posteriores.<\/li>
- Es posible tener mas de un pivote, ejemplo un pivote para tareas front y uno para tareas backend<\/li>
- Antes de comparar la velocidad de tu equipo debes verificar la historia pivote que se usa para usar las comparaciones, recuerdo una historia cuando un manager me dijo que un equipo hacia 400 puntos por sprint y el mio solo 40, que como era posible, cuando fui a validar la historia pivote para ellos era un 34 y para nosotros era un 3.<\/li>
- Los marcos de trabajos \u00e1giles son para darnos una idea de c\u00f3mo hacer las cosas, no es una biblia o un mandato que se deba cumplir al pie de la letra. Recuerda que cada equipo\/proyecto\/empresa tiene particularidades diferentes, prueba y adaptate a lo que m\u00e1s te beneficie.<\/li>
- No olvides contemplar cuanto te va a costar probar la historia, que el desarrollo no tarde no significa necesariamente que las pruebas lo ser\u00e1n.<\/li>
- Si a\u00fan tienes dudas de la historia a votar, no votes, se valiente y pide una nueva explicaci\u00f3n.<\/li><\/ol>\n\n\n\n
Si tienes alg\u00fan otro te invito a comentar.<\/p>\n","protected":false},"excerpt":{"rendered":"
Se que existen miles de art\u00edculos e incluso videos de esto en internet pero quise compartir mi visi\u00f3n del c\u00f3mo se deben hacer las estimaciones en proyectos tratando de ser lo m\u00e1s dummy posible, as\u00ed que aqu\u00ed vamos: Las estimaciones \u00e1giles nacen para dar una visi\u00f3n del esfuerzo y m\u00e1s o menos tiempo que puede … Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[24],"tags":[4,5,9,10,13,16,17],"class_list":["post-121","post","type-post","status-publish","format-standard","hentry","category-agilismo","tag-agile-coach","tag-agilismo","tag-estimaciones-agiles","tag-fibonnaci","tag-planning-poker","tag-scrum","tag-scrum-master"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/posts\/121"}],"collection":[{"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/comments?post=121"}],"version-history":[{"count":5,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/posts\/121\/revisions"}],"predecessor-version":[{"id":179,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/posts\/121\/revisions\/179"}],"wp:attachment":[{"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/media?parent=121"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/categories?post=121"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lafilosofiadelsoftware.com\/index.php\/wp-json\/wp\/v2\/tags?post=121"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}