En el último Wednesday Break celebrado en CAPSiDE, Enric Segarra destacaba, entre otras cosas, la importancia de que el departamento comercial de una empresa sea capaz de intuir o detectar los cambios de paradigma en la industria y que la empresa lo respalde y apueste por ello para poder liderar el sector a medio o largo plazo. En el campo tecnológico por ejemplo, se está consolidando ya el cambio de paradigma del hierro (servidores físicos apilados en centros de datos) al cloud (máquinas virtuales generadas on-demand). Del mismo modo, el equipo de operaciones debe detectar los cambios de paradigma de su campo y adoptarlos si encajan en la estrategia y filosofía de la empresa y del mismo equipo.

En Managing Your Self, Jagdish Parikh muestra cómo las cosas están cambiando en todos los aspectos y todos los niveles: cuando antes las estrategias eran planeadas, ahora se aprecia la innovación; las viejas estructuras eran jerárquicas, mientras que ahora tiene más forma de red intercomunicada; antes el valor se encontraba en «ser igual pero mejor» que la competencia, ahora se buscan los factores diferenciadores; se está cambiando el foco de atención de la institución al individuo; y el liderazgo ya no busca ser dogmático, sino inspirador.

Para los equipos de operaciones, los cambios se dan en 2 aspectos:

Quedarse atrás en cualquiera de los dos aspectos puede tener graves repercusiones en el futuro de la compañía. En este sentido, se ha hablado largo y tendido de las metodologías ágiles que hace ya años que están desplazando poco a poco los viejos métodos. Los cambios que implican las metodologías ágiles van desde la gestión del equipo por parte del CTO a las tareas de cada día para los operadores.

En administración de sistemas, concretamente, se daba hasta hace poco de forma habitual el modelo de vieja escuela consistente en sysadmins trabajando individualmente, en proyectos separados, con asignación de tareas por temas (él es experto en bases de datos, ella en servidores web, el de más allá en clústeres de computación, etc.). Esto supone diversos problemas, empezando por un bus factor bajísimo, incluso hasta de valor 1. Esto significaría que, en caso que uno de los componentes del equipo faltara, el proyecto no podría continuar sin graves problemas o retrasos importantes, con indeseables consecuencias para la compañía.

Las metodologías ágiles empujan al equipo a comunicarse, a trabajar juntos, a implicar a todo el mundo en todas las tareas, con una visión conjunta.

Esto no significa que todos los miembros de un equipo hagan el mismo trabajo, pero sí que estén al corriente de lo que hacen los compañeros, para así detectar problemas rápidamente y solucionarlos. Todo el mundo se mueve en la misma dirección. Los equipos ágiles son flexibles, se adaptan a los imprevistos y tienen un alto bus factor. Algunas de las más conocidas son el Kanban, el Scrum o el Extreme Programming.

Aunque se suele hablar de estas técnicas en referencia a equipos de desarrollo de software, son también perfectamente aplicables a los administradores de sistemas. Una reunión conjunta el pasado mes de marzo entre el grupo de Sudoers de Barcelona y la Comunidad Agile-Barcelona reveló, tras comparar experiencias, que los problemas que afectan a unos y otros no son tan diferentes como ambos grupos suelen pensar. Se coincidió también en que, aunque parece evidente que las nuevas metodologías pueden ayudar muchísimo a la productividad de los equipos y a reducir el estrés de los individuos, la resistencia de algunos gestores o miembros de los grupos hacía que fuese duro implantarlas. Sin embargo, se concluyó que vale la pena intentarlo e insistir, pues al romper esta resistencia inicial, las ventajas se ven en seguida.

Los stand-up meetings de Scrum, la limitación de las tareas que se pueden aceptar de KanBan, o el Pair Programming de Extreme Programming son sólo algunas técnicas concretas que se pueden aplicar. Sin embargo, cada equipo puede adaptar estas técnicas a su estilo y funcionamiento habitual. Si los componentes del equipo están cómodos y la aplicación de las metodologías no es forzada, el cambio es más fácil y todo el mundo se beneficia.

En equipos dedicados a la tecnología, mantenerse al día de los cambios del sector es crucial para ofrecer los mejores servicios de forma rápida y ágil, para no atar al cliente a una solución que se queda anticuada en poco tiempo y para no responder lentamente a nuevas necesidades. Tener un equipo de sysadmins flexible, dispuesto a escuchar y aprender, capaz de responder a las emergencias sin causar perjuicios a otros clientes, y que no sufra si falla algún miembro, es un factor vital para el éxito del departamento TIC de cualquier empresa.

En CAPSiDE hace ya tiempo que utilizamos metodologías ágiles en nuestro equipo de «operaciones», e intentamos mejorarlas y adaptarlas a las necesidades reales de nuestros ingenieros y clientes. Con ello hemos notado una mejora considerable en eficiencia y aprendizaje del equipo, que se traduce rápidamente a un mejor y mayor valor para nuestros clientes.

TAGS: agile, ágiles, aprendizaje, devops, eficiencia, equipos, ingeniería, method, metodologías, operaciones

speech-bubble-13-icon Created with Sketch.
Comentarios
Marcos | septiembre 16, 2014 9:46 pm

Hola.

Antes de nada dar la enhorabuena a Alba por el fantástico articulo.

En nuestra empresa llevamos aplicando la metodología scrum desde hace 6 meses… Personalmente me parece una medida fantástica que se ha adaptado a la perfección a todos los equipos de developers, pero que en el departamento de sistemas (yo soy sysadmin) no se ha adaptado nada bien. Nunca acabamos nuestros sptints a tiempo, ni teniendo en cuenta la desviación de soporte, los imprevistos, apagar fuegos, actualizaciones no programadas etc… Es verdad que no tenemos un scrum máster pero ponemos un esfuerzo titánico en cumplir todos los puntos de scrum, standup meetings, definir sprints, loguear horas en jira, etc… Y este esfuerzo tan grande nunca se ve recompensado, al revés, finalmente tenemos un burntout chart catastrófico, sprint no cumplidos y una represalia por parte de los superiores.

Siento el comentario pesimista pero después de tanto tiempo y esfuerzo invertido en esta metodología para el departamento de sysadmin solo puedo sacar dos conclusiones posibles: o no aplicamos nada bien la metodología (cosa que me da coraje puesto que todos los demás equipos les va bien) o realmente no se puede adaptar al departamento de sistemas….

Un saludo.

Reply
jlmartinezbcn | julio 11, 2012 4:42 pm

¡Gracias por tu comentario Alberto!

La idea, que intentamos seguir en el día a día dentro de nuestro equipo, es que sí que haya un compañero “experto” en ciertos campos, pero al mismo tiempo creemos en compartir todo el conocimiento posible con los demás componentes del equipo. Con esto conseguimos que cualquier/a de los ingenieros/as puedan dar soporte directo al cliente final pudiendo ser resolutivos.

No se trata de que todos seamos expertos en todo, pero sí que conozcamos los conceptos principales y sus métodos de setup y troubleshooting (muchas veces, la tecnología de base es la misma). De hecho llevamos a cabo sesiones internas de formación desde hace años donde el “experto” comparte sus experiencias y todos aprendemos.

Por otro lado, nosotros no nos dedicamos al desarrollo de software sinó a la ingeniería de los sistemas. No nos gusta ver el área de sistemas como “aquellos que se encargan del hierro y el data center”. Creemos que con la llegada del Cloud Computing el área de sistemas no desaparecerá como tal, sinó que se transformará en una área que tenga que decidir entre los diferetes perfiles de cloud (no todos ofrecen lo mismo y cada proyecto requiere de uno en particular para conseguir sus objetivos), y diseñar los sistemas para aprovechar al máximo las nuevas posibilidades que brindan los diferentes clouds. Creemos que la figura del ingeniero de sistemas (SysAdmin, Redes/Networking, Troubleshooting y Co-Sourcing a cliente de manera cercana) es una figura clave y que seguirá siendo necesaria.

Es altamente probable que siempre haya migraciones, falta de estandarización entre “clouds” y fine-tunnings de aplicación/servidor por ejemplo, ya que las aplicaciones dependen del hardware que hay debajo (aunque sea virtual) y del diseño de las plataformas.

La complejidad creciente del software que comentas también supone una complejidad creciente de los sistemas, y en especial del diseño de arquitecturas de sistemas para que las plataformas resultantes sean escalables.

De nuevo gracias por tu comentario y por compartir tus opiniones con nosotros.

Jose Luis Martinez
CTO de CAPSiDE

Reply
neodexion | julio 11, 2012 1:32 pm

Básicamente estoy de acuerdo, pero no se ha tenido en cuenta la entropía.

Actualmente, el nivel de complejidad del software está creciendo exponencialmente, lo que ocasiona la necesidad de «especialistas». ¿Alguien recuerda al famoso Webmaster que hacia de todo?… Ahora se requiere especialistas en cada materia… incluso en cada producto.

Lo curioso del tema es que la solución más ¿ágil? puede estar en «la nube» y por tanto, desmantelar o transformar el área de «sistemas» a cambio de sistemas en la nube (Azure… etc).

@albertofdez
MeBA, IT Architect & Agile Coach.

Reply

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*