martes, 12 de agosto de 2008

Colaboración entre iguales

(Pensamientos)

Está produciendose un cambio esencial en el modo de canalizar la capacidad de innovación y creación de valor que tienen las empresas. Las empresas inteligentes y multimillonarias reconocen que la innovación suele iniciarse en la periferia del sistema. Cada vez más, estas empresas jerárquicas están recurriendo a modelos de redes de negocios basados en la colaboración y la auto-organización, donde masas de consumidores, empleados, proveedores, socios e, incluso, competidores crean valor cooperando, sin el control directo de una dirección. Esto tiene que ver con el coste cada vez mas reducido de la colaboración....

La era de la inteligencia interconectada en red es una era de oportunidades. No se trata sólo de la interconexión en red de la tecnología, sino de la interconexion en red de los seres humanos mediante la tecnología. No es una era de maquinas inteligentes, sino de seres humanos que, mediante redes, combinan su inteligencia, conocimiento y creatividad para conseguir avances en la creación de riqueza y el desarrollo social. Es una era de nuevas y enormes oportunidades, con un potencial inimaginable.

Pensemos en la investigación científica. En el pasado, los científicos trabajaban con una supercomputadora muy potente, por ejemplo, para simular los mecanismos de una membrana celular biológica como recurso que les permitía comprender la estructura de las moléculas biológicas. Sin embargo, a medida que las redes van invadiendo el planeta, es posible unir de forma simultánea los ordenadores de todas partes del mundo para atacar el problema.
En lugar de un único ordenador caro que presta apoyo a un solo grupo de científicos, es posible interconectar una red global de ordenadores para prestar apoyo a grupos de científicos distribuidos. La red se transforma en un ordenador, infinitamente mas potente que una sola maquina. Y la inteligencia humana interconectada en red se aplica a la investigación, creando así un orden mas elevado de pensamiento, conocimiento --y, tal vez, incluso una conciencia interconectada en red--- entre las personas.

Idéntica interconexion puede aplicarse a los negocios y a casi todos los demas aspectos de la iniciativa humana: aprendizaje, asistencia sanitaria, trabajo, entretenimiento.

La interconexion en red puede transformar la inteligencia de una empresa al incorporar el know-how colectivo para que influya en la resolución de problemas y la innovacion. Al abrir en forma espectacular los canales de comunicación humana, es posible que la conciencia se amplíe y pase de los individuos a las organizaciones? Las organizaciones inconsistentes, como las personas, no aprenden. Si adquieren conciencia, las organizaciones pueden ser capaces de aprender y eso es una condicion previa para la supervivencia. La inteligencia interconectada en red es el eslabón perdido del aprendizaje de las organizaciones y la organización consciente puede construir la base para lograr organizaciones que aprenden, tan difíciles de conseguir. Y, tal vez, la inteligencia interconectada en red pueda extenderse mas allá de las organizaciones para crear una toma de conciencia mas amplia --la conciencia social--- en las comunidades, las naciones y otras entidades mas amplias.

Para las empresas inteligentes, la creciente oleada de colaboración masiva ofrece enormes oportunidades. Las empresas pueden salir de sus cuatro paredes para sembrar las semillas de la innovacion y recoger una abundante cosecha. De hecho, las empresas que entablan unas relaciones agiles y basadas en la confianza con colaboradores externos están bien posicionadas para construir unos ecosistemas empresariales muy activos que crean valor con mayor eficacia que las empresas organizadas jerarquicamente.

Esta nueva forma de innovacion y creacion de valor se la denomina comúnmente "producción entre iguales" y describe lo que ocurre cuando masas de personas y empresas colaboran abiertamente para potenciar la innovacion y el crecimiento en sus sectores.

La produccion entre iguales, en su forma mas pura, constituye una manera de producir bienes y servicios basada completamente en la autoorganizacion y en comunidades igualitarias de individuos que se unen de forma voluntaria para producir un resultado compartido. En realidad, la producción entre iguales combina elementos de jerarquía y autoorganizaicon, y se fundamenta en principios meritocraticos de organización; en otras palabras, los miembros mas cualificados y con mas experiencia asumen el liderazgo y ayudan a integrar las aportaciones de la comunidad.
En muchas comunidades de producción entre iguales, las actividades productivas son voluntarias y no reportan beneficios monetarios. Son voluntarias en el sentido de que las personas hacen contribuciones a esas comunidades porque quieren y porque pueden. Nadie ordena a un trabajador que publique un articulo en Wikipedia o que aporte código al sistema operativo Linux. No reportan beneficios monetarios porque la mayoría de los participantes no se les paga por las contribuciones que hacen (al menos, no en forma directa) y los individuos determinan si quieren producir, qué producen y qué cantidad quieren producir. Sin embargo, que la gente no reciba un dinero por participar en producción entre iguales no implica que no se beneficien de otras maneras.

Por lo pronto, la producción entre iguales aprovecha motivaciones voluntarias de una manera que propicia la asignación de la persona adecuada a la tarea adecuada con mayor eficacia que las empresas tradicionales. La razón es la auto selección.

Normalmente, las comunidades de productores suelen utilizar "licencias publicas generales" para garantizar a los usuarios el derecho a compartir y modificar obras de creación siempre que se comparta con la comunidad cualquier modificación introducida.

Las personas participan en comunidades de producción entre iguales por una amplia variedad de motivos intrínsecos y de interés propio.
Ya sea por diversión, altruismo, obtener stutus dentro de la comunidad para aspirar crecimiento profesional, etc etc

Este tipo de producción funciona cuando se cumplen tres condiciones mínimas:
  1. El objeto de la producción es información o cultura, una circunstancia que mantiene a un nivel bajo el coste de participación para las personas que contribuyen,
  2. las tareas pueden descomponerse en porciones reducidas que los individuos pueden aportar con pequeños incrementos y con independencia de los demás productores (a saber, entradas de una enciclopedia o componentes de un programa informático) y
  3. el coste de combinar esas porciones para obtener un producto final terminado, incluyendo aquí el liderazgo y los mecanismos de control de calidad, debe ser bajo.
En definitiva, la producción entre iguales funciona porque pueden hacerlo.

(Gracias a Don y Anthony)

viernes, 25 de julio de 2008

Negocios en tercera dimensión

Mucho se ha dicho acerca de la participación de las empresas en Second Life. Lo que en un principio fue un furor, el lugar clave donde "había que estar", hoy tiene algunas miradas escépticas y empieza a despertar desconfianza. Están quienes dicen que las empresas tienen sus locales vacíos, que no hay nadie que los atienda, y que incluso algunas ya piensan en abandonar este espacio.

Second Life, el mundo virtual creado por la empresa Linden Lab, donde las compañías pueden adquirir parcelas de tierra para construir oficinas, salas de conferencias y jardines, fue concebido en un primer momento como un espacio para reforzar el marketing de las compañías. Las noticias acerca de lo que pasaba en esta segunda realidad repercutían luego en el "mundo real", por lo que para tener resonancia en el mercado parecía fundamental formar parte de este juego.

Pero, como suele pasar con todo "boom mediático", Second Life también dejó de ser noticia, y desde las áreas de Marketing se dejó de concebir como el lugar donde "había que estar".

Sin embargo, y más allá de las críticas, hay quienes siguen apostando a esta segunda realidad, utilizando las herramientas que presenta con fines diferentes a la mera visibilidad de la empresa. Así, hay universidades que dictan clases aquí, e incluso ciudades que son sedes de conferencias, para dar algunos ejemplos.

Quienes participamos de este espacio virtual, nos encontramos con infinitas posibilidades para unificar personas y equipos laborales que se encuentran en distintas oficinas, ciudades o países. De este modo, podemos ingresar a un lugar de colaboración, donde se puede trabajar en conjunto con gente que está físicamente distribuida en lugares diversos.

Es cierto que una reunión realizada a través de Second Life puede no tener la calidad de una teleconferencia. Sin embargo, este espacio cuenta con un ambiente completo, realizado con tecnología 3D, donde uno tiene imagen, audio y texto, y que puede resultar muy viable para conectar más de dos puntos. Del mismo modo, puede resultar un espacio interesante para hacer una capacitación a distancia.

A su vez, para las empresas de servicios, Second Life puede resultar una herramienta adicional para mostrar a sus clientes prototipos y simulaciones de proyectos en marcha.

Por lo tanto, es probable que el éxito o fracaso de las empresas dentro del este mundo virtual pase por el encontrar estas vetas y oportunidades que la interoperabilidad a través de la tecnología en 3D ofrece y, una vez descubiertas, hallar el modo de explotarlas al máximo.

martes, 8 de julio de 2008

Conclusión de un Sabio anónimo

"Como la velocidad de la luz es mayor que la del sonido, ciertas personas parecen brillantes antes... de que escuchemos las pelotudeces que dicen."

Edicion en español: :D
"
Como la velocidad de la luz es mayor que la del sonido, ciertas personas parecen brillantes antes... de que escuchemos las gilipolleces que dicen."

miércoles, 5 de marzo de 2008

Inteligencia interconectada en red, era de oportunidades

No es sólo la interconexión en red de la tecnología, sino de la de los seres humanos mediante la tecnología. No es una era de maquinas inteligentes, sino de seres humanos que, mediante redes, combinan su inteligencia, conocimiento y creatividad para conseguir avances en la creación de riqueza y el desarrollo social.

Éste cambio esencial en el modo de canalizar la capacidad de innovación y creación de valor que tienen las empresas, la oleada de colaboración masiva ofrece enormes oportunidades. Las empresas pueden salir de sus cuatro paredes para sembrar las semillas de la innovación y recoger una abundante cosecha. De hecho, las empresas que entablan unas relaciones ágiles y basadas en la confianza con colaboradores externos están bien posicionadas para construir unos ecosistemas empresariales muy activos que crean valor con mayor eficacia que las empresas organizadas jerárquicamente.

Esta nueva forma de innovación y creación de valor se denomina producción entre iguales y describe lo que ocurre cuando masas de personas y empresas colaboran abiertamente para potenciar la innovación y el crecimiento en sus sectores. En su forma más pura, constituye una manera de producir bienes y servicios basada completamente en la autoorganización y en comunidades igualitarias de individuos que se unen de forma voluntaria para producir un resultado compartido. En realidad, la producción entre iguales combina elementos de jerarquía y autoorganización, y se fundamenta en principios meritocraticos de organización; en otras palabras, los miembros más cualificados y con más experiencia asumen el liderazgo y ayudan a integrar las aportaciones de la comunidad.

En muchas comunidades de producción entre iguales, las actividades productivas son voluntarias y no reportan beneficios monetarios. Son voluntarias en el sentido de que las personas hacen contribuciones a esas comunidades porque quieren y porque pueden. Nadie ordena a un trabajador que publique un artículo en Wikipedia o que aporte código al sistema operativo Linux. No reportan beneficios monetarios porque la mayoría de los participantes no se les paga por las contribuciones que hacen (al menos, no en forma directa) y los individuos determinan si quieren producir, qué producen y qué cantidad quieren producir. Sin embargo, que la gente no reciba un dinero por participar en producción entre iguales no implica que no se beneficien de otras maneras.

Por lo pronto, la producción entre iguales aprovecha motivaciones voluntarias de una manera que propicia la asignación de la persona adecuada a la tarea adecuada con mayor eficacia que las empresas tradicionales. La razón es la auto selección.

Las personas participan en comunidades de producción entre iguales por una amplia variedad de motivos intrínsecos y de interés propio, ya sea por diversión, altruismo, obtener status dentro de la comunidad para aspirar crecimiento profesional, etc etc.
Este tipo de producción funciona cuando se cumplen tres condiciones mínimas:
  1. El objeto de la producción es información o cultura, una circunstancia que mantiene a un nivel bajo el coste de participación para las personas que contribuyen,
  2. las tareas pueden descomponerse en porciones reducidas que los individuos pueden aportar con pequeños incrementos y con independencia de los demás productores (a saber, entradas de una enciclopedia o componentes de un programa informático) y
  3. el coste de combinar esas porciones para obtener un producto final terminado, incluyendo aquí el liderazgo y los mecanismos de control de calidad, debe ser bajo.
En definitiva, la producción entre iguales funciona porque pueden hacerlo.

Esto es lo que está sucediendo ahora, no sabemos cómo evolucionará, la velocidad y la forma que tomará. De seguro, aportará muchos beneficios para todos y no será una bala de plata universal.

(Nota: Varias partes han sido tomadas del libro Wikinomics de Don Tapscott)

martes, 26 de febrero de 2008

Buenas practicas - lecciones aprendidas en la especificaciones de requerimientos

Definición
Un requerimiento es la condición o capacidad que necesita el usuario para resolver un problema o alcanzar un objetivo. Es la condición o capacidad que debe satisfacer o poseer un sistema o una componente de un sistema para satisfacer un contrato, un standard, una especificación u otro documento formalmente impuesto [IEEE610].

Recomendaciones / sugerencias para el documento de requerimientos
"
La experiencia es la mejor escuela para escribir requerimientos adecuados"
- Wiegers
  • Oraciones con gramática, sintaxis y puntuación adecuada
  • Oraciones cortas y directas
  • Voz activa, imperativos: "el sistema debe hacer algo" y no "algo debe hacerse"
  • Usar los términos consistentemente y de acuerdo a la definición del glosario
  • No use sinónimos: no varíe el lenguaje para atraer al lector
  • Descomponga un requerimiento de alto nivel en detalle suficiente para clarificarlo y eliminar la ambigüedad
  • Use una forma consistente de redactar: "el sistema debe"+verbo
  • Especifique la acción que dispara el comportamiento del sistema
  • Evite el "debería", "podría" y condicionales
  • En "El usuario debe..." especifique al usuario: "El cajero debe..."
  • Presente información visualmente, las masas de texto no ayudan
  • Enfatice la información más importante
Términos ambiguos y su modificación
Término ambiguoFormas de mejorarlo
aceptable, adecuadoDefina qué constituye la aceptabilidad y cómo el sistema la juzga
tanto como sea practicableNo deje en manos de los desarrolladores determinar qué es practicable.
al menos, como mínimo, no más que, no excederEspecificar los valores mínimos y máximos aceptables
EntreDefina si los puntos extremos están o no en el rango
depende deDescriba la naturaleza de la dependencia. ¿Otro sistema provee input a este sistema, debe instalarse otro sistema antes que su sofwtware sea ejecutado o su sistem depende de otro para ejecutar algún cálculo o servicio?
EficienteDefina como el sistema usa eficientemente recursos, cuan rápidamente ejecuta operaciones o como es de fácil para la gente usarlo
rápido, velozEspecifique la mínima velocidad aceptable a la que el sistema ejecuta alguna acción
FlexibleDescriba las formas en la que el sistema debe cambiar en respuesta a condiciones cambiantes o necesidades del negocio
mejorado, mejor, más rápido, superiorCuantifique cuanto mejor o más rápido constituye una mejora adecuada en un área funcional específica
incluyendo, incluyendo pero no limitado a, y así sucesivamente, etc. tal comoLa lista de ítems debería incluir todas las posibilidades. De otro modo no podría usarse para diseño o testeo
maximice, minimice, optimiceEstablezca los valores máximo y mínimo aceptable para algún parámetro
normalmente, idealmenteDescriba también el comportamiento del sistema bajo condiciones anormales o no-ideales
OpcionalmenteClarifique si se trata de una opción del sistema, del usuario o del desarrollador
razonable, cuando es necesario, donde sea apropiadoExplique como se produce este juicio
RobustoDefina como el sistema maneja las excepciones y responde a condiciones operacionales no esperadas
transparente, suave, grácilTraduzca las expectativas del usuario en caracterísrticas observables del producto
VariosEstablezca cuantos o proveea las cotas mínima y máxima del rango
no deberíaEstablezca los requerimientos positivos, diciendo que hará el sistema
estado del arteDefina qué significa
SuficienteExplique con cuanto de algo se establece la suficiencia
soporte, disponibleDefina exactamente que funciones debe ejecutar el sistema que soporten alguna capacidad
Amistoso, fácil, simpleDescriba las características del sistema que alcanzarán las necesidades de uso del usuario y las expectativas de usabilidad

Características de una buena especificación de requerimientos - factores de calidad de una especificación de requerimientos
  • Correcta
  • No ambigua
  • Completa
  • Consistente
  • Rankeada / Clasificacion por importancia
  • Verificable
  • Modificable
  • Traceable
  • Independiente del diseño
  • Concisa / Breve
  • Organizada
  • Anotada
Correcta
Una especificación de requerimientos es correcta "sí y sólo si todo requerimiento formular en ella es uno que el software debe satisfacer"

No ambigua
Una especificación de requerimientos no es ambigua "sí y sólo si todo requerimiento formulado en ella tiene una sola interpretación".
Ello requiere que al menos cada característica del producto final se describa con un único término.
Debe evitarse toda afirmación ambigua:
"Todos los clientes tienen el mismo campo de control"
"Todos los archivos son controlados por un bloque de control de archivo"
El lenguaje natural es fuente de ambigüedades.

Completa
Una especificación de requerimientos es completa "sí y sólo si incluye los siguientes elementos:
Todos los requerimientos significativos que impone al software
Todas las respuestas del software a todas las clases posibles de inputs
Todas las etiquetas y referencias a las figuras, tablas y diagramas de la especificación de requerimiento y las definiciones de los términos y unidades de medida"
Este atributo es el más difícil de definir y detectar violaciones, por lo que hay que dedicarle tiempo y trabajar a conciencia.

Consistente
(Hablamos de consistencia interna)
Una especificación de requerimientos es internamente consistente sí y sólo si ningún subconjunto de requerimientos está en conflicto.
Tipos de inconsistencias
Comportamiento conflictivo: dos partes especifican diferentes y conflictivos: estímulos para inducir una respuesta, respuestas a un mismo estímulo y condición.
Términos conflictivos: dos términos diferentes se utilizan para definir lo mismo
Características conflictivas: dos partes requieren rasgos contradictorios
Inconsistencia temporal: dos partes requieren comportamientos temporales contradictorios.

Rankeada / Clasificacion por importancia
Que cada requerimiento tenga una identificación que indica la importancia. Se los puede clasificar, por ejemplo, en "Esenciales" (el software no es aceptable sin éstos), "Condicionales" (pueden mejorar el software, pero no es inaceptable si está ausente) u "Opcionales" (esa función puede o no estar presente).
Que cada requerimiento tenga una identificación de la estabilidad. La estabilidad se puede expresar en términos del número de cambios que se esperan.

Verificable
Todo requerimiento incluido en ella es "verificable", es decir que exista un proceso finito y efectivo en costo con el que chequear que el sistema a construir satisface el requerimiento.
En general los requerimientos ambiguos no son verificables.
Ejemplos de requerimientos no verificables:
- El producto debe trabajar bien
- El producto debería tener una buena interfase
- El programa no debe entrar nunca en un loop infinito
- El output del programa debe estar habitualmente dentro de los 10 segundos
Ejemplos de requerimientos verificables
- A partir de producido el evento X, se obtendrá el output del proceso: debe estar dentro de los 20 segundos el 60% de las transacciones y dentro de los 30 segundos el 99% de las transacciones.
- Algunas de las fuentes de no verificabilidad son las ambigüedades, problemas no resolubles y cantidades no medibles.

Modificable
Cualquier cambio puede hacerse: fácilmente, manteniendo la "completitud" y consistentemente.
Requiere tener una organización coherente y fácil de usar, no ser redundante.

Traceable / Rastreable
Si es claro el origen de cada requerimiento y facilita la referencia de cada requerimiento en futuros desarrollos o mejoras de la documentación.
Tipos de rastreabilidad: hacia delante y hacia atrás.
Beneficios:
- Importancia en operaciones y mantenimiento
- Claridad del origen de cada requerimiento
- Facilita negociar los requerimientos
- Facilita referenciar cada requerimiento individual establecido en la especificación de requerimientos

Independiente del diseño
No debe implicar una arquitectura específica de software o algoritmo, dado que no se debe limitar a esta instancia de una única alternativa de diseño. Hay excepciones aceptables.

Concisa / Breve
A igualdad de cualidades, la mejor es la mas corta

Organizada
Una especificación de requerimientos es organizada si los requerimientos que contiene son fácilmente localizables

Anotada
Las anotaciones a una especificación de requerimientos proveen guía al desarrollo de la organización del documento. Hay dos casos de anotaciones requeridas: necesidad y estabilidad

Tipos de requerimientos según las capacidades o características

Necesidades
: Capacidades o características requeridas al sistema de software para resolver el problema. Posibles formas:
Funcionalidad
Comportamiento del sistema
Performance, tiempo de respuesta
Necesidades operacionales
Características de las interfaces de hw y sw.

Deseos: Capacidades o características de un sistema de software deseadas por los stakeholders, no son imprescindibles para resolver el problema. Posibles formas:
Funcionalidad extra
Comportamientos específicos del sistema
Características de la interfase del usuario
Algoritmos particulares

Expectativas: Capacidades o características del sistema de software esperadas por los stakeholders. A menudo no explícitas, y por ello se pierden fácilmente. Posibles formas:
Aspectos específicos del dominio, funcionalidad
Confiabilidad
Características de la interfase con el usuario
Características de performance

Referencias
[IEEE610] Definición IEEE-Std-610 (1990)

lunes, 25 de febrero de 2008

Snoop Update 08 - Evento para desarrolladores (Argentina)

El 16 de abril de 2008 en el Paseo La Plaza (Buenos Aires, Argentina) se realizará uno de los eventos mas importantes de Argentina para desarrolladores y técnicos. El evento tiene como objetivo difundir los últimos avances en la tecnología de Software. Algunos motivos por los que vale la pena asistir al evento:
  • Tiene contenidos especializados.
  • Las presentaciones no responden a un fabricante de software en particular (son “agnósticas”)
  • Esta pensado para transmitir conocimiento.
  • Los contenidos son de uso práctico. Contenidos específicos y de utilidad práctica.
  • Brinda capacitación a los asistentes.
  • Será acorde a la realidad del mercado local (Argentina)
  • Sesiones paralelas de tecnología y desarrollo a cargo de los líderes y personalidades de la industria.
  • Contarán con personalidades de reconocimiento internacional, como en los eventos anteriores.
  • Y no menos importante, el evento es Gratuito, solo tienes que registrarte en su Web.
En paralelo con este evento, se está organizando el UPDATE 4 CIO'S, un espacio en donde se expone cómo la tecnología de la información satisface las necesidades actuales de los negocios, a través de flexibilidad y adaptación. Esta conferencia se reunirán los referentes de la industria para compartir sus experiencias sobre las últimas tendencias del mercado de IT. Mas información: Snoop Update 08

domingo, 24 de febrero de 2008

Practicas ágiles en contextos distribuidos (Parte 2)

Introducción

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
Múltiples vías de comunicación

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.

Gestión del Team

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

Practicas ágiles en contextos distribuidos (Parte 1)

Introducción

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.
Offshore: Consecuencias

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
¿Offshore: pueden ayudar las practicas ágiles?

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
En la próxima entrega se explicarán:
  • 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
Distributed Continuous Integration

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)
Esta practica no siempre es posible implementarla, todo depende de cómo este constituido el equipo onsite.

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


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


Java vs .Net

By Esteban Lorenzano and Leonardo Miaton (Enero 2007)

El lenguaje Java surgió en 1997 enfocado, fundamentalmente, al creciente mundo de Internet a través de los applets. Sin embargo, no fue hasta que pasó del lado del cliente al del servidor que adquirió verdadera importancia.
Las emergentes tecnologías orientadas a producir contenidos dinámicos (concretamente los “Servlets” y luego los “JSPs” ), permitieron crear un conjunto de componentes para el desarrollo de aplicaciones completas que se ejecutan del lado del servidor, enviando al cliente únicamente el resultado de las operaciones realizadas.
En este sentido, fue fundamental el enfoque original de la plataforma Java: "write once, run anywhere" (‘escribe una vez, corre en cualquier lado’) que permitió que los servidores de aplicaciones Java funcionen en las más variadas infraestructuras. Hay versiones de Java para prácticamente cualquier sistema operaoperativo/hardware actuales (IBM AIX, HP-UX, Solaris, Linux, Windows, etc.)
.NET, por su parte, surgió en 2001 como la respuesta de Microsoft a la creciente popularidad de Java y sus arquitecturas para el desarrollo de aplicaciones empresariales web, beneficiándose de la experiencia de Java, pero añadiéndole características propias. A diferencia de su competidor, el enfoque que .NET sigue, es la interoperabilidad e intercambiabilidad de los lenguajes en los que se escriben las aplicaciones. Es decir: se puede escribir en varios lenguajes, que incluyen C++, Visual Basic, Java y el nuevo lenguaje de Microsoft, C#.
A continuación, basados en el creciente interés del mercado informático, realizaremos un análisis comparativo de las fortalezas y debilidades de ambas, en cuanto a modelo de ejecución y arquitectura de aplicaciones.

Articulo para descargar.