II.4.3 Por qué utilizar Scrum para desarrollar aplicaciones web

En general, las aplicaciones Web cumplen la mayor parte de las características que se mencionan en el epígrafe II.2.2, por lo que la utilización de procesos ágiles podría ser ventajoso para este tipo de desarrollos. La necesidad del cliente que contrata un desarrollo Web es que su producto esté disponible en la red lo más pronto posible. Si no se tiene en cuenta esta necesidad, la aplicación no resultará un producto provechoso para el cliente. Puesto que los procesos ágiles permiten tener versiones de producto previas a la versión final, si se aplican correctamente estos procesos el cliente podrá disponer de forma rápida de alguna versión intermedia. Además el ciclo de desarrollo de la mayoría de los sitios y aplicaciones Web es extremadamente corto [47]. Por otra parte, los desarrollos Web se perciben como desarrollos sencillos y los desarrolladores son sometidos a una gran presión de trabajo para terminar lo más pronto posible. Esta forma de trabajar implica, sin duda alguna, modificaciones. Luego sería conveniente garantizar un proceso de desarrollo adaptable a los cambios. Otra cuestión fundamental a tener en cuenta es que las aplicaciones Web se desarrollan sin conocer los perfiles de los usuarios finales de las mismas, o lo que es lo mismo sin conocer los requisitos de usuario del sistema. Sin lugar a dudas esto implicará cambios en los requisitos inicialmente detectados, lo que lleva de nuevo a la elección de un proceso adaptativo.

Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores prácticas para trabajar en equipo y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

En esta metodología se realizan entregas parciales del resultado final del proyecto, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad y la productividad son fundamentales.

Aunque Scrum surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software, y donde al aplicarlo proporciona ventajas como:

• Entrega de un producto funcional al finalizar cada iteración.

• Posibilidad de ajustar la funcionalidad en base a la necesidad de negocio del cliente.

• Visualización del proyecto día a día.

• Alcance acotado y viable.

• Equipos integrados y comprometidos con el proyecto, toda vez que ellos definieron el proyecto.

Entre principales beneficios que reporta utilizar Scrum como metodología de desarrollo de un sistema se encuentran además: [48]

• Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese momento, ya completados) lo cual proporciona las siguientes ventajas:

o Gestión regular de las expectativas del cliente y basada en resultados tangibles. El cliente establece sus expectativas indicando el valor que le aporta cada requisito del proyecto y cuando espera que esté completado; y comprueba de manera regular si se van cumpliendo sus expectativas, da feedback, ya desde el inicio del proyecto puede tomar decisiones informadas a partir de resultados objetivos y dirige estos resultados del proyecto, iteración a iteración, hacia su meta.

o Resultados anticipados (time to market). El cliente puede empezar a utilizar los resultados más importantes del proyecto antes de que esté finalizado por completo.

o Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado, etc. De manera regular el cliente redirige el proyecto en función de sus nuevas prioridades, de los cambios en el mercado, de los requisitos completados que le permiten entender mejor el producto, de la velocidad real de desarrollo, etc.

o Gestión sistemática del Retorno de Inversión (ROI). De manera regular, el cliente maximiza el ROI del proyecto. Cuando el beneficio pendiente de obtener es menor que el coste de desarrollo, el cliente puede finalizar el proyecto.

o Mitigación sistemática de los riesgos del proyecto. Desde la primera iteración el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigación de manera anticipada. La cantidad de riesgo a que se enfrenta el equipo está limitada a los requisitos que se puede desarrollar en una iteración. La complejidad y riesgos del proyecto se dividen de manera natural en iteraciones

• Productividad y calidad. De manera regular el equipo va mejorando y simplificando su forma de trabajar.

• Alineamiento entre el cliente y el equipo de desarrollo. Los resultados y esfuerzos del proyecto se miden en forma de objetivos y requisitos entregados al negocio. Todos los participantes en el proyecto conocen cuál es el objetivo a conseguir. El producto se enriquece con las aportaciones de todos.

• Equipo motivado. Las personas están más motivadas cuando pueden usar su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo.

Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

Muchos desarrolladores en la actualidad se ven en la disyuntiva de utilizar Extreme Programming o Scrum en sus sistemas pero es válido aclarar que XP es recomendable emplearlo solo en proyectos a corto plazo y reporta altas comisiones en caso de fallar, además puede no ser más fácil que el desarrollo tradicional; los usuarios pueden no querer frecuentes pequeños releases y requiere un rígido ajuste a los principios XP. Además es difícil predecir costo y tiempo de desarrollo ya que no se precisa los elementos a acoplarse en el proyecto y mantener el producto puede ser difícil, debido a que tiene muy poca documentación.