viernes, 20 de junio de 2014

Implementando agile en una empresa tradicional

Acabo de leer una nota de InfoQ acerca de la necesidad de entrenar y acompañar a los gerentes de IT (y sumaría de las áreas clientes) en metodologías ágiles para asegurar que se implemente de manera exitosa las políticas y prácticas propuestas.

Leer esta nota me hizo pensar en la tarea que estamos encarando en la empresa para cambiar la forma de trabajo en IT, buscar mayor agilidad, previsión y calidad en lo que producimos.

Desde fin del año pasado estoy empujando la implantación de metodologías ágiles en la empresa. Es un cambio cultural enorme y un desafío profesional que me propuse encarar con todas mis energías.

En un principio eramos unos pocos locos los que iniciamos con la idea de agilizar la forma en que producimos software, basándonos en metodologías ágiles (luego la base sería SCRUM), los principios de Lean y la filosofía de DevOps. Ese grupo de 3 o 4 locos con un conocimiento previo casi nulo comenzamos a estudiar y leer mucho, para luego sentar las bases de la nueva forma de trabajo que íbamos a proponer, y comenzamos la cruzada de sumar adeptos para formalizarlo.

Una vez que formamos una masa crítica de gente convencida de que era necesario cambiar, era necesario hacer que el efecto contagio escalara a toda la organización. Comenzamos de la manera tradicional, presentando al top management lo que proponíamos como cambio. Luego de una presentación de unas horas compraron el cambio (volveré a este punto en un rato), con lo que teníamos luz verde para seguir escalando a toda la empresa (una empresa con miles de empleados, con una base de personas que trabajan en IT del 5%). Las tareas que nos propusimos (y realizamos) fueron:

  1. Medir la temperatura de las ganas de cambio. Esto lo hicimos mediante presentaciones, charlas y talleres con el equipo IT. La conclusión de esta actividad fue que todos queríamos cambiar, que no podíamos seguir trabajando como lo estábamos haciendo. Eso era muy bueno. Pero también nos dimos cuenta que si bien todos querían el cambio, nadie quería empujar ese cambio, y esperaban que alguien lo hiciera. Decidimos ser nosotros el motor de ese cambio.
  2. Selección de herramientas que soportaran la metodología. Uno de los problemas detectados en las herramientas que soportaban la metodología actual era la falta de una herramienta que permitiera una trazabilidad end to end desde el requerimiento a la implementación, y el hecho de que dicha herramienta (o el proceso implementado) tenía mucha burocracia y una automatización casi nula. Luego de mucho analizar, decidimos implementar varias herramientas de Atlassian, sumadas a otras para resolver problemáticas puntuales (Grunt, Selenium, Bower, Artifactory)
  3. Organizar y dictar talleres sobre la nueva metodología, para establecer las bases teórico-prácticas. Preparamos y dictamos talleres sobre:
    1. SCRUM
    2. Gestión de requerimientos y planificación ágil (inception, user stories y user story mapping)
    3. Pair Programming, TDD y BDD como prácticas básicas para asegurar calidad y compartir conocimientos.
    4. Demo de la suite de herramientas que soportarán la metodología
    5. Talleres de acompañamiento prácticos para comenzar a trabajar con agile en un proyecto real.
  4. Proponer nuevas maneras de contratación para servicios de desarrollo y testing, de forma tal que se amoldaran a las filosofías agile.
  5. Contar con una consultora especializada en metodologías ágiles para ayudarnos a dar los primeros pasos, y brindar capacitaciones formales sobre agile.
  6. Sumar al área de recursos humanos al cambio cultural, para brindar soporte y acompañarnos con el gran cambio que significa salir de una metodología tradicional e ir a agile.
Este último punto es crucial, ya que es muy necesario ver este tipo de cambios como una modificación de la cultura organizacional, y no como un mero cambio de la forma en que trabaja IT. Hicimos y estamos haciendo un excelente trabajo en conjunto. Una de las tareas que realizó el equipo de gestión de cambio fue un assessment de las personas principalmente impactadas por el cambio, para entender que acciones se debían realizar. En las conclusiones de ese análisis surgió un punto que lamentablemente no me sorprendió, y que tiene mucha relación con como comencé este post. El principal punto de atención no era el miedo (que existía), ni la aversión al cambio (inexistente por suerte). Sino que veían que los gerentes no compartían la visión que comunicábamos y compartíamos con ellos.

Atentos a este warning, disparamos acciones adicionales:
  1. Sumar a los talleres al top management.
  2. Sumar al top management a las capacitaciones formales.
Es necesario que todos estén convencidos y sumados a la filosofía propuesta por agile, para lograr que sea un éxito. Ya que no es solo un cambio en la forma en que programamos, gestionamos requerimientos o analizamos. Es un cambio cultural y organizacional que abarca, también:
  • Como contratamos y gestionamos proveedores
  • Como planificamos un proyecto y medimos su avance
  • Como definimos y manejamos el budget
  • Como tratamos con nuestros clientes (internos y externos).
Podríamos haber hecho las cosas diferentes, seguro, pero estoy convencido que dimos y estamos dando todos los pasos necesarios para lograr trabajar de una manera mas eficiente, que nos permita crear software de calidad, y ser felices trabajando sin luchar contra las burocracias de una gran empresa.

domingo, 15 de junio de 2014

Miedos de estudiar ingeniería en un adolescente

La semana pasada tuve la oportunidad de participar en una actividad que organiza Junior Achievement junto a varias empresas, una de ellas Telecom. Esta actividad, llamada "Socios por un día" busca que adolescentes finalizando la secundaria compartan un día de trabajo con un profesional de la carrera que eligieron. Yo estuve acompañado durante ese día por una chica de un colegio de Flores, a la que pude mostrarle diferentes aspectos del trabajo en IT en la empresa:

  • Una reunión con el top management de IT
  • Ver como trabajan los analistas, desarrolladores y personas de soporte IT
  • Ser parte de una actividad de entrenamiento / cambio cultural que estamos realizando
Ella se fue muy contenta, y yo también. Creo que la convencimos de seguir nuestro camino. Durante el tiempo que compartimos, me fue contando los miedos que le daba la carrera. Me pareció bueno compartir las dudas, y las respuestas que le di, ya que dichas inquietudes deben ser compartidas por varios.

Me da miedo que la carrera sea difícil
Todas las carreras son difíciles, tal vez las ingenierías un poco mas aun, pero ninguna va a ser fácil. Lo que si me imagino que debe ser realmente muy difícil, es estudiar una carrera que no te apasione ni que te haga feliz, solo porque desde afuera pareciera mas simple.
Uno debe buscar seguir una carrera que lo haga feliz. Si se logra eso, todo se hace mas simple.

Me da miedo que no me guste y tenga que abandonar
Uno no sabe como va a terminar una historia antes de empezarla. Así como no sabes como termina un libro antes de leerlo o una película antes de comenzar a verla, no sabes que puede pasar con tu vida personal o profesional. Es algo que se va dando de a poco, con las decisiones que tomas todos los días.
Lo que uno tiene que tener en mente es un objetivo de vida, y hacer que las decisiones que uno vaya tomando te lleven a cumplirlo (o cambiarlo!).
No esta mal cambiar el rumbo mientras se esta andando, si ese cambio te hace ir a algo que te divertirá y gustará mas.

Me gustaría una carrera donde no tenga que exponerme ante gente todo el tiempo
Una de las mejores cosas que tiene trabajar en sistemas es que uno puede virtualmente hacer lo que mas le guste, todo depende de las decisiones que vayas tomando. Podes trabajar en cualquier industria (desde farmacéutica hasta servicios, pasando por empresas de producción) y en diferentes roles, en un abanico que va desde roles con mucha relación interpersonal a roles con mas introspección y trabajo individual. Todos los roles son importantes y necesarios, por lo que podes hacer lo que mas te haga feliz.
Una cosa que es necesario tener en cuenta desde antes de empezar, es que ocupar un puesto gerencial no es el único final de la carrera. Uno puede ser un excelente especialista en alguna o muchas cosas durante toda su carrera, y eso esta buenísimo!

Me gustaría una carrera que me permita trabajar en el exterior
Hoy en día IT es una de las carreras con mayor salida laboral en el exterior. Lo que si, tene en cuenta que hacen falta muchos ingenieros y especialistas IT en Argentina, así que evalúa quedarte!

Me da cosa tener que saber inglés para estudiar sistemas
Si bien no es obligatorio saber inglés para estudiar sistemas o trabajar en IT, es un punto importante. Hoy en día aún mucho conocimiento de la industria se genera y comunica en ese idioma. 
Si no te gusta aprender idiomas, te vas a dar cuenta, con el correr de la carrera, que te va empezando a gustar, mas teniendo en cuenta que queres viajar al exterior!


¿Como empiezo a trabajar en sistemas?
Existen muchísimas posibilidades para empezar a trabajar en sistemas, y esa es la primer decisión que tendrás que tomar en tu carrera.

Podes comenzar trabajando para una consultora de sistemas, como analista, desarrollador o tester trainee, para luego ir avanzando en otras tareas o aspectos. Este es un buen camino para empezar, ya que en general estas empresas ponen foco en capacitar a chicos que recién entran, y asignarles tareas en proyectos grandes en poco tiempo (no voy a hablar de las cuestiones éticas que tiene esta práctica). Te permitirá tener experiencia en un corto plazo.

Podes buscar entrar a una empresa que tenga un área de sistemas y un programa de pasantías. Esto lo podes buscar fácilmente en la facultad. En general son trabajos part-time, lo que te dará tiempo para ir ganando experiencia de a poco, sin dejar de darle dedicación al estudio.

Otra alternativa es, en paralelo con la carrera, hacer un curso corto de programación o sobre alguna tecnología. Esto te permitirá tener trabajos free-lance desde tu casa. No vas a conocer el mundo empresarial de esa manera (cosa que no esta para nada mal, puede ser muy bueno mantenerse alejado de las empresas), pero vas a ganar experiencia en la auto-organización, la negociación  y a defenderte, hecho no menor.

Lo que si, si trabajas, busca la forma de que no perjudique la carrera. Vas a encontrar la tentación de dejar de estudiar porque vas a ganar plata y te va a gustar, pero es pan para hoy y hambre para mañana. Termina la carrera.

¿Cuanto tiempo tengo que estudiar para poder comenzar a trabajar?

En la práctica, podrías trabajar en sistemas sin haber estudiado un día en una universidad. Volve a la pregunta anterior para ver las opciones que tenes.

Mi recomendación  es que al menos estés un año en la carrera antes de comenzar a trabajar. El cambio de la secundaria a la facultad ya es lo suficientemente grande como para romperte todos los esquemas de tu cabeza. Amoldate a la facu, a estudiar de otra manera y, en muchos casos, a viajar todos los días mucho mas que las pocas cuadras que debías recorrer a tu colegio.

Y así, una vez que estés en ritmo con el estudio universitario, ahi si, inicia la carrera del cambio constante buscando trabajo.

Me inquieta no saber como contar a mis conocidos que hago
No creo que ningun trabajo o actividad sea facil de explicar para alguien que conoce poco o nada de la misma u ocupa su vida en tareas diferentes. El problema con IT va un poco mas allá, ya que actualmente todos tienen un sistema al alcance de la mano, ya sea en su mano (un celular) o una PC desde la cual accede a internet.
Por eso, acostumbrate a que, cuando digas que estudias sistemas, te pidan que le configures la impresora, que le arregles el celular o le quites un virus a su PC.
Y lo mas importante, acostumbrate a que. cuando intentes por todos los medios de explicar que es lo que haces, te mires como si estuvieras hablando en chino mandarín. Es asi, es lo mas duro de ser de IT.

domingo, 19 de enero de 2014

Mal entendiendo el manifiesto agil

Hace ya muchos años, en febrero de 2001, 17 referentes de lo que en ese momento se llamaban las metodologías "lightweight" (livianas) se reunieron en un resort (lugar extraño, pero no voy a meterme en ese tema) para acordar los lineamientos de la nueva rama metodológica de IT.

Una de las cosas que hicieron, fue sacar la mote de livianas a la metodología, y llamarlas ágiles. Para mi, ese fue un primer paso para eliminar uno de los primeros malentendidos de dichas metodologías. Llamarlas livianas hacen pensar que son mas fáciles de implementar, o que sirven para proyectos de juguete y no en serio, como las metodologías tradicionales. Por otro lado, llamarlas ágiles demuestra el principal objetivo de esta forma de trabajar: enfocarse en el aprendizaje y adaptación continua, de manera colaborativa con el ambiente.

Luego de horas de charla (y me imagino que también comida y alguna que otra cerveza) definieron 4 guías generales, acompañados de 12 principios, que formaron las bases del crecimiento futuro de las metodologías.

Actualmente, muchos años después, las grandes compañías se atreven a pensar en sumar estas metodologías "novedosas" a sus proyectos. Esto es una buena noticia, pero muchas veces se malentienden los lineamientos o los principios ágiles, lo que lleva al fracaso al corto plazo (en el mejor de los casos), o al largo plazo (lo que se relaciona con mucho tiempo y dinero perdido).

En mi opinión, parte de esos malentendidos se da por la naturaleza humana de buscar siempre el camino mas simple, y no adentrarse demasiado en lo que produce ese camino o en entender completamente lo que se hace. Como dice Douglas McGregor, en su teoría X, el ser humano es vago por naturaleza. No estoy completamente de acuerdo con esto, pero creo que muchas personas (en la lectura del manifiesto ágil se da claramente), paran de investigar o ahondar mas un tema cuando descubren alguna teoría que sirve para fundamentar su pensamiento.

Para explicar mi opinión, primero transcribiré los lineamientos del manifiesto ágil:

  1. Individuos e interacciones sobre procesos y herramientas
  2. Software funcionando sobre documentación extensiva
  3. Colaboración con el cliente sobre negociación contractual
  4. Respuesta ante el cambio sobre seguir un plan 
Luego de los cuales se encuentra la siguiente frase: "Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.". En ningún lado dice que debemos desechar los elementos de la derecha, y solo aplicar los de la izquierda. Pero muchos lo entienden de esa manera, solo porque la parte izquierda puede verse, desde el punto de vista de muchos, como lo único que debe hacerse en un proyecto IT. Y eso no es ágil. Eso es un fracaso.
¿Porque se da esto? Porque los que afirman que son agilistas ya que no documentan, no siguen procesos y no tienen un plan, no siguieron leyendo mas profundamente sobre el manifiesto ágil. 
Debajo de los párrafos anteriormente transcritos, se encuentra un link hacia la explicación de la historia del manifiesto (about the manifest). Seguramente esta página tiene muchas menos lecturas que la principal (tal vez sea un problema para muchos que dichos párrafos sean escritos solo en ingles), y eso explica el fracaso de muchos proyectos mal llamados ágiles. 
Voy a transcribir un párrafo de dicho texto:
"The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.". Y lo voy a traducir por si ese es el problema:
"El movimiento ágil no es anti-metodología. De hecho, muchos de nosotros quieren devolverle credibilidad a la palabra metodología. Queremos volver a tener un equilibrio. Nosotros adherimos al modelado, pero no al hecho de almacenar algún diagrama en un repositorio corporativo. Adherimos a la documentación, pero no a cientos de páginas nunca mantenidas y raramente utilizadas. Planificamos, pero reconocemos los límites de planificar en ambientes cambiantes.".

Creo que si este párrafo estuviera junto a los lineamientos base, los rechazos a las metodologías ágiles serían mucho menores.
Las metodologías ágiles no se tratan de no tener procesos ni herramientas, sino de tener los que ayuden a los individuos y sus interacciones a ser mas fluidas, eficientes y eficaces. O sea, que ayuden a hacer lo correcto en el menor tiempo posible.
Las metodologías ágiles no se tratan de no tener documentación, sino de documentar lo relevante para comprender el código, que el mismo sea mantenible a futuro y que este siempre actualizada, para ser útil.
Las metodologías ágiles no se tratan de no tener un contrato con el cliente. Se debe tener la visión del cliente para poder tener un proyecto exitoso desde el principio, pero dicha visión no debe usarse como el mantra del proyecto, que nunca puede ser modificado. El alcance, los requerimientos y las necesidades van a cambiar durante el proyecto, debemos aceptarlo y no rechazarlo mediante un contrato y control de cambios.
Por último, usando metodologías ágiles, se planifica, y de una manera mucho mas eficiente que las metodologías tradicionales. Se planifica de a poco, haciendo que cada paso sea seguro. Preguntale sino a un project manager tradicional, cuando va a terminar. Si es sincero, te va a decir que no sabe. Lo mismo pasará con un Product Owner o un Scrum master, por ejemplo, pero luego de tres iteraciones se irá animando a brindar alguna visibilidad mas certera. 

Y seguro, en el segundo caso el plan será mas cierto y fácil de seguir.




domingo, 12 de enero de 2014

Por que leer Lean Startup, de Eric Ries


Hace unos días termine de leer el libro "Lean Startup" de Eric Ries. Es un libro que busca transmitir una filosofía de management no tradicional, basada en los aprendizajes de metodologías de origen japones como Lean y Just In Time.
No es un libro para que lean solo aquellos que quieran comenzar su propia empresa - o startup, sino que lo primero que hace es hacer entender que todos somos emprendedores, ya sea iniciando nuestro propio emprendimiento independiente, o trabajando en una gran empresa multinacional.
Es un libro realmente muy interesante, que no se queda solo con la teoría, sino que muestra como llevarlas a la práctica y nos deja algunos casos donde su implantación fue un éxito.
En los próximos párrafos, voy a transmitir algunos de los conceptos que, segun mi opinión, son los mas importantes, y por los cuales recomiendo invertir el tiempo en leerlos del propio autor.
En primer lugar, los 5 principios de Lean Startup:

  1. Los emprendedores están en todos lados. O sea, no importa que trabajemos por nuestra cuenta o en una multinacional, todos los que trabajamos para crear nuevos productos y servicios somos emprendedores.
  2. El entrepreneurship es management. El "emprendedorismo" es una nueva disciplina, que debe existir en toda compañía.
  3. Aprendizaje validado. Las startups existen para aprender como generar un negocio sustentable. Esto se logra realizando experimentos, midiendo y aprendiendo.
  4. Build-Measure-Learn (Hacer-Medir-Aprender). Este es el ciclo de aprendizaje continuo que se debe llevar adelante, para realmente esforzarse en el producto indicado.
  5. Contabilidad de la innovación. No nos debemos olvidar de demostrar el progreso, priorizar y gestionar nuestros esfuerzos en la innovación.
Un punto que me pareció muy importante - y que es parte del core del libro, viene del principio 4 y 3. Lo mas importante es aprender, no importa si lo que produzcamos tiene éxito o no en el mercado al que apuntamos. Debemos "perdonar el error la primera vez, y asegurarnos de que no vuelva a suceder". Esto se logra realizando un MVP - Minimun Viable Product, creado en base a hipótesis iniciales, el cual nos permita - mediante mediciones de valor- validar dichas hipotesis, y nos brinde información para seguir en el camino planteado, o cambiar la ruta hacia un nuevo obejtivo, manteniendo la visión mientras sea necesario. Esta forma de trabajar asegura que vamos a usar nuestra capacidad - muchas veces escasa - en desarrollar el producto que realmente se requiere.

Nombre en el párrafo anterior que, para crear un MVP - el cual debe servir para validar lo que queremos, y tiene que ser lo mas simple posible-, es necesario tener hipótesis que el mismo siga. Estas hipótesis marcan como el producto se supone que creará valor, y como irá creciendo una vez establecido. Debemos tener claro estos dos puntos, y establecer una manera clara de medir la innovación y el aprendizaje generado mediante métricas base asociadas a cada hipótesis o assumption, que permita demostrar claramente y de manera no ambigua como se crea valor, y como se va creciendo. Si las métricas están bien definidas (y no son vanity metrics-enfocadas en un aspecto parcial del problema), nos va a permitir establecer cuando perseverar, o cuando cambiar el rumbo.

Debemos definir bien las métricas asociadas a nuestras hipotesis, teniendo en cuenta la regla de las tres A, para que las mismas sean:
  • Accionables. O sea, que deben demostrar claramente una causa y efecto.
  • Accesibles. Los datos deben ser accedidos por todos los involucrados en el producto, de la manera mas simple posible.
  • Auditables. Se debe poder tracear la información que generó las métricas, para defender cuando decimos que el proyecto va bien, o va mal y debemos cambiar el rumbo.
Volviendo a que el MVP sea lo mas simple posible. Es importante asegurarnos que vayamos avanzando en el desarrollo deproducto de a pasos cortos (small batches), que produzcan iteraciones de creación-medición-aprendizaje. Por eso, debemos ir planificando mejoras pequeñas, pero medibles y que nos permitan aprender y definir los siguientes pasos.

Algunas otras prácticas o herramientas que me parecieron interesantes:
  • Enfocarnos en tener un MVP simple, y validarlo con usuarios finales, en un ambiente real, aunque cuidado. Lo mas adecuado es realizar estas validaciones midiéndolas por poblaciones de usuarios (cohortes), lo que nos permitirá tener una visión mas acabada de nuestra situación.
  • Tener al aprendizaje sobre nuestro producto como primer objetivo, y dejar para una segunda instancia la optimización. Para un ingeniero o diseñador este punto es muy difícil, pero es vital mantenerlo en práctica.
  • Realizar pruebas de diferentes versiones de productos a diferentes poblaciones, comparando las métricas entre los diferentes grupos de clientes. Pueden ser mediante tests A/B, pruebas green-blue servers, etc.
  • Técnicas como continuous integration y continuous deployment permiten acelerar el ciclo de creación-medición-aprendizaje, mediante la automatización, que lleva a la eliminación de desperdicios (tiempos muertos), y el foco en esforzarse para crear valor en lugar de realizar tareas repetitivas.
  • KANBAN nos permite tener siempre visible la capacidad de nuestros equipos, y el flujo de actividades, haciendo mas simple encontrar puntos de mejora y aumentar la productividad general.
  • Debemos generar una organización adaptativa, que evolucione constantemente y no se quede congelada. Una herramienta para lograr esto, es ejecutar el ciclo de "5 porque" (five whys) cuando nos encontramos con un problema, para llegar a la raiz del mismo. Muchas veces, un problema que parece técnico - solución simple y superficial, en realidad esta dada por un problema sistémico y asociado a personas.
Esto fue solo un resumen de lo que a mi me parece mas importante del libro, pero es muy recomendable meterse a lleno, leerlo e implementar sus prácticas (Algo que voy a hacer, y luego comentar mis aprendizajes).


jueves, 2 de enero de 2014

Frases desmotivantes que se mal usan para motivar

Hoy tuvimos un almuerzo muy interesante con el equipo, esos donde se dan charlas al mediodía que muchos logran solo que sucedan a la noche, e incentivados por algunas sustancias prohibidas o no tanto. Pero no, estábamos sobrios, despiertos y con ganas de filosofar.

Entre tantos temas, surgió uno muy interesante: ¿que frases escuchamos, nos contaron o se ocurren que puede decir un lider, queriendo motivar, pero que logra totalmente lo contrario? A continuación, el compendio resultante, que se va a traducir en un "cubo de des-motivación":


  1. "Recorda: sos prescindible". Esta frase es terrible. Logra desmotivar hasta la persona mas motivada de un equipo. No tiene costado positivo alguno.
  2. "Es bueno tener actualizado tu perfil de linkedin". Tal vez esta frase halla sido utilizada con un lado positivo, el de enfrentar una posible futura crisis estando preparados, sin que nos agarre desprevenidos. Pero muchos (me incluyo) lo pueden tomar para el otro lado: Somos prescindibles
  3. "Si se puede mejorar, aun no lo terminaste". Horrible mensaje. Buscar la perfección a todo costo nunca puede llevar a nada bueno. Desgasta el equipo y no se logra ningún objetivo. 
  4. "Quedate trabajando... nadie te espera". Puff, malisima desde la primera a la última letra. No imagino una persona que pueda verse líder dando mensajes de este estilo.
  5. "No se puede ser el mejor en todo, y menos en lo que haces". No solo te insultan y te tratan de inutil, sino que dicen que lo que haces no tiene sentido. Aunque hay que ser sincero, saca presión ;).
  6. "¿Lindas las vacaciones? Ahora a trabajar, te faltan 350 días para las próximas". Esto puede ser un muy mal chiste de bienvenida de vacaciones, pero puede generar un pico de presión (y depresión) post-vacaciones que origina un espiral de malos augurios.
Actualización 3/1/14: Algunos agregados que me fueron pasando:
7. "No dejes para mañana lo que podes hacer hoy, posiblemente mañana no haga falta, o no estes para hacerlo". Esta pega bajo, muy bajo.
8. "Descansa en las vacaciones, te espera un año bien cargadito". Esta no solo no motiva, sino que te caga las vacaciones.

Seguramente existirán muchas mas, muy malas, tal vez sin mala intensión, pero muy hirientes y contraproducentes.

Seamos cautos con la comunicación, es lo mas importante.

PD: Gracias al equipo por los aportes!

lunes, 25 de noviembre de 2013

De que hablamos cuando hablamos de DevOps

Como todo nuevo término de la industria IT, DevOps tiene muchas implicancias y significados, dependiendo de los intereses, historia y conocimientos de quienes lo definan, y a quienes lo comuniquen.

Muchos pueden pensar a DevOps como una serie de herramientas para cambiar la forma de gestionar la operación de los sistemas y su relación con las áreas de desarrollo, mientras otros pueden definirlo como una serie de prácticas para extender las prácticas de desarrollo ágiles (SCRUM, KANBAN) hacia las áreas de operaciones. Otros, los escépticos, pueden decir que son un montón de gente loca intentando cambiar el mundo, y que obviamente fracasaran porque lo que funciona en este mundo es la previsibilidad, monitoreo y gestión de prácticas tradicionales como ITIL, y que lo propuesto por DevOps lo único que traerá es mas caos. Por último, están quienes creen que es un nuevo área de la organización IT que viene a salvarnos de todos nuestros problemas (estos últimos para mi son los mas errados).

Para mi, no es ninguna de todas las definiciones anteriores, y al mismo tiempo todas. Me gusta definir a DevOps basándome en un paper de Mandi Walls (Building a DevOps Culture), como un  movimiento cultural combinado con una serie de prácticas de desarrollo de software soportadas por herramientas que juntas habilitan a un desarrollo mas rápido (o a fallar mas rápido mas seguido). Por lo que es muy importante tener en cuenta que implementar un cambio a un nivel que mejore nuestra capacidad de entregar software de calidad mas seguido no es algo que pueda ser realizado de un día para el otro, y requiere su tiempo de maduración y soporte de la organización completa (o al menos aquellas áreas impactadas).

DevOps no es algo nuevo (Patrick Debois acuñó el término en 2009, mientras organizaba la primer DevOps conference en Bélgica), sino que es un muy buen blend entre prácticas maduras con enfoques novedosos para enfrentar desafíos comunes en la entrega y operación de soluciones de software. Mezcla la visión de desarrollo (no solo los desarrolladores, sino también testers y QA) y operaciones (incluyendo no solo a los operadores, sino también a administradores de sistemas, DBA), poniendo foco en la colaboración y feedback constante para soportar la mejora contínua de la forma de trabajo.

Según cuenta Michael Hüttermann en su libro DevOps for Developers, DevOps abarca numerosas actividades y aspectos:

  • Cultura: Las personas son mas importantes que los procesos y herramientas. Hay que tener siempre en cuenta que el software es hecho por personas y para personas. Debemos buscar la forma de ser felices haciéndolo, y hacer felices a los que obtienen el resultado de nuestro trabajo.
  • Automatización: Es esencial obtener feedback rápido y minimizar los errores en tareas repetitivas.
  • Medición: Se debe encontrar una forma única de medir, acompañado por incentivos de calidad y compartidos (o al menos alineados).
  • Compartir: Es imprescindible crear una cultura en la que las personas compartan ideas, procesos y herramientas.
Hablamos entonces de cambiar la cultura de dos áreas históricamente enfrentadas (desarrolladores vs operadores) para que se vean como un único equipo (con objetivos alineados), compartiendo información y apoyados en la medición continua y automatización de tareas que no aportan valor para mejorar el día a día de su trabajo, y paso a paso, como diría el Tolo Gallego.

¿Como podemos entonces emprender este cambio cultural para poder trabajar mejor? Debemos enfocarnos en generar una nueva cultura, con base en los siguientes pilares:
  • Comunicación abierta, donde nadie tenga miedo a participar y decir su opinión, y donde la decisiones sean tomadas de manera global, con responsabilidad compartida entre todos. Basta de ocultar información para sacarse de encima problemas.
  • Incentivos alineados, tal como lo comenta Michael Hütterman y tal como lo nombré en párrafos anteriores.
  • Responsabilidad alineada. Debe quedar en claro que la responsabilidad de un área no termina cuando culminó su porción de tarea y la pasó la pelota al siguiente pipe en el pipeline de desarrollo. La responsabilidad de todos los involucrados termina cuando se alcanzó el nivel de aceptación acordado entre TODOS.
  • Respeto. Todos deben respetarse. Puede ser que no se quieran (ya eso va de la mano de los sentimientos de cada uno), pero es vital que cada uno reconozca el valor del otro en el pipeline completo.
  • Confianza. Esto si es realmente desafiante. Los desarrolladores deben confiar en que lo que los encargados de operaciones les indican sobre el funcionamiento en producción, y estos últimos deben confiar en que lo que desarrollo produce es lo mejor dadas las circunstancias, y trabajar en conjunto para llegar a los objetivos planteados en conjunto.
Tenemos que tener en cuenta que algo es seguro: No es posible refactorizar una persona o resetearla tal como lo podemos hacer con las aplicaciones o los servidores. Se trata de un cambio interno de las personas, y debemos encontrar la forma de trabajar con los pre-conceptos, experiencias pasadas y prejuicios, para transformar la energía negativa actual en el combustible del cambio.

domingo, 4 de marzo de 2012

Creando infografías

Por cuestiones que no vienen al caso, tuve que pensar en como comunicar gráficamente muchos datos, métricas e indicadores, para que un auditorio no técnico comprenda claramente lo que se quería comunicar.

Esa tarea era algo desconocido para mi, ya que me gusta ver y analizar infografías, pero nunca puse a pensar como comunicar muchos datos de manera simple. Fué un gran desafío para mi.
En primer lugar pensé cuales eran las variables que quería mostrar (las cuales eran muchas), y luego vino la parte mas creativa, pensar como acomodar la información y luego la parte mas práctica, como llevarlo a una imagen.

Con respecto a como acomodar la información, caí en la cuenta de que lo que quería mostrar era la relación entre elementos (nodos), e indicar de alguna manera gráfica el peso que tenía esa relación entre los mismos. Además, debía indicar algunas otras métricas relacionadas a cada nodo. Por lo que decidí acomodar los nodos y sus relaciones como grafos, y que las relaciones mostraran con el grosor el peso que tenían. Para llegar a esto no fue que me dormi y al levantarme se me había ocurrido, sino que sumé mi lectura asidua de infografías a la búsqueda activa en http://vi.sualize.us. Es muy bueno para buscar inspiración (creo fervientemente que la creatividad no es mas que acomodar de otra manera ideas existentes).

Para terminar, la parte práctica la llevé a cabo con la herramienta de diseño open source Inkscape (descargable de http://inkscape.org). Después de probar varias alternativas open source al Photoshop y Corel Draw, me quedé con esta, por la cantidad de posibilidades que brinda, y la versatilidad de uso que tiene. Realmente es muy buena. La única contra, es que solo permite exportar a png, pero no es algo que me moleste demasiado.

En conclusión, tuve un día en que me puse el gorro de diseñador gráfico y realmente la pase bastante bien.

jueves, 9 de febrero de 2012

NLTK - Bitácora - La instalación

Gratamente motivado por un proyecto que estoy encarando, estoy aprendiendo NLTK (Natural Language Toolkit), una serie de herramientas de Python enfocadas en el procesamiento informático del lenguaje natural, siendo este el lenguaje que utilizamos los humanos para comunicarnos.
¿Para que me sirve procesar el lenguaje natural utilizado por los humanos? En el extremo simple, para contar la cantidad de veces que se repite una palabra o frase. En el extremo mas complejo, para lograr una comprensión de lo que se quiere transmitir con una porción de texto, y lograr conclusiones o acciones sobre dicha comprensión.
Sin meterme demasiado mas sobre la explicación del procesamiento del lenguaje natural (haré un post cuando tenga una comprensión mayor del tema), paso a comentar los pasos que hice hasta ahora.
Instalé las librerías y herramientas necesarias para poder trabajar con NLTK. Seguí las instrucciones de la documentación pública del toolkit (http://www.nltk.org/download), por lo que el primer paso, la instalación, fue dado.
Ahora, solo resta ponerse a aprender en base a ejemplos, para ir haciendo cosas mas complejas a futuro.

domingo, 8 de enero de 2012

¿Cual es el tamaño ideal de un equipo de arquitectura empresarial?

Según estuve leyendo en Gartner, establecen que según sus investigaciones el tamaño ideal de un equipo de arquitectura empresarial va inicialmente entre un 2% y un 4% del número total de personas que forman parte del área de IT de una empresa. No me cierra de esa frase que supone que Enterprise Architecture es solo IT, cuando tiene una gran relación con la tecnología, eso es cierto, pero también tiene mucho de estrategia y conocimiento del negocio.
No creo que se pueda establecer una relación tan clara y fuerte entre el tamaño de un equipo de EA y el área de IT, en primer lugar por lo antedicho, y en segunda instancia porque es necesario tener en cuenta muchas variables que son propias de cada organización, entre las que se me ocurren:
  • El alcance que el área de EA tiene en la organización, ya que no es lo mismo un área que solo se encargue de definir la estrategia de la arquitectura aplicativa, que aquella que tenga dentro de sus funciones la definición de la estrategia de negocio, la arquitectura tecnológica y aplicativa y la definición de tendencias del mercado.
  • El nivel de madurez de la organización, ya que si la organización ejerce una planificación estratégica ordenada, se requiere menos esfuerzo de arquitectura para llevarla adelante.
  • El presupuesto alocado por la organización para las iniciativas de arquitectura hará crecer o decrecer la cantidad de personas que formen el grupo de EA.
  • La madurez en la gestión de los proyectos, y la facilidad para hacer que cada proyecto tenga dependencia de las definiciones de EA definirá el nivel de esfuerzo requerido, y por ende la carga de trabajo que hará aumentar o decrecer al equipo.
Es necesario tener en cuenta muchas cuestiones para definir el tamaño del equipo, y no creo que exista una receta para definirlo. Pero creo que un buen comienzo es la definición de las actividades que realizará el equipo de arquitectura, los entregables que brindará y el nivel de servicio que se espera dar al resto de la organización. En base a esto, sumado a la cantidad de proyectos en ejecución y planificados y el nivel de participación, la tarea de definir el tamaño y capacidad de un equipo de arquitectura no es muy distante a la definición de un equipo para un proyecto cualquiera.

Organización de un equipo de EA

Una buena manera de establecer la organización de un equipo de arquitectura empresarial es tener en cuenta las funciones que debe cumplir el área, el valor que dicha función le brindará a la empresa, y la relación con los procesos de la empresa (como el ciclo de vida de desarrollo o el proceso de planificación estratégica).
Según lo veo, las funciones que cumple un área de arquitectura empresarial se pueden resumir en las siguientes:
  • Definición, que cubre la creación y establecimiento de políticas, estándares y guías base, que son el entregable para ordenar la estrategia de arquitectura de los diferentes proyectos de la organización.
  • Control, asegurando que los proyectos cumplan las políticas, estándares y guías base, y detectando la necesidad de cambio de dichos entregables definidos (ya que los mismos deben evolucionar y no quedar estancos). Esta función debe entregar un reporte del cumplimiento, excepciones o evoluciones necesarias.
  • Acompañamiento de los diferentes proyectos, cumpliendo la función de consultor en cualquier etapa de los proyectos IT, y guiando sobre el cumplimiento de las políticas, estándares y guias base establecidas. Obtiene también información de los proyectos como retroalimentación al repositorio de información de arquitectura y a la planificación arquitectural. No solo se participa como un consultor que aporta conocimientos técnicos, sino también de estrategia y de negocio.
  • Transferencia de conocimiento a todos los stakeholders de la organización o a quien requiera contar con los conocimientos generados por el área de arquitectura. Estos conocimientos no solo están relacionados a lo definido por la función de definición, sino también a lo que al área de EA conozca por su participación en todos los proyectos o la investigación sobre tendencias.
  • Investigación, que es una función mas que importante, ya que sienta las bases de los conocimientos necesarios para permitir una evolución constante de la arquitectura para brindar siempre el valor requerido.
  • Velar por que los activos generados por arquitectura (relacionados a arquitectura aplicativa, arquitectura de datos, arquitectura técnica, etc.) se encuentren actualizados y sirvan para la función que fueron creados, representar el cúmulo de información necesario para conocer el estado actual y establecer el estado futuro de la arquitectura.
Luego, es necesario mapear cada una de estas funciones a los procesos organizacionales, determinando claramente el valor que la función de EA le brindará a la o las etapas relacionadas. De esa forma, se comunicará claramente a los stakeholders el valor brindado (también es importante encontrar la forma de medir el retorno y el valor generado).
Teniendo estas funciones como base y el mapeo con los procesos organizacionales, se cuenta con una base para planificar la organización del equipo, establecer la cantidad de personas que deben formar el equipo de arquitectura, y comunicarlo a las personas adecuadas para la ejecución del plan de EA.