Saltar al contenido

Un enfoque basado en datos para los principales equipos de software

El satélite GitHub de este año en Londres se centró en la forma de trabajar de los equipos y en cómo mejorar los flujos de trabajo con las herramientas adecuadas para su equipo. Se pidió a GitPrime que presentara junto con oradores de Codacy, Rollbar, CircleCI, GitHub, y más para educar, inspirar y explorar las mejores prácticas de la industria.

El presidente de GitPrime, John Witchel, compartió acerca de un enfoque basado en datos para dirigir equipos de software, y cómo utilizar eficazmente los datos de los depósitos de git para permitir la productividad de los desarrolladores de software.

Un enfoque basado en datos para los principales equipos de software
Un enfoque basado en datos para los principales equipos de software

John llevó a la audiencia a través de una serie de casos de uso para medir la productividad, para demostrar cómo se mide la productividad en la ingeniería de software, y por qué los KPI son importantes para los desarrolladores.

Aquí hay un video de la charla:

A continuación se muestra una transcripción ligeramente editada:

Me llamo John Witchel. Soy el presidente y director general de GitPrime. Muchas gracias por venir.

Me gustaría empezar haciendo una pregunta: ¿es posible conseguir un aumento del 20% en la productividad con un equipo existente? Es un número muy grande.

Voy a pasar un poco de tiempo hoy mostrándote cómo puede suceder eso.

GitPrime está en el negocio de la métrica de productividad para equipos de ingeniería con el propósito de crear un equipo de ingeniería más productivo. Fundamentalmente, en GitPrime estamos tratando con “la caja negra de la ingeniería”. La caja negra de la ingeniería es un problema caro y en gran parte sin resolver hoy en día. En el corazón de ese problema, es que es sorprendentemente difícil rastrear a los desarrolladores.

Irónico, ¿verdad? Los desarrolladores son los que ayudan a rastrear virtualmente a todos los demás grupos de la empresa hoy en día. Somos los que escribimos el software que se convirtió en Salesforce. Lo hicimos para marketing, contabilidad e inventario. Sin embargo, somos el último grupo en usar métricas de seguimiento. Eso es algo malo. Creo que es muy, muy difícil ser el mejor si no te miden de alguna manera.

Si estás tratando de sacar el máximo provecho de tu equipo de ingeniería, la forma correcta de hacerlo es medir. Lo siguiente son algunas cosas que GitPrime mide, que también son algunas de las preguntas que hacemos a nuestros clientes. Pregúntaselas a tu propio equipo:

  • ¿Qué equipos de su grupo, en su empresa, tuvieron el mayor impacto el mes pasado? ¿En qué medida?
  • ¿Esta semana fue más productiva que la anterior? ¿Según quién y según qué métrica?
  • ¿Cuánto del trabajo del mes pasado fue para pagar la deuda técnica? ¿Como un porcentaje de su quemadura total? ¿Cómo lo sabes?
  • ¿Cómo le muestras a los demás que tu equipo está trabajando duro? ¿Qué datos apoyan esto?

Todos hemos estado en equipos en los que todo el mundo se está rompiendo el culo. Parece que no puedes obtener crédito por todo el trabajo que estás haciendo, pero si pudieras exhibirlo en una pizarra y mostrarlo a la gente fuera de la ingeniería, podría cambiar la conversación.

En lugar de seguir hablando conceptualmente de cómo hace eso GitPrime, quiero sumergirme en una serie de animaciones de nuestro producto. Hablaré de cómo hacemos lo que hacemos, y cómo usar esta herramienta.

Comprende tu comportamiento en el trabajo

Este es el punto de entrada a nuestro producto: el informe de flujo de trabajo de confirmación. Lo que ven aquí es una vista consolidada de todos sus repositorios. Como una nota rápida para el contexto: GitPrime toma todos los repositorios de tu empresa, los lee, los analiza, genera un enorme conjunto de metadatos y luego produce informes. Git es la fuente principal de toda nuestra información.

Lo que estamos viendo es esencialmente un corte aproximado de lo grande que es cada compromiso individual de estos miembros del equipo. Ahora, creo que todos en esta sala estarían de acuerdo en que contar líneas de código es una idea terrible. ¿Verdad?

Para alguien que sepa leer este informe, ver cuán grande y regular es el compromiso de un desarrollador puede ser un buen indicador de si está teniendo éxito, luchando, necesitando un poco de ayuda o (más comúnmente) debe ser dejado en paz. Si miramos a Allen (en la parte superior), vemos a una persona que se compromete ligeramente. Comparado con sus otros dos compañeros de equipo, parece que es un problema. En realidad no es un problema. Allen está trabajando en un problema de ingeniería muy difícil, está afinando una secuela. Como su manager, no espero más de uno o dos compromisos en un par de semanas, dada la difícil naturaleza de este problema. Nathan aquí, revisando toneladas de cosas. Está haciendo una parte inicial del proyecto. Y Peter – toneladas y toneladas de fusiones. Cuando “apago” la fusión se compromete, todavía está en buena forma.

Mediante una simple búsqueda, puedo comprobar si los desarrolladores que se supone que están haciendo el trabajo en mi boleto lo están haciendo realmente, sin interrumpirlos. Eso es algo muy especial; creo que todos sabemos que un ingeniero interrumpido es un ingeniero que acaba de bajar a casi cero la productividad. ¿Cuántas veces hemos estado allí? Tengo 15 variables en mi cabeza. Entonces, alguien dice, “Oye, hombre. ¿Puedo tener un segundo de tu tiempo?” Y tú dices: “En realidad, puedes tener 20 minutos, porque he olvidado por completo lo que estaba pensando”. Si podemos detener ese comportamiento interrumpido con respecto a los estados, aumentamos la productividad. Si sabemos intervenir cuando alguien está luchando, aumentamos la productividad.

Compara esta semana con tu típica

GitPrime tiene todo un conjunto de métricas. Algunas de las cuales te resultarán familiares, otras son nuevas. En este informe, podemos clasificar a las personas por varios puntos de datos. Lo más importante, podemos marcar dónde están, en relación con su media rodante, o su “típico”.

Agitarse. Tomemos esta columna de aquí, la tercera a la derecha. Este es el índice de rotación de personal. Ahora, todo el mundo se revuelve. La rotación es cuando escribes una línea de código, y luego reescribes una línea de código. Ponemos una línea en un tallo que básicamente dice que si se revuelve el código (si se escribe una línea de código y se reescribe esa misma línea de código en tres semanas), está bien. Simplemente no obtienes doble crédito por ello. Si te agitas demasiado, puede ser una indicación de que hay un problema.

Echemos un vistazo a Katherine, en la parte superior de la pila de batidoras. Ella reescribió el 90% de su código en las últimas tres semanas. Eso sería problemático, excepto por el hecho de que está en el prototipo, en cuyo caso, es un comportamiento totalmente normal. Puedo ver que normalmente está en un 38%, más o menos, pero también sé que la pusieron en ese proyecto hace sólo dos semanas, así que en realidad voy a ignorar ese conjunto de datos. Luke, sin embargo, tiene un problema. Ha batido el 60% de su código en los últimos siete días, mientras que normalmente lo hace con los dígitos bajos. Está trabajando en una función de administración estándar, sólo reescribiendo algunas páginas. ¿Por qué se agita tanto más?

No lo sé, pero como gerente, necesito sentarme de mi silla. Voy a dejar a Katherine en paz. Voy a dejar a Mark en paz. Voy a dejar a Alexander en paz, y voy a ir a ver a Luke. Esa clase de manejo de precisión incrementa la productividad de todos los demás en esta junta y potencialmente va a salvar a Luke de un problema bastante serio. En este caso en particular, fue un problema serio, y como soy un fantástico gerente – problema resuelto.

Comprobando. Día desde el último registro no trivial. Está bien no hacer el check-in todos los días, pero no puedes hacerlo muy a menudo. Si tienes más de una semana, necesitas tener una razón para no hacer el check-in. Por lo general, hay una buena razón.

Al final del día, GitPrime es una herramienta de señalización. Es una señal para un gerente de dónde poner su atención.

tt100 Productivo. TT100, tiempo en horas requerido para escribir cien líneas de código después de la rotación. Esta no es una estadística muy interesante cuando se toma en un momento dado. Sin embargo, cuando se toma en un largo período de tiempo, esta métrica termina siendo un indicador sobresaliente de la productividad, especialmente para los ingenieros en ciertas clases de trabajo. Para los desarrolladores que están haciendo nuevas características, trabajando en partes de rápido movimiento en el front-end del código, los HTMLers – esto termina siendo un área excelente para señalar que alguien está atascado.

De nuevo, puedo ignorar a algunos de estos tipos porque sé que están haciendo afinaciones, o alguna otra área donde no esperaría una tremenda cantidad de producción. Sin embargo, si John C (al final de la lista) es un HTMLer que sólo escribe nuevas características en el prototipo, yo comprobaría si tiene algún problema. ¿Tiene sentido? Es mucho mejor que andar por la oficina y decir: “Oye, tío. ¿Cómo va todo? Bien, ¿bien? ¿Bueno? Oh, bien. Genial”. Nadie admite nunca que no vaya bien. Si le preguntas a cualquier ingeniero en la mitad de su día, “¿Cómo va todo?”, siempre dirá que bien. Entonces, tienes que investigar. Tienes que empujar. Todo ese tiempo que estás empujando y empujando y preguntando, tratando de descubrir problemas, estás perdiendo el tiempo de tu desarrollador. Le estás quitando productividad a tu equipo. Esto apunta a resolver eso.

Compara tu posición con el resto del equipo

Cuando te metes en la maleza, a veces vale la pena echar un vistazo al lugar donde un ingeniero está en posición al resto del equipo. Lo que tenemos aquí son dos ejes: Throughput (líneas netas de código, después del churn), y Churn. Aquí hay un desglose de quiénes se encuentran en los cuatro cuadrantes:

  • El cuadrante superior derecho: aquí es donde tienes a tus “prolíficos” programadores. Estas son personas que producen una tremenda cantidad de trabajo con muy poca reescritura.
  • El cuadrante inferior derecho: aquí es donde a menudo se ven los gerentes y los líderes de equipo a tiempo parcial – personas que no necesariamente deben tener un alto rendimiento. Su trabajo tiende a ser pequeño y preciso, como los retoques. Por lo demás, se les considera “perfeccionistas”.
  • En el cuadrante inferior izquierdo, el cuadrante “podría estar atascado”: tienes gente que se agita mucho y tiene una salida neta de muy poco.
  • Y finalmente, encontrarán a sus “exploradores” en el cuadrante superior izquierdo: Estas son personas que tienen un alto rendimiento y una alta rotación. Esto se ve más comúnmente en los desarrolladores que escriben HTML, CSS y JavaScript. Estos tipos escriben código, obtienen retroalimentación de un interesado interno, escriben algo más de código y se lo muestran de nuevo al interesado.

Explora el progreso de tu equipo a lo largo del tiempo

Pon todos estos datos juntos, y obtendrás las tendencias. Echemos un vistazo a Impacto. El impacto mide esencialmente la “carga cognitiva” que su equipo llevaba cuando implementaba los cambios. Es una función de la cantidad de código que estás escribiendo, el número de lugares de edición y el número de archivos afectados (por nombrar algunos).

Digamos que entro, arreglo un método de ayuda, y lo ato a alguna pieza de la parte delantera. Todo mi código estaría bastante concentrado en toda la base de archivos, ¿verdad? Ahora, compara eso con el tipo a mi lado, que tocó 15 archivos por todo el mapa, tiene un par de líneas de código en las líneas 1 – 20, y edita en unas 30. Él llevó una carga cognitiva más alta, o tuvo un mayor impacto en la base de código, que yo.

El volumen de compromiso es exactamente como suena. Es un método más sofisticado para medir la producción bruta del equipo. Veamos las líneas de tendencia. Una de las cosas que es muy, muy común es porque podemos caer en, porque podemos caer en eventos en nuestros informes, podemos caer en eventos en nuestros informes, podemos ver cosas que están impulsando la productividad.

Normalmente, eso es una liberación, ¿verdad? También podría ser el hombre en llamas. También podría ser la pérdida de un jugador clave en el equipo, la renuncia o la incorporación de un jugador clave en el equipo. Se hace muy fácil ver lo que está haciendo una diferencia en su equipo. Medimos y miramos los compromisos. Este es un informe que muestra los elementos que se revisan. Este es un punto de datos o informe extremadamente útil para la gente que está tratando de ver que el último kilómetro pase por la puerta.

Analice su proceso de revisión de códigos, e identifique el valor comercial estancado

Samantha abrió una oficina de relaciones públicas hace cinco meses… todavía está en el aire. No sé qué está pasando ahí, pero matemos las relaciones públicas, quitémoslas o cerremoslas. No está bien que un RP esté fuera durante cinco meses, punto.

Esto se ordena en base a la edad de las relaciones públicas. Puede desplazarse hacia abajo y ver los más antiguos.

También puedes tener una idea de cuán difícil y rápida es esta liberación. ¿81.000 líneas de código para revisar? Este es el peor de los casos. Si tienes 81.000 líneas de código para revisar, y estás a una semana del cierre, puedes apostar que esa liberación va a salir mal. Como referencia, 32 relaciones públicas abiertas es mucho, deberías estar cerrando relaciones públicas en un equipo grande. En un equipo de 50 personas, deberías cerrar las relaciones públicas un par de días después de que se abran, como mucho.

Muy rápidamente, la conversación de “¿Cómo va?” y “¿Se siente bien?” comienza a cambiar. Empieza a ser sobre datos. Por supuesto, puede ser intimidante para la mayoría de los ingenieros cuando miran estos informes por primera vez. Lo más importante que deben recordar los ingenieros es que los datos son nuestros amigos. Los datos están donde está la verdad.

Cuando nos metemos en discusiones en nuestras organizaciones, si se trata de los datos, la mayoría de las veces ganamos, porque los datos despolitizan las conversaciones. Deja de tratarse de lo que sentimos y de los gerentes de producto y las partes interesadas – siempre son muy buenos para hablar. Si puedes salir de la parte de la conversación y entrar en la parte de los datos, la verdad suele salir a la luz.

Aunque al principio puede ser intimidante saber que un grupo de gente está mirando tus compromisos, tus relaciones públicas, tus flujos de trabajo y tu impacto, encontrarás que es algo bueno para la ingeniería. También podemos mirar los comentarios. Una de las cosas que me encantan de GitHub es que es una gran plataforma para la codificación social. Es simplemente una mejor herramienta para comunicarse rápidamente con otros ingenieros, obtener retroalimentación, hacer un bucle con esa retroalimentación, y obtener una revisión por parte de los pares. Eso es, de nuevo, intrínsecamente bueno. Es algo bueno, pero es importante entender el flujo de compromisos. Si una persona en un equipo grande lleva una carga antinatural de revisión y comentarios, es un signo de baja productividad. Normalmente, esa persona es el perro alfa del equipo. En cambio, si extendemos su revisión y sus comentarios con otros ingenieros, esos otros ingenieros mejoran. El perro alfa puede hacer más del trabajo pesado para el que fue contratado originalmente.

Lo que estamos viendo aquí es quién abrió el PR, lo comentó y lo fusionó. Esto muestra quién está haciendo el trabajo social alrededor del lanzamiento. Una vez más, se ve un número de métricas de alto nivel, muy, muy bueno para la señalización temprana, muy bueno para indicar que hay un problema antes de que ese problema se manifieste completamente.

Conclusión

Concluiría que hay mucho valor allí. Es un nivel superior al de interrumpir a cada ingeniero un par de veces a la semana. Es un nivel superior al de los estudios retrospectivos. Es un nivel superior al de no saber. Es un nivel superior a tener que discutir y debatir y negociar el valor de tu trabajo con alguien que es, por definición, mejor argumentador y negociador que tú.

Al final del día, como promotor, sólo quiero ser reconocido por la calidad y la fuerza de mi trabajo. Cuanto más claramente pueda mostrar/articular/evidenciar eso, mejor y más saludable seré como ingeniero. Cuanto mejor sea mi equipo en su conjunto. Esperemos que, a medida que GitPrime continúe creciendo y teniendo éxito, todos seremos mejores por ello.

Gracias.