En la entrega anterior se presentó cómo y porqué las metodologías ágiles y las prácticas relacionadas, pueden ser de ayuda en los proyectos offshore, donde el desarrollo está ubicado en países donde los costos suelen ser menores. En esta entrega completamos las prácticas y lecciones aprendidas.
Best practices para la gestión de proyectos Offshore
En la entrega anterior se presentaron las prácticas de "Distributed Continuou
s Integration", "Script Test: Ayudar a comprender los requerimientos", "Bug-fixing first" y "Wiki". A continuación se explicarán las siguientes:- Múltiples vías de comunicación
- Embajadores
- Nearshore Pilot
- Tutorial + FAQ = Documentación on-deman
- Simulación de ambiente
- Gestión del Team
- Regular Short Status Meeting & Short Iterartions
- Nosotros!
- Proceso de aceptación
- Diferencias de zona horaria
Al trabajar de forma remota, los pequeños errores de entendimiento rápidamente se transforman en grandes problemas.
En los equipos de desarrollo distribuido, los responsables deben prestar atención a las prácticas de comunicación, que, por lo general, omiten sin consecuencias negativas en el desarrollo local. Es muy importante emplear una modalidad efectiva de comunicación, y disponer de diferentes tipos de canales.
Hoy en día, existen gran cantidad de herramientas de comunicación que pueden utilizarse en los proyectos offshore, pero la más habitual, y también la más eficaz, en la comunicación persona a persona es la mensajería instantánea (MSN Messenger, Yahoo Messenger, GTalk, etc.), que permite hacer preguntas y respuesta de un modo veloz.
Existen otras opciones, como las conferencias telefónicas, indispensables para las comunicaciones de grupos, o para cuando la información que se necesita es mucha; o las videoconferencias, menos utilizadas.
En lo que se refiere a la comunicación escrita, el correo electrónico es el más empleado, aunque es fundamental el uso de la wiki, para propiciar el ambiente colaborativo, publicando toda la información que puede resultar útil al equipo.
El teléfono debe ser utilizado sin problemas y sin que los costos cohíban su uso por parte de los integrantes del equipo. Actualmente, gracias al avance tecnológico, con el Protocolo de Voz sobre Internet (VoIP) se reducen considerablemente los costos de la comunicación "verbal".
Entonces la combinación de estos dos medios mitiga ampliamente los efectos de la distancia. En una conversación, cuando hay problemas de comprensión, si una cosa no se entiende por voz, se lo escribe!
Cada canal de comunicación debe ser usado en el momento necesario a fin de garantizar la máxima cohesión de todo el equipo.
Embajadores
Los responsables de los proyectos deben tratar de construir relaciones humanas personales dentro de los equipos. Ninguna herramienta de comunicación, es mejor que una linda visita.
Tanto al inicio del proyecto, como de forma regular (cada 6 u 8 semanas), resulta muy útil que representantes de los equipos mantengan alguna reunión "cara a cara".
La práctica ambassador (embajadores) prevé un intercambio recíproco de embajadores de las dos partes.
Los embajadores pueden ser los mismos project leaders, o arquitectos y/o desarrolladores, en función del contexto y de la razón de la visita.
Esto permite conocerse mejor, entender el contexto recíproco, el modo de trabajar y posiblemente detectar mejoras en el proceso y/o comunicaciones.
Nearshore Pilot
Esta práctica, cuando estructuralmente es posible, prevé una prueba piloto del proceso de externalización en nearshore de una parte de la aplicación, antes de pasar todo a offshore.
La elección de una aplicación piloto que posea una importancia empresarial de grado bajo o medio limitará los efectos de cualquier problema inicial que pueda surgir con el proceso de externalización offshore. Cuando este proceso se haya consolidado, también se puede considerar la posibilidad de llevar a cabo otros proyectos offshore sin pasar por esta prueba.
En síntesis, la prueba piloto permite una mayor facilidad de startup, setup y tunning del proceso que cuando se pretende hacerlo directamente en offshore.
Tutorial + FAQ = Documentación on demand
En función del contexto del proyecto, hay diferentes tipos de documentación que son muy útiles disponer para que los desarrolladores de offshore se familiaricen con el producto a extender o modificar. Ejemplos de los tutoriales a los que se hace referencia van desde pequeños documentos específicos del negocio que deban aprender, hasta las reglas de codificación que deben emplearse para el proyecto.
Cuando el equipo offshore reside en un país donde se habla otro idioma, hay que tener en cuenta la traducción de la documentación. Este paso "teóricamente" obvio, a veces no es tenido en cuenta en la planificación. Además hay que considerar el caso en el cual escasea, es insuficiente y/o falta, entonces la primera actividad es hacerla, y después realizar la traducción.
La documentación así traducida permitirá el start-up del equipo offshore.
Para ayudar o agilizar la toma de conocimiento del software del proyecto, en algunas circunstancias es útil disponer de una demo (prototipo) y/o tutorial práctico.
El eventual "gap de know how" entre los dos niveles de documentación puede ser mitigado en modo colaborativo e incremental mediante la creación sobre la Wiki de una sección de FAQ (Frequently Asked Questions).
Cada pregunta por parte de un miembro del team offshore debe ser escrita en la Wiki y tener la correspondiente respuesta del equipo onsite.
Si se aplica en modo riguroso y continuo, la práctica trae en modo natural e incremental una actualización sistemática de la documentación y reducida ad hoc por las exigencias del team offshore.
Los "enemigos" de esta practica son el uso no disciplinado de las herramientas como la mensajeria instantánea y el teléfono, donde la información, una vez "consumida" y no publicada en la Wiki es perdida, por lo que se debe concientizar su uso.
Simulación de ambiente
Cuando un desarrollo se realiza en offshore, en muchas ocasiones el proyecto debe interactúar con otros sistemas y/o fuentes de datos. Para ello es necesario disponer de una buena conectividad y utilizar canales seguros para mantener la seguridad e integridad de los datos que se transmiten.
Figura 5 - Aplicaciones offshore que acceden a datos onsite vía VPN
Esto requiere el acceso por parte del equipo offshore a los data store onsite mediante una Virtual Private Network (VPN), es decir una línea de comunicación dedicada virtualmente.
Una VPN es una red privada que utiliza un medio de transmisión público y compartido como puede ser por ejemplo Internet. Los mensajes de la VPN transitan sobre la red pública oportunamente cifrados y mediante protocolos seguros como IP Security, PPTP, etc.
Es fundamental tener en cuenta las posibles indisponibilidades de la red y/o de las eventuales carencias de calidad de conexión. Se necesita hacer mitigar estos inconvenientes, de modo que no afecten, o afecten lo menos posible, el trabajo offshore.
Figura 6 - Local DB + Host Mock + Security Mock
Una alternativa es la simulación de los ambientes (Mock Environment). A continuación se presentan algunas posibles prácticas:
Local DB
Para las aplicaciones en las cuales es necesario recuperar datos de una BD, sería acertado replicar la base, y que el equipo offshore tenga su propia base donde acceder. Será una tarea del equipo onsite construir las DLL de definiciones y los relativos scripts SQL para su carga (populate). Esto permite al team offshore trabajar en forma independiente del ambiente onsite.
Host Mock
La capa de integración debe "simularse" (loopback locale), fingiendo el acceso al host y restituyendo los datos de test oportunamente configurados.
De esta manera es posible desarrollar las partes de la aplicación, sin necesidad de acceder al host. Es importante que tal operación se realice mediante configuraciones y de ningún modo programado (hard code).
Security Mock
En ciertos casos es necesario disponer de un Security Mock, es decir una "seguridad fingida", que permita la ejecución de la aplicación sin tener que validar la seguridad definida en el ambiente del cliente.
Este caso puede considerarse, como un caso particular del anterior. En cierto modo, cuando se quiere que la aplicación que se esta desarrollando contemple directivas de seguridad (por ejemplo permisos de acceso), y es necesario consultar el esquema de seguridad (cualquiera fuere y se encuentre fuera del alcance del proyecto), entonces se deben poner los controles en forma de configuración (no programático, hard code) para su simulación durante el período de desarrollo.
Uno de los primeros puntos que deben analizarse es distribución entre los equipos offshore y los onsite. Ciertamente, no resulta fácil establecer una regla general. Se estima que una buena forma de repartirlos es un 30% local y un 70% offshore. Esto no quiere dar por regla que estos porcentuales son los mas utilizados, como siempre todo depende del contexto y del proyecto, por ejemplo si se quiere implementar una solución de integración, en el que el aspecto funcional tiene gran importancia, el tamaño del equipo onsite debería aumentar, por ejemplo 40/60.
Por otro lado, en un proyecto (sobretodo offshore) no es una buena practica que el líder del proyecto "local" gestione directamente los recursos offshore.
Es conveniente que la estructura organizativa prevea que el Project Leader onsite sea ayudado por un Offshore Team Leader para la coordinación de los desarrolladores.
El Offshore Team Leader resulta una especie de "Proxy" del Onsite Project Leader, ayudándolo a entender / relevar / comunicar / asistir frente a eventuales problemas del proyecto (retrasos, incomprensiones, errores, etc.).
Figura 7 - Gestión del team
Por otro lado, se recomienda no relegar los equipos offshore meramente a las funciones de desarrollo, sino que se aconseja implicarlos en otras actividades, esto garantiza una comunicación más fluida, una mayor motivación y, además, una alta productividad, ya que se reduce la dependencia de los equipos locales. De la misma forma también es necesario balancear los roles de los equipos, un "anti-pattern" en tal sentido es, por ejemplo, tener un solo "Gurú" de un lado, dificultando el crecimiento del team del otro.
La creación de figuras análogas ayuda a crear una ambiente de trabajo colaborativo y a evitar una actitud de superioridad por parte de uno u otro equipo.
Figura 8 - Mismos roles en ambos lados
Regular Short Status Meeting & Short Iterartions
Las metodologías ágiles promueven regularmente reuniones breves para todo el equipo de desarrollo (scrums en Scrum, stand-up meeting en XP, etc.).
Esto es muy importante también en un proyecto offshore en el cual se necesita tener en cuenta además de la distancia física, las diferencias horarias.
Se necesita que la reunión de realice en un horario que tenga en cuenta las respectivas exigencias del trabajo (por parte de cada team).
Por otro lado es importante también subdividir el proyecto en iteraciones breves.
Tener hitos cercanos permite tener controles frecuentes y, relevar y gestionar primero cuantos errores y/o incomprensiones surgieran, prevenir es mejor que curar!
Nosotros!
La parte remota del grupo no debe ser vista por la parte onsite como "los que desarrollan", y de la misma forma, el equipo onsite no debe verse por parte del equipo offshore como "los que definen y controlan". Si bien la separación de roles y actividades existe, debe mantenerse un clima de cooperación con la mayor cohesión posible. Tratar que los equipos onsite y offshore, hablen siempre de "nosotros" (sin importar la ubicación física donde se encuentren, y no hacer diferencia, "ellos y nosotros".
Proceso de aceptación
Uno de las motivaciones principales del offshore es la reducción de costos garantizando un adecuado nivel cualitativo.
Para poder garantizar un adecuado nivel cualitativo es importantísimo tener claro los criterios de aceptación y de mediciones, de tamaño y esfuerzo, del proyecto.
Es recomendable especificar en cada proceso (sobretodo en el ámbito offshore) el proceso de aceptación de los entregables del producto de software antes de entregárselo al cliente.
Por ejemplo, el proceso que se puede aplicar a un proyecto, puede prever el control de la documentación y el código. Para el control de código se aplican los criterios de quality assurance a nivel de audit code, code coverage y test.
A nivel de audit code (código y naming convention) no deben estar presentes errores a nivel ERROR o WARNING en el producto de software.
A nivel de code coverage el porcentaje de cobertura de los test (a nivel de clase, método, statement y bloques) no debe ser inferior al 75%. A nivel de test debe estar presente, en todo momento, un test por cada bug declarado resuelto y deben estar presentes, y documentados, los test relevados y los acceptance test acordados con anticipación.
El procedimiento de aceptación debe ser riguroso y por sobre todo, repetible.
Para esto, una buena práctica es buscar de formalizar los pasos que componen tal procedimiento (por ejemplo, reporte en la Wiki, documento Word, tabla del Excel, etc.).
Diferencias de zona horaria
Administrar el cambio horario no es trivial.
Existen básicamente dos estrategias para manejar las diferencias de zona horaria. La primera es separar a los equipos por actividad, por ejemplo, tener gerentes de producto y de aseguramiento de calidad en la empresa y desarrolladores en el exterior (para describir las funciones principales. No olvidar las recomendaciones expuestas sobre la Gestión del Team). Esta organización permite implementar un ciclo en el que los desarrolladores implementan arreglos y nuevos requisitos mientras sus contrapartes están durmiendo y viceversa. Por ejemplo, con un cambio horario de 4 horas (por ejemplo Argentina y España), cuando el equipo argentino inicia a trabajar, el equipo español está a la mitad de la jornada de trabajo (y posiblemente en el break del almuerzo).
De un modo pragmático, se necesita buscar subdividir la jornada del equipo onsite, dedicando la primera parte para gestionar la actividad y crear elementos útiles para el team offshore para la tarde, y la segunda a seguir/colaborar con el equipo offshore.
El segundo enfoque es dividir los proyectos en bloques y tratar de asignar cada bloque a una ubicación, delegando la mayor cantidad de funciones posibles a esta ubicación. El segundo enfoque obliga a una mejor comunicación y por lo tanto sirve mejor al desarrollo ágil, pero ambos funcionan y muchas veces no existe otra opción.
Si bien es sencillo decirlo, no es propiamente trivial llevarlo a la práctica.
Conclusiones
Seguramente la gestión de un proyecto offshore requiera elevar la competencia de proyect management para buscar y gestionar procesos adaptados a los alcances prefijados: son de hecho diversos factores que pueden ralentar u obstaculizar el correcto desarrollo del proyecto, afectando los beneficios económicos y de escalabilidad ligados al desarrollo offshore.
El offshore introduce costos y riesgos extras, respecto a una gestión de proyecto onsite.
La posibilidad de miscommunication y/o misunderstanding en un proceso offshore es superior (distancia, diferencias horarias, cultura, idioma, etc.) y se necesita atenuar con rigor (aun mas rigor que aquel que deberíamos en un proyecto onsite) con el empleo de las practicas explicadas, con el fin de minimizar tales riesgos.
Es necesario ser buenos mediadores para sobrepasar y mitigar las eventuales dificultades del idioma y la cultura; además, hay que tener la actitud justa y una buena dosis de flexibilidad.
Es importante tener bien presente la necesidad de tener una buena comunicación, también desde un punto de vista tecnológico, previendo una buena conectividad (conexión VPN, línea telefónica, etc.) y utilizando las herramientas disponibles.
En este artículo se han presentado algunas importantes prácticas y lecciones aprendidas, útiles para la gestión de procesos offshore, tomado de la literatura actual y nuestra experiencia, en Snoop Consulting.
Referencias
[Brooks, 1987] Frederick P. Brooks, Jr., "No silver bullet: Essence and accidents of software engineering", Computer, vol. 15, no. 1, pp. 10-18, Abril 1987.
[DXP] Michael Kircher, Prashant Jain, Angelo Corsaro, David Levine. "Distributed eXtreme Programming". Second International Conference on eXtreme Programming and Agile Processes in Software Engineering - XP2001. Cagliari, Sardinia, Italy. Mayo 2001.
[Fowler, 2002] Martin Fowler, Matthew Foemmel. "Continuous Integration". ThoughtWorks Inc, 2002. (http://www.martinfowler.com/articles/continuousIntegration.html)
[Fowler, 2006] Martin Fowler. "Using an Agile Software Process with Offshore Development". Última actualización Julio 2006. (http://www.martinfowler.com/articles/agileOffshore.html)
[Rossini, 2006] S. Rossini, "Le metodologie agili e i progetti offshore" MokaByte 108 Junio 2006
No hay comentarios:
Publicar un comentario