Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

#NoEstimates, Estimación Ágil y otras maneras de gestionar

10,163 views

Published on

#NoEstimates, Estimación Ágil y otras maneras de gestionar

Published in: Career

#NoEstimates, Estimación Ágil y otras maneras de gestionar

  1. 1. Estimar no “es timar”, #NoEstimates y otras maneras alternativas de gestionar un proyecto @jgarzas
  2. 2. ¿Cuánto crees que tardarán en construirla? ni idea, pero tiene que estar para ya
  3. 3. As the Negocio As the Product owner As the Desarrollo Casting
  4. 4. DISCLAIMER: Comenzamos hablando del contexto del que venimos y en el que estamos, si ya te lo conoces… “vaya a la diapositiva 30”
  5. 5. 1968
  6. 6. 1968 “Software designers are in a similar position to architects and civil engineers”
  7. 7. 11   Diseño previo e inamovible…
  8. 8. …antes de la Construcción
  9. 9. Ciclo de vida en Cascada... ¿Testing al final?
  10. 10. Año  4!!!  
  11. 11. …Pero aquí hay algo que no encaja
  12. 12. “Caminar  sobre  el  agua  y  desarrollar  software  en  base   a  una  especificación  es  fácil,  si  ambos  elementos   están  congelados”  (Edward  V.  Berard)  
  13. 13. La cara que se te queda cuando en un proyecto NO cambian requisitos
  14. 14. R D C T 1   CASCADA 12 meses Papel Predictibilidad
  15. 15. 1   Tiempo Valorentregado
  16. 16. Proyecto… ¿Cerrado o Llave en mano? :-O
  17. 17. KYBELE  CONSULTING  S.L.  www.kybeleconsul@ng.com  -­‐  Copyright  ©  2012  All  rights  reserved.  Contains  propietary  informa@on.     En 1950 se usó por primera vez el Ciclo de Vida Iterativo, en el desarrollo software del X-15
  18. 18. R D C T 1   2   CASCADAITERATIVO 12 meses 3 meses
  19. 19. 2   Tiempo Valor entregado Valor entregado Valor entregado
  20. 20. Estamos descubriendo mejores maneras de desarrollar software Firmantes del Manifiesto Ágil (2001)
  21. 21. R D C T R D C T R R C T R C C T C R D T R R C T R D C T R D C T R D C T 1   2   3   CASCADAITERATIVOÁGIL 12 meses 3 meses 3 semanas
  22. 22. Tiempo
  23. 23. R D C R D C T R R C T R C C T C R D T R R C T R D C T 1   3   CASCADAÁGIL 12 meses 3 semanas Dto. Dto. Dto. Equipo ¿Tamaño del Equipo?
  24. 24. R D C R D C T R R C T R C C T C R D T R R C T R D C T 1   3   CASCADAÁGIL 12 meses 3 semanas Testing... ¿Quizá demasiado tarde? Testing Testing… T
  25. 25. Estimación ágil Más o menos así de gordo es el proyecto
  26. 26. No estás solo ni eres el único…
  27. 27. La mayor causa de fracaso en proyectos software viene de la presión del calendario… por haber hecho malas estimaciones - Brooks (1975)
  28. 28. Conocer el QUÉ Conocer el TAMAÑO (Unidad) Conocer el TIEMPO IDEAL Conocer el TIEMPO REAL
  29. 29. Tamaño
  30. 30. ¿Estimar con Punto Función…? ¿Perdón?
  31. 31. PUNTo Historia: lo que importa son los valores relativos de una historia (o item) frente al resto
  32. 32. un punto historia es esfuerzo ideal Nooo es es… complejidad
  33. 33. Te la puedes bajar gratis del blog
  34. 34. El punto historia asume error
  35. 35. “El proyecto durará 24 meses, 3 días y 2h” Je, jeje
  36. 36. La estimación y la probabilidad
  37. 37. ¿En días?
  38. 38. ¿Y por qué no horas?
  39. 39. ¿Y por qué no segundos?
  40. 40. “Las posibilidades de acertar al 100% son muy remotas” -- McConnell
  41. 41. ¿Probabilidad? Estimar con un solo número asume la idea de que la probabilidad es 100%
  42. 42. Esta es una distribución más probable… No hay límite en lo que refiere a los problemas…
  43. 43. CONSEJO: No des una estimación con un solo número, acompáñalo de la probabilidad
  44. 44. El punto historia depende del dod
  45. 45. El punto historia lo asigna todo el equipo
  46. 46. velocidad
  47. 47. Bueno.. ¿Y los Contratos?
  48. 48. !Contrato cerrado¡ !Contrato por horas¡
  49. 49. La clausula “Dinero sin hacer nada” (Money for Nothing) -- Jeff Sthuerland
  50. 50. El cliente puede rescindir el contrato en cualquier momento. El proveedor obtiene un 20% de lo que resta (el cliente deja de perder un 80% de lo que se desarrollaría y que no necesitará)
  51. 51. La clausula “Cambios Gratis” (Change for Free) -- Jeff Sthuerland
  52. 52. Los cambios en las prioridades son gratis.. sino se cambia la cantidad total de trabajo. Nuevos requisitos se pueden sustituir a otros de igual cantidad de trabajo
  53. 53. Y si no estimo… ¿qué pasa? eh #noestimates
  54. 54. ¿Tiene sentido estimar? O que la estimación inicial condicione todo el proyecto
  55. 55. Estimar… ¿Es timar?
  56. 56. Si los requisitos cerrados son una mala idea… ¿Cómo se puede llegar a un compromiso en tiempo – dinero sin conocer el alcance?
  57. 57. Cuando se usan puntos historia para estimar. Realmente, ¿tiene sentido ordenar el product backlog por estimación y no por valor?
  58. 58. Necesitamos estimaciones … ¿O hacer lo posible con el presupuesto disponible?
  59. 59. “-Es que si trabajo así me van a engañar, ya que desarrollo va a trabajar más despacio para intentar alargar el proyecto-”.
  60. 60. Si la empresa de desarrollo te quiere engañar lo hará en cascada, en ágil o en cualquier modelo
  61. 61. Pero al no atarte a una estimación te llevas de regalo poder cambiar los requisitos cuando quieras
  62. 62. En cualquier caso, recuerda, “Customer collaboration over contract negotiation”, si no hay confianza difícilmente habrá un proyecto de éxito
  63. 63. “-Es que sin estimaciones cerradas no se cuánto tiempo van a tardar-”
  64. 64. Sino está claro qué hay que hacer, porque se descubre según avanza el proyecto, estará poco claro cuándo se va a terminar.
  65. 65. ¿Te crees que con requisitos cerrados sabías seguro cuándo se va a terminar?
  66. 66. En realidad, tendrás una previsión de finalización pragmática, viendo el trabajo completando por tiempo, la velocidad, que te valdrá para hacer previsiones
  67. 67. Velocidad (trabajo completado por Sprint), TRADICIONAL ÁGIL CON ESTIMACIONES ÁGIL #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
  68. 68. Compromisos por Sprint (semanas) TRADICIONAL ÁGIL CON ESTIMACIONES ÁGIL #NOESTIMATES Acuerdos “cliente” – “proveedor” La estimación inicial es 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
  69. 69. Ciclo de vida iterativo e incremental con iteraciones cortas. Framework tipo Scrum TRADICIONAL ÁGIL CON ESTIMACIONES ÁGIL #NOESTIMATES Modelo, framework, ciclo de vida referencia Ciclo de vida en cascada Kanban
  70. 70. Pago por Sprint o iteración. Pago por tiempo. TRADICIONAL ÁGIL CON ESTIMACIONES ÁGIL #NOESTIMATES Modelo contractual Proyecto cerrado o llave en mano (que mal suena lo de llave en mano, parece que vas a comprar una casa)  Pago por valor (historia de usuario) entregada
  71. 71. Salvo causa mayor, se intenta que no haya cambio de alcance dentro del Sprint (semanas) TRADICIONAL ÁGIL CON ESTIMACIONES ÁGIL #NOESTIMATES Flexibilidad al cambio Muy poca. Se cierran requisitos al principio, se estima, se cierra tiempo, alcance. Esto se pone en contrato y nadie quiere cambiar nada Se intenta sólo no cambiar una historia o tarea empezada, el resto se puede a cambiar en cualquier momento
  72. 72. TeRminando…
  73. 73. Lo que todo responsable de negocio debería saber, ya que nunca nunca nunca nadie lo ha vulnerado…. Calidad Ni yo Pude romperlo..
  74. 74. Estimación Ágil @jgarzas

×