Software y la teoría del caos, un enfoque despreocupado - Un enfoque colaborativo al manejo de sistemas complejos

En su libro, Jim Highsmith, trata de comprender có mo las organizaciones y los equipos en general trabajan juntos y logran completar sus proyectos. Al concluir este aná lisis, trata recié n de estudiar el desarrollo de proyectos de software como un caso especial. Highsmith se dedicó a la enseñ anza y uso de metodolog as monumentales por muchos años. Luego inició el uso de un enfoque má s liviano, un poco menos extremo que el de Kent Beck y sus colaboradores. De todas maneras, nos alienta a cambiar de paradigmas, para usar una de las palabras favoritas de Microsoft.

---

Highsmith introdujo un nuevo vocabulario para el manejo de proyectos, por ejemplo, el ciclo de desarrollo deber contar con tres fases: especular, colaborar y aprender. Suena extrañ o? Prefiri usar especular en vez de planificar ya que piensa que la palabra "planificació n" se usa cuando se sabe exactamente hacia dó nde nos encaminamos, pero en realidad en CAS tenemos un sueñ o, una visió n apasionada pero poco clara de lo que queremos. Segú nél, descubrimos lo que necesitamos mientras se desarrolla el trabajo. Ademá s, si durante la creació n de un plan, uno se desví a, se piensa que es un defecto. Los gerentes opinan, en ese momento, que se debe regresar al plan original, mientras que en el CAS se considera que los desví os son los esfuerzos del equipo por encontrar la verdadera solució n, por lo que deberí an seguirse cuidadosamente si pensamos que nos dirigirá n aésta. Use la palabra "colaborar" en vez de "construir" ya que opina que la actividad má s importante de un equipo es trabajar juntos, y no contar con una lista de tareas a ejecutarse. Sostiene que el poder del equipo no consiste en las fortalezas individuales de sus miembros, sino má s bien en la cooperació n abierta y generosa para lograr el objetivo má s importante: el cumplimiento de la misió n del proyecto. Finalmente, escoge la palabra "aprender" en vez de "retroalimentar" debido a que desde un punto de vista de ingenierí a la idea de retroalimentar es obtener informació n sobre el rendimiento especí fico. Pero en un sistema complejo, no se busca loóptimo sino la adaptació n a condiciones siempre cambiantes: la idea de algo ptimo hace sentido solamente cuando existen condiciones estables, en donde también hay lí mites preestablecidos a alcanzarse. En los sistemas complejoséstos tambié n existen, pero siempre cambian (a veces se transforman en algo peor, o algo mejor), entonces el objetivo es aprender cuá les son los lí mites actuales, cuá les partes de su comportamiento le ayudará n en dichas circunstancias y qué partes se deberá n cambiar. Entonces, no hace falta solamente la retroalimentació n, sino el aprendizaje.

---

Tal vez la transició n desde planificar-construir-recibir retroalimentació n hacia especularcolaborar- aprender suene como mero juego de palabras, especialmente cuando averigue que el ASD propone ciclos cortos de desarrollo orientados a la entrega de componentes, como la XP, sin ningú n vocabulario complicado detrá s de esto. Pero me parece que la situació n es semejante a cuando fui de programació n de procedimientos a aquella de orientació n a objetos. Inicialmente, pensaba que la idea de que "los objetos se mandan mensajes que reciben respuestas" era algo rara, sobre todo porque me parecí a que simplemente estaban llamando a funciones como siempre. Pero las palabras tienen significados poderosos y el visualizar el sistema como una telara a de actores que llevan a cabo su trabajo solicitá ndose entre sí ayuda especí fica en vez de que sea un conjunto, organizado jerá rquicamente, de menú s, ventanas, funciones y bases de datos, cambia en verdad la manera en que se crean los sistemas. No se trata del idioma o de las herramientas usadas, sino de la manera en que piensa sobre los problemas a resolver y sus soluciones. Tengo que reconocer que la terminologí a de ASD y su manera de ver el mundo ayudan a organizar los proyectos de software de un modo má s natural. Una cosa que XP no tiene es un nivel administrativo. Kent Beck señ ala que XP fue creado para equipos localizados en el mismo lugar, compuestos de 10 a 12 personas, en donde la comunicació n constante y los ciclos cortos de construcció n y retroalimentació n casi reemplazan por completo la necesidad de contar con administradores especializados. Pero en los Centros de Desarrollo Virtual existen equipos distribuidos y probablemente má s grandes que los de XP, entonces se requiere de algú n tipo de coordinació n. Como comente anteriormente, Michael Lauer resolvió el problema al incorporar algunas prá cticas de las metodologí as monumentales: contar con un documento de especificaciones detallado, presionar al equipo para que trabaje horas extras, y todo esto funcionó en general. El ASD también reconoce la necesidad de que existan administradores pero, basá ndose de nuevo en el comportamiento de organizaciones exitosas que viven en ambientes que cambian rá pidamente, Jim Highsmith propone un modelo diferente para el manejo de proyectos de software. (Dentro de los ambientes cambiantes consideramos la biotecnologí a, la consultorí a, y el software entre otros).