La semana pasada estuvo bastante movida en presentaciones, charlas, etc. De algunas de ellas te he ido dejando algún extracto, como mis diapositivas sobre Deuda Técnica, y en este caso quiero compartir contigo las que he estado usando sobre #NoEstimates
Ya sabes que sobre el tema de #NoEstimates hemos hablado por aquí en más de una ocasión, en los post ¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado, en el de Comparando el enfoque tradicional, con el ágil con estimaciones y con el #noEstimates y en ¿Necesitamos estimaciones de proyectos software… o presupuestos?
Además, por si fuera poco, si estás interesado en el tema, el próximo día 9, en Madrid, el grupo de Management 3.0 – Peopleware – Liderazgo Técnico, de la mano de Pablo Perez, va a dedicarle una reunión al tema. Estás invitado.
Y aquí están las diapositivas de las que te hablaba…
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Entonces, es viable aplicar #NoEstimates con Scrum?
Hola Javier! Cómo estas? Un gusto participar de tu blog.
Hoy te hago una pregunta para conocer tu opinión.
Actualmente trabajo en una empresa de sistemas en el área de desarrollo de producto CORE.
Por ende nosotros no corremos contra los tiempos impuestos por un cliente externo, sino que sentimos la presión interna.
Principalmente nuestro trabajo consiste en lanzar nuevos releases del producto y bugfixes.
El problema principal es la intolerancia del directorio a la incertidumbre en la precisión de la fecha de entrega del nuevo release y de su alcance, ya que las acciones de comercialización se apoyan fuertemente en las nuevas funcionalidades del producto.
En este tipo de panorama en donde la previsión se vuelve muy importante para la empresa, la complejidad de implementar NoEstimates creo que viene dada por la experiencia en rodaje de metodologías agiles del equipo involucrado y de métricas anteriores.
Vos que opinas? Cómo implementarías NoEstimates en el panorama anteriormente citado, en donde no hay predisposición para cambiar fechas (o es muy acotado) y el alcance se usa como herramienta de venta, por ende el cambio de escope del release no es una variable de ajuste (o es muy acotada)?
Saludos
LH
Desde la distancia, creo que podríais hacer uso de una previsión en base a la velocidad, a ver si esto te ayuda https://www.javiergarzas.com/2014/01/estimacion-agil-scrum.html y https://www.javiergarzas.com/2014/03/la-velocidad-en-un-proyecto-agil-o-scrum.html
En una conversacion que varios agilistas tuvimos con Agustin Villena en el ultimo Agiles 2014, nos dijo que habia que tener cuidado con la palabra «velocidad» pues eso implicaba la posibilidad de «aceleración» y es lo que los managers nos pedirian aun a costa de no tener un ritmo de trabajo sostenible.