Análisis deslocalización de un producto software (II)

Introducción

Este artículo es la segunda parte de este primer artículo , donde se continúa con las tareas de análisis para la deslocalización de un producto software.

Una vez que se ha analizado qué tipo de producto tenemos, qué estructura de equipo lo está desarrollando y el proceso de producción que se sigue, vamos a ver ahora que mínimos hay que establecer para comenzar con la deslocalización.

Estos mínimos que se describen son los que por experiencia sabemos que hay que definir para que al menos la deslocalización pueda tener una posibilidad de éxito. Por lo tanto, es una condición necesaria pero no suficiente.

La base sobre la que se sustenta la definición de estos mínimos es la aplicada ya en muchos otros ámbitos:

"Divide and Conquer."

Julius Caesar

Como veremos, todas las redefiniciones que veremos a continuación tendrán el objetivo de dividir la producción actual en todas sus dimensiones: fases de producción, roles del equipo y sus comunicaciones y los activos producidos.

Redefinir las fases de producción y los activos

Es clave definir las fases de producción así como sus activos durante el análisis de la deslocalización de un producto software. El objetivo es identificar las fases de producción por el activo que produce cada fase. Las fases que nosotros identificamos son las siguientes:

Fase	Activo
Análisis funcional	Descripción funcional del producto
Diseño	Diseño detallado del producto
Implementación	Código del producto
Testing	Planes de pruebas de aceptación del producto
Adaptación de datos	Datos de configuración del producto / datos de pruebas

Cada fase necesita una entrada para producir su activo. El activo producido por una fase será la entrada a la siguiente fase.

Por ejemplo, la entrada al diseño detallado será el activo producido por el análisis funcional que es la descripción funcional.

En el caso del activo de datos de configuración no se cumple esto ya que es un activo ortogonal a todas las fases.

Cada activo define un marco de referencia al activo producido en la siguiente fase:

1. El análisis funcional no especificará ninguna feature que no esté soportada por algún requisito del cliente.
2. El diseño detallado no tendrá ningún servicio que resuelva una funcionalidad no descrita en el análisis funcional.
3. El código del producto no tendrá ningún servicio implementado no especificado en el diseño detallado. El código del producto incluye tanto el código que ejecuta en producción como los tests unitarios, tests de integración y tests de ensamblaje.
4. Los planes de pruebas de aceptación no tendrá ninguna prueba que no pueda trazarse con ninguna feature del análisis funcional.

Según la estrategia que vayamos a seguir para la deslocalización necesitaremos tener unos activos con mayor o menor detalle en su definición. Esto lo veremos en un futuro artículo.

Como se puede ver no se está definiendo nada nuevo que no haya contemplado ya la ingeniería del software. Solo se hace hincapié que es necesario tener estas fases y activos si se quiere deslocalizar la producción.

Tampoco se está diciendo aquí que haya que seguir un ciclo de vida en cascada, lo que chocaría con seguir una metodología ágil. Sólo se están identificando las fases y activos necesarios, sin entrar en definir como se tienen que dar a lo largo del tiempo.

Nótese que hasta aquí se han identificado solamente las fases de desarrollo, dejando fuera las fases de operación del sistema (DevOps) ya que solamente se está analizando la deslocalización de la producción, no de la operación.

Redefinir los roles del equipo

Durante el análisis de la deslocalización de un producto software es clave redefinir los roles del equipo, junto con sus responsabilidades. Cuando nos movemos a un entorno distribuido de producción hay que asegurar que ninguna responsabilidad queda descubierta.

Se pueden definir los roles a partir de las fases de producción identificadas anteriormente. Un rol puede ser cubierto por uno o varios miembros del equipo y un miembro puede cubrir varios roles.

Las responsabilidades que identificamos para cada rol se pueden ver en la siguiente tabla:

Rol	Responsabilidades
Jefe de proyecto	Definición y control del alcance de cada versión, gestión de riesgos, control económico y otras responsabilidades típicas de gestión.
Responsable técnico	Responsable de la tecnología aplicada en el producto o en una parte de él, aseguramiento de la calidad del código.
Analista funcional	Elaboración de la descripción funcional del producto, colaboración en la definición de las pruebas de aceptación y realización de auditorías funcionales del código producido .
Diseñador	Elaboración de los diseño detallados del producto.
Desarrollador	Implementación del código acorde al diseño, incluyendo las pruebas unitarias, pruebas de integración y pruebas de ensamblaje.
Tester	Definición de los planes de pruebas de aceptación y paso de pruebas de aceptación.
Adaptador de datos	Preparación de datos de configuración del producto y de datos para pruebas de aceptación.
Responsable de entrega	Aseguramiento de la infraestructura necesaria en cada versión: creación de ramas, construcción de artefactos, construcción del entorno de pruebas de aceptación, etc.

Aparecerán nuevos roles y responsabilidades según nos movamos a un modo de trabajo distribuido en remoto concreto.

Redefinir las comunicaciones

Nuevo entorno de trabajo

Es imprescindible definir las comunicaciones entre los miembros del equipo en el análisis de deslocalización de un producto software. Se ha tener en cuenta que en este nuevo paradigma de trabajo la comunicación face to face será la menos usada.

Debido a que nos movemos a un entorno distribuido tenemos que buscar soluciones que nos concentren las comunicaciones y la información que de ellas se derive para ponerla en común a todo el equipo.

Otro aspecto a considerar es cuando tienen lugar las comunicaciones. Mientras que un entorno no distribuido se es más propenso a tener comunicaciones síncronas interrumpiendo al compañero de al lado, en un entorno distribuido se tenderá a tener comunicaciones asíncronas. Esto requerirá una mayor planificación para organizar la ocurrencia de estas comunicaciones. Se ha de lograr un equilibrio entre las interrupciones que producen los miembros que deben resolver el tema y los bloqueos que se producen los miembros que no pueden avanzar en su trabajo por no resolverse este tema.

La comunicación escrita será la preferible, pues permite la asincronía, el tratamiento en bloque de varios problemas y la concentración de la información poniéndola disponible para el resto del equipo. Sin embargo, es cierto que no siempre es posible explicar perfectamente una cuestión técnica solamente escribiendo.

Por otro lado, la comunicación escrita tiene una desventaja respecto a la comunicación oral (más aún si es presencial) . La desventaja es que está más abierta a la interpretación del lector y quién escribe tiene más dificultades para expresar el tono de la conversación y su tono emocional. Es por esto que en algunos casos delicados sea ideal apoyar la comunicación escrita con la comunicación oral.

En el caso de comunicaciones que necesiten la presencia física de los participantes hay que considerar el desfase horario que pudiera haber entre los diferentes sitios remotos así como la lengua a utilizar.

Para definir una comunicación es necesario considerar los siguientes aspectos:

Pongamos un ejemplo de comunicación según el esquema anterior:

Comunicación	Dudas sobre un diseño detallado
Roles	Diseñador, desarrollador
Motivo	Clarificar dudas en el diseño que tiene el desarrollador. Pueden ser dudas de implementación o del propio diseño.
Lenguaje	Se suele hablar en términos de patrones de diseño o del propio lenguaje de implementación.
Adaptación	Comentarios escritos en la herramienta que contenga el diseño, por mensajería instantánea o directamente por teléfono pero dejando constancia de lo acordado por escrito posteriormente.

Canales de comunicación

Otro aspecto importante cuando tenemos sitios remotos es definir los canales de comunicación entre los miembros del equipo. Es preciso evitar comunicaciones cruzadas que no respetan los canales definidos ya que esto puede conducir a tomar soluciones diferentes para un mismo problema. Y provocar además que no todos los miembros estén informados sobre la solución adoptada.

Hay que poner especial atención cuando hay comunicación entre dos miembros que resuelve un problema que puede repetirse más adelante. En este caso esta comunicación 1 a 1 dará lugar a una comunicación 1 a muchos repetidamente. Se puede decidir escribir la solución escogida en una wiki para que pueda ser consultada por el equipo y escribir un correo al grupo para que sepan de la existencia de esta solución en la wiki.

Herramientas

Las herramientas online colaborativas se vuelven imprescindibles en un entorno distribuido de trabajo, pues hacen posible la comunicación escrita con las ventajas que antes comentábamos. La siguiente tabla recoge un abanico de herramientas online útiles para el trabajo en remoto en entornos remotos y distribuidos:

Tipo herramienta	Usos	Ejemplos
Herramienta de gestión de issues	Registro de requisitos de usuario, features y backlog del producto, gestión ágil, registro de bugs, etc.	JIRA
Herramienta tipo wiki	Edición de documentación con posibilidad de exportación a documentos cerrados, de realizar comentarios y de trabajo colaborativo.	Confluence, Google docs
Mensajería instantánea	Dudas puntuales, avisos imprevistos, etc.	Slack, Google Chat
Correo electrónico	Para notificaciones exporádicas. Se preferirá el uso de grupos de correo, en lugar de comunicaciones 1 a 1.	Gmail
Videoconferencia	Para reuniones técnicas, de coordinación, etc. Se deberá dejar constancia escrita de los resultados y acuerdos alcanzados.	Zoom, Google Hangouts, Skype
Teléfono	Para cuestiones excepcionales y personales entre los miembros del equipo. O para tratar algún tema técnico rápidamente pero luego dejando constancia escrita del resultado.

Lenguaje

Otro aspecto importante en la comunicación es el lenguaje utilizado en cada comunicación. Cuando hay varios sitios de trabajo el objetivo es lograr una comunicación efectiva y eficaz, evitando malos entendidos en el mensaje que se pretende comunicar.

Para ello es indispensable utilizar un lenguaje apropiado y que estará adaptado a cada aspecto bajo discusión.

Si se está hablando sobre la descripción funcional del producto, se deberá usar un lenguaje basado en los conceptos de negocio que han sido usados para describir el producto. En el caso del diseño detallado de una feature del producto, se usará los términos relativos a patrones de diseño de software. Si estamos discutiendo sobre la implementación de algún servicio, entonces utilizaremos los términos propios del lenguaje de programación o del framework utilizado.

Todos los miembros del equipo deberán conocer estos lenguajes específicos y deberán hacer un esfuerzo por aplicarlo convenientemente.

Al final se trata de pasar de un lenguaje natural utilizado en la fase de análisis del negocio a un lenguaje de programación determinado, pasando por lenguajes intermedios (funcional y de diseño) que sirven para hacer las traducciones intermedias sin perder información.

Es importante tener varios lenguajes en el equipo porque de lo contrario puede haber miembros que no puedan participar en la producción. Por ejemplo, si no usamos un lenguaje basado en los conceptos del negocio, entonces los roles de analista funcional y tester no podrán intervenir en la comunicación. A menudo ocurre que se da más importancia en un equipo de trabajo al lenguaje técnico de programación. En este caso, solamente podrán intervenir y aportar su opinión los desarrolladores y algún diseñador o analista que en el pasado hayan sido desarrolladores.

Visitas

Hasta ahora hemos mencionado modos de comunicación que no involucran a las personas físicamente. Sin embargo, la comunicación en persona sigue siendo de vital importancia. Cuando tenemos varios sitios es indispensable visitar estos sitios para conocer en persona a los demás compañeros del equipo y empatizar con ellos. Solemos empatizar con los compañeros que tenemos al lado o que conocemos de más tiempo.

Se pueden planificar visitas con cierta frecuencia a los otros sitios para mantener viva esta relación personal. En nuestro caso, solemos hacer visitas a otros centros y aprovechamos para trabajar codo con codo en algún tema complejo del desarrollo de alguna feature. Es aconsejable que los miembros que hacen estas visitas vayan rotando para maximizar la exposición.

Otra posibilidad es que algún miembro del equipo de un sitio ya establecido se desplace por una temporada a un sitio en fase de establecimiento, haciendo de facilitador entre ambos sitios. Será la persona de transmitir al nuevo sitio la cultura y las buenas prácticas establecidas. Cabe mencionar que para esta labor no sirve cualquier persona. Ha de ser una persona empática y con buenas habilidades de comunicación.

Es imprescindible evitar la actitud de nosotros y vosotros que suele darse cuando hay varios sitios con diferentes responsabilidades. Incluso se da en un equipo centralizado cuando hay varios departamentos o grupos independientes. Mitigar esta actitud evita a la larga muchos enfrentamientos y conflictos en el equipo.

Refactorización del producto

Necesidad de refactorización

Durante el análisis para la deslocalización de un producto software es de vital importancia analizar como está construido el producto. Es muy probable que si hasta ahora no teníamos un proceso de producción definido en fases y ademas teníamos un único sitio de trabajo, entonces no tengamos un producto con una arquitectura desacoplada y cohesiva.

Será necesario sin lugar a dudas una refactorización del producto para lograr al menos tener diferentes módulos o subsistemas del producto desacoplados entre sí.

No hablaremos en este artículo de cómo llevar a cabo técnicamente esta refactorización hasta que no veamos las estrategias de deslocalización que pueden darse en un próximo artículo. Lo que sí mencionaremos serán los pasos a dar para llevar a cabo esta refactorización.

Plan de refactorización

El primer paso en el plan de refactorización del producto es obtener la arquitectura detallada del producto. Ya sea porque tenemos documentación del diseño del sistema o porque apliquemos ingeniería inversa, es necesario obtener un diagrama de la arquitectura del sistema que muestre las dependencias entre los componentes y entre los servicios de un componente, indicando los flujos de datos principales intercambiados. Será básico el obtener los objetos principales del negocio identificados en el código.

El segundo paso es obtener la arquitectura objetivo a la que se pretende llegar. Como hemos comentado antes esta arquitectura objetivo deberá ir alineada con la estrategia de deslocalización. Es necesario refactorizar la arquitectura existente aplicando patrones de diseño para conseguir que la arquitectura cumpla con los dos principios básicos comentados anteriormente: alta cohesión y bajo acoplamiento.

El tercer paso establecer un plan para llevar a cabo esta refactorización. Será preciso trazar un plan para que partiendo de la arquitectura original consigamos llegar a la arquitectura objetivo. Habrá que pasar por arquitecturas intermedias por varios motivos.

El primer motivo es mitigar el riesgo de no perder funcionalidad ni incluir nuevos bugs entre refactorizaciones.

El segundo es que no se suele contar con tiempo suficiente como para hacerlo en un solo paso, pues el negocio sigue necesitando evoluciones funcionales del producto.

El tercero es derivado del segundo. Se necesitará reservar un presupuesto para realizar esta refactorización de modo incremental y deberá ser acordado con el equipo de gestión.

En un futuro artículo seguiremos profundizando en como hacer cada uno de estos pasos.

Infraestructura necesaria

Durante el análisis para la deslocalización de un producto software es necesario identificar qué infraestructura mínima es necesaria para poder trabajar en remoto.

Si optamos por el uso de herramientas online colaborativas tenemos dos opciones.

La primera opción es que la herramienta esté disponible en los servidores de nuestra empresa. En este caso se necesitará acceso remoto a la herramienta. La mayoría de herramientas admiten acceso vía https por lo que no es necesario ni montar una VPN.

La segunda opción es que la herramienta se contrate como un SaaS, por lo que no necesitaríamos acceder a los servidores de nuestra empresa.

En un entorno distribuido necesitamos contar con una plataforma de integración continua para centralizar la construcción y despliegue de nuestros artefactos. El conjunto de estas herramientas queda recogido en la siguiente tabla:

Uso	Herramienta
Repositorio de código	Github, GitLab, Bitbucket
Servidor de integración contínua	Jenkins, Bamboo
Repositorio de artefactos	Nexus, Artifactory
Servidor de despliegue continuo/automatizado	Jenkins, Ansible
Plataforma análisis de código	SonarQube

Además de tener una plataforma de integración continua necesitamos tener infraestructura para desplegar nuestras aplicaciones y realizar pruebas en fábrica antes de realizar la entrega al cliente. Tenemos diferentes opciones. Desde la más simple que es trabajar con máquinas virtuales (VMware, VirtualBox) a la más compleja que permita ejecutar microservicios (OpenShift).

Por último necesitamos herramientas que hagan posible la gestión del trabajo. Podemos diferenciar dos tipos de herramientas. Herramientas para la gestión de tareas e issues en general (Jira, Trello) y herramientas para tareas de documentación (Confluence, Alfresco).

En cuanto a herramientas para la comunicación, ya se comentaron anteriormente.

Conclusiones

Durante el análisis para la deslocalización de un producto software hemos visto lo mínimo que hay que tener para hacer posible esta deslocalización. Se ha comentado las redefiniciones necesarias y que afecta al proceso de producción, a los roles y responsabilidades de cada miembro del equipo y a las comunicaciones entre los miembros.

También hemos visto la necesidad de refactorizar el producto software de cara a tener una mínima posibilidad de éxito en su deslocalización y a como definir un plan de refactorización del producto.

Por último hemos visto la infraestructura mínima necesaria para posibilitar el trabajo en remoto y distribuido del equipo, identificando herramientas para cada trabajo específico.

Una vez realizado este análisis y haber efectuado estos cambios sería aconsejable seguir trabajando con el equipo centralizado según el nuevo modo de trabajo y usando las nuevas herramientas.

Después de todo esto, el siguiente paso será escoger qué parte de la producción estamos en disposición de deslocalizar. Esto lo veremos en un futuro artículo.