Software y la teoría del caos, un enfoque despreocupado - Conclusiones

La velocidad actual de cambios del Internet y adelantos del comercio electró nico no nos permiten el uso de metodologí as inmensas que asumen que existe un ambiente bastante estable, para el manejo de proyectos de desarrollo de software. Debido a que la programació n libre y sin direcció n no es una alternativa, especialmente cuando se trata de proyectos grandes y distribuidos, se ha creado toda una familia de metodologí as conocidas como livianas oágiles. Una deéstas que es especialmente atractiva, por basarse fuertemente en los fundamentos de la teorí a de Sistemas Adaptables Complejos CAS (tambié n conocidos como teorí a del caos), es el Desarrollo de Software Adaptable (ASD). Este propone equipos que se auto-organizan y se adaptan durante ciclos cortos de desarrollo en espiral y mediante el aprendizaje para alcanzar objetivos en movimiento. La metodologí aágil má s popular es la Programació n Extrema (XP) que da importancia a los equipos pequeñ os y presenta prá cticas especí ficas que mejoran la productividad del programador y la calidad y resiliencia del có digo.

---

Ambas metodologí as se asemejan mucho a pesar del hecho de que evolucionaron de manera independiente. Ya que ASD propone má s bien un conjunto de patrones y no uno de reglas fijas y, ademá s, alienta procesos de adaptació n permanentes, pienso que el uso de prá cticas de XP con una administració n ASD y con una adaptació n rá pida por medio del aprendizaje, constituyen una combinació n muy efectiva para el manejo del desarrollo de software con equipos virtuales. Según su descripció n:

---

Sentido comú n, lo cual significa la manera de percibir el mundo que nos rodea, es algo que es indispensable en la administració n. Si notamos que el mundo es estable y predecible, nuestro enfoque a la administració n será muy diferente que cuando es turbulento y no predecible. Tener la idea de que el mundo es relativamente estable, un punto de vista como el de Newton, hizo que se creen prá cticas de administració n conocidas como "Control de Comando". En cambio, el percibir al mundo como algo cambiante y no predecible ha generado un nuevo conjunto de prá cticas administrativas, conocidas a veces como participativas, modernas, o centradas en las personas. En un mundo tumultuoso, en el cual la idea de "sentido comú n" se mejora con la comprensió n de sistemas complejos adaptables, creo que té rminos má s aplicables a estas prá cticas administrativas modificadas serí an Liderazgo-Colaboració n, en donde "liderazgo" reemplaza a "comando" y "colaboració n" a "control".

---

Los lí deres de un proyecto de CAS deben tener ideas, un equipo que trabaje en conjunto, y el deseo de arriesgarse. La colaboració n se encargará de có mo se organizan los componentes de software y có mo los miembros del equipo se coordinan. Un principio de CAS es que no se monitorea a las personas basá ndose en las tareas cumplidas sino segú n un estado cada vez mejorado del proyecto. Esto significa se administra el estado del trabajo y no su flujo. Y esto nos lleva a otro aspecto de la administració n: responsabilidad. En un proyecto CAS cada miembro se hace responsable del estado actual y deléxito (o fracaso) final del proyecto, entonces se detiene el juego de culpar a otro, así de plano. Se puede preguntar a cada uno la situació n actual, ya que la comunicació n fluye libremente, y nadie puede decir que no sabí a. Ademá s, se llevan horarios con informació n de cada ciclo de desarrollo para forzar al equipo a tomar decisiones. Esto es importante porque caso contrario los equipos tienen la tendencia a seguir todas las opciones nuevas, sin decidirse por un camino especí fico. Los calendarios son ejemplos de una té cnica ASD para evitar que un equipo, que se auto-organiza, llegue al caos. A pesar de que pueda pensar que el ASD es muy teó rico y poco prá ctico, este no es el caso. De hecho, Jim Highsmith demuestra con ejemplos especí ficos y prá cticos có mo ha funcionado en proyectos de software complejos. Pone énfasis en la palabra "ejemplos" ya que piensa que los proyectos complejos deben adaptarse, por lo que presenta patrones cuya utilidad se ha demostrado en vez de reglas fijas. Usted deberá decidir si su proyecto se asemeja a los incluidos en los ejemplos. Externamente, un proyecto ASD se parece mucho a uno XP, pero las bases teó ricas má s fuertes y la administració n para evitar el caso hacen que sean intrigantes. En resumen, es divertido leer el libro: "Desarrollo de Software Adaptable" ya que está lleno de ejemplos y analogí as. Por este motivo, le aliento a hacerlo y conocer sus detalles que no esté n dentro del alcance de este informe.