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.

sábado, 23 de febrero de 2008

Metodos Agiles y Disciplinados

By Lionel Barrabino and Leonardo Miaton (2007)

Todas las empresas aspiran a incrementar su competitividad, produciendo más rápido, mejor y con menores costes lo que implica una mejora o evolución continua de sus procesos de desarrollo de software.


En un primer momento las notaciones de modelado y posteriormente las herramientas, pretendieron ser “La Solución" para el éxito en el desarrollo de software. A fines de los noventa había ya gran cantidad de tipos de procesos y modelos. Algunos de los más relevantes eran el modelo en cascada o lineal-secuencial, su variante con fases superpuestas, el de construcción de prototipos, el de desarrollo rápido (RAD), el incremental, el modelo en espiral básico, el de desarrollo concurrente, modelos iterativos o evolutivos (basados en componentes, por ejemplo) y otra gran cantidad de variantes, donde cada una se originaba a partir de la crítica o en la percepción de las limitaciones de otra.

Sin embargo, las expectativas no fueron satisfechas. Esto se debía, en gran medida a que las metodologías de desarrollo no habían evolucionado. Poco sirven las buenas notaciones y herramientas si no se proveen marcos para su aplicación. Así, en los últimos diez años, organismos y corporaciones han desarrollado gran cantidad de estándares de metodologías de desarrollo: Modelo de Madurez de la Capacidad (CMM), derivaciones de ISO9000, BootStrap, TickIt, SDCE, Trillium...

Articulo completo para descargar.

Patterns for Personalized Web Applications

By Daniel Schwabe, Gustavo Rossi, Juan Danculovic and Leonardo Miaton. Proceedings of EuroPLoP 2001

Abstract: In this paper we present some patterns we mined in Web applications that present some kind of personalized structure or behavior. We first introduce the growing need to include personalization features in Web applications and present a taxonomy for reasoning about design structures for personalization. Finally, we present 4 personalization patterns: Link Personalization, Content Personalization, Structure Personalization and Remote Personalization.
View or download: www.lifia.info.unlp.edu.ar/papers/2001/Schwabe2001b.pdf

Putting Hypermedia Patterns to Work: a Case Study

By Fernando D. Lyardet, Barbara Mercerat, Leonardo Miaton. (1999)

Abstract: This paper we present an example of a redesign of an existing website using OOHDM methodology and how patterns helped to easily improve a website by correctly identifying the different design issues. Scenario: a government website for small companies program.

View or download: uts.edu.au/~dbl/Hy...etHT99Workshop.pdf