Agilidad es Cambio Cultural

Día a día refuerzo la creencia de que lo que denominamos agilidad, no es más que una evolución en como nos organizamos, conectamos y relacionamos, en resumen: en cómo vemos, interpretamos e interactuamos con el mundo a nuestro alrededor. Es un tema mucho más de fondo que de forma.

Es un cambio cultural. Punto.

No tiene mucho que ver con adoptar nuevas herramientas o prácticas. Pueden ayudarnos un poco en el sentido que algunas prácticas vehiculizan o habilitan algunos cambios. Pero el cambio profundo es de perspectiva, de paradigma.

Pensar redes en lugar de jerarquías, cambiar la rigidez por la adaptación, el control por el empoderamiento, abrirnos a los demás, transparentarnos para poder dar y recibir lo mejor en un círculo virtuoso.

Lo que hace varios años era un desafío al status quo, actualmente se convirtió en un standard, con los beneficios y lo distorsiones que eso conlleva. Una serie de commodities que nos achatan y nos obligan a pensar como salir.

Siempre van a existir nuevos conceptos, metodologías, frameworks, y maneras de hacer las cosas: Scrum, Kaban, Design Thinking, SAFe, LeSS, SPRINT, etc. El desafío es saber entender el espíritu de las cosas, y cómo generan más valor.

Me gustaría desde este humilde lugar desafiarnos a encontrar todos los días el siguiente paso, la próxima evolución, incomodarnos nuevamente. De alguna manera lograr establecer la cultura de estar al filo de la comodidad, en un viaje eterno dentro y fuera de la zona de confort.

Como todo proceso de cambio, lo primero que hay que encontrar no son grandes respuestas si no las preguntas adecuadas.

Mantengámonos atentos, curiosos, abiertos y transparentes. No nos va a garantizar ninguna revolución, pero nos va a acercar a sentir día a día la sensación de siempre querer ir por más. Y ese es el comienzo.

[edit]
Pueden leer la versión en inglés aquí.

Experiencias con Equipos de Desarrollo

Una Primera Reflexión

A veces me cuesta encontrar temas para escribir, no creo que la razón sea que no tenga nada interesante para contar (eso espero), si no que enfoco el hecho desde un punto de vista equivocado.

En muchos casos busco los temas afuera, cuando en realidad los tengo que buscar adentro. Dicho de otra manera: debo escribir acerca de lo que más conozco, mi área de expertise. Allí donde la experiencia de los años de trabajo me nutre de material valioso. En lugar de ir a buscar el tema “hot”, y desarrollar mi punto de vista sobre ese particular tópico. Gran consejo de Martín Salías.

Entonces, con esto en mente, me gustaría poder compartir algunas experiencias, intentando focalizarme en analizar buenas prácticas, tips, sin querer dogmatizar, dando mi punto de vista, yendo a las fuentes y aprendiendo en el camino. Veamos que sale 🙂

En este caso el contexto está dado en un trabajo anterior, oficiando de Arquitecto de software, dentro del área de desarrollo de una empresa de producto. Estaba a cargo de liderar las decisiones técnicas, hacer coaching de los equipos y del proceso de desarrollo en su totalidad, incluída la elección de herramientas que lo soportaban, entre otras cosas.

En el área estábamos a cargo del desarrollo, evolución y soporte de varios productos con base en internet. Para lo cual existían pequeños equipos de developers, diseñadores, analistas y testers, asignados a cada producto.

Hoy me quiero focalizar en el proceso de desarrollo. El cual, nobleza obliga, ya estaba siendo desplegado en parte en el momento en el que yo me incorporé al equipo.
Para esto, me gustaría usar algunos disparadores, los cuales van a ser útiles para describir puntos claves del modelo y las prácticas que utilizábamos. Algunos de ellos relativos a prácticas más duras, ingenieriles, y otras más blandas, culturales y de gestión.

Scrum / Kanban

Dependiendo del contexto del producto, se trabajaba con uno u otro. En el caso de tener mayor previsibilidad, donde podíamos armar iteraciones con time-boxing de dos semanas, usabamos scrum. Teníamos nuestro backlog general, del cual un subconjunto del mismo era priorizado como resultado de una planning en conjunto con el equipo de negocio.
Tomando el caso de un producto más dinámico, donde usabamos A/B testing para validar nuestras hipótesis, recurrimos al uso de kanban como soporte de nuestro trabajo. La idea era permitir al negocio manejar las prioridades de una manera más flexible, sin tener impacto en replanificación. Pudiéndo así, enfocarnos en acelerar el flujo de trabajo, eliminando pasos innecesarios (waste) para entregar valor lo antes posible.

Colaborative (Software) Design

Al salir de la reunión de sprint planning, nos comprometíamos a un nuevo (sprint) backlog. Seguido a esta reunión, hacíamos una planificación técnica, en donde el equipo de desarrolladores y arquitecto nos juntabamos para explotar cada user story. Allí se discutían aspectos técnicos de implementación, dándole lugar a todos los integrantes del equipo a dar su punto de vista. Eran en algunos casos un par de horas en el pizarrón, donde se acordaba un diseño de alto nivel para implementar las stories priorizadas por el usuario. Aquí la palabra clave es acuerdo, dado que hacer esta reunión tenía varios impactos positivos: crear consenso en el equipo, lograr mayor compromiso en cada uno de los integrantes con los objetivos de la iteración, obtener feedback del equipo que eventualmente mejore la implementación del requerimiento, incrementar el aporte e interacción de los integrantes generando cohesión en el equipo.
Las fotos de las pizarras funcionaban como documentación del diseño, para futura referencia.

Repositorios / Políticas de Branching

Pasando a temas más técnicos, se puede mencionar que versionábamos nuestro código fuente con git. En este contexto, realizamos una migración de todo el código de nuestros productos a gitlab, lo cual resultó un acierto muy importante. Gitlab, ofrece varias características muy al estilo github, donde podemos navegar nuestro código a través de una interfaz web, la cual dispone de un dashboard, para el manejo de usuarios, grupos, permisos, etc. Se puede ver la actividad de los equipos directamente desde este dashboard, entre otras cosas que voy a nombrar más adelante y en futuros posts.
Usabamos el patrón featureBranch, por lo cual, creabamos una nueva rama para cada nuevo feature significativo que debíamos entregar, por el cual nos asegurabamos de poder trabajar de manera simultánea en varios features y no pisarnos en caso de hacer pruebas. Adicionalmente teníamos los branchs fijos: release candidate y master, donde versionabamos las versiones de testing / staging y de producción respectivamente, creando tags por cada nuevo release.

Peer Review

Otra de las prácticas que nos habilitó el uso de gitlab, es la posibilidad de hacer revisiones de a pares de los commits realizados. Un desarrollador, al terminar de implementar un feature, puede pedir una revisión a otro a través de la plataforma (implementada a través de pull requests). La cual centra toda la interacción, idas y vueltas, comentarios y correcciones en la herramienta.
Esta práctica tiene múltiples beneficios: se mejora la calidad integral del código fuente, dado que cada feature implementada es revisada por algún integrante del equipo. Se gana en conocimiento del código, dado que los developers no sólo leen su propio código, si no que de alguna manera están “forzados” a leer código de otros. Esto mejora la implementación de estándares, y colabora a crear lo que en términos de XP sería collective ownership, concepto que enfatiza la responsabilidad de todos los integrantes como dueños y aportantes a lo largo y ancho del código fuente.

Integración Contínua

Cada commit en el repositorio git, generaba una integración de todo el código fuente. Esto se implementaba con un servidor de CI jenkins alojado en nuestro datacenter, que estaba configurado para tal motivo. Esta corrida incluía un chequeo de la calidad del código fuente, tomando como base estándares de la comunidad. Así como se corrían los tests unitarios y se generaban los resultados de cobertura de código (code coverage).
Por las noches se corrían builds que contenían diferentes tipos de tests, generando reportes que se analizaban al otro día por la mañana. Tema que se detalla a continuación.

Test Automation

Para cada iteración se preparaban los casos de prueba manuales, y a su vez se identificaban los casos de prueba automatizados. Este trabajo se hacía desde el inicio de la iteración, dado que los casos de prueba servían de input a los desarrolladores para validar si la feature cumplía o no con el resultado esperado.
En el caso de los tests automatizados, utilizabamos Selenium, junto con un framework desarrollado internamente para facilitar la sintáxis. Los casos de test se guardaban en el repositorio junto al código fuente y se ejecutaban tanto manualmente como en trabajos programados de manera noctura, como se suele hacer habitualmente para minimizar el impacto en la performance en la infraestructura, dado su (largo) tiempo de ejecución.

Conclusión

Se enumeraron sólo algunos de los puntos salientes del proceso y prácticas de desarrollo que utilizabamos.
En resumen, intentamos elegir la mejor manera de trabajar en equipo, focalizados en agregar valor al negocio. Sin apegarnos a ningún marco de trabajo preestablecido, si no que adoptando y adaptando tanto metodologías ágiles de gestión, cambios culturales —más agilismo todavía 🙂 —, como prácticas de ingeniería conocidas y probadas para armar nuestro propio combo de trabajo.

Quedaron afuera varios temas importantes que hacían al core de nuestro trabajo, por ejemplo:

  • Versionado de releases
  • Validación & versionado de schemas de base de datos
  • Manejo de dependencias
  • Generación de entornos de desarrollo automatizada

Estos tópicos los podemos dejar para la próxima, allí nos vemos 🙂

 

Paremos de sobreestimar el Liderazgo

El título puede sonar controversial, hasta desafiante, pero es algo que da vueltas en mi cabeza desde hace tiempo. Quizás haga falta desarrollarlo un poco para darle el sentido completo al concepto.

Estoy cansado del protagonismo del liderazgo como motor del crecimiento, los cambios y el cumplimiento de los objetivos organizacionales. De los 10 tips para ser un buen líder, del líder silencioso, el colaborativo, el autoritario, coaching, las diferencias entre un jefe y un líder, y una larga lista de etcéteras.
Estoy de acuerdo con que deban existir líderes capaces de guíar, mostrar el camino, inspirar, motivar, hacer del camino a los objetivos algo tan disfrutable y desafiante como el mismo fin del camino, pero creo que el mundo no termina ahí. O al menos deberíamos equilibrar la balanza un poco más hacia otro lado.

¿Dónde están los artículos que enumeren los tips para ser un buen integrante de equipo?
Para dar un ejemplo puedo citar los roles de Scrum, así como encontramos al Product Owner, el Scrum Master, también hay uno que se llama Team. Démosle más importancia a esto, seamos conscientes del concepto de autogestión y llevémoslo a la realidad cotidiana.

Ahora, insto a los integrantes de equipos a tomar protagonismo, a hacernos algunas preguntas:

  • ¿Quién realmente está al mando?
  • ¿Cuánto incido en la realidad de mi entorno?
    • ¿Poco? ¿Mucho?
    • ¿No tanto como quisiera?
      • Ok. Qué puedo hacer para involucrarme aún más y ser yo quien me cumpla un rol de liderazgo desde algún aspecto en particular, sin una etiqueta.

Cambiemos el foco de: “Qué seria de nosotros sin un buen líder”, a “Qué sería de un líder sin nosotros“.

No voy a ser tan tonto de ignorar los beneficios que aporta un liderazgo positivo en un equipo u organización, el efecto multiplicador de un líder que genera más líderes. Pero para eso, ya existe mucho material de referencia en google 🙂

¿Dev vs Ops?

En esta oportunidad me gustaría detenerme en un tema conocido por los que alguna vez tuvimos que poner software en producción: El eterno dilema entre desarrolladores y IT.

Quién de nosotros no tiene una (o varias) historias relacionadas con la interacción con el área operativa, soporte de ambientes, caídas de servidores, redes, etc. En un principio parecen dos mundos que tienen objetivos contrapuestos:

  • Los desarrolladores, evolucionar el producto. Ya sea con nuevas funcionalidades o mejoras.
  • Los profesionales de IT, mantenerlo estable y rápido

Pero en los tiempos que corren, y especialmente gracias al advenimiento de las metodologías ágiles; las prácticas de entrega continua, los roles se empiezan a entrecruzar cada vez más. Así es como ambos comienzan a intervenir en procesos más integrales, donde ambos se alinean para satisfacer las necesidades del negocio.
Configurar y hacer troubleshooting de servidores de integración continua, automatizar deployments o procesos de testing, generar métricas de código, cobertura de test unitario, con herramientas como: Maven, TeamCity, Jenkings, Chef, etc.
Otra de las tendencias que ayudó a dicha evolución en los roles, es el crecimiento y mayor adopción de las plataformas de cloud computing, como Windows Azure, AWS, etc. Ahora no es un asunto exclusivo de IT administrar las plataformas o  ambientes donde corren nuestras aplicaciones. Se comparten mucho más los roles, y sobre todo el conocimiento, que es lo que nos hace abrir la cabeza y así ponernos un poco en el lugar del otro.

A continuación me gustaría mostrar un video de una charla dictada en el año 2009 (!!). He aquí el nacimiento del término DevOps. Durante la O’Really Velocity Conference, dos expositores mostrando las diferencias entre los dos mundos. Uno de ellos del bando de los desarrolladores, el otro en las filas de IT. No tardan mucho para empezar a remarcar cuántos aspectos son los que los unen para llegar a cumplir los objetivos de las organizaciones.

http://blip.tv/oreilly-velocity-conference/velocity-09-john-allspaw-10-deploys-per-day-dev-and-ops-cooperation-at-flickr-2297883

También me gustaría compartir un sitio donde se habla mucho de este nuevo rol DevOps, brindando buenas prácticas, información de eventos, etc. El título lo dice todo: DevOps.com “Helping finishing what agile development started.” Chapéu!

Así que ya saben, la próxima vez que necesiten un ambiente de QA, o levantar un ticket por un error del ambiente de desarrollo, compartan este link con nuestro amigo de IT. Mejor trabajar juntos.

Call to Action

Hacía rato que una charla no me hacía llegar el mensaje de una manera tan clara como ésta, con la fuerza y la tensiones adecuadas.

Bred Victor – The Future of Programming

No estoy tratando de declamar o vanagloriar el contenido de la exposición, no se trata de eso. Se trata de el método que se utiliza, gracias a ciertos recursos como la analogía y la provocación, se logra llegar a un clima final en el que el autor puede dar un mensaje con el público más cerca. El recorrido labrado en conceptos conocidos por todos (los programadores), empatiza con los espectadores.

Está claro que existe mucho de provocación en las palabras y hay mucho tiros por elevación dentro de la retórica. Enaltece al público, no lo subestima.

Más allá de todo, comparto mucho el mensaje final 🙂

PD: Con ésta charla de TED me pasó algo similar: Why work doesn’t happen at work. El orador utiliza la exageración y provocación para enviar un mensaje claro.

Sobre Microsoft y la Comunidad de Desarrolladores

Esta vez retorno al blog escribiendo sobre un tema que me viene dando vueltas en la cabeza desde hace tiempo. Vale la pena aclarar que no es un tema nuevo para los que estamos involucrados en el desarrollo de software, sobre todo con herramientas Microsoft.

Una de las críticas más grandes que se le hace a Microsoft con respecto a su política relacionada a sus productos y cómo se relacionan con la comunidad, es la cantidad de tiempo que se toman entre releases. Lo que dificulta el feedback con los usuarios, que deben esperar mucho tiempo para ver los cambios esperados en los productos, frameworks, etc.

No es una noticia nueva, pero que cada día se viene ahondando aún más, que Microsoft está cambiando este mindset a uno más relacionado a la comunidad open source. Liberando el código fuente del .Net Framework, luego ASP.NET MVC. Colaborando y adoptando tecnologías open source desde su nacimiento, comenzando por JQuery hace varios años, luego knockout.js, Git, etc.

Otra de las aristas de este cambio interno es la frecuencia de los releases, el hecho de liberar versiones de forma más frecuente hace que la comunidad entre en un círculo virtuoso de feedback con los productos. Teniendo así una visión mucho más integradora entre la comunidad y la empresa como herramienta de innovación y adopción de nuevas tecnologías.

La semana pasada, tuvo lugar la conferencia de desarrolladores más grande dentro del mundo Microsoft, BUILD 2013. Esta oportunidad el lugar seleccionado fue la bella San Francisco, y tuvo ejemplos claros de lo que se menciona en este post. Uno de ellos fue hecho por Scott Hanselman, Principal Community Architect de Windows Azure y Web Tools, en su charla “What’s New in ASP.NET and Visual Studio 2013”. Si pueden dedicar un tiempo para mirar la presentación, es sumamente recomendable no sólo por su contenido si no también para aprender un poco acerca de cómo hacer llevadera una charla puramente técnica 🙂

En la imagen inferior se puede ver la cadencia de releases de ASP.NET planteada durante la charla.

http://channel9.msdn.com/Events/Build/2013/2-546

Especificación HTML 5 Terminada

Una buena noticia para todos los que estamos involucrados de alguna u otra manera en el mundo de internet, y más aún en el desarrollo de software basado en la web. La especificación HTML 5 fue declarada como “feature complete”, o sea que ya se puede desarrollar sobre una base más firme y acordada. Salud a todos!

HTMLComplete

Para más información aquí está el link con el anuncio: http://www.w3.org/News/2012#entry-9667