Introducción a DevOps - ¿El siguiente paso a Scrum?

El desarrollo de software con Scrum, que comenzó con algunos equipos pioneros hace unos pocos años, se ha convertido en una tendencia creciente sinó ya del "mainstream". Es actualmente el modelo de desarrollo más extendido, aunque dista aún bastante de ser mayoritario y que se realice de manera madura allá donde se introduce.

"Cada empresa es un mundo", pero de la misma manera que Scrum se ha hecho enormemente popular, en general aún no ha alcanzado una integración suficientemente buena con las operaciones (explotación, producción...) fuera de las start-ups y los equipos muy pequeños.

Por otra parte, durante la década del 2000 se expandieron movimientos y frameworks como Enterprise Systems Management (ESM) e ITIL v2. Estos movimientos, que han aportado notables mejoras a la estabilidad de producción, han estado centrados principalmente en organizaciones grandes y proveedores IT como IBM, HP o CA.

Una visión alternativa, originada en la "pesadez" y la pobre adaptación a las empresas más pequeñas de estas aproximaciones, tomo forma en el concepto de DevOps, acuñado por Patrick Debois en 2009. Desde entonces se han ido sucediendo eventos (como los DevOpsDays) y webs dedicadas a la materia.

En resumen, actualmente la visión generalizada de los departamentos de IT según los grupos de desarrollo de software y de explotación/sistemas puede ser:

• Desarrollo: quiero construir y publicar lo que me pide el negocio con agilidad.
• Explotación: me miden por el coste y disponibilidad. No quiero riesgos.

El resultado muchas veces consiste en despliegues grandes y espaciados en el tiempo, con una pobre comunicación conjunta, que suele producir errores, retrabajo y más coste que haberlo hecho de manera conjunta desde el principio.

DevOps.org

El enfoque de DevOps comparte la agilidad de Scrum para mejorar la comunicación entre cliente (el negocio) y el proveedor (desarrolladores), fomentando la confianza, la compartición del plan y del avance en el trabajo, y tomando un feedback frecuente. Al igual que el Scrum Master y el Product Owner actúan como los responsables de la coordinación entre negocio y desarrollo, el DevOps engineer se encarga de planificar y seguir la coordinación entre desarrollo y operaciones, aunque sin tener necesariamente mando sobre éstos.

LMC Software

El rol principal en DevOps es Ingeniero de operaciones, similar al Chief Engineer el Toyota Production System. Consiste en coordinar a los equipos de desarrollo y a los administradores, aunque no tiene autoridad final sobre los equipos.

Attunity.com

Aunque DevOps tiene una fuerte relación con las herramientas que automatizan las operaciones (p.e. Jenkins, BuildForge, Puppet Labs, etc.) el aspecto fundamental son los procesos integrados entre desarollo y producción. No se trata de "hacerlo igual de mal, pero más rápido".

En España todavía no han habido eventos importantes sobre DevOps, si bien en Madrid hay un grupo de interés con bastante actividad. 

En próximos posts seguiré escribiendo sobre DevOps, y ¡estaré encantado de contactar con otras personas que estén interesadas sobre esta materia!

Chrome va lento con Flash

Un post off-topic sobre Google Chrome.

Desde las últimas semanas (agosto 2012) vi que Chrome va muy lento en aplicaciones con Flash (p.e. Gmail), convirtiéndose en una tortura.

El problema es uno de los plugins de Flash (PepperFlash) que falla. Para desactivarlo, 

1. Pegad en la URL:  chrome://plugins/
2. Localizar el plugin de flash (suele ser el 1º)
3. Click en "+ Details"
4. Desactivar PepperFlash y reiniar.
5. Voilà!

http://www.monkeycoder.co.nz/Community/posts.php?topic=3384

Plan de empresa Barcelona con Kit-emprendedores.com

Kit-emprendedores.com es una iniciativa de Cynertia Consulting que tiene como objetivo reunir su experiencia en la creación de Planes de negocio y el apoyo integral a los emprendedores.

En esta web se encuentran descritos los servicios y recursos que se ofrecen de soporte a la creación de empresas:

• Plan de empresa
• Web de empresa, posicionamiento en Google y guías
• Tienda virtual
• Soporte tecnológico
• Selección de local y proveedores

La filosofía de Kit-emprendedores es reutilizar la experiencia acumulada en proyectos reales para economizar el soporte, manteniendo en todo momento una atención totalmente personalizada y de alta calidad.

Scrum, PMBOK, modas y comparaciones

Hace unas semanas pude asistir a una interesante sesión organizada por la gente de Agile Barcelona, titulada "Agile, State Of The Art".

Aunque el objetivo de esta sesión no era introducir las metodologías y técnicas ágiles más conocidas y difundidas como Scrum o Kanban, sinó explicar que se está haciendo de nuevo en este ámbito, en algunos momentos se estableció el (clásico) debate sobre cuando es mejor aplicar Scrum y cuando otras metodologías tradicionales de gestión de proyectos (simbolizadas por PMBOK).

Este debate me inspiró a escribir este post, debido a que creo que existe cierta confusión sobre los factores que hacen que aplique más un tipo de metodologías que otras.

El entorno importa, más que la metodología.

Uno de los tópicos que se introdujo fue: en las metodologías tradicionales se negocia mal el alcance al comenzar y luego eres prisionero del "triángulo de acero". Esto pasa habitualmente por situaciones del contexto como:

• Comerciales (y clientes) poco capacitados.
• Empresas que entran conscientemente en proyecto sabiendo que sus propuestas son con pérdidas para "entrar en un cliente".
• No se consulta al equipo técnico, la oferta "es algo del comercial". 
• Competencia caníbal (yo me bajo los pantalones más que el otro), etc.

En mi opinión, se confunde una mala praxis habitual con las supuestas debilidades de metodologías tradicionales. Estos factores claramente son identificados como riesgos a evitar en PMBOK y por tanto, no se pueden atribuir como limitaciones de las metodologías "tradicionales". Además, si estamos en un entorno como estos, caracterizados por la poca capacidad, competencia desmedida, desconfianza entre cliente y proveedor, etc. Scrum tampoco funcionaría.

Todos solemos usar más la herramienta que más conocemos.

En la sesión creo que hablaron (hago una simplificación) fans de metodologías tradicionales, metodologías ágiles y otros "equidistantes" entre ambos tipos de metodologías.

La foto de la cabecera representa una cosa que me dijeron hace años cuando trabajaba en IBM "si sabes usar bien un destornillador, tenderás a clavar clavos con él". Es una tendencia natural entre todos la de confiar más en la metodología que más conocemos y desconfiar de aquella que conocemos, aunque no sea la que más se adapta al problema a resolver.

Igual que no tiene sentido aplicar PMBOK o Prince2 en proyectos claramente indefinidos y donde hay un alto grado de confianza entre cliente y proveedor (p.e. desarrollo interno de producto), tampoco tiene sentido aplicar Scrum donde hay poca confianza entre ambas partes, o donde existen altos costes asociados que deben ser evaluados cuidadosamente antes de comenzar el proyecto.

Haciendo una exageración, ¿alguien se imagina construir una central nuclear o una presa por iteraciones? ¿Podemos pasar al backlog del siguiente sprint una mejora en la reducción de escapes de radioactividad?

Mundo académico, mundo blogger y mundo profesional.

Los diferentes ámbitos tienen diferentes dinámicas, y en mi experiencia se decantan mayoritariamente hacia diferentes modelos de ver la gestión de proyectos. Digo mayoritariamente, porque lógicamente es imposible encontrar audiencias uniformes en estos ámbitos tan grande.

El mundo académico es pionero en el desarrollo y aplicación de técnicas, y explica desde hace décadas los modelos tradicionales de gestión de proyectos e ingeniería del software, pero en general es menos sensible a la evolución profesional y por ambas cosas, suele orientarse más a la aplicación estricta de la gestión de proyectos tradicional.

El "mundo blogger", entendido como los expertos que escriben en blogs, comunidades y redes sociales, es mucho más dinámico que el académico y difunde más rápidamente las tendencias y novedades. Por ello encontramos que la mayoría de autores en Internet hablan sobre Agile, más fácil de comenzar a usar (no siempre suficientemente bien) que sobre metodologías tradicionales.

Por otro lado, creo que existe una tendencia por parte de muchos bloggers que son freelances u ofrecen servicios de consultoría a ensalzar lo bueno que es aplicar la metodología que dominan y a demonizar (o situar como "pasado de moda") lo que no dominan. Esto, tristemente, pasa frecuentemente con Scrum.

Finalmente, el "mundo profesional" es seguramente el más variado. Existen empresas certificadas y muy orientadas al "compliance" de metodologías, otras que han adoptado completa o parcialmente Agile, y muchas otras que usan lo que traen como experiencia sus trabajadores. Cada empresa es un mundo.

¡Queremos vuestros comentarios!

Esta es mi visión del asunto, reconociendo que generalizar en "4 líneas" es un ejercicio siempre incompleto, pero aportando mi opinión sobre lo que la confusión y comparaciones equivocadas que se establecen entre las diferentes metodologías.

Me gustaría recibir vuestros comentarios, seguro que son enriquecedores vuestros puntos de vista.

Nueva versión de WorkBook, el ERP lider para empresas de servicios

Workbook A/S, el fabricante del ERP lider para empresas de servicios del sector de publicidad y servicios profesionales ha publicado la versión 8.2 de WorkBook.

Este producto cubre las principales necesidades de las empresas orientadas a proyectos, mediante las siguientes módulos:

• CRM para gestionar oportunidades y crear ofertas de proyectos
• PM para definir calendarios de trabajo, asignar tareas, controlar el avance del proyecto e imputar las dedicaciones
• FI para gestionar la facturación y la contabilidad

Esta herramienta es web y se puede operar tanto en la nube (pagado por uso de usuarios y módulos), tanto como en la infraestructura de la empresa.

Esta nueva versión incorpora novedades que aumentan la facilidad de uso y flexibilidad del producto.

Gestión ágil de equipos vs Parálisis burocratica

Uno de las principales dificultades que supone la gestión de personas, y particularmente la de equipos, es la burocracia que se establece cuando los equipos crecen e incorporan personas con poca experiencia trabajando conjuntamente.

Todos podemos reconocer este fenómeno que suele reducir considerablemente la eficiencia y eficacia de los equipos, así como la moral de aquellos miembros más activos de estos grupos que trabajan activamente a favor de la mejora de la comunicación.

El Dr. Michael Sutcliffe de la Universidad de Cambridge, identifica en un artículo [1] los 8 síntomas características del fallo en la comunicación (8 Symptoms of Communication Breakdown), que son los siguientes:

1. La decisión invisible: no se sabe claramente quien toma realmente las decisiones.
2. Trabajo inacabado: se inician muchas tareas y se acaban pocas.
3. Parálisis en la coordinación: no se puede hacer nada sin validarlo con todas las partes.
4. Nada nuevo: no hay ideas o pensamientos laterales radicamente nuevos.
5. Pseudo-problemas: pequeños impedimentos se convierten en problemas insalvables.
6. Guerras centralizadoras: el "centro" lucha para mantener "la consistencia y el control" sobre las unidades independientes.
7. Dominación de las entradas: las personas reaccionan cuando se les asigna una tarea pero no asumen ninguna responsabilidad proactivamente.

Estos síntomas, con los que podría estar de acuerdo cualquier fan de la clásica serie británica Yes Minister, me llamaron la atención y pensé en analizar como los afrontan las metodologías de gestión ágil como Scrum. Revisitando la lista tenemos lo siguiente:

1. La decisión invisible: Scrum tiene claramente definidos los roles (Product Owner, Scrum Master, Development Team), así como cuando y como se toman y documentan las decisiones.
2. Trabajo inacabado: este fenómeno no se puede producir en Scrum, pues se eligen cuidadosamente las funcionalidades a incluir en cada Sprint (Sprint Backlog) y en caso que alguna de ellas no se pueda acabar se devuelve al contenedor del proyecto (Product Backlog).
3. Parálisis en la coordinación: de nuevo esto no se da en Scrum pues la coordinación se reduce a momentos puntuales (Daily Scrum) y las tareas son asignadas a una persona únicamente.
4. Nada nuevo: Scrum respeta de manera explícita la comunicación abierta y el respeto por los demás. Igualmente existen momentos definidos para encontrar mejoras al proceso (Scrum Retrospective) y al producto (Scrum Review).
5. Pseudo-problemas: en Scrum, las dificultades que tienen los miembros del equipo se comentan sistemáticamente con carácter diario (Daily Scrum) y tienen el soporte del equipo para impedir que se conviertan en problemas serios.
6. Guerras centralizadoras: este puede ser uno de los problemas en la implantación de Scrum para organizaciones complejas. En el libro [2] se detallan técnicas para establecer un buen marco de colaboración entre la oficina de proyectos, product managers y product owners.
7. Dominación de las entradas: los miembros del equipo toman de manera autónoma la responsabilidad sobre las funcionalidades y tareas a implementar, sin esperar a que nadie se las tenga que asignar.

Como resúmen, Scrum (y otras metodologías ágiles) atacan con efectividad la problemática de la burocracia en el ámbito de la gestión de proyectos. Un ámbito muy interesante que queda por  es la extensión de estos principios ágiles a la gestión de procesos y funciones de empresas no orientadas a proyecto, espero publicar algún post una vez haya leído el siguiente libro [3] que tengo en cartera.

Referencias:

• [1] The Personal MBA - P218. Communication Overhead. Nota: no he podido localizar el artículo original del Dr.Sutcliffe que aparece citado en esta sección.
• [2] Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Dean Leffingwell. 2011 Addison-Wesley Professional. 
• [3] The Leader's Guide to Radical Management: Reinventing the Workplace for the 21st Century. Stephen Denning. 2010  Jossey-Bass.

Spanair y el Cloud Computing:

El 28/1/2012 Spanair dejó de operar de manera súbita. Aunque muchos estaban al corriente de sus dificultades financieras, la gran mayoría del público la veía como una compañía asentada y fiable. La sorpresa fue mayúscula.

Este caso puede ser relevante en la discusión actual sobre el futuro de la computación. En los últimos años, y de manera más intensamente desde 2011, los términos "cloud computing", "ahorro energético", "pago por uso", "public cloud vs private cloud", etc. cada vez se oyen de manera más frecuente y parece que la cuestión no es si el modelo actual de  computación basado en poseer el software (libre o con licencia, de código abierto o cerrado) y operarlo va a continuar, sinó cuanto tiempo falta para la migración más o menos masiva al cloud.

Además de los actores consolidados de infraestructuras (Amazon EC2, Google, IBM, Microsoft, etc.) y de aplicaciones (Salesforce, Google Apps, Microsoft, WebEx, etc.) han aparecido multitud de "miniaplicaciones" verticales muy usadas para hacer casi de todo, p.e.:

1. Compartir pantalla (p.e. join.me)
2. Compartir documentos y presentaciones (p.e. Cacoo.com y Sinc.in)
3. Mantener diagramas Gantt de proyecto (p.e. Gantto.com)
4. Y un larguísimo etcétera.

Muchos de estos proveedores, especialmente aquellos que ofrecen aplicaciones con una mínima complejidad y necesidad de integración, ponen a disposición de los usuarios APIs que permiten su integración e incluso el "backup" de datos.

Así pues, usando de "aquí y allá" las funcionalidades que más nos interesan, podemos integrarnos un mapa de aplicaciones independientemente de si estas están "operadas" por nosotros o por terceros. El esquema "best of breed", sin duda parece muy interesante.

Ahora bien, más allá de todos los matices de este modelo, la dudas básicas que se plantea es: 

1. ¿qué pasa si un proveedor deja de operar así, sin más, como hizo Spanair? 
2. Por mucho que tengamos garantías en forma de contratos, SLA, capacidad de hacer backup de datos, etc. ¿qué pasaría el día siguiente con esta aplicación?
3. ¿Y con los datos? 
4. ¿Y las integraciones con terceras aplicaciones?

Como es sabido, este modelo presenta sus incógnitas, por mucho que nos imaginemos que ciertos proveedores son "grandes y estables", como lo parecía Spanair para el público general.

Además de poder hacer "backup" de los datos, es conveniente para mitigar este riesgo poder cambiar de "operador de infraestructura" si el que usamos actualmente falla. Y eso, de momento sólo pasa por tener a mano el código.

¿Podemos usar aplicaciones (p.e. de código abierto) y operarlas en un cloud privado (p.e.Capside)? Puede ser una solución mientras los proveedores (o markets) no tienen en cuenta esta problemática.