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.