3 prácticas “ágiles” para aumentar la productividad de tu equipo:

1. Un espacio de trabajo adecuado para el equipo
2. Ciclos de trabajo cortos
3. Pon el trabajo a prueba (test driven development)

Más en Pymecrunch

Para garantizar la calidad y la seguridad de un sistema, un lenguaje o una aplicación, a veces conviene pensar de forma diferente. Pensar más en “cómo podría fallar” y no tanto en “cómo podría funcionar”. Esta es la interesante tesis de este post sobre desarrollo ágil, surgido a partir de una reflexión de Bruce Schneier:

Los ingenieros de seguridad ven el mundo de una forma muy diferente al resto de ingenieros. En vez de centrarse en cómo funcionan los sistemas, se centran en cómo esos sistemas fallan; no sólo eso, también tienen que pensar en cómo otros pueden hacer que esos sistemas fallen y, por supuesto, en cómo impedirlo. Y es que la práctica totalidad de las “vulnerabilidades” de software ni siquiera aparecen en las operaciones más comunes. Sólo surgen cuando un “atacante” las aprovecha. Así que los ingenieros de seguridad necesitan pensar como los atacantes.

En ocasiones, la gente sin esta mentalidad cree que puede diseñar productos de seguridad, cuando en realidad no está capacitada. Y los resultados de esta ineficacia se pueden ver en muchos ámbitos: sistemas de encriptación fraudulentos, programas de software, protocolos de Internet, sistemas de votación, tarjetas, sistemas de pago, etc. Muchos de estos sistemas cuentan con un responsable de la seguridad, sí, pero ese responsable simplemente no es capaz de pensar como un “atacante”.

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í.

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.

No importa si eres un consultor IT, un analista de negocio o un diseñador web. “Dibujar” lo que tienes en la cabeza antes de lanzarte a redactar, a programar o a diseñar puede resultarte de gran ayuda. No hace falta que utilices lápiz y papel, claro. Hay otras maneras. Te sugerimos que aproveches los diferentes recursos de diagramación para abordar el proyecto con una visión más amplia y certera. Estos recursos te permitirán:

1. Asegurarte de que el planteamiento de partida tiene bases sólidas.
2. Te darán la oportunidad de “discutir” el proyecto hasta conocer mejor la visión de tu cliente.

Al fin y al cabo, es en ese estadio inicial cuando más sencillo y menos traumático resulta introducir cambios.

Te proponemos las siguientes herramientas:

Diagramas de flujo: Son esquemas que representan la estructura y el flujo de navegación de un sitio web o de una aplicación. Algo así como un “plano” en el que se muestran las conexiones y la interacción entre las diferentes partes de un sistema. El aspecto de los elementos es lo de menos mientras pueda comprenderse el flujo. Esta visión esquemática y de conjunto te permitirá sacar a la luz bastantes nudos y contradicciones que hasta el momento habían pasado inadvertidos.

Wireframe o “maqueta”. Un wireframe es una representación esquemática de una página web. No muestra elementos gráficos, porque lo importante es establecer el contenido y el comportamiento de las diferentes páginas.

El wireframe puede ser más o menos detallado: se considera de baja fidelidad cuando se limita a representar aspectos generales, y de alta fidelidad cuando alcanza un gran nivel de detalle, por ejemplo, en el caso de una maqueta dinámica que permite, incluso, interactuar al usuario.

Tanto lo diagramas de flujo como las maquetas nos proporcionan una excelente oportunidad para “discutir” el proyecto con el resto del equipo y, por supuesto, con el cliente antes de empezar a programar y diseñar, de forma que los malentendidos y los cambios y modificaciones no resulten demoledores. En ambos casos, el aspecto de los diagramas es absolutamente secundario. De hecho, introducir elementos de diseño en esta fase suele consistir un grave error: el cliente enseguida centrará la discusión en las formas y colores, dejando de lado otros temas fundamentales.

Wireframe vs prototipo. Ojo. Un wireframe no debe confundirse con un prototipo. Hay una diferencia fundamental entre ambos: los prototipos se construyen para funcionar -aunque no cuenten con una funcionalidad completa- mientras que los wireframes o maquetas tienen como principal objetivo representar el sistema, y no tanto actuar. Como ya hemos comentado, podríamos realizar un wireframe de baja fidelidad con lápiz y papel, y sería perfectamente válido siempre que resulte comprensible.

EL PUNTO DE VISTA DEL USUARIO: OTRAS HERRAMIENTAS INTERESANTES

Especificaciones. Las especificaciones constituyen un sistema muy extendido para documentar, comunicar y conseguir un acuerdo con el cliente sobre el diseño de la aplicación. El problema es que, en el mundo del desarrollo web -convertido muchas veces en una carrera enloquecida- el exceso de documentación y una recogida de requisitos excesivamente reglada pueden eternizar el desarrollo de un proyecto. Y lo que nosotros buscamos es un desarrollo ágil. Por eso, dentro de la metodología ágil SCRUM han surgido herramientas alternativas a las especificaciones tradicionales. Una de las más consolidadas son las historias de usuario.

User stories/Historias de usuario. Una historia de usuario es una forma de recoger los requisitos de un proyecto en tan sólo un par de frases. Esas frases se anotan en una pequeña cartulina o tarjeta para garantizar que los requisitos no crecen hasta hacerse inabarcables, y se formulan en un lenguaje corriente, para que tanto el equipo como el cliente pueda entenderlas a la perfección. El objetivo es capturar de forma rápida y efectiva los requisitos reales del cliente, sin perderse en montañas de documentación y procesos formales. De esta forma, en un entorno de cambio constante, los cambios pueden ser absorbidos sin que el proyecto se desplome.

Las historias de usuario se llaman así precisamente porque recogen el punto de vista del usuario. En su blog, Kelly Waters nos propone el siguiente sistema: Una historia de usuario debe centrarse en el QUIÉN, el QUÉ, y el POR QUÉ, no en el CÓMO. Por ejemplo, en un sitio web de empleo, dos de las historias de usuario serían:

• Como persona en busca de trabajo, quiero buscar un empleo para progresar profesionalmente.
• Como seleccionador de personal, quiero publicar una oferta de trabajo para encontrar a un nuevo miembro del equipo.

La estructura sería:
Como [rol de usuario], quiero [objetivo], de forma que pueda [motivación]

La importancia de la última parte -la que corresponde al POR QUÉ- no está tan acreditada, pero también es cierto que conocer la motivación del usuario puede darnos buenas pistas sobre sus necesidades.

Card sorting. Esta técnica de tarjetas resulta útil cuando se quiere construir una estructura de contenidos basándose en el punto de vista del usuario. Consiste en observar y analizar la forma en que los usuarios agrupan y asocian unas tarjetas etiquetadas con diferentes temas. Siguiendo el comportamiento y el orden de los usuarios se puede organizar la información del sitio web. Hay dos tipos de card sorting:

• Abierto. Los usuarios pueden agrupar las diferentes categorías temáticas con total libertad, haciendo tantos grupos como crean necesario.
• Cerrado. Se establece un número limitado de conjuntos, de forma que el usuario debe ubicar cada tema en uno de esos grupos. Por ejemplo, se establecen desde el principio los grupos “qué hacemos” “quiénes somos” “cómo lo hacemos” y el usuario debe incluir cada tema en una de esas 3 categorías.

Las metodologías tradicionales de desarrollo incorporan tareas y procesos que sirven para medir el éxito del proyecto desde diversos puntos de vista: calidad, por ejemplo, a través de los errores detectados en cada una de las entregas; calendario, contrastando el esfuerzo final en trabajador/día con las estimaciones realizadas al principio; costes, al poner en relación el presupuesto inicial y el gasto real. La lista sigue.

El problema -o el reto- es que ejecutar y analizar esas métricas no es, precisamente, el fuerte de las organizaciones que practican un desarrollo ágil. ¿Cómo medir entonces el éxito del proyecto? La clave está en la satisfacción del usuario. Aunque pongamos en práctica el proceso de forma impecable, siguiendo todos los pasos precisos, si el cliente final no está contento con el resultado, no hay éxito posible.

Esto nos conduce hasta la siguiente pregunta: ¿Cómo se mide la satisfacción de un cliente? La satisfacción es un término abstracto, así que a veces no queda más remedio que utilizar métricas subjetivas. Algunas son inequívocas, como que el cliente muestre una sonrisa de oreja a oreja. Pero desgraciadamente, las cosas no siempre son tan sencillas.

Define “éxito”. Por eso, conviene buscar desde el principio una especie de acuerdo o consenso entre el cliente y el equipo de desarrollo sobre lo que se entiende por “éxito”. Hay, desde luego, una serie de preguntas guía que conviene plantear antes de abordar el proyecto:

• ¿Cómo sería una aplicación de éxito para tu organización? ¿Cómo la definirías?
• ¿Qué es el éxito para ti? ¿Qué entiendes por éxito?
• ¿Cómo sabrás cuándo un proyecto ha tenido éxito?

Define “proyecto completado”. Y, en relación directa con lo dicho anteriormente, es necesario buscar un consenso también sobre cuándo y cómo se considerará que el proyecto ha sido efectivamente “completado”. Dónde acaba, vamos. Porque bien está lo que bien acaba…

Los usuarios de un grupo de discusión de Agile India proponen las siguientes métricas. El cliente quedará satisfecho si:

• Obtiene los resultados de negocio que esperaba al idear el proyecto
• Ha podido modificar y corregir el curso del proyecto según las exigencias de negocio
• Ha podido intervenir desde el principio en el desarrollo
• Ha podido asignar prioridades al desarrollo de las funcionalidades, consiguiendo la funcionalidad más apropiada en el plazo apropiado.
• Ha podido interrumpir el desarrollo de ciertas funcionalidades antes de que fuesen implementadas, porque se ha dado cuenta de que no iban a servir
• Ha establecido una relación bidireccional exitosa con el equipo de desarrollo
• No se ha llevado sorpresas durante el proyecto
• Considera que ha obtenido un buen resultado por el dinero invertido

Más información en Infoq y en agileindia.

¿Cómo ven tu web los buscadores? Puedes insertar aquí la dirección URL de tu sitio para obtener, al instante, un pequeño informe de posicionamiento. Hay que reconocer que esta empresa, dedicada al marketing online, ha creado una buena herramienta para promocionarse…

¿Nuevo en la metodología SCRUM? Henrik Kniberg ha creado una “lista de tareas” con todos los pasos que un equipo debe seguir para trabajar con metodología SCRUM sin meter demasiado la pata… Hay una versión con prioridades de primer nivel y otra, con la fuente muy pequeña, que muestra todos los pasos.

Es un hecho: las PYMES apenas invierten en desarrollos software a medida. Y es un sinsentido, porque podrían utilizar esos desarrollos para agilizar sus procesos y ahorrar costes; en definitiva, para hacer mejor las cosas gastando menos dinero.

Lo que está claro es que ese rechazo existe, y debe tener, por tanto, una explicación. Nuestra experiencia en ASPgems nos ha dado ocasión de hablar con muchos empresarios y gestores, y nos permite aventurar los siguientes motivos:

• Abandonados en mitad de la nada. La queja es muy común: “Muchas empresas nos han dejado tirados en mitad del proyecto, nunca han llegado a completarlo”.
• Miedo a la eternidad. Las PYMES piensan que el proyecto tardará en desarrollarse siempre mucho más de lo inicialmente previsto. Es un clásico: “Si el informático dice “es cuestión de días”, calculo semanas; si dice “semanas”, calculo meses; y si dice “tardaré un año”, entonces mejor ni hablamos…”
• Problemas a la hora de definir los requisitos. El espacio de trabajo habilitado para definir lo que la PYME necesita resulta inadecuado. La empresa nunca tiene tiempo de contar todo lo que sabe hacer, y no encuentra lugar para explicar lo que realmente necesita.
• Fuera de nuestro alcance. Todavía permanece la imagen de la tecnología asociada a grandes inversiones al alcance sólo de las grandes empresas.

Afortunadamente, el panorama ha cambiado, y mucho. Con la metodología de desarrollo ágil SCRUM, las cosas mejoran sustancialmente:

• Dentro del plazo. Nuestra experiencia en ASPgems nos indica que es perfectamente posible finalizar los proyectos dentro del plazo previsto. De hecho, llevamos casi 2 años entregando proyectos on-time. Y, de todas formas, en el caso de que no acabáramos a tiempo, el cliente recuperaría parte del dinero comprometido.
• El avance se ve y se toca. SCRUM permite que el cliente compruebe el avance del proyecto sobre la marcha, mediante entregas parciales. Esto supone una ventaja notable frente al método clásico, en el que el usuario debe esperar hasta el final para descubrir el resultado, que en ocasiones es toda una sorpresa. El riesgo añadido de no ver nada hasta el final es que, muchas veces, se ha estado circulando por la senda equivocada, y ya es demasiado tarde para rectificar…
• Más sencillo, mucho mejor. El análisis funcional no es necesario. Se sustituye por una lista de necesidades que todo el mundo puede comprender y compartir, desde el cliente hasta el último miembro del equipo.
• El último empujón. ¡¡Ya es posible quitar un 0 a la cifra de inversiones!!

En ASPgems queremos hacer llegar estas ventajas a las PYMES y, aunque la tarea no es fácil, lo que pensamos hacer es:

1. seguir haciendo bien nuestro trabajo con SCRUM y, sobre todo
2. comunicar a las PYMES el nuevo mensaje: hacemos bien nuestro trabajo y podemos ayudaros a hacer mejor el vuestro

¿Cuál es la mejor manera de adoptar “Agile” para una organización? ¿Hacerlo poco a poco, a partir de un proyecto piloto, o cambiarlo todo de golpe? El patrón más común sigue siendo el de empezar la transición a Agile con un proyecto piloto, para aprender de él y después extenderlo al resto de la organización. Normalmente se arranca con uno, dos o tres equipos de 5 a 10 personas cada uno. Sin embargo, también hay empresas que prefieren atacar el cambio a Agile de una sola vez, es decir, que apuestan por realizar la conversión “de golpe”. Veamos algunas de las posibles ventajas y desventajas:

POCO A POCO

Ventajas.

• Se minimiza el coste de los errores. No es lo mismo fallar con un solo equipo que hacerlo con 100…
• Permite seleccionar y centrarse en los equipos y los proyectos más exitosos, para vencer así las reticencias de los escépticos
• Siembra la organización con personas que actúan como embajadores para que otros comiencen a aceptar el cambio.

Desventajas.

• Las conclusiones del trabajo con un grupo pequeño no tienen por qué ser extrapolables a un proyecto mayor.
• Se tarda más en empezar poco a poco y escalarlo que en atacar el cambio de una sola vez.
• Se puede transmitir la sensación de que la empresa duda o desconfía del proceso ágil, y que por eso prefiere empezar por unas “pruebas” para tantear la situación.

DE GOLPE

Ventajas.

• Muestra el compromiso y la confianza de la empresa con Agile.
• Todo acaba pronto. Puede ser doloroso, pero no dura demasiado.
• Se evita el conflicto entre 2 procesos opuestos, el ágil y el tradicional, que de otra forma tienen que convivir, con los roces que eso implica.
• Los escépticos se ven obligados a asumir la estrategia de la empresa: no les queda otra opción, puesto que es la única estrategia posible.

Desventajas

• La transición es muy arriesgada. La empresa se juega el todo por el todo.
• Lo más probable es que la transición requiera una complicada reorganización de los equipos y las relaciones internas.
• El proceso puede generar mucho stress, presión y tensión.

Más sobre patrones de adopción de agile.

Y otras dos gemas:

1. PHP o Ruby, ¿quién corre más? Un blogero ha realizado un pequeño experimento para medir la velocidad de ejecución -en segundos- del código PHP y Ruby. También ha incluido Perl, Python y C++ en este “benchmarking” casero. Los resultados, aquí.
2. Una compañía de Manchester, 34SP, ha comenzado a ofrecer a sus clientes un servicio de hosting configurado específicamente para Ruby on Rails. Según su director técnico, “Ruby on Rails no funciona bien en un entorno de hosting compartido, así que para sacarle todo el jugo necesitas tu propio servidor. Pero dado que un servidor dedicado puede resultar demasiado caro, ofrecemos un servicio configurado para las aplicaciones de Rails con un frontend Apache“.

Scrumalliance sigue actualizando una lista con las empresas que han utilizado la metodología Scrum en alguno de sus proyectos. Su objetivo: identificar las compañías en las que podemos encontrar profesionales con los que charlar y discutir sobre Scrum y Agile. En definitiva, dar soporte a la comunidad.

La fuente de información proviene, normalmente, del entorno de las empresas listadas, así que hay que observar los datos con cautela y prevención. En cualquier caso, es una referencia interesante: según la lista, grandes empresas de diferentes ámbitos, como Adobe, Bank of America, BBC, Google, Merrill Lynch, Microsoft, Nokia o Siemens han confiado en Scrum para llevar a cabo alguno de sus proyectos. Y cada vez son más.

Para completar este “Scrum Pack”, una lección magistral a cargo de Ken Schwaber, uno de los fundadores de Agile Alliance y Scrum, y firmante del Agile Manifesto. El vídeo es de hace tiempo, pero no tiene desperdicio.