Encuentro Empresarial TIC Universidad - Empresa

Hace más de un año escribí un artículo acerca de algunas ideas que facilitasen que el mundo de la Universidad y la Empresa se acercasen. Este artículo, que se puede leer aquí, incidía en algunas cuestiones importantes, que gratamente encontré reflejadas en la mesa redonda a la que asistí este jueves 28 de Octubre. Se trataba de en un encuentro empresarial en el que los ponentes, todos ellos importantes cargos del mundo de la Empresa y la Universidad de Alicante, exponían su visión acerca del problema y posibles soluciones.
Hubo una idea que considero clave, y es que desde la Empresa no podemos esperar a que la Universidad nos traiga todas las soluciones. Debemos influir y tomar parte de ella, y desde ese punto de vista creo que la Universidad está dando muchos pasos para abrirse y dejar pasar nuevas ideas. La Universidad aporta Conocimiento, y la Empresa Experiencia. Sí, Conocimiento y Experiencia con mayúsculas, que juntas forman el binomio perfecto que tanta falta hacer a nuestra sociedad.
Los estudios de doctorado no deben ser exclusivos de aquellos estudiantes que prolongan y prolongan sus estudios, y al final su única salida laboral sea la Universidad. Me atrajo la idea de que desde el mundo universitario se está dando facilidades y opciones para que personas totalmente integradas en el mundo laboral puedan desarrollar estudios de doctorado. ¿ Qué mejor manera es esa de llevar los conocimentos más avanzados de I+D a la empresa ?

Agilidad y Buenas Prácticas de Desarrollo

Las prácticas ágiles deben ir acompañadas con buenas prácticas en programación. Hablamos de la estrecha relación de la agilidad con TDD, BDD, ATDD, refactorización, etc. Todas ellas técnicas y prácticas propias de desarrollo.
Recientemente, he conocido "Domain-Driven Design" (DDD), impulsado por un grupo de expertos, entre los que se encuentra Eric Evans ("Domain-Driven Design: Tackling Complexity in the Heart of Software"), y que cumple a la perfección los principios de las metodologías ágiles.
Como explican sus creadores, Domain-Driven design no es ninguna tecnología, ni metodología. Se trata de una forma de pensar y organizar un conjunto de prioridades, dirigidos a la aceleración de proyectos de software que tienen que tratar con complejos dominios (http://domaindrivendesign.org/resources/what_is_ddd)
Propugna la comunicación directa entre los expertos del dominio (el cliente), los analistas y desarrolladores, utilizando un lenguaje común (lenguaje ubícuo) que permita un entendimiento completo del dominio, hacia la elaboración iterativa del diseño que conduzca a la correcta codificación del problema planteado.
Como dice Eric Evans en su libro "Domain-Driven Design Quickly" (de descarga gratuita en InfoQ), no basta con conocer las técnicas adecuadas de programación si no van acompañadas de unos sólidos conocimientos de arquitectura y sus principios. Esta arquitectura reconoce la complejidad en la elaboración del software, y trata de
Para los que trabajamos con .Net, existe una mágnifíca guía, en estos momentos en fase Beta, llamada "Guía de Arquitectura N-Capas orientada al Dominio con .Net 4.0", que trata de llevar a su implementación práctica el DDD. Todo el material relacionado se puede encontrar en el "Centro de Arquitectura - MSDN".

Liderazgo a cuenta de la Selección Española

Leía esta mañana un artículo en El País sobre el liderazgo ejercido por Vicente del Bosque para conseguir que nuestra selección ganase el Mundial. Es posiblemente un perfecto análisis hecho a posteriori a sabiendas que las cosas han ido pefectas, y que no hubiéramos leido si la dichosa "pelotita" no hubiera entrado en cuartos de final contra Paraguay. Creo que todo el mundo habría aclamado la vuelta de Luis Aragonés, y habrían mandado a del Bosque a remar galeras, cuando es indudable que en ciertos deportes como el fútbol, hay un factor azar muy importante, que no debería desmerecer el trabajo de los jugadores y por supuesto del entrenador. Pero, como el topicazo dice, "el fútbol es así", y la propia vida ¿ no es así ?


Pero dejando atrás cuestiones filosóficas, estoy bastante de acuerdo con el análisis que se realiza en el artículo sobre diferentes estilos de liderazgo. Y me quedo con los siguientes puntos:

• El líder como gran conocedor de la materia. Corren ríos de tinta sobre este punto, pero en el mundo de la tecnología en que yo me muevo y conozco, lo considero necesario. Sin entrar en mucha profundidad, considero que confiere al líder, autoridad, respeto, y simplifica la toma de decisiones.



• El líder debe saber obtener lo mejor de su equipo. Contar con los mejores y conseguir de ellos los mejores resultados. Ayudar a mejorar a los recién llegados, y los que puedan tener alguna carencia concretar. Yo diría, también, invitar a abandonar a aquellos cuya actitud bombardea y desestabiliza el funcionamiento del grupo.

• No hay un estilo de liderazgo universal y que funcione en todos los casos. Cada situación exige unas directrices diferentes, y en ciertos momentos se debe pasar de un estilo conciliador, a otro que requiera un mayor control.

Me imagino que proliferarán en los próximos meses más artículos y libros pretendiendo explicar el éxito de la selección expañola de fútbol, y seguro que algunos de ellos obtendremos ideas que nos lleven a la reflexión y a la mejora contínua.

Sobre la Inteligencia de Jeff Hawkins y Sandra Blakeslee

La Inteligencia Artificial es lo que realmente me llevó a estudiar Informática. La idea de hacer máquinas inteligentes como las de Star Wars me apasionaba. Al final, la vida me llevó a objetivos más pragmáticos, dentro de la informática, aunque tengo que decir que no menos apasionantes.


Pues bien, el interés por la IA nunca me ha abandonado, y ésto es lo que me ha llevado a leer el libro "Sobre la Inteligencia" de Jeff Hawkins y Sandra Blakeslee.


Desde luego, esperaba encontrame un contenido más técnico, pero se queda principalmente en la faceta de divulgación científica. No obstante, tengo que decir que en ningún momento me ha defraudado. Merece la pena y no entiendo porque la edición española, publicada por Espasa, está descatalogada y resulta imposible encontrarlo en ninguna librería. Finalmente, he tenido que recurrir a la biblioteca de la Universidad de Alicante.


Antes de entrar a comentar el contenido del libro me gustaría resaltar un párrafo de la parte inicial de "Agradecimientos", en la que Jeff Hawkins describe perfectamente el papel de un jefe de proyectos: "Cuando alguien me pregunta cómo me gano la vida, nunca sé que responder. La verdad es que me la gano haciendo muy poco, pero me he rodeado de gente que sí parece hacer muchas cosas. Mi contribución es llamarles la atención de cuando en cuando y tratar de redirigir al equipo por un nuevo camino cuando resulta necesario. Si he obtenido algún éxtio en mi carrera se lo debo en buena parte al trabajo duro y a la inteligencia de mis colegas". Creo que es una descripción genial de un jefe de proyectos, que realmente actúa como líder e impulsor de su equipo.
Después de leer el libro, me queda la sensación de que todavía queda un largo recorrido por entender el funcionamiento del cerebro. Tampoco tengo claro que el camino para hacer máquinas inteligentes sea imitar el funcionamiento del cerebro humano. ¿ No deberían poder existir "inteligencias" diferentes a la humana ? Pero dejando razonamientos filosóficos, creo que un buen punto de partida es desentrañar el funcionamiento de uno de los artefactos más perfectos que conocemos, que es nuestro cerebro. Además, lógicamente, de los beneficios que proporcionará en nuestra calidad de vida.
Entrando ya en materia, yo mo quedo con estas ideas transmitidas en el libro:

• La IA no tiene éxito porque únicamente se fija en la conducta , en los resultados y no en lo que sucede en la "caja negra" que es nuestro cerebro.
  
• Las redes neuronales se acercan más al objetivo porque tienen en cuenta la retroalimentación que se genera en el intercambio neuronal (sinapsis), tanto hacia arriba, como hacia abajo, de las capas que conforman la corteza cerebral.
  
• Nuestra corteza cerebral almacena en las sinapsis nuestra memoria, y lo que realmente se almacenan son patrones, de tal forma que no necesitamos tener la secuencia completa de algo para llegar a su información. Almacenamos relaciones, más que detalles.
  
  
• El neurocientífico Vernon B. Mountcastle describió un algoritmo único que rige todo nuestro cerebro, independientemente del sentido que estemos usando. Lo prueba, por ejemplo, el hecho de que personas con minusvalías psíquicas estén utilizando parte de sus cerebros para cuestiones que en el resto de personas "normales" están situadas en otras zonas de la corteza. El funcionamiento de la corteza cerebral se basa en una estructura jerárquica de flujo de información entre las 6 capas que componen la corteza cerebral. La siguiente imagen, obtenida del artículo "Hierarchical Temporal Memory", ilustra este hecho:

• Los tres principales elementos de la memoria son: Almacenamiento de secuencias, memoria autoasociativa, y representaciones invariables.
  


• Los humanos somos capaces de llegar a una solución mucho antes que una computadora porque se utiliza la memoria, y somos capaces de generar predicciones. Esa dupla memoria-predicción es la base de la inteligencia. Realmente las neuronas se activa antes de recibir la experiencia sensorial. En este aspecto, los autores comentan que la famosa prueba de Turing para describir máquinas inteligentes, esta equivocado, puesto que realmente es la predicción y no la conducta, la que debe probar si una máquina es inteligente o no. Como dicen los autores: "La inteligencia se mide por la capacidad predictiva de una memoria jerárquica, no por una conducta semejante a la humana".
  


• La predicción requiere de la realimentación del flujo neuronal a través de las 6 capas de la corteza cerebral: lo que sucede fluye hacia arriba, y lo que se espera que suceda hacia abajo.


• La únidad básica de predicción es la columna cortical. Para que una columna prediga cuando debe activarse necesita saber qué está pasando en otro lugar, y por eso las conexiones sinápticas van de un lado a otro de la corteza cerebral.


• Sobre el aprendizaje una cuestión importante, es que con el tiempo nuestro conocimiento desciende por la jerarquía cortical, y por lo tanto en la cima tenemos la oportunidad de aprender estructuras de orden superior. Es esa estructura de orden superior la que nos otorga experiencia. Es el hipocampo el que nos permite generar memorias nuevas.


• La creatividad se puede definir llanamente como la facultad de elaborar predicciones por analogía, algo que ocurre en todas partes de la corteza cerebral. La creatividad viene condicionada por factores educativos y factores genéticos. En este aspecto, una curiosidad acerca del cerebro de Einstein es que tenía más células de apoyo (neurogliocitos) por neurona, que la media.
  


• Para explicar la imaginación basta con dejar que nuestras predicciones den la vuelta y se conviertan en entradas. Es lo que Grossberg denominó "realimentación plegada", vemos lo que imaginamos.
  


• Para construir memorias jerárquicas como la humana, los retos son: Capacidad (para simular las sinapsis), y Conectividad (para simular la materia blanca subcortical).
  


• Son cuatro los atributos en los que los sistemas de memoria construidos bajo estas premisas superarán a nuestro cerebro: velocidad, capacidad, posibilidad de duplicación y sistemas sensoriales.

Éstas son simplemente, alguna de las ideas con las que me quedo, pero el libro contiene mucho más por explorar.

La versión inglesa del libro tiene web propia: http://www.onintelligence.org/

Por otra parte, comentar que fruto de sus investigaciones, Jeff Hawkins ha fundado la empresa Numenta, cuyo objetivo es el desarrollo de las memorias jerárquicas descritas en el libro. En la web de dicha empresa se pueden descargar algunas aplicaciones que demuestran su funcionamiento.
Y por último, también he encontrado ese vídeo de Jeff Hawkins en Ted.com:

La Auténtica Felicidad

Se trata de un estupendo libro del Dr. Seligman, que leí hace un tiempo, y que realmente me abrió los ojos hacia ciertos aspectos de la vida. Es uno de los impulsores de la llamada psicología positiva, que trata de analizar e investigar las emociones positivas del ser humano, y a través de ellas mejorar por supuesto nuestra calidad de vida.
En Ted.com se puede ver una charla de Seligman explicando precisamente conceptos de la psicología positiva.

The Predictability Paradox

Viendo en YouTube la charla de Ángel Medinilla sobre Contratos Ágiles se menciona como referencia de interés el artículo escrito por Mary Poppendieck "Lean Development & the Predictability Paradox". Se trata de un gran artículo, en todos los sentidos, tanto en extensión (39 páginas), como en las ideas que en él se transmiten. Ideas, sencillas, pero potentes a la vez, extraidas de Lean Manufacturing y su práctica en la marca japonesa Toyota.
Todo el artículo gira alrededor de lo paradójico que puede resultar intentar alcanzar la máxima predictabilidad en un proyecto software. Como dice la autora: "La paradoja es que intentar con demasiado esfuerzo crear predictabilidad origina el efecto opuesto".

El camino propuesto comprende los siguientes principios: comenzar pronto, aprendizaje constante, comprometerse lo más tarde posible, y entregas rápidas.Y a su vez, estos principios se apoyan en cuatro focos adicionales: eliminar todo aquello que no aporta valor ("waste", pero he preferido no buscar traducción directa a esta palabra), fortalecer la autoridad del equipo de trabajo, integración completa del testeo dentro del propio desarrollo, evitar la sub-optimización descomponiendo el todo en partes más pequeñas.

Algunas de las principales ideas con las que yo me quedo son las siguientes:

- Los usuarios tienen dificultad para articular claramente lo que ellos necesitan, y las necesidades de los usuarios cambiarán una vez que ellos vean el potencial del sistema y entiendan lo que pueden llegar a hacer con él. Por ello, de la importancia de comenzar a desarrollar lo antes posible.
- Si dividimos un problema complejo en partes más pequeñas, resultará mucho más difícil centrarnos en el campo de actuación en el cual dicho problema existe, porque el esfuerzo se estará dirigiendo hacia solucionar los sub-problemas. En ese aspecto el desarrollo Lean trabaja con un enfoque de "embudo": se comienza explorando la amplitud del paisaje, para ir luego gradualmente estrechando el campo de visión.
- Los planes están basados especulaciones, puesto que realmente no conocemos todo lo necesario cuando estamos creando el plan del proyecto. Puesto que hay que asumir los cambios como algo totalmente natural en un proyecto de software, debemos tener "feetback" constante en el proceso de desarrollo, puesto que en caso contrario estaremos desarrollando para situaciones que existieron al principio del plan, pero no cuando el software se vaya a entregar.
- Retrasar los compromisos, significa mantener abiertas las opciones posibles tanto tiempo como sea posible. Como se comentaba antes, las decisiones se deben basar en hechos, y no en proyecciones. Como comenta Mary Poppendieck en el artículo: "La decisiones se deberían hacer en el último momento responsable: el momento en el que un fallo en la toma de decisiones elimina una alternativa importante". Para ello, es importante también tener una capacidad de respuesta muy rápida.
- Hay que proporcionar autoridad y poder decisión al propio equipo de trabajo, puesto que realmente una planificación que pueda cambiar de forma rápida es mejor implementada por ellos, que adoptando una planificación centralizada.
- En el pensamiento lean, la eliminación de cualquier cosa que no añada valor ("waste") es el punto clave para conseguir la excelencia. Y en este sentido, es necesario revisar aquellos puntos de la cadena donde el trabajo permanece parcialmente hecho.
- La creación de defectos es "waste" en proporción directa al tiempo que el defecto permanece en el sistema. Por eso es tan importante que los defectos creados, sean detectados y solucionados inmediatamente a través del testeo.
- Una gestión efectiva del equipo de trabajo pone el énfasis en que éstos definan y constantemente mejoren sus propios procesos. Ésto debe marcar la diferencia entre rendimiento pésimo y resultados estelares. Se asume que el equipo de trabajo conoce su trabajo y los problemas derivados mejor que nadie. Es muy importante tener un buen método para tranferir conocimientos y experiencia entre todos los miembros del equipo, del tal forma que nadie sea indispensable.
- En cuanto al testeo, éste debe estar completamente integrado dentro del proceso de desarrollo. Se dice en el artículos que cualquier sistema de software que pueda sufrir cambios en el futuro debería tener un completo conjunto de tests automatizados, del tal forma que cuando se realicen cambios, sea imposible romper el resto del sistema. Es indispensable que el sistema sea testeado en las mismas condiciones en las que se encontrará en el entorno real de producción.
-La desagregación en tareas ignora el flujo de valor a través del conjunto completo de la cadena económica. Se centra en el coste y tiempo de hacer cosas, pero no considera el valor de no estar haciendo nada. La autora critica en este apartado, la creación de la Estructura de Desglose del Trabajo (Work Breakdown Sctructure,WBS) propuesta en la gestión de los proyectos convencionales, porque se centra en la gestión del coste y la planificación de cada parte de forma individual. En este sentido, también, se aconseja medir el redimiento del equipo completo, más que tratar de medir el rendimiento individual de cada miembro.
- Mary Poppendieck defiende la idea de que cada proyecto debería tener su propio cuadro de mandos que reflejase los principales conductores de valor de negocio, en vez de medir los proyectos en coste, planificación y alcance. Esos indicadores son lo que realmente deberían dictar el éxito o no del proyecto.
- En cuanto a los contratos se defiende que hay que buscar en todo momento la maximización de beneficios proveedor-cliente, y en este sentido los "Targets Contracts" son un buen mecanismo para conseguir dicho objetivo. Se trata de un tema que me gustaría desarrollar en otro post, porque realmente hay materia para muchos ríos de tinta. Recomiendo además, ver la charla de Ángel Medinilla que al principio de este post se mencionaba.

Hasta aquí un repaso de las ideas con las que yo me quedo de este gran artículo. Ideas con las que mayoritariamente estoy de acuerdo. No estoy de acuerdo en la visión que se proporciona en el artículo de la WBS, porque considero que el objetivo perseguido por su realización puede ser totalmente compatible con la visión a más bajo nivel (a nivel de implementación) perseguido por lean. Y en general hay otras ideas propuestas en el artículo, que se tratan totalmente opuestas a la visión que, por ejemplo, el PMI traza de la gestión de proyectos, pero que bajo mi punto de vista son totalmente complementarias. Pero, efectivamente, sobre estos temas también hay mucha materia para escribir.

Curso de Scrum de Proyectalis

Este lunes y martes, he tenido la gran suerte de asistir al curso de Scrum, organizado por la empresa Proyectalis, de Ángel Medinilla, creador del blog: www.presionblogosferica.com.
La verdad es que tenía grandes expectativas en este curso, y tengo que decir que se han visto cubiertas por completo.
No sólo ha sido un curso de Scrum, sino sobre todo un curso orientado a la gestión de proyectos software, con conceptos como el de Kaizen (mejora contínua), los valores del equipo de desarollo, productividad, testeo, ....
Los juegos propuestos por Ángel para demostrarnos ciertos conceptos de Scrum, buenísimos, y muy esclarecedores.
Por otro lador, un curso también muy valioso, por el intercambio de opiniones y visiones de otros colegas de profesión, muchos de los cuales ya se están peleando con Scrum, y por tanto sus experiencias siempre son muy a tener en cuenta para ponerlo en marcha.