Archive for the ‘desarrollo web’ Category

La puesta en producción

16 noviembre 2009

Se acerca el día “D”. Voota empieza su andadura esta semana y, como no puede ser de otra manera, estamos llenos de emoción. Y cuando digo emoción, me refiero a lo contentos que estamos y a las ganas que tenemos de verlo funcionando, no a que tenemos los pelos como escarpias por el miedo a la puesta en producción. Veamos algunos consejillos para que esto no ocurra.

Ante todo, ¡orden!

Para que la subida (o puesta en producción) sea un éxito, es fundamental hacer una buena planificación, preparar el proceso unos días antes. Una buena idea es tener un checklist de cosas a preparar/revisar antes de ponerse manos a la obra. Podría ser algo tan simple como:

  • Asegurar que los servidores están correctamente actualizados.
  • Comprobar los datos. Todos están correctamente cargados con la información adecuada.
  • Backups. Asegurarse de que todos los subsistemas se están copiado adecuadamente según la política de backup.
  • Todas las aplicaciones están listas (este punto debería llevar implícito toda una fase de pruebas funcionales)

Otra cosa importante es planificar el día y la hora correctamente. Si se planifica la subida a última hora del día, ante cualquier imprevisto, se condena uno a una de dos: dejar el trabajo a medias, o a hacer horas extras. Lo mejor es hacerlo a media mañana con tranquilidad y sin estrés. Lo mismo pasa con el día. Si se realiza la subida un viernes, se está exponiendo el sitio a que se pasé 3 días offline.

Sube pronto, sube a menudo

Hoja de ruta (roadmap) de Voota

Hoja de ruta (roadmap) de Voota

Una de las máximas del desarrollo ágil es que los “sprints” deben de ser cortos. Esta semana Voota sale con lo esencial, es decir, un sistema de opiniones sobre políticos con un ranking para ver los más votados. Hemos querido reducir tanto que ya tenemos programado otro “sprint” de 7 días para subir la semana que viene. En su Trac se puede ver la hoja de ruta de Voota.

Sólo errores, ¡por favor!

No se puede concebir un desarrollo de software que no tenga incidencias, bugs o errores (depende quien los nombre). Son fallos en el desarrollo que se producen a todos los niveles (datos, aplicación, sistemas, …). Es por esto que es imprescindible una fase de pruebas de software, durante la cual se van identificando y corrigiendo estos fallos. Hasta aquí todo bien, el problema es que, inevitablemente, al revisar las aplicaciones siempre aparecen funcionalidades nuevas con las que se podría dotar al sitio. La tentación de informar como incidencia una nueva funcionalidad que se le ocurre al encargado de hacer la revisión es muy grande.
Es importante no caer en esta tentación a menos que se detecte una funcionalidad importante no detectada en la fase de definición. En este caso debería incluirse en la definición con su correspondiente estimación y retrasar la subida todo lo que sea necesario. Nunca “colarla” como un error. Lo único que se conseguiría con esto es degradar la calidad del software.

Ya está, ¿y ahora qué?

Ramificaciones para gestionar subidas en Voota

Ramificaciones para gestionar subidas en Voota

Un problema clásico de las puestas en producción es el siguiente. Se sube una versión a producción, por ejemplo, “milestone0.5”. Inmediatamente se comienza con el desarrollo del “milestone0.6”, pero dos días después se descubre un error importante en la versión en producción (“mileston0.5”). Si no se ha tenido la precaución de guardar el estado de todos los programas en el momento de hacer la subida, el problema no se podrá solucionar hasta que el “milestone0.6” esté listo. Es por esto importante hacer una “foto” con el estado del proyecto en el momento de la subida. Cualquier gestor de fuentes del mercado (subversion en el caso de Voota) permite crear ramas (branching).
Una rama en el gestor de fuentes es como tomar una foto del estado del proyecto, con la ventaja que se puede cambiar de una rama a otra cuando se necesite.

¡ Vamos, pues, a por el siguiente punto kilométrico !

Anuncios

Desarrollo web, desarrollo ágil

13 octubre 2009

Para que “algo” funcione en internet tiene que ser ágil desde todos los puntos de vista. Las páginas web deben pesar poco, el tiempo de respuesta desde que se pide una página hasta que se muestra en el navegador tiene que ser casi inmediato y, dentro de un sitio, si una página ha de ser visitada, más vale que se acceda a ella en pocos clics. Afortunadamente estos conceptos ya han sido aceptados y digeridos por la mayoría de profesionales que se dedican a la “construcción de internet”.

Sin embargo, muchas veces es obviado el concepto de agilidad en la fase de desarrollo. Aunque existen muchas formas y metodologías para aplicarlo, una vez más, lo más importante es aplicar la lógica y entender bien lo que se está haciendo para poder llegar a ser “ágiles”. Se trata de aplicar unos conceptos fundamentales que cada metodología implementará de una manera. Algunas metodologías son Scrum, Programación Extrema (XP) o Agile Unified Process (AUP).

Scrum: Procesos y elementos

Scrum: Procesos y elementos

¿Qué es desarrollo ágil?

Según el manifiesto para el desarrollo ágil de software, éste se basa en 4 pilares básicos:

  • Somos un equipo. Poco aportan unos procedimientos muy estrictos y las herramientas más caras del mercado si el equipo de desarrollo no sabe utilizarlos. Se trata de repartir coherentemente las responsabilidades y el trabajo del desarrollo. Debe haber una cabeza sin duda, pero la implicación y  motivación de cada miembro del equipo es decisiva para el éxito del proyecto. No será fácil aplicar este concepto si se piensa únicamente en horas/hombre (horas/recurso) como un activo del proyecto.
  • Hacemos software, no documentos. El segundo principio dice que hay que dar la importancia justa a la documentación. Si se pretende hacer una documentación exquisita con extensos documentos funcionales que recojan todas y cada una de las necesidades de la aplicación, ocurrirá una de estas dos cosas: En el mejor de los casos, el producto final no se parecerá en nada a lo planteado en estos documentos, o, en el peor, el desarrollo no empezará nunca.
  • Tendremos que hablar con el cliente. Para muchos esto es lo más duro. Trabajando en consultoría es frecuente oír decir que el cliente no sabe lo que quiere, que las especificaciones son malas, que no saben nada de informática o que cambian de opinión cada dos por tres. Seguramente, pero “that’s life”. La solución no es fácil, pero todo pasa por ser flexibles, no hacer rígidos planes al principio y sí hacer continuas iteraciones para ver que se ha hecho y que se va a hacer. Siempre con la aprobación y colaboración del cliente.
  • Ooops, algo ha cambiado. Esta es la piedra filosofal del desarrollo ágil. Hay que estar listo para el cambio. Las iteraciones de desarrollo deben ser cortas. Estar preparado para cambios de prioridades.

En resumidas cuentas, para hacer una super-aplicación, habrá que empezar haciendo un programita, mostrarlo al cliente (aunque sea interno en la empresa), recoger las sugerencias y cambios y preparar la siguiente iteración (seguramente es suficiente con una pequeña lista de tareas). Iteración tras iteración se llegará a la super-aplicación, pero mientras tanto ya tenemos algo. No olvidar nunca que estas iteraciones deben ser cortas (Scrum propone 2 semanas – 1 mes). Si no da tiempo a hacerlo todo en el tiempo prefijado, seguramente habrá alguna tarea que se pueda dejar para la siguiente iteración.