Metodología de Desarrollo en el Software Libre: Rompiendo Paradigmas

Transcripción

1 Metodología de Desarrollo en el Software Libre: Rompiendo Paradigmas

2 Agenda Introducción Desarrollo tradicional vs. Desarrollo en SL Desafíos en el SL Calidad en el SL Casos de Éxito Comunidades de SL como Sistemas Emergentes Prácticas en el desarrollo de SL Paradigmas tradicionales desafiados Aplicación de las técnicas SL en nuestros propios desarrollos 2

3 Introducción Linux es Subversivo! Desarrollo de la WWW y SL han ido de la mano. Impresión inicial: El desarrollo del Software Libre no debería poder ser exitoso. Primer estudio: La catedral y el Bazar por Eric S. Raymond. Investigaciones de campo revisando casos de estudio, modelos de comunidades y metodología de desarrollo.

4 Desarrollo tradicional vs. Desarrollo en SL Desarrollo Tradicional Construcción de catedrales: Objetivos y requerimientos bien planteados Liderazgo tradicional, descendente Asignación de tareas Equipos de tamaño reducido Control y seguimiento de actividades Desarrollo en Software Libre Cada desarrollador agrega las funcionalidades que considera necesarias Liderazgo emergente, no impuesto Cada desarrollador escoge en que trabajar Decenas o cientos de desarrolladores participando. Desarrolladores participan en tiempo parcial y cuando lo desean

5 Desafíos en el SL Salvo contadas excepciones, los desarrolladores no participan bajo contrato El trabajo no es asignado, sino que cada quien participa como desea hacerlo. Hay mucha rotación en las comunidades de desarrolladores: Siempre entran o salen desarrolladores. Normalmente, no hay diseño global o detallado. Generalmente, no hay plan de proyecto o lista de entregables

6 Calidad en el Software Libre Tablas de Densidad de Defectos encontrados Module #PR/ KLOC Added #PR / KDelta Projects #PR/ KLOC Added #PR/ KDelta #PF/ KLOC Added #PF/ KDelta Apache 2,6 40,8 Project C 5,7 164 Project D Project E 6,9 256 /layout 2,8 51 Apache 2,64 40,8 2,64 40,8 Project A 0,11 4,3 * * Project C 0,1 14 5,7 164 Project D 0, Project E 0,1 10 6,9 256 /js 0,7 19 Módulos de Mozilla /rdf 1,4 27 /netwerk 3,1 42 /editor 2,5 44 Leyenda PR PF Post Release Defects Post Feature Defects (testing phase) /intl 1,6 20 /xpinstall 4 56 KLOC KDelta Miles de lineas de código Miles de cambios en el código Tomado de Mockus et al, ACM Transactions on Software Engineering and Methodology, Vol. 11, No. 3, July 2002

7 Casos de Éxito en el Software Libre Cómo pueden ser exitosos estos proyectos y aplicaciones con las condiciones con las que se producen?

8 Comunidades de SL como Sistemas Emergentes Comportamiento inteligente en el nivel colectivo a partir de acciones simples en el nivel individual y las interacciones de los individuos. Surgimiento del éxito es ascendente, desde el colectivo y no impuesto descendentemente. Control indirecto y distribuido.

9 Prácticas en el Desarrollo de Software Libre Prácticas de Desarrollo de Linus Torvalds Liberar rápido y muy seguido Delegar todo lo que se pueda Ser abierto hasta el punto de la promiscuidad

10 Prácticas en el Desarrollo de Software Libre Las comunidades de SL están gobernadas por la acción individual de sus miembros: Mecanismos formales tienen una acción limitada. Cada desarrollador decide en que proyecto participar y que actividad desempeñar. Protección de la Propiedad Intelectual con licencias como GPL, entre otras. Motiva a los desarrolladores a participar voluntariamente. Esto asegura que hay beneficio en la participación de otros

11 Prácticas en el Desarrollo de Software Libre Elegancia del código es vital Código autoexplicativo Promueve la fácil integración de nuevos recursos voluntarios Disminuye el costo de entender el trabajo de los demás, y de cambiarlo. Modularidad en el diseño Facilita la autodivisión del trabajo y la autoorganización del equipo. Disminuye la necesidad de coordinación colectiva. Permite la apropiación de actividades de manera independiente

12 Prácticas en el Desarrollo de Software Libre Los conflictos se resuelven haciendo y no hablando Generalmente se ignoran los conflictos de la lista de correo, cada quien demostrando su argumento con su propia implementación Si hay más de una opción en competencia, generalmente se hacen las dos. Las consecuencias de los conflictos son mínimas Líneas paralelas de desarrollo son mecanismos muy usados

13 Prácticas en el Desarrollo de Software Libre Decisiones colectivas provienen de la comunidad Mecanismos de imposición de decisiones no son viables Mecanismos formales como sistemas de votación son muy poco usados Esquema de enjambre en la toma de decisiones. Se consideran como factores determinantes: Estadísticas de actividad de los proyectos. Reputación de los participantes Elegancia de las soluciones

14 Prácticas en el Desarrollo de Software Libre Monitoreo es llevado a cabo por toda la comunidad Hall of Shame. El código resultante será visto y publicado en Internet. Todo lo que codifiques podrá ser usado en tu contra Las sanciones son un resultado directo del monitoreo Mecanismos formales de sanciones casi nunca son usados Spamming o Flamming: El código que no cubre las expectativas de calidad es ignorado o su autor termina abarrotado de correos solicitando explicación.

15 Prácticas en el Desarrollo de Software Libre Múltiples capas de desarrollo anidado División emergente del trabajo Alto nivel de especialización División visible entre usuarios desarrolladores iniciados, bug reporters, y core developers. Aprovechamiento de la participación masiva Número elevado de bug reporters Apertura a nuevos desarrolladores voluntarios Grupos de pequeño o mediano tamaño de core developers. Ley de Linus

16 Paradigmas tradicionales desafiados Ley de Brooks vs Ley de Linus Ley de Brooks: Añadir más personal a un proyecto retrasado lo retrasa más La necesidad de intercomunicación se ve disminuida por la elegancia del código y la modularidad del diseño. Ley de Linus: Dados muchos ojos, todos los errores serán obvios Reduce dramáticamente la necesidad de un equipo dedicado de pruebas

17 Paradigmas tradicionales desafiados Ineficiencia de líneas de desarrollo paralelas Mecanismo de resolución de conflictos Selección de la mejor opción Resolver haciendo y no hablando Control Centralizado vs. Control Distribuido El colectivo promueve la calidad del producto Disminución de la erosión en la motivación por efecto del control y seguimiento

18 Paradigmas tradicionales desafiados Motivación por el trabajo en si y no por la remuneración Los desarrolladores disfrutan hacer un trabajo de calidad, elegante y que cumpla sus funciones. Orientación ascendente del producto (bazar) vs. orientación descendente (catedrales) El colectivo puede ser tan inteligente como las individualidades El todo es mayor a la suma de sus partes

19 Cómo aprovecharnos de éstas técnicas? Útil en los Desarrollos Internos y de herramientas para el repositorio Acceso libre al código Sólo lectura Participación voluntaria Desarrolladores usuarios, grupo de testers masivos Autoorganización del grupo de desarrollo

20 Gracias por su atención Preguntas?