Propiedad colectiva

Los equipos típicamente adoptan convenciones que gobiernan a quién se le permite modificar algún código fuente que fue escrito originalmente por otro, a menudo referido como “propiedad”. Estas convenciones pueden ser escritas y explícitas, meramente orales o totalmente implícitas. Existen muchos modos diferentes; normalmente sólo un desarrollador “posee” cada archivo de código. La propiedad colectiva del código, como su nombre indica, es la convención explícita de que “cada” miembro del equipo no sólo está permitido, sino que de hecho tiene el deber positivo de hacer cambios en “cualquier” archivo de código según sea necesario: ya sea para completar una tarea de desarrollo, para reparar un defecto, o incluso para mejorar la estructura general del código.

Beneficios esperados

Una política de propiedad colectiva del código:

  • Reduce el riesgo de que la ausencia (o indisponibilidad) de un desarrollador paralice o ralentice el trabajo.
  • Aumenta la posibilidad de que el diseño global sea el resultado de decisiones técnicas sólidas, más que de la estructura social, como en la “Ley de Conway”.
  • Es un factor favorable en la difusión del conocimiento técnico.
  • Alienta a cada desarrollador a sentirse responsable de la calidad del conjunto.

Obstáculos comunes

Pueden existir normas tácitas o implícitas que contradigan una política de propiedad colectiva adoptada por el equipo. Por ejemplo, un desarrollador se vuelve malhumorado cada vez que se modifican los archivos de un componente en particular, de modo que el equipo comienza a tratarlos como “de facto” bajo su propiedad exclusiva. Asegúrese de verificar que la política sea consistente con el comportamiento real.

Costes potenciales

Si bien la idea de la propiedad colectiva está alineada con otros principios de responsabilidad compartida en Agile (como la responsabilidad compartida, entre el cliente y el equipo de desarrollo, por los resultados del proyecto), tiene sus detractores. Los argumentos en contra también son plausibles y hay que tener cuidado:

  • En el límite, tener a todos responsables de la calidad puede ser una situación indistinguible de no tener a nadie responsable de la calidad.
  • La falta de aplicación social de límites alrededor de los componentes del código puede llevar (por “Ley de Conway”) a una falta de interfaces bien definidas, sin embargo, las interfaces bien definidas son una clave para un diseño eficaz.

Orígenes

  • 1968: “La “Ley de Conway” es acuñada y resumida de la siguiente manera: “Cualquier organización que diseñe un sistema (definido más ampliamente que los sistemas de información) producirá inevitablemente un diseño cuya estructura es una copia de la estructura de comunicación de la organización”. Durante mucho tiempo ha tenido el estatus de folklore más que de resultado científico bien fundamentado, aunque estudios recientes le han dado cierto apoyo académico. (Los aspectos sociales del desarrollo de software fueron ignorados por la ingeniería de software académica hasta mediados de los 90’s.)
  • 1995: Coplien nombra el patrón “Code Ownership” en los lenguajes de patrones de diseño de programas, en una primera versión de su “Organizational Patterns”, una obra influyente en el desarrollo posterior del discurso ágil. Sin embargo, apoya la propiedad exclusiva de los códigos individuales y advierte contra la propiedad colectiva que él equipara a la no propiedad en absoluto. Coplien admite que existen objeciones contra la propiedad individual, pero argumenta que otros de sus patrones mitigan esos problemas.
  • 1998: Los primeros escritos sobre Programación Extrema recomiendan la “Propiedad del Código Colectivo” como una práctica oficial. Los “extremos” argumentan, al igual que Coplien lo hace en la dirección opuesta, que otras prácticas de Programación Extrema mitigan los problemas citados contra la propiedad colectiva: convenciones de códigos uniformes y pruebas extensivas.
  • 1998: El primer artículo sobre Extreme Programming, “Chrysler goes to Extremes”, describe varias prácticas de XP tales como tareas auto-elegidas, pruebas primero, iteraciones de tres semanas, propiedad colectiva de código, y programación de pares.

Deja un comentario

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar