Cales, cando e como empregalas

Dar coas métricas de software axeitadas non é tarefa doada. Cando tes acceso a datos, e no desenvolvemento de software recolleranse unha gran cantidade deles, contas con moitas métricas posibles. De feito, ás veces, demasiadas, ata o punto en que pode supor certa saturación!

Este informe tenta formalizar unha estratexia e un método cos que identificar, comprender e empregar métricas, na procura da súa aplicación nos procesos de InnerSource. Parte da información incluída neste documento baséase en literatura precedente, mais ningún deses escritos semella centrarse especificamente nas métricas necesarias en InnerSource para entender se un proceso está a funcionar como se espera ou se, por contra, vai precisar cambios substanciais.

Posto que InnerSource é un procedemento a medio ou longo prazo, como con cada nova metodoloxía que se pon en marcha nunha empresa, toda retroalimentación sobre o proceso e o seu rendemento será primordial para garantir a calidade dos resultados. Este informe espera ser a unión entre desenvolvedores/as, xestores/as e directivos/as, á hora de construír un marco axeitado de software de minería de datos baseado en indicadores chave que sirvan para impulsar a mellora do proceso. E, específicamente no caso de InnerSource, espérase que este documento sirva de axuda na selección de métricas e estudos iniciais.

Cómpre ter presente que toda a estrutura organizativa deberá estar aliñada coas métricas empregadas para a análise. A retroalimentación cualitativa dos distintos niveis da organización tamén será parte fundamental deste proceso, que inclúe desde os/as desenvolvedores/as ata o persoal directivo e os mandos intermedios. Todos/as deben comprender que estas accións de seguimento perseguen un obxectivo específico e non tentan rastrexar as súas actividades individuais.

Xunto coas métricas, recoméndanse tamén os sistemas de recompensa; pero sempre co enfoque posto en fomentar algunhas accións específicas, como alentar aos/ás desenvolvedores/as a presentar a súa primeira pull request[^1]. Coas métricas ocorre que a xente, as veces, pode enganalas; polo que deberían usarse só por períodos curtos de tempo para fomentar certos comportamentos, de xeito que permitan ao equipo de desenvolvemento afacerse aos novos procesos. O uso máis recomendable das métricas consiste en facer un seguimento do rendemento de todo o equipo e prever obstáculos en puntos de conxestión e accións que poidan atrasar a súa actividade.

Este informe segue o enfoque GQM (polas súas siglas en inglés, Obxectivo-Pregunta-Métrica)[^2]. Consiste en indicar o(s) obxectivo(s) dunha decisión en particular, logo formular un conxunto de preguntas que se axusten a ese obxectivo e, finalmente, tornar cunha lista de métricas que respondan a cada unha das preguntas propostas.

Dado que InnerSource adopta un significado diferente segundo a organización na que se empregue, tamén pode ter propósitos diferentes. Non obstante, algúns dos obxectivos que xeralmente requiren tódalas organizacións, poderíanse encadrarse principalmente nos seguintes grupos [^3]:

• Mellorar a calidade do código mediante a integración continua (en inglés, e en adiante, CI). Os proxectos de código aberto úsanse para procesos de CI e revisión por pares. E cantos máis ollos revisen un determinado fragmento de código, maior será a súa vantaxe de cara a detectar cedo problemas potenciais. De feito, está comprobado que é beneficioso incluír a revisión do código no proceso, ata o punto de aforrar a metade do gasto potencial do mantemento do software[^4]. Por outra banda, a CI permite automatizar comprobacións que no pasado eran realizadas por humanos/as, como probas unitarias, probas de regresión, de comprobación de estilo, entre outras.

• Reducir o prazo de comercialización. A medida que se rompen os silos dentro da organización, haberá desenvolvedores/as e áreas empresariais en toda a organización dispostos/as a traballar na mesma temática. E isto axuda a aumentar a velocidade do proceso de desenvolvemento.

• Permitir a innovación entre os/as desenvolvedores/asas, que agora poden colaborar entre si, e crear as súas propias redes sociais noutras áreas empresariais. Esta colaboración da pé a novos puntos de vista para un mesmo problema, pois arestora os/as desenvolvedores/as poden crear novos repositorios de forma sinxela a partir dalgunhas regras, mantendo eses proxectos como incubadoras e obtendo o apoio de quen poida participar nalgún momento. A factocracia tamén podería formar parte do proceso.

• Reducir os custos de desenvolvemento e mantemento. O mantemento redúcese cando se limitan as áreas de negocio que traballan na mesma temática, de xeito que o custo se reparta agora entre todas elas. Isto aplícase tamén ao punto de vista do desenvolvemento e o mantemento. Calquera das áreas interesadas en participar nun proxecto, por estar os seus obxectivos aliñados co antedito proxecto, poden contribuír con recursos.

• E, por último, mais non menos importante, permitir aos/ás desenvolvedores/as traballar sobre temáticas que consideren relevantes para a organización, ou sexan do seu propio interese, faraos/ás sentir máis cómodos/as. InnerSource favorece o mantemento nas organizacións dos/as desenvolvedores/as particularmente bos ou boas, pero tamén axuda no proceso de contratación; xa que a organización parecerá máis innovadora se escoita as necesidades dos/as desenvolvedores/as. Ademais, isto promove unha maior implicación xeral dentro da organización.