En este artículo veremos 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 primer lugar se presenta una breve introducción a las metodologías tradicionales y a las ágiles; a continuación se explicará en qué consiste un proyecto offshore, junto a sus modos de contratación y dificultades existentes, en comparación a los proyectos onsite; para seguir con una reseña de los métodos ágiles adaptados a este contexto; y finalizar con la descripción de las prácticas ágiles y lecciones aprendidas útiles para la gestión de procesos offshore.
Metodologías tradicionales y ágiles, mejores prácticas
Una metodología de desarrollo es un la conjunción de métodos que especifican quién debe hacer qué cosa, cuándo debe hacerse, estableciendo un conjunto de roles (el quién), actividades (la cosa) y un ciclo de vida que establece las diferentes fases.
El desarrollo de software es riesgoso y difícil de controlar, más aún en contextos offshore. Prueba de ello es que existen muchas metodologías que inciden en aspectos del proceso de desarrollo. Por una parte tenemos aquellas más “tradicionales”, que llevan asociado un marcado énfasis en el control del proceso, mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este esquema tradicional para abordar el desarrollo de software, ha demostrado ser efectivo y necesario en proyectos de gran envergadura (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales, donde las necesidades de los clientes son muy cambiantes, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad.
Bajo este escenario, ha surgido una corriente en la industria del software que considera que las necesidades de los clientes son muy cambiantes. En pos de esto surgen metodologías que parecen contradecir la visión tradicional, por estar especialmente orientadas para proyectos pequeños, con plazos reducidos, requisitos volátiles, y/o basados en nuevas tecnologías, por lo que las metodologías ágiles constituyen una solución a medida para ese entorno, aportando una elevada simplificación, que a pesar de ello, no renuncia a las prácticas esenciales para asegurar la calidad del producto.
Figura 1 – Prácticas ágiles “transversales” a las metodologías
Los métodos ágiles más conocidos y empleados son: eXtreme Programming, Scrum, Crystal Methods, Feature Driven Development, Dynamic Systems Development Method, Adaptive Software Development.
Lo que estos métodos tienen en común es su modelo de desarrollo incremental (pequeñas entregas con ciclos rápidos), cooperativo (desarrolladores y usuarios trabajan juntos en estrecha comunicación), directo (el método es simple y fácil de aprender) y adaptativo (capaz de incorporar los cambios). Las claves de los métodos ágiles son la velocidad y la simplicidad. De acuerdo con ello, los equipos de trabajo se concentran en obtener lo antes posible una pieza útil que implemente sólo lo que sea más urgente; la prioridad es satisfacer al cliente mediante entregas tempranas y continuas de software que le aporte un valor. En este momento se espera el feedback del cliente y se dan la bienvenida a los cambios solicitados, interpretándolos como un avance en la comprensión y luego satisfacción del cliente.
Por lo dicho podemos concluir que en las metodologías tradicionales, en primer lugar se estudian bien los requisitos del producto para después estimar y planificar las actividades y los recursos necesarios para planificar su ejecución. Y en las metodologías ágiles, por su carácter adaptativo, el producto es realizado progresivamente, entregando partes del software totalmente funcionales en cada una de sus iteraciones, considerando en forma natural los ajustes que surgieran en el transcurso del tiempo.
La gestión de los procesos de desarrollo, sin un adecuado soporte metodológico, llevará a costos y elevados riesgos de gestión, sobretodo si se aplican a proyectos de gran envergadura.
Está de más decir que en la práctica, no existe un proceso de desarrollo universal, aplicable a todo proyecto [Brooks, 1987]. Las características del equipo de desarrollo, el dominio de aplicación, el tipo de contrato, la complejidad y envergadura del proyecto, etc., todos estos factores hacen necesario adaptar nuestra metodología de desarrollo.
Existen contextos en los que el uso de procesos de desarrollo de software ágil permanece cuestionable. Algunos ejemplos son los grandes equipos de desarrollo (más de 20 personas trabajando en un proyecto independiente), sistemas en los que la predicción es primordial (aplicaciones de vida crítica) y los entornos burocráticos. No se analizarán la aplicación de las prácticas en estos contextos. Igualmente, es posible utilizar las Best Practices en un modo integrado y transversal a la metodología en si misma que se emplee.
Offshore
La presión por reducir costes y concentrarse en las actividades de mayor rendimiento de la inversión (ROI), ha obligado a las empresas a buscar soluciones para alcanzar este objetivo, manteniendo los niveles de servicio actuales. Una de estas fórmulas, conocida como offshore, es la externalización de servicios a países más económicos, como la Argentina.
El proceso de externalización del proceso de desarrollo toma el nombre de Business Process Outsourcing (BPO). Que es la relocalización de funciones de procesos de negocios en proveedores de servicios, ya sea interno o externo a la empresa. BPO en español se traduce como "Externalización de Procesos de Negocios". Tal término fue concebido a mediados de los años 90 y toman popularidad en los últimos años, gracias a la explosión de los negocios de Internet.
Las principales ventajas del offshore son:
-
Nivel de servicios y calidad igual o superior, acceso a recursos inmediatamente disponibles y altamente cualificados. Generalmente las empresas que brindan servicios de offshoring invierten, para ser competitivas, en nuevas tecnologías, tanto de Software como de Hardware
-
Disminución real de los costes, especialmente en actividades de trabajo intenso.
-
Price stability: estabilidad del costo del proyecto.
-
Escalabilidad
-
Turnos de noche y velocidad en la entrega.
-
Oportunidad para que las empresas se centren en competencias clave, traspasando las actividades de menor importancia a terceros.
-
New business Partner: el offshore lleva a tener nuevos business Partners
Figura 2 – Equipos offshore y onsite
Existen distintas tipologías de proyectos offshore, principalmente podemos dividirlas en dos categorías:
- Fix Price & Time Box (Hitos): proyecto de precio fijo donde el proyecto de refiere a una oferta “llave en mano”, definiendo los objetivos y alcances del proyecto y el equipo offshore debe entregar el trabajo completo al cliente. Para el cliente el proceso de desarrollo lo ve como un proceso de caja negra.
- Collaborative projects: proyectos colaborativos, en los cuales el equipo offshore colabora con el desarrollo del proyecto en forma conjunta con el equipo onsite.
Lo primero que debe considerarse en el caso de un proyecto offshore, en base a los principales principios de las metodologías ágiles, es que el principio de la proximidad física (face-to-face) “desaparece”.
Con la dispersión física de las personas involucradas en el proyecto, la aplicación de las prácticas ágiles fundamentales, como es el stand-up meeting y la convivencia del mismo espacio de trabajo, se tornan, en principio, inaplicables.
En un proyecto offshore la comunicación se encuentra afectada a causa de:
- Dispersión geográfica
- Cambio horario
- Idioma
- Diferencias culturales
- Calidad tecnológica de la conectividad
En la sección anterior se listaron las principales dificultades que la externalización offshore conlleva, la pregunta fundamental resulta por tanto, cómo y si las practicas ágiles pueden ser de ayuda al proceso de desarrollo.
La adopción creciente de procesos en offshore, y la adopción de metodologías ágiles para el caso de equipos distribuidos en un contexto internacional ha llevado a las mismas metodologías ágiles a “adaptarse” (Agile Offshore Software Development o en el caso del mismo XP con el Distributed eXtreme Programming [DXP].
En el caso de AOSD, se basa en las Best Practices de XP (Continuous Integration, Strong Quality, Short iterations, etc.), RUP (notación UML para formalizar las especificaciones) y Open Source (Herramientas colaborativas y practicas asociadas (JUnit, NUnit, HttpUnit, etc.), todo esto aplicado en el contexto de proyectos offshore.
Distributed Extreme Programming (DXP)
DXP es una adaptación de XP, adecuado a la gestión de proyectos offshore.
El foco de la metodología DXP es “corregir / adaptar” la gestión de las practicas que requerían el acercamiento físico y que debían adaptarse al contexto de los proyectos offshore.
| Practicas XP | Cercania fisica | Practicas DXP |
| Planning game | Si | Distributed Planning Game |
| Continuous Integration | Si | Distributed Continuous Integration |
| On-Site Customer | Si | Virtual On-Site Customer |
| Pair programming | Si | Remote Pair Programming |
| Small Releases | No | |
| Metaphor | No | |
| Simple design | No | |
| Testing | No | |
| Refactoring | No | |
| Collective ownership | No | |
| 40-hour week | No | |
| Coding Standards | No | |
El esfuerzo para amoldar la metodología fue principalmente destinado a las practicas de Planning game, Continuous Integration, On-Site Customer y Pair programming, para buscar adaptarlas al contexto distribuido, que deben ser eficientes y colaborativas.
Con este fin aparecieron herramientas que minimizan la sensación de “alejamiento” físico, y “virtualizan” el acercamiento de las personas.
DXP introduce un nuevo valor al proceso, la paciencia. La paciencia y la tolerancia, la paciencia frente a los problemas tecnológicos (por ejemplo la baja calidad de las conexiones, problemas en las redes, ruido en las comunicaciones telefónicas, etc.) y la tolerancia por las diferencias culturales.
Best practices para la gestión de proyectos Offshore
A continuación se describirán algunas prácticas y lecciones aprendidas, útiles para la gestión de los procesos offshore.
Éstas prácticas / lecciones aprendidas son el producto de la experiencia que hemos recolectado en Snoop Consulting en los últimos años, combinada con la literatura de referencia (por ejemplo [Fowler, 2006], [Rossini, 2006]) que específicamente en este tema no abunda.
Las prácticas y las lecciones aprendidas que se explicarán en esta primer parte del artículo son las siguientes:
- Distributed Continuous Integration
- Script Test: Ayudar a comprender los requerimientos
- Bug-fixing first
- Wiki
- 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
La Integración Continua (Continuous Integration) es una práctica de XP que pone énfasis en el hecho de tener un proceso de construcción y testeo completamente automático, que permita al equipo modificar, compilar y testear un proyecto varias veces en un mismo día.
Todas los integrantes del equipo deben integrar su código con la última versión estable por lo menos una vez al día.
Martin Fowler [Fowler, 2002] afirma que el desarrollo de un proceso disciplinado y automatizado es esencial para un proyecto controlado, el equipo de desarrollo está más preparado para modificar el código cuando sea necesario, debido a la confianza en la identificación y corrección de los errores de integración. Con el proceso de Integración Continua la mayor parte de los bugs de un sistema se manifiestan en el mismo día en el que se integran los módulos intervinientes, reduciendo drásticamente los tiempos para determinar el problema y resolverlo, cada vez que se realiza la integración, los que la hacen deben asegurarse que todas las pruebas se ejecutan correctamente, para que el nuevo código sea incorporado definitivamente.
Hacer builds regularmente permite tener la posibilidad de obtener feedback continuo y actualizaciones del desarrollo offshore. Tal monitoreo permite controlar y seguir el progreso del proyecto, y anticipar eventuales errores y/o discrepancias; nos proporciona indicadores de la evolución real del código.
Existen varias herramientas que ayudan a realizar esta tarea, tal es el caso de Microsoft Team Foundation, CruiseControl, CruiseControl.NET, etc.
La práctica de Integración Continua puede ser también de fundamental ayuda en los procesos Offshore: Integración Continua Distribuida (Distributed Continuous Integration)
Figura 3 - Distributed Continuous Integration
Para la Integración Continua Distribuida es importante tener una muy buena conectividad a fin de evitar las largas esperas en los procesos de construcción (build). Es una buena práctica, en general, que el servidor donde se realizan los build se encuentre cerca del equipo de desarrollo principal, que generalmente es el de offshore.
Por otro lado en los proyectos colaborativos donde no tenemos centralizada la fuerza de trabajo, podemos considerar el hecho de disponer el repositorio de código en cluster.
Script Test: Ayudar a comprender los requerimientos
Cuanto más grande es la distancia, mas ceremonia hay que poner en la comunicación de los requerimientos. Una forma de ayudar a la comprensión de los requerimientos, es comunicar, además, los test de aceptación (Acceptance Test).
Dichos test ayudan a entender mejor el requisito y/o el diseño a implementar, disminuyendo la posibilidad de malos entendidos o incompresibilidad (respecto al requisito), más que a representar un “objetivo concreto” para el desarrollo offshore.
Estos test agilizan a su vez el uso de Test Driven Development (TDD): la práctica de desarrollo guiada por tests.
Siguiendo la practica TDD, se desarrolla en primer lugar el código de testeo de la funcionalidad de interés, y luego el código aplicativo que tal función implementa.
Esta práctica permite:
- Aclarar mejor el requisito
- Dar al desarrollador offshore un concreto objetivo a conseguir.
- Atenuar el uso de TDD en el equipo offshore (RTDD – Remote Test Driven Development)
Bug-fixing first
Puede decirse que las dos tareas de desarrollo más comunes son la de corregir bugs e implementar nuevas características. Es muy útil seguir la práctica de comenzar primero por el desarrollo correctivo (corrección de bugs).
La actividad de bug-fixing requiere más lectura de código que desarrollo nuevo, y es una manera óptima de familiarizarse con el producto de software y el proceso metodológico.
Antes de corregir una anomalía se deben revisar uno o más casos de test (test de unidad como por ejemplo JUnit, NUnit o HttpUnit) que pondrán en notoriedad el error a corregir.
El error será considerado solucionado cuando la ejecución del test, desarrollado previamente, resulte exitosa.
TDD permite el desarrollo natural e incremental de una suite de test que permiten por un lado la verificación del código desarrollado, y por el otro, la posibilidad de verificar la no regresión frente a las intervenciones al software.
Wiki
Hay varias formas de compartir información, una de ellas con el uso de Wikis, que por su facilidad de instalar, usar, su esencia colaborativa y que sólo se necesita un browser, es la que empleamos en nuestros proyectos.
Cualquier información común debe ser puesta aquí, información pública del proyecto, como requerimientos, guías de diseño, instrucciones de build, notas del progreso, FAQ, HOW-TO, Best Practices, lecciones aprendidas, Tips&Trices, etc.; cualquier cosa que deba ser escrito para que el equipo tome conocimiento.
Las Wiki, por naturaleza, no son estructuradas; es importante que el equipo la emplee con criterio para mantenerla estructurada y de fácil consulta. Es muy recomendable que alguna persona tenga el rol de “jardinero”, para ir controlando y depurando la información generada. Una Wiki no estructurada, o en la que no se encuentre la información fácilmente, perjudica en gran parte sus beneficios.
Figura 4 - Pantalla de un proyecto en la TikiWiki
[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
1 comentario:
Hola me gustaría saber de donde sacaste esa definición de metodología de desarrollo de software, la encunetro ajustada, pero me necesito una referencia para ella.
Atte.
Caroline
Publicar un comentario