En el desarrollo de software, ¿por qué es importante medir la velocidad?

En el desarrollo de software, la pregunta más importante que se le hace al Gerente de Proyecto / Gerente de Programa / Gerente de Producto es: “¿Cuándo se entregará esto?

No hay forma de que podamos predecir que un producto / característica en particular se completará en “x” días o en la “a” fecha de un mes. Y ningún líder empresarial le permitiría salir de una sala de reuniones sin dar un cronograma tentativo. ¿Cómo podemos derivar en esta fecha tentativa? Aquí es donde entra en juego la velocidad de un equipo [Lea: los diferentes equipos tienen una velocidad diferente] .

Consideremos un escenario: se formó un pequeño equipo para desarrollar un producto. ¿Cómo hacemos para decidir nuestros pequeños hitos? Inicialmente, sería una medida de nuestra propia intuición y capacidad para realizar ciertas tareas. A medida que el equipo crece trabajando en los “picos” iniciales para analizar algunas características simples de “MVP”, aprenderemos cómo se desempeña el equipo, esta línea de tiempo / tiempos se convierten en la base. [Una analogía sería cómo la Fórmula 1, la práctica, el calentamiento y la calificación, cada uno de los cuales actúa como un punto de referencia para mejorar y obtener una posición en el top 10 de la cuadrícula]

Esta evaluación comparativa ayuda a un gerente que trabaja en estrecha colaboración con el equipo y que tiene una comprensión justa de la tecnología involucrada para predecir un marco temporal tentativo para la finalización del trabajo.

La velocidad no es una medida precisa de la velocidad. Es una medida relativa, por lo que es mejor gestionar las expectativas definiendo y comunicando claramente: “¿Qué significa la velocidad para su equipo?”.

Una buena lectura de Mike Cohn: sepa exactamente lo que significa la velocidad para su equipo Scrum

Por lo tanto, la razón más importante para medir la velocidad es dar una respuesta tentativa a la pregunta más importante: ¿ cuándo entregará?

No estoy de acuerdo con tu premisa. La velocidad de medición es * popular *. Creo que no solo no es importante, es contraproducente.

Velocity tiene la intención de capturar una serie de cosas relacionadas: precisión de las estimaciones, tiempo perdido por sobrecarga administrativa, etc. Es fácil, conveniente y, al menos a corto plazo, ayuda a establecer expectativas como describe Ian McAllister.
bliki: XpVelocity

Sin embargo, la ambigüedad causada por envolver tantas cosas dispares en una sola medida a menudo y tal vez inevitablemente conduce a un pensamiento descuidado. Mi experiencia ha sido que para cualquier equipo, la velocidad es una función monotónica que va en la dirección incorrecta: con el tiempo, la “velocidad” es más lenta (lo que significa, básicamente, que todos los equipos se vuelven más lentos a medida que ganan experiencia). Lo que en realidad está sucediendo es que el número de cosas diferentes que se consideran como “velocidad” está creciendo, y la medida única conveniente en última instancia oscurece lo que realmente está sucediendo.

Después de adoptar y practicar varias formas de desarrollo ágil durante casi 15 años, he abandonado el uso de la “velocidad”. Quiero saber cuánto tiempo mis equipos realmente pasan escribiendo código, así que tengo en cuenta las horas reales dedicadas al código; Quiero buenas estimaciones, así que utilizo las técnicas descritas en el brillante libro “Cómo medir cualquier cosa” para obtener rangos calibrados para el “mejor” y el “peor” caso para cada tarea, por lo que sé la confianza en la estimación.

Cómo medir cualquier cosa: Encontrar el valor de los intangibles en los negocios: Douglas W. Hubbard: 9780470539392: Amazon.com: Libros

Si la gente no pasa suficiente tiempo escribiendo código, entiendo por qué y hago que se detenga. ¿Pasan demasiado tiempo en operaciones? Luego invierta en operaciones reductoras. ¿Pasan demasiado tiempo en reuniones? Luego, encuentre formas de reducir las reuniones o ajuste el presupuesto para las horas disponibles en un sprint.

En resumen, no permita que la conveniencia de la “velocidad” oscurezca cómo su equipo está pasando tiempo.

Asumo aquí que por “velocidad” te refieres al número de puntos de historia realizados por sprint.

Puede que no sea tan importante medir la velocidad per se. Lo importante es que, dado el mismo contexto, es decir, el tamaño del equipo, las habilidades, etc., deberíamos poder evaluar aproximadamente la capacidad del equipo para cumplir durante el mismo período de tiempo. El período de tiempo aquí es típicamente un sprint.

El desarrollo de software es conocido por sobreestimar o prometer demasiado. Las cosas que parecen fáciles y que se pueden hacer rápidamente terminan resultando complicadas y requieren mucho tiempo. En la mayoría de los casos, es imposible predecir con mucha anticipación, pero gracias a la administración, el marketing, etc., predecir con mucha anticipación se había convertido en la norma.

Scrum, o cualquier otra forma decente de desarrollar software, lo juega empíricamente. También se llama ‘el clima de ayer’. Lo que se supone que envía el mensaje que no espera un cambio radical en la capacidad de entrega.

Hay ciertos pensamientos que circulan en estos días que medir la velocidad desde los puntos de la historia es un desperdicio. Todo lo que necesitamos es una forma de evaluar la capacidad del equipo para cumplir. Y eso también se puede hacer midiendo el número de características por sprint. Puede haber una variación en el tamaño de la característica, pero se espera que se cancele, dadas suficientes características y suficiente tiempo.

  1. El seguimiento de la velocidad actual le permite estimar mejor la velocidad futura
  2. La estimación precisa de la velocidad futura le permite establecer expectativas apropiadas para lo que su equipo puede ofrecer.
  3. Establecer expectativas apropiadas para lo que su equipo puede ofrecer aumenta su capacidad para cumplir con las expectativas.
  4. Repetidamente cumplir con las expectativas genera confianza con la gerencia.
  5. ¡Todos están felices!

More Interesting

¿Cuál es el alcance y el futuro de los trabajos de gestión de productos en India?

¿Deberían los desarrolladores de UI informar al Director de Ux en lugar del Director de Desarrollo de Aplicaciones en una empresa SaaS centrada en Ux?

¿Cuáles son algunas métricas clave que los PM consideran al desarrollar nuevas funciones en Yammer?

¿Qué combinación de materiales podría usar para crear una estera de yoga que tenga agarre, durabilidad, sea ecológica y tenga diseños complejos impresos?

¿Por qué te convertiste en físico después de trabajar como ingeniero de I + D durante la mayor parte de tu vida? ¿Por qué su nuevo énfasis está completamente en el desarrollo de nuevos productos?

¿Cuáles cree que son los "Principios de la gestión de productos"? ¿Difieren según el tipo de producto (es decir, software, hardware, moda) o son universalmente aplicables a cualquier producto?

¿Cuál es el consejo de Mark Fisher para entrar en el desarrollo de productos?

¿Dónde se cruzan finalmente la gestión de productos y UX en el proceso de desarrollo de productos?

¿Cuál es mejor, la metodología Agile o Waterfall para la implementación del software CRM?

¿Qué se necesita para ser un buen gerente de producto en un inicio?

¿Qué debo hacer como desarrollador cuando el gerente de producto ya no cree en el producto?

¿Cuáles son las ventajas y desventajas de hacer una investigación de usuarios con las mismas personas pero con muchos productos diferentes frente a todas las personas diferentes con muchos productos diferentes?

¿Cuál es la diferencia entre los roles de "Gerente de producto" y "Gerente de desarrollo de producto" en Amazon?

¿Cómo combina la provisión de servicios de desarrollo de software (outsourcing) con el desarrollo de su propio producto?

¿De qué debo tener cuidado al contratar con fabricantes de chips?