La adicción creada por Apps es un problema mayor?

La ciencia de la persuasión está siendo utilizada por las empresas de tecnología más exitosas, a través del Diseño del Comportamiento para lograr que los usuarios regresen una y otra vez a sus productos. Lo imperativo del enfoque es maximizar el-tiempo-en-el-dispositivo y la mejor manera pareciera ser la distribución de recompensas al operante en un calendario variable.  Independientemente de la utilidad de los productos, el sistema mismo está inclinado a favor de los diseñadores. Esto está siendo tan prevalente que algunos psicólogos piensan que es necesario  despertar al mundo para que se dé cuenta de cómo la tecnología digital está disminuyendo la capacidad de escoger libremente.

Conductismo & Diseño Conductual

Skinner fue el exponente más conocido de la Escuela Conductista, donde la premisa era que la conducta humana se entiende mejor en función a incentivos y recompensas. A partir de finales de los años cincuenta una nueva generación de académicos re-direccionó la psicología hacia los procesos mentales, como la memoria y la emoción. Sin embargo el conductismo nunca desapareció completamente y en años recientes ha re-emergido en una nueva forma, cómo una disciplina aplicada la cual es usada por empresas y gobiernos para influenciar las decisiones que una persona toma cada día: qué comprar, con quién hablar, qué hacer en el trabajo. Se denomina “Diseño Conductual” y su fundador es B.J. Fogg. Sus seguidores están particularmente interesados en la manera en la cual la interfaz digital puede condicionar decisiones humanas.

Diseño de la interfaz digital y el App

El diseño ha aparedo como la fuerza que potencia la habilidad computacional al servicio de los usuarios de la tecnología. Las aplicaciones se pueden diseñar para que metódicamente se puedan explotar las reglas de la psicología con la intención de lograr que la gente haga cosas que de lo contrario no haría.  Tenemos como ejemplos, los correos electrónicos que inducen a comprar de inmediato, las apps y juegos que capturan y fijan la atención, los formatos en línea que empujan hacia una decisión en lugar de otra. Todas están diseñadas para mover al cerebro humano y capitalizar sus instintos, sus peculiaridades y defectos.

Las piedras angulares del cambio de conducta requieren que para que la persona haga algo, tres cosas deben ocurrir en forma simultánea: (1) la persona debe querer hacerlo, (2) la persona debe estar en capacidad de hacerlo y (3) a la persona se le debe solicitar que lo haga (con un activador). La solicitud para la acción solo es efectiva cuándo la persona está altamente motivada. Para obtener las conductas esperadas el diseño debe: 

• ·         Aumentar el número de activadores que llevan a la conducta deseada.
• ·         Mejorar la habilidad para ejecutar la conducta (hacerla más fácil).
• ·         Ampliar la motivación para aplicar la conducta con motivadores intrínsecos y extrínsecos.

Ética de la Economía Digital

Los fabricantes de productos tienen la habilidad para mejorar las vidas de las personas, para ubicar los puntos donde están los dolores de las personas y así ayudarlos. Los hábitos pueden ser buenos o malos y la tecnología tiene la habilidad de crear buenos hábitos. La pregunta es cuál es la  responsabilidad asociada a la capacidad de influenciar la psicología de miles de millones de personas? Algunos de los psicólogos que han participado en el desarrollo de la ciencia de la persuasión están preocupados por la forma en que está siendo utilizada. Exactamente dónde y cuándo la persuasión es beneficiosa y ética debería ser un tópico de investigación y debate más profundo. Es preocupante que el diseño de los menúes de las Apps está en manos de un pequeño número de hombres, entre 25 y 35 años de edad, graduados en Ciencias de la Computación y quiénes viven en San Francisco.

Se hace referencia a “The Scientist who makes Apps addictive” http://bit.ly/2ehCpsK y “Stanford's School Of Persuasion: BJ Fogg On How To Win Users And Influence Behavior” http://bit.ly/2fz1cvr. 

La revolución de los algoritmos

Un algoritmo es un procedimiento o conjunto de instrucciones paso-a-paso, utilizado con frecuencia en una computadora para resolver un problema, que hoy en día  típicamente se  ejecuta a una velocidad y a una escala increíble.  La intensidad y lo variado del uso de los algoritmos nos permite pensar que estamos viviendo la revolución de los algoritmos y posiblemente su principal reto a futuro es el hecho que las máquinas y los algoritmos que los accionan se han venido haciendo cada vez más complejas y rápidamente se está perdiendo la habilidad de entender como funcionan y de anticipar su comportamiento o de detectar las debilidades no previstas. Para ponerlo en contexto, en la colocación de un hombre en la luna en 1.969 se usaron 145.000 líneas de código y ahora se requieren más 2 mil millones de código para procesar Google, con el agravante adicional que los sistemas actuales son además laberintos de interconexión.

Por ello, la principal fuente de dificultad no está en la programación de los algoritmos, sino más bien  en lograr que quienes los administren entiendan aquello que los algoritmos hacen bien, para cuáles preguntas tienen respuestas y para cuáles no las tienen. Es una responsabilidad del más alto nivel de la organización que los administra. Aquello que puede hacer un algoritmo es enormemente poderoso e incluye: identificación de patrones demasiado sutiles para la observación humana, el uso de dichos patrones para generar percepciones precisas y la información para la toma de mejores decisiones.

El reto de la Revolución de los Algoritmos

El reto es entender los riesgos y las limitaciones, ya que construido dentro de los algoritmos están (1) los valores humanos de sus desarrolladores, (2) las necesidades comerciales de sus creadores y (3)   límites de la comprensión humana. Hasta los más sofisticados algoritmos y aplicaciones de Inteligencia Artificial  (particularmente los sistemas de aprendizaje profundo), en última instancia están limitados por la imaginación y por la visión futurística de sus desarrolladores en términos de las entradas que pueden identificar, de  las salidas que pueden controlar y de la lógica que aplican. Esa complejidad obliga a cuidar el más mínimo error, por el impacto que pueda tener, y además considerar las vulnerabilidades asociadas a cualquier algoritmo.

Limitaciones de los algoritmos

Los algoritmos en esencia, transfirieren comprensión o percepción desde un contexto a otro. Ellos usan data existente para predecir lo que puede ocurrir en un ámbito ligeramente distinto (entorno, población, tiempo, una pregunta). Las predicciones que se realizan bajo un contexto específico no necesariamente  aplican de igual manera a un contexto distinto. Saber lo que un algoritmo no puede decir es tan importante cómo conocer lo que si puede. También es importante recordar que correlación no significa causalidad. Aún cuando un algoritmo es capaz de hacer predicciones, ello no elimina la necesidad de cuidar la  identificación de conexiones entre causa y efecto, ya que el algoritmo no es un reemplazo a experimentos controlados.

Objetivos y opciones en los algoritmos

• ·         Si se trata de un objetivo blando, este debe ser identificado, definido y cuantificado de acuerdo a su orden de importancia. Ya que los objetivos blandos son difíciles de cuantificar, es necesario tener cuidado extremo en la toma de acciones sobre resultados de ese tipo de algoritmo.
• ·        
  
  Los algoritmos no entienden de equilibrios entre opciones compensatorias (trade-off) – Teniendo identificado el objetivo principal y una lista de inquietudes, el diseñador del algoritmo debe construir los equilibrios entre las posibles opciones. Esto puede implicar expandir el objetivo para que incluya múltiples resultados, ponderados por importancia relativa.

Se hace referencia a “Make Algorithms Accountable” http://nyti.ms/2aZyWMo, “In Machines We Trust: Algorithms Are Getting Too Complex To Understand” http://bit.ly/2bMnQ1J and “Algorithms Need Managers, Too” http://bit.ly/1keDr8C. 

Blockchain: La tecnología del futuro en Finanzas?

El mundo financiero es un muy importante usuario de tecnología y frecuentemente está entre los que hacen los pruebas piloto de nueva tecnología. En este momento el sector financiero está considerando ser pionero con la tecnología Blockchain, donde aparte del potencial específico en Finanzas, también hay otras industrias que la podrán aprovechar. Tecnología nueva para que sea exitosa requiere inversión y los entes financieros tienen los recursos para ello. 

Blockchain, como tecnología sustenta el Bitcoin (“Bitcoin para un Dummy” http://bit.ly/1QnVAim), pero hoy se le está viendo como una aplicación independiente de Bitcoin y ya se habla de la industria del Blockchain.  Una manera de describir Blockchain, es verla como un registro digital en forma de un gran “libro de contabilidad distribuido” y que además:

·         Es una base de datos mantenida en forma colectiva por un número de participantes, en lugar que lo haga un solo actor.

·      Hace que las computadoras de cada participante acuerden como actualizar utilizando un “mecanismo de consenso” y llegado a un acuerdo en las modificaciones, estas son inalterables debido a la sofisticada criptografía utilizada en Blockchain.

·      Esa naturaleza criptográfica inherente a Blockchain hace que cada transacción sea más transparente, segura e irreversible, mitigando riesgos en el proceso de compensación y en los acuerdos de liquidación.

Blockchain en Finanzas

La oficina de patentes de Estados Unidos le aprobó a Bank Of America 10 patentes relacionadas con Blockchain, las cuales había presentado en 2014. Esto podría significar que BoA piensa modernizar totalmente sus operaciones o incluso crear un red completa basada en Blockchain. Las patentes abarcan “un sistema de pago criptográfico”, detección de riesgos, almacenamiento fuera de línea de criptomonedas y el uso de Blockchain para medir actividades fraudulentas.  Recientemente, IBM, JPMorgan, la Bolsa de Londrés y Wells Fargo anunciaron el Open Ledger Project, un consorcio que facilitará el uso de la tecnología Blockchain. Es necesario considerar que:

·         El impacto del uso generalizado de Blockchain se prevé para dentro cinco a diez años.

·         El liderazgo en su propagación probablemente lo tendrán las empresas grandes y tradicionales más que los emprendimientos, debido a que su adopción involucra a muchos participantes. 

·         La adopción de tecnología le permite a los bancos grandes aparentar ser innovadores.

·      Hay quienes piensan que Blockchain puede ser tan revolucionario, que termine liberando al sistema financiero de escoria acumulada, desde sistemas de TI incompatibles hasta intermediarios costosos e innecesarios.

Las ventajas de Blockchain en Finanzas

El entusiasmo generado por Blockchain tiene que ver con realidades como estas:

·         Las empresas financieras podrán hacer seguimiento de sus activos en una sola base de datos, en lugar de las múltiples bases de independientes que utilizan hoy.

·         Las condiciones de una negociación se pueden acordar en forma casi instantánea, sin requerir cantidades de intermediarios. Así también se reduce el riesgo al necesitar menos capital inmovilizado.

·         Esos “libros distribuidos” facilitan el cumplimiento de distintas regulaciones incluyendo las de anti-blanqueo, por cuanto proveen un registro de todas las transacciones históricas.

·         Blockchain puede servir como la base para los “contratos inteligentes”, que automáticamente ejecutan las promesas embebidas en un bono.

·         Existe el uso potencial de Blockchain para funciones como los “acuerdos de liquidación”, cuándo efectivo y títulos son intercambiados entre compradores y vendedores. Por la inmediatez de la transacción se reduce exposición al riesgo de insolvencia de las partes del acuerdo.

También hay posibles escollos:

·         Escalabilidad, ya que los “libros distribuidos” actuales no pueden manejar un volumen gigantesco de transacciones.

·      Confidencialidad, existen técnicas de encriptación que están siendo desarrollados actualmente.                        `

Hay referencias a “ Does Bitcoin still matter?” http://bbc.in/1WdYiKD, “Bank of America is trying to load up on patents for the technology behind bitcoin” http://bit.ly/1MtM1qD, "Banks will quintuple spending on blockchain by 2019" http://bit.ly/22bbJfa y "Distributed ledgers are the future, but their advent will be slow" http://econ.st/1RVqsmi. 

Recién nos acostumbramos a los Apps y ahora serán Bots!!

Ya nos acostumbramos al uso de las Apps en nuestros teléfonos inteligentes y ahora más bien enfrentamos una verdadera inundación de ofertas de Apps. Con frecuencia se hace difícil seleccionar cual necesitamos y se está llegando al punto de saturación, donde el 25% de los Apps descargadas son abandonadas después de un solo uso.

Pero la tecnología avanza inexorablemente y cuándo se detecta un espacio de necesidades, nacen las oportunidades y la nueva oferta de tecnología se cuela. Una opción interesante que tiene posibilidades de convertirse en un nuevo fenómeno son los Bots. Estos Bots o Chatterbots son  agentes conversacionales, en la forma de un programa computacional diseñado para simular una conversación inteligente por texto o por vía auditiva con uno o más usuarios humanos. Ellos están generalmente accionados por Inteligencia Artificial (“Bot” proviene de “Robot”). Los Bots nos permiten establecer una “conversación” con un “robot” y son Servicios, donde los usuarios pueden completar tareas como revisar noticias, organizar reuniones, pedir comida, reservar un vuelo o navegar entre Apps a través del envío de mensajes cortos. También pueden resolver vía auditiva necesidades básicas de soporte o de información sobre productos.

Características

Los usuarios los encontrarán más fáciles de usar que los Apps: (1) la instalación toma segundos, (2) cambiar entre Bots no implica tocar otro ícono y (3) “hablarle” a un bot es más apetecible que lidiar con un operador de soporte del cliente de un banco o de una línea aérea. Al igual que las páginas web, los Bots también residen  en los servidores y no en el dispositivo del usuario y por ello son más fáciles de crear y de actualizar.

Historia

Por años, los Bots fueron unos bichos digitales irritantes que hacían un mal trabajo sustituyendo a seres humanos en los Call Center o inflando el volumen de tráfico pretendiendo que leían páginas web. Sin embargo, en los nuevos usos identificados, son elementos de interacción con el usuario y su importancia se realza:

·         A partir de junio 2015 cuando Telegram, una aplicación de mensajería de origen ruso con más de 100 millones de usuarios, lanza una plataforma y una tienda de Bots.

·     En Abril 2016 Facebook devela una facilidad que permite a los Desarrolladores hacer codificación de Bots dentro de Messenger, donde un objetivo es disminuir la necesidad de desplazamiento.

·         Mientras el mercado de Apps se estanca, 2.500 millones de personas usan al menos una App de Mensajería (WhatsApp, Messenger, etc.) y el número está en pleno crecimiento. Simultáneamente los servicios basados en Inteligencia Artificial se perfeccionan y ellos necesitan una forma de hablar con gente real: los Bots parecen la opción más obvia.

Cuándo son útiles los Bots auditivos

• Los Bots son útiles en servicios como Soporte y Mesa de Ayuda, Reclutamiento, Asistencia a una persona o Coordinación de equipos ya que existe  la necesidad hablar con otro:
•  Los Bots pueden automatizar toda o parte de estas conversaciones.
• Un Bot puede servir de primer nivel o de enlace entre el usuario y el proveedor humano del servicio.
• Los Bots son útiles al mantener la conversación dentro del contexto y con ello se entrega un servicio en forma más rápida y simple.

El naciente ecosistema de Bots

·         Telegram, una plataforma y tiends de Bots.

·         Chatfuel, permite contruir Bots para Telegram. 

·         Pana, una agencia de viaje en línea que acepta mensajes de texto y hace reservaciones. 

·         MeeKan, permite reuniones para usuarios.

·         Assist, un buscador tipo Google para Bots. 

         Operator, un Amazon del Comercio-de-Bots.

Se hace referencia a “Bots, the next frontier” http://econ.st/1NalYXy, “Bots are Back, and They Might Even Be Welcome” http://nyti.ms/1MuVF3F, and “To bot or not to bot” http://bit.ly/1WYSqDR. 

Qué se requiere para trabajar en DevOps?

Al vivir en mundo cada día más digitalizado, la forma y la velocidad en la cual se programa o se hacen desarrollos es cada vez más determinante. Cómo respuesta a esta necesidad ha tomado fuerza “DevOps”, un  método de desarrollo de software que enfatiza la comunicación, la colaboración y la integración entre desarrolladores de software y los profesionales de Infraestructura de TI. Siendo una respuesta a la interdependencia entre el desarrollo de software y las operaciones de TI apunta a ayudar a producir en forma rápida (o ágil) productos y servicios de software. Para mayor información, hace unos meses publiqué en mi blog “Quién no ha escuchado de DevOps?” http://bit.ly/1YHAuw1.

Otra consecuencia de este fenómeno es el impacto que tiene DevOps sobre la profesión de Desarrollador, ya que tiene otros requerimientos de conocimientos y habilidades. Esto impacta de manera muy importante al  personal que ha creado experticia y que vive de hacer Desarrollo e Infraestructura. DevOps se asemeja a lo que podríamos denominar un Programador de Sistemas “moderno” y si un Desarrollador está interesado en convertirse en Ingeniero DevOps no existe un programa de estudios para lograr esto. Los que han entrado a trabajar en DevOps han sido principalmente  desarrolladores interesados en implementación y operaciones de la red, o administradores de sistemas con una pasión por la codificación y el scripting que deciden pasar al lado del desarrollo para mejorar su planificación de las pruebas y de la implementación.

Todo esto sin olvidar que la profesión de Desarrollador es muy solicitada en el mundo y es una de las carreras más importantes para la generación joven.  Uno de los nuevos caminos existentes para que las  personas aprendan Desarrollo con un enfoque más moderno son los “Boot-camps” y hay un interesante ejemplo en el artículo “Open Letter to Employers on Behalf of Bootcamp Grads” http://bit.ly/1NF49A9.  

Encuesta sobre DevOps (2013)

En el mercado la demanda por personas conocedoras de DevOps está creciendo rápidamente, ya que las empresas que lo aplican obtienen excelentes resultados: logran implementar código con una frecuencia 30 veces mayor que sus competidores y sus fracasos de implementación son 50% menores. Curiosamente, solo el 18% de los encuestados podía identificar en sus empresas empleados con la denominación DevOps, ya que se trata de un fenómeno en plena evolución.

Habilidades en DevOps

Hay cuatro áreas de habilidades que se requieren para quienes trabajan en DevOps:

•          Codificación o scripting.
•          Infraestructura.
•          Reingeniería de procesos.
•          Comunicación y colaboración con otros.

Estas habilidades indican que software ya no se escribe como se ha venido haciendo tradicionalmente, antes se escribía desde cero en un proceso muy largo y complejo. Ahora crear nuevos productos es frecuentemente una combinación de (1) la selección de componentes de fuente de acceso libre y coserlos con código, (2) el asegurar que el nuevo software funcionará a través de los diferentes sistemas operativos y plataformas y (3) la aplicación de pruebas e implementación con mayor frecuencia.

Quién construye el software es el mismo que lo opera!

Atributos claves para DevOps

Los atributos incluyen: (A) habilidad de utilizar una amplia variedad de tecnologías y herramientas de código abierto, (B) habilidad de codificar y hacer sripts, (C) experiencia con sistemas y operaciones TI, (D) familiaridad con pruebas e implementación incrementales y frecuentes, (E) comprensión profunda de herramientas de automatización, (F) habilidades de manejo de datos, (G) fuerte foco en resultados de negocios y (H) familiaridad con colaboración, comunicación abierta y el cruce de fronteras entre las especialidades.

Se hace referencia a “As a software engineer, how do I shift my career to devops” http://bit.ly/1LX26vO y “What Is a DevOps Engineer?”  http://bit.ly/1Tgv4s1. 

Los 5 artículos del Factor Tecnológico más leídos en 2015 en el Blog

En esta segunda entrega, aprovecho el cierre del año 2015 para presentar una recopilación de los artículos más leídos correspondientes al Factor Tecnológico de mi Blog en el año 2015:

#1 … “Uber es mucho más que un taxi” http://bit.ly/1Fp3KmB

Uber, más allá de un servicio de taxi se ha convertido en un fenómeno global. Uber, ya hoy en día está ofreciendo otros servicios como taxis compartidos (Uberpool), el servicio de entrega-de-almuerzos (UberEATS) y  un servicio para ordenar suministros para la casa…

#2 … “Quién no ha escuchado de DevOps?” http://bit.ly/1GmZJvj

Ha sido común escuchar las historias de aplicaciones que tomaban años en ser desarrolladas y al final estaban llenas de errores e incluso con cierta frecuencia debían ser desechadas totalmente. “DevOps” es de alguna manera una respuesta que busca corregir esas situaciones, desarrollar más rápido, ir probando en el camino, involucrando a otros en el proceso.. 

#3… “Agricultura 3.0 a la vista” http://bit.ly/1EK6P0i

Agricultura 3.0 representa el futuro para la agricultura basado en la data y en el aprovechamiento del software inteligente, de la Nube y de sensores de bajo costo. También se le conoce como Agricultura de Precisión, ya que se trata de poder llegar hasta al más mínimo elemento, incluso la posibilidad de actuar y controlar el proceso a nivel de planta individual ..

#4 … Qué es Big Data y cuáles son sus retos? http://bit.ly/1MZqg5f

Big Data es uno de esos términos que escuchamos o leemos cotidianamente y nos preguntamos que será exactamente. Por cierto, eso no debe sorprender ya que su significado y su aplicación e impacto están en plena evolución. La descripción más simple y directa  es que se trata de  conjuntos de datos que son tan grandes o complejos que las aplicaciones tradicionales de procesamiento de datos no son adecuadas para su manejo…

#5 … Cuál es el momento para lanzarse a la Nube? http://bit.ly/15HJ5d5

Cuando usamos el buscador de Google, Twitter, Amazon, eBay y cualquiera de los Apps en los teléfonos inteligentes estamos accesando la Nube.  Estas aplicaciones operando desde la Nube llevaron a la creación de un nuevo estilo de computación elásticamente escalable y de auto-servicio en el cual se han comenzado a construir aplicaciones externas e internas a nivel de las empresas. Estas se preguntan cuál es el momento para lanzarse a la Nube...

A partir del año 2016 mi Blog, respondiendo al tipo de material que estoy publicando,  cambiará de nombre y se denominará Factor Humano & Tecnológico

Todavía aplica el Método Ágil de Desarrollo de Software?

Históricamente el Hardware hizo evolución más rápida que el Software y, ya que ambos tuvieron en las primeras etapas su uso en el ámbito empresarial, se aplicó para el Desarrollo de Software una metodología muy estricta especialmente en lo referente a la planificación previa y a la documentación exigida. Los desarrolladores de alguna manera se sentían prisioneros de la documentación y no podían, como era su deseo, dedicar el grueso de su tiempo a lo que disfrutaban haciendo: programar. También los proyectos eran largos y engorrosos y mucha veces frustrantes o fracasaban. En el año 2001 se hizo un  “Manifiesto Ágil” que logró una transformación mayor e hizo que el Desarrollo del Software se hiciera mucho más veloz y a través de los años se han visto los resultados prácticos.

El Método Ágil ha permitido que las apps en nuestros móviles se multipliquen de manera espectacular y en muy poco tiempo. Estamos sintiendo el impacto de la consumerización de la Tecnología de Información y ahora enfrentamos un mundo mucho más complejo. Los proyectos son de mayor impacto y el costo de un fracaso es mucho mayor, y existe la necesidad hacer evolucionar el Método Ágil. Trataremos en el artículo de revisitar el “Manifiesto Ágil”, plantear las circunstancias actuales y algunas opciones y acciones hacia el futuro.

El Manifiesto Ágil en 2001

En el año 2001 críticos de los modelos de mejora del desarrollo de software basados en procesos, se reunieron para tratar sobre técnicas y procesos para desarrollar software. En la reunión se acuñó el término “Métodos Ágiles” para definir los métodos que estaban surgiendo como alternativa a las metodologías formales (CMMI, SPICE), las cuáles consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo. Los métodos alternativos se resumieron  en cuatro postulados, los que han quedado denominados como el “Manifiesto Ágil” donde se plantean que “Están poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros para que lo hagan. Con este trabajo han llegado a valorar”:

1.     A los individuos y su interacción, por encima de los procesos y las herramientas.

2.     El software que funciona, por encima de la documentación exhaustiva.

3.     La colaboración con el cliente, por encima de la negociación contractual.

4.     La respuesta al cambio, por encima del seguimiento de un plan.

Aun cuando hay valor en los elementos de la derecha, se valora más los de la izquierda.

El Manifiesto Ágil 2001 y los Analistas de Negocios

El Manifiesto en el año 2001 fue extraordinario para los equipos de desarrollo de software, pero representó retos reales para los Analistas de Negocios y otras partes importantes involucradas en una visión más amplia del desarrollo de aplicaciones. Los problemas que ya existían con el enfoque ágil en el 2001, todavía están presentes hoy, pero han sido magnificados por el panorama cambiante de la entrega de productos de software y como resultado:

·         Hay más información disponible, posiblemente en exceso.

·         Hay contextos, conversaciones y decisiones no documentadas.

·         Las brechas de  comunicaciones se amplían por la mayor dispersión geográfica de los equipos de trabajo.

·         El tiempo de comercialización se ha recortado dramáticamente.

·         Las necesidades de los clientes siguen sin satisfacerse.

La realidad en 2015

En 2015, hay que seriamente repensar el Manifiesto Ágil, ya que en 2001 cuándo se publicó el “Manifiesto Ágil”, la tecnología para el lugar de trabajo lucía muy diferente a lo que encontramos hoy en día. Los canales de comunicación eran más limitados en variedad y compartir la información no era comparable en facilidad a la que hay hoy en día con Internet de alta-velocidad, data móvil y una multitud de opciones de almacenamiento en la Nube. Es necesario repensar el Manifiesto Ágil ya que: (1) El Mundo ha cambiado, (2) El Software está en todas partes (3), La complejidad ha aumentado y (4) Los proyectos todavía fallan. Por eso bueno preguntarse: (a) Cómo luce el “Ágil” hoy en día?, (b) Los Valores del Manifiesto Ágil todavía aplican?, (c) En cuál momento Ágil pasó de procesos a  actitud o mentalidad?, (d) Cómo se puede integrar la intención del Manifiesto con la nueva forma de trabajo? y (e) Cómo se pueden hacer evolucionar los conceptos de agilidad para enfrentar los retos hoy en día de una nueva forma?.

El Manifiesto Ágil en 2015

Hay quienes proponen que es posible que en un Manifiesto del 2015 se tengan que hacer consideraciones como las siguientes:

·         A los individuos y su interacción, combinado con los procesos y las herramientas.

·         El software que funciona, balanceado con la documentación exhaustiva.

·         La colaboración con el cliente, combinada con la negociación contractual.

·         La respuesta al cambio, combinada con el seguimiento de un plan.

Los valores de la izquierda y de la derecha deben ser balanceados.

A esto habría que agregar que en las metodología futuras estarán presentes los siguientes elementos: (a) La data y las ciencias conducirán las decisiones, (b) La cultura será un foco, (c) El comportamiento individual será un conductor y (d) Las herramientas tendrán un rol mucho más determinante.

Algunas recomendaciones para hoy en día

Mientras no aparezca una actualización formal de la Metodología Ágil hay algunas recomendaciones que aplican:

•     Tomar una pausa y repensar temas como estos: (a) Desacoplar el Manifiesto de Ágil, (b) Continuar la evolución del entendimiento y la definición del fracaso, (c)  Evaluar los métodos usados para la comunicación, (d) Hacer seguimiento de las métricas y usarlas para iterar y (e) Pensar en Agilidad desde el punto de vista organizacional.
•    Comunicar: (a) Encontrar formas de constantemente proveer visibilidad a la organización, (b) Permitir el flujo libre de las comunicaciones y las opiniones, (c) Identificar donde las decisiones son tomadas y capturadas y (d) Constantemente preguntar a la gente si entienden no solamente lo que hacen sino también el por qué lo hacen.
•         Evolucionar: (a) Abrir el diálogo sobre cultura, (b) Abrazar los procesos, (c) Comunicar, comunicar, comunicar y (d) Es preferible empezar con exceso de información, a partir de allí se puede seleccionar y limitar para balancear.

Se hace referencia a “A Modern Take on the  Agile Manifesto” publicado por Jama Software (Disponible por solicitud en formato Adobe) y “The Agile Business Analyst: How Much Is Enough?” publicado por Global Software (Disponible por solicitud en formato Adobe).

Quién no ha escuchado de DevOps?

Es casi imposible hoy en día leer publicaciones o noticias asociadas a tecnología de la información y no encontrar artículos y referencias a ”DevOps”.  Así que siendo “DevOps” una expresión cada vez más común en la literatura de tecnología parece oportuno tratar de conocerla y entenderla.  Una de los aspectos más interesantes es que se trata de un concepto que recibió reconocimiento y denominación hace muy poco tiempo, ha crecido rápidamente y se encuentra en pleno proceso de evolución.   Por lo tanto seguramente en unos años, “DevOps” será bastante diferente a lo que encontramos ahora. 

Incluso aquellos que no están directamente asociados a Computación han escuchado las historias de aplicaciones que tomaban años en ser desarrolladas y al final estaban llenas de errores e incluso con cierta frecuencia debían ser desechadas totalmente. “DevOps” es de alguna manera una respuesta que busca corregir esas situaciones, desarrollar más rápido, ir probando en el camino, involucrando a otros en el proceso.  “DevOps” trata principalmente de romper barreras en la forma de trabajo y barreras culturales entre desarrollo y operaciones (los que ejecutan las aplicaciones) y está asociado a las expectativas que las líneas del negocio tiene de lo que Tecnología le pueda aportar.  En la cobertura del artículo se cubrirán con respecto a “DevOps” los temas de definición, historia, los factores que lo impulsan y los componentes. 

Definición

DevOps es un acrómino de (Dev= Desarrollo y Ops=Operaciones), por lo tanto abarca ambos campos, siendo tan reciente su origen, que existen múltiples y variadas definiciones, así que a continuación presentamos una definición personal.

“DevOps” es un método de desarrollo de software que enfatiza la comunicación, la colaboración y la integración entre desarrolladores de software y los profesionales de Infraestructura de TI.  Siendo una respuesta a la interdependencia entre el desarrollo de software y las operaciones de TI apunta a ayudar a producir en forma rápida (o ágil) productos y servicios de software.  Extendiendo el concepto al mundo corporativo, donde se manejan grandes volúmenes y se requiere una capacidad repetitiva de todos los procesos asociados a Desarrollo de software,   “DevOps” expande su enfoque basado en principios de eficacia y agilidad para incluir a los responsables de las líneas de negocios que conjuntamente con las unidades de Desarrollo, Operaciones y Control de Calidad colaboran para entregar aplicaciones de software en forma continua lo cual permite a las líneas de negocios aprovechar más rápidamente oportunidades de negocios y reducir el tiempo de despliegue de las aplicaciones incluyendo la retroalimentación de los clientes. 

“DevOps” ofrece una gran caja de herramientas que trabajan en forma automática alrededor de los requerimientos de desarrollo de aplicaciones y facilitan todo ese proceso.  Los desarrolladores reciben lo que necesitan para su trabajo, Infraestructura puede cumplir sin tanto esfuerzo.  Estas herramientas se pueden dividir en conjuntos que soportan cada paso del ciclo de desarrollo:  desde codificación, siguiendo a integración, apoyando implementación  o despliegue y completando el ciclo con monitoreo y reporte de fallas. 

Historia

El término DevOps se popularizó a través de unas conferencias denominadas “Días de DevOps” que se iniciaron en 2009 en Bélgica.  A partir de ese momento esas conferencias han continuado realizándose en Estados Unidos, Brasil, Australia, Alemania, Suecia y Nueva Zelanda.  El término DevOps comenzó a aparecer en Internet en la primavera del año 2010. 

Factores que lo impulsan

La adopción de DevOps está siendo propulsada por varios factores que incluyen:

·         Los grandes volúmenes de aplicaciones que se necesita desarrollar y la respuesta rápida que se espera.

·         La demanda de actualizaciones más frecuentes a las aplicaciones, por parte de los responsables de las unidades de desarrollo y también de las unidades de negocios.

·         El uso cada vez más extendido de diversos procesos y metodologías de desarrollo, particularmente las metodologías ágiles.

·         La mayor disponibilidad de infraestructura virtualizada y de infraestructura en la Nube, tanto en forma interna dentro de las empresas como la ofrecida por proveedores externos.

·         El aumento en el uso de herramientas de automatización del Centro de Datos y de la Administración de las Configuraciones. 

Los componentes

Los principales componentes que conforman DevOps incluyen:

ü  Herramientas de Desarrollo (abarcando el código que generalmente reside en un repositorio compartido y las herramientas de Administración de Defectos que son utilizadas para identificar las fallas en las aplicaciones).

ü  Herramientas de Integración del Código (utilizando un servidor de integración continua desde donde los programadores pueden tomar el código que reside en un repositorio compartido, lo construyen, lo prueban y reportan los resultados).

ü  Ambientes y herramientas de implementación (los cuales varían dependiendo de la plataforma de operaciones y de la infraestructura adicional disponible).

ü  Herramientas de monitoreo de las aplicaciones en fase de producción.

ü  Reportes de Bugs, conjuntamente con los ambientes donde estos ocurren y las herramientas requeridas para reproducir esos ambientes.

ü  El ciclo de DevOps se repite eteramente, ya que DevOps busca que en este ambiente complicado la capacidad de desarrollo no se estanque.  El propósito de DevOps es que los elementos rutinarios sean fáciles y rápidos de ejecutar de manera que los desarrolladores se puedan concentrar en crear nuevas funcionalidades o atributos y en corregir los bugs. 

Los principios de DevOps

DevOps se basa en principios que todavía están en evolución y ellos son: 

Desarrollar y probar contra sistemas que emulan los de producción

El objetivo aquí es permitir que los equipos de desarrollo y de aseguramiento de la calidad desarrollen y prueben contra sistemas que se comportan tal como lo hace el sistema en su fase de producción.  De esta manera se puede observar cómo se comporta la aplicación y también su desempeño, mucho antes de que esté lista para su despliegue. 

Se busca probar la aplicación bajo el ambiente más parecido al real y simultáneamente también se busca validar los procesos de entrega de aplicaciones.  Desde el punto de vista de Operaciones este principio tiene un enorme valor, ya que permite ver muy temprano en el ciclo cómo se comporta el ambiente que debe soportar la aplicación y permite eventualmente crear las bases para poder entonar ese ambiente en función de la aplicación.  

Desplegar bajo procesos confiables y repetibles

Este principio permite a Desarrollo y Operaciones apoyar un proceso de desarrollo ágil e iterativo en todas las fases hasta producción.  La automatización es esencial para poder crear procesos que cumplan con las siguientes condiciones: iterativos, frecuentes, repetibles y confiables.  Esto le permite a la organización crear una cartera de entregables, donde los despliegues y las pruebas se pueden realizar en forma automática y continua.  La ejecución frecuente de despliegues también permite poner a prueba los procesos de despliegue, limitando los riesgos de fallas en los momentos de entrega.   

Monitorear y validar la calidad operacional

Típicamente las organizaciones son muy buenas monitoreando aplicaciones y sistemas en producción, ya que existen muchas opciones para hacer esto y ellas utilizan herramientas que permiten capturar las métricas de producción en tiempo real.  Sin embargo, este monitoreo es realizado sobre  aplicaciones individuales,  donde las aplicaciones no están conectadas las unas con las otras.  DevOps exige que el monitoreo sea realizado más temprano en el ciclo, requiriendo además que se haga monitoreo de las características funcionales y de las características no-funcionales de la aplicación.   

En cualquier momento, a medida que las aplicaciones están siendo desplegadas y probadas, DevOps exige que se capturen métricas de calidad y que sean analizadas. Este monitoreo frecuente provee aviso tempranero sobre temas operacionales y de calidad que podrían aparecer posteriormente en la etapa de producción.  Adicionalmente, las métricas deben ser capturadas en un formato que sea entendible y utilizable para todos los interesados, incluyendo a los responsables de las aplicaciones en las líneas de negocio.  

Ampliar círculos de retroalimentación

Uno de los principales objetivos de DevOps es permitir a las organizaciones reaccionar y poder realizar cambios rápidamente en sus procesos de negocio.  En la entrega de software, el objetivo se transforma en proveer retroalimentación en un corto tiempo y además poder aprender rápidamente de cada acción que se toma.  Las organizaciones deben crear canales de comunicación que permitan a todas las partes interesadas accesar la información y actuar sobre la base de la retroalimentación y por ello:

·         Desarrollo puede actuar ajustando sus planes de proyecto o sus prioridades.

·         Producción (Operaciones) puede actuar mejorando los ambientes de producción.

·         Las Líneas de Negocios pueden actuar modificando sus planes de implementación. 

Para el artículo se usaron como referencia materiales provenientes de: “Elements of DevOps” (InfoWorld) http://bit.ly/1z7bm6j , “DevOps for Dummies” 2014 y en (Information-age) - “Why 2015 is the year of DevOps culture”  http://bit.ly/1zwVtHi, “An (absolute) beginner’s guide to DevOps” http://bit.ly/166Gutc y Survival of the fittest: Will DevOps save IT from going the way of the dodo? http://bit.ly/1yQzVpc