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

Posteado May 26, 2008 a 9:22 am por ansueta Feed Articulos

3 prácticas extraídas del desarrollo de software ágil que puedes aplicar en tu empresa para mejorar la productividad del equipo y la calidad del trabajo:

1. Un espacio de trabajo adecuado para el equipo

Aunque a alguno todavía le parezca cosa de magia, las barreras físicas afectan directamente a la comunicación entre los diferentes componentes de una empresa o de un equipo, y condicionan las relaciones que se establecen entre ellos. Las paredes en una oficina, los pasillos e incluso los separadores que se interponen entre dos empleados que se sientan frente a frente pueden entorpecer la comunicación fluida y constante que estamos buscando.

Oficinas en el cuartel general de Google

Algunas ideas:

  • Luz, buena ventilación y plantas.
  • Espacios compartidos en los que la gente trabaja frente a frente, codo con codo. Y espacios semi-privados para mantener reuniones y conversaciones telefónicas.
  • Grandes corchos y pizarras para apuntar ideas, esquemas o procesos y poder compartirlos con el equipo.
  • Buenas sillas y mesas, y equipos informáticos actualizados.
  • Cada persona puede “configurar” su espacio a su gusto, con sus plantas, sus carteles, sus juguetes.
  • Es mejor que el espacio esté abierto a los miembros de otros equipos de la empresa, y que puedan acercarse cuando quieran para ver qué se cuece y cómo se trabaja.
  • Servicios de primera necesidad: es conveniente que los baños, las impresoras o la máquina de café se encuentren cerca del área de trabajo.
  • Si la comunicación es abierta, fluida y continua, es muy probable que, en ocasiones se vuelva un poco ruidosa. Así que es mejor que haya suficiente espacio entre el espacio del equipo y otras áreas de la empresa, de manera que no llegue a molestar.

2. Ciclos de trabajo cortos

Aunque este apartado está muy ligado al desarrollo de software, en esencia puede aplicarse a casi cualquier ámbito: si el objetivo -llamemosle entrega- está muy alejado en el tiempo, la motivación del equipo decrece y acaba por desinflarse. Resulta mucho más apasionante descomponer el proyecto en tareas más reducidas y con entregas más frecuentes en el tiempo. En el desarrollo ágil de software se trabaja, por ejemplo, mediante sprints que duran una semana. Resulta muy recomendable ver el planteamiento de la metodología Scrum.

La motivación es la base de la productividad. Si no alcanzamos a ver el final, es muy fácil que cunda la relajación/aburrimiento entre el equipo, y que cuando llegue el momento de realizar la entrega, se produzca el desastre… Los ciclos de trabajo cortos generan una especie de “presión”, pero esta presión, lejos de desmoralizar, motiva a los integrantes del equipo y les ayuda a superar las situaciones complejas del proyecto. Eso sí: para que este sistema funcione, es necesario confiar en el equipo, y permitirle que se auto-gestione y se organice para superar las situaciones más complicadas. Esa confianza es la mejor manera de generar compromiso en los miembros del equipo.

3. Pon el trabajo a prueba

Durante el proceso de diseño y construcción de cualquier producto o servicio surgen muchos cambios, nuevas peticiones, añadidos, correcciones, etcétera. Y la clave fundamental del éxito estriba en ser capaz de responder a esos cambios con agilidad. Se trata de evitar esa situación tan temida: hemos acabado el producto, y sólo entonces nos hemos dado cuenta de que hay que incorporar tantos cambios y modificaciones que ese producto, simplemente, ya no sirve. Es demasiado tarde para cambiar. Si estás construyendo, pongamos por caso, una web, no esperes al final para ver si al cliente le gusta, o para comprobar que funciona como estaba previsto.

Es necesario incorporar los cambios a lo largo de todo el proceso, manteniendo una comunicación fluida en el equipo y con el cliente. Es la manera en que podremos ir creciendo y aprendiendo, en un proceso de mejora continua que realmente estimulará a todos los miembros del equipo.

Plantéatelo así: los cambios son fruto del conocimiento; surgen cuando descubrimos algo más sobre el producto, sobre las necesidades del usuario o sobre las peticiones del cliente. Incorporar ese cambio es todo un reto pero, si lo superamos, podemos estar seguros de que nuestro producto o servicio es mejor que antes de introducir la modificación.

Aunque parezca lo contrario, la calidad no tiene por qué estar siempre reñida con la velocidad. En el mundo del desarrollo software se utiliza un método ágil conocido como Test Driven Development que consiste, básicamente, en lo siguiente: en un escenario de ciclos de trabajo cortos y cambio constante, cuando se decide incluir una nueva funcionalidad, primero se crean unos “casos de prueba” que la aplicación tiene que superar para cumplir con los requisitos, y después se realiza la programación para que la aplicación supere esos casos de prueba. Es decir, no se programa primero y se testea después, sino que, partiendo de los requisitos, primero se determina el test que hay que superar y después se crea el código necesario para pasar la prueba. Este método permite realizar el trabajo a muy buen ritmo reduciendo notablemente los defectos y errores.

Algo más sobre el tema pero más enfocado en el desarrollo de software.

2 Commentarios Publicado en: General, Productividad, Tendencias

Tags: , , ,

“Menos” puede ser mucho “más” también en las aplicaciones informáticas

Posteado April 18, 2008 a 3:34 pm por ansueta

La idea de que una aplicación es mejor cuantas más funcionalidades ofrece no siempre está justificada. Desde luego, no en el caso de los autónomos y las pequeñas y medianas empresas, que normalmente realizan tareas muy concretas, y cuentan con estructuras reducidas y recursos limitados. Por eso, a la hora de elegir o construir la aplicación que necesitas, conviene tener en cuenta que “menos” puede acabar siendo “mucho más”, tal y como sucede en otras disciplinas. Es decir, que concentrarse en las funcionalidades clave, en las que de verdad aportan valor a tu negocio, puede ser el mejor método para conseguir el software de gestión más adecuado.

Sencillez

Si el otro día hablábamos de la agilidad que ofrece SCRUM para gestionar proyectos, y de la transparencia que caracteriza a las aplicaciones de código abierto, en esta ocasión nos centraremos en la sencillez. Esta pequeña pequeña y práctica filosofía puede condensarse en sólo tres palabras: “menos es más”, y consiste en diseñar sitios web y aplicaciones sencillas, que hacen exclusivamente aquello que necesitamos y no otra cosa. Nada más y nada menos. El objetivo es que podamos concentrar nuestro esfuerzo y nuestros recursos en hacer muy bien nuestro trabajo del día a día, las tareas que realizamos siempre. Vamos a analizar esta perspectiva con un poco más de detalle.

¿Menos es más?

El problema

Durante muchos años, el principal objetivo de los proveedores de software ha sido ofrecer al usuario el máximo de opciones y funcionalidades. Parecía que la única forma de competir era superar en número al adversario: más funciones, más presupuesto, más recursos.

Como consecuencia de esta “escalada” continua, hemos creado aplicaciones gigantes, diseñadas para satisfacer las necesidades de un “super-usuario total” que en realidad no existe. Al intentar cubrir todas las necesidades, estas aplicaciones se han vuelto demasiado complejas, incómodas e ineficientes para realizar algunas tareas que pueden ser básicas para nuestro negocio. Esto ha hecho que mucha gente haya decidido replantearse la filosofía de “cuanto más, mejor”.

Como hemos mencionado, los autónomos y las PYMES necesitan herramientas que les ayuden a desempeñar de manera eficaz su trabajo diario. El uso de una aplicación sobredimensionada -que ofrece muchas más funcionalidades de las que luego se van a utilizar- puede presentar las siguientes desventajas:

  • Es difícil que estas aplicaciones hagan exactamente aquello que necesitamos, porque no están diseñadas pensando en nuestra labor concreta, sino en cubrir el máximo de funcionalidades. Un ejemplo clásico: necesitamos apuntar nuestros gastos del mes y, al final, acabamos utilizando una complicada hoja de cálculo para introducir media docena de importes. La potencia de la hoja de cálculo no está en discusión pero, ¿realmente es este el programa que más nos facilita el trabajo?
  • El esfuerzo que se ha invertido en desarrollar ese máximo de opciones y funcionalidades es un esfuerzo que se ha dejado de invertir en mejorar otras funcionalidades vitales para nuestro negocio (ver la eficiencia de Pareto más abajo).

Sea por la complejidad de la aplicación, sea por lo restringido de nuestras tareas, no siempre llegamos a utilizar todo el potencial disponible. Estas opciones y funciones “inútiles” -al menos para nosotros- pueden generar los siguientes inconvenientes:

  • Ocupan espacio en el interfaz y en la mente del usuario, por lo que resultan más complicadas de entender y perjudican a la usabilidad de la aplicación
  • Consumen recursos: pueden consumir memoria y son más caras y complicadas de mantener
  • Cuestan más: son funcionalidades por las que el cliente tiene que pagar aunque no las utilice. Incluso aunque no se pague estrictamente por funcionalidad, el esfuerzo invertido en su desarrollo acaba repercutiendo en el precio final.

Siguiendo en la misma línea, un sitio web repleto de funcionalidades resulta:

  • Más caro de hacer
  • Más caro de mantener
  • Más difícil de entender

Por eso es tan importante tener claro qué es lo que realmente necesitamos.

Lógicamente, esto no significa que las grandes aplicaciones genéricas no sirvan. Desde luego, para las grandes compañías, que cuentan con una amplia estructura, puede tener todo el sentido del mundo disponer de un sitema ERP muy complejo. Para el resto, no siempre está tan claro.

Esta reflexión es común en casi cualquier disciplina. Tomemos un ejemplo muy simple:

Imagina una navaja suiza multiuso. Con ella puedes cortar el pan, puedes descorchar una botella o cortarte las uñas; puedes incluso soltar una tuerca, o utilizarla como un palillo para los dientes…

Está muy bien que esa herramienta te ofrezca tantas posibilidades pero, si lo único que quieres es cortar el pan cuando vas de paseo al campo, ¿para qué quieres una navaja multiuso?

En cierto modo, es tirar el dinero. Es mejor que te compres una navaja sencilla pero que se ajuste a lo que de verdad vas a hacer con ella. Que pese poco y que tenga un filo dentado para cortar mejor el pan. Eso es lo que tú necesitas. Y, además, te va a costar menos dinero.

A medida

Una de las posibilidades destacadas para encontrar la herramienta que buscas es un desarrollo a medida. Hace apenas 5 años, los precios y la tecnología hacían poco viable esta opción para las empresas pequeñas. Hoy, la competencia entre proveedores y la aparición de nuevas aplicaciones y herramientas ágiles, tipo Ruby on Rails, permiten realizar desarrollos sencillos en tiempos record. Sin duda la situación ha cambiado.

Como comentamos en un post anterior, también ha ganado peso el uso de aplicaciones de código abierto. Algunas han sido adaptadas y mejoradas por la comunidad para ajustarse a determinadas necesidades. Si, aún y todo, no satisfacen tus exigencias, siempre puede tomar una de ellas como punto de partida para después realizar una personalización.

“Menos” no significa “nada”

La filosofía de “menos es más” nos propone una reflexión interesante. Pero, como sucede con casi todo, si la llevamos al extremo puede perder su sentido. Es decir, si ese “menos” pasa a ser tan poco, tan poco que casi ni se nota, entonces no sirve para nada. Es lo que algunos, en tono jocoso, han denominado “menos es morro”: la aplicación hace tan pocas cosas, y de forma tan limitada, que resulta una tomadura de pelo…

En cualquier caso, antes de buscar o desarrollar la aplicación que necesitas, resulta muy útil plantearse la siguiente pregunta: ¿cuáles son las tareas que realizo en el día a día y que aportan valor a mi negocio? La aplicación debe dar la mejor respuesta a esta pregunta con los recursos disponibles.

Algunas ideas clave

El origen de la expresión “menos es más”. El arquitecto Mies van der Rohe, director de la conocida Escuela de la Bauhaus, hizo famoso el aforismo “Menos es más” (less is more). En 1929 recibió el encargo de proyectar el Pabellón de Alemania en la Exposición Internacional de Barcelona. Su edificio se convirtió en la gran atracción del evento, y una de las obras más innovadoras por su simpleza y funcionalidad. Mies conquistó a los usuarios. Y su aforismo “menos es más” pasó a la historia.

La navaja de Occam. La navaja de Occam es un razonamiento basado en una premisa muy simple: en igualdad de condiciones la solución más sencilla es probablemente la correcta. El postulado es algo así como “no debe presumirse la existencia de más cosas que las absolutamente necesarias”. Más

Eficiencia de Pareto. El concepto de eficiencia de Pareto dice que no es posible beneficiar a más elementos de un sistema sin perjudicar a otros. Se basa en criterios de utilidad: si algo genera o produce provecho sin perjudicar a otro, provocará un proceso natural hasta alcanzar el punto óptimo. En una reinterpretación libre, algunos traducen la eficiencia de Pareto en algo así como: concéntrate en ese 20% del trabajo que te va a permitir alcanzar el 80% de tus objetivos. Más

¡Mantenlo sencillo, estúpido! Traducido del inglés Keep It Simple Stupid (KISS), es un principio que recomienda el desarrollo informático empleando partes sencillas y comprensibles, y que rechaza los sistemas enrevesados.

1 Commentario Publicado en: General, Productividad, Tendencias

Tags: , , , , , , , , ,

SCRUM: metodología “ágil” para tus proyectos

Posteado April 2, 2008 a 9:24 pm por ansueta

En muchas ocasiones, los modelos de gestión tradicionales no nos sirven para afrontar un reto que hoy en día resulta fundamental: incorporar cambios con rapidez y en cualquier fase del proyecto. Se trata de evitar lo que tantas veces nos ha ocurrido: cuando el proyecto se encuentra bastante avanzado nos damos cuenta de que no vamos por el buen camino o, simplemente, el cliente decide introducir cambios sustanciales, y esos cambios nos obligan a tirar por la borda todo el trabajo realizado hasta entonces, y nos impiden acabar en el plazo previsto.

Dado que los cambios nunca van a dejar de existir, lo que necesitamos es ser capaces de gestionar los proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses Takeuchi y Nonaka estudiaron las prácticas de empresas con buenos resultados de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packard. De ahí extrajeron la base de la metodología SCRUM que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta consolidarse en campos de actividad muy diferentes.

Seguro que puedes utilizar algunas de sus técnicas y procedimientos para mejorar la gestión de los proyectos en tu empresa. Estas son algunas de las claves de SCRUM:

Mejor con equipos pequeños y auto-organizados

Los equipos pequeños y formados por miembros de diferentes disciplinas consiguen mejores resultados. Es fundamental que el equipo pueda organizarse por sí mismo y la comunicación sea transparente. Esta es la manera de que todos los miembros se compromentan y se encuentren motivados. De hecho, la palabra SCRUM procede del vocabulario del rugby y significa melé; es decir, esa “figura” en la que los compañeros del equipo se amontonan, forman una piña y empujan todos en la misma direccion.

Scrum

Punto de vista del usuario

La recogida de requisitos para crear un producto se realiza teniendo en cuenta la visión del cliente y del usuario. Para ello se utilizan las historias de usuario, unas sencillas tarjetas en las que se recoge -de forma esquemática y en un lenguaje claro- QUÉ es lo que queremos hacer.

Con esas historias de usuario construimos la lista de requisitos del producto o “product backlog”. A cada item de la lista se le asigna una prioridad. El equipo tiene que estimar cuánto tiempo es necesario para realizar cada una de las tareas.

Sprints cortos, entregas frecuentes

El mercado exige ciclos de desarrollo cada vez más cortos. Para lograrlo se utiliza el sprint de requisitos o “sprint backlog”, una lista en la que se detalla CÓMO se van a construir los diferentes requisitos del producto.

Los requisitos del product backlog se “trocean” para transformarlos en tareas de no más de 16 horas. Cada sprint suele realizarse en un plazo de entre 2 y 4 semanas. Al final, el objetivo es entregar algo que funcione, para el usuario pueda probarlo y se puedan introducir los cambios necesarios antes de que sea demasiado tarde. Esto es lo que nos permitirá ser flexibles.

Roles dentro de SCRUM

Aunque suene a broma, los roles se dividen en dos: los “cerdos” y los “pollos”. Y la mejor manera de entender la diferencia entre unos y otros es un chiste:

Un cerdo y un pollo van caminando por la carretera. El pollo le dice al cerdo:
-Oye, ¿por qué no abrimos un restaurante?
El cerdo se vuelve y le responde:
-Buena idea, ¿cómo quieres que lo llamemos?
El pollo se lo piensa y propone:
-¿Por qué no lo llamamos “Huevos con jamón”.
-No cuentes conmigo -responde el cerdo-. En ese caso, tú sólo estarías IMPLICADO, mientras que yo estaría realmente COMPROMETIDO.

Siguiendo esta lógica, el papel de los cerdos -que son los que están realmente comprometidos, porque son los que contribuyen con su “jamón” al proyecto- lo desempeñan:

  • El product owner o dueño del producto, que representa la voz del cliente y aporta la visión de negocio. Él se encarga de escribir las historias de usuario, les da prioridad y las ubica en la lista de requisitos del producto.
  • El ScrumMaster o facilitador, que tiene como principal papel el de dejar el camino libre de obstáculos e impedimentos para que el resto del equipo consiga el objetivo del sprint.
  • El equipo, que tiene la responsabilidad de entregar el producto. Lo ideal es que incluya entre 5 y 9 miembros, y que pertenezcan a diferentes disciplinas (desarrolladores, diseñadores, etc.).

El papel de los “pollos”, que no son actores esenciales pero sí están implicados y deben ser tenidos en cuenta, lo juegan:

  • Los usuarios del producto o aplicación.
  • Los clientes y vendedores.
  • Los gestores y directivos.

Reunión diaria. Transparencia total

Una de la figuras fundamentales de la metodología SCRUM es la reunión diaria de todo el equipo. Tiene que hacerse de la siguiente forma:

  • La reunión es diaria y se hace siempre a una hora predefinida, normalmente por la mañana. Es importante que todos los miembros del equipo acudan puntuales.
  • La reunión debe durar alrededor de 15 minutos y se realiza de pie, para mantener el máximo de concentración y atención.
  • Todos los roles son bienvenidos, pero sólo los “cerdos” pueden hablar
  • En la reunión se realizan las siguientes 3 preguntas clave: 1. ¿Qué has hecho desde ayer? 2. ¿Qué tienes planeado hacer mañana? 3. ¿Has encontrado algún problema para conseguir tu objetivo?
  • Uno de los puntos más importantes es el de la transparencia: todos los miembros saben que están haciendo os demás, y los problemas deben ser sacados a la luz en cuanto se detectan.
  • En definitiva, SCRUM permite la creación de equipos motivados, capaces de organizarse por sí mismos, donde la comunicación y la transparencia es total. Y además, con esta metodología, el usuario gana protagonismo y el cliente se convierte en parte del equipo de desarrollo.

    Ejemplo

    Algunas herramientas ágiles

    Los métodos de desarrollo ágil ponen el énfasis en la comunicación “cara a cara” y en los resultados más que en la generación de documentación y, por eso, muchos de sus procesos pueden llevarse a cabo prácticamente sin herramientas. 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 proponemos las siguientes:

    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.

    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.

    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.

    24 Commentarios Publicado en: General, Productividad

    Tags: , , , , , , , , ,