diff --git a/translations/gl/README.md b/translations/gl/README.md index 5182988..d4fbd95 100644 --- a/translations/gl/README.md +++ b/translations/gl/README.md @@ -4,7 +4,7 @@ Este libro busca proporcionar información sobre a xestión de distintos aspectos indispensables á hora de empregar InnerSource nas empresas. -É o resultado dun proceso aínda en marcha, no que calquera persoa está convidada a contribuír de calquera xeito posible. As aportacións en forma de ideas, comentarios, correccións de erros tipográficos, ou mesmo cambios en parágrafos ou seccións enteiras, serán benvidas. Este repositorio ten como obxectivo aportar coñecemento especializado desde a industria de maneira que sexa útil a terceiros/as. Para isto, estamos na procura activa de revisores/as que poidan colaborar neste proceso e expresamos o noso agradecemento a aquelas persoas que xa fixeron algunha contribución ao libro. +É o resultado dun proceso aínda en marcha, no que calquera persoa está convidada a contribuír de calquera xeito posible. As achegas en forma de ideas, comentarios, correccións de erros tipográficos, ou mesmo cambios en parágrafos ou seccións enteiras, serán benvidas. Este repositorio ten como obxectivo achegar coñecemento especializado desde a industria de maneira que sexa útil a terceiros/as. Para isto, estamos na procura activa de revisores/as que poidan colaborar neste proceso e expresamos o noso agradecemento a aquelas persoas que xa fixeron algunha contribución ao libro. Pode atopar máis información sobre este proceso na [sección de contribucións](https://github.com/dicortazar/managing-inner-source-projects/blob/master/CONTRIBUTING.md). diff --git a/translations/gl/infrastructure/assessment.md b/translations/gl/infrastructure/assessment.md index 3a554d7..61791b4 100644 --- a/translations/gl/infrastructure/assessment.md +++ b/translations/gl/infrastructure/assessment.md @@ -1,6 +1,6 @@ # Compare canto ten de InnerSource a súa infraestructura -Limitarse a detallar a infraestrutura necesaria dentro dunha organización para aplicar InnerSource de xeito efectivo sería demasiado simplista. Esta sección ten como obxectivo enumerar as preguntas que lle debe facer ao equipo correspondente para verificar se a infraestrutura interna e ben coñecida pódese empregar no proceso InnerSource. +Limitarse a detallar a infraestrutura necesaria dentro dunha organización, para aplicar InnerSource de xeito efectivo, sería demasiado simplista. Esta sección ten como obxectivo enumerar as preguntas que lle debe facer ao equipo correspondente para verificar se a infraestrutura interna e ben coñecida pódese empregar no proceso InnerSource. O propósito principal será o de comparar a infraestrutura interna empregada nunha organización e verificar se conta co conxunto de ferramentas máis axeitado para a posta en marcha de InnerSource. En concreto, no proceso de desenvolvemento de software será necesario o uso de ferramentas específicas como o sistema de versionado, o proceso de revisión do código, o sistema de tíckets, a integración continua, o almacenamento de documentación e unha plataforma colaborativa na que compartir decisións técnicas. @@ -14,7 +14,7 @@ Logo, para cada unha de delas, teremos que verificar se están a seguir os disti | Sistema de tíckets | | | | | | | | Revisión de código | | | | | | | | CI | | | | | | | - | Wiki / Documentación | | | | | | | + | Wiki/Documentación | | | | | | | | Listaxe de tarefas pendentes | | | | | | | | Notas colaborativas | | | | | | || @@ -22,9 +22,9 @@ Logo, para cada unha de delas, teremos que verificar se están a seguir os disti | | Accesibilidade | Transparencia | Arquivable | Localizable | Fácil de minar | Dereitos de acceso | |---------------------|----------|--------------|------------|------------|------------|---------------| - | Listaxes de correo / foros| | | | | | | + | Listaxes de correo/foros| | | | | | | | Canles instantáneas | | | | | | | - | Preguntas / respostas | | | | | | || + | Preguntas/respostas | | | | | | || ## Infraestrutura de monitorización diff --git a/translations/gl/infrastructure/basics.md b/translations/gl/infrastructure/basics.md index ee2e5da..b86c785 100644 --- a/translations/gl/infrastructure/basics.md +++ b/translations/gl/infrastructure/basics.md @@ -2,28 +2,28 @@ Posto que InnerSource consiste principalmente nun cambio cultural, necesitamos ferramentas de fácil acceso ou baixa barreira de entrada. Canto máis sinxelas sexan de empregar, maior será o número de desenvolvedores/as interesados/as en traballar noutras áreas da empresa e proxectos InnerSource. -Aínda que existe un proceso de revisión de código e leva tempo aprender a facelo, tamén hai outras áreas nas que os/as desenvolvedores/as poden contribuír. Na documentación, na mera corrección de erratas da wiki colaborativa, e ata nas reunións de deseño; ou, incluso, en actividades de revisión, en proxectos do interese do/a colaborador/a ou mediante a petición de novas funcionalidades. Posto que hai diferentes xeitos de colaborar na empresa, o obxectivo de InnerSource é fomentar este tipo de accións o máximo posible, para facer saber saber ao equipo de desenvolvemento que as súas accións son valoradas. +Aínda que existe un proceso de revisión de código e leva tempo aprender a facelo, tamén hai outras áreas nas que os/as desenvolvedores/as poden contribuír. Na documentación, na mera corrección de erratas da wiki colaborativa, e ata nas reunións de deseño; ou, incluso, en actividades de revisión, en proxectos do interese do/da colaborador/a ou mediante a petición de novas funcionalidades. Posto que hai diferentes xeitos de colaborar na empresa, o obxectivo de InnerSource é fomentar este tipo de accións o máximo posible, para facerlle saber saber ao equipo de desenvolvemento que as súas accións son valoradas. Así pois, a infraestrutura estará dividida en tres áreas principais: -- En primeiro lugar, na infraestrutura do proceso de desenvolvemento que contén as ferramentas básicas para os/as desenvolvedores/as: Seleccionar as ferramentas axeitadas servirá para contar cun proceso claro que aporte confianza á comunidade. Calquera desenvolvedor/a debe seguir ese proceso co fin de evitar problemas imprevistos. Por exemplo, calquera desenvolvedor/a, incluso os/as *trusted committers*, deben afrontar un proceso de revisión cando envían un fragmento de código. Certo é que os *trusted committers* xa contan cunha reputación na comunidade que lles será de utilidade pero, aínda así, terán que pasar tamén por este proceso de revisión. Un fluxo de traballo ben definido aporta confianza a tódalas áreas empresariais. Por iso mesmo, a certeza na definición de requisitos, no proceso de desenvolvemento do software, no uso de sistemas de versionado ou de tíckets, no proceso de revisión do código e na integración continua resultará de grande axuda. -- En segundo lugar, un uso rigoroso da infraestrutura das canles de comunicación: Estas ferramentas deben ser o máis transparentes que sexa posible e tódalas reunións técnicas deben ir seguidas dun resumo que inclúa os resultados e decisións na listaxe de correo. Isto axuda na apertura de discusións técnicas, pero tamén á hora de referenciar as decisións que foron tomadas con anterioridade. Como este libro toma como exemplo grandes empresas, tamén é necesario o uso de canles de comunicación asíncronas como o IRC, moi habitual nas comunidades de software libre. Algunhas opcións máis avanzadas poderían ser [Slack](https://slack.com/intl/es-es/), ou mesmo [Mattermost](https://mattermost.com/), no caso de que a empresa prefira empregar software libre interno SaaS (polas súas siglas en inglés, software como servizo). -- En terceiro lugar, a infraestrutura da monitoración é chave á hora de aplicar InnerSource e, en xeral, de achegar unha nova metodoloxía ás empresas. Esta é unha das principais diferenzas entre as comunidades de software libre; abertas por defecto e ligadas aos aspectos chave mencionados. Con todo, a infraestrutura empregada para medir os avances nos procesos non é un dos obxectivos primordiais das comunidades de software libre que, en xeral, empregan unha metodoloxía de desenvolvemento exitosa, cada comunidade coas súas propias particularidades pero aberta por defecto. InnerSource necesita este tipo de infraestrutura, posto que tanto o equipo de desenvolvemento como os/as superiores/as de área precisan da retroalimentación para mellorar o seu rendemento. Calquera cambio no proceso de desenvolvemento de software nas grandes organizacións ou na cultura da empresa coa construción dunha comunidade deben levarse a cabo a través dun conxunto de accións e, á súa vez, será necesaria a confirmación de que esas accións están a funcionar. Para isto, a organización e máis as distintas áreas de negocio precisan dunha infraestrutura de monitoración. +- En primeiro lugar, na infraestrutura do proceso de desenvolvemento que contén as ferramentas básicas para os/as desenvolvedores/as: seleccionar as ferramentas axeitadas servirá para contar cun proceso claro que achegue confianza á comunidade. Calquera desenvolvedor/a debe seguir ese proceso co fin de evitar problemas imprevistos. Por exemplo, calquera desenvolvedor/a, incluso os/as *trusted committers*, deben afrontar un proceso de revisión cando envían un fragmento de código. Certo é que os *trusted committers* xa contan cunha reputación na comunidade que lles será de utilidade pero, aínda así, terán que pasar tamén por este proceso de revisión. Un fluxo de traballo ben definido achega confianza a todas as áreas empresariais. Por iso mesmo, a certeza na definición de requisitos, no proceso de desenvolvemento do software, no uso de sistemas de versionado ou de tíckets, no proceso de revisión do código e na integración continua resultará de grande axuda. +- En segundo lugar, un uso rigoroso da infraestrutura das canles de comunicación: estas ferramentas deben ser o máis transparentes que sexa posible e todas as reunións técnicas deben ir seguidas dun resumo que inclúa os resultados e decisións na listaxe de correo. Isto axuda na apertura de discusións técnicas, pero tamén á hora de referenciar as decisións que foron tomadas con anterioridade. Como este libro toma como exemplo grandes empresas, tamén é necesario o uso de canles de comunicación asíncronas como o IRC, moi habitual nas comunidades de software libre. Algunhas opcións máis avanzadas poderían ser [Slack](https://slack.com/intl/es-es/), ou mesmo [Mattermost](https://mattermost.com/), no caso de que a empresa prefira empregar software libre interno SaaS (polas súas siglas en inglés, software como servizo). +- En terceiro lugar, a infraestrutura da monitoración é chave á hora de aplicar InnerSource e, en xeral, de achegar unha nova metodoloxía ás empresas. Esta é unha das principais diferenzas entre as comunidades de software libre; abertas por defecto e ligadas aos aspectos chave mencionados. Con todo, a infraestrutura empregada para medir os avances nos procesos non é un dos obxectivos primordiais das comunidades de software libre que, en xeral, empregan unha metodoloxía de desenvolvemento exitosa, cada comunidade coas súas propias particularidades, pero aberta por defecto. InnerSource necesita este tipo de infraestrutura, posto que tanto o equipo de desenvolvemento como os/as superiores/as de área precisan da retroalimentación para mellorar o seu rendemento. Calquera cambio no proceso de desenvolvemento de software nas grandes organizacións ou na cultura da empresa coa construción dunha comunidade deben levarse a cabo a través dun conxunto de accións e, á súa vez, será necesaria a confirmación de que esas accións están a funcionar. Para isto, a organización e máis as distintas áreas de negocio precisan dunha infraestrutura de monitoración. ## Infraestrutura do proceso de desenvolvemento -Existen tres aspectos fundamentais a ter en conta na fase de desenvolvemento: o versionado, a revisión do código e os sistemas de integración continua. Estes deben seguir un proceso similar ao que se representa na seguinte imaxe. Se este proceso resulta familiar é porque se basea no [proceso de desenvolvemento de software libre](https://docs.openstack.org/infra/manual/developers.html), tal e como se indica na súa wiki. O seu fluxo de traballo contén as pezas básicas necesarias tamén para InnerSource. Outras comunidades empregan un enfoque similar, mais, lamentablemente, non se dispón doutra figura coa que ilustralo. En calquera caso, esta figura é nova, pois a prefería independente da infraestrutura. OpenStack usa Git, Gerrit e distintas ferramentas para este proceso, aínda que tamén outras serían posibles. Por exemplo, Linux Kernel emprega listaxes de correo para o proceso de revisión do código e a comunidade Mozilla emprega outras ferramentas. Considere a seguinte figura como unha forma xenérica de introducir información sobre distintos aspectos da revisión do código e a integración continua no proceso de desenvolvemento de software. +Existen tres aspectos fundamentais para ter en conta na fase de desenvolvemento: o versionado, a revisión do código e os sistemas de integración continua. Estes deben seguir un proceso similar ao que se representa na seguinte imaxe. Se este proceso resulta familiar é porque se basea no [proceso de desenvolvemento de software libre](https://docs.openstack.org/infra/manual/developers.html), tal e como se indica na súa wiki. O seu fluxo de traballo contén as pezas básicas necesarias tamén para InnerSource. Outras comunidades empregan un enfoque similar, mais, lamentablemente, non se dispón doutra figura coa que ilustralo. En calquera caso, esta figura é nova, pois preferíaa independente da infraestrutura. OpenStack usa Git, Gerrit e distintas ferramentas para este proceso, aínda que tamén outras serían posibles. Por exemplo, Linux Kernel emprega listaxes de correo para o proceso de revisión do código e a comunidade Mozilla emprega outras ferramentas. Considere a seguinte figura como unha forma xenérica de introducir información sobre distintos aspectos da revisión do código e a integración continua no proceso de desenvolvemento de software. -En resumo, o proceso que segue a figura é o seguinte: O/A desenvolvedor/a debe clonar o repositorio (1), facer cambios nel (2), executar algunhas probas locais (3), presentar as *pull requests* para eses cambios (4), despois realizaranse algunhas probas (5) cun resultado específico (6). Se ese resultado é negativo necesitamos pasar por unha nova versión do código e volver ao medio local (7: Proceso de revisión → Copia actualizada *upstream*). Se a CI funciona e o proceso de revisión ten unha resposta positiva, pasa de novo por CI antes de que se integre no código mestre (8). Se o proceso de revisión proporciona unha avaliación negativa, o fragmento de código volve de novo ao/á provedor/a (7: Proceso de revisión → Copia actualizada *upstream*). +En resumo, o proceso que segue a figura é o seguinte: o/a desenvolvedor/a debe clonar o repositorio (1), facer cambios nel (2), executar algunhas probas locais (3), presentar as *pull requests* para eses cambios (4), despois realizaranse algunhas probas (5) cun resultado específico (6). Se ese resultado é negativo, necesitamos pasar por unha nova versión do código e volver ao medio local (7: proceso de revisión → Copia actualizada *upstream*). Se a CI funciona e o proceso de revisión ten unha resposta positiva, pasa de novo por CI antes de que se integre no código mestre (8). Se o proceso de revisión proporciona unha avaliación negativa, o fragmento de código volve de novo ao/á provedor/a (7: proceso de revisión → Copia actualizada *upstream*). ![Proceso habitual de desenvolvemento de software](development_workflow_gl.jpg) -- **Sistema de versionado**: Emprégano os/as desenvolvedores/as para almacenar as distintas interaccións dun determinado software. Nos casos en que están distribuídos en distintas localizacións xeográficas, o sistema de versionado permite que calquera, en calquera momento, poida enviar un fragmento de código para a súa revisión. Os sistemas que facilitan o desenvolvemento *offline* son moi recomendables xa que os/as desenvolvedores/as poderán traballar de xeito local e enviar posteriormente o código. -- **Sistema de revisión do código**: Unha vez que un fragmento de código estea listo para ser enviado, debe revisalo previamente outro/a desenvolvedor/a. Isto obriga a contar cun proceso específico para o envío de ese fragmento de código. A modo de exemplo, hai varias formas nas que as comunidades de software libre revisan o código enviado; mediante o uso de ferramentas específicas, enviando o fragmento de código a unha listaxe de correo ou a través do sistema de versionado. Como un dos principais obxectivos InnerSource é manter o proceso o máis sinxelo posible, a principal recomendación é evitar canles con moito ruido (como as listaxes de correo) ou ferramentas demasiado difíciles de empregar. Tamén se recomenda utilizar ferramentas que inviten a outros/as a comezar a desenvolver un novo código fonte sen necesidade de envialo para revisar. As primeiras discusións no proceso de revisión do código axudan a producir un código mellor e a contar con mentores/as implicados/as no proceso. -- **Sistema de Integración Continua (CI)**: Esta é unha das ferramentas fundamentais no proceso de desenvolvemento. Xa son varios os ollos postos no código fonte no proceso de revisión; e coa adición dunha plataforma de integración continua, debería cubrirse calquera tipo de proba: regresión, probas unitarias, probas de usuarios/as finais etc. Idealmente, esta plataforma debería integrarse co proceso de revisión do código. Deste xeito, os/as desenvolvedores/as poden agardar pola resposta do sistema CI antes de continuar co proceso de revisión e ter a certeza de que funciona antes de calquera esforzo pola súa parte. -- **Sistema de tíckets**: Os tíckets son útiles para atraer comunidade a un proxecto InnerSource. Ademais, teñen dous propósitos específicos: a transparencia no proceso de desenvolvemento, a apertura de incidencias e poder contar cunha folla de ruta das que están por pechar. Por outra banda, proporciona unha plataforma para que usuarios/as e novos/as contribuidores/as indiquen as súas necesidades. Os tíckets permiten achegar á comunidade os proxectos InnerSource, xa que na plataforma non só se abrirán informes de erros, tamén se solicitarán novas funcionalidades. Ao mesmo tempo, favorecen a socialización, xa que a comunidade pode votar e determinar que informes consideran máis importantes. Unha información fundamental para os/as desenvolvedores/as, que poden coñecer as necesidades da comunidade e das distintas áreas de negocio. Para rematar, todo pode discutirse nos cumios de deseño nos que se definen outras follas de ruta baseadas nos requisitos dos/as usuarios/as, desenvolvedores/as e das organizacións. -- **Sistema de documentación**: A documentación agora está dispoñible para calquera membro da organización. E na súa elaboración xurdirán novos obxectivos que non se centran só nos desenvolvedores/as, senón tamén nos/as usuarios/as. De feito, esta documentación debería centrarse en varios roles, para cubrir as necesidades de todos/as. Ademais, a documentación debe ser transparente e, como tal, aberta a calquera posible cambio por parte dos membros. Isto axudará a adecuala ás necesidades dos/as usuarios/as, pero tamén ás dos demais membros da organización A ferramenta que se empregue debería facer uso de toda esta información; desde as API habituais dos/as desenvolvedores/as ata o interese por comprender o que ese fragmento de código ofrece á organización dos/as usuarios/as de alto nivel. Cómpre indicar que a documentación tamén abrangue información tan xeral como a propia misión ou o tipo de cousas que ese fragmento de código pode facer ou non. -- **Plataforma de deseño colaborativo**: Nas grandes organizacións, InnerSource é sinónimo de equipos distribuídos por distintas localizacións xeográficas. As reunións cara a cara son pouco frecuentes, mais deberíase contar con infraestruturas para superar esa barreira. Neste tipo de medios colaborativos, deberíanse almacenar as especificacións de requisitos, decisións técnicas, listaxes de tarefas pendentes e outros datos. Isto proporcionará transparencia ao proceso, pero tamén documentación e comunicación informal. Estas ferramentas deberían empregarse mesmo cando os/as desenvolvedores/as traballan en reunións cara a cara, pois deixarán rastros de actividade, lexibles por outros membros da organización. +- **Sistema de versionado**: emprégano os/as desenvolvedores/as para almacenar as distintas interaccións dun determinado software. Nos casos en que están distribuídos en distintas localizacións xeográficas, o sistema de versionado permite que calquera, en calquera momento, poida enviar un fragmento de código para a súa revisión. Os sistemas que facilitan o desenvolvemento *offline* son moi recomendables xa que os/as desenvolvedores/as poderán traballar de xeito local e enviar posteriormente o código. +- **Sistema de revisión do código**: unha vez que un fragmento de código estea listo para ser enviado, debe revisalo previamente outro/a desenvolvedor/a. Isto obriga a contar cun proceso específico para o envío dese fragmento de código. A modo de exemplo, hai varias formas nas que as comunidades de software libre revisan o código enviado; mediante o uso de ferramentas específicas, enviando o fragmento de código a unha listaxe de correo ou a través do sistema de versionado. Como un dos principais obxectivos InnerSource é manter o proceso o máis sinxelo posible, a principal recomendación é evitar canles con moito ruído (como as listaxes de correo) ou ferramentas demasiado difíciles de empregar. Tamén se recomenda utilizar ferramentas que inviten a outros/as a comezar a desenvolver un novo código fonte sen necesidade de envialo para revisar. As primeiras discusións no proceso de revisión do código axudan a producir un código mellor e a contar con mentores/as implicados/as no proceso. +- **Sistema de integración continua (CI)**: esta é unha das ferramentas fundamentais no proceso de desenvolvemento. Xa son varios os ollos postos no código fonte no proceso de revisión; e coa adición dunha plataforma de integración continua, debería cubrirse calquera tipo de proba: regresión, probas unitarias, probas de usuarios/as finais etc. Idealmente, esta plataforma debería integrarse co proceso de revisión do código. Deste xeito, os/as desenvolvedores/as poden agardar pola resposta do sistema CI antes de continuar co proceso de revisión e ter a certeza de que funciona antes de calquera esforzo pola súa parte. +- **Sistema de tíckets**: os tíckets son útiles para atraer comunidade a un proxecto InnerSource. Ademais, teñen dous propósitos específicos: a transparencia no proceso de desenvolvemento, a apertura de incidencias e poder contar cunha folla de ruta das que están por pechar. Por outra banda, proporciona unha plataforma para que usuarios/as e novos/as contribuidores/as indiquen as súas necesidades. Os tíckets permiten achegar á comunidade os proxectos InnerSource, xa que na plataforma non só se abrirán informes de erros, tamén se solicitarán novas funcionalidades. Ao mesmo tempo, favorecen a socialización, xa que a comunidade pode votar e determinar que informes consideran máis importantes. Unha información fundamental para os/as desenvolvedores/as, que poden coñecer as necesidades da comunidade e das distintas áreas de negocio. Para rematar, todo pode discutirse nos cumios de deseño nos que se definen outras follas de ruta baseadas nos requisitos dos/das usuarios/as, desenvolvedores/as e das organizacións. +- **Sistema de documentación**: a documentación agora está dispoñible para calquera membro da organización. E na súa elaboración xurdirán novos obxectivos que non se centran só nos desenvolvedores/as, senón tamén nos/nas usuarios/as. De feito, esta documentación debería centrarse en varios roles, para cubrir as necesidades de todos/as. Ademais, a documentación debe ser transparente e, como tal, aberta a calquera posible cambio por parte dos membros. Isto axudará a adecuala ás necesidades dos/das usuarios/as, pero tamén ás dos demais membros da organización A ferramenta que se empregue debería facer uso de toda esta información; desde as API habituais dos/das desenvolvedores/as ata o interese por comprender o que ese fragmento de código ofrece á organización dos/das usuarios/as de alto nivel. Cómpre indicar que a documentación tamén abrangue información tan xeral como a propia misión ou o tipo de cousas que ese fragmento de código pode facer ou non. +- **Plataforma de deseño colaborativo**: nas grandes organizacións, InnerSource é sinónimo de equipos distribuídos por distintas localizacións xeográficas. As reunións cara a cara son pouco frecuentes, mais deberíase contar con infraestruturas para superar esa barreira. Neste tipo de medios colaborativos, deberíanse almacenar as especificacións de requisitos, decisións técnicas, listaxes de tarefas pendentes e outros datos. Isto proporcionará transparencia ao proceso, pero tamén documentación e comunicación informal. Estas ferramentas deberían empregarse mesmo cando os/as desenvolvedores/as traballan en reunións cara a cara, pois deixarán rastros de actividade, lexibles por outros membros da organización. ![Proceso estendido do desenvolvemento de software habitual](development_workflow_all_gl.jpg) @@ -31,28 +31,28 @@ En resumo, o proceso que segue a figura é o seguinte: O/A desenvolvedor/a debe InnerSource implica un cambio cultural baseado na transparencia e na meritocracia. As canles de comunicación deben estar abertas dentro da organización e calquera pode publicar nelas. -Toda decisión tomada fóra das canles públicas debe ser posteriormente rexistrada nestas, xa que tódalas decisións deben poderse rastrexar e referenciar. +Toda decisión tomada fóra das canles públicas debe ser posteriormente rexistrada nestas, xa que todas as decisións deben poderse rastrexar e referenciar. -- **Listaxes de correo / Foros**: A comunicación asíncrona entre os equipos de desenvolvemento é moi eficaz. A distribución xeográfica obriga aos membros da organización a evitar as canles de comunicación directa cando sexa posible se os/as colaboradores/as viven en diferentes fusos horarios. +- **Listaxes de correo/foros**: a comunicación asíncrona entre os equipos de desenvolvemento é moi eficaz. A distribución xeográfica obriga os membros da organización a evitar as canles de comunicación directa cando sexa posible se os/as colaboradores/as viven en diferentes fusos horarios. -- **Mensaxería instantánea**: É outra canle de comunicación asíncrona, como as canles IRC empregadas habitualmente no software libre ou como Mattermost. Permite liderar discusións técnicas, almacenar a información e xuntar a tódolos/as desenvolvedores/as nunha sala virtual na que poden debater, pero tamén na que os/as usuarios/as poden entrar a buscar consello. -- **Preguntas / Respostas**: Este tipo de plataformas axuda a compartir preguntas co resto da comunidade. Usuarios/as e desenvolvedores/as poden votar polas máis interesantes, o que axudará a chamar a atención sobre cuestións de interese para a comunidade InnerSource. -- **Videoconferencia**: Unha reunión cara a cara é sempre vantaxosa e aínda máis cando se fala de cuestións técnicas. Este tipo de comunicación sincrónica é de grande utilidade para as discusións, mais obrigan aos membros do equipo a xuntarse ao mesmo tempo e na mesma sala virtual. Como pode ser que se atopen en varias zonas horarias diferentes, estas reunións serán máis difíciles de organizar que as conversas na mensaxería instantánea ou nas listaxes de correo. +- **Mensaxería instantánea**: é outra canle de comunicación asíncrona, como as canles IRC empregadas habitualmente no software libre ou como Mattermost. Permite liderar discusións técnicas, almacenar a información e xuntar a todos os desenvolvedores/as nunha sala virtual na que poden debater, pero tamén na que os/as usuarios/as poden entrar a buscar consello. +- **Preguntas/respostas**: este tipo de plataformas axuda a compartir preguntas co resto da comunidade. Usuarios/as e desenvolvedores/as poden votar polas máis interesantes, o que axudará a chamar a atención sobre cuestións de interese para a comunidade InnerSource. +- **Videoconferencia**: unha reunión cara a cara é sempre vantaxosa e aínda máis cando se fala de cuestións técnicas. Este tipo de comunicación sincrónica é de grande utilidade para as discusións, mais obriga os membros do equipo a xuntarse ao mesmo tempo e na mesma sala virtual. Como pode ser que se atopen en varias zonas horarias diferentes, estas reunións serán máis difíciles de organizar que as conversas na mensaxería instantánea ou nas listaxes de correo. ## Infraestrutura de monitoración -Esta infraestrutura é necesaria para comprender a situación actual do proceso de desenvolvemento do software e debería servir de axuda na toma de decisións. Un dos aspectos chave ao escoller ferramentas específicas é que faciliten a recuperación de datos. Isto significa que agora que calquera ferramenta é unha fonte de datos, dita fonte de datos debería proporcionar unha forma de extraelos. Esa información de datos sen procesar deberá analizarse e tratarse despois para que sexa útil. +Esta infraestrutura é necesaria para comprender a situación actual do proceso de desenvolvemento do software e debería servir de axuda na toma de decisións. Un dos aspectos chave ao escoller ferramentas específicas é que faciliten a recuperación de datos. Isto significa que agora que calquera ferramenta é unha fonte de datos, a dita fonte de datos debería proporcionar unha forma de extraelos. Esa información de datos sen procesar deberá analizarse e tratarse despois para que sexa útil. -Se amplía esta información no capítulo de métricas pero, en resumo, calquera organización que aplique InnerSource, ou calquera outra nova metodoloxía, debe ter unha forma de verificar como se está a desempeñar ese novo proceso en comparación co anterior. +Amplíase esta información no capítulo de métricas pero, en resumo, calquera organización que aplique InnerSource, ou calquera outra nova metodoloxía, debe ter unha forma de verificar como se está a desempeñar ese novo proceso en comparación co anterior. -Esta infraestrutura de monitoración tamén debería ter como resultado varios xeitos de acceder a dita información. Isto dependerá do rol que acceda á devandita información. Pois na organización todo o mundo pode ter acceso á información extraída das ferramentas de desenvolvemento e das canles de comunicación mais, se cadra, non todos/as terán interese en acceder aos datos sen procesar ou aos informes de alto nivel e trianuais enfocados aos altos cargos. +Esta infraestrutura de monitoración tamén debería ter como resultado varios xeitos de acceder á dita información. Isto dependerá do rol que acceda á devandita información, pois na organización todo o mundo pode ter acceso á información extraída das ferramentas de desenvolvemento e das canles de comunicación mais, se cadra, non todos/as terán interese en acceder aos datos sen procesar ou aos informes de alto nivel e trianuais enfocados aos altos cargos. -Para isto, a plataforma de monitoración debe proporcionar acceso aos datos sen procesar recuperados de tódalas fontes de datos, aos datos enriquecidos despois de eliminar as inconsistencias e aos resultados finais como taboleiros, KPI ou informes trianuais. De feito, ter datos procesables axudará aos membros da comunidade a aliñar eses resultados coas súas necesidades específicas. +Para isto, a plataforma de monitoración debe proporcionar acceso aos datos sen procesar recuperados de todas as fontes de datos, aos datos enriquecidos despois de eliminar as inconsistencias e aos resultados finais como taboleiros, KPI ou informes trianuais. De feito, ter datos procesables axudará os membros da comunidade a aliñar eses resultados coas súas necesidades específicas. A seguinte é unha arquitectura potencial que podería axudar no acceso a varias capas de datos, desde información sen procesar ata visualizacións detalladas. ![Infraestrutura de monitoración](monitoring_infrastructure_gl.jpg) -- **Plataforma de recuperación:** Emprega como entrada calquera das fontes de datos xa mencionadas: Os sistemas de versionado, as listaxes de correo, os tíckets, os documentos colaborativos, entre outros que deben ter algún xeito de recuperar a información que conteñen. Algunhas ferramentas poden xerar eventos que xa non se almacenan. Esta plataforma debería encargarse deses casos. Como exemplo dos *logs* temporais, se non existe unha política para manter os *logs* de Apache ou os traballos executados por unha instancia de Jenkins, non hai xeito de recuperar conxuntos de datos antigos. -- **Plataforma de enriquecemento:** Esta parte da análise de datos enfócase en limpar e preparar a información para a súa visualización. -- **Plataforma de visualización:** Pode axudar a xerar resultados precisos para rastrexar o status do proceso da metodoloxía. Mediante a visualización, esta plataforma produce gráficos procesables, pero tamén KPI ou documentos estáticos para compartir fóra da empresa. +- **Plataforma de recuperación:** emprega como entrada calquera das fontes de datos xa mencionadas: os sistemas de versionado, as listaxes de correo, os tíckets, os documentos colaborativos, entre outros que deben ter algún xeito de recuperar a información que conteñen. Algunhas ferramentas poden xerar eventos que xa non se almacenan. Esta plataforma debería encargarse deses casos. Como exemplo dos *logs* temporais, se non existe unha política para manter os *logs* de Apache ou os traballos executados por unha instancia de Jenkins, non hai xeito de recuperar conxuntos de datos antigos. +- **Plataforma de enriquecemento:** esta parte da análise de datos enfócase en limpar e preparar a información para a súa visualización. +- **Plataforma de visualización:** pode axudar a xerar resultados precisos para rastrexar o status do proceso da metodoloxía. Mediante a visualización, esta plataforma produce gráficos procesables, pero tamén KPI ou documentos estáticos para compartir fóra da empresa. diff --git a/translations/gl/infrastructure/infrastructure.md b/translations/gl/infrastructure/infrastructure.md index 761966b..1075da7 100644 --- a/translations/gl/infrastructure/infrastructure.md +++ b/translations/gl/infrastructure/infrastructure.md @@ -4,32 +4,32 @@ A infraestrutura é un dos puntos chave de InnerSource. Proporciona as ferrament O equipo de desenvolvemento, os mandos intermedios e a dirección forman parte do mesmo proceso, que require dun cambio de mentalidade para pasar a formar parte dun proceso máis achegado ao empregado no software libre. E haberán de ser capaces de aceptar as novas regras do xogo. -Xa que InnerSource fomenta a emprega dalgúns dos principios de desenvolvemento das comunidades de software libre, as comunidades InnerSource precisan dun cambio cultural no que a comunicación aberta e a transparencia no proceso de toma de decisións sexan vitais. +Xa que InnerSource fomenta o emprego dalgúns dos principios de desenvolvemento das comunidades de software libre, as comunidades InnerSource precisan dun cambio cultural no que a comunicación aberta e a transparencia no proceso de toma de decisións sexan vitais. Así pois, a infraestrutura seleccionada debe ser aberta e transparente, e facilitar aos/ás desenvolvedores/as o cumprimento dalgunhas pautas específicas como os procesos de revisión de código. Isto tamén debería axudar a evitar imprevistos. Cada contribuidor/a dunha nova infraestrutura deberá seguir as mesmas regras, mais haberá diferenzas no nivel de acceso permitido; por exemplo, entre as novas incorporacións e quen xa está a presentar *commits*. -Ademais, esta infraestrutura debe ser sinxela seguindo o enfoque KISS (polas súas siglas en inglés, *Keep It Short and Simple*, facer algo curto e doado) para diminuír a barreira de acceso de novos/as contribuidores/as. Canto máis fácil sexa o proceso, máis atractivo resultará para quen queira facer a súa primeira contribución a algunha das fontes de datos. +Ademais, esta infraestrutura debe ser sinxela seguindo o enfoque KISS (polas súas siglas en inglés, *Keep It Short and Simple*, facer algo curto e doado), para diminuír a barreira de acceso de novos/as contribuidores/as. Canto máis fácil sexa o proceso, máis atractivo resultará para quen queira facer a súa primeira contribución a algunha das fontes de datos. -Nas comunidades de software libre ocorre o mesmo; polo xeral é preciso contar cunha subscrición para algunhas das ferramentas, como poden ser as listaxes de correo ou as wikis. Unha vez obtida, xa se poden facer actualizacións das wikis ou enviar correos electrónicos. No caso do código fonte, o proceso foise burocratizando a medida que a revisión do código foi cobrando importancia. +Nas comunidades de software libre ocorre o mesmo; polo xeral, é preciso contar cunha subscrición para algunhas das ferramentas, como poden ser as listaxes de correo ou as wikis. Unha vez obtida, xa se poden facer actualizacións das wikis ou enviar correos electrónicos. No caso do código fonte, o proceso foise burocratizando á medida que a revisión do código foi cobrando importancia. Con todo, webs como [GitHub](https://github.com/) e [GitLab](https://gitlab.com/) proporcionan acceso ao código fonte, ás incidencias, ás *pull requests* e á edición das wikis mediante unha única conta. As comunidades que empregan esta infraestrutura adoitan contar cun modelo de gobernación no que calquera cambio deberá ser revisado polo/a *trusted committer*. En InnerSource existen algúns aspectos chave que cómpre ter en conta. Estes están vencellados principalmente aos atributos de accesibilidade e transparencia, mais tamén deben ser arquivables, localizables e sinxelos no uso e na minería de datos. -- **Accesibilidade**: Todas as ferramentas empregadas no proceso de desenvolvemento de software deben ser accesibles para calquera persoa da organización. Isto permite xerar confianza entre os/as desenvolvedores/as e reduce as barreiras para calquera que queira contribuír nos proxectos InnerSource. Deste xeito, tódalas contribucións son benvidas e estas poden vir de calquera. -- **Transparencia**: Co foco na autoría das distintas contribucións. Desde o mesmo proceso de envío do código, ata a corrección de erratas, todo debe quedar rexistrado, incluída a autoría de cada contribución ou cambio realizado. Isto axuda a identificar aos/ás principais contribuidores/as da comunidade, pois co tempo pasarán a conformar o equipo principal da devandita comunidade. Como non tódalas contribucións son ao código, a autoría debería axudar a comprender as doutros tipos; como a documentación, as mentorías ou a resolución de dúbidas nos foros a outros membros. Todas estas son actividades de interese nas comunidades InnerSource. +- **Accesibilidade**: todas as ferramentas empregadas no proceso de desenvolvemento de software deben ser accesibles para calquera persoa da organización. Isto permite xerar confianza entre os/as desenvolvedores/as e reduce as barreiras para calquera que queira contribuír nos proxectos InnerSource. Deste xeito, todas as contribucións son benvidas e estas poden vir de calquera. +- **Transparencia**: co foco na autoría das distintas contribucións. Desde o mesmo proceso de envío do código, ata a corrección de erratas, todo debe quedar rexistrado, incluída a autoría de cada contribución ou cambio realizado. Isto axuda a identificar aos/ás principais contribuidores/as da comunidade, pois co tempo pasarán a conformar o equipo principal da devandita comunidade. Como non todas as contribucións son ao código, a autoría debería axudar a comprender as doutros tipos; como a documentación, as mentorías ou a resolución de dúbidas nos foros a outros membros. Todas estas son actividades de interese nas comunidades InnerSource. -- **Arquivable:** As ferramentas deben xerar un rexistro no que se garde a información de accións previas. Isto será de grande axuda en relación a fragmentos concretos do código, para solucionar discusións técnicas nas canles de comunicación ou na toma de decisións durante os cumios de deseño. Tamén servirán como referencia. -- **Localizable:** A medida que máis proxectos se suman a InnerSource, a cantidade de repositorios de información crecerá de igual xeito. É importante dispor de capacidades de busca dentro da plataforma. Isto axudará a reutilizar e descubrir proxectos e contribuidores/as útiles para os nosos propósitos. Tamén será de axuda saber se existen outros proxectos que cubran as súas necesidades específicas. -- **Fácil de minar**: O conxunto de ferramentas seleccionado debería ser sinxelo de minar. Podería tratarse dunha ferramenta externa que mine calquera fonte de datos dispoñible e constrúa áreas específicas do proceso de desenvolvemento de software ou podería proporcionala a propia estrutura. Isto será útil para que a comunidade entenda onde se atopan os puntos de conxestión no proceso, mais tamén axudará a detectar posibles problemas, bloqueos ou calquera outra situación non desexada. -Tal e como se explicará máis adiante, no capítulo dedicado ás métricas, os datos desempeñan un papel fundamental na aplicación de InnerSource. Permiten comprender cara onde se dirixe todo o proceso; así como tomar decisións cando sexa necesario co obxectivo de seguir na dirección correcta. Para isto, serán tamén de importancia as ferramentas que permiten recuperar información a través dunha API (como GitHub API) ou grazas a un sistema de *log* (como a liña de comandos «git log»). +- **Arquivable:** as ferramentas deben xerar un rexistro no que se garde a información de accións previas. Isto será de grande axuda en relación con fragmentos concretos do código, para solucionar discusións técnicas nas canles de comunicación ou na toma de decisións durante os cumios de deseño. Tamén servirán como referencia. +- **Localizable:** a medida que máis proxectos se suman a InnerSource, a cantidade de repositorios de información crecerá de igual xeito. É importante dispor de capacidades de busca dentro da plataforma. Isto axudará a reutilizar e descubrir proxectos e contribuidores/as útiles para os nosos propósitos. Tamén será de axuda saber se existen outros proxectos que cubran as súas necesidades específicas. +- **Fácil de minar**: o conxunto de ferramentas seleccionado debería ser sinxelo de minar. Podería tratarse dunha ferramenta externa que mine calquera fonte de datos dispoñible e constrúa áreas específicas do proceso de desenvolvemento de software ou podería proporcionala a propia estrutura. Isto será útil para que a comunidade entenda onde se atopan os puntos de conxestión no proceso, mais tamén axudará a detectar posibles problemas, bloqueos ou calquera outra situación non desexada. +Tal e como se explicará máis adiante, no capítulo dedicado ás métricas, os datos desempeñan un papel fundamental na aplicación de InnerSource. Permiten comprender cara a onde se dirixe todo o proceso; así como tomar decisións cando sexa necesario co obxectivo de seguir na dirección correcta. Para isto, serán tamén de importancia as ferramentas que permiten recuperar información a través dunha API (como GitHub API) ou grazas a un sistema de *log* (como a liña de comandos «git log»). -- **Dereitos de acceso:** Ao existir un proceso aberto e transparente para tomar decisións que fomentan a participación, merece a pena empregar unha infraestrutura que limite o acceso a determinados roles dentro da organización. Calquera está convidado/a a participar, pero só un subconxunto de contribuidores/as terá dereito a enviar os fragmentos de código fonte ou editar as wikis de documentación. A infraestrutura debe permitir esta división de roles. Deste xeito, calquera poderá ler a documentación, pero só algunhas persoas terán permiso para escribir. +- **Dereitos de acceso:** ao existir un proceso aberto e transparente para tomar decisións que fomentan a participación, merece a pena empregar unha infraestrutura que limite o acceso a determinados roles dentro da organización. Calquera está convidado/a a participar, pero só un subconxunto de contribuidores/as terá dereito a enviar os fragmentos de código fonte ou editar as wikis de documentación. A infraestrutura debe permitir esta división de roles. Deste xeito, calquera poderá ler a documentación, pero só algunhas persoas terán permiso para escribir. -É probable que estes aspectos resulten familiares, posto que son chave á hora de poñer en marcha unha infraestrutura nos proxectos de software libre. Dous grandes libros falan desta circunstancia. [*Producing Open Source Software*](https://producingoss.com/) [Produción de software en código aberto] de Karl Fogel e [*The Art of Community*](https://www.jonobacon.com/books/artofcommunity/) [O arte da comunidade] de Jono Bacon. O primeiro céntrase nas necesidades básicas dunha infraestrutura de proxectos de software libre establecida desde cero. O segundo, pola súa parte, pon o foco en como dar sorporte específico aos fluxos de traballo coas ferramentas. Ambos proporcionan unha excelente perspectiva sobre os proxectos de software libre que é tamén parcialmente aplicable en proxectos InnerSource. +É probable que estes aspectos resulten familiares, posto que son chave á hora de poñer en marcha unha infraestrutura nos proxectos de software libre. Dous grandes libros falan desta circunstancia. [*Producing Open Source Software*](https://producingoss.com/) [Produción de software en código aberto] de Karl Fogel e [*The Art of Community*](https://www.jonobacon.com/books/artofcommunity/) [A arte da comunidade] de Jono Bacon. O primeiro céntrase nas necesidades básicas dunha infraestrutura de proxectos de software libre establecida desde cero. O segundo, pola súa parte, pon o foco en como dar sorporte específico aos fluxos de traballo coas ferramentas. Ambos proporcionan unha excelente perspectiva sobre os proxectos de software libre que é tamén parcialmente aplicable en proxectos InnerSource. -Tal e como declara Jono no seu libro: «_para elixir as ferramentas axeitadas, primeiro temos que saber que queremos conseguir. Temos que saber cal é o noso **fluxo de traballo**.»._ +Tal e como declara Jono no seu libro: «_para elixir as ferramentas axeitadas, primeiro temos que saber que queremos conseguir. Temos que saber cal é o noso **fluxo de traballo**»._ A seguinte sección céntrase nas necesidades da infraestrutura ao iniciar un proxecto InnerSource. Non existen grandes diferencias desde o punto de vista dos aspectos chave. Non obstante, temos que lidar coa infraestrutura existente, interna e, en moitos casos, de acceso restrinxido, e comprobar se a devandita infraestrutura é suficiente para os nosos propósitos e obxectivos da posta en marcha de InnerSource. -Polo tanto, haberá dúas áreas principais a considerar; en primeiro lugar, se é posible reutilizar a infraestrutura existente e, en segundo lugar, que ferramentas están dispoñibles que se axusten aos nosos requisitos chave no caso de necesitar unha nova infraestrutura. +Polo tanto, haberá dúas áreas principais que considerar; en primeiro lugar, se é posible reutilizar a infraestrutura existente e, en segundo lugar, que ferramentas están dispoñibles que se axusten aos nosos requisitos chave no caso de necesitar unha nova infraestrutura. diff --git a/translations/gl/introduction/framework.md b/translations/gl/introduction/framework.md index ffcfbde..6bcd206 100644 --- a/translations/gl/introduction/framework.md +++ b/translations/gl/introduction/framework.md @@ -2,10 +2,10 @@ Ao adoptar os procesos e principios de InnerSource, as organizacións conseguen: -- Unha xestión eficaz dos recursos, cunha mellor reutilización do código e do coñecemento e un mellor reparto dos costes entre as distintas unidades empresariais. +- Unha xestión eficaz dos recursos, cunha mellor reutilización do código e do coñecemento e unha mellor repartición dos custos entre as distintas unidades empresariais. - Innovacións ou melloras tecnolóxicas máis rápidas, xa que o código se desenvolve de forma colaborativa e transparente por medio das contribucións recibidas das distintas áreas da empresa interesadas. -- Un equipo de traballo apoderado e máis comprometido, ao permitirlles formar parta da folla de ruta de desenvolvemento da compañía. -- Maior innovación interna, que permite ao persoal propor novas ideas baseadas na tecnoloxía e coñecementos da empresa. +- Un equipo de traballo apoderado e máis comprometido, ao permitirlles formar parte da folla de ruta de desenvolvemento da compañía. +- Maior innovación interna, que lle permite ao persoal propor novas ideas baseadas na tecnoloxía e nos coñecementos da empresa. Pero calquera proxecto, incluso os de software libre, necesitará un marco de traballo que poida axudar ao persoal a definir ou dar resposta aos seguintes aspectos: @@ -25,7 +25,7 @@ O dicionario define a gobernación como: Para o software libre, a gobernación descríbese no documento «modelo de gobernación» de OSSWatch[^1]: ->O modelo de gobernación describe os roles que poden asumir os/as participantes dun proxecto e o proceso de toma de decisións dentro do mesmo. Ademais, a gobernación describe as regras básicas para a participación no proxecto e os procesos para a comunicación e o intercambio entre o equipo e a comunidade. +>O modelo de gobernación describe os roles que poden asumir os/as participantes dun proxecto e o proceso de toma de decisións dentro del. Ademais, a gobernación describe as regras básicas para a participación no proxecto e os procesos para a comunicación e o intercambio entre o equipo e a comunidade. Xeralmente, o modelo de gobernación é un documento escrito que contén: @@ -50,7 +50,7 @@ Por infraestrutura referímonos ás ferramentas empregadas polo equipo de desenv ## A colaboración como cambio cultural -Crear unha comunidade comprometida é un dos puntos chave para o éxito e sostibilidade dos proxectos de software libre. O mesmo principio aplícase aos proxectos de InnerSource. +Crear unha comunidade comprometida é un dos puntos chave para o éxito e a sostibilidade dos proxectos de software libre. O mesmo principio se aplica aos proxectos de InnerSource. A xestión da comunidade é diferente á xestión tradicional de equipos de desenvolvemento, polo que os/as xestores/as de proxectos deben adaptar as súas habilidades ao novo escenario. @@ -62,9 +62,9 @@ Nun escenario InnerSource perfecto, e baseándonos na cita de David Pink, vosted Pero non adoitamos vivir en mundos perfectos e hai varios escenarios nos que o financiamento será fundamental para os proxectos de InnerSource: -- Nos pagos en diferentes rexións xeográficas. +- Nos pagamentos en diferentes rexións xeográficas. - Cando hai traballadores/as que combinan o traballo de proxectos InnerSource con outros que non o son. -- Nos costes compartidos entre diferentes unidades de negocio cun presuposto propio. +- Nos custos compartidos entre diferentes unidades de negocio cun presuposto propio. - Proxectos desenvolvidos por unha combinación de persoal da empresa e subcontratado. De novo, o software libre proporciona algúns exemplos de como obter financiamento para os seus proxectos e organizacións como Linux Foundation, Apache Software Foundation etc.; as cales, se trasladamos os seus principios «fundacionais» ás nosas compañías, poderían servirnos de referencia. @@ -73,12 +73,12 @@ De novo, o software libre proporciona algúns exemplos de como obter financiamen Por último, pero non menos importante, se falamos de xestión, a medición convértese nunha habilidade básica para nós. Máis aló de recompilar datos, os cargos superiores necesitan entender os obxectivos da organización e como empregar os datos recollidos para chegar a alcanzalos. Tamén cómpre coidar a forma de compartir eses datos cos equipos e o que queren conseguir. ->«Recompilar datos é só o primeiro paso cara a sabedoría, pero compartir datos é o primeiro paso cara a comunidade.». Henry Lewis Gates (Profesor da Universidade de Harvard). +>«Recompilar datos é só o primeiro paso cara á sabedoría, pero compartir datos é o primeiro paso cara á comunidade.». Henry Lewis Gates (profesor da Universidade de Harvard). A medición aberta pode ser moi vantaxosa para a nosa comunidade InnerSource: -- Conciencia; permítenos entender quen somos, que estamos a facer etc. +- Conciencia; que nos permite entender quen somos, que estamos a facer etc. - Control da gobernación, posta en marcha das políticas de seguimento. - Transparencia para xerar confianza externa, como para garantir a equidade na nosa comunidade InnerSource. -[^1]: http://oss-watch.ac.uk/resources/governancemo \ No newline at end of file +[^1]: http://oss-watch.ac.uk/resources/governancemo diff --git a/translations/gl/introduction/introduction.md b/translations/gl/introduction/introduction.md index fa2bee7..2bee515 100644 --- a/translations/gl/introduction/introduction.md +++ b/translations/gl/introduction/introduction.md @@ -1,18 +1,18 @@ # Introdución -Corría o ano 2011 cando Marc Andressen escribiu o seu artigo «Why Software is eating the World»[^1] [Por que o software está a engulir o mundo]. Por aquel entón, Linux Kernel xa se puxera en marcha vinte anos atrás a través dun modelo colaborativo aberto a centos de desenvolvedores/as de diferentes compañías; algúns/unhas dos/as cales contribuían incluso no seu tempo libre. Hoxe, Linux pódese atopar en case calquera dispositivo, desde no IoT (polas súas siglas en inglés, Internet das Cousas) ou nos compoñentes de automóbiles, ata no hardware de supercomputación na nube, sen esquecer un dos sistemas operativos móbiles máis empregados no mercado. +Corría o ano 2011 cando Marc Andressen escribiu o seu artigo «Why Software is eating the World»[^1] [Por que o software está a engulir o mundo]. Por aquel entón, Linux Kernel xa se puxera en marcha vinte anos atrás a través dun modelo colaborativo aberto a centos de desenvolvedores/as de diferentes compañías; algúns/algunhas dos/das cales contribuían incluso no seu tempo libre. Hoxe, Linux pódese atopar en case calquera dispositivo, desde na IoT (polas súas siglas en inglés, Internet das Cousas) ou nos compoñentes de automóbiles, ata no hardware de supercomputación na nube, sen esquecer un dos sistemas operativos móbiles máis empregados no mercado. E Linux é só un exemplo de como un proxecto OSS (polas súas siglas en inglés, e en adiante, de código aberto ou software libre) evolucionou de non ser máis que unha mera idea ata chegar a ter múltiples aplicacións en diferentes sectores profesionais. Con cada nova aplicación, o sistema mellorou co transcurso do tempo, grazas á súa metodoloxía colaborativa de desenvolvemento baseada no software libre. -Case seis anos despois, podemos asegurar que os proxectos de software libre ou código aberto triunfaron no ecosistema de desenvolvemento das TI (Tecnoloxías da Información). Son moitas as empresas que adoptaron os procesos propios do software libre, e moitas as persoas que contribuíron; tanto desde as diferentes compañías, de xeito voluntario. +Case seis anos despois, podemos asegurar que os proxectos de software libre ou código aberto triunfaron no ecosistema de desenvolvemento das TI (tecnoloxías da información). Son moitas as empresas que adoptaron os procesos propios do software libre, e moitas as persoas que contribuíron; tanto desde as diferentes compañías, de xeito voluntario. Como conseguiu o software libre alcanzar o nivel de innovación que logrou hoxe en día? Como acadou a aceptación do mercado que observamos na actualidade? Como atinxiu tal cantidade de contribucións tanto individuais como de organizacións? -Trátase dun esforzo en equipo; no anuncio de IBM Linux[^2], John Wooden, exentrenador de baloncesto do UCLA Bruins, dicía: «O xogador que fai grande ao seu equipo é máis valioso que un gran xogador. Perderte a ti mesmo no equipo polo ben deste é o verdadeiro traballo en equipo.». +Trátase dun esforzo en equipo; no anuncio de IBM Linux[^2], John Wooden, ex adestrador de baloncesto do UCLA Bruins, dicía: «O xogador que fai grande o seu equipo é máis valioso que un gran xogador. Perderte a ti mesmo no equipo polo ben deste é o verdadeiro traballo en equipo». E se as metodoloxías de colaboración empregadas nos proxectos de software libre están a proporcionar tecnoloxía innovadora de alta calidade, grazas ás comunidades de desenvolvemento comprometidas; por que non aplicar as mesmas metodoloxías na súa compañía? Pois iso é InnerSource! -Se aínda non se decidiu a aplicar InnerSource na súa empresa, nós recomendamos que comece por ler o libro *Getting Started with InnerSource*[^3] [Como iniciarse en InnerSource] de Andy Oran. Logo diso, e se vostede decide tomar este camiño, pode confiar no presente libre para obter unha mellor comprensión dos distintos escenarios do marco de traballo e a xestión de habilidades en InnerSource. +Se aínda non se decidiu a aplicar InnerSource na súa empresa, nós recomendamos que comece por ler o libro *Getting Started with InnerSource*[^3] [Como iniciarse en InnerSource] de Andy Oran. Logo diso, e se vostede decide tomar este camiño, pode confiar no presente libro para obter unha mellor comprensión dos distintos escenarios do marco de traballo e a xestión de habilidades en InnerSource. ## Principios de InnerSource diff --git a/translations/gl/introduction/scenarios.md b/translations/gl/introduction/scenarios.md index ae3dfa3..ef64043 100644 --- a/translations/gl/introduction/scenarios.md +++ b/translations/gl/introduction/scenarios.md @@ -1,33 +1,33 @@ # Escenarios Onde se emprega a metodoloxía InnerSource? Que tipo de compañías xa a están a empregar? -No ano 2000, Tim O’Reilly definiu InnerSource como «o uso de técnicas de desenvolvemento de software libre dentro dunha corporación». Evidentemente, esta definición aplicase tanto ás compañías que desenvolven software para o seu uso propio, como para outros. +No ano 2000, Tim O’Reilly definiu InnerSource como «o uso de técnicas de desenvolvemento de software libre dentro dunha corporación». Evidentemente, esta definición aplícase tanto ás compañías que desenvolven software para o seu uso propio, como para outros. Algunhas técnicas comúns para o desenvolvemento de software libre son: -- Desenvolvemento transparente: Calquera pode revisar e contribuír. -- As *forks* son benvidas: Xeralmente, a innovación vese impulsada por novas ideas que xorden de proxectos existentes. -- Equipos diversos: Xente de tódalas partes do mundo pode contribuír, independentemente do seu xénero, educación ou raza. -- Comunicación transparente: Todo sempre por escrito e debe formar parte do arquivo, desde documentos ata as conversas, para contar cun historial no caso de precisar revisalo. +- Desenvolvemento transparente: calquera pode revisar e contribuír. +- As *forks* son benvidas: xeralmente, a innovación vese impulsada por novas ideas que xorden de proxectos existentes. +- Equipos diversos: xente de todas as partes do mundo pode contribuír, independentemente do seu xénero, educación ou raza. +- Comunicación transparente: todo sempre por escrito e debe formar parte do arquivo, desde documentos ata as conversas, para contar cun historial no caso de precisar revisalo. InnerSource, como o software libre, é idónea para fomentar a colaboración entre organizacións, posto que elimina as barreiras entre diferentes equipos, áreas empresariais e, mesmo, as posibles barreiras xeográficas. -Máis aló do perfil evidente das compañías dedicadas ao desenvolvemento de software, imos ver tamén algúns outros escenarios e situacións en que a emprega de InnerSource pode ser de utilidade. +Máis aló do perfil evidente das compañías dedicadas ao desenvolvemento de software, imos ver tamén algúns outros escenarios e situacións en que o emprego de InnerSource pode ser de utilidade. ## A onda transformadora dixital -Durante os últimos anos, moitas compañías tiveron que enfrontarse á chamada «transformación dixital», para tornar en compañías omnicanle[^1]. Na actualidade, convertéronse en grandes usuarias das TI e os pasos chave desta transformación estiveron xeralmente definidos por: +Durante os últimos anos, moitas compañías tiveron que enfrontarse á chamada «transformación dixital», para tornar en compañías omnicanle[^1]. Na actualidade, convertéronse en grandes usuarias das TI e os pasos chave desta transformación estiveron xeralmente definidos: -- A rotura os silos entre as organizacións (cambio cultural). -- A adopción de novas TI (a nube, *big data*, móbiles etc.). +- Pola rotura os silos entre as organizacións (cambio cultural). +- Pola adopción de novas TI (a nube, *big data*, móbiles etc.). A adopción destas tecnoloxías adoita significar que as compañías necesitan crear equipos DevOps competentes. Iso é, «DevOps»[^2], se cadra o segundo termo máis relevante nestes últimos anos logo da «transformación dixital». E os equipos DevOps comparten algunhas características cos equipos de desenvolvemento colaborativo do software libre. Tal e como xa fora descrito por John Willis e Damon Edwards en 2010, o «marco DevOps» correspóndese con CALMS —que (polas súas siglas en inglés) significa Cultura (de colaboración), Automatización, Axilidade, Medición e Uso compartido— e, sen dúbida, contén termos familiares para calquera desenvolvedor/a de software libre. -Estes equipos adoitan desenvolver solucións de software personalizadas mediante receitas de implementación para as súas compañías. Para as pequenas e medianas empresas (PEME), isto podería ser útil e sinxelo de xestionar. Pero que é o que acontece cando a compañía conta con varios equipos DevOps arredor do mundo? Como poden garantir que se comparta o código e o coñecemento en toda a organización? +Estes equipos adoitan desenvolver solucións de software personalizadas mediante receitas de implementación para as súas compañías. Para as pequenas e medianas empresas (peme), isto podería ser útil e sinxelo de xestionar. Pero que é o que acontece cando a compañía conta con varios equipos DevOps arredor do mundo? Como poden garantir que se comparta o código e o coñecemento en toda a organización? Xa vimos empresas que afrontaron o mesmo problema con diferentes solucións, por mor da falta de organización transparente entre organizacións, así como de metodoloxías colaborativas. @@ -39,21 +39,21 @@ Nalgúns casos, son os altos cargos corporativos ou unha unidade central da comp Noutros casos, as unidades de negocio pode que se comporten como compañías independentes. Cada unha emprega a súa propia arquitectura TI, o que remata cunha xestión dos recursos ineficiente causada pola multiplicación de tecnoloxías, desenvolvementos etc. -O desenvolvemento colaborativo en ecosistemas de software libre empregouse en máis dunha ocasión como exemplo de que estas metodoloxías permiten romper os silos entre compañías que mesmo poderían ser competidoras de mercado. Esas compañías foron capaces de compartir o seu coñecemento e recursos por unha meta común. Se a competencia pode colaborar para construír a tecnoloxía na que basear os seus negocios, por que as distintas unidades empresariais dunha corporación non poderían facer o mesmo se a súa misión é o éxito corporativo? +O desenvolvemento colaborativo en ecosistemas de software libre empregouse en máis dunha ocasión como exemplo de que estas metodoloxías permiten romper os silos entre compañías que mesmo poderían ser competidoras de mercado. Esas compañías foron capaces de compartir o seu coñecemento e recursos por unha meta común. Se a competencia pode colaborar para construír a tecnoloxía na que basear os seus negocios, por que as distintas unidades empresariais dunha corporación non poderían facer o mesmo se a súa misión é o éxito corporativo? ## A burbulla das *start-ups* -Moita xente podería argumentar sobre se estamos ou non a vivir nunha «burbulla start-up»; mais non hai dúbida de que nos atopamos rodeados de noticias sobre pequenos grupos de persoas que, mediante roldas de inversión, pasaron dun garaxe a fundar compañías multinacionais en poucos anos. +Moita xente podería argumentar sobre se estamos ou non a vivir nunha «burbulla start-up»; mais non hai dúbida de que nos atopamos rodeados de noticias sobre pequenos grupos de persoas que, mediante roldas de investimento, pasaron dun garaxe a fundar compañías multinacionais en poucos anos. -A nosa experiencia dinos que a apertura de oficinas no estranxeiro sempre é un reto, e a xestión de equipos de desenvolvemento que crecen con rapidez pode ser un problema serio. A falta de canles de comunicación efectivos e transparentes, así como de procedementos de documentación, podería dificultar a incorporación de novo persoal e diminuír o seu compromiso coa empresa. +A nosa experiencia dinos que a apertura de oficinas no estranxeiro sempre é un reto, e a xestión de equipos de desenvolvemento que crecen con rapidez pode ser un problema serio. A falta de canles de comunicación efectivas e transparentes, así como de procedementos de documentación, podería dificultar a incorporación de novo persoal e diminuír o seu compromiso coa empresa. Por outra banda, as compañías de recente creación xa naceron aproveitando as solucións informáticas existentes para proporcionar servizos omnicanle. Están acostumadas a traballar baixo a «cultura DevOps» e pode que lles resulte máis doado adoptar unha metodoloxía común a toda a organización que permita a transparencia e a colaboración. ## Falta de implicación no traballo -Se algún dos escenarios anteriores lle resulta familiar, é posible que a súa implicación no traballo non sexa moi alta. Mais non se preocupe, é bastante habitual. De acordo co World Economic Forum[^3], o 70 % dos/as traballadores/as afirma non sentirse comprometido/a co seu labor profesional. +Se algún dos escenarios anteriores lle resulta familiar, é posible que a súa implicación no traballo non sexa moi alta. Mais non se preocupe, é bastante habitual. De acordo co World Economic Forum[^3], o 70 % dos/das traballadores/as afirma non sentirse comprometido/a co seu labor profesional. -No mesmo artigo pódese ler que: «Unha investigación da Universidade de California descubriu que cando o persoal está motivado é un 31 % máis produtivo, as súas ventas crecen un 37 % e é o triple de creativo que os membros do persoal sen motivación. E, segundo un estudo do Consello de Liderazgo Corporativo levado a cabo con máis de 50 000 persoas, tamén hai un 87 % menos de probabilidades de que queiran renunciar». +No mesmo artigo pódese ler que: «Unha investigación da Universidade de California descubriu que cando o persoal está motivado é un 31 % máis produtivo, as súas vendas crecen un 37 % e é o triplo de creativo que os membros do persoal sen motivación. E, segundo un estudo do Consello de Liderazgo Corporativo levado a cabo con máis de 50 000 persoas, tamén hai un 87 % menos de probabilidades de que queiran renunciar». Towers Watson[^4] descubriu que as empresas con traballadores/as comprometidos/as producían un 19,2 % máis de ingresos operativos nun ano, pero as compañías cun menor grao de compromiso reducían os seus ingresos operativos nun 32,7 %. @@ -61,9 +61,9 @@ Foi Daniel Pink, no seu libro titulado *Drive*[^5], quen sostivo que a motivaci - Autonomía, típica dos equipos de desenvolvemento de software libre con capacidade para a autoxestión. - Mestría ou desexo de perfeccionar as habilidades de desenvolvemento para mellorar o proxecto no que están a participar. -- Propósito, que en moitos proxectos de software libre defínese como a misión. +- Propósito, que en moitos proxectos de software libre se define como a misión. -Estes aspectos son chave para a motivación dos/as desenvolvedores/as de software, xa que as súas tarefas implican habilidades cognitivas, toma de decisións, creatividade ou pensamento de orde superior. +Estes aspectos son chave para a motivación dos/das desenvolvedores/as de software, xa que as súas tarefas implican habilidades cognitivas, toma de decisións, creatividade ou pensamento de orde superior. [^1]: https://en.wikipedia.org/wiki/Omnichannel diff --git a/translations/gl/measuring/areas.md b/translations/gl/measuring/areas.md index 8075b0b..930631b 100644 --- a/translations/gl/measuring/areas.md +++ b/translations/gl/measuring/areas.md @@ -1,14 +1,14 @@ Á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. +Nos proxectos de desenvolvemento de software hai varias áreas susceptibles de análise. Mentres que as análises tradicionais se centran 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. +Basicamente, InnerSource consiste nas interaccións directas entre desenvolvedores/as, ao eliminar todos os 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. +- **Actividade**: Este factor pon o foco no básico. Todos os 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/das 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/das 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 a 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/da mentor/a, a actividade dos/das 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. +- **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 se mide 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. +- **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 diferenza máis destacable é a interacción dos/das 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. \ No newline at end of file +- **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. diff --git a/translations/gl/measuring/goals.md b/translations/gl/measuring/goals.md index 87119c1..00e3567 100644 --- a/translations/gl/measuring/goals.md +++ b/translations/gl/measuring/goals.md @@ -3,7 +3,7 @@ Obxectivos no uso das métricas Este apartado pretende proporcionar unha estratexia de métricas InnerSource que axude a entender o camiño a seguir desde o inicio do proceso ata que este atinxa toda a organización. -É importante destacar que as mesmas métricas que poden ser de utilidade para algunhas organizacións poden non ser tan útiles en tódolos contextos. De igual xeito, os proxectos de software libre non teñen por que ser semellantes entre si en termos de gobernación, licenzas, infraestrutura ou fases do proceso, aínda se todos están a producir software libre ou a traballar en comunidade. Este manual xorde cun obxectivo similar, o de pormenorizar como sería o proxecto InnerSource ideal, tendo en conta que non hai dúas organizacións que utilicen o mesmo enfoque. +É importante destacar que as mesmas métricas que poden ser de utilidade para algunhas organizacións poden non ser tan útiles en todos os contextos. De igual xeito, os proxectos de software libre non teñen por que ser semellantes entre si en termos de gobernación, licenzas, infraestrutura ou fases do proceso, aínda se todos están a producir software libre ou a traballar en comunidade. Este manual xorde cun obxectivo similar, o de pormenorizar como sería o proxecto InnerSource ideal, tendo en conta que non hai dúas organizacións que utilicen o mesmo enfoque. Por mor disto, é posible que as métricas útiles en certas situacións, como as das organizacións tecnolóxicas, non sempre sexan aplicables noutros escenarios como, por exemplo, os bancos. Isto débese a factores externos, pois incluso as regulacións legais poden variar dun país a outro. @@ -11,6 +11,6 @@ Por último, no caso de InnerSource, o uso de métricas cumpre tres propósitos - **Comprobar** o traballo en curso: permite identificar os puntos en desenvolvemento en tempo real. Se se coñece o estado do proxecto pódese saber tamén a velocidade coa que avanza un novo proceso en marcha. Isto non só favorece o paso de A a B, senón que permite probar distintos enfoques para un mesmo problema e realizar varias probas. -- **Liderar** a mellora do proceso: InnerSource supón un punto de inflexión no seu funcionamento. Precísanse indicadores que determinen se a mellora do proceso funciona correctamente, tanto traballando dun xeito moi xerarquizado como moi pouco. E cando non da resultado emprégase outro enfoque ou aplícanse outras políticas. +- **Liderar** a mellora do proceso: InnerSource supón un punto de inflexión no seu funcionamento. Precísanse indicadores que determinen se a mellora do proceso funciona correctamente, tanto traballando dun xeito moi xerarquizado como moi pouco. E cando non dá resultado emprégase outro enfoque ou aplícanse outras políticas. -- Os aspectos **motivacionais**: InnerSource supón tamén un cambio cultural, algo que non se adoita considerar sequera noutras metodoloxías. De feito, este cambio cultural é a chave de InnerSource. Pois estas son as accións que axudan a migrar dunha forma de traballo tradicional a outra máis transparente e orientada á comunidade. A guía deste proceso poden ser as métricas. En primeiro lugar, para situar aos/ás desenvolvedores/as e mostrarlles como está a funcionar o proceso mais, tamén, para desfrutar no traballo e nas competicións, retos, hackatóns e outras actividades analizables que promoven organizacións máis orientadas á comunidade. \ No newline at end of file +- Os aspectos **motivacionais**: InnerSource supón tamén un cambio cultural, algo que non se adoita considerar sequera noutras metodoloxías. De feito, este cambio cultural é a chave de InnerSource. Pois estas son as accións que axudan a migrar dunha forma de traballo tradicional a outra máis transparente e orientada á comunidade. As métricas poden ser a guía deste proceso. En primeiro lugar, para situar aos/ás desenvolvedores/as e mostrarlles como está a funcionar o proceso mais, tamén, para desfrutar no traballo e nas competicións, retos, hackatóns e outras actividades analizables que promoven organizacións máis orientadas á comunidade. diff --git a/translations/gl/measuring/gqm.md b/translations/gl/measuring/gqm.md index fdf7eee..81b97f4 100644 --- a/translations/gl/measuring/gqm.md +++ b/translations/gl/measuring/gqm.md @@ -1,27 +1,27 @@ -Enfoque GQM (Obxectivo-Pregunta-Métrica) +Enfoque GQM (obxectivo-pregunta-métrica) ============================= -O enfoque GQM é un mecanismo paraugas que permite definir e determinar as métricas do software. Isto pódese estender facilmente á súa aplicación noutros escenarios, aínda que o sistema InnerSource adáptase especialmente ben a este tipo de avaliación. +O enfoque GQM é un mecanismo paraugas que permite definir e determinar as métricas do software. Isto pódese estender facilmente á súa aplicación noutros escenarios, aínda que o sistema InnerSource se adapta especialmente ben a este tipo de avaliación. Segundo o documento orixinal: ->Calquera proceso de enxeñaría require retroalimentación e avaliación. O desenvolvemento de software é unha disciplina de enxeñaría e as medicións serven, precisamente, de retroalimentación e avaliación. A medición e os datos permiten comprender e controlar os procesos e produtos do software. Facilita a toma de decisión intelixentes e a mellora co paso do tempo. Pero o foco das medicións debe pórse nos obxectivos e modelos. É necesario establecer metas para cada un dos procesos e produtos do software e estes obxectivos deben poder medirse impulsados polos modelos axeitados.[^6] +>Calquera proceso de enxeñaría require retroalimentación e avaliación. O desenvolvemento de software é unha disciplina de enxeñaría e as medicións serven, precisamente, de retroalimentación e avaliación. A medición e os datos permiten comprender e controlar os procesos e produtos do software. Facilita a toma de decisións intelixentes e a mellora co paso do tempo. Pero o foco das medicións debe pórse nos obxectivos e modelos. É necesario establecer metas para cada un dos procesos e produtos do software e estes obxectivos deben poder medirse impulsados polos modelos axeitados.[^6] O enfoque GQM emprégase, a grande escala, no ámbito académico e na industria como método para determinar as métricas útiles para un conxunto predefinido de obxectivos. No caso específico de InnerSource, en resumo, algúns dos obxectivos máis importantes poden ser os seguintes: -- Obxectivo 1: Mellorar a calidade do código mediante CI e revisión por pares. -- Obxectivo 2: Diminuír o prazo de comercialización. -- Obxectivo 3: Permitir a innovación entre os/as desenvolvedores/as. -- Obxectivo 4: Reducir os custos de desenvolvemento e mantemento. -- Obxectivo 5: Mellorar o compromiso dentro da organización. +- Obxectivo 1: mellorar a calidade do código mediante CI e revisión por pares. +- Obxectivo 2: diminuír o prazo de comercialización. +- Obxectivo 3: permitir a innovación entre os/as desenvolvedores/as. +- Obxectivo 4: reducir os custos de desenvolvemento e mantemento. +- Obxectivo 5: mellorar o compromiso dentro da organización. Logo, para cada un dos obxectivos pode haber unha ou máis preguntas que respondan a eses obxectivos específicos. E gardarán especial relación coa fase na que se atope o proceso. Aínda que poden manterse os mesmos obxectivos cando acabamos de comezar a aplicar InnerSource dentro dunha organización e cando a metodoloxía está totalmente establecida, as preguntas relacionadas poderán ser potencialmente diferentes. Centrémonos no obxectivo número 5: mellorar o compromiso dentro da organización. Podemos comezar este proceso a partir dunha organización xerárquica na que existen silos de desenvolvedores/as e emprégase *Agile* como metodoloxía principal de desenvolvemento de software. Como punto de partida, a cuestión esencial sería comprender se as políticas específicas están funcionando realmente; como abrir a infraestrutura, permitir a discusión pública, ter reunións de deseño, así como unha longa lista de actividades que fomenten a interacción entre desenvolvedores/as. Por outra banda, nunha organización InnerSource, a cuestión sería buscar mellorar o compromiso ou, polo menos, contar cun proceso de desenvolvemento de software estable neste sentido. -**Comezar de cero**: Pregunta 1: Cantos dos/as desenvolvedores/as as recén chegados/as participan nos proxectos InnerSource? +**Comezar de cero**: Pregunta 1: Cantos dos/das desenvolvedores/as as recén chegados/as participan nos proxectos InnerSource? **Traballar nunha comunidade InnerSource**: Pregunta 1: A atracción de novos/as desenvolvedores/as mellora co paso do tempo? E esta pregunta leva á pregunta 2: Estanse a conservar estes/as novos/as desenvolvedores/as? E, por último, a pregunta 3: Canto tempo tarda un/unha desenvolvedor/a en abandonar a comunidade? @@ -29,7 +29,7 @@ E está claro que ao comezar de cero cómpre centrarse na mellora das fases inic Agora imos descubrir as métricas vinculadas a cada unha das preguntas e pode que se dea resposta a algunhas delas ao mesmo tempo. A continuación, nun caso de catro preguntas, poderiamos definir as seguintes métricas: -- P1: Cantos dos/as novos/as desenvolvedores/as atraídos/as están a participar en proxectos InnerSource? +- P1: Cantos dos/das novos/as desenvolvedores/as atraídos/as están a participar en proxectos InnerSource? - M1. Número de novos/as desenvolvedores/as. @@ -47,8 +47,8 @@ Agora imos descubrir as métricas vinculadas a cada unha das preguntas e pode qu - M4. Número de desenvolvedores/as incorporados/as no último ano, que aínda traballan no proceso. - - M5. Cantidade relativa de desenvolvedores/as retidos/as respecto do total dos/as incorporados/as no último ano. + - M5. Cantidade relativa de desenvolvedores/as retidos/as respecto do total dos/das incorporados/as no último ano. - P4: Canto tempo tarda un/unha desenvolvedor/a en abandonar a compañía? - - Mediana do tempo total de tódolos/as desenvolvedores/as desde o seu primeiro *commit* ata o último. \ No newline at end of file + - Mediana do tempo total de todos os desenvolvedores/as desde o seu primeiro *commit* ata o último. diff --git a/translations/gl/measuring/measuring.md b/translations/gl/measuring/measuring.md index 0ebcebf..49e4854 100644 --- a/translations/gl/measuring/measuring.md +++ b/translations/gl/measuring/measuring.md @@ -9,14 +9,14 @@ Posto que InnerSource é un procedemento a medio ou longo prazo, como con cada n 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. +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 os/as desenvolvedores/as a presentar a súa primeira *pull request*[^1]. Coas métricas ocorre que a xente, ás veces, pode enganalas; polo que deberían usarse só por períodos curtos de tempo para fomentar certos comportamentos, de xeito que lle 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. +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]: +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 todas as organizacións, poderíanse encadrar 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. +- Reducir o **prazo de comercialización**. Á 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. \ No newline at end of file +- 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 estaren os seus obxectivos aliñados co antedito proxecto, poden contribuír con recursos. +- E, por último, mais non menos importante, permitirlles aos/ás desenvolvedores/as traballar sobre temáticas que consideren relevantes para a organización, ou sexan do seu propio interese, faraos/as 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/das desenvolvedores/as. Ademais, isto promove unha maior **implicación** xeral dentro da organización. diff --git a/translations/gl/measuring/metrics.md b/translations/gl/measuring/metrics.md index 7f32563..580db8c 100644 --- a/translations/gl/measuring/metrics.md +++ b/translations/gl/measuring/metrics.md @@ -3,7 +3,7 @@ Exemplos de interese Aínda que, nalgúns casos, as comunidades de software libre parecen semellantes, existen peculiaridades que definen a súa idiosincrasia propia. Matices como a selección dunha ferramenta de revisión de código, poden supor un cambio significativo no xeito en que se analiza o devandito código. Isto tamén acontece nos proxectos InnerSource. -De feito, unha parte chave do proceso InnerSource é a súa infraestrutura; xa que os/as desenvolvedores/as terán que traballar dun xeito específico segundo a mesma. Por exemplo, a comunidade de OpenStack usa a aplicación Gerrit e obriga aos/ás desenvolvedores/as que queren facer un *commit* dun fragmento de código a empregala. Isto significa que a comunidade ten a certeza de que están a revisar calquera fragmento de código que se fusiona na liña de base. +De feito, unha parte chave do proceso InnerSource é a súa infraestrutura; xa que os/as desenvolvedores/as terán que traballar dun xeito específico segundo esta. Por exemplo, a comunidade de OpenStack usa a aplicación Gerrit e obriga os/as desenvolvedores/as que queren facer un *commit* dun fragmento de código a empregala. Isto significa que a comunidade ten a certeza de que están a revisar calquera fragmento de código que se fusiona na liña de base. Polo tanto, dispor da infraestrutura axeitada axuda a seguir un proceso predefinido. Non obstante, isto tamén permite ter máis en conta as métricas, ao establecer unhas fases claras do traballo que debe seguir cada desenvolvedor/a que traballe na organización. @@ -16,50 +16,50 @@ A continuación, preséntase unha listaxe de estudos de interese en empresas que Mentoría e axuda aos/ás novos/as contribuidores/as -------------------------------- -Esta análise está relacionada coa centralización do desenvolvemento e a atracción e mantemento de novos/as desenvolvedores/as. Cando se está na procura de aumentar a cantidade de participantes no ecosistema InnerSource, os *trusted committers* e os/as mentores/as serán esenciais. Ademais da súa participación no desenvolvemento, os/as *trusted commiters* están principalmente a cargo da revisión do proxecto e é moi posible que tamén das mentorías. A mentoría debería axudar a que os/as novos/as desenvolvedores/as se sintan cómodos/as traballando no proxecto e, para iso, os/as mentores/as axúdannos de varias maneiras no que concirne a entender como empregar a infraestrutura dispoñible (os repositorios Git, as listaxes de correo, o proceso de revisión de código etc.). Ademais, o/a mentor/a proporcionará indicacións sobre a documentación e as pautas para a escritura do código e o seu rol servirá para axudar a comprender como contribuír a esa comunidade en concreto. Por último, este rol tamén se encargará de revisar os fragmentos de código das primeiras *pull requests* dos/as novos/as contribuidores/as, e de asesoralos/as acerca da necesidade dos posibles cambios solicitados e sobre as potenciais peticións de actualizacións para ese fragmento de código. +Esta análise está relacionada coa centralización do desenvolvemento e a atracción e o mantemento de novos/as desenvolvedores/as. Cando se está na procura de aumentar a cantidade de participantes no ecosistema InnerSource, os *trusted committers* e os/as mentores/as serán esenciais. Ademais da súa participación no desenvolvemento, os/as *trusted commiters* están principalmente a cargo da revisión do proxecto e é moi posible que tamén das mentorías. A mentoría debería axudar a que os/as novos/as desenvolvedores/as se sintan cómodos/as traballando no proxecto e, para iso, os/as mentores/as axúdannos de varias maneiras no que concirne a entender como empregar a infraestrutura dispoñible (os repositorios Git, as listaxes de correo, o proceso de revisión de código etc.). Ademais, o/a mentor/a proporcionará indicacións sobre a documentación e as pautas para a escritura do código e o seu rol servirá para axudar a comprender como contribuír a esa comunidade en concreto. Por último, este rol tamén se encargará de revisar os fragmentos de código das primeiras *pull requests* dos/das novos/as contribuidores/as, e de asesoralos/as acerca da necesidade dos posibles cambios solicitados e sobre as potenciais peticións de actualizacións para ese fragmento de código. -Pódese facer un seguimento do proceso e rexistrar toda esta información. Pois como InnerSource está a fomentar unha infraestrutura transparente para tratar tódalas actividades relacionadas co desenvolvemento do produto, as discusións están abertas a calquera persoa interesada. Polo tanto, a análise de mentorías axuda a comprender quen son os/as mentores/as e se están a axudar a reducir o tempo do proceso de revisión, ao proporcionar instrucións claras sobre como proceder e información sobre o número de novos/as contribuidores/as que están a chegar á comunidade. Estes son só algúns exemplos de como realizar un seguimento potencial da actividade dos/as mentores/as e do impacto da mesma nunha empresa que está a traballar no marco de InnerSource. +Pódese facer un seguimento do proceso e rexistrar toda esta información. Pois como InnerSource está a fomentar unha infraestrutura transparente para tratar todas as actividades relacionadas co desenvolvemento do produto, as discusións están abertas a calquera persoa interesada. Polo tanto, a análise de mentorías axuda a comprender quen son os/as mentores/as e se están a axudar a reducir o tempo do proceso de revisión, ao proporcionar instrucións claras sobre como proceder e información sobre o número de novos/as contribuidores/as que están a chegar á comunidade. Estes son só algúns exemplos de como realizar un seguimento potencial da actividade dos/das mentores/as e do seu impacto nunha empresa que está a traballar no marco de InnerSource. -Isto debe compararse con etapas anteriores do proceso de desenvolvemento de software e mellorar os puntos de conxestión da actividade cando sexa necesario. Un posible problema común nas comunidades de software libre, e tamén dentro das empresas, é unha alta carga de traballo dos/as mentores/as e revisores/as principais. Posto que, nalgúns momentos, estes/as son o punto de conxestión no proceso de revisión do código, é necesario incorporar máis revisores/as principais á comunidade. +Isto debe compararse con etapas anteriores do proceso de desenvolvemento de software e mellorar os puntos de conxestión da actividade cando sexa necesario. Un posible problema común nas comunidades de software libre, e tamén dentro das empresas, é unha alta carga de traballo dos mentores/as e revisores/as principais. Posto que, nalgúns momentos, estes/as son o punto de conxestión no proceso de revisión do código, é necesario incorporar máis revisores/as principais á comunidade. -Tamén é interesante fomentar a creación do rol dos/as mentores/as aínda que non sexan os/as revisores/as principais da comunidade, xa que poden aportar información útil aos/ás novos/as contribuidores/as. Este rol tamén pode ser visto como un/unha xestor/a da comunidade que facilita o camiño daqueles/as interesados/as en facer contribucións. +Tamén é interesante fomentar a creación do rol dos mentores/as aínda que non sexan os/as revisores/as principais da comunidade, xa que poden achegarlles información útil aos/ás novos/as contribuidores/as. Este rol tamén pode ser visto como un/unha xestor/a da comunidade que facilita o camiño daqueles/as interesados/as en facer contribucións. O ciclo de desenvolvemento ----------------- -O estudo do ciclo de desenvolvemento está relacionado coa redución do prazo de comercialización. Isto podería entenderse como un xeito de determinar se as políticas aplicadas están realmente a diminuír o tempo total de desenvolvemento dunha nova función ou de corrección dun erro, entre outras accións. O obxectivo desta análise consiste en comprender o tempo total que abrangue o proceso que vai desde a versión inicial do/a usuario/a ata a inclusión dos cambios no repositorio de código fonte. +O estudo do ciclo de desenvolvemento está relacionado coa redución do prazo de comercialización. Isto podería entenderse como un xeito de determinar se as políticas aplicadas están realmente a diminuír o tempo total de desenvolvemento dunha nova función ou de corrección dun erro, entre outras accións. O obxectivo desta análise consiste en comprender o tempo total que abrangue o proceso que vai desde a versión inicial do/da usuario/a ata a inclusión dos cambios no repositorio de código fonte. -Isto é importante para entender o tempo que adoita tardarse en implantar un novo requisito logo da fase de deseño, posta en marcha, proceso de revisión do código, integración continua e prazo de integración. Como aquí interveñen os SLA (polas súas siglas en inglés, Acordo de Nivel de Servizo), pódese calcular canto tarda a petición dunha nova funcionalidade en formar parte do código fonte e, despois, o tempo para activala ou corrixila en produción. +Isto é importante para entender o tempo que adoita tardarse en implantar un novo requisito logo da fase de deseño, posta en marcha, proceso de revisión do código, integración continua e prazo de integración. Como aquí interveñen os SLA (polas súas siglas en inglés, acordo de nivel de servizo), pódese calcular canto tarda a petición dunha nova funcionalidade en formar parte do código fonte e, despois, o tempo para activala ou corrixila en produción. -Algúns exemplos desta análise poderían ser acerca da rapidez coa que se executan os requisitos —por exemplo, se cadra 50 % ou 80 % deles—, e sobre a capacidade de reducir aínda máis a súa duración por parte da comunidade a medida que pasa o tempo. Tamén é posible dividir este proceso en varias fases: a *feature request*, as tarefas pendentes, o proceso de desenvolvemento, o proceso de revisión de código, a integración continua, a integración no código mestre, máis integración continua e, finalmente, a posterior activación da funcionalidade para o/a cliente/a. E, grazas a esta división en fases, será posible buscar puntos de conxestión. +Algúns exemplos desta análise poderían ser acerca da rapidez coa que se executan os requisitos —por exemplo, se cadra 50 % ou 80 % deles—, e sobre a capacidade de reducir aínda máis a súa duración por parte da comunidade á medida que pasa o tempo. Tamén é posible dividir este proceso en varias fases: a *feature request*, as tarefas pendentes, o proceso de desenvolvemento, o proceso de revisión de código, a integración continua, a integración no código mestre, máis integración continua e, finalmente, a posterior activación da funcionalidade para o/a cliente/a. E, grazas a esta división en fases, será posible buscar puntos de conxestión. -Como exemplo, consideremos a fase de revisión do código. Hai dous roles que xogan un papel importante nela: o/a provedor/a e o/a revisor/a e, o tempo que ambos/as dedican ás súas tarefas específicas, pódese dividir. Deste xeito, existirá un tempo de espera para a acción do/a revisor/a (xeralmente, a propia revisión do código) e un tempo de espera para a acción do/a provedor/a (xeralmente, modificacións da *pull requests* solicitadas polo/a revisor/a). +Como exemplo, consideremos a fase de revisión do código. Hai dous roles que xogan un papel importante nela: o/a provedor/a e o/a revisor/a e, o tempo que ambos/as dedican ás súas tarefas específicas, pódese dividir. Deste xeito, existirá un tempo de espera para a acción do/da revisor/a (xeralmente, a propia revisión do código) e un tempo de espera para a acción do/da provedor/a (xeralmente, modificacións da *pull requests* solicitadas polo/a revisor/a). -Se se da o caso de que o tempo de espera para a acción dun/dunha provedor/a é demasiado elevado, é posible que a comunidade deba levar a cabo accións formativas cos/coas novos/a participantes ou desenvolvedores/as. Mais se é o tempo de espera para a acción do/a revisor/a o que aumenta co tempo, é necesario que a comunidade considere levar a cabo accións que axuden a reducilo. Por exemplo, poden escoller outros/as desenvolvedores/as para que sexan revisores/as de código, ou ser máis precisos/as coas peticións solicitadas aos/ás provedores/as. +Se se dá o caso de que o tempo de espera para a acción dun/dunha provedor/a é demasiado elevado, é posible que a comunidade deba levar a cabo accións formativas cos/coas novos/a participantes ou desenvolvedores/as. Mais se é o tempo de espera para a acción do/da revisor/a o que aumenta co tempo, é necesario que a comunidade considere levar a cabo accións que axuden a reducilo. Por exemplo, poden escoller outros/as desenvolvedores/as para que sexan revisores/as de código, ou seren máis precisos/as coas peticións solicitadas aos/ás provedores/as. Funil de contribuidores/as ----------------- Esta análise céntrase en comprender canto tarda un/unha contribuidor/a da comunidade InnerSource en converterse en desenvolvedor/a ou revisor/a principal. As comunidades poden verse como cebolas que teñen varias capas. Por un lado, atoparemos persoas que só actúan como usuario/a final e, por outra banda, os/as que cando atopan un *bug*, deciden comunicarllo á comunidade. Tamén haberá usuarios/as que ademais de informar do *bug* e ademais envían unha *pull request*. E, finalmente, están os/as membros do equipo de desenvolvemento que poden participar na comunidade de xeito ocasional, habitual ou, mesmo, como desenvolvedor/a principal. -A proporción habitual destas comunidades, polo menos en software libre, está a seguir unha distribución na que o 80 % da actividade realízaa un 20 % dos/as desenvolvedores/as. Prevese que as comunidades InnerSource sigan a mesma distribución, ao ser tamén o desenvolvemento dentro da organización un proceso aberto. Deste xeito, tamén contará cos roles mencionados, desde os/as usuarios/as finais puros/as ata os/as desenvolvedores/as principais. +A proporción habitual destas comunidades, polo menos en software libre, está a seguir unha distribución na que o 80 % da actividade a realiza un 20 % dos/das desenvolvedores/as. Prevese que as comunidades InnerSource sigan a mesma distribución, ao ser tamén o desenvolvemento dentro da organización un proceso aberto. Deste xeito, tamén contará cos roles mencionados, desde os/as usuarios/as finais puros/as ata os/as desenvolvedores/as principais. Volvendo á análise, o estudo do funil de contribuidores/as ten como obxectivo comprender canto tempo lle leva a un desenvolvedor/a converterse en colaborador/a dun proxecto InnerSource; desde a primeira vez que solicita unha nova funcionalidade nunha listaxe de correo ou xera un informe de erros, ata o momento en que fai o seu primeiro *commit* ou a súa primeira revisión dun fragmento de código. -O obxectivo desta análise é, de feito, pór en contexto a eficacia do/a xestor/a da comunidade, dos/as mentores/as e doutros roles involucrados. +O obxectivo desta análise é, de feito, pór en contexto a eficacia do/da xestor/a da comunidade, dos/das mentores/as e doutros roles involucrados. Isto tamén axuda a comprender que porcentaxe de colaboradores/as ou usuarios/as, finalmente, contribúen cun *commit* dun fragmento de código, e que porcentaxe chega a converterse en *trusted committer* ao cabo dun tempo. Compromiso ----------------- -Nesta sección abórdase a atracción e retención de novos membros. A medida que o método InnerSource evoluciona nunha organización, espérase que os/as desenvolvedores/as traballen noutros proxectos que non estean directamente relacionados coas súas áreas de negocio. Aqueles/as que participen por primeira vez, conformarán a taxa de atracción da comunidade. Pola contra, os/as que aínda estean a facer contribucións nese proxecto, conforman a taxa de retención. Ademais, os/as que deixen a comunidade despois dun tempo, formarán parte da taxa dos/as desenvolvedores/as que non foron retidos. +Nesta sección abórdase a atracción e retención de novos membros. Á medida que o método InnerSource evoluciona nunha organización, espérase que os/as desenvolvedores/as traballen noutros proxectos que non estean directamente relacionados coas súas áreas de negocio. Aqueles/as que participen por primeira vez, conformarán a taxa de atracción da comunidade. Pola contra, os/as que aínda estean a facer contribucións nese proxecto, conforman a taxa de retención. Ademais, os/as que deixen a comunidade despois dun tempo, formarán parte da taxa dos/das desenvolvedores/as que non foron retidos. -O obxectivo ideal de calquera proxecto é conseguir atraer á maior cantidade posible de desenvolvedores/as e mantelos/as para que non abandonen a comunidade. Pero isto non sempre acontece. A rotación é algo inevitable e os proxectos, as áreas de negocio e as organizacións teñen que lidar con ela. Con todo, é posible medir o compromiso da comunidade e o xeito no que determinadas políticas axudan máis que outras a atraer e reter a un maior número de desenvolvedores/as. +O obxectivo ideal de calquera proxecto é conseguir atraer a maior cantidade posible de desenvolvedores/as e mantelos/as para que non abandonen a comunidade. Pero isto non sempre acontece. A rotación é algo inevitable e os proxectos, as áreas de negocio e as organizacións teñen que lidar con ela. Con todo, é posible medir o compromiso da comunidade e o xeito no que determinadas políticas axudan máis que outras a atraer e reter un maior número de desenvolvedores/as. Esa taxa de atracción e retención podería verse afectada por outras variables como a linguaxe de programación, as persoas que traballan no proxecto ou as retribucións, entre outras. -Algunhas das preguntas específicas nesta análise gardan relación co grao de implicación ou sentimento de pertenza dos/as desenvolvedores/as na súa unidade de negocio ou na compañía, e permitirán pulir o proceso para atraer e manter aos/ás mellores desenvolvedores/as. En que medida o proxecto ou comunidade está a conseguir manter aos/ás desenvolvedores/as? A que distancia se atopa esta comunidade da comunidade co mellor desempeño? Coñécense as razóns polas que os/as anteriores desenvolvedores/as abandonaron a comunidade? E, se é así, estase a levar a cabo algunha acción para facerlles saber a súa importancia na mesma? +Algunhas das preguntas específicas nesta análise gardan relación co grao de implicación ou sentimento de pertenza dos/das desenvolvedores/as na súa unidade de negocio ou na compañía, e permitirán pulir o proceso para atraer e manter os/as mellores desenvolvedores/as. En que medida o proxecto ou comunidade está a conseguir manter as/as desenvolvedores/as? A que distancia se atopa esta comunidade da comunidade co mellor desempeño? Coñécense as razóns polas que os/as anteriores desenvolvedores/as abandonaron a comunidade? E, se é así, estase a levar a cabo algunha acción para facerlles saber a súa importancia nela? Cantas máis sexan as posibles métricas, con máis información sobre o tema analizado contará o proxecto. E isto tamén podería verse como unha forma de medir a neutralidade e a transparencia non só no proxecto, senón entre varias áreas empresariais e na empresa en xeral. @@ -73,11 +73,11 @@ Os silos tamén son consecuencia das empresas xerarquizadas onde só os altos ca Difundir os coñecementos ----------------- -A medida que se eliminan os silos e a estrutura se volve menos xerarquizada, os coñecementos deben compartirse con tódolos/as integrantes da empresa. Os/as desenvolvedores/as chegan a un novo proxecto, fan contribucións e adquiren coñecementos sobre como avanzar, sobre a misión do devandito proxecto, a súa idiosincrasia e infraestrutura etc. Esas interaccións pódense medir grazas ao rastro que deixan nas distintas fontes de información. +A medida que se eliminan os silos e a estrutura se volve menos xerarquizada, os coñecementos deben compartirse con todos os integrantes da empresa. Os/as desenvolvedores/as chegan a un novo proxecto, fan contribucións e adquiren coñecementos sobre como avanzar, sobre a misión do devandito proxecto, a súa idiosincrasia e infraestrutura etc. Esas interaccións pódense medir grazas ao rastro que deixan nas distintas fontes de información. Por exemplo, os/as desenvolvedores/as que traballan no mesmo arquivo poderán estar máis ou menos familiarizados/as coa biblioteca, mais contan cun vínculo entre eles/as; ese fragmento de código fonte. Do mesmo xeito, os/as que toman o rol de mentores/as e aqueles/as aos/ás que mentorizan tamén están a construír a súa propia rede social específica. -Algunhas métricas concretas de interese son as relacionadas coa análise de como o coñecemento chega a ser algo xeralizado, a medida que as persoas contribúen en distintos repositorios de información. Como exemplo, pódese empregar a territorialidade para comprender o illamento dos/as desenvolvedores/as mentres traballan. De feito, cando existen áreas do código que son altamente territoriais, pode querer dicir que ninguén está a prestar axuda nesa área de código. Así, cómpre entender os motivos do *código spaghetti*, ou das funcionalidades complexas que requiren unha comprensión profunda do que se está a desenvolver etc. +Algunhas métricas concretas de interese son as relacionadas coa análise de como o coñecemento chega a ser algo xeralizado, á medida que as persoas contribúen en distintos repositorios de información. Como exemplo, pódese empregar a territorialidade para comprender o illamento dos/das desenvolvedores/as mentres traballan. De feito, cando existen áreas do código que son altamente territoriais, pode querer dicir que ninguén está a prestar axuda nesa área de código. Así, cómpre entender os motivos do *código spaghetti*, ou das funcionalidades complexas que requiren unha comprensión profunda do que se está a desenvolver etc. Outras maneiras de medir a fluidez do coñecemento na comunidade consisten en analizar *o código orfo* que deixan os/as desenvolvedores/as que abandonan o proxecto. Cabe preguntarse se hai alguén que manteña esa parte do código, se hai outras persoas ao cargo que xa participaran niso con anterioridade, e cales son as áreas de coñecemento habituais das que se encargan os/as revisores/as principais. @@ -86,7 +86,7 @@ Finalmente, métricas habituais, como a intermediación, poden axudar a facerlle Cambio cultural dos mandos intermedios ----------------- -Os silos están relacionados cos mandos medios, pois estes/as son os/as encargados/as de filtrar e controlar que os equipos de desenvolvedores/as acaden uns prazos e obxectivos específicos. Non obstante, non se fomentan as actividades entre equipos e a falta de dinamismo afecta a outras áreas de innovación da compañía, xa que as persoas tenden a centrarse soamente no traballo polo que cobran e non polo traballo dos/as demais. +Os silos están relacionados cos mandos medios, pois estes/as son os/as encargados/as de filtrar e controlar que os equipos de desenvolvedores/as acaden uns prazos e obxectivos específicos. Non obstante, non se fomentan as actividades entre equipos e a falta de dinamismo afecta outras áreas de innovación da compañía, xa que as persoas tenden a centrarse soamente no traballo polo que cobran e non no traballo dos/das demais. Adicionalmente, este rol nas empresas vén dado pola súa disposición xerárquica, e así é como se espera que funcione cos/coas demais traballadores/as que tenten escalar na xerarquía. @@ -95,12 +95,12 @@ Porén, InnerSource ten como obxectivo fomentar as relacións entre desenvolvedo Escalabilidade ----------------- -Permitir as relacións D2D desde calquera lugar da empresa, conduce á escalabilidade pura. Os mandos intermedios tenden a reconverterse en xestores/as da comunidade que fomentan ese tipo de comportamentos, atraen hackatóns á súa empresa e convidan a persoas externas a participar nos seus proxectos, do mesmo xeito que tamén eles/as participan nos de outros/as. +Permitir as relacións D2D desde calquera lugar da empresa, conduce á escalabilidade pura. Os mandos intermedios tenden a reconverterse en xestores/as da comunidade que fomentan ese tipo de comportamentos, atraen hackatóns á súa empresa e convidan persoas externas a participar nos seus proxectos, do mesmo xeito que tamén eles/as participan nos doutros. -Conservar aos/ás mellores desenvolvedores/as +Conservar os/as mellores desenvolvedores/as ----------------- -Contar coa liberdade e confianza da empresa na que traballan os/as desenvolvedores/as é un bo complemento para sentirse ben no traballo. De feito, un dos principais obxectivos de calquera organización é manter aos/ás seus/súas mellores desenvolvedores/as, pero tamén atraer aos/ás mellores do mundo. Este cambio cultural e no modo de traballar permite ter aos/ás desenvolvedores/as aliñados/as coa estratexia xeral da empresa. +Contar coa liberdade e confianza da empresa na que traballan os/as desenvolvedores/as é un bo complemento para sentirse ben no traballo. De feito, un dos principais obxectivos de calquera organización é manter os/as seus/súas mellores desenvolvedores/as, pero tamén atraer os/as mellores do mundo. Este cambio cultural e no modo de traballar permite ter os/as desenvolvedores/as aliñados/as coa estratexia xeral da empresa. Así pois, algúns dos obxectivos iniciais que cumprir dentro da empresa son: eliminar os silos, reconverter aos mandos intermedios, escalar o desenvolvemento e contar cun gran equipo. Seguindo o enfoque GQM, isto permítenos traballar nas cuestións específicas das que se busque resposta. @@ -109,42 +109,42 @@ Permitir unha innovación en detalle Segundo o enfoque GQM, cada obxectivo pode presentar varias preguntas e cada pregunta pode responderse cunha ou máis métricas que axuden a comprender unha situación específica. Tamén se dá por feito que a organización xa aplicou InnerSource e quere verificar se o proceso conduce a unha mellora real con varios obxectivos concretos. -**Obxectivo: Permitir a innovación entre os/as desenvolvedores/as** +**Obxectivo: permitir a innovación entre os/as desenvolvedores/as** - Pregunta: Como interactúan os/as desenvolvedores/as con outras áreas da empresa? - - Fundamento: A innovación é o resultado de mesturar varios puntos de vista cando se resolven problemas. Os/as desenvolvedores/as doutras disciplinas ou áreas de negocio formularán ideas que poden fomentar ese proceso de innovación. + - Fundamento: a innovación é o resultado de mesturar varios puntos de vista cando se resolven problemas. Os/as desenvolvedores/as doutras disciplinas ou áreas de negocio formularán ideas que poden fomentar ese proceso de innovación. - - Métrica: Número de desenvolvedores/as atraídos/as aos distintos proxectos InnerSource. + - Métrica: número de desenvolvedores/as atraídos/as aos distintos proxectos InnerSource. - - Métrica: Número de desenvolvedores/as retidos/as nos distintos proxectos InnerSource. + - Métrica: número de desenvolvedores/as retidos/as nos distintos proxectos InnerSource. - - Métrica: Número de contribucións (*commits*, edicións das wiki, correos electrónicos e outras métricas sobre os/as contribuidores/as atraídos/as). + - Métrica: número de contribucións (*commits*, edicións das wiki, correos electrónicos e outras métricas sobre os/as contribuidores/as atraídos/as). - - Métrica: Número de *trusted committers*. + - Métrica: número de *trusted committers*. - Pregunta: Como se están a crear os novos proxectos dentro da empresa? - - Fundamento: A creación de novos proxectos é o resultado de permitir que os/as desenvolvedores/as se sintan cómodos/as dentro da organización. Os novos proxectos son a consecuencia de facerlles saber que poden aportar ideas á actividade principal da empresa. + - Fundamento: a creación de novos proxectos é o resultado de permitir que os/as desenvolvedores/as se sintan cómodos/as dentro da organización. Os novos proxectos son a consecuencia de facerlles saber que poden achegar ideas á actividade principal da empresa. - - Métrica: Número de novos proxectos na plataforma. + - Métrica: número de novos proxectos na plataforma. - - Métrica: Número de distintos/as desenvolvedores/as que crean novos proxectos. + - Métrica: número de distintos/as desenvolvedores/as que crean novos proxectos. - - Métrica: Número de desenvolvedores/as activos/as nos últimos proxectos. + - Métrica: número de desenvolvedores/as activos/as nos últimos proxectos. - Pregunta: Están mellorando o soporte na empresa os proxectos de incubación? - - Fundamento: Como a incubación de proxectos necesita un certo proceso ata a súa maduración, relaciónase directamente coa actividade no apartado sobre incubación do programa InnerSource. + - Fundamento: como a incubación de proxectos necesita un certo proceso ata a súa maduración, relaciónase directamente coa actividade no apartado sobre incubación do programa InnerSource. - - Métrica: Número de novos proxectos en incubación. + - Métrica: número de novos proxectos en incubación. - - Métrica: Número de proxectos incubados que se converteron en proxectos oficiais. + - Métrica: número de proxectos incubados que se converteron en proxectos oficiais. - Pregunta: Que novas tecnoloxías se introduciron na empresa? - - Fundamento: É representativo o caso de PayPal[^7], que adoitaba traballar nunha linguaxe de programación específica. Mais a innovación chegou da man de novos/as desenvolvedores/as que coa introdución de JS conseguiron aforrar centos de liñas de código. + - Fundamento: é representativo o caso de PayPal[^7], que adoitaba traballar nunha linguaxe de programación específica. Mais a innovación chegou da man de novos/as desenvolvedores/as que coa introdución de JS conseguiron aforrar centos de liñas de código. - - Métrica: Número de novas linguaxes de programación. + - Métrica: número de novas linguaxes de programación. - - Métrica: Número de novas bibliotecas de software libre creadas no desenvolvemento. \ No newline at end of file + - Métrica: número de novas bibliotecas de software libre creadas no desenvolvemento. diff --git a/translations/gl/measuring/references.md b/translations/gl/measuring/references.md index 646b343..7c3ab69 100644 --- a/translations/gl/measuring/references.md +++ b/translations/gl/measuring/references.md @@ -3,9 +3,9 @@ Referencias[^1][^2][^3][^4][^5][^6][^7] [^1]: Unha *pull request* é a acción de presentar un fragmento de código para a súa revisión. Este termo ven das comunidades de software libre e xurdiu do traballo colaborativo en GitHub. -[^2]: Modelado e medición de *software*: O paradigma métrico da cuestión meta. Victor R. Basili. +[^2]: Modelaxe e medición de *software*: o paradigma métrico da cuestión meta. Victor R. Basili. -[^3]: Existen moitas charlas e, mesmo, manuais en Internet que mostran os obxectivos de InnerSource. A listaxe proposta dos principais non pretende ser exhaustiva, senón unha introdución ao contexto InnerSource. E podería considerarse un resumo das seguintes charlas e manuais: *Getting Started with InnerSource. Keys to collaboration and productivity inside your company* [Iniciación a InnerSource. Claves para a colaboración e a produtividade dentro da súa empresa] de Andy Oram; *Inner Sourcing. Enterprise Lessons Learned from the Open Source Community* [InnerSource: Leccións empresariais aprendidas da comunidade de software libre] de Jim Jagielski; e *Community Development Practices in Corporate IT. InnerSource Fundamentals* [Prácticas de desenvolvemento comunitario en TI. Fundamentos de InnerSource] de Guy Martin e Andrew Aitken. +[^3]: Existen moitas charlas e, mesmo, manuais na internet que mostran os obxectivos de InnerSource. A listaxe proposta dos principais non pretende ser exhaustiva, senón unha introdución ao contexto InnerSource. E podería considerarse un resumo das seguintes charlas e manuais: *Getting Started with InnerSource. Keys to collaboration and productivity inside your company* [Iniciación a InnerSource. Claves para a colaboración e a produtividade dentro da súa empresa] de Andy Oram; *Inner Sourcing. Enterprise Lessons Learned from the Open Source Community* [InnerSource: Leccións empresariais aprendidas da comunidade de software libre] de Jim Jagielski; e *Community Development Practices in Corporate IT. InnerSource Fundamentals* [Prácticas de desenvolvemento comunitario en TI. Fundamentos de InnerSource] de Guy Martin e Andrew Aitken. [^4]: *Best Kept Secrets of Peer Code Review* [Os secredos mellor gardados da revisión por pares], escrito por Jason Cohen, Steven Teleki, Eric Brown et al. diff --git a/translations/gl/measuring/strategy.md b/translations/gl/measuring/strategy.md index 7469ff3..46af5fb 100644 --- a/translations/gl/measuring/strategy.md +++ b/translations/gl/measuring/strategy.md @@ -1,7 +1,7 @@ Estratexia ======== -Mesmo ao tomar e medir datos, as persoas seguen sendo un compoñente chave da estratexia de aplicación das métricas e no impulso de cambio baseado neses datos. As métricas que levan a unha mellora do proceso ou a un cambio motivacional son necesarias para ser entendidas e aprobadas por aqueles dos que se vai facer un seguimento. E non hai que medilo todo, senón centrarse en áreas específicas do traballo dos/as desenvolvedores/as que axuden a entender se está a funcionar. +Mesmo ao tomar e medir datos, as persoas seguen sendo un compoñente chave da estratexia de aplicación das métricas e no impulso de cambio baseado neses datos. As métricas que levan a unha mellora do proceso ou a un cambio motivacional son necesarias para seren entendidas e aprobadas por aqueles dos que se vai facer un seguimento. E non hai que medilo todo, senón centrarse en áreas específicas do traballo dos/das desenvolvedores/as que axuden a entender se está a funcionar. Ademais disto, a estratexia de métricas está directamente ligada ao propósito xeral da actualización do proceso. De cando en vez, as organizacións actualizan os seus obxectivos e eses obxectivos obrigan a facer un cambio nas métricas empregadas para analizar canto lle falta á organización para acadalos. @@ -11,24 +11,24 @@ Desenvolvedores/as e mandos intermedios deben formar parte do proceso para compr Para o uso de métricas en InnerSource, xa definiramos os seguintes propósitos: -- Concienciación: Ser coñecedores/as do traballo en curso. +- Concienciación: ser coñecedores/as do traballo en curso. -- Mellora do proceso: Detectar problemas e comprender as súas causas raíz (buscar os puntos de conxestión do proceso actual). +- Mellora do proceso: detectar problemas e comprender as súas causas raíz (buscar os puntos de conxestión do proceso actual). -- Motivación: Deixar que o equipo de desenvolvemento participe do seguimento (por exemplo, fomentando novas contribucións a un novo proxecto). +- Motivación: deixar que o equipo de desenvolvemento participe do seguimento (por exemplo, fomentando novas contribucións a un novo proxecto). -Unha forma habitual de aplicar unha nova metodoloxía consiste en seguir o PDCA (polas súas siglas en inglés, Planificar-Facer-Comprobar-Actuar) para unha mellora continua. Os pasos «Planificar» e «Comprobar» serán os máis relevantes para este capítulo de métricas, mentres que os outros dous estarán presentes na aplicación de melloras no proceso («Facer») e na toma de decisións («Actuar»). +Unha forma habitual de aplicar unha nova metodoloxía consiste en seguir o PDCA (polas súas siglas en inglés, planificar-facer-comprobar-actuar) para unha mellora continua. Os pasos «Planificar» e «Comprobar» serán os máis relevantes para este capítulo de métricas, mentres que os outros dous estarán presentes na aplicación de melloras no proceso («Facer») e na toma de decisións («Actuar»). As accións de planificación consisten en comprender a situación actual do proceso dentro da organización. Para iso, e desde o punto de vista das métricas, é necesario recadar información cualitativa e cuantitativa. Cuantitativa, no sentido de medir o que está a suceder no equipo de desenvolvemento actual e comprender como desenvolvedores/as e mandos intermedios usan a infraestrutura e interactúan entre si. Así poderá botarse unha primeira ollada á situación do proxecto nun momento determinado. -En canto aos datos cualitativos, tamén será necesaria a retroalimentación do equipo de desenvolvemento e dos/as cargos superiores, xa que comprenden como funciona realmente o proceso actual. Cabe esperar que isto solucione as cuestións que non acada o enfoque cuantitativo e permita comprender se, desde o punto de vista da dirección, as métricas son útiles para o seu traballo ou non o son en absoluto. +En canto aos datos cualitativos, tamén será necesaria a retroalimentación do equipo de desenvolvemento e dos/das cargos superiores, xa que comprenden como funciona realmente o proceso actual. Cabe esperar que isto solucione as cuestións que non acada o enfoque cuantitativo e permita comprender se, desde o punto de vista da dirección, as métricas son útiles para o seu traballo ou non o son en absoluto. Por último, é preciso definir os obxectivos, preguntas e métricas que axudarán a entender a contía da mellora á hora de aplicar novas políticas no proceso de desenvolvemento de software e noutras áreas. Esas métricas tamén se poden vincular a algunhas accións, como alertas cando o proceso do software non evoluciona como se esperaba. E esas alertas deberían rematar en accións ou decisións no paso de «Actuar». -En resumo; a retroalimentación cualitativa e cuantitativa, a definición de obxectivos e preguntas para medir o seu éxito que se comprobarán con posterioridade e, no momento de iniciar este proceso, facer un seguimento da situación do proxecto. +En resumo, a retroalimentación cualitativa e cuantitativa, a definición de obxectivos e preguntas para medir o seu éxito que se comprobarán con posterioridade e, no momento de iniciar este proceso, facer un seguimento da situación do proxecto. Unha vez que se definen as métricas e os KPI, o paso «Facer» levará algunhas semanas ou meses de traballo nos que os/as desenvolvedores/as traballarán nunha determinada situación con algunhas condicións específicas. O paso de «Comprobar» permitirá determinar se este proceso tivo o éxito suficiente, en función dos obxectivos orixinais definidos no paso «Planificar». Poderiamos ter mellorado o rendemento do modelo de desenvolvemento, pero se o obxectivo deste ciclo fose atraer máis desenvolvedores/as, fallariamos. -Ademais, a aplicación de diferentes políticas ou accións pode levarse a cabo de forma paralela e con diferentes proxectos. Poñamos o exemplo da selección dun novo modelo de gobernación para tres proxectos InnerSource diferentes: ditador/a benévolo/a, meritocracia pura na que os/as desenvolvedores/as poden traballar por si mesmos/as e un modelo mixto de meritocracia no que se guía aos/ás desenvolvedores/as no tipo de tarefas nas que poden traballar. +Ademais, a aplicación de diferentes políticas ou accións pode levarse a cabo de forma paralela e con diferentes proxectos. Poñamos o exemplo da selección dun novo modelo de gobernación para tres proxectos InnerSource diferentes: ditador/a benévolo/a, meritocracia pura na que os/as desenvolvedores/as poden traballar por si mesmos/as e un modelo mixto de meritocracia no que se guían os/as desenvolvedores/as no tipo de tarefas nas que poden traballar. -Isto pode axudar a seguir un proceso de proba do modelo de goberno a pequena escala, de xeito que aquel con máis éxito poida exportarse posteriormente a outros. Esta proba A/B permite determinar o mellor modelo de goberno en determinadas circunstancias. E contar coa retroalimentación cualitativa e cuantitativa das persoas implicadas no proceso, e das fontes de datos que empregaron, proporciona unha valiosa perspectiva sobre o rendemento dos varios modelos. \ No newline at end of file +Isto pode axudar a seguir un proceso de proba do modelo de goberno a pequena escala, de xeito que aquel con máis éxito poida exportarse posteriormente a outros. Esta proba A/B permite determinar o mellor modelo de goberno en determinadas circunstancias. E contar coa retroalimentación cualitativa e cuantitativa das persoas implicadas no proceso, e das fontes de datos que empregaron, proporciona unha valiosa perspectiva sobre o rendemento dos varios modelos.