lunes, 31 de julio de 2017

DevOps versus Bimodal IT


Hace un tiempo, reflexionaba yo sobre la viabilidad de aplicar metodologías Agile de forma generalizada en una empresa compleja con un mapa de sistemas complejo.

Y mi sensación, que en el fondo todavía mantengo, es que la aplicabilidad de Agile no es el todo general, que los proyectos más complejos precisan algo más de planificación y visión a largo plazo, y un ciclo de vida que, al menos al principio, no se adapta a la velocidad y metodología de Agile. Pensaba yo que ciertos proyectos deben seguir una gestión de proyectos más tradicional (en general los más complejos y los que más determinan la arquitectura y mapa de sistemas) y otros, sin embargo, se beneficiaría de un enfoque agile (aquellos de planteamientos funcionales más sencillos, con mayor orientación hacia el cliente y con más peso en los aspectos de interfaz de usuario).

Y en eso descubrí el concepto de Bimodal IT, creado por Gartner y que se parecía mucho a lo que yo había pensado. Bimodal IT distingue, en efecto, dos tipos de proyectos y dos formas de gestionarlos. 

Los sistemas que se denominan 'sistemas de registro ('record systems'), es decir, los que soportan la columna vertebral de los procesos y datos corporativos, se gestionarían en el modo 1 según el modelo en cascada más tradicional y buscando sobre todo la fiabilidad. 

Los sistemas que denominan de relación ('engagement system'), los dedicados a interaccionar con el cliente y crear un vínculo con él, se gestionarían en el modo 2, que sería 'agile' y donde lo que primaría sería la velocidad y capacidad de respuesta.

Me encuentro ahora leyendo 'The DevOps Handbook' para profundizar en DevOps que, como ya vimos, es heredero de, aunque no se limita a, la filosofía agile. Y veo que uno de sus autores, Jez Humble, hace poco más de un año dedicó en su blog, 'Continuous Delivery', un post en que criticaba esa filosofía promovida por Gartner.

Tres son los argumentos que esgrime Jez Humble en contra de Bimodal IT

  • Reduccionismo: Opina Humble que es una simplificación el pensar que con esos dos modos se resuelve toda la problemática.

  • Acoplamiento entre los sistemas de registro y los de interacción: Afirma en este sentido Humble que la modificación de un sistema de relación (modo 2) suele precisar de modificaciones en los sistemas de registro (modo 1), por lo que no es correcta una separación drástica entre ambos tipos de sistemas y entre ambos modos.

  • La fiabilidad no está reñida con la velocidad: Aquí, Humble va más allá y, por decirlo de alguna manera, 'niega la mayor': no es cierto que la fiabilidad esté reñida con el tiempo de respuesta. Jez Humble entiende que DevOps da respuesta a ambas necesidades y, por tanto, no es necesaria la famosa gestión bimodal.

Jez Humble en acción
Finaliza Humble su artículo en un tono algo más conciliador y entreve que, quizá, la gestión bimodal sea útil como un primer paso, en el caso de empresas con una gestión muy tradicional, para acercarse a DevOps. Un primer paso que en opinión de Humble no puede exceder de unos meses.

Un debate, en cualquier caso, muy interesante y más que necesario y realista. Mi experiencia me lleva a estar más cerca del modelo de Gartner... y mi esperanza a estar más cerca de Jez Humble y DevOps.

¿Conclusión?

Supongo que no hay otra: debemos aspirar al modelo DevOps, pero ser muy realistas y cuidadosos en la transición... y ser muy conscientes de la realidad (la realidad, no la aspiración) de nuestras compañías. Quizá no estemos tan cerca de un DevOps o un Agile como quisiéramos...

viernes, 28 de julio de 2017

La prueba del algodón de la Customer Experience


Ahora que tan de moda está la así llamada 'Customer Experience', ahora que se aboga tanto por construir experiencias memorables y por apelar a la simplicidad y la emoción, corremos el riesgo de construir metodologías de laboratorio, formular complejas teorías, olvidarnos realmente de lo esencial.

Lo esencial es el cliente, lo esencial es el usuario.

Y lo que éste necesita o desea puede ser mucho más sencillo de lo que se puede imaginar desde un laboratorio o, en cualquier caso, es fácil que sea distinto.

Si queremos conseguir una excelente experiencia de cliente o de usuario no nos retiremos al laboratorio. nos nos aislemos. Hablemos con él o, incluso mejor, observemosle, veamos cómo usa un sistema o producto, cómo interacciona con él, qué espera...

Así se nos recomienda en 'The DevOps Handbook', abogando por la técnica del contextual enquiry, cuando se nos dice:

One of the most powerful techniques in interaction and user experience design (UX) is contextual inquiry. This is when the product team watches a customer use the application in their natural environment, often working at their desk.

He tenido personalmente la experiencia de comparar lo que uno se imaginaba, con la mejor de las intenciones, en un laboratorio, con lo que un verdadero usuario esperaba. Una experiencia más que reveladora, una lección inolvidable. 

La experiencia de cliente empieza y acaba en el cliente.

¿Por qué buscarla en otro sitio?

miércoles, 26 de julio de 2017

En Pulse: La sonrisa triste


Sonrío.

Y la sonrisa puede tener muchos significados.

Puede ser el reconocimiento espontáneo de una agudeza, de un ingenio, de un chisporroteo de inteligencia.

Sonrío con cariño mal disimulado ante la inocencia de una niña de significado especial que despliega ingenuidad o simplemente espontaneidad.

Sonrío ante lo cercano, lo conocido, lo entrañable.

Pero a veces, sólo a veces, un velo tenue tiñe de sombras tristes esa sonrisa.

Sonrío tristemente ante el reconocimiento casi cómico de esas pequeñas miserias tan entrañables por tan conocidas, tan conocidas por tan frecuentes, tan frecuentes que las hacen aún más tristes…

Sonrío tristemente al leer en ‘The DevOps Handbook’ la siguiente argumentación:

Examples of ineffective quality controls include:
  • Requiring another team to complete tedious, error-prone, and manual tasks that could be easily automated and run as needed by the team who needs the work performed.
  • Requiring approvals from busy people who are distant from the work, forcing them to make decisions without an adequate knowledge of the work or potential implications, or to merely rubber stamp their approvals.
  • Creating large volumes of documentation of questionable detail which become obsolete shortly after they are written.
  • Pushing large batches of work to teams and special committees for approval and processing and then waiting for responses.

Sonrío tristemente ante lo entrañable, ante lo conocido, ante lo frecuente...

Pero antes de que el abatimiento borre definitivamente la sonrisa, me acuerdo de niñas especiales y del deber y aspiración a la educación, la enseñanza y la transformación.

Entreveo caminos y opciones, proyectos y ambiciones, mejora y transformación, digital o no.

Una luz brillante disuelve los últimos velos y mi sonrisa, más profunda, más franca, más abierta, celebra el triunfo de la posibilidad, la voluntad y la inteligencia.

*****
Artículo publicado en Pulse el 25/07/2017
Pulse es el servicio de noticias personalizadas de la red social profesional LinkedIn

martes, 25 de julio de 2017

Colaboración: “Las smart cities aúnan lo social, lo económico y la sostenibilidad” en 'A un CLIC de las TIC'


El pasado Jueves 20 de Julio se publicaba en A un CLIC de las TIC, el blog de la unidad de Grandes Clientes de Telefónica, el artículo titulado "Las smart cities aúnan lo social, lo económico y la sostenibilidad".

El artículo consiste en una entrevista a Marieta del Rivero sobre su libro titulado 'Smart Cities: una visión para el ciudadano', publicado por LID Editorial y, quizá más importante, sobre el propio concepto de Smart City y la visión de la autora sobre el mismo.

La entrevista estuvo precedida, unos días antes, por un encuentro personal con la autora, un encuentro muy agradable en lo personal y muy interesante en lo profesional.

El resultado, este artículo "Las smart cities aúnan lo social, lo económico y la sostenibilidad" que espero os animéis a leer.


lunes, 24 de julio de 2017

Tres interesantes patrones de gestión de sistemas


A aquellos que estén familiarizados con el diseño software, especialmente el diseño orientado a objetos, les resultará seguramente familiar el término 'patrones de diseño'. Un patrón de diseño es algo así como un diseño genérico, un modelo de diseño repetitivo. una buena solución 'ya enlatada' para un problema común de diseño software.

Los patrones de diseño se hicieron populares (y tremendamente útiles) a partir del afamado libro 'Design Patterns. Elements of Reusable Object-Oriented Software' de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. El libro, debo decirlo, con el que creo que más aprendí de diseño orientado a objetos en su momento (un momento algo lejano ya).

Pero los patrones no tiene por qué limitarse a diseño de software orientados a objetos. Siempre que existan unas problemáticas frecuentes y similares en cualquier ámbito, y siempre que identifiquemos un tipo de solución válida para ese tipo de problemáticas, nos encontraremos ante un patrón.

Leyendo 'The DevOps Handbook' me encuentro con esta misma palabra, patrón ('pattern'), pero en un ámbito diferente, aunque todavía dentro del mundo del software. Se trata de tres patrones que tienen que ver más con la arquitectura y explotación de sistemas que con la ingeniería del software.

En el caso de los dos primeros patrones, el problema a resolver es cómo conseguir un despliegue frecuente (idealmente continuo) de nuevo software en producción con un riesgo tolerable. Para este problema, se nos proponen dos patrones: 'feature toggles' y 'dark launching' que, por cierto, pueden ser complementarios.

'Feature toggles' (conmutadores de características) consiste en dotar al sistema de unos elementos de configuración (por ejemplo vía fichero XML o JSON) que permitan realizar activación/desactivación o la apertura de las nuevas funcionalidades de forma controlada. Por ejemplo, se puede controlar a qué usuarios se les permite o no el acceso a la funcionalidad reciente, implementando políticas de número crecientes de usuarios como podría ser: al principio sólo el equipo de desarrollo, luego los usuarios de la compañía proveedora del servicio, luego un número limitado de clientes y, finalmente, toda la planta de clientes. También se puede utilizar para desactivar completamente una funcionalidad que se ha mostrado defectuosa o no escalable.

'Dark launching' (lanzamiento opaco) habla de desplegar en entorno de producción software y funcionalidad pero de modo que no son visibles para los usuarios finales, ya sea porque está desactivadas para ellos, ya sea porque no producen ninguna manifestación visible sino sólo trabajo en 'background' (por ejemplo, medidas y obtención de KPIs). En la sombra, el equipo de proveedor del servicio puede trabajar comprobando el funcionamiento correcto y las prestaciones y escalabilidad, antes de decidirse a desplegar 'en abierto'. Este patrón pude apoyarse en el de 'feature toggles' ya que pueden ser esos conmutadores de características lo que nos sirva para mantener la nueva funcionalidad como 'opaca'. 

El tercer patrón cambia de tercio y se centra ahora más en una solución de arquitectura para permitir desplegar una nueva tecnología conviviendo con otra legacy.

'Strangler application' (estrangulador de aplicaciones') lo que propone es, simplemente, recubrir el 'legacy con un API, de forma que se concentre ahí toda la interacción entre la nueva tecnología o aplicación y la legada. De esta forma, se reduce drásticamente el acoplamiento entre ambas y se habilita una relativamente sencilla eliminación de la aplicación legada, si así lo decidimos, mediante una nueva implementación del API que recubría al legado. La re-implementación de esa API puede incluso, ser gradual, resultando en cualquier caso trasparente el ritmo de sustitución para la nueva tecnología o aplicación.



Probablemente, aquellos lectores duchos en ingeniería software y con experiencia real con sistemas reconozcan estos patrones, incluso aunque puedan no haber oído nunca el nombre que se les aplica. En mi caso particular, puedo decir que, en efecto, he conocido las tres estrategias en la práctica, aunque hasta ahora no las había catalogado como patrón ni conocía el nombre que las denomina.

Es lo que tienen los patrones: son soluciones comunes, y muchos profesionales probablemente han llegado a y aplicado las mismas conclusiones, incluso sin saber que otros colegas hacían lo mismo en otras compañías o proyectos.

El identificarlos como patrones hacen más fácil, sin embargo, entenderlos, comunicarlos  e identificarlos la próxima vez.

Y con ese espíritu, y por lo que pueda ayudar, he escrito este post.

viernes, 21 de julio de 2017

Entender el trabajo del desarrollo software


La tecnología es bella y absorbente en sí misma.

Y el desarrollo software es bello y absorbente en sí mismo. Prendados de la belleza del propio software, entusiasmados por el desafío que significa hacer un programa o implementar una nueva tecnología, los desarrolladores profesionales pueden a veces olvidarse de cuál es el verdadero sentido de su trabajo.

El desarrollo software profesional rara vez es un objetivo en sí mismo. Está al servicio del negocio. Sirve para crear un producto vendible, o para automatizar procesos, o para disponer de un canal de relación con clientes, o para integrarse con proveedores, o para medir la actividad, o para... 

Una tecnología, por atractiva y elegante que resulte para el desarrollador, no es un fin si no está al servicio de los objetivos del negocio, si no nos ayuda a conseguirlos o mejorarlos.

Puede resultar algo triste para el desarrollador más vocacional...pero es así. Y mejor tenerlo claro.

En el libro 'The DevOps Handbook' se menciona a Randy Shoup, antiguo director de ingeniería de Google. Cuando describe el ambiente en el equipo que desarrolló Google App Engine dice:

everyone knew that our job was not to 'write code' but it was 'run a service'.

Esa es justo la idea. El trabajo no es hacer código por sí mismo, sino disponer de un servicio.

Si en Google lo tienen claro, el resto también puede ¿no?

miércoles, 19 de julio de 2017

La empatía que conduce a la eficiencia


La empatía es una virtud muy humana, una virtud que, en el mundo profesional, relacionamos con la comunicación, con el 'engagement', quizá con el liderazgo...pero pocas veces se nos habrá ocurrido ponerla en relación con algo tan'árido', tan aparentemente maquinal como es la eficiencia ¿verdad?

Pues a lo mejor tenemos que cambiar de opinión. Leyendo en 'The DevOps Handbook' algo más de detalle sobre los tres caminos de DevOps, y en concreto sobre el primero, el que promueve el paso rápido entre el desarrollo y la operación, en busca de la agilidad y calidad,  me encuentro la siguiente afirmación:

According to Lean, our most important customer is our next step downstream. Optimizing our work for them requires that we have empathy for their problems in order to better identify the design problems that prevent fast and smooth flow.

Según los principios de Lean, adoptados por DevOps, cada elemento de la cadena productiva de tecnología debe estar pendiente del siguiente eslabón, pero no de una forma mecanicista, más propia de una cadena industrial tradicional, sino de una forma empática, es decir, entendiendo y anticipándose a los problemas que el siguiente del equipo se puede encontrar. Si esta empatía existe, se harán todos los esfuerzos por evitar problemas al siguiente eslabón y, de esta forma, se ganará agilidad, se eliminarán retrabajos y, en conjunto, se ganará eficiencia.

Tal vez, lo humano sea eficiente o, quizá, ya que somos humanos, hemos de tratarnos como tal si queremos sacar lo mejor de nosotros... y obtener frutos de eficiencia y calidad.

lunes, 17 de julio de 2017

Dónde ahorra Lean Manufacturing... y mucho más


A modo de recordatorio y para inventario.

Me interesa ir reuniendo los diversos aspectos que hemos de buscar en un proceso de negocio para poder mejorarlo. Así que apunto las fuentes que apuntan temas a vigilar en un proceso para hacerlo más óptimo.

Leyendo 'The DevOps Handbook' me encuentro una referencia a Lean Manufacturing que conviene recordar. No es extraña esta referencia dado que, como veíamos hace poco, Lean Management es un claro antecedente de DevOps.

Uno de los 'mantra' de Lean Manufacturing es la eliminación del desperdicio, 'muda', todo aquello que no aporta valor final. En el libro sobre DevOps nos recuerdan los siete tipos de desperdicio que identifica Lean Manufacturing.

Son éstos:
  • Inventario
  • Exceso de producción
  • Procesado extra
  • Transporte
  • Esperas
  • Movimiento
  • Defectos
Sin duda, cada apartado merece un largo tratamiento en sí mismo, pero de momento queda a modo de apunte, de recordatorio, y para añadir al censo de cosas a vigilar o mejorar en procesos de negocio, en este caso, de fabricación.

Aproximadamente esto mismo lo vimos hace ya más de tres años en el artículo que titulamos 'Aplicando los principios lean al mundo del software: 7 fuentes de desperdicio a eliminar', pero me ha parecido interesante revisitarlos.

Además, la ocasión me sirve de 'excusa' para reunir los artículos que he publicado en este blog, basados en diversas fuentes, pero que identifican puntos generales de mejora en un proceso de negocio... y quizá ese sea el mayor interés de todo el artículo...

Otros artículos relacionados (censo de mejoras en procesos de negocio)

viernes, 14 de julio de 2017

Los tres caminos de DevOps


Tres son tres los caminos que sigue DevOps para conseguir sus objetivos de agilidad y calidad.

Tres caminos que nos describen Gene Kim, Jez Humble, Patrick Debois y John Wilis en su libro 'The DevOps Handbook'.

Se trata de los tres caminos que se muestran en la figura:

El primer camino es el que va linealmente desde el desarrollo (Dev) a la Operación (Ops) y finalmente al cliente y se esfuerza en la agilidad. En este camino nos esforzamos en reducir el tamaño de lotes y los intervalos de trabajo y en evitar que los defectos viajen aguas abajo.

El segundo camino proporciona un feedback continuo aguas arriba con el objetivo de evitar repetir problemas ya conocidos o posibilitar una detección y recuperación más temprana.

El tercer camino tiene que ver con el aprendizaje continuo, con una cultura de alta confianza que soporta el riesgo y la experimentación.

Tres son tres los caminos... y grande la transformación.

miércoles, 12 de julio de 2017

Las influencias de DevOps: Lean y Agile.


Cuando hablamos de música, de literatura, de artistas, muchas veces los eruditos o los propios artistas disertan sobre sus influencias, sobre aquellos otros personajes que han marcado y moldeado de alguna forma, su manera de interpretar el arte.

No se trata de arte (¿o tal vez si?) pero en metodologías y técnicas de gestión también se producen influencias, una suerte de polinización cruzada entre ámbitos de gestión, sectores y gurús que hacen nacer cosas nuevas a partir de hallazgos anteriores.

Un caso que podría ser claro al respecto es DevOps, una forma de gestión de la TI que nace integrando enseñanzas de oras disciplinas y ámbitos más o menos cercanos  que busca la agilidad y la calidad integrando el mundo del desarrollo y la operación TI..

Me encuentro inmerso en la lectura de 'The DevOps Handbook', escrito por Gene Kim, Jez Humble, Patrick Debois y John Wilis y en sus primeros pasos nos hablan de alguna de esas influencias.

La primera es Lean Manamegement, una filosofía de gestión nacida en Toyota en su famoso TPS (Toyota Production System) cuya obsesión es la eliminación de los desperdicios ('muda') es decir, de todo aquello que no aporta valor, mediante una revisión y vigilancia continua del proceso.

Así no explican los autores esta influencia:

DevOps is the result of applying Lean principles to the technology value stream

Y también:

DevOps is the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream.


La otra influencia viene ya del propio mundo del TI y se trata de Agile, esa filosofía de gestión de proyectos software que busca los desarrollos rápidos e incrementales con alta participación del cliente/usuario:

many also view DevOps as the logical continuation of the Agile software journey that began in 2001.

No es extraña la convergencia de ambas influencias. Al fin y al cabo, una de las metodologías Agile es precisamente Lean y otra es Kanban, con la misma ascendencia de las técnicas japonesas de mejora continua y calidad total.

No es extraña tampoco esa convergencia si se tiene en cuenta que DevOps intenta aunar los esfuerzos de desarrollo (más anclados en técnicas de dirección de proyectos, como Agile) con la operación (lo que ofrece más cercanía con filosofías tipo Lean)

Y, al final, ¿que se obtiene de todo esto? Pues el objetivo no está falto de ambición. Así nos lo explican los autores:

Lean principles focus on how to create value for customer through systems thinking by creating constancy of purpose, embrace scientific thinking, creating flow and pull (versus push), assuring quality at the source, leading with humility, and respecting every individual.

Valor, pensamiento científico, propósito, flujo, calidad, liderazgo y respeto. Casi nada al aparato.

En siguientes artículos veremos algunos aspectos de cómo DevOps se articula para intentar conseguir tan exigentes expectativas.

lunes, 10 de julio de 2017

Deuda técnica


La deuda no es mala por sí misma.

Endeudarse es una forma de obtener recursos y con base en ellos impulsar nuestro negocio o nuestra vida. Mediante la deuda podemos afrontar iniciativas que, tal vez sin ella, fuesen imposibles. Nos endeudamos como personas, 'nos hipotecamos', para comprar una casa que difícilmente podríamos pagar al contado, o para permitirnos unos estudios o quizá un coche. Nos endeudamos como empresa para invertir en proyectos de futuro: una expansión internacional, una nueva línea de productos, una nueva tecnología productiva, unas nuevas infraestructuras...

La deuda proporciona lo que se denomina el apalancamiento financiero, y la palabra apalancamiento nos sugiere impulso, potenciación de capacidades. Y es así, sin el capital que se nos aporta al contraer una deuda, no podríamos imaginar llevar a cabo ciertos proyectos.

No. La deuda no es mala en sí misma. No es mala siempre que se gestione responsablemente, siempre que se mantenga en límites asumibles, siempre que seamos capaces de saldarla, siempre que la controlemos y no seamos controlados por ella.

Pero no sólo existe deuda financiera.

En el ámbito de las tecnologías de la información, Ward Cunningham acuñó el término deuda técnica, algo así como problemas latentes que creamos por decisiones erróneas o cortoplacistas y que, poco a poco comprometen la evolución de nuestra TI.

Esta es su explicación según es citada en 'The DevOps Handbook' de Gene Kim, Jez Humble, Patrick Debois y John Willis:

technical debt describes how decissions we make lead to problems that get increasingly more difficult to fix over time, continually reducing our available options in the future- even when taken on judiciously, we still incur interest.

¿Tampoco es mala la deuda técnica? ¿La podemos considerar un apalancamiento?

La verdad es que creo que la deuda técnica es fundamentalmente negativa. Suele responder a errores o falta de visión o planificación a medio/largo plazo.

En algunos casos particulares podría considerarse como un apalancamiento: situaciones en que adoptamos una solución no óptima a corto plazo, para tener resultados más rápido. Quizá, por ejemplo, en lugar de renovar sistemas para adaptarse a una nueva tecnología o arquitectura, construimos una capa sobre los existentes que 'simulan' esa adaptación.  El problema es que, rara vez se gestiona la deuda. Rara vez, eliminamos la capa que creamos como solución a corto para realizar la verdadera renovación. Rara vez, en definitiva saldamos la deuda contraída. Muchas veces ni siquiera recordamos haberla contraído. 

Por desgracia, la deuda técnica no suele controlarse sino que aumenta y aumenta... aumenta sin medida hasta que es preciso un 'rescate'.. o una desaparición.

viernes, 7 de julio de 2017

La realidad aumentada explicada por Alan B. Craig

'Understanding augmented reality' es una revisión amplia de los conceptos y estado del arte de la realidad aumentada, una disciplina que el autor define como 'un medio' más que una tecnología, resaltando el hecho de que combina muchas tecnologías, que éstas pueden evolucionar sin que sin embargo el concepto de realidad aumentada varíe, y de que lo más importante es el contenido, aquello que se transmite mediante técnicas de realidad aumentada.

El tratamiento es muy ordenado y sistemático, a veces incluso ligeremente aburrido, y con ello se tiene al menos la aparente tranquilidad de no haber dejado ningún punto imporante sin tratar.

El libro se estructura en nueve capítulos:
  • 'What is aumented reality?': propone la definición de realidad aumentada como un medio, hace un brillante repaso histórico de cómo hemos alcanzado el concepto actual de realidad aumentada y pone la realidad aumentada en relación con otras tecnologías.

  • 'Augmented reality concepts': habla de los principales elementos y conceptos presentes en una solución de realidad aumentada incluyendo los sensores, el procesador y los visualizadores.

  • 'Augmented reality hardware': Hace un muy sistemático repaso por el hardware necesario y su estado del arte siguiendo el mismo orden que en el capítulo anterior, a saber, sensores, procesador y visualizadores.

  • 'Augmented reality software': Toca ahora el turno para el repaso del software, una materia que ordena en cuatro apartados, software directamente involucrado en la aplicación de realidad aumentada, software usado para crear la aplicación, software usado para crear contenido y otros tipos de software

  • 'Content is key! Augmented reality content': defiende la importancia del contenido para cualquier aplicación de realidad aumentada y repasa algunas ideas como los diferentes tipos de contenidos para los diferentes sentidos, la creación estática o dinámica de contenidos, etc

  • 'Interaction in augmented reality': se centra ahora en la interacción del usuario con la aplicación y aborda temas como la comunicación, la navegación o los entornos multipersona

  • 'Mobile augmented reality': hace foco brevemente en el uso de los dispositivos móviles para soportar aplicaciones de realidad aumentada, con sus ventajas y limitaciones, y los tipos de arquitecturas aplicables.

  • 'Augmented reality aplications': Propone una tipología de aplicaciones de realidad aumentada e identifica áreas de uso.

  • 'The future of augmented reality': Hace una prospección de lo que el futuro puede deparar a la realidad aumentada, repasando primero el estado en cuanto a aplicaciones, tecnología y desarrollo de contenidos para, a continuación, identificar una serie de tendencias de índole general.

'Understanding augmented reality' es un tratado serio, riguroso y abarcador de esta disciplina, muy ordenado en su desarrollo, abundantemente acompañado por fotografías y esquemas para ayudar a entender o visualizar aquello que se explica, no profundamente técnico aunque sin eludir tampoco la tecnología y, en general, de muy buena factura. El único pero sea, tal vez, el tono tan plano de la exposición a la que se le echaría en falta un puntito de pasión u originalidad para el tratamiento de un tema tan atractivo.

En cualquier caso, una más que buena referencia.

Alan B. Craig

(Fuente: Traducción y ligera elaboración propia de su perfil en la página oficial del libro 'Understanding Augmented Reality'.)

Alan B. Craig
El doctor Alan B. Craig ha estado en el National Center for Supercomputing Applications (NCSA) durante más de 25 años. Además, es Director Asociado de interacción hombre-máquina en el Institute for Computing in Humanities, Arts, and Social Science (I-CHASS). Es también el interlocutor acerca de humanidades, arte y ciencias sociales del Extreme Science and Engineering Discovery Environment (XSEDE).

El doctor Craig no es nuevo en el mundo de la escritura. Además de 'Understanding augmented reality', también ha escrito 'Understanding Virtual Reality' con William R. Sherman. Ha escrito numerosos capítulos de libros y artículos. Habla nacional e internacionalmente sobre una variedad de materias a audiencias que van desde las académicas a la administración o la industria.

A lo largo de su carrera ha estado implicado en el desarrollo y estudio de muchas tecnologías y conceptos, incluyendo la realidad virtual, realidad aumentada, visualización científica, computación de altas prestaciones, sistemas colaborativos, data mining y sistemas web. Le han sido concedidas 3 patentes americanas por sus innovaciones. Además de su trabajo en representación visual de la información, el doctor Craig has estado fuertemente implicado en el uso del sonido para representar datos, así como en sistemas multimodales. Su trabajo ha abarcado todo el continuo de la realidad, desde lo real a lo digital y vuelta a lo digital a través de la invención personal, así como en la frontera entre ambos mundos. En todos sus empeños se ha enfocado fundamentalmente en aplicaciones relacionadas con la educación.

Más allá de su vida profesional, el doctor Craig ha estado implicado en numerosos otros empeños creativos, concentrándose fundamentalmente en la escritura, grabación e interpretación de música.

Puedes saber más acerca del autor visitando su perfil en I-CHASS.

miércoles, 5 de julio de 2017

Tendencias en realidad aumentada


Vamos a ir cerrando la serie de posts dedicados a realidad aumentada inspirados en la lectura del libro 'Understanding Augmented Reality' de Alan B. Craig.

Antes de echar ese cierre con una reseña del libro, vamos a repasar brevemente las tendencias que al autor apunta para la realidad aumentada. Cabe advertir que el libro está escrito en 2013 así que pudieran estar ligeramente desactualizadas pero creo que, en realidad, son bastante actuales.

Éstas son las tendencias apuntadas:

  • Aplicaciones de realidad aumentada móvil

  • Marcadores de referencia (fiducial markers) especializados. Los marcadores de referencia ayudan a orientarse a las aplicaciones de realidad aumentada, especialmente a su 'visión'. El autor prevé nuevos tipos de marcadores, más naturales, incluyendo marcadores del tipo del 'skyline' de una ciudad

  • Trazado mejorado y tecnologías de trazado híbridas como, por ejemplo, la combinación de GPS con trazado óptico.

  • Menos estorbos, es decir, uso de pantallas en lentillas, sensores más pequeños y ligeros, etc de forma que el usuario se sienta más libre, más natural...

  • Uso de más sentidos, desplazando algo del foco actual en lo visual hacia el olfato, el tacto, etc

  • Visualizadores y representaciones de más alta fidelidad.

  • Sistemas de proyección, Es decir, no tanto que el usuario vea la realidad aumentada sino que la proyecte lo que soportaría, por ejemplo, múltiples participantes en la experiencia.

  • Mayor control sobre el mundo real, es decir usar menos botones y dispositivos y emplear más el propio mundo real para controlar la experiencia.

  • Aplicaciones privadas y multipersona.

  • Aplicaciones que pueden cambiar de contenido, es decir, aplicaciones más genéricas pero que pueden aplicarse sobre contenido diferente de forma sencilla.

  • Repositorios de contenidos y aplicaciones de realidad aumentada

  • Más áreas de aplicación.

  • Contenido ubícuo y canales de 'aumento'.

  • Nuevos mecanismos de descubrimiento de contenido aumentado, es decir, que el usuario puede 'descubrir' que hay contenido disponible sin necesidad de saberlo previamente.

  • Herramientas de edición más simples de usar

  • Atención a discapacitados.

  • Mejoras y más formales mecanismos de evaluación de las experiencias aumentadas.

Muchas tendencias, y todas bastante razonables. Algunas, como lo de la movilidad, parecen confirmarse. iremos viendo las otras...

lunes, 3 de julio de 2017

Siete estilos de aplicaciones de realidad aumentada


Muchas son, sin duda, las posibilidades de la realidad aumentada. muchos los sectores y áreas donde se puede aplicar. Probablemente todavía sea pronto para reconocer con nitidez dónde están sus límites.

Sin embargo, Alan B. Craig, en su libro 'Understanding augmented reality' se atreve a identificar siete estilos de aplicaciones, algo así como patrones de aplicaciones que se repiten con independencia del sector u objetivo específico de la aplicación.

Estos son los estilos que identifica el autor:

  • Libros mágicos: Se trata de un libro del cuál algunos elementos como, por ejemplo, ilustraciones o conceptos, se pueden visualizar,por ejemplo de forma tridimensional, mediante técnicas de realidad aumentada.

  • Espejos mágicos: Se trata de espejos que, aparte de reflejar el mundo real, incluyen elementos digitales. Un caso podría ser, por ejemplo, una aplicación en que le permite a uno verse en el espejo con diferentes trajes o vestidos.

  • Puertas y ventanas mágicas: Se trata, como el nombre indica, de una ventana o una puerta a través de las cuales, aparte del mundo real, se ve una realidad digital adicional. Podría valer para imaginarse, por ejemplo, si se está haciendo la reforma de una casa, imaginarse lo que se vería al poner una puerta en un sitio u otro.

  • Lentes mágicas: Se trata de observar la realidad a través de una lentes o gafas que presentan información adicional.

  • Ayuda a la navegación: Un tipo de aplicaciones que, como el nombre hace imaginar, simplemente ayudan a las personas a encontrar el camino en un sitio que desconocen.

  • Aumento no referencial: En este caso, la realidad no se aumenta incluyendo nuevos objetos o informaciones, sino modificando ligeramente los objetos reales, por ejemplo cambiando colores, el volumen de la voz, etc

  • Realidad aumentada de visión objetiva: Es un caso en que los usuarios ven una representación de sí mismos. La realidad y aumentada incluye al propio usuario en la escena.

Seguramente, el tiempo y la creatividad traerán nuevos estilos y posibilidades, pero me ha parecido una clasificación interesante, clarificadora y que nos ayuda a imaginarnos mucho mejor todo lo que se puede conseguir con realidad aumentada.