SCRUM. Una Herramienta de Hiper-Productividad
El problema para los desarrolladores es que los cambios en el software se traducen en problemas, especialmente cuando el error puede “tumbar” el sistema completo. Con Scrum se trata de convertir estos problemas en oportunidades.
Para Rugby, Scrum es la forma de reiniciar el juego, después de una falta menor. En cambio, en desarrollo de software, Scrum es una mejora a las aproximaciones metodologicas incrementales e iterativas, que lo que busca es tener una “caja negra” controlada.
El proceso de desarrollo de software es complejo y complicado. Sobretodo si se requiere alta flexibilidad y control. Para esto, la selección de la metodología juega un papel importante para determinar la probabilidad de éxito en el proyecto. Las metodologías ágiles permiten esta flexibilidad, pero eventualmente pueden tornarse impredecibles e impracticas.
Scrum, tiene como premisa ser una “herramienta hiper-productiva”. Su objetivo primordial es encontrar el máximo de productividad de un equipo de desarrollo. Tratando de reducir al máximo la burocracia y los riesgos generados por las actividades no orientadas a producir software, optimizando al máximo el retorno de la inversión y dando valor agregado en corto tiempo.
Este proceso ágil, tiene varias características, una de ellas es que es un proceso iterativo con iteraciones mensuales en las cuales el cliente interactúa con el equipo para saber que quiere desarrollar. Existen 3 actores en Scrum, uno de ellos es el equipo desarrollador (Scrum Team), que es autogerenciado, y sabe que es lo que va a hacer, el cliente que se llama Product Owner que se encarga de saber que funcionalidades son de alto riesgo para el producto y quiere que sea implementado para la próxima iteración mensual, llamada Sprint. Al inicio de cada Sprint, el equipo se reúne en una Sprint Planning Meeting y en conjunto con el Product Owner prioriza las características a desarrollar del producto que están consignadas en un artefacto llamado Product Backlog. De esta priorización el Scrum Team selecciona la tareas que se van a completar durante el Sprint, y estas tareas son “movidas” del Product Backlog al Sprint Backlog que es un artefacto en el cual se almacenan las actividades del Sprint.
Durante todo el mes, se realizan reuniones diarias al inicio del día, llamadas Daily Scrum Meeting, en las cuales se resuelven los problemas que se tuvieron desde la anterior reunión. Los problemas que se deben resolver en los Daily Scrum se basan en dar respuesta a las siguientes preguntas:
- ¿Que hiciste ayer?
- ¿Que harás hoy?
- ¿Hubo algún impedimento para realizar tu trabajo?
Enfocándose solo en lo que se hizo ayer y lo que se hará hoy, se gana un buen entendimiento de la velocidad con que se desarrolla el proyecto. Esta reunión no es para que un jefe recolecte información de lo que están haciendo los miembros del equipo o quien se esta atrasando. En vez de eso, esta reunión es para que lo miembros hagan compromisos con los otros miembros y haya una buena comunicación en el equipo, es decir, alinear a las personas hacia una misma dirección. Esta reunión es coordinada por el tercer actor, el Scrum Master, que (y espero se entienda bien), no es un director de proyectos, es el líder del equipo que se encarga de que los miembro del equipo se compenetren con las practicas y valores de Scrum, vela para que el equipo no se comprometa con cosas que puede cumplir durante el Sprint, además de facilitar y ser responsable de remover cualquier obstáculo que el equipo reporta en las reuniones diarias.
A pesar de que Scrum parece ser un proceso simple, para medianos y pequeños proyectos, no nos podemos dejar engañar. Solo un tercio de las empresas que adoptan Scrum logran implementarlo con éxito. Y no es porque Scrum no sirva, es porque realmente es difícil de implementar, debido a que las organizaciones están estructuradas para construir software de forma tradicional en la cuales los equipos son controlados y comandados por alguien que les dice que hacer, mientras que Scrum requiere de equipos autogerenciados, además de los roles funcionales contra los equipos ínter funcionales con la capacidad de entregar productos al cliente de forma mas rápida. En resumen, es difícil de implementar porque requiere un cambio de hábitos que se han mantenido a lo largo de los años, esto es algo con lo que las organizaciones deben lidiar. Pero la forma de afectar esto es crear cultura, empezando con un equipo a trabajar y ver que no se esta trabajando con un batallón militar, sino como equipo colaborativos, con personas que están pensando como resolver problemas conjuntamente, cuando los otros equipos vean esta forma de trabajar, van a querer saber que esta haciendo ese equipo para ser productivo, y eventualmente los cliente se van a dar cuenta que se le esta entregando software cada mes y va a querer saber como se trabaja y va a integrarse al proceso, y al final toda la organización va a estar trabajando con esta herramienta altamente productiva.
AJAX, el ¿que?, y ¿donde?
Desde hace varios años, los clientes siempre nos han preguntado como hacer para que una aplicación Web tenga la misma facilidad de respuesta y versatilidad de una aplicación de escritorio.
Debido a la simplicidad de las aplicaciones Web, existe una brecha entre estos 2 tipos de aplicaciones.
Esta brecha se está cerrando, con las nuevas tecnologías y los avances en los nuevos navegadores en la Web, podemos lograr una mayor y mejor experiencia para los usuarios de nuestras aplicaciones.
Así como LAMP o SPA ha surgido un nuevo conjunto de tecnología llamado AJAX, que representa un cambio fundamental en lo que es posible hacer en las aplicaciones Web.
Que es?
Ajax no es un framework, ni una nueva tecnología, ni un API. Es realmente un conjunto de tecnologías existentes desde hace varios años, pero que antes se usaban independientemente, y que ahora en conjunto ofrecen nuevas formas de trabajo para las aplicaciones Web.
AJAX es la abreviatura de Asynchronous JavaScript and XML (ingles para Javascript Asíncrono y XML), y esta compuesto por tecnologías como Hojas de Estilo en Cascada y XHTML, DOM (Documento Object Model), XML y XSLT, XMLHttpRequest, y Javascript.
Comúnmente, las aplicaciones Web funcionan con un esquema petición-respuesta, en donde las acciones del usuario disparan peticiones HTTP al servidor. El servidor realiza algún procesamiento y retorna una respuesta HTML al cliente.
Esto requiere que el usuario tenga que esperar hasta que se pinte la pantalla cada vez que la aplicación requiere algo del servidor.
Con una aplicación con AJAX, logramos eliminar esta característica propia de las aplicaciones Web. Aquí se introduce un componente mas entre el servidor y el usuario, el motor Ajax. Al inicio de una sesión, se carga el motor Ajax, en un frame oculto, el cual se encarga de pintar la interfaz y de enviar y recibir peticiones del servidor. Ajax muestra un esquema de interacción con el servidor de la siguiente manera
A grandes rasgos la interacción es similar al esquema clásico; la diferencia radica en el concepto de Asincronía, que permite hacer las peticiones sin requerir que el usuario vea que la pantalla se tiene que pintar nuevamente, algo antes hecho usando DHTML, y mostrado en el framework UIX de Oracle que le dio el nombre de Partial Page Rendering.
¿Donde y Cuando?
Como toda tecnología nueva, no debemos correr a implementarla en todos los proyectos, solo por estar a la moda, existen ciertas características que deben tener las aplicaciones para poder obtener las mayores ventajas de Ajax.
Debido a que Ajax es un conjunto de tecnologías y no un framework, el uso de este al inicio del proyecto, en un proyecto ya existente o en fases de mantenimiento es viable, siempre y cuando se tengan las siguientes características en las aplicaciones:
- Interacción basada en Formas.
La naturaleza de los formularios es que son lentos, todos requieren que se envíe la petición al servidor y que regrese la respuesta. Con AJAX las validaciones son en línea y los cambios pueden ser vistos instantáneamente.
- Menús de Selección
Es una variante de los formularios. Si tenemos un menú de selección como de países y departamentos, la lista de departamentos puede ser generada dinámicamente sin requerir que se pinte toda la pantalla.
- Navegación con Árboles Jerárquicos.
Las aplicaciones con menús tipo árbol son muy complejas. Se pueden hacer con DHTML y cargar todo el menú en Javascript lo que lo hace pesado, o se puede hacer dinámico, pero pintando toda la pagina. Con AJAX se puede recuperar desde el servidor la parte del árbol que se requiere y solo actualizar esa parte del menú.
- Comunicación P2P rápida – chats.
Antes los chats si no eran hechos con tecnologías como Applets, no se podían tener notificaciones inmediatas a menos que se pintara la página cada cierto tiempo. Con AJAX podemos hacer las actualizaciones del Chat mucho más rápido porque no hay que pintar todos los mensajes anteriores. Ej.: GMail con Gtalk integrado.
- Votaciones, Encuestas
Con AJAX se puede tener el resultado de las votaciones, inmediatamente después de hacer el envío de la elección hecha.
- Manipulación de datos y filtros.
Cuando se trabaja con tablas de datos, que pueden requerir ordenamiento o filtros, no es necesario ir al servidor. Esta puede ser hecha con AJAX para que sea mucho más rápido.
- Auto completar y texto comúnmente ingresado.
Si siempre se ingresa la misma frase o tener texto predictivo es muy útil en las aplicaciones Web y esto puede ser logrado con AJAX, como en Google Suggest.
- Errores Interactivos.
El proceso de entrada de datos puede ser muy rápido si con AJAX se hacen las validaciones inmediatamente después de que el usuario ha ingresado un dato, sin necesidad de terminar todo el formulario.
- Queries muy grandes – Web Services (Llamados Remotos).
Los llamados a Web Services que tomen mucho tiempo, pueden ser manejados con AJAX, los usuarios no tienen que esperar a que el Web Service responda para seguir trabajando en la aplicación.
- Operaciones Computacionales Costosas.
Javascript es muy lento para realizar operaciones matemáticas. Con AJAX, todas estas operaciones pueden ser hechas en el servidor y mostrar el resultado inmediatamente sin el tiempo de latencia de pintar el resultado.
Cuando NO? Riesgos?
Hasta ahora se han identificado 3 riesgos potenciales al momento de utilizar AJAX. Estos son inherentes al procesamiento asíncrono y a las tecnologías que hacen posible este tipo de procesamiento.
- Compatibilidad de Javascript.
Javascript siempre ha tenido problemas de compatibilidad con los distintos browsers. Esto puede ser un riegos si el aplicativo va dirigido a varios navegadores, pero puede ser evitado con algo de esfuerzo al hacer las librerías AJAX o con un cross-browser AJAX framework.
- Compatibilidad de los Bookmarks (Favoritos)
Al igual que los frames, cuando se trabaja con AJAX y con páginas dinámicamente generadas, existe el problema que no se puede hacer bookmark de la página generada porque la URL puede llevar a un lugar no deseado.
- Compatibilidad del botón regresar.
AJAX rompe la funcionalidad del botón regresar, porque el histórico es dinámicamente generado. Si el usuario requiere este botón hay que tener mucho cuidado al usar AJAX. Existen scripts que permiten evitar este problema.
- Múltiples peticiones.
Si tenemos un script que vaya muchas veces al servidor usando AJAX, se debe tener en cuenta el número de usuarios que usaran el aplicativo, ya que estos multiplicarán el número de peticiones y pueden generar indisponibilidad del servidor.
Como vimos, al igual que cualquier tecnologia, Ajax tiene sus ventajas y desventajas. Igualmente debe ser usado en ciertos tipos de aplicaciones y para en algunos casos. Podemos esperar que Ajax mejore los tiempos de respuesta de una aplicación, como un plus al objetivo inicial, que es mejorar la experiencia del usuario.
