Javier en parte estoy de acuerdo con el planteamiento para lidiar con un cliente que pide fechas. Lo que me "chirría" es la entrega constante de algo que no sabemos qué es (QUE). ¿Qué sentido tiene entregar algo que puede no ser valioso para el usuario? === desperdicio. Sin saber el QUE no podemos seguir entregando nada. Te compro la iteración, por supuesto, pero sobre la base de un primer QUE (MVP) que será el que responda al principal problema de nuestro usuario. Partiendo de ello a iterar midiendo y aprendiendo (validando que aportamos valor). Por este motivo, ir a roadmaps de más de un Q es más un ejercicio de imaginación por la alta incertidumbre. En definitiva, si cliente quiere fechas, disclaimer en mayúsculas sobre la incertidumbre que existe (técnica, por cambios en mercado, bloqueos y dependencias no detectadas,etc...)
Genial la explicación como siempre... Respecto a esto, en el día a día sigo escuchando cosas como "Agile es incluso peor que el cascada, ya que tenemos el estrés de las fechas de entrega del cascada pero ¡¡cada dos semanas!!", en fin... siguen sin entenderlo... Gracias por compartir Javier.
¡Excelente vídeo! Ahora si bien es cierto que el modelo tradicional fracasa cuando se enfrenta a la realidad del qué, el modelo ágil "fracasa" (o sufre muchísimo) a la hora de encajarlo en los procesos empresariales dentro de una gran empresa, la realidad del cómo.
Pero Javier… cuando nos metemos en esos híbridos encuentro los problemas: si el qué no está definido, cómo sé si en un año (fecha límite) voy a poder entregarlo? Y sin ponerme a hacer un análisis detallado de requerimientos al inicio (romper el backlog en detalle al inicio) cómo voy a saber si en todos los Sprints me da tiempo de entregarlo todo??
Gracias Javier, muy clara la explicación. Yo incluiría también el "Cómo", donde los equipos ágiles tampoco conocen el camino para la solución, eso implica que no se puede dar la fecha fin, por eso la importancia de los entregables viables.
El problema principal que veo yo, es que el cliente siempre querrá saber cuánto tendrá que pagar al final por su proyecto. Si vas a una empresa que te dice, no sé cuánto va a salir el proyecto, porque depende del tiempo que nos vaya a tomar, entonces obviamente todo se complica. Al final la metodología ágil tampoco soluciona el problema de determinar tiempos, es mejor en el sentido que son tiempos menores ya que acota el problema en tareas más pequeñas, pero aún así se tiene que estipular el tiempo. Otro problema que veo como desarrollador, es que por vender, los comerciales comprometen tiempos que le suenan bien al cliente y no la verdad. Por eso siempre se atrasa todo, porque acortan demasiado los tiempos. Para ser más competitivos comercialmente y eso también es lógico, se necesitan clientes.
Hola Javier. En el minuto 10'28'', se corta y luego vuelve la grabación, pero se pierden algunos segundos de la explicación. Gracias, no obstante, por el vídeo.
Igual el éxito de esta estrategia depende de la capacidad de priorizar y definir del cliente / product Owner / usuario Porque si le ofrezco una capacidad, y no logra dar con las definiciones de lo que quiere, vamos a llenar el producto de basura y desperdicio o en el peor de los casos vamos a llenar los ambientes previos de ese desperdicio
Saludos. ¿Alguien puede por favor brindarme un enlace para acceder a más información sobre Ziv, Humphrey y Wagner? He buscado pero no logro encontrar algo puntual y me gustaría conocer un poco más sobre lo que dicen de requisitos; del no saber lo que se quiere hasta que se ve y que no es posible especificar un sistema al 100% (3:08). Todos lo sabemos, pero tener una fuente podría ayudarme a abordar mejor las discusiones. Muchas gracias.
3 роки тому+1
Aquí está www.javiergarzas.com/2021/04/en-un-sistema-software-los-requisitos-casi-siempre-van-a-cambiar.html
Sabe cuanto me va a entregar pero no el qué? se consume el presupuesto y al final no se tiene el que deseado, no debería ser una posición tan cómoda y se debería realizar un análisis más detallado y buscar el camino hibrido. Los presupuestos $$$ no son ilimitados.
Javier en parte estoy de acuerdo con el planteamiento para lidiar con un cliente que pide fechas. Lo que me "chirría" es la entrega constante de algo que no sabemos qué es (QUE). ¿Qué sentido tiene entregar algo que puede no ser valioso para el usuario? === desperdicio. Sin saber el QUE no podemos seguir entregando nada. Te compro la iteración, por supuesto, pero sobre la base de un primer QUE (MVP) que será el que responda al principal problema de nuestro usuario. Partiendo de ello a iterar midiendo y aprendiendo (validando que aportamos valor). Por este motivo, ir a roadmaps de más de un Q es más un ejercicio de imaginación por la alta incertidumbre. En definitiva, si cliente quiere fechas, disclaimer en mayúsculas sobre la incertidumbre que existe (técnica, por cambios en mercado, bloqueos y dependencias no detectadas,etc...)
Genial la explicación como siempre... Respecto a esto, en el día a día sigo escuchando cosas como "Agile es incluso peor que el cascada, ya que tenemos el estrés de las fechas de entrega del cascada pero ¡¡cada dos semanas!!", en fin... siguen sin entenderlo... Gracias por compartir Javier.
¡Excelente vídeo! Ahora si bien es cierto que el modelo tradicional fracasa cuando se enfrenta a la realidad del qué, el modelo ágil "fracasa" (o sufre muchísimo) a la hora de encajarlo en los procesos empresariales dentro de una gran empresa, la realidad del cómo.
Extraordinario!!... Los proyectos tienen fechas fin, los productos no.
Pero Javier… cuando nos metemos en esos híbridos encuentro los problemas: si el qué no está definido, cómo sé si en un año (fecha límite) voy a poder entregarlo?
Y sin ponerme a hacer un análisis detallado de requerimientos al inicio (romper el backlog en detalle al inicio) cómo voy a saber si en todos los Sprints me da tiempo de entregarlo todo??
Gracias por el vídeo Javi !
Como de costumbre gran explicación a un problema que todos sufrimos en el dia a dia, Thanks
Gracias Javier, muy clara la explicación. Yo incluiría también el "Cómo", donde los equipos ágiles tampoco conocen el camino para la solución, eso implica que no se puede dar la fecha fin, por eso la importancia de los entregables viables.
Excelente
Improvisar, adaptarse y sobreponerse.. ser ágil significa fluir con los hechos e ir adaptándose a la realidad
El problema principal que veo yo, es que el cliente siempre querrá saber cuánto tendrá que pagar al final por su proyecto. Si vas a una empresa que te dice, no sé cuánto va a salir el proyecto, porque depende del tiempo que nos vaya a tomar, entonces obviamente todo se complica. Al final la metodología ágil tampoco soluciona el problema de determinar tiempos, es mejor en el sentido que son tiempos menores ya que acota el problema en tareas más pequeñas, pero aún así se tiene que estipular el tiempo. Otro problema que veo como desarrollador, es que por vender, los comerciales comprometen tiempos que le suenan bien al cliente y no la verdad. Por eso siempre se atrasa todo, porque acortan demasiado los tiempos. Para ser más competitivos comercialmente y eso también es lógico, se necesitan clientes.
Hola Javier. En el minuto 10'28'', se corta y luego vuelve la grabación, pero se pierden algunos segundos de la explicación. Gracias, no obstante, por el vídeo.
Igual el éxito de esta estrategia depende de la capacidad de priorizar y definir del cliente / product Owner / usuario
Porque si le ofrezco una capacidad, y no logra dar con las definiciones de lo que quiere, vamos a llenar el producto de basura y desperdicio o en el peor de los casos vamos a llenar los ambientes previos de ese desperdicio
Saludos. ¿Alguien puede por favor brindarme un enlace para acceder a más información sobre Ziv, Humphrey y Wagner? He buscado pero no logro encontrar algo puntual y me gustaría conocer un poco más sobre lo que dicen de requisitos; del no saber lo que se quiere hasta que se ve y que no es posible especificar un sistema al 100% (3:08). Todos lo sabemos, pero tener una fuente podría ayudarme a abordar mejor las discusiones. Muchas gracias.
Aquí está www.javiergarzas.com/2021/04/en-un-sistema-software-los-requisitos-casi-siempre-van-a-cambiar.html
Diste en el clavo: Múltiples Fechas de entrega VS una fecha Fin!!! Clarísimo.
Sabe cuanto me va a entregar pero no el qué? se consume el presupuesto y al final no se tiene el que deseado, no debería ser una posición tan cómoda y se debería realizar un análisis más detallado y buscar el camino hibrido. Los presupuestos $$$ no son ilimitados.