No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

¿Qué es velocidad en ingeniería?

23/28
Recursos

Aportes 69

Preguntas 1

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.

Repitan después de mi:

-“No usaré la velocidad como métrica para mi equipo”

Según el libro Accelerate se miden las compañias por:

  • Deployment frequency
  • Lead Time
  • Mean Time To Recovery (MTTR)
  • Change Failure Rate

Con esto clasifican si una empresa si una empresa o un equipo
es un high, medium, lower software delivery performer

Lo ideal seria medir el desempeño de los equipos basado en objetivos.

¿Qué es velocidad en ingeniería?


Cuando hablamos de velocidad nos referimos a la práctica de estimar tareas de ingeniería, ya sea puntos o tamaños de camisetas, sumarlas y intentar entender cuánto vamos a poder hacer una determinado tiempo.

🔥🔥🔥 Velocidad como métrica de productividad es problemático.

La velocidad es relativa y depende de cada equipo. Y cuando se usa como métrica de productividad los equipos ‘juegan’ la métrica y esto afecta la colaboración.

Si usas capacidad como una métrica de productividad, haces que tu equipo opere de una forma insostenible y no pueden reaccionar a cambios.

Parecería un poco naive, pero yo he usado estrategias de autoe-valuación del trabajo y estimación cualitativa de avances de cada miembro del equipo, en porcentajes. Les he pedido que me indiquen en su apreciación técnica personal, cuánto consideran que han avanzado en sus respectivas asignaciones … luego estos datos se consolidan en un avance general del proyecto, también en porcentaje estimado y se exponen a todo el equipo.
Me funcionó bastante bien.

Siguiendo el manifiesto agil, creo que la productividad de un equipo esta directamente ligada al estado del producto desarrollado, es decir al valor liberado al cliente medido en Features.

En mi caso estamos comenzando a implementar OKR, cada team member es dueño de sus objetivos y damos seguimiento constante a los resultados claves. de la misma manera los OKR no estan ligados a compensación salarial.

Creo que en nuestro contexto medir siempre tiene una pizca de relativo. Opino que se podría medir por objetivos, así en lugar de conseguir puntos o rellenar horas el centro está en completar objetivos que otorgan valor al producto.

La velocidad es buena para planear trabajo y terrible para medir equipos.

Hay varios indicadores que se utilizan

  • Número de errores reportados por pruebas por cada iteracion.
  • Desfase de lo planeado contra lo entregado.
  • Objetivos cumplidos.

Partiendo de la premisa que para cada sprint podemos tener capacidad de desarrollo diferente.
Example: Podemos tener 2 features de valor funcionando para el final del sprint **pero **sin embargo nuestra capacidad de desarrollo era de 4 features de valor y no dos.
_Por tal motivo concluyo con que la productividad y eficacia del equipo se mide X features de valor funcionando (KPI, OKR, objetivos como los quieras llamar) en base a nuestra capacidad de desarrollo de ese sprint en específico _

Podriamos usar una metrica de, que es para el empleado un buen dia de productividad, dejar que ellos mismos se midan durante una semana, cuantos problemas ellos resolvieron etc, y asi seria una forma inteligente de medir

A través del cumplimiento de los objetivos establecidos en cada sprint

yo mido al mi equipo, basándome en lo resultados que obtuve con ellos en iteraciones pasadas. y evaluó y si resuelven tareas mas rápido. No abarco mas de los se que no pueden. y trato de tener un colchón de tiempo. Si le calcule muy mal y me sobra mucho tiempo. No muevo la fecha de entrega. Aprovecho ese tiempo para capacitar al equipo. Hacemos algún curso o actividad.

Se puede medir un equipo por el impacto de las tareas que desarrollan y si estas al final de cuentas no regresan a la fabrica por errores que de cierta manera podrían haber sido manejables por el desarrollador.

Cualquier sistema de evaluación NO es bueno si es que se considera solo una variable, si vas a considerar velocidad (tiempo) pues adicionar otras variables como dificultad para desarrollar algo, limpieza o eficiencia, etc.

Es el mismo concepto del teletrabajo, un proceso asíncrono que se mide por resultados o metas obtenidas en un tiempo determinado.
Lo que un equipo pueda hacer en un día, no significa que los demás puedan o deban hacerlo en el mismo tiempo.

El equipo es como un órgano vivo, para medir su productividad yo mediría la llegada a las etapas. Por ejemplo el proyecto grande lo divido en 5 etapas, la primera la subdivido en etapa A, B y C… y listo, al equipo de la etapa 1 lo puedo medir por el cumplimiento anticipado o no de los tiempos para la etapa A, luego la B y luego la C. Para integrar varios equipos usaría diagramas de Gant y listos

Yo mediria a mi equipo en 2 faces.
1.- Tiempo estimado de tarea / Tiempo en resolución
Si es igual o mayor a 1 el equipo es productivo y debo poner atención en que esta haciendo bien y como mantenerlo igual o mejor. En caso de ser menor a 1 poner atención en que lo esta frenando o si realmente esta capacitado para el nivel de los objetivos.

2.- Comparar el punto 1 entre distintos periodos y proyectos.

Para medir la productividad y eficacia del equipo de desarrollo, consideraria si se estan alcanzando los objetivos del negocio. Ejm: Si sacar a producción un feature nuevo impacta mis metricas de revenue, consideraria que el equipo está rindiendo. Otra forma de decirlo sería medir el software funcional a lo largo del tiempo, si no se está logrando el roadmap, hay que replantear la estrategia.

Recomiendo mucho trabajar con OKRs. Además de las prácticas mencionadas en este curso. Los OKRs brindan transparencia, visibilidad y fomentan el alto desempeño de los equipos.

Velocidad
Herramienta para planear la capacidad de un equipo

  • Relativa y depende de cada equipo
  • No usar velocidad como medida de productividad, los equipos tendrán a jugar con la métrica y afecta la colaboración
  • No usar capacidad como medida de productividad, harás que tu equipo opere de forma insostenible y no pueda reaccionar a cambios

“La velocidad es buena para planear trabajo y terrible para medir equipos”

Considero que se puede medir con base a resultados de equipo. Hacer acuerdos. Y tal vez medir la productividad con ciertos factores durante ese tiempo, como bugs y lanzamientos a producción.

De esa manera podemos estimar que tan avanzado quedp el proyecto, si está al 100% o a un nivel menor y ver datos como cuántos despliegues nos costo realizar por cada feature, analizando su complejidad. Así mismo ver cuáles fueron los errores que se tuvieron y ver los aprendizajes. Hacer una retrospectiva de que fue lo que sucedió.

Me dí cuenta que herramientas como GitLab a nivel de desarrollo te da muchos datos al respecto y en cierta manera son públicos para los integrantes del equipo. Eso mismo orienta a querer ir a alcanzar el resultado y cumplir los objetivos acordados.

Indicadores interesantes pueden ser: El número de historias de usuario TERMINADAS. (Productividad)

El número de bugs asociados a historias de usuario (Calidad)

Depende a qué se dedique la empresa, si es tipo agencia por el tiempo en que se finalize la parte técnica de un proyecto

Cantidad de tareas realizadas por semana

O si es un proyecto muy grande, lo rápido que lleguemos a ciertos milestones importantes

Nos funciona analizando las tareas del proyecto, con el equipo de trabajo clasificamos las tareas de acuerdo a la complejidad (alta, media, baja) y finalmente tenemos un estimado para cada clasificación, por ejemplo: complejidad alta: 3dias, media: 2 dias y baja: 1dia. Finalmente se asignan las tareas de acuerdo al skill de cada colaborador y listo.

Yo lo haría con objetivos terminados o trabajados. Si a inicio de mes se establecieron tantos objetivos con unos plazos y unos limites. Los equipos que van terminando o que están haciendo.

Si tenían 10 objetivos, y para final de mes solo lograron uno y están retrasados en 2, demuestra que no están siendo productivos.

  • Tags en las historias, clasificar el tipo de trabajo que se esta haciendo, si es un improvement, hotfix, new feature. Así podemos determinar en que partes le tocá invertir más a la compañia

Creo que para medir la productividad de un equipo se puede ver la relación entre el trabajo avanzado y el trabajo completo del proyecto. P = (Trabajo avanzado)/(Cantidad de trabajo total)*100

Por el puntaje asignado a cada una de las actividades cumplidas en un proyecto junto con la cantidad de veces que fue reportada una falla en esa actividad.

Por objetivos y tareas es la manera mas clara de medición y un equilibrio entre responsabilidad y libertad de ejecución para el ingeniero.

Estimaría una métrica de complejidad de proyecto balanceandola con el equipo y así saco promedios.

Por objetivos, historias terminadas COMPLETAS, cursos impartidos no solo tomados, “Gracias” de usuarios.

Lo mejor seria medir al equipo por la realización de tareas (funcionalidades nuevas) con valor.

Para mí, se puede medir la productividad del equipo por objetivos logrados (funcionalidades nuevas, número de casos de soporte o acciones de mantenimiento) en un tiempo determinado en contraste con lo planeado al inicio de ese intervalo de tiempo.

Mediría a partir del progreso y backlog de los sprints

OKR’s

Gracias

Lamentablemente el profesor confunde términos y los mezcla… por favor corregir…

numero de sprint alcanzados o notas de usuario alcanzadas

no por estar ocupados estan haciendo bien su trabajo

dependiendo de los roles cada uno de los CI tendrian un valor en su productividad

OKRs

Podría medir por Cards que están desarrolladas y probadas por QA de manera exitosa ya que en cuanto fueron puntuadas en el inicio del Pi Planning.

Por objetivos soy administrador y comprendo que el buen código requiere tiempo, al final lo que me importa es cumplir el objetivo y que el código sea de calidad

emm justo vengo a este curso a ver como, pq no se me ocurre… justo lo que dice de medir por tareas o horas, genera solo problemas.

La mediria con % de proyectos o objetivos concluidos, y en calidad de respuesta ante adversidades.

Por la cantidad de Bugs en la puesta en QA o Prod

aplicaría el indicador de fulfillment (puntos estimados / puntos logrados).

Lo definiria por tareas terminadas durante un lapso de tiempo 😄

por objetivos

podríamos medir por la calidad de la entrega del producto en ciclos cortos.

Por avance, objetivos, hitos

debe existir más allá de todo un tiempo para capacitación, estudio y crecimiento, va de la mano con la productividad.

Por objetivos cumplidos, por mejoras a lo planeado.

una mezcla de entregables por sprint pero que tengan similares niveles de workload. Tampoco directamente asociada a lineas de codigo ni puntaje

como un todo, las entregas individuales no son tan importantes como la sinergia que contiene la combinación de estos aportes individuales.

Voy a dar otro punto de vista que para muchos va a sonar polémico. Hay un movimiento de #NoEstimates, dejo un artículo al respecto

https://ronjeffries.com/xprog/articles/the-noestimates-movement/

Medir segun reportes de fallas, sulucion de dichas fallas y nuevas funciones que mejoran el producto.

funcionalidad o entendimiento del material a trabajar y avance del mismo

Cantidad no es lo mismo que calidad. Por eso se definen proyectos desglosados en tareas pequeñas por día.

Impacto de los outcomes entregados como base para medir a los equipos

Pienso que seria ideal hacer una medición en base a objetivos. Objetivos cumplidos según la planificación realizada.

En impacto al negocio

Por objetivos cumplidos en los tiempos estimados.

Lo mediría en base a porcentaje logrado por día

" La velocidad como métrica es problematizo", es relativa y depende de cada equipo

Impacto del entregable para el cliente, sea final o interno.