Garantía de 30 días

Title

Garantía de 30 días

Patlet

cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos os equipos e fará que sexa máis probable que se acepten as contribucións.

Problema

Un equipo desenvolve un compoñente que se emprega na organización e resístese a aceptar ou directamente rexeita as contribucións (feature requests). Este comportamento bloquea o progreso e xera frecuentes interrupcións a causa das escaladas.

Contexto

• Os equipos dependen de que outro equipo acepte as súas contribucións para que o compoñente producido polo equipo receptor poida ser empregado polo equipo contribuidor.

• O equipo receptor non dispón dos recursos, dos coñecementos, dos permisos ou da disposición necesaria para escribir, por si mesmo, o compoñente/funcionalidade aportado/a.

Aspectos que mellorar

• Desconfíase das contribucións a causa dun pasado de enganos: os equipos enviaban contribucións que non estaban rematadas e, posteriormente, presentaban peticións de correccións que as deixaban listas para o seu uso en produción.

• Se se aporta código externo, o equipo receptor pode albergar a sospeita natural de que o outro equipo non saiba escribir un código que satisfaga as súas expectativas.

• Cada equipo tenta axudar primeiro a que os/as seus/súas propios/as líderes acaden as súas propias metas. Esta lealdade cara a directiva pode complicar a resolución deste problema.

• Naturalmente, existe un rexeitamento a responsabilizarse do código que non foi escrito por un/unha mesmo/a.

• As contribucións de código deben reescribirse a fondo antes de ser aceptadas na base de código.

• Témese que os/as contribuidores/as non estean dispoñibles para recibir asistencia coa corrección de erros unha vez transcorrido o tempo da contribución.

• Os equipos temen que as contribucións de código xeren custos de mantemento elevados, pero non saben como controlalo.

• Os equipos receptores poden temer que, ensinar a outras persoas a contribuír co código, expoña unha débeda técnica no seu sistema e que a visibilidade poida ser prexudicial.

• É posible que os equipos receptores non crean que obterán un código aceptable por moito asesoramento que brinden.

• Calquera dos equipos pode sentirse inseguro á hora de medir os riscos ou certificar que están mitigados nunha contribución; o sistema en si é algo fráxil (pode que non haxa maneiras de probalo completamente e detectar tódolos problemas).

Solución

Aborde os temores dos equipos receptores e contribuidores establecendo un período de garantía de 30 días, a partir do momento no que a contribución de código entra na fase de produción. Durante este período de garantía, o equipo contribuidor comprométese a proporcionar correccións de erros ao equipo receptor.

Teña en conta que o período de garantía tamén pode chegar a ser de 45, 60 ou 100 días. A duración pode variar en función das limitacións do proxecto, o ciclo de vida do software do proxecto ou os compromisos cos/coas clientes/as, entre outros factores.

Ademais, axuda a proporcionar directrices de contribución claras, concretando as expectativas do equipo receptor e o equipo contribuidor.

Garantía de 30 días

Contexto resultante

• O equipo receptor está disposto a aceptar contribucións e pode compartir a carga de traballo das adaptacións/reparacións iniciais.

• Maior transparencia e equidade.

• Evita que as escaladas se volvan demasiado pesadas.

Exemplos coñecidos

• Isto foi probado con éxito en PayPal.

• GitHub emprega internamente este modelo cun prazo de garantía modificado de 6 semanas.

• Microsoft recomenda este modelo coma un principio: os equipos establecen o seu propio obxectivo temporal específico en función das súas necesidades e confianza.

Autoría

• Cedric Willians

Recoñecementos

• Dirk-Willem van Gulik

• Padma Sudarsan

• Klaas-Jan Stol

• Georg Grütter

Estado

• Estruturado

• Redactado no Cume InnerSource de primavera de 2017; revisado o 18 de xuño de 2017.

Variantes

• Garanta a cooperación dos equipos dependentes, converténdoos nunha comunidade mediante a responsabilidade de máis dun/dunha trusted commiter (TC), designados/as por meritocracia.

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro