Webinar #noEstimate
•Descargar como PPTX, PDF•
11 recomendaciones•10,214 vistas
Este documento discute el enfoque de #NoEstimates para el desarrollo de software, el cual implica realizar proyectos sin ningún proceso formal de estimación. Varios autores argumentan que las estimaciones son inexactas debido a la naturaleza cambiante de los requisitos, y que en su lugar se debe enfocar en la entrega continua de valor mediante iteraciones cortas y colaboración con el cliente. También se comparan los enfoques tradicional, ágil con estimaciones y #NoEstimates en términos de métricas, compromisos y
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (18)
Similar a Webinar #noEstimate
Similar a Webinar #noEstimate (20)
Más de 233 Grados de TI
Más de 233 Grados de TI (20)
Webinar #noEstimate
- 3. ¿Cómo podemos estimar cuando todavía no sabemos o entendemos la solución? Neil Killick http://neilkillick.com/2013/01/31/noestimates-part-1-doing-scrum-without-estimates/
- 4. si los requisitos no son precisos… las estimaciones no son precisas
- 5. http://www.javiergarzas.com/2011/06/breve-introduccion-estimacion-4.html El nivel de precisión de la estimación es distinto a medida que avanza el proyecto
- 6. para construir software necesitamos sólo una visión clara y un propósito compartido, objetivos de alto nivel, y no el detalle de cómo vamos a lograrlos
- 7. ¿qué sentido tiene buscar una estimación precisa y condicionar todo el proyecto a ella? ¿qué sentido tiene si sabemos desde el principio que es inexacta por naturaleza?
- 8. #NoEstimates no significa que las estimaciones sean malas, sino que no son necesarias Woody Zuill
- 9. Estimación es la cantidad de tiempo necesaria para desarrollar un producto, determinado por el juicio humano y basado en su propia experiencia
- 10. #NoEstimates es desarrollar un proyecto de software sin ningún proceso de estimación.
- 11. Si el cliente pregunta, ¿Cuanto tiempo llevará esto? Eso es estimación….Si no lo pregunta, eso es #NoEstimates.
- 12. ¿Necesitamos estimaciones de proyectos software… o presupuestos?
- 13. En casi todos los proyectos, comienzan con “- ¿Esto cuánto va a costar?-“ Pero, quizá, la pregunta correcta no debería ser… “-¿De cuánto presupuesto dispones?-“.
- 14. “- Es que si trabajo con un presupuesto me van a engañar, ya que desarrollo va a trabajar más despacio para intentar alargar el proyecto -”.
- 15. Si la empresa de desarrollo te quiere engañar lo hará en cascada, en ágil o en cualquier modelo
- 16. Pero al no atarte a una estimación te llevas de regalo poder cambiar los requisitos cuando quieras
- 17. En cualquier caso, recuerda, “Customer collaboration over contract negotiation”, si no hay confianza difícilmente habrá un proyecto de éxito
- 18. “-Es que sin estimaciones cerradas no se cuanto tiempo van a tardar-”
- 19. Sino está claro que hay que hacer, porque se descubre según avanza el proyecto, estará poco claro cuándo se va a terminar.
- 20. ¿Te crees que con requisitos cerrados sabías seguro cuándo se va a terminar?
- 21. Y, no obstante, en la realidad si que vas a tener una previsión de finalización, ya que vas a ir viendo los requisitos que el equipo va completando por periodo de tiempo, lo que te dará lo que llamamos la media de velocidad, que te valdrá para hacer previsiones de finalización.
- 22. algunas ideas para hacer funcionar #NoEstimates
- 23. 1 - comienza los proyectos con poca inversión. Entrega SW funcionando siempre
- 24. 2 - financia un prototipo que entregue SW funcionando, luego usa modelos para hacer predicciones
- 25. 3 - convierte las relaciones contractuales a partnerships
- 26. 4 – Modelos de comercialización cloud
- 27. 5 - #NoEstimates consiste en buscar la forma de que si sea viable en el mundo real no estimar
- 28. Comparando el enfoque tradicional, con el ágil con estimaciones y con el #noEstimates http://www.javiergarzas.com/2014/12/comparando-el-enfoque-tradicional-con-el-agil-con-estimaciones-y-con-el-noestimates.html https://docs.google.com/presentation/d/1AinGFFlzOE4gL8Bntp2rJFAdoqhku_iXrKgfJjK-BSw/mobilepresent?pli=1#slide=id.p13
- 29. Velocidad (trabajo completado por Sprint), Puntos Historia. Burn Down / Up TRADICIONAL ÁGIL C/ ESTIMACIONES #NOESTIMATES Métricas típicas de seguimiento de proyecto Tiempo Real vs Tiempo Estimado.% de avance (p.e. El típico del Gantt) Valor entregado. Historias de Usuario completadas, Lead Time, Cycle Time
- 30. Compromisos por Sprint (semanas) Acuerdos “cliente” – “proveedor” La estimación inicial se convierte en un compromiso a largo plazo (meses, años), en tiempo, precio y alcance Entrega continua. Flujo continuo de entrega de valor. Los acuerdos están en la ordenación por valor de aquello a realizar y en intentar reducir los tiempos de elaboración (el cycle time, desde que se empieza a trabajar en una tarea hasta que se termina) TRADICIONAL ÁGIL C/ ESTIMACIONES #NOESTIMATES
- 31. Ciclo de vida iterativo e incremental con iteraciones cortas. Framework tipo Scrum Modelo, framework, ciclo de vida referencia Ciclo de vida en cascada Kanban TRADICIONAL ÁGIL C/ ESTIMACIONES #NOESTIMATES
Notas del editor
- No está muy claro el origen de la idea, pero desde luego, en los últimos tiempos, el movimiento que recomienda y defiende que las estimaciones en el mundo del software no tienen sentido (e incluso son perjudiciales) ha crecido con relativa fuerza en el mundo del desarrollo software y, más concretamente, en el mundo ágil. Más allá de los orígenes, por si quieres seguir este tema, quienes más están liderando el #NoEstimates son Woody Zuill y Neil Killick. Hoy en día, este movimiento en contra de las estimaciones software podemos encontrarlo agrupado bajo el nombre #NoEstimates (lo de la # al principio del nombre viene de que éste es un hasghtag de twitter, por si no eres muy tuitero, bajo el que se recopilan opiniones sobre el tema).
- Realmente, por la naturaleza del software, es imposible obtener una estimación precisa Como expone en un artículo Neil Killick, que como te decía es unos de los precursores del movimiento, la base del movimiento #noEstimates está en “¿Cómo podemos estimar cuando todavía no sabemos o entendemos la solución?” El desarrollo software es, por su propia naturaleza, impredecible y no repetitivo. A diferencia de la producción de, por ejemplo, automóviles (te recomiendo aquí aquel post de Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas), el producto exacto que estamos construyendo es desconocido hasta que lo hemos construido. Por esta razón, fijar el alcance exacto (en tiempo – esfuerzo) de los proyectos software es imposible. Incluso si lo fuera, no es deseable, ya que un enfoque de este tipo limita el cambio durante el proyecto, limita un diseño emergente, los requisitos cambiantes y la innovación. Si aceptamos que el alcance de aplicación a desarrollar es siempre la variable… también debemos aceptar que la fecha de entrega puede ser variable.
- Obtener una estimación se basa en satisfacer un conjunto fijo de requisitos, si los requisitos no son precisos… las estimaciones no son precisas Y tener unos requisitos precisos antes de comenzar… ya sabemos, y está muy debatido, que es algo que muy pocos proyectos se pueden permitir, algo que siempre pretendió el ciclo de vida en cascada, algo que generó (genera) proyectos en los que todas las partes acaban inconformes, etc. No me extiendo en las razones de todo esto, que ya las hemos contado muchas veces, no obstante, si tienes interés léete estos dos post: Contrato cerrado, ¿el peor enemigo del software o mal necesario? Y Diagramas Gantt cómo arma de destrucción masiva de proyectos.
- Estimar varias veces durante el proyecto. No basta con estimar al principio, según avanza el proyecto deberíamos reajustar la estimación. Algunos autores señalan que deberíamos estimar al menos en tres puntos: En la etapa de estudio de viabilidad, o inicio del proyecto, en la etapa de requisitos y en la etapa de diseño. Yo incluso creo que en proyectos grandes habría que estimar varias veces según avanza el desarrollo. El nivel de precisión de la estimación es distinto a medida que avanza el proyecto. Al principio del proyecto, cuando sólo se tienen requisitos, el error con el que se trabaja es mayor que cuando se estima en la fase de diseño. Una figura muy útil para entender esto es el “cono de incertidumbre”, que muestra cómo las estimaciones son más precisas según progresa el proyecto: Aparte de tamaño y esfuerzo global, hay que estimar fases concretas del ciclo de vida. Si no se tienen históricos, existen fórmulas que dicen cómo se divide en fases el esfuerzo total del proyecto, las más famosas son del ISBSG. Cada empresa (y muchas veces tipo de proyecto) tiene su método de estimación. No hay un mejor método de estimación… hay uno mejor para cada empresa, y este depende del negocio, del tamaño de la empresa, de su madurez, etc. Por ejemplo, el método de estimación para empresas que desarrollan productos no será seguramente igual que el de empresas que externalizan. Utilizar varias fuentes y métodos. Complementar siempre el método de estimación con datos de proyectos anteriores (analogía), y realizar comparativas con los mismos. Además, complementar preguntando al equipo de desarrollo. Usa una unidad de estimación acorde a la fase del proyecto en la que estimas. A la hora de proporcionar una estimación muchas veces es útil valerse de rangos, que se pueden ir ajustando conforme avanza el proyecto. Por ejemplo, “entre la primera y la segunda semana del mes de abril” o “10 meses con más menos quince días de error”. Un error muy frecuente es en la primera estimación decir el día exacto de finalización del proyecto, cuando sabemos que en una estimación tan temprana siempre hay error.
- Como argumentan desde el #noEstimates, para construir software necesitamos sólo una visión clara y un propósito compartido, objetivos de alto nivel, y no el detalle de cómo vamos a lograrlos. Entonces… ¿qué sentido tiene buscar una estimación precisa y condicionar todo el proyecto a ella? ¿qué sentido tiene si sabemos desde el principio que es inexacta por naturaleza?
- En la verdadera forma iterativa entonces podemos alinear nuestras decisiones justo a tiempo acerca de cómo vamos a mejorar el producto en la siguiente iteración (es decir, lo que vamos a construir al lado, también conocidos como elementos principales en la Pila de Producto) con estas metas. To build software we need a clear vision and shared purpose of what success looks like. When commencing with a potentially valuable software initiative we need well understood high level goals, not the detail of how we will achieve those goals. In true iterative fashion we can then align our just-in-time decisions about how we will improve the product in the next iteration (i.e. what we will build next, aka top items in the Product Backlog) with these goals.
- Woody Zuill y neil Killick Zuill didn't claim that estimates are "bad" in all cases; rather, they're not always essential to the software development process. an estimate is "a length of time it will take to develop software, determined by human judgment and based on experience." There are many ways to do this. You can break the work down into chunks and add it up, you can look at a variety of similar projects to compare, or you can stick your finger in the air and guess. All of those are estimation techniques. We'll define #NoEstimates as running a software project without any human estimation process. If customers asks, "How long will it take?" that's estimating. If they never have to ask, that's #NoEstimates.
- For the purpose of this article, an estimate is "a length of time it will take to develop software, determined by human judgment and based on experience." There are many ways to do this. You can break the work down into chunks and add it up, you can look at a variety of similar projects to compare, or you can stick your finger in the air and guess. All of those are estimation techniques.
- Corte, ver como aplicar en la realidad
- Entiendo que os estaréis preguntando como hago p llevar esto a la realidad, yo lo puedo decir de manera muy coherente aca pero afuera hay que hacer presupuesto y vender proyectos y lo que quiero deciros es que si se puede y de hecho ya se esta haciendo…
- El problema no solo son los requisitos, sino la tecnología cambiante y el cliente también (diferentes) La incertidumbre no solo está en los requisitos…
- En la medida de lo posible En vez de tener proyectos llave en mano hacer acuerdos de colaboración Es lo típico cuando una empresa que tiene una idea se alía con una consultora tecnológica para llevarlo acabo .. en este caso no es necesaria la estimacion, porque no vendemos un proyecto cerrado sino que firmamos un acuerdo de colaboración
- http://www.slideshare.net/mgbarcomb/fly-weight-agile-stop-making-it-harder-than-it-needs-to-be En modelos de comercialización cloud se factura por uso el proyecto de desarrollo de software Hay muchas consultoras grandes que en vez de vender proyectos llave en mano cobran sus servicios por utilización Imagínate una multinacional con miles de empleados dispersos alrededor del mundo que necesita un proyecto de single signe on (autenticación unica) En vez de contratarnos un proyecto cerrado con necesidad de estimar p hacer este sw, nos paga por usuario conectado por mes Consultoras grandes como everis ademas de proyectos cerrados estan tendiendo a vender proyectos por uso
- No está muy claro el origen de la idea, pero desde luego, en los últimos tiempos, el movimiento que recomienda y defiende que las estimaciones en el mundo del software no tienen sentido (e incluso son perjudiciales) ha crecido con relativa fuerza en el mundo del desarrollo software y, más concretamente, en el mundo ágil. Más allá de los orígenes, por si quieres seguir este tema, quienes más están liderando el #NoEstimates son Woody Zuill y Neil Killick. Hoy en día, este movimiento en contra de las estimaciones software podemos encontrarlo agrupado bajo el nombre #NoEstimates (lo de la # al principio del nombre viene de que éste es un hasghtag de twitter, por si no eres muy tuitero, bajo el que se recopilan opiniones sobre el tema).