Agilidad y Web 2.0

En estos días está de moda hablar de Web 2.0 en relación con casi cualquier cosa, y es que la Web 2.0 puede tener relación con todo lo que el ser humano pueda hacer y comunicar. Yo no quiero desentonar y hablaré de Web 2.0, o más bien, de las metodologías de desarrollo que pueden utilizarse a la creación de una aplicación Web 2.0.

Creo que el problema al que se enfrentan muchas empresas a la hora de querer entrar al mundo de la Web 2.0 es que los enfoques tradicionales y protocolarios son poco eficientes en este nuevo ecosistema.

Si un desarrollo requiere de más de tres meses de levantamiento de requerimientos y unos 6 meses de creación de código, durante los cuales no se hace una modificación a los requerimientos, las cosas podrán ir bien para un proyecto de uso empresarial tradicional como el control de nómina, la administración de la actividad de ventas, etc. Sin embargo, en la Web 2.0 seis meses son una eternidad, en seis meses Google compró alguna empresa y ya ofrece algún otro servicio, Microsoft liberó una nueva aplicación Live, Flikr comenzó a hospedar videos, etc.

Un proyecto Web 2.0 debería realizarse en una metodología que nos permita adaptarnos continuamente

Un proyecto que tenga como destino el escenario Web 2.0 debería realizarse en una metodología que nos permita adaptarnos continuamente, modificar los requerimientos drásticamente y adaptarnos a las otras nuevas tecnologías que otros están creando. Un contexto tan dinámico es el marco ideal para la aplicación de metodologías ágiles como la XP que permiten modificaciones y adaptaciones continuas durante la vida del proyecto.

Una aplicación Web 2.0 es un producto que nunca termina de crearse

Una aplicación Web 2.0 no debería verse como un producto terminado. El entorno de mercado en el que las aplicaciones Web 2.0 se presentan cambia demasiado rápido y un servicio que no se adapta a estos cambios puede quedar rápidamente superado por sus competidores. En este sentido, una aplicación Web 2.0 es un producto que nunca termina de crearse, y la única granularidad administrativa es la que podemos forzar con las versiones del sistema, si es que acaso las tenemos. Pero incluso las versiones pueden ser un problema para una aplicación Web 2.0, si un problema de seguridad es corregido pero no se liberará la corrección hasta la próxima versión, nuestra aplicación continuará con el problema por más tiempo del necesario. Supongamos que, para evitar esto, adoptamos la política de incorporar las modificaciones de seguridad sin esperar a la liberación de una versión, aún así, seguiremos perdiendo oportunidades de mercado por estar esperando la liberación de una versión completa para agregar funcionalidad nueva que, según el momento, pudiera ser crítica en el mercado.

Las metodologías ágiles crean valor sin descuidar las consideraciones presupuestales

Un desarrollo continuo puede parecer demasiado costoso para una empresa, sin embargo, aquí vale la pena pensar en el costo que representa crear una aplicación y dejarla morir con respecto a las ganancias que puede ofrecer un sistema que se adapta con agilidad a las condiciones del mercado. Las metodologías ágiles pueden ayudar en la creación de valor sin descuidar las consideraciones presupuestales del proyecto, pues permiten a la empresa reevaluar continuamente las prioridades del producto y ajustar el plan de desarrollo para asegurar que cada semana de desarrollo está agregando valor real a la aplicación.

Un negocio donde existe una fuerte dependencia en un sistema adaptable y en continuo desarrollo no debería darse el lujo de tardar meses en validar una modificación de requerimientos, o peor aún, de mantener un desarrollo aislado durante meses para comprobar que el sistema ya ha perdido actualidad respecto al entorno de mercado.

Las metodologías son el vehículo del éxito

Las ideas y el valor ofrecido por una aplicación Web son lo que le da su verdadero éxito, pero las metodologías de desarrollo detrás de la aplicación son el vehículo para alcanzarlo, y sólo metodologías que han sido creadas para aceptar modificaciones continuas, incluso en el modelo de dominio, pueden ofrecer un sustento técnico confiable al negocio final.

4 thoughts on “Agilidad y Web 2.0

  1. Saludos.

    Acá hay que diferenciar entre la creación de la funcionalidad inicial y el mantenimiento de la aplicación.

    Cuando se visualiza un nuevo concepto de aplicación, se ha de esperar a tener un primer incremento o prototipo para poder evaluar la idea en funcionamiento y de ahí correr el riesgo de llevarla a producción.

    Luego, el mantenimiento progresivo puede ser la vía para incorporar nuevas ideas o corregir fallos.

    Es decir, que no hay una diferencia metodológica en este tipo de desarrollo. Decir que los métodos ágiles tengan ventaja (por oposición imagino a las aproximaciones tipo RUP) solo se sostiene si se piensa en el modelo de cascada, pero dado que RUP se basa en el modelo en espiral, no veo como valida la sugerencia.

    Sin embargo como cuña publicitaria, vale. Seguro es un concepto que enganchara a muchos.

  2. Iván,

    Cómo ya he dicho en varias ocasiones, no es mi intención desacreditar RUP/UP, sino promover las metodologías ágiles. Espero que perdones mis tendencias evangelistas a favor de una metodología que me gusta y que encuentro, quizá por razones personales, mejor que RUP/UP.

    A pesar de que RUP/UP es una metodología con un fuerte soporte institucional, no me atrevería a llamarla tradicional. En su momento fue una metodología que reunía muchas innovaciones metodológicas y sin duda sigue siendo una vanguardia en el desarrollo de software.

    Sin duda RUP/UP puede usarse para desarrollar aplicaciones Web 2.0, tanto en prototipo inicial como las subsecuentes modificaciones, sólo anoto mi creencia en que las metodologías ágiles pueden adaptarse mucho más rápido por estar menos atadas a procesos documentales y por mantener iteraciones mucho más cortas que RUP/UP (me adelanto a tu crítica reconociendo que en RUP/UP puedes tener iteraciones igualmente cortas, pero estarás de acuerdo en que no es lo común).

    Siendo RUP/UP una metodología iterativa con el compromiso de incrementar el valor real de la aplicación con cada iteración, se puede utilizar como una metodología en entornos de continuos cambios, pero creo que RUP/UP reacciona un poco más lento que las metodologías ágiles, lo que es una ventaja en ciertos casos sobre todo en proyectos grandes, pero una desventaja en otros.

  3. Saludos!

    Ya extrañaba intercambiar opiniones contigo. No es frecuente poder tener discusiones de nivel xD.

    Te compro la idea de evangelizar. Solo que lo he hecho un poquito yo mismo. Mil disculpas por eso.

    Por otra parte, si supieras que la lista de características solicitas de SCRUM (no tengo a la mano el nombre técnico que se le da en scrum) es algo que en verdad veo útil para extender progresivamente una aplicación una vez ya puesta en producción.

    O lo que es lo mismo, que en el animo de tomar lo mejor que este disponible sin importar su origen, algo por lo demás característico de RUP, veo como una próxima adición a mi forma de trabajar el mantener una lista como la de SCRUM, justamente con el mismo propósito, aunque lo veo más en un ambiente de adquisición o customización [sic] de sistemas que en uno de desarrollo de una aplicación completa.

    Si lo asumo, como probablemente pase, será la segunda característica de SCRUM que asuma, ya que actualmente hacemos una versión de la reunión SCRUM para poder vernos las caras y saber que estamos haciendo todos. En nuestro caso dicha reunión es semanal.

    Por otra parte siento que sigo apostando por un esquema más formal, ya que los documentos de especificación y la arquitectura documentada del sistema siguen siendo instrumentos de valor para nosotros. Entonces seguimos siendo RUP/UP, aunque adoptemos buenas prácticas de otros lugares.

  4. Iván,

    En efecto hacen falta siempre las buenas pláticas, sobre todo con gente que piensa distinto. Eso de hablar con quien piensa igual que uno termina por convertirse en un monólogo a dos voces.

    Cada quien tratará siempre de promover aquellas herramientas que cree son útiles a otros, y como dices, lo importante es no cerrar el paso a las sugerencias que pudieran provenir de los demás.

    Aunque no practico como tal el SCRUM, me doy cuenta de que muchas de las prácticas que tenemos durante los proyectos se pueden homologar a las prácticas de SCRUM. Pero siendo SCRUM una herramienta del lado ágil, no voy a presumirlo más.

    De lo que nosotros hemos adoptado desde RUP/UP puedo contar los documentos de casos de uso, que prefiero a las “historias de usuario” o “guiones de usuario” de XP. Sobre todo en su caso detallado, los casos de uso ofrecen una instantánea de las necesidades de negocio en el entorno cultural de la empresa. La versión XP es quizá demasiado resumida y es fácil que quede incompleta, sobre todo cuando es realizada por personas sin mucha experiencia. La versión RUP/UP detallada requiere un análisis más exhaustivo y puede hacerse más apegado a una receta, lo que ayuda al aprendizaje de la técnica. Ya con experiencia podrán adoptar la forma ágil de la XP.

    Las cartas de cambios de requerimientos las hemos tomado del MSF de Microsoft en su versión para metodologías ágiles, que ofrece un documento breve y útil de comunicación con el cliente. Incluso en el caso de proyectos ágiles con XP tratamos de usar esta carta más como una forma de crear una bitácora que para comprobar al cliente el tiempo y costo excedidos debidos a cambios de requerimientos.

    Ya se ve que en este mundo, lo importante es buscar herramientas con las que uno se sienta cómodo sin apegarse a un conservadurismo metodológico.

    Saludos

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s