Velocidad o Velocidades de Desarrollo?

En la semana con @cafegifo tuvimos una conversación sobre la velocidad de desarrollo de los equipos, en la cual analizamos que siempre se consideran las ausencias de integrantes del equipo para aumentar o disminuir los puntos de historia con los cuales nos comprometeremos. Pero que sucede si cambia totalmente el contexto de negocio y la dificultad técnica? Estamos considerando esto. En el equipo que participó tenemos una velocidad promedio de 36 puntos desarrollando para un sistema nuevo, pero llegó el momento de modificar un sistema legado con una dificultad técnica gigante y lógica de negocio que nadie conocía. Resultado promedio 16 puntos de historia. En su experiencia @davidlaym @sapamo @DeibyOd @taichi2000 @felipet u otro, cómo han tratado este tema? . En mi equipo estamos trabajando con distintas velocidades dependiendo de los factores que considere el Sprint.

Los puntos de historia son bien cuestionables como medida de capacidad (yo prefiero ”ancho de banda") de un equipo de trabajo, dado que asumen una hipótesis falsa, es decir, el tiempo que demora un trabajo NO es proporcional a su complejidad.
Les recomiendo leer este libro https://www.actionableagile.com/predictability-book/

Si leen el capítulo 12, la pregunta es siempre: ¿podemos resolver este ítem en nuestro tiempo estándar? (Siendo el tiempo estándar el que demoran un 85% de lo que hemos resuelto). Si no es así, se divide. Si es así, se podrá ejecutar cuando haya un cupo disponible en nuestra cola de entrada podremos aceptarlo.

Si se dan cuenta, este modelo se adecúa muy bien a cambios de problema o tecnología.

Les recomiendo también esta charla de @manuelcepeda sobre el mismo tema http://www.slideshare.net/leansight/cuando-estar-listo-mtricas-y-forecasting-con-kanban

1 me gusta

Hola, en mi experiencia, la principal -o única- utilidad de los puntos es dar predicitibilidad a un equipo.

Hacia fuera del equipo, a nadie debería importarle si un equipoi hace 18 o 36 puntos (ya que el valor de un punto es una medida inventada por cada equipo), sólo debería importarles el tener un aproximado relativamente confiable de cúando el equipo entregará el siguiente MVP. Desde este punto de vista, da lo mismo si el equipo hace 18 o 36 puntos, sólo importaría que el equipo se sienta tranqulo con lo que están haciendo y con que puedan entregar un nivel satisfactorio de confianza hacia los clientes.

Más allá de lo anterior, y tratando de contestar de manera más práctica tu pregunta, en las últimas estimaciones en puntos que hicimos con mi equipo (ahora ya no estamos estimando en puntos), la certeza técnica era uno de los factores que considerábamos al momento de estimar, porque nuestro objetivo era entregar siempre la misma cantidad de puntos en un sprint. Para hacerlo, estimábamos siempre de manera comparativa. Es decir, si teníamos que hacer dos historias similares, pero en tecnologías distintas (por poner un ejemplo), poníamos en un nivel más alto (de fibonacci) aquella que haríamos en la tecnología desconocida.

Hace un tiempo escribí un artículo con mis opiniones sobre la velocidad de los equipos, te dejo el link por si te interesa: https://medium.com/@ferpobletea/no-no-subiremos-nuestra-velocidad-8795f62a6d03#.2yfxfnw3p

Saludos!

Fernando

2 Me gusta

La velocidad, desde mi experiencia y según lo que interpreto de lo que he leido y compartido en la comunidad, es solamente una métrica post-facto con valor para realizar retrospectiva, pero con poco valor para proyectarse a futuro.
El problema de la velocidad es que es que depende de muchos factores, todos difíciles de medir independientemente y no entendemos como fluctúan en relación a lo demás.

La velocidad depende fuertemente del equipo y al mismo tiempo del proyecto, por lo que si cambias un equipo de proyecto (o cambias el proyecto de manera importante), cambia la velocidad y si cambias el equipo trabajando en el proyecto, también cambia la velocidad. Esos son extremos, pero incluso la motivación, enfermedad/asistencia, vacaciones afectan, entre otros. Por esto las velocidades de distintos equipos y distintos proyectos no son comparables unas con otras. Creer que un equipo es más “rápido” que otro porque su “velocidad” es mayor es una equivocación, porque miden cosas distintas para cada equipo y a distintas escalas. De la misma forma, tratar que un equipo “acelere” es también equivocado. El nombre de “velocidad” es una metáfora muy peligrosa en ese respecto.

Con el tiempo, las fluctuaciones en velocidad debieran menguar y encontrar un buen promedio estable. El problema es que cambiar cualquier parámetro de manera importante va a afectar la velocidad y el promedio ya no te sirve y debes empezar de nuevo desde cero, porque es un equilibrio dinámico de muchos factores que no entendemos como interactúan. A esto me refiero que si cambia una persona en el equipo, o cambia importantemente el proyecto en el que trabajan, no puedes usar promedios anteriores para hacer un pronóstico de como se comportará este nuevo equipo, porque son efectivamente, equipos distintos.

Como verás, la opinión respecto a esto es diversa, @ferpobletea indica que sirve para predecir, @agustinvillena los cuestiona directamente y yo les doy un valor primario de retrospectiva y a su capacidad de predecir, le asigno una fragilidad alta.