Fundamentos de la I.A. (Inteligencia Artificiosa??)

Las aplicaciones informáticas (eso si, a golpe de cañon!) van madurando. Ya consiguen, en la mayoria de las ocasiones, hacer lo que dicen que hacen y comienzan a ser realmente útiles y hasta necesarias. Partiendo de esta base, el usuario, como es lógico, desea que la aplicación sea más y más eficiente. Demanda ciertas características asociadas tradicionalmente con lo que denominamos "inteligencia". Que el software no solo responda de manera determinista, sino que sea capaz de ayudarle, de preveer sus necesidades con antelación y responder con reflejos a la realidad del día a día.

De nuevo, la pelota está en nuestro tejado...(la de los desarrolladores de software, no mires hacia arriba!!)

Nuestras aplicaciones, independientemete de la funcionalidad que cubran, deben comenzar a adoptar dichas caracteríaticas puesto que será una cualidad excluyente a plazo medio. Es fácil de decir, pero no tan sencillo de transformar en instrucciones que admita un compilador... Por ello vamos a analizar algunas de las características que debe cumplir un software para poder decir que es "inteligente" y a que problemas comunes se deben enfrentar independientemente del campo en el que se apliquen.

Haciendo un poco de historia, hacia 1950 parecía que la mecanización de la inteligencia estaba a tiro de piedra pero todavía más de 50 años después no hemos conseguido interiorizarla a nivel general. ¿Existirá alguna razón oscura para no poder lograr alcanzar esa misteriosa meta? Realmente no hay quien sepa donde está la raya divisoria entre la conducta inteligente y la no-inteligente (pensar que exista una raya puede ser una error en si mismo) Lo que si sabemos es que existen algunas características que denotan inteligencia:

• Responder con mucha flexibilidad a las situaciones.
• Sacar provecho de circunstancias fortuitas.
• Hallar sentido en mensajes ambiguos o contradictorios.
• Reconocer la importancia relativa de los diferentes elementos de una situación.
• Encontrar semejanzas entre varias situaciones, pese a las diferencias que puedan separarlas.
• Encontrar diferencias entre varias situaciones, pese a las semejanzas que puedan vincularlas.
• Sintetizar nuevos conceptos sobre la base de conceptos viejos que se toman y reacomodan de nuevas maneras.
• Tener ideas novedosas.
• (Ahí queda eso...)

Existe aquí una paradoja, puesto que los ordenadores son por naturaleza máquinas inflexibles y recae sobre el software simular estas características. Los expertos en I.A. crean gran cantidad de reglas inflexibles para conseguir que las máquinas sean flexibles. Dichas reglas deben estar organizadas en diferentes niveles, Tiene que haber reglas "llanas"," metarreglas" con las que modificar las reglas "llanas" y probablemente "meta-metareglas" con las que modificar las "metareglas"...(¿Hasta donde?)

La razón de tantas reglas que operan a tantos niveles distintos es que el ser humano (que asumimos posee inteligencia) se enfrenta cada día a millones de situaciones distintas, de diferentes tipos. En ciertas ocasiones nos servirán las reglas "llanas", en otras ocasiones deberemos aplicar un conjunto de reglas "llanas" modificadas o ajustadas por ciertas "metareglas". En otras ocasiones, sin embargo, deberemos crear nuevas reglas a partir de las existentes enriqueciendo así el conjunto disponible.

En el meollo de la inteligencia hay, sin duda, extraños bucles fundados en reglas que directa o indirectamente se modifican a si mismas.
Aunque la complejidad de nuestro entendimiento parece a veces tan abrumadora que el problema de entender nuestro inteligencia parezca no tener solución. Pero tengamos fé. Se han dado pasos hacia su resolución y sin duda se darán más, es cuestión de trabajo y tiempo!!

8 maneras de cargarte la metodología de un plumazo

No es fácil implantar una manera común de desarrollar proyectos de Software. Cada maestrillo tiene su librillo y no siempre nos es fácil adaptarnos al mínimo común necesario para trabajar en equipo de manera orquestada.

Por contra, lo que sí que es realmente fácil , es dinamitar el camino andado. Hace falta muy poco para saltarse alguna que otra regla y echar abajo lo ganado con tanto esfuerzo. Existen algunos puntos claves en los que los equipos somos especialmente propensos a ceder, veamos algunos…

(*Hablando en SCRUM)

1. No preparar suficiente Product Backlog para que el equipo adquiera prespectiva del proyecto.
   Aunque parezca mentira a los desarrolladores nos gusta saber qué leches estamos programando. De hecho las mejores propuestas de mejora de las aplicaciones surgen, al menos en las primeras fases del proyecto, del propio equipo de desarrollo. Para poder aprovechar toda esa energía/sinergia los desarrolladores deben poder hacerse una idea global del proyecto.
   
2. No profundizar lo suficiente el el Sprint Planning Meeting por cansancio o falta de concrección en la exposición del Product Owner.
   La reunión previa en cada sprint permite al equipo hacerse una idea lo más concreta posible de las funcionalidades que más valor aportan al proyecto. Nos permite alinearnos con las necesidades del cliente de tal forma que todos aunemos esfuerzos en la misma dirección. También permite mitigar los riesgos e identificar sorpresar antes de asumir un compromiso. Un buen hábito que no siempre se realiza es el de poner una meta al sprint ( por ejemplo “Disponer del sistema de automatización de informes” ) que identifique la situación ideal al final del mismo y ayude al desarrollador a responder preguntas que le “tienten” por el camino. (¿Es esto importante para la meta del sprint?)
   
3. Falta sistemáticamente al Daily Scrum o no respetar sin aviso las pocas liturgias que especifica SCRUM.
   Una de las características que hace a SCRUM “medio” bala de plata tan demandada por los desarrolladores, es las pocas imposiciones que propone. De éstas, una de las más importantes, es la de realizar una pequeña reunión diaria en al que cada miembro del equipo explica que ha hecho el día anterior, que impedimentos se ha encontrado y que pretende hacer en el mismo día de la reunión. Este Daily Scrum es el que da jabón al equipo y permite que todo el mundo este al día del avance, evitar duplicar batallas…
   
4. Estancar conocimiento asumiendo un mismo desarrollador todas las Sprint Backlog Item de un Product Backlog Item.
   Es importante que nadie sea imprescindible. Que todos los miembros del equipo desarrollen tareas de todos los Product Backlog Items permite evitar que se creen “Reinos de Taifas” y estandariza el código. Además los equipos de desarrollo con un poco de verguenza torera se igualan por el mejor, lo que permite que se produzca aprendizaje por el camino, mejorando la calidad final del proyecto.
   
5. Inventarse tareas sobre la marcha o modificar las existentes bajo demanda.
   Cuando un equipo de SCRUM asume un compromiso con el cliente a través de un sprint, dicho compromiso es inmutable por ambas partes. Es por esto que los sprints son tan cortos, para permitir reorientar el proyecto entre sprints.
   
6. Intentar esconder las desviaciones o sufrir el “sindrome del investigador“.
   Si existen desviaciones, lo mejor es saberlo y ser consciente de las causas que las han provocado. En la mayoría de ocasiones dichas desviaciones se pueden justificar y son el argumento principal para mejorar los procesos del equipo. Otro de los aspectos que debe afrontar cualquier metodología es lograr una adecuada visibilidad. Esta característica es la que debe permitir permite que los StakeHolders conocozcan la situación del proyecto. Adoptar una visibilidad adecuada permite detectar las desviacioes de manera temprana así como planificar las acciones orientadas a corregirlas. Como equipo debemos ser capaces de justificarlas y transmitir los motivos a los StakeHolders adecuados, así como las acciones y planes creados. Suele ser un buen hábito, especificar a nivel de Product Backlog Item las condiciones de aceptación, en las cuales se especifican las poscondicones necesarias para que una historia pueda darse por terminada. Por supuesto, deben cumplirse todas para que se pueda dar por finalizada.
   
7. No retroalimentar Sprint Backlog Items después de realizarlos.
   Es verdad que siempre vamos con prisa, que existen muchas tareas y todas las excusas que quieras poner, pero para poder decir “Hecho” (y hecho es hecho!!) cada desarrollador debe actualizar como parte de la tarea el estado de los Sprint Backlog Items asociados. Mantener al día dicha información nos permite, analizar las desviaciones y observar la tendencia del sprint y el producto. Colateralmente nos ayuda a ganar y mantener la visibilidad del proyecto manteniendo a los diferentes StakeHolder lo más al día posible.
   
8. Evitar las Sprint Retrospective o demostrar falta de compromiso.
   En SCRUM la unión y el compromiso del equipo es clave puesto que todos los miembre del mismo interactuan ampliamente con los demás. El Sprint Retrosprective es la liturgia clave para recibir feedback del mismo y aumentar la unión y sentimiento de grupo. Estas reuniones pueden mejorar mucho los procesos afinando el día a día del equipo, identificando los posibles cuellos de botella y planificando como evitarlos.
   Como siempre, la clave es la constancia, no ceder al desaliento y aplicar las técnicas espartanas de confianza en tus compañeros de equipo. Solo así se puede lograr el “milagro” de echar a andar y mantener una forma de trabajo metodológica.

Como siempre, la clave es la constancia, no ceder al desaliento y aplicar las técnicas espartanas de confianza en tus compañeros de equipo. Solo así se puede lograr el “milagro” de echar a andar y mantener una forma de trabajo metodológica.

Publicado originalmente en Synergos

La metodología (Ágil) va a llegaaaaar…

Como ya predijo el filósofo Arrabál, las cosas están cambiando.

Poco a poco, el sector del desarrollo del software se va haciendo un hombrecito. Desde luego este proceso no se ha postpuesto por falta de esfuerzos. La industria, cual madre concienciada, haciendo palanca a través de la Ingeniería del Software ha intentado estandarizar de muchas maneras el “artístico” proceso de crear software. Algunos de estos intentos han sido más forzados que otras (UML, CMMI, Métricas de calidad… ), pero casi todos han demostrado la misma poca efectividad.

Dichos intentos “encauzadores” de mama industria han quedado a medio camino por la misma razón: contaban con que el terreno sobre el que se apoyaban era firme, cuando realmente lo hacían sobre arenas movedizas. En relación a otras ciencias (y entornos productivo-económicos) el desarrollo de software avanza muy rápido.

Alcanzar esta velocidad de crucero implica que hay mucho que mejorar y obliga al sector a reinventarse contínuamente. La tecnología, los modelos de negocio, el alcance de la funcionalidad de las aplicaciones, la automatización de procesos, la integración y orquestación de unidades de negocio… todo está en expansión. Como todos sabemos, no se puede estandarizar lo que no deja de cambiar, por lo que los intentos realizados se han ido quedando anticuados antes de alcanzar su madurez.

Pero en ese reinventarse ha cambiado la prespectiva…

Un buen día nos damos cuenta de que estamos peleando contra la realidad. Nos liberamos y dejemos de atacar y evitar el cambio como un enemigo. Es una actitud provocada por el convencimiento que surge desde dentro de que no hay otra opción. Debemos asumir (cuanto antes mejor) el cambio como algo que está ahi, nos guste o no, no podemos evitarlo. ¡¡Todo cambia!!

En las metodologías “predictivas” se destinan gran parte de los recursos a ser capaz de predecir lo que se va a desarrollar en los próximos años. Por muy concienzudo que sea dicho estudio, el contexto varía, las necesidades del cliente cambian, surgen nuevas oportunidades y riesgos. El que mayor capacidad de cambio demuestre, contará con una ventaja competitiva significativa.
Por lo tanto, permitir que nuestro cliente marque el siguiente paso (o mejor dicho, pasito) a dar nos permite ajustar el camino a recorrer a las necesidades que sobre la marcha surgan, aportando un mayor valor al software y satisfacción al cliente, que es nuestro objetivo… ¿o no?


Publicado originalmente en Synergos

.NET Framework 4.0 y C# 4.0 (1 de 5)

Podemos incluir las nuevas caracteristicas que se incluyen en C# 4.0 en cuatro grupos principales:

• Dynamic lookup
  Nos permite escribir métodos, operadores, acceso a propiedades y campos y cualquier invocación a objetos que se salte la comprobación estática de tipos de C# resolviendose en tiempo de ejecución. (¿esto es bueno o malo...? ya hablaremos, pero lo bueno es poder elegir, no? )
  


• Parámetros con nombre y opcionales
  A partir de C# 4.0 los parámetros puedrán ser especificados como opcionales, asignandoles un valor por defecto en la declaración de miembro. Por supuesto, cuando el miembro sea invocado, los argumentos opcionales pueden ser omitidos. Los de VB.net que dejen de sacar pecho, porque además cualquier parámetro podrá ser pasado por nombre en lugar de posición. (nada de opcionales al final...)
  


• Caracteristicas especificas de Interoperabilidad con COM
  La combinación de las dos mejoras comentadas anteriormente permiten hacer más cómoda la programación contra objetos COM. Además en el framework 4.0 se incluirán otras pequeñas características que mejorarán aún más esta "dura" experiencia.
  


• Varianza y Contravarianza
  Quien haya profundizado en la O.O. usando genericos se dará cuanta de lo necesaria que era esta caracteristica. Ahora C# admite "co y contravariance" (por ejemplo Lista de objetos <-> Lista de string). Además los tipos de la B.C.L. son actualizados para que tengan en cuenta esta característica.

Continuaremos profundizando en posteriores posts.

.NET Framework 4.0 y C# 4.0 (0 de 5)

Visual Studio 2010 y el .NET Framework 4.0 estarán pronto en beta y con ellos se incluirán nuevas características. Una de ellas, es la nueva versión del lenguaje de programación C# (4.0, que se dice pronto!!). Para ponernos un poco en situación voy a escribir una serie de post en los cuales reflejar las evoluciones más significativas del mismo.

Para hacer las cosas como se deben vamos a hacer un poco de historia:

El equipo C# comienza en 1998 con el objetivo de crear un nuevo lenguaje de programación simple, moderno, orientado a objetos y type-safe (seguridad de tipos) para la plataforma .NET.

Microsoft lanza la plataforma .NET y el lenguaje de programación C# en verano de 2000 con gran éxito puesto que a día de hoy es uno de los más usados.

Uno de los principales éxitos de C# ha sido las buenas fuentes en las que se basa ( C++, Java...) así como el continuo y rápido proceso de evolución que la gente del equipo responsable de Microsoft le aplican.

Con la versión 2.0 del lenguaje se incluye el soporte para genericos, metodos anónimos, iteradores, tipos parciales y tipos nulables.

En la siguiente versión, la 3.0 el lenguaje se centra en habilitar LINQ para lo cual requiere todo lo anterior y una serie de nuevas características:

• Variables locales de tipo implicito.
• Métodos de extensión. (se emplea para implementar los proveedores de LINQ de manera debilmente acoplada)
• Expresiones Lambda. (de esto ya hablaremos en otro post)
• Inicializadores de objetos y colecciones.
• Tipos anónimos.
• Arrays implicitamente tipados.
• Expresiones de consulta y árboles de expresiones.

Ahora que hemos conseguido un poco de prespectiva comenzaremos a hablar en el siguiente post de las novedades de C# 4.0.

Nota:

El nombre de C# es un guiño a modo siguiente evolución de C++. (C con 4 +)
C =>C++=>C++++