Desarrollo Ágil

El desarrollo ágil es una filosofía de trabajo focalizada en actuar, más que en pensar o planificar y que actualmente utilizan muchos proyectos web de éxito. En el siguiente artículo presentaremos el concepto y la aplicación del desarrollo ágil...

Desarrollo ágil es una filosofía, no una metodología:

El desarrollo ágil no es una metodología con pasos establecidos, es simplemente una manera de pensar y de trabajar.

El desarrollo ágil se puede resumir en una frase "ejecuta rápidamente". La rapidez no es un método infalible a aplicar a rajatabla, es una manera de enfocar las tareas enfocada a dar prioridad a la ejecución sobre la planificación.

Planificas o actúas:

El tiempo no es infinito. No puedes hacer todo al mismo tiempo, optar por una opción o la otra conlleva muchas cosas. Claro, puedes hacer ambas cosas, pero entonces harás ambas a medias.

Especular o probar en real:

¿Funcionará una web que busca en 23 webs de vuelos simultáneamente como Trabber? A priori la idea tiene sentido, pero quién sabe si funcionaría, si captaría tráfico, si generaría fidelidad... A posteriori se ha visto que sí, que funciona, pero a posteriori todo parece siempre evidente. La única manera de saberlo ha sido desarrollar el proyecto.

En un entorno donde las innovaciones envejecen en apenas meses, donde todo evoluciona a la velocidad de la luz, no está siempre clara la utilidad de dedicar excesivamente tiempo a investigar que puede funcionará y qué no, o a planificar al detalle. Es divertido especular con ideas en el aire, pero no se obtiene nada en concreto.

Investigar e innovar:

Innovar también es investigar

Innovación significa crear algo que no existía antes, ejecutar para obtener algo físico. Investigar es averiguar información útil para el proyecto, crear algo intangible, conocimiento.

La ventaja de innovar sobre investigar, es que a la vez que obtienes algo físico funcionando, también puedes averiguar información útil para el proyecto, en muchos casos una información mucho más fiable que te proporciona la pura investigación. En conclusión, innovando también investigas.

Tras investigar y planificar puedes tardar 8 meses en tener la primera beta impoluta para lanzarla a público o tardar 1 mes con algo hecho rápidamente sin refinar. En la segunda opción 7 meses más tarde puedes tener cientos o miles de usuarios, una versión refinada y mucha más información real, no especulaciones. En la primera opción nada te garantizaría que la beta impoluta no sea después un fiasco.

Internet facilita innovar y hacer experimentos con usuarios reales, basta con publicar la web y tener un poco de tráfico.

Reacción rápida:

Rectificar puede ser percibido negativamente, significa que has cometido un error o lo puedes percibirlo positivamente como que has aprendido y eres capaz de reaccionar rápidamente para arreglarlo.

Cuanto más rápidamente ejecutes, antes descubrirás qué es bueno, qué es malo, qué es suficientemente bueno y podrás hacer mejoras. Rectificar no es fácil, conlleva ser humilde y modesto.

Cuando el área del proyecto está muy trillada y se conoce bastante sobre lo que funciona, si puede tener sentido investigar y planificar para mejorar lo que ya existe. La filosofía de desarrollo ágil funciona mejor cuando se trata de hacer algo desde 0 o rediseñarlo totalmente, por el contrario es menos recomendable cuando quieres mejorar algo que ya sabes que funciona.

Ideas sobre desarrollo ágil:

Lo mejor es enemigo de lo bueno

¿Cuando tienes algo suficientemente bueno para sacar a público? En cuanto funcione de manera técnicamente aceptable.

Lo mejor es enemigo de lo bueno, pero lo mejor aún es peor enemigo cuando ni siquiera sabes qué es. No dudes, sácalo a real y verás si funciona o no.

Resuelve los problemas cuando los tengas:

No tiene sentido preocuparse de problemas de escalabilidad en el futuro al principio de un proyecto, deberías preocuparte de las cosas más urgentes en ese momento. Además de quitarte tiempo muy valioso, seguramente las soluciones a las que llegues distarán de ser óptimas. Por ejemplo, hasta que no sepas exactamente qué problemas de escalabilidad vas a tener no sabrás cuál será la mejor opción.

Lo mismo pasa con los temas legales. Si no hay ingresos, ni pagos, ni información personal muy delicada almacenada no creo que valga la pena que te quiten el sueño. La última cosa de la que me preocuparía sería de como declarar una pequeña cantidad de ingresos de Adsense.

Los grandes planes nunca funcionan:

No es una ley de Murphy, pero como si lo fuera. Planificar excesivamente aleja de la realidad, es muy fácil escribir en un papel ideas, pero muy difícil ejecutarlas. Conforme una planificación se complica es más probable que no funcione como se espere.

Es positivo tener unas ideas básicas y generar algunos documentos concisos, pero hay que evitar la complicación excesiva. Jesús Encinar cuenta como redujeron el plan de negocio de Idealista de 150 páginas a solo 7.

Logs y estadísticas de servidor:

Para saber qué funciona y qué no funciona de los cambios realizados, tu gran aliado serán las estadísticas. Son la manera más rápida, ágil y barata de obtener información fiable del mundo real.

No se trata de manejar mil datos estadísticos, sino centrarte en los realmente relevantes y sensibles a los cambios. Los test de usuarios de guerrilla son útiles especialmente cuando tienes dudas o hay grandes cambios.

No es algo nuevo:

La filosofía de desarrollo ágil no es nueva en absoluto. Cualquiera que comienza un proyecto puede optar por planificar bien o actuar rápido, ya sea construyendo un puente o diseñando una web. Simplemente en algunos proyectos puede ser más adecuado hacerlo que en otros.

No es recomendable arriesgarse a tener accidentes construyendo un puente, todo tiene que estar bien planificado y aguantar mucho más de lo necesario. Sin embargo una web inicialmente no la creas para resistir mucho más tráfico del necesario y si un día cae un par de horas se puede resolver fácilmente.

Es un medio, no un fin:

La metodología de desarrollo web ágil, como cualquier otra metodología es un medio, no un fin. No se trata de aplicarla a rajatabla, sino cuando nos ayude a conseguir nuestro objetivo. Nadie debería seguir esta filosofía en su proyecto porque lo ha leído este artículo, ni en ningún otro, sino porque es lo más adecuado para su proyecto en ese momento y en esas condiciones.

Hay servicios que deben funcionar perfectamente desde el primer día porque por su propia naturaleza solo aportan si funcionan bien, no se les daría una segunda oportunidad, para esto no vale el desarrollo ágil. Si desarrollas un servicio de pago tampoco te recomiendo experimentar demasiado con desarrollo ágil.

Sin marketing masivo:

Hacer cambios de manera rápida no significa forzosamente la presencia de bugs, pero ciertamente con desarrollo ágil puede ser más proclive a tenerlos. Además puede que el aspecto del sitio no sea muy refinado cuando lo sacas a público tras un mes de desarrollo.

Por estas razones no es bueno aparecer en grandes medios porque entonces como comentaba Joel on Software en Massive Frontal PR is incompatible with Ship Early and Often" tendrías dos problemas a) un proyecto inacabado b) todo el mundo lo sabría.

Para un proyecto que utiliza desarrollo ágil es mejor el marketing de guerrilla, de blogs, el boca-oreja y en general cualquier técnica enfocada a un público más pequeño y limitado. Este público especialmente interesado en la idea es más comprensivo y da mucho feedback, sugiere, comenta, etc.

Motivación y abandono:

El desarrollo ágil disminuye la probabilidad de abandono del proyecto porque lo hace más motivador.

Cualquier proyecto desde 0 requiere un volumen de motivación impresionante, no es extraño que un proyecto se abandone sin ser completado, lo que sucede mucho más frecuentemente en proyectos que tardan muchos meses en salir a público.

Un desarrollo ágil tiene una primera versión mucho antes con lo que minimiza el riesgo de abandono previo. Luego al no parar de sacar cambios y recibir feedback de los usuarios se obtiene más motivación positiva y se reduce la probabilidad de que sea abandonado.

Con pocos recursos es más fácil:

Cuanto menos tengas, menos tienes que perder. Si no tienes inversión más que tu tiempo, eso será lo único que perderás si te arriesgas. Si te alguien te paga mucho dinero o invierte en tu proyecto, te dará más miedo arriesgarte a experimentar y probar cosas nuevas.

La conclusión es sencilla, aunque paradójica, tu escasez de recursos te abre la puerta de grandes oportunidades. Para llegar a innovar radicalmente hay que experimentar y probar haciendo cosas que grandes empresas ni podrían, ni se atreverían a hacer.

Utilizando desarrollo web ágil un equipo pequeño y sin recursos convierte sus debilidades en ventajas. Hay que evitar entrar a competir con las grandes con sus mismas armas y sus mismas metodologías de trabajo, es muy complicado tener opciones entrando en su terreno.

Equipo inicial minúsculo:

No hablo de un equipo pequeño de 5 o 6, me refiero a un equipo minúsculo de 2 o 3 personas inicialmente.

Si hay mucha gente tardas demasiado en ponerte de acuerdo y sobre todo es complicado que nadie se moleste cuando parece que das "bandazos" con tanto experimento y cambio de opinión. A menos gente más agilidad de implementar y menos discusiones.

Lo que no recomiendo en absoluto para un proyecto así es depender de patas físicas, de acuerdos con terceros, de demasiada gente, etc. es complicado utilizar desarrollo ágil en esas circunstancias.

¿Es serio un proyecto llevado así?

Sucede que algunas personas no toman en serio un proyecto que cambia cada dos por tres, donde algunas cosas no son tan estables como debieran y que no tiene inicialmente un nivel de refinamiento muy alto. Se puede llegar a pensar que es un proyecto de "amiguetes", algo poco serio, un juego.

En realidad nada tiene que ver una cosa con la otra. Cualquier experimento tiene mucho de juego, de descubrir que funciona y que no funciona, de ser como un niño curioso que prueba y prueba.

En realidad es positivo que sea divertido y que el ambiente sea relajado porque es solo es posible tener ideas nuevas y atreverse a implementarlas rápidamente en un ambiente flexible y donde se acepte la alta incertidumbre como normal, justamente lo que no sucede en un ambiente de trabajo clásico. Creo que no sería positivo para un proyecto desarrollado de manera ágil el parecer "serio". Las camisetas y la ausencia de trajes no son casualidad o una moda en este ambiente.

El desarrollo ágil no es para siempre:

El desarrollo ágil es especialmente útil al principio del proyecto, cuando hay que crear algo de la nada y aprender lo antes posible.

Más tarde, al cabo de un año o dos, cuando ya empiezas a tener claro lo que funciona y lo que no, la filosofía forzosamente cambia. Empieza a haber más gente en el equipo, se empieza a discutir más y se hace menos. Es normal e inevitable, no es lo mismo jugarte perder usuarios cuando empiezas y solo tienes un par de miles que más tarde cuando tienes un par de cientos de miles.

Cuando tienes muchos usuarios además se complican los cambios, la gente se acostumbra a las cosas y prefieren estabilidad, no les gustan los cambios, aunque realmente sean positivos para ellos.

Una filosofía de trabajo que no es para todos ni para todo

Tu carácter personal es importante:

Para aplicar desarrollo ágil debes tolerar niveles altos de incertidumbre e incluso de caos en ocasiones. No te debe poner excesivamente nervioso no saber qué va a pasar en el futuro. Es una filosofía que funciona bien con personas que necesitan respuestas rápidas, hacer algo y ver los cambios, que no les gusta esperar.

Si tu estilo de trabajo es muy organizado y planificado, te incomoda la incertidumbre, pero por el contrario eres capaz de mantener alta tu motivación en un largo proyecto donde los resultados no se visualizan hasta meses más tarde, seguramente esta filosofía de trabajo no es para ti.

Cuando tienes ideas muy claras, te entusiasman ciertos autores y te encantan las metodologías, seguramente encajarás muy bien en otros proyectos, pero no en uno de desarrollo web ágil. Al contrario, la gente más óptima para desarrollo ágil, es la que peor encaja en grandes organizaciones con muchas jerarquías y procesos. No opino que un perfil sea mejor que otro, simplemente son diferentes para casos diferentes. #Haga click aquí para leer más artículos de DesarrolloWeb.com

Artículos Similares
- Desarrollo de Productos
En la época en que vivimos, solo sobrevivirán las empresas que sean más competitivas y creativas, y para hacerlo debemos ofrecer productos a precios competitivos. A continuación te damos los pasos a tener en cuenta en la ingeniería de desarrollo y diseño de productos...
- Franquicia Vs. Emprendimiento
- Desarrollador de Negocios
- Contratación de Personal: La Naturaleza Humana
- Gerentes que Buscan la Calidad Organizacional
- Los servicios se globalizan
- Desarrollo de Productos I
- El Estilo Imitativo de un Líder
- Potenciar su Desarrollo Gerencial
- Desarrollo De Productos II