Áreas de análise

Nos proxectos de desenvolvemento de software hai varias áreas susceptibles de análise. Mentres que as análises tradicionais céntranse nas métricas do código; actividade, comunidade e proceso constitúen tamén compoñentes chave que deben ser tidos en conta. Este manual pon en contexto aquelas áreas non tan ben estudadas, pero vitais para InnerSource, como son a comunidade e o proceso.

Básicamente, InnerSource consiste nas interaccións directas entre desenvolvedores/as, ao eliminar tódolos aspectos xerárquicos intermedios. Trátase de crear comunidades e construír redes sociais que permitan fluír o coñecemento, e deixar que os equipos de desenvolvemento colaboren entre eles (D2D), afastándose das xerarquías tradicionais. Isto contribúe a aumentar a actividade de desenvolvemento, a romper os silos de información e permite a innovación dentro da organización.

• Actividade: Este factor pon o foco no básico. Tódolos/as desenvolvedores/as deixan vestixios de actividade en cada interacción coa infraestrutura da organización. Poden ser desde commits e correos electrónicos, a actividades de tíckets ou revisións de código. Todo é potencialmente cuantificable e moitas destas accións dos/as desenvolvedores/as dan mostra dun organigrama con información de tendencias. Medir a actividade implica cuantificar os sinais que deixan ata as accións máis básicas dos/as desenvolvedores/as. Cando esta información se engade e calcula por unha tempada, pódense obter tendencias a partir dos datos. As medicións de actividade habituais poden basearse no número de commits ata unha data concreta, pero tamén segundo o aumento ou diminución desa cantidade comparada con outros períodos de tempo. Isto poderíase aplicar a calquera evento potencial que discorra na comunidade de desenvolvemento: correos electrónicos, revisións, apertura e peche de tíckets, comentar a revisión dun código por correo, outros máis elaborados como as accións do/a mentor/a, a actividade dos/as novos/as usuarios/as e a información de referencias cruzadas como os tíckets referidos ás pull requests ou aos seus commits etc.

• Comunidade: as persoas son parte fundamental de InnerSource. Se un dos obxectivos consiste en desxerarquizar a estrutura dunha organización, é necesario medir como se relaciona o persoal cos/coas outros/as desenvolvedores/as. Aínda que , de novo, isto mídese a través do rastro que deixa o equipo de desenvolvemento, as análises propostas céntranse máis en como constrúen as persoas as súas propias redes sociais. Posto que cada quen terá os seus intereses propios, cómpre entender como atraer ou reter talento nun proxecto. Cales son as políticas con mellores resultados e máis atractivas para os/as desenvolvedores/as; e quen é líder no proceso de desenvolvemento de software? Neste caso, as medicións habituais gardan relación coa análise do funil de contribuidores/as que chegan a un proxecto interno, a eficacia de políticas específicas para atraer desenvolvedores/as (por exemplo, hackatóns) e outras máis especializadas como a territorialidade (en tanto que un/unha desenvolvedor/a sexa máis ou menos territorial) ou a intermediación á hora de construír redes xogando con algúns indicadores.

• Proceso: Temos unha comunidade de desenvolvedores/as traballando xuntos/as e, polo tanto, xerando un rastro de actividade. Pero InnerSource vai máis alá da difusión do coñecemento por toda a organización. Tamén é importante reducir os prazos de comercialización, aumentar a velocidade de desenvolvemento e crear produtos mellores. Por ese motivo, o proceso impón unha área de análise necesaria, que podería definirse como a burocracia que seguen os/as desenvolvedores/as para chegar a escribir un fragmento de código. Nunha estrutura máis xerárquica poderían darse reunións diarias nas que tomar decisións e establecer requisitos. Se queremos mellorar ese proceso, en primeiro lugar, deben medirse os seus parámetros chave. Neste aspecto, as comunidades* InnerSource* parécense bastante ás comunidades de software libre nas que o estilo de código, a documentación, o proceso de revisión do código, a CI e as reunións de deseño forman parte do proceso. A diferencia máis destacable é a interacción dos/as distintos/as desenvolvedores/as entre si, aínda cando pertencen a distintas áreas empresariais ou se existe unha distancia xeográfica. A devandita interacción é a que deberá perfeccionarse para poder mellorar en calidade e aumentar a velocidade do proceso de desenvolvemento. De feito, o obxectivo ideal desta mellora é conseguir que todo o proceso poida completarse en cero segundos, que tan pronto os/as desenvolvedores/as ideasen un novo fragmento do código, este xa fose funcional e puidese integrarse de xeito automático. Como podemos chegar a esta situación? Non se sabe, mais poderíase calcular e comprobariamos o lonxe que estamos do ceo.

• Código: Este aspecto da análise probablemente é ben coñecido. As métricas habituais determinan a complexidade do código, a modularidade, a cobertura das probas e a cobertura da documentación, entre outras. Con eses cálculos, o que podemos controlar é cara onde dirixen as devanditas métricas o noso método InnerSource. O aumento da complexidade do código ou a diminución da cobertura das probas pode indicar comportamentos inesperados que deberían corrixirse e controlarse.