Nuevo blog

Buen dia para uds

Escribo esta entrada para informarles de la existencia de un nuevo blog por mi parte
el cual es http://yeradis.blogspot.com

no es mas que una continuidad de este
pero bajo mi nick directamente

Ud. sera automaticamente redirigido al nuevo blog

sin mas me despido....

Salu2s y que la buena suerte los acompañe siempre (y espero que a mi también :D)

TIEMPOS DE ANTAÑO

Saludos a todos los que amablemente siguen este blog
que mucho trafico no tiene , jajajajaj

Hacia ya algún tiempo que no escribía principalmente por falta de tiempo, la vida aquí en mi nuevo destino es muy agitada y hay que correr mucho, pero bueno me dejo de lloriqueo, que agotamiento tenemos todos y así voy al tema de este articulo

En una ocasión en este mismo blog desarrolle un articulo llamado : "Hazte programador en 3 días, La receta de 6 ingredientes para el éxito."

Y volviéndolo a releer, para ver que tal esta , ya que lo mejor que hay es observar las cosas hechas después de algún tiempo me percate de algo que en ese momento se me paso
y es que en el primer punto de la receta se menciona que el interés por la programación, es muy provechoso para aprender mejor y que hay que asegurarse de que uno se divierta lo suficiente como para invertir 4 años, que al principio puede ser torturan te, pero con los libros adecuados puede aplacarse la dureza del comienzo.
y he aqui el motivo impulsor de este articulo por este mismo motivo lo titulo TIEMPOS DE ANTAÑO

Ya que recuerdo en mis inicios en la programación , siempre estuvieron presentes estos libros adecuados que me ayudaron a aplacar la dureza del comienzo y es que siempre con cualquier lenguaje que uno deseara emprender una aventura en su conocimiento, siempre, siempre se encontraría con los libros que considero imprescindibles los cuales a mi juicio son: El manual del usuario,La guia de referencia del lenguaje y el Manual del programador

Libros que actualmente se puede decir que no existen no se si es por el propio desarrollo evolutivo de la informática o por conveniencia de unos y otros y así poder montar negocios con respecto a a capacitación, lo cierto es que en tiempos de antaño si querías conocer el lenguaje de programación C , C++ u otro , siempre estos libros los ibas a encontrar con mucha facilidad, libros que te premitian sumergirte en el mundo que encierra cada lenguaje sin problema permitiéndote avanzar mucho mas rápido en la aventura comenzada.

Y lo cierto es que de un tiempo acá , es algo que he visto que ha desaparecido. Por al menos yo no he encontrado lenguaje alguno donde se me facilite el encontrar estos libros que considero muy imprescindibles. Lo que si me encuentro es mucho libro basura, la verdad que, ninguno me enseña nada, los libros esos(sin quitar el merito a quien lo merece), una cosa si, hojas tienen , son tan voluminosos que para llevártelos encima haz de contratar carrito de super de lo grandes que son(los libros) y lo mas jodió es que no se aprende con ellos te hablan tanto de tantas cosas que lo que necesitas del lenguaje no te lo dicen por ningún lado aunque es cierto que para principiantes la gran mayoria de esos libros son mas que suficientes.

Se que a muchos que han empezado recientemente en este mundo de la programación les parezca normal y dirán que que es lo que estoy hablando , pero se, que los que han empezado hace ya mucho saben de lo que hablo , es cierto que en ese entones no había mucho libro , pero al menos, esos del lenguaje que fuese, se encontraban.

Pocos he visto que si te proveen algo como lo es la Borland con su Object Pascal(Delphi) y de ellos no me sorprende, dado el impulso que han dado el desarrollo que actualmente tenemos en materia de informática.

Lo que si me llamo mucho la atención, es, cuando lo encontré, que un proyecto como FreePascal si cuente con estos libros básicos que considero imprescindibles, y es algo que han mantenido desde entonces y espero que no lo cambien algo que muchas compañías comerciales no han hecho; pero ojo dicen que si(esas compañias) te lo dan pero de tal manera que no te enteras de nada cuando presionas F1 para la ayuda.

Para aquellos que deseen aprender programación en pascal , les recomiendo que empiecen por FreePascal que no es mas que un proyecto Open Source de Object Pascal, proyecto que a su vez cubre todas las áreas necesarias , va desde la consola hasta el sistema gráfico de ventanas así como el acceso a bases de datos y demás tecnologías, este proyecto para aquellos que deseen empezar se los recomiendo, pero eso si recuerden que no es una herramienta solo para principiantes ya que se puede desarrollar lo que se desee en el , desde en sistema gestor de bases de datos hasta un sistema operativo funcional.

Y lo mejor de todo es que es completamente gratis o libre el FreePascal que es el paquete que incluye el entorno de trabajo para programar y dentro viene incluida también esta informacion, estos libros que considero imprescindibles


Espero que lo aquí escrito le sirva a alguien

Salu2s y que la buena suerte los acompañe siempre (y espero que a mi también :D)

mi nuevo principio

Saludos a todos los que sigan este blog
como pudieron apreciar estuve ausente varias semanas
y es que estaba en proceso migratorio para poder estar con mimujer
y asi comenzar juntos ella y yo , nuestro nuevo principioç
la continuacion del proyecto que elegimos con una materializacion mas concreta

ahora tratare con una periodicidad publicar algunos articulos
dentro de mis posibilidades en lo que encuentro trabajo


Salu2s y que la buena suerte los acompañe siempre (y espero que a mi también :D)

Ausente

Les dejo estas lineas para aquellos que tengan la gentileza de leer este blog sepan que estare ausente por un tiempo
ya que dentro de muy poco al fin podre continuar con la vida que escogi para mi al lado de la mujer que amo

Salu2s y que la buena suerte los acompañe siempre (y espero que a mi también :D)

Hazte programador en 3 días, La receta de 6 ingredientes para el éxito.

No son pocas las personas que creen que pueden volverse expertos comprando un libro de esos de "Aprende X cosa en milésimas de segundos"
para ellos y para uds tengo una buena noticia:ESTÁN EN UN ERROR SI SE CREEN ESTO

La excelencia en cualquier área puede lograrse sólo mediante el trabajo de toda
una vida; con mucha dedicación y esfuerzo, no es algo que pueda adquirirse a un menor precio desgraciadamente para muchos.Lo siento.

Algunos investigadores (no hablo de mi :P) han mostrado que se necesitan aproximadamente diez años para desarrollar habilidades en cualquiera de una amplia variedad de áreas, incluyendo el fútbol, la pelota,el juego de ajedrez, la composición musical o literaria, la pintura, el piano, la natación, el tenis,el pin-pon, entre muchas otras.

Y la programación es una de esas áreas.

La programación es consideraba por algunas personas como un arte, no se trata solo de escribir cualquier barbaridad para obtener un desastre de programa sino que se necesita de destreza,habilidad y agilidad y sobre todo de buena experiencia, algo que esos libros de 'Hazte genio en 3 días' no enseñan.

Quizás si puedan acercarte, pero de una forma muy superficial a lo que es en si la programación en un lenguaje específico, es decir su sintaxis; pero a programar no se aprende en 3 días, ya que en 3 días no tendrás tiempo de escribir varios programas que valgan la pena, y mucho menos de aprender de tus éxitos y errores. No tendrás tiempo de trabajar con alguien experimentado en esta área y tampoco en 3 días podrás entender lo que es vivir en ese ambiente. En resumen, en 3 días no tendrás tiempo de aprender mucho.

En 3 días puedes aprender , por ejemplo,la sintaxis de Pascal (si es que conoces un lenguaje similar), pero no podrás aprender mucho poder cómo usarla. Por ejemplo, si fueras, digamos, un programador Basic, de seguro podrías aprender a escribir programas en el estilo de Basic usando la sintaxis de Pascal(que desastre), pero no aprenderías realmente para lo que Pascal es
bueno (o malo). Entonces ¿cuál es el objetivo de aprender asi? Alguien que no recuerdo, dijo alguna vez: "Un lenguaje que no afecte tu manera de pensar acerca de la programación, no merece conocerse".

Así que esos libros sólo podrán lograr una familiaridad demasiado superficial como dije anteriormente, no un entendimiento profundo del tema tratado.

Y para aquellos que ya estaban llorando o a punto de hacerlo por la cantidad de cosas negativas que dije, les tengo una buena noticia "si se puede aprender a programar"

A uds (los llorones :-P) , aquí les dejo mi receta para el éxito en la programación
y que conste, lo que aquí les dejo es algo que aprendí en todos estos años que llevo como programador desde que empece a los 8 años.

Mi Receta para el éxito:

1• Pon interés por la programación, y programa porque es divertido(al menos para mi) y muy provechoso. Asegúrate de que te diviertas lo suficiente como para invertir 4 años, al principio puede ser torturante pero con los libros adecuados puede aplacarse la dureza del comienzo.
2• Ten contacto con otros programadores. Lee otros programas(codigos). Esto, creo yo, es más importante que cualquier libro o curso.Leyendo códigos aprendes estilos,formas y mecanismos.Dialoga con otros programadores,intercambia ideas, esto es primordial para un aprendizaje eficiente y productivo.
3• Programe. Señores se los digo, el mejor tipo de aprendizaje que puedan tener es aprender practicando la programación, la programación no se aprende solo leyendo, hay que romperse los dedos tecleando(que es broma lo de romperse los dedos , lo demás no).
4• Ten proyectos con otros programadores(programa en grupo). Sin miedo alguno, sé el mejor programador en algunos proyectos o sé el peor en otros, no hay problemas con esto ya que de una forma u otra vas ganando en experiencia y conocimientos. Si eres el mejor, pon a prueba tus habilidades para ser líder del proyecto y así poder (o al menos intentar) inspirar a otros con la visión que. Cuando eres el peor del proyecto no importa ya que aprendes lo que los mas experimentados hacen, y aprendes lo que a ellos no les gusta para nada hacer (ya que te ponen a hacer esas cosas a ti :-P).
5• Trabaja en proyectos hechos.Proponte conocer un programa escrito por otra persona.Observa cuánto te toma comprenderlo y hazle correcciones las correciones que creas que sean mejor. Pon tu cabecita a funcionar y piensa en cómo diseñar tus programas para facilitarles el trabajo a aquellas personas que le harán mantenimiento cuando tu no estés.
6• Aprende otros lenguajes. Por lo menos 3. Esto te servirá mucho ya que todos los lenguajes no son iguales ni son hechos para la misma cosa , cada lenguaje fue creado para satisfacer una necesidad especifica y puedes aprender nuevas formas y vías de esta pluralidad y también a la hora de tomar algún proyecto te servirá el conocer los paradigmas que encierran estos lenguajes. Te recomiendo que incluyas en estos que aprendas alguno con soporte para abstracciones de clases,otro con abstraccion funcional, también uno con abstraccion sintáctica, y fíjense como uso el termino abstracción, recuerden que la abstracción es la madre de la productividad.



De cualquier manera que quiera verlo, la lectura de libros solamente no será suficiente.
Pero como todo lo antes dicho, es custionable(puede generar el debate) no dude en comprar( o piratear) su libro de Aprende Lingo en 3 días ya que probablemente obtendrás algo de él.
Pero desgraciadamente no cambiará tu vida o tus habilidades reales como programador en 72 horas.



Salu2s y que la buena suerte los acompañe siempre (y espero que a mi también :D)

La creatividad y la persona emprendedora

El proceso de emprender es, sin duda, un camino que muchas veces llega a ser muy complejo donde se necesita voluntad, capacidad y suerte y, a pesar de todo, la buena combinación de estos elementos no garantiza el éxito de toda “aventura”. La dificultad radica de esto, principalmente, en encontrar una idea atractiva, muy atractiva y no dejarse desalentar ni vencer por todos los obstáculos(lo mas dificil diria yo) que hay que sortear a lo largo del proceso. En definitiva señores, las ventajas y beneficios existen pero se hacen esperar, hay que ser pacientes y tenaz para conseguir llevar a cabo un reto de esta consideración donde el camino a recorrer no sera el mas facil de todo.

Ahora bien, existen personas con muchisima más facilidad que otras a la hora de ser creativos,algunas nacen con ciertas cualidades(un don????), otros las desarrollan, pero de todas formas, todos podemos ser más creativos si nos lo proponemos.

Existen muchisimas técnicas que ayudan a ejercitar y preparar nuestra mente y desarrollar habilidades creativas. Pero la verdad es que, sin necesidad de practicar técnicas muy sofisticadas para descubrir nuevas ideas, la creatividad puede surgir en cualquier momento y en cualquier circunstancia del día a día, por ejemplo, puede ser resultado de:

•nuestra propia inquietud, queremos hacer algo nuevo, queremos
cambiar, buscamos nuevos horizontes y en un momento dado tenemos
una idea.....
• nuestra capacidad observadora, inquietos buscamos esa nueva idea
en nuestro entorno esforzándonos por ver donde los demás no ven.
• nuestra propia experiencia laboral/empresarial, idea que surge al
conocer otra empresa, al movernos en ambientes empresariales, al
conocer otros negocios.
• de manera aleatoria e imprevista, surge una idea al informarnos
sobre un sector, una actividad, en un viaje, en una conversación en
familia, reunión entre amigos, etc.
• de nuestra propia necesidad, el mercado actual no satisface mis
necesidades en un servicio o producto concreto o de la manera que
a mí me parece más acertada.
• del aprovechamiento de revoluciones/cambios que acontecen en
el mundo, como pueden ser el desarrollo de las nuevas tecnologías
de la información y de la comunicación, las nuevas características
demográficas, el cambio en los hábitos de consumo, etc.
• de nuestra propia imaginación, intentar canalizar ese potencial en
una idea realista y eventualmente atractiva para los demás.

Estas a mi criterio serían algunas de las fórmulas que nos pueden ayudar a generar una idea, si somos persistentes y tenaces(muy tenaces) seguro que terminaremos encontrando alguna clave que nos conduzca hacía un nuevo reto.

Salu2s y que la buena suerte los acompañe siempre (y espero que a mi también :D)

El dilema de Linux, variables a considerar!!!!

En el mundo Linux, algunas distribuciones tienen fama de ser fáciles y otras tienen super fama de difíciles e incluso imposibles , y la verdad esto lo decimos solo por el proceso de instalacion principalmente sin tener en cuenta otros factores.

Dejando a un lado las impresiones personales recibidas y los muchos dolores de cabeza vividos, hay algunos de estos Mitos que no tienen en cuenta el día a día de trabajo. Instalar una distro de linux puede ser muy fácil, incluso super facil, pero si su mantenimiento es complicado, esa distribución de linux se debería considerar difícil. Pero sin embargo, esto normalmente no sucede asi. Criticamos a las distribuciones de Linux segun su proceso de instalación, y lo peor de todo, es que, normalmente no dedicamos ni media hora a instalar un sistema operativo(usando el asistente principal), pero sí pasamos horas,horas y horas utilizándolo,trabajando con el y actualizándolo,acomodandolo a nuestro gusto.

Pero a que con Windows no pasa esto, alguien recuerda el Win 98 y su proceso de instalacion???? o el Win Nt ????

Y escribo estas lineas por un articulo que lei en el blog de Andrew Cowie, un artículo sobre cómo aprender Linux en el que se muestra un gráfico que nos compara estas dos variables: Facilidad de Instalar y Facilidad de Actualizar. Esto es lo que deberiamos tener en cuenta a la hora de seleccionar una distro de Linux. Al menos yo concuerdo con sus valoraciones, aqui les dejo el gráfico:

Al menos, a mi, no me sorprende la posición de Ubuntu, que se ve muy bien en ambos aspectos(Facil de Instalar/Facil de Actualizar). La verdad es que Ubuntu ha dado en el clavo haciendo un “Debian mucho mas fácil” (algo que se quiso conseguir anteriormente con otras distros de linux). Sus paquetes no tienen el acabado final como los de Debian, pero el usuario lo quiere rápido y fácil y es lo que Ubuntu esta ofreciendo.

Tanto es asi que podemos ver en algunos articulos como se cataloga a Ubuntu la mejor distro hasta el momento, enfocada en el usuario final y por eso es que la comunidad de usuarios de Ubuntu va creciendo muy rápidamente y eso se nota en la publicación de creciente de varios libros, entre muchas otras iniciativas para fomentar su uso e invitar a los usuarios en su proceso de aceptación.

Salu2s y que la buena suerte los acompañe siempre (y espero que a mi también :D)

Teoria del Caos, la clave para el desarrolo de proyectos mejor y mas rápido

Antes de comenzar me gustaría decirles que este escrito(no es mio) es solo un enfoque despreocupado , no se puede tomar como una referencia, así que no lo haga en casa si no esta acompañado de un adulto deje esto a los profesionales :P

Y digo así ya que en nuestra búsqueda de una metodología que nos facilite la vida, hemos intentado de todo y si no me creen solo paren un momento y miren cuantas metodologías de desarrollo de software existen y al final todas fallan en algún punto, por eso, aclare antes, que esto es solo un acercamiento a un estilo, a una forma, que si la analizamos bien y especificamos podríamos usarlo en nuestro entorno de trabajo.

aquí les dejo el escrito:

¿Serán la Teoria del Caos la clave para el desarrollo de proyectos Mejor y Más rapido ????

El escenario

Seguramente usted se ha enfrentado a esta situación antes: las especificaciones del
proyecto han cambiado con tanta frecuencia que el actualizar el cronograma se ha
convertido en un ejercicio inútil. Hasta hace poco, existía una sola explicación aceptada
por todos para esta situación una mala metodología es decir no se debería
haber comenzado un proyecto sin un conjunto bien definido de especificaciones.
Pero, la vida real nos ha demostrado que el compilar un conjunto de este tipo de especificaciones
es una aventura llena de peligros. Tendrá que hacer estimaciones
sin nada concreto o invertir grandes cantidades de tiempo y dinero para obtener
una guí a definitiva de especificaciones. Y por supuesto, hablar de "especificaciones
definitivas" parece una contradicción de términos en desarrollo de software.
Hablando ahora sobre la fase de diseño, no debe sorprendernos que los desarrolladores
del equipo digan algo como "ahora que entiendo el problema pienso que puedo
crear el código correcto". Pero de esto se dan cuenta cuando el módulo ya ha sido
escrito. Otra contradicción de términos en nuestra industria podría ser "diseño de
software correcto al primer intento".
Finalmente, hablemos sobre pruebas, cuando se establecen cronogramas esta es un
área sobre lo que no hay nada escrito. Dependiendo de cuán bien se hayan definido
y comprendido las especificaciones y el diseño y también de la calidad del equipo de
desarrollo, las pruebas podrían representar del 20 al 80% del tiempo total. Gerentes
de proyecto sin experiencia con frecuencia asignan un máximo de 15% a esta fase.
Esto ocurre, porque la alta gerencia podría pensar que un mayor porcentaje significar
a que el equipo de desarrollo ha estado creando software de mala calidad.
Le parece conocido este escenario? Si es que no, usted pertenece a una minoría
con suerte. Tanto estudios formales como informales han demostrado que la mayoría
de proyectos de software no cumplen los cronogramas ni los presupuestos, a veces
con consecuencias desastrosas.

La causa del problema

Claro que este escenario no es nada nuevo. Hace ya cerca de veinte añ os se crearon
diferentes metodologías para disciplinar los proyectos de software utilizando
prácticas estándares de ingeniería. A pesar de esto, la situación ha permanecido
igual y los creadores de metodologías dicen que la culpa ha sido por la lenta adopción de sus propuestas. Despu és de todos estos años, uno se pregunta por qué el
mercado ha sido tan reticente en adoptarlas, si en realidad estas metodologías pueden
resolver problemas tan costosos.
De hecho, voceros respetados de la comunidad del desarrollo sugieren que las así
llamadas metodologías monumentales pueden haber causado más daños que beneficios
y que la situación parece que se ha tornado más grave desde el inicio del Internet
y el increíble aumento de la velocidad en los cambios en los modelos de negocios.
Estos voceros piensan que las metodologías monumentales surgieron de
paradigmas mal concebidos, como por ejemplo, que la ingeniería de software se
asemeja a la eléctrica, química y especialmente a la civil. Según un análisis posterior
(que se ha demorado quince años en llevar a cabo), existen algunas diferencias
fundamentales

1. En la ingenier ía civil, usted hace un aná lisis detenido y un diseñ o del producto a fabricar
y luego ejecuta un proceso de construcció n bastante caro, pero en términos generales
rutinario y sin mayores cambios. Esto es posible solamente porque el producto
fue comprendido muy bien, es relativamente simple y (especialmente) las necesidades
y leyes físicas no cambiaban.
La mayor ía de proyectos de software trata de capturar relaciones complejas y siempre
cambiantes y flujos de trabajo, ademá s de una teorí a unificada de có mo funcionan las
organizaciones humanas. No existe todaví a una teorí a que pueda convertir tales sistemas
en algo tan predecible como, por ejemplo, la resistencia de los materiales.
2. Algunas investigaciones sugieren que la creaci ón de software es un ejercicio continuo
de diseñ o (es decir: hallar una solució n, construirla, ver si funciona, si funciona, ir
al pró ximo reto, sino comenzar de nuevo.) Esto hace que el centro dte gravedad econó
mico del proyecto se aleje de la construcció n repetitiva y se acerque al lado creativo.
En este sentido, los proyectos de software se asemejan má s a los departamentos
de investigació n y desarrollo que a las fá bricas.
3. El aná lisis y dise ño de la ingenierí a civil se llevan a cabo por gente muy inteligente
y preparada, en cambio la fabricació n en sí puede ser realizada por gente menos preparada.
En ingenierí a de software, profesionales igual de inteligentes y preparados se
dedican a la construcció n. Si uno contrata programadores no muy listos que escriben
có digo sin pensar mucho al respecto para cumplir especificaciones, es poco probable
que se logre un proyecto exitoso. Una consecuencia muy importante es la siguiente:
en la ingenier ía civil, los mé todos de trabajo pueden ser impuestos por una autoridad,
en cambio en ingeniería de software, el lí der debe convencer a sus compañ eros.
Tenemos que darnos cuenta de que sí existen proyectos de software con especificaciones
fijas y que se pueden comprender de manera razonable. En estos casos la mentalidad
de la ingenierí a civil funcionar muy bien. Lamentablemente, tengo el presentimiento
de que la mayor ía de proyectos de software no cumple estos pará metros y en
estos casos, la escuela de administració n basada en "aná lisis/diseñ o/definició n de tareas
y costos/creació n de calendarios/construcció n siguiendo planes" no es adecuada

El inicio de la solución

Martí n Fowler afirma de manera convincente que probablemente la diferencia fundamental
entre los proyectos de software y de otras ingenierí as es que los primeros no
son predecibles. Como hemos indicado, esto es el resultado de especificaciones cambiantes
y de la falta de comprensión de có mo deber funcionar el sistema que se está
tratando de automatizar. Entonces, pregunta Martí n, có mo podemos controlar un mundo
no predecible? La respuesta, o más bien dicho, el fundamento teórico de la respuesta
viene de un campo no esperado: la teorí a del caos, conocida má s formalmente
(sospecho que deseaban evitar los chistes) como teorí a de Sistemas Complejos Adaptables
(CAS, segú n sus siglas en el inglé s). El enfoque de la teor a de CAS es explicar
cómo sistemas complejos tales como el cuerpo humano, la economía nacional, o la
evolución de las especies, pueden ser estables e incluso mejoradas, sin una entidad
de control que indique los cursos de acció n a tomarse (algunos diría n: aú n a pesar de
que existen entidades que tratan de normar cuá les son las acciones a tomar.)

Todos los CAS tienen algunas propiedades principales

1. Est á compuesto de agentes independientes (por ejemplo, empresas en una economí a
o cé lulas nerviosas en un cerebro). Estos agentes interact úan entre sí de manera no linear,
es decir, el entero es má s que la suma de sus partes. El control tiende a ser muy
disperso y el orden no se impone de arriba hacia abajo, pero de alguna manera surge de
las interacciones de sus agentes, a pesar de que cada uno tiene sus propios objetivos.
2. Existen varios niveles de organizació n dentro de un CAS y cada nivel provee los bloques
para construir el siguiente nivel. Por ejemplo, las personas forman departamentos,
los departamentos empresas y las empresas la economí a. Ademá s, las agregaciones
actú an como agentes tambié n.
3. Los agentes anticipan el futuro, tomando acciones basadas en un conjunto de reglas
internas. Estas pueden ser modelos internos simples o complejos que han sido autoimpuestos
por el agente (por ejemplo, una regla relativa al estado de mercado que hace
que se abran o cierren las contrataciones de personal en una empresa).
4. Cada CAS tiene muchos nichos y cada uno es capaz de ser explotado por unos pocos
agentes particulares. Esto diversifica los agentes, ya que se adaptarán para sobrevivir
y prosperar, lo cual a su vez hace que los nichos sean cada vez má s diversos. Un
ejemplo de algo que se mueve rá pidamente es el mercado del Internet

Un concepto muy revelante de nuestro análisis es aquel del orden emergente, el orden
que aparece por la cooperación / competencia (conocido como "coopetencia") de los
agentes del CAS. El siguiente relato demuestra este concepto de manera clara (esta
historia, al igual que la mayor a de esta secció n ha sido extra do de un libro que considero
como lectura obligatoria: "El Desarrollo de Software Adaptable" de Jim Highsmith.)
A mediados de los añ os 1980, Craig Reynolds estaba interesado en simular el comportamiento
de una bandada de pá jaros. En vez de intentar descubrir y programar reglas
para toda la bandada, Reynolds decidió programar el comportamiento de cada "boid"
(que fue el nombre con el que denomin ó a sus pá jaros simulados). Las reglas que siguieron
sus "boids" fueron:
1. Intentan mantener una separació n mí nima con otros "boids".
2. Intentan lograr que su velocidad se asemeje a la de los "boids" cercanos.
3. Intentan moverse hacia el centro de la masa de "boids" cercanos para alcanzar la
coherencia con éstos.
Por sorprendente que parezca, las bandadas de "boids" simulaban bastante bien a una
bandada real de pá jaros. El orden surgí a del comportamiento individual sin que haya
ninguna regla sobre el grupo.
Es interesante tomar en cuenta que en la mayoría de CAS, la complejidad en sí nos
impide comprender cómo funciona todo el sistema. Pero, al comprender cómo los
agentes relevantes se comportan, podemos generalmente simular el todo, y a sí volverlo
predecible.
Entonces, para regresar a la pregunta que se plan teó al inicio de esta secció n, có mo
podemos controlar un sistema no predecible (en nuestro caso un proyecto de software)?
Una respuesta simplificada se aproxima a lo siguiente:
1. Identificar los agentes relevantes: clientes, programadores, usuarios, etc.
2. Identificar patrones de comportamiento de estos agentes en proyectos exitosos.
3. Sumergir a los agentes en este comportamiento y luego soltarlos. Se espera que se
auto-organizarán, haciendo que el proyecto no solo sobreviva sino que prospere con
energí a al filo del caos.
Le parece esto algo intrigante pero poco profundo para intentarlo? Espere porque vamos
a analizar no só lo uno sino dos enfoques desarrollados de manera independiente
(pero que en todo caso tienen algunas semejanzas sorprendentes) que se basan en
estas ideas y que han sido usados ya en proyectos exitosos de desarrollo de software
(aquellos en que todo el mundo termina feliz al final del dí a).

Problemas de diseño extremos,soluciones de programación extremas

El sentido común del desarrollo de software nos dice que mientras má s tarde se introduzcan
cambios en un sistema, éste se volv erá má s caro y complicado. Eventualmente
ser má s atractiva la idea de escribir un nuevo sistema en vez de añadir nueva funcionalidad
al ya existente. Por lo tanto, deber á llevar a cabo un aná lisis completo para
averiguar las necesidades posibles (presentes y futuras) y crear un diseñ o que sea lo
suficientemente flexible como para poder incorporarlas. Debido a la velocidad actual
de cambios tecnoló gicos y de mercado, tal tarea parece má s apta para un adivino antes
que para un ingeniero de software.
Kent Beck nos invita a un mundo distinto: un mundo en el cual a ñadir funcionalidad en
la mitad o al final del proceso de desarrollo es solo ligeramente má s caro que hacerlo
al principio. Antes de iniciar un debate complicado sobre este proceso de soñ ar despierto,
consideremos por un momento cuá les serí an las consecuencias de tal utopí a.
Inicialmente, pondría atención en solamente los requerimientos actuales y luego diseñaría
una solució n que satisfaga únicamente dichas necesidades. De esta manera,
se detendrí a por fin el proceso de adivinanzas. La solució n producida serí a tan simple
como sea posible y como usted sabe, la simplicidad en el diseñ o es la clave del éxito.
Entonces, escribirí a el có digo que cumpla con los requerimientos actuales y no incluiría
ni una lí nea adicional. Los programas cortos son má s fáciles de comprender, contienen
menos errores y en general mejoran la productividad del programador. Finalmente,
el cliente recibiría en el menor tiempo posible exactamente lo requerido, que es generalmente
exactamente aquello por lo que habí a pagado. Suena grandioso, no?
Los beneficios son tan increí bles que Jim Highsmith dice que, aun cuando la propuesta
de Ken Beck no fuera cierta, deberí amos desarrollar sistemas de tal manera que sea
verdadera. Pero esto aparentemente es imposible de lograr, ya que hemos notado có -
mo un sistema inicialmente simple se vuelve cada vez más complicado mientras se
añ aden caracter ísticas, a la vez que el diseñ o se vuelve malo y aumentar la funcionalidad
se complica paulatinamente, se vuelve riesgosa, y realmente poco agradable. Có -
mo podemos evitar este proceso? Martí n Fowler define el "refactoring" como el proceso
de cambiar un sistema de software de tal manera que no se altere el comportamiento
externo del có digo pero se mejore su estructura interna. Mejor aú n, Fowler no se queda
en la propuesta sino que provee consejos detallados en un ejemplo en
"Refactoring", que es otro libro de lectura obligada de desarrollo de software. Recuerde
la idea consiste en cambiar có digo que ya funciona para convertirlo a má s adaptable a
cambios que se presenten en el futuro, y no para que corra más rápidamente ni para
ahorrar en su consumo de memoria.
Pero tal vez ahora se sienta desconfiado, ya que todos conocemos lo que ocurre cuando
se cambia có digo que funciona: el sistema comienza a fallar en sitios poco esperados
y de manera poco esperada. Falla a menos que haya estado programando mediante
el mé todo de programació n con pruebas iniciales. Esta té cnica propone que cuando
a un programador se le asigna un proyecto, deber desarrollar una serie de pruebas
para comprobar si su solució n resuelve el problema. Luego escribe un pequeñ o programa
o rutina para correr las pruebas de manera automatizada. Solamente despué s de
haber hecho todo esto, el programador comenzar á el trabajo de escribir el có digo verdadero
de la solució n. Cierto que esto requiere má s disciplina y trabajo que solamente
codificar, pero los beneficios son muchos: cuando se crean las pruebas, uno puede
pensar tambié n en la solució n, verificar si se han satisfechos los requerimientos y finalmente,
cuando se hace "refactoring" uno puede estar seguro de que no se ha "roto" el
funcionamiento. El "refactoring" y la programación con pruebas iniciales son ejemplos
claros de té cnicas de desarrollo complementarias y son parte de las doce prácticas de
la Programación Extrema, o XP según sus siglas, una metodología de desarrollo que
promueve un enfoque de regresar a los conceptos básicos.
El XP confronta directamente las metodologías monumentales, también conocidas como
metodologí as Gran M, ya que propone un conjunto mí nimo de prácticas dirigidas a
impactar directamente en la productividad de los programadores y la calidad de su trabajo
en vez de controlar todo el proyecto por medio de documentación e hitos. En el
capítulo 10 de "Extreme Programming Explained" (Programación Extrema Explicada),
Kent Beck resume las doce prá cticas:
1. El Juego de la Planificació n: determine rá pidamente el alcance de la pró xima versió n
al combinar las prioridades de negocio con los estimados té cnicos. Cuando la realidad
supere al plan, actualí celo.
2. Pequeñas versiones: ponga en producción a un sistema simple rápidamente, luego
lance al mercado nuevas versiones durante un ciclo corto.
3. Metá fora. Guíe todo el desarrollo con una historia simple de cómo funciona todo el
sistema.
4. Diseñ o simple: el sistema deber diseñ arse de tal manera que sea lo má s simple posible
en cualquier momento dado. La complejidad adicional se retirar tan pronto sea
descubierta.
5. Pruebas: los programadores continuamente escribirá n pruebas de unidad, que deben
correr sin problemas para que el proceso de desarrollo pueda continuar. Los clientes
escribirá n pruebas demostrando que se ha completado la implementació n de las caracterí
sticas.
6. "Refactoring": los programadores cambiará n la estructura del sistema sin cambiar su
comportamiento para eliminar la duplicación, mejorar la comunicación, simplificar, y
añ adir flexibilidad.
7. Programación por pares: todo el código de producción ser á escrito por dos programadores
que compartirá n una sola má quina.
8. Propiedad colectiva: cualquiera puede cambiar có digo de cualquier parte del sistema
en cualquier momento.
9. Integració n continua: se integra rá y crear á las nuevas versiones del sistema muchas
veces por dí a, siempre que se haya completado una tarea.
10. Semanas de 40 horas: solamente se trabajará 40 horas por semana, como regla.
Nunca se trabajará horas extras dos semanas seguidas.
11. Cliente en el sitio: incluya un verdadero usuario como parte del equipo, que esté
disponible a tiempo completo para contestar las preguntas.
12. Está ndares de codificació n: todos los programadores deberá n escribir có digo que
cumplan las reglas y se enfatizar la comunicació n durante su creació n.
Algunas de las prá cticas indicadas son de sentido comú n: cliente disponible en el lugar,
está ndares de codificació n. En cambio, otras son técnicas redescubiertas: ejecució
n de pruebas y simplificació n en el diseño, "refactoring" y el juego de la planificació
n. Otras prácticas pueden ser controversiales: programació n por pares, y propiedad
colectiva. Beck presenta razones para alentar la aplicació n de estas prá cticas e incluye
detalles explí citos sobre có mo emplearlas. El resultado general de la metodologí a: haga
lo mí nimo que puede llegar a funcionar, obtenga toda la retroalimentació n que pueda,
cambie calendarios y haga "refactoring" libremente. No hay un plan a largo plazo o
un horario fijo y se prefiere la comunicació n personal a la escrita. Desde el punto de
vista de las metodologí as monumentales, este comportamiento es perezoso (sino se lo
puede considerar "malo"). De todas maneras, lo importante es: Se consiguen los resultados
esperados de esta manera?
Hace cerca de diez añ os, Alistair Cockburn fue contratado por IBM para que cree una
metodologí a para el desarrollo orientado a objetos. Parte de su enfoque fue entrevistar
al mayor nú mero posible de miembros de equipos de proyectos, anotando todo lo que
decí an contribuí a a su éxito o fracaso. Segú n sus palabras:
"En el estudio de IBM, todo equipo exitoso "se disculpaba" por no seguir un proceso
formal, por no usar una herramienta tipo CASE de alta tecnologí a, por simplemente
mantenerse cerca y analizar cualquier cosa que surgí a. Mientras tanto, una buena cantidad
de equipos con problemas no lograban encontrar el motivo de sus fallas a pesar
de seguir un proceso formal, tal vez se olvidaron de algú n paso? Finalmente comencé
a conocer equipos que se daban cuenta que su éxito se habí a dado justamente por no
seguir procesos elegantes con entregas formales, pero que m ás bien discutí an con libertad
y entregaban software, luego de realizar varias pruebas."
Estos resultados han sido consistentes, desde 1991 a 1999, desde Hong Kong al continente
Americano, en Noruega, y en Sud frica, tanto para sistemas en COBOL como
Smalltalk, Java, Visual Basic, Sapiens y Synon. Para resumir los resultados podemos
decir:
Siempre que pueda reemplazar la documentació n escrita con comunicació n oral, há galo.
As reducir la dependencia en productos escritos y mejorará la probabilidad de llegar
a entregar el sistema.
Mientras má s frecuentemente pueda entregar pedazos del sistema que corran y hayan
sido probados, depender menos de "promesas" y podrá entregar el sistema.
Las personas son entes que se comunican. Incluso los programadores más introvertidos,
funcionan mejor en un ambiente en donde haya comunicació n informal llevada a
cabo cara a cara que en aquel donde exista solamente comunicaciones escritas. Desde
un punto de vista de costos y horarios, el escribir algo toma má s tiempo y comunica
menos que una discusió n con ejemplos en la pizarra blanca.
Aparentemente, comportamientos similares a aquellos propuestos por XP han resultado
exitosos en muchos lugares y en muchas pocas. Se acuerda de lo que discutimos
sobre agentes en un ambiente no predecible? Mencionamos que los agentes definen
sus reglas de comportamiento y los van refinando para poder llevar a cabo su trabajo
adecuadamente en su nicho. Aquí podemos observar có mo cada equipo de desarrollo
ha descubierto de manera independiente el mismo conjunto bá sico de reglas que les
permite auto-organizarse y del cual surge un orden, en vez de que se imponga desde
arriba autoritariamente. Si seguimos la teorí a de CAS, deberí amos tratar de incluir estas
reglas en nuestros equipos de desarrollo, para poder mejorar sus probabilidades de
éxito.

La Programación Extrema y los
Centros de Desarrollo Virtual

Para nosotros, es especialmente relevante analizar có mo se puede aplicar XP a los
CDV(Centros de Desarrollo Virtual) que son aquellos equipos que está n geográ ficamente
separados y que pueden llegar a tener varias docenas de desarrolladores. Kent Beck
señ ala que XP asume que los grupos son pequeñ os (de 20 personas má ximo) que trabajan
en el mismo lugar, por lo que resulta interesante preguntarnos qué ocurre con
grandes proyectos y con grupos que trabajan en diferentes lugares.
Analicemos primero el problema del tamañ o de grupo. A pesar de que XP recomienda
usar todas sus prá cticas, si es posible usar solamente un subconjunto de éstas. Ademá s
se puede modificarlas un poco para obtener todos los beneficios del XP puro. En la
Conferencia "JavaOne 2001", Michael Lauer presentó una conferencia sobre el uso de
XP para grandes proyectos de J2EE. Describió los detalles de un proyecto exitoso que
excedí a considerablemente el tamañ o recomendado por Beck. En resumen, Lauer propuso
lo siguiente:
1. Contar con un dise ño serio desde el inicio en vez de concentrarse en la metá fora propuesta
por XP.
2. Contar con un grupo principal de arquitectos senior para desarrollar una serie de patrones
de arquitectura de componentes, por ejemplo patrones de persistencia de objetos
o patrones en cuanto a la interfaz de usuario MVC. Se entregará n estos patrones a los
desarrolladores.
3. Usar un subconjunto de prá cticas de XP. Algunas de las excluidas fueron: programació
n por pares obligatoria, la semana de 40 horas (qué pena !) y, lo m ás sorprendente,
el cliente disponible en el mismo local.
Lauer afirma que de esta manera logró :
1. Mantener contentos a los gerentes, ya que un arquitecto administraba de 20 a 40 desarrolladores.
2. Disminuir los costos de entrenamiento (aun cuando solo 1 o 2 de cada 10 solicitantes
tení an el perfil correcto para el proyecto).
3. Acortar los ciclos de desarrollo.
4. Crear software m s robusto.
5. Capacitació n continua
6. Eliminació n del mito del mes-hombre, logrando un gran grado de paralelismo en el
desarrollo.
Y por supuesto, Lauer y sus clientes estaban contentos y sentí an que habí an logrado algo
importante. Entonces, parece que el factor del tamañ o de equipo podrí a eliminarse
si se varí a en cierto grado a XP.
Cuando se analiza la dispersió n geográ fica del equipo, tenemos que recordar que lo que
requiere XP es que exista comunicació n fluida de persona a persona. Debido a las mejoras
continuas de las telecomunicaciones y las herramientas de Internet que van desde
las má s simples ("chat") a las má s sofisticadas (reuniones virtuales), estar presentes
electró nicamente en el mismo ambiente es casi igual a estar fí sicamente en el mismo
cuarto. La experiencia se está mejorando cada vez má s. Sin embargo, el hecho de estar
en diferentes husos horarios sí podr a afectar la comunicació n, sin importar que tan
buena sea la infraestructura de comunicaciones.
Kent Beck trata de delimitar claramente d nde funciona y en qué condiciones no funciona
XP. Por ejemplo, funciona muy bien cuando se trata de equipos localizados en un sitio
y el proyecto a desarrollarse no es un sistema de misi ón crí tica. Y que pasa si su
proyecto cumple con todas las especificaciones? Serí a interesante poder iniciar el trabajo
con el modelo XP (o algo equivalente) y luego adaptarlo durante la ejecució n para
que satisfaga las demandas del proyecto. Pero parece difí cil cambiar la metodologí a de
desarrollo en medio del proyecto. Usando terminologí a de la metodologí a CAS, lo que
necesitamos es no solo descubrir y emular el comportamiento de los agentes exitosos
pero tambié n conocer los procesos que usan los agentes para intentar encontrar y adoptar
nuevas reglas. Si logramos esto y podemos emular dichos procesos, podremos crear
equipos que no solo creen buen software sino que tambié n adapten los procedimientos
a su ambiente especí fico. De esta manera su rendimiento mejorará cada vez má s y ésta
es justo la idea detrá s de la metodologí a de Desarrollo de Software Adaptable (o ASD
segú n sus siglas en inglé s) que es nuestro siguiente tema

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).

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.

C o n c l u s i o n e s

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.


Salu2s y que la buena suerte los acompañe siempre (y espero que a mi también :D)
y recuerden: saqué uds sus propias conlclusiones