Kelly Waters nos da algunas claves para no perder de vista la visión de conjunto (the big picture) durante el desarrollo de un proyecto ágil. Aquí os dejo una traducción libre:

“Cuando utilizamos un enfoque basado en el desarrollo ágil, no hay grandes especificaciones ni diseños inamovibles. El alcance del proyecto varía. Algunos requisitos evolucionan, y otros nuevos van emergiendo. Las funcionalidades crecen, cambian y desaparecen a lo largo de todo el ciclo de vida del proyecto. En este entorno variable, la cuestión es: ¿qué podemos hacer para no perder de vista la visión de conjunto?

Aunque el desarrollo ágil consiste, en gran parte, en trocear los objetos hasta conseguir pedazos pequeños y manejables -para obtener, por ejemplo, el product backlog y el sprint backlog- es muy importante no perder de vista el contexto global, para que nos sirva como guía y referencia a lo largo de todo el proceso.

Este contexto se nos presenta en 3 formas principales:

• Contexto de negocio
• Contexto de proyecto
• Contexto de la solución

Contexto de negocio

ALGUNAS PREGUNTAS ÚTILES: ¿Cuál es la visión de negocio? ¿Cuáles son los retos y las oportunidades desde el punto de vista del negocio? ¿Cuáles son los objetivos de negocio a corto, medio y largo plazo? ¿Quiénes son los clientes? ¿Por qué compran y para que utlizan las solución que vamos a desarrollar? ¿Qué les gusta y qué no les gusta del proyecto? ¿Quién es la competencia y cómo son sus soluciones?

Sin esta información global de contexto, cualquier equipo de desarrollo está trabajando con una gran desventaja. La gente de desarrollo puede ser muy innovadora y si los equipos de desarrollo cuentan con una visión interna real del contexto de negocio, pueden ser mucho más proactivos. Con esta información, es mucho mas probable que las soluciones innovadoras emerjan a la superficie.

Contexto del proyecto

Muchos de los elementos definidos en la fase de inicio de un proyecto tradicional siguen siendo importantes en un entorno de desarrollo ágil.

ALGUNAS PREGUNTAS ÚTILES: ¿Cuáles son los problemas específicos o las oportunidades que el proyecto intenta abordar? ¿Cuál es la visión para el proyecto? ¿Cuáles son los objetivos del proyecto? ¿Cuál es el enfoque? ¿Cuál es el coste previsto y el plazo de entrega? ¿Cuáles son los beneficios y cómo se van a conseguir? ¿Quién trabajará en el proyecto y cuál será su estructura?

Las respuestas a éstas y otras preguntas constituyen una guía de referencia importante para el equipo. Esta guía se hace más necesaria si cabe en un desarrollo ágil, en el que hay libertad para cambiar las cosas durante todo el proceso. Con esta información, el equipo dispone de algunos parámetros con los que trabajar, y tiene claro cuáles son los resultados esperados.

Contexto de la solución

He escrito varios posts sobre cómo escribir buenas historias de usuario. Me gusta que sean tan pequeñas, autoexplicativas y manejables. Hacen que las cosas resulten sencillas. Pero, ¿qué deberíamos hacer antes de llegar al detalle de las historias de usuario? Es importante enmarcarlas dentro del contexto global de la solución. Las siguientes herramientas pueden ayudarnos:

• Mapa (roadmap) de producto de “alto nivel” (no entra en detalles). Utilizando una línea de tiempo amplia -por ejemplo, meses o trimestres- este mapa nos permite destacar las funcionalidades clave del producto y los diferentes hitos principales que se producen a lo largo del proyecto. A diferencia de un plano, un mapa de producto es indicativo y evoluciona a medida que las cosas cambian. Proporciona al equipo una estructura del plan de sprints, y ayuda a identificar las prioridades y a establecer los objetivos de cada sprint.
• Visuales de alto nivel. Pueden ser wireframes o maquetas con las pantallas clave, un storyboard conceptual para el interfaz de usuario, etc. Sea cual sea su forma, este boceto de alto nivel debe mostrar cómo funcionará la solución desde la perspectiva del usuario. No hace falta que estos visuales especifiquen todas las pantallas, ni todas las funcionalidades. La solución final ni siquiera tiene que mostrar el mismo aspecto de los visuales (de hecho, casi nunca lo hace). Pero constituye una buena guía para arrancar el proyecto porque cubre los escenarios principales a los que se va a enfrentar el usuario-tipo.
• Arquitectura (de alto nivel) de la solución. No hace falta que sea un diseño detallado. Lo que necesitamos es una arquitectura que nos sirva para entender las tecnologías clave, la estructura del producto, y cómo se comporta la solución desde una perspectiva técnica. Puede ser una imagen que vaya evolucionando. Algo así como el boceto que dibujamos en una pizarra al iniciar el proyecto, pero complementado con los detalles que vamos añadiendo a medida que el proyecto avanza y tomamos decisiones técnicas.

Resumen: Un equipo de desarrollo ágil necesita trocear las cosas en pequeños fragmentos y hacer las entregas de manera incremental. Para hacerlo, resulta especialmente importante tener en mente el contexto general. Mi consejo es que utilices herramientas-guía de alto nivel, ligeras y muy visuales (objetivos del proyecto, mapa de producto, arquitectura de la solución), y las mantengas pegadas en la pared junto con las historias de usuarios y las tareas diarias.

Podéis leer el post original aquí.

Richard Stallman, gurú de la informática y genuino impulsor del software libre, pasó por Madrid hace unos días y dio una conferencia en la que habló sobre la libertad y el usuario. Aquí os dejo un resumen libre, basado sobre todo en la primera parte de la conferencia. Es un poco largo, pero creo que merece la pena. Esta es la controvertida visión de Stallman:

Sobre Richard Stallman. “En el año 83 lancé el movimiento de software libre. El objetivo era, primeramente, desarrollar un sistema operativo libre para que fuese posible usar una computadora en libertad. Este sistema se llamó GNU. Comencé su desarrollo en enero del 84. En el año 92 faltaba un componente importante, el kernel. Otro programador [Linus Torvalds] liberó un kernel que se llamaba Linux. La combinación del sistema completo GNU y el kernel Linux era un sistema completo y libre. Desde entonces es posible (más o menos) comprar un PC y usarlo en libertad, siempre que uses una versión netamente libre GNU Linux, y no instales otros programas privativos.”

Premisa. El software libre es aquel que respeta la libertad del usuario, en contraposición al software privativo, que sume a los usuarios en una situación de inhibición e impotencia. Inhibición porque los usuarios tienen prohibido compartirlo con los demás, e impotencia porque no poseen el código fuente y, por tanto, no pueden cambiar el programa ni saber qué es lo que el programa verdaderamente está haciendo.

Según Stallman, un programa de software es libre si proporciona al usuario las 4 libertades esenciales:

LIBERTAD 0. La libertad de ejecutar el programa como quieras.
LIBERTAD 1. La libertad de estudiar el código fuente del programa y cambiarlo para que haga lo que tú quieres que haga.
LIBERTAD 2. La libertad de ayudar a tu prójimo: es decir, la libertad de distribuir copias del programa a los demás cuando quieras.
LIBERTAD 3. La libertad de contribuir a tu comunidad, es decir: la libertad de distribuir copias de tus versiones cambiadas cuando quieras.

Con estas 4 libertades, el programa es software libre. Sus usuarios son libres y el sistema social de su distribución y uso es un sistema ético que respeta la libertad del usuario y la solidaridad social de la comunidad. Si una de estas libertades falta o es insuficiente, el programa se convierte en software privativo, porque el sistema social de su distribución y su uso no es ético. Un programa privativo no es una contribución a la humanidad, sino un ataque. Es un trampa que intenta atraer a la gente para que ceda su libertad.

(more…)

Facilitar recomendaciones comerciales a través del correo electrónico es ilegal según la Agencia Española de Protección de Datos. No es posible enviar ningún mail con contenidos publicitario o promocional salvo que exista un consentimiento previo e informado del destinatario, algo que casi nunca sucede en los típicos “Recomendar a un amigo” de los sitios web.

Así aparece reflejado en una Resolución de la Agencia, del 20 de febrero de 2008, en la que se multa a una página web por ofrecer a los internautas la facilidad de remitir a la dirección de correo electrónico de un familiar o de un amigo un mensaje informativo invitando al destinatario a registrarse. La infracción ha sido considerada leve, pero muchos piensan que puede constituir un importante golpe para el marketing viral.

El envío de este tipo de correos electrónicos, aunque lo llevan a cabo los propios internautas, se realiza desde la dirección IP de la empresa sancionada, por lo que la Agencia estima que la página web es responsable.

Leer el artículo en El Economista.

En el blog de Alberto estaba esta presentación con datos mas que interesantes.En tres palabras, más videos, mas participación y menos televisión.

| View | Upload your own

Hoy hemos celebrado la reunión mensual de raileros en Barcelona, en las oficinas de Linqia.

Fuimos siete, Christian presentó algunos aspectos de escalabilidad de Linqia. Hablamos también del stack EC2/S3/SQS, y de git, entre otras cosas.

Hoy fui a la reunión con el Segway y una vez terminada improvisamos unas prácticas en Gran de Gràcia.

Alistair Croll ha escrito en Gigaom un curioso post en el que hace una lista sobre las 10 maneras en que Internet -tal y como la conocemos- desaparecerá en el futuro. Aquí va una traducción libre:

“A menudo pensamos en Internet como una plataforma para la comunicación global, en la que la información fluye de forma libre, los innovadores pueden lanzar nuevas aplicaciones a voluntad, y todo el mundo tiene su propia voz. Pero es poco probable que la Internet de nuestros hijos se parezca a la que conocemos ahora. ¿Cómo puede morir Internet? Hay 10 posibilidades:

1. Alguien destruye los DNS (Servicio de Nombres de Dominio). Internet se basa en los DNS. Pero si alguien rompe el modo fundamental en el que encontramos los sitios web, ya no podríamos confiar en las URL’s nunca más. El Phishing -o fraude informático- sería fácil. Domina el DNS e Internet será tuya.

2. Ataque de una red de zombies. Un número incalculable de PC’s esclavos están esperando a la intentona de los hackers del lado oscuro. Matt Sergeant, de Message Labs, calcula que la red de bots está formada por entre 5 y 10 millones de equipos (aunque algunos rebajan bastante esta estimación). Hoy, los bots saturan nuestros buzones de correo con spam. Pero en el pasado, han sido utilizados para atacar empresas y países, y para chantajear a sitios web. Al final, es una carrera de armamento en el que solo una de las partes respeta las reglas.

3. Fallo masivo en la infraestructura física. Si un accidente con un par de cables en el Mediterráneo puede hacer que Internet deje de funcionar para cientos de millones de usuarios, imagina lo que podría conseguir un ataque intencionado.

4. Guerra por fragmentación. Desde Usenet, la gente se ha ido agrupando con aquellos que piensan igual que ellos. En su libro “The Big Switch”, Nicholas Carr cita un estudio según el cual el 90% de los enlaces originados en en el seno de la comunidad conservadora y liberal permanecen en el seno de esa comunidad. Algunas herramientas de enlaces de referencia pueden ser configuradas para mantener a los visitantes en sitios que mantienen su punto de vista. ¿El resultado final? Islas de gente que piensa lo mismo, cada vez más seguros de que sólo hay una respuesta correcta, la suya propia. Se acabaron los sueños de una comunidad global tal y como la imaginaron los creadores de Internet.

5. Un virus realmente bueno acaba con los routers. El mecanismo auto-sanador de Internet recae en el Border Gateway Protocol (BGP). Pero, ¿y si alguien se cuela en los routers? En una presentación de NANOG, en 2006, Cisco se concentró en los puntos vulnerables y concluyó que “los ataques más dañinos son causados por una mala configuración deliberada de un router en el que se confía”. Corrompe el BGP y no sólo impedirás que fluya el tráfico en Internet, sino que también dañarás nuestra capacidad de llegar a los routers para arreglarlos.

6. Las actualizaciones rompen el funcionamiento de las actualizaciones. Casi todo el software está diseñado hoy en día para parchearse y mantenerse actualizado. Pero a veces el proceso de actualización automática desencadena sus propios problemas. El 16 de agosto de 2007, Skype se cayó en lo que la compañía dijo fue un efecto colateral de una actualización masiva a Windows. Sólo es cuestión de tiempo que una actualización se convierta en una pieza fundamental del software, haciendo imposible que se actualice a sí misma, y dejando así sin servicio a millones de usuarios hasta requerir una intervención manual.

7. La Red deja de ser neutral. Si los proveedores empiezan a cobrarnos por el acceso a los sitios de la misma manera que hacen las compañías de televisión por cable con su servicio Premium, pronto encontrarás un cargo de Google en tu factura mensual. Esto ocurre ya con muchos móviles que incluyen servicios de Facebook o YouTube. Es, quizá, la muerte más odiosa, porque significaría el fin de la innovación: nadie sería capaz de lanzar el próximo Skype, Twitter o YouTube sin la aprobación de los proveedores.

8. Los abogados se meten en el ajo. Internet ha sido un experimento de libertad de expresión. Eso puede haber llegado a su fin. Incapaces de perseguir a los propios sitios, los abogados la toman con las compañías de hosting y las de registro. Es así como el grupo suizo de banca Julius Baer silenció al “chivato” de Wikileaks. Y una vez que hay un precedente, vendrán otros casos. La industria discográfica se está planteando si puede perseguir a los proveedores por hacer posible la violación del copyright. Esta es la ironía de la neutralidad de la Red: cuando las telecos empiezan a tratar a diferentes bytes de forma diferente, dejan de ser “proveedores comunes” y pueden ser responsables por lo que transmiten, incluyendo contenido ilegal. Así que tendrán que responder.

9. Jardines vallados. Muchos países ponen restricciones al uso de Internet. El firewall de China -que incluye 30.000 personas clasificadas por usos impropios- es un buen ejemplo. Internet es una herramienta de intercambio social y esta “revolución” podría asustar a cualquier gobierno. Imagina, por ejemplo, que el congreso de Estados Unidos prohibiese la pornografía online y bloquease los sitios para adultos (que constituyen el 18.8 % de las visitas en 2004 según Hitwise). En vez de una Internet global, regresaríamos a los estándares de decencia impuestos por los legisladores. Sería como Dirty Dancing una vez tras otra.

10. El ser humano acaba consigo mismo. Como señalaba la revista Discover hace unos años, tenemos muchas maneras de acabar con nosotros mismos, desde las armas nucleares hasta las plagas, pasando por un agujero negro creado por nosotros mismos mediante un acelerador de partículas. ¿Y qué sería Internet sin usuarios?

Internet ha cambiado de forma ya, dejando atrás sus aspiraciones iniciales de academia libre para convertirse en una plataforma comercial controlada por empresas y proveedores. En muchos sentidos, el tiempo transcurrido entre el nacimiento de ARPAnet en 1969 y el fin de Netscape el pasado febrero constituye simplemente un reducido período en la historia que la generación Facebook no olvidará.”

Podéis leer el post original aquí.

Como no podía ser de otra manera, hay quienes se han tomado con humor estas profecías un tanto catastrofistas. Esta es la versión de coña: 10 formas (y pico) en las que Internet podría morir

Rails 2.1 está al caer. Aunque todavía no está confirmada la fecha de “lanzamiento”, ya podemos saber en qué consistirán las mejoras estrella:

• Gem dependencies: Los plugins de Rails son muy útiles porque, al estar incluidos en la aplicación, pueden ofrecen funcionalidades extra sin dependencias externas. Sin embargo, no sucede lo mismo con las gemas, en las que hasta hace poco, no había manera builtin de definir estas dependencias externas mediante programación. Todo esto cambiará con la nueva versión.
• Dirty tracking con actualizaciones parciales: Saber si tus objetos de Active Record han sido modificados o no es ahora mucho más sencillo.
• has_finder toma la forma de named_scope. El popular plugin has_finder tomará la forma de named_scope en Rails 2.1.
• Soporte de zona horaria incorporado. Ya no será necesario forzar la zona horaria con hasta dos plugins.
• Mejor infraestructura de cacheo. A partir de ahora, podrás especificar tu motor de cacheo preferido en el fichero de configuración.

Podéis ver más en el blog de Ruby on Rails.

Curso gratuito de Ruby on Rails

Los desarrolladores Michael Slater y Christopher Haupt -ambos ex Adobe- han creado un curso online gratuito para aprender Ruby on Rails desde 0. Los usuarios podrán acceder al código utilizado durante el curso, publicado bajo licencia Open Source en un repositorio público. El método utilizado para distribuir los contenidos será el correo electrónico: cada participante recibirá un mensaje por lección, con suficiente espacio de tiempo como para que puedan asimilar el tema. Además, los alumnos podrán plantear sus dudas y preguntas.

¿Qué materiales ofrece el curso?

• Una serie de 8 podcast de audio que explican los conceptos básicos de Ruby on Rails.
• Screencasts en los que se describe, paso a paso, cómo construir una aplicación Ruby on Rails sencilla.
• Código fuente completo para construir la aplicación de prueba del curso.

¿Por qué aprender Ruby on Rails?
Los autores del curso lo tienen claro: Ruby on Rails es una poderosa herramienta Open Source que te permite construir aplicaciones web realmente sofisticadas de una forma muy rápida:

• Gestiona toda la comunicación con la base de datos, de forma que puedes manejar los objetos software y dejar que el framework genere SQL.
• Ofrece un sistema de plantillas para gestionar la presentación de las páginas, además de facilidades para procesar formularios y actualizaciones AJAX.
• Proporciona una amplio abanico de plugins que permiten desarrollar funcionalidad de forma rápida.

Ruby on Rails fue diseñado para que emplees tu tiempo de la manera más eficaz, eliminando el trabajo pesado e innecesario, y permitiéndote crear grandes soluciones con un enfoque ágil y basado en iteraciones.

Hay una gran demanda de desarrolladores para Ruby on Rails, así que aprender a construir sitios con Rails puede ser un gran paso en tu carrera como desarrollador web, tanto si eres freelance como si tienes en mente mejorar tu puesto de trabajo en una empresa.

Échale un vistazo al curso.

Esta semana le hemos pegado un repaso a nuestro plugin model_auto_completer con algunas versiones seguidas (release often!) que han llevado a la 1.5.3 de hoy mismo.

Lo más destacado de estas releases:

• Test suite semi-automática.
• Nuevo helper de conveniencia model_auto_completer_result para generar de una tacada la lista de resultados que espera el código cliente.
• Nuevo flag :append_random_suffix que permite deshabilitar la generación de sufijos aleatorios en los IDs de los campos. (Sugerencia de Wolfram Arnold, thank you dude!)
• Nueva opción :url para poder configurar la acción de autocompletado con una named route.
• Corrección de un bug relativo a seleccionar dos veces modelos usando el ratón.
• Buena revisón a la documentación.

Los métodos de desarrollo ágil ponen el énfasis en la comunicación “cara a cara” más que en la generación de documentación, de forma que alguno de los procesos más destacados, como por ejemplo SCRUM, pueden llevarse a cabo prácticamente sin herramientas: papel, boli y algunas tarjetas son suficientes.

Esta búsqueda de la sencillez no ha impedido que aparezcan en el mercado algunas aplicaciones específicas para trabajar con una metodología ágil. Os vamos a proponer algunas. De menos a más:

Enseña tus cartas
Cardmeeting es una sencilla herramienta de colaboración simultánea en la que los usuarios pueden ir añadiendo sus cartas con ideas, conceptos, tareas, etc. Puede resultar útil para celebrar una tormenta de ideas o brainstorming, para realizar una planificación ágil, o simplemente para fijar y compartir las ideas con otros usuarios. Las cartas pueden clasificarse luego en diferentes categorías temáticas (curioso, sorprendente, divertido, frustrante) y colores, de forma que podemos asignar un orden a las ideas formuladas de manera dispersa. Todavía está en versión Alfa. Si tenéis curiosidad, podéis repasar la conferencia Agile de 2006.

Hecho para scrum
Scrumdesk es una herramienta de gestión diseñada específicamente para trabajar con SCRUM, la metodología de desarollo ágil más conocida. Permite automatizar los procedimientos básicos de SCRUM, como son la elaboración del product backlog (lista de requisitos de alto nivel ordenada según la prioridad), el sprint backlog (lista de tareas que deben ser completadas en un plazo de entre 1 y 4 semanas) o las historias de usuario. Podéis consultar aquí la lista de funcionalidades.

Todo el ciclo del proyecto
En Rally afirman ser los auténticos y genuinos número 1 en el software de gestión ágil… Su aplicación cubre todo el ciclo del proyecto, y permite crear un flujo entre la labor de los gestores, desarrolladores y responsables de testing. Sus productos están centrados en las siguientes funciones: organización del proyecto, el reporte y control, la planificación y seguimiento, gestión de calidad, colaboración de equipos, customización e integración, y administración de permisos. Entre los clientes de Rally se encuentran varias grandes compañías.