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🙂

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: