5 pasos para implantar un proceso ágil

Si todavía no has implantado técnicas ágiles en tu equipo de desarrollo y estás considerando la adopción de alguna metodología te presentamos 5 cambios que permitirán incrementar la productividad de forma significativa. Mira el siguiente gráfico y pregúntate cual es el coste del cambio en tu organización.

Esta entrada pretende recoger algunos consejos que puedan facilitar al cambio en organizaciones y equipos hacia el agilismo. La visión que se refleja en esta entrada es el resultado de 6 años de trabajo en proyectos de implantación de métodos ágiles.

Esta entrada pretende recoger algunos consejos que puedan facilitar al cambio en organizaciones y equipos hacia el agilismo. La visión que se refleja en esta entrada es el resultado de 6 años de trabajo en proyectos de implantación de métodos ágiles.

1. Paradigma.

El agilismo no consiste en sustituir unas prácticas (de un modelo en cascada) por otras. Seguir un proceso ágil de desarrollo implica modificar las ideas preconcebidas sobre la construcción de software, olvidar los dogmas (los ágiles también), someter las reglas de oro al escrutinio del sentido común.

Para empezar, pregúntate cómo cambiaría tu proceso si el coste de un cambio no fuera exponencial…

Familiarizate con los principios expresados en el Manifiesto Ágil.

Simplifica: «Do the simplest thing…»

Uno de los grandes mantras de eXtreme Programming es «Do the simplest thing that could possibly work». La idea es eliminar complejidad y favorecer el crecimiento orgánico a medida que conocemos más detalles sobre las necesidades del cliente.

Es muy importante tener en cuenta el cambio de paradigma del que ya hemos hablado para evitar ‘hábitos’ tan poco productivos como el diseño anticipado.

Practica la humildad, comienza con soluciones simples y evoluciona. ¿Quieres profundizar más? El diseño de interfaces de clase guiado por pruebas de unidad (test-driven development) te dará una nueva perspectiva.

Maximiza la Comunicación

Uno de los factores que más intervienen en el éxito o fracaso de un proyecto es la comunicación. En sentido amplio, dentro del término comunicación incluimos:

  • Entendimiento de los requisitos funcionales y no funcionales del cliente.
  • Estado del proyecto/producto.
  • Interfaz de Usuario
  • Calidad del software.
  • Conocimiento transversal en el equipo.

Como norma general deberemos implantar técnicas que conduzcan a maximizar la comunicación entre los participantes en el proyecto.

 2. Modelo orgánico

Comienza con un modelo de proceso Iterativo e Incremental.

Modelo Iterativo (proceso)

El modelo iterativo establece que el producto se construirá mediante la división del proyecto en subproyectos (iteraciones o sprints) que se ejecutarán de forma repetitiva.

I. Divide tu proyecto en subproyectos (iteraciones o sprints) cada uno de los cuales no deberá durar más de 4 semanas. Comienza por iteraciones de 2 semanas y ajusta según demande el equipo o proyecto.

II. Estima el coste de los requisitos en cada iteración. Si para algún requisito se ha estimado más de 1 semana de trabajo, divídelo en con ayuda del cliente.

III. Observa como aumenta la productividad del equipo en cada iteración/sprint. Mide la capacidad del equipo para afinar las estimaciones en la próxima iteración.

IV. Mantener un ritmo sostenido de entregas en iteraciones cortas aumenta la motivación del equipo y el compromiso del cliente.

Modelo Incremental (producto)

El modelo incremental establece que el producto se construirá mediante la incorporación de nuevas funcionalidades en cada iteración. Una definición que me gusta particularmente es la del modelo de crecimiento orgánico en el que el producto crece funcionalmente en cada iteración.

¿Cómo aplicamos este modelo al desarrollo de software? Aquí van algunos consejos:

I. Comienza con un conjunto de bloques de funcionalidad definidos y priorizados por el cliente. No es necesario disponer de TODOS los requisitos para arrancar el proyecto.

II. Selecciona en cada iteración los requisitos más valiosos para el cliente.

III. Un requisito se considera entregable cuando se ha implementado al 100%: Es mejor disponer de 9 requisitos al 100% que de 10 al 90%.

3. Prácticas

Visión

Los requisitos de usuario conforman la visión del producto. Deben estar expresados en un lenguaje que permita describir funcionalmente las necesidades del cliente. La funcionalidad contenida en la visión del producto debe tener información sobre el valor que aporta al cliente y medidas de prioridad. El orden en que se planifican los requisitos será una función del valor de negocio y el coste estimado (retorno de la inversión).

Planifica según la capacidad del equipo

Cada iteración o sprint comienza con una sesión de planificación en la que se seleccionarán los requisitos según el retorno de la inversión y la capacidad del equipo. Traduce los requisitos en tareas de desarrollo que servirán para planificar y asignar al equipo. Una vez planificada la iteración es el momento de resistirse al cambio; cualquier cambio de requisitos deberá esperar a la siguiente iteración.

Mide tu progreso

Las iteraciones cortas proporcionan dos ventajas fundamentales:

  1. Permiten comprobar el avance del proyecto en cada iteración garantizando que el estado es conocido en numerosos puntos de control.
  2. Favorecen que el seguimiento de la iteración se concentre en un breve periodo de tiempo.

Otras técnicas imprescindibles:

Reunión diaria: Debe ser muy rápida, idealmente no más de 15 minutos por lo que a veces se realiza de pié (stand-up meeting) y se deberá responder a 3 preguntas:

  1. ¿Qué se ha hecho desde la última reunión?
  2. ¿Que se pretende hacer hasta la siguiente?
  3. ¿Hay algún obstáculo que lo impida?

Integración Continua: La Integración Continua es una práctica ágil que sugiere realizar integraciones de producto de forma automática y frecuente. La integración continua permite no sólo identificar problemas sintácticos sino, también, realizar validaciones unitarias (mediante la ejecución automática de tests de unidad) y funcionales así como realizar métricas de calidad, cobertura de tests, etc. En Google encontrarás numerosas herramientas para automatizar los procesos de integración continua.

Entrega a cliente: Intenta que el cliente se involucre en el proyecto. Su papel será fundamentalmente el de resolver ambiguedades sobre los requisitos y su ‘valor de negocio’ así como el de validar el progreso del producto. La entrega frecuente aporta muchas ventajas:

  • Cada entrega es una oportunidad para medir el estado del producto. Contrasta el resultado con el cliente, valida la calidad, corrige estimaciones, monitoriza el progreso y celebra los éxitos con el equipo.
  • Introduce tests de unidad como parte del proceso de desarrollo. Construye y ejecuta los tests de forma frecuente.
  • Feedback. Prioriza la obtención de información del cliente. Técnicas como el prototipado evolutivo están dirigidas a construir el producto desde el interfaz para favorecer la validación temprana del cliente. No se trata de una maqueta (de usar y tirar) sino del producto final que iremos ampliando de forma incremental.

Haz piña! Fomenta el conocimiento del equipo, tanto sobre la funcionalidad como sobre la arquitectura, el diseño y la implementación. Define (de manera democrática) convenciones de estilo, diseño de soluciones, uso de frameworks, bibliografía relevante, etc. Realiza reuniones cada día (stand-up meetings o daily scrum) para resolver dificultades. Realiza revisiones de código (busca voluntarios).

4. Herramientas

Los métodos nos aportan disciplina y control sobre el proyecto. Sin embargo la productividad solo se obtiene a través de un conjunto de herramientas colaborativas alineadas con nuestro proceso. A continuación enumeramos aquellas herramientas que consideramos imprescindibles:

  1. Gestión de Versiones/Configuración. Los cambios sobre el código deben ser almacenados de forma frecuente en el gestor de versiones para que puedan intervenir en los ciclos de integración continua favoreciendo el feedback ante conflictos o errores. Hay numerosas alternativas de código abierto: Subversion, Git, Mercurial y comerciales: PlasticSCM que te darán un rendimiento profesional.
  2. Gestión de Proyectos orientado a tareas. Almacena todos los requerimientos (funcionalidades, historias de usuario, épicas, product backlog items), tareas e incidencias en una herramienta que permita mantener la relación entre ellos así como información sobre valor de negocio, prioridad, orden, versiones de producto (sprints), etc. Los gestores de incidencias (issue trackers) pueden ser una buena alternativa aunque nosotros te recomendamos uno por encima del resto: JIRA.
  3. Seguimiento ágil de proyectos. Disponer de herramientas que nos proporcionan información actualizada sobre el estado de nuestro proyecto facilita la toma de decisiones para alcanzar los objetivos en cada iteración. Existen una gran cantidad de gráficas y vistas ágiles que nos ayudan en el seguimiento: tableros Kanban, gráficas de Burn-down, gráficas de Flujo Acumulado, etc. En nuestro caso, el seguimiento se realiza mediante el complemento ágil de JIRA: Greenhopper.
  4. Integración Continua. Automatiza la construcción periódica del producto, tanto para las entregas como para el despliegue en entornos de prueba. En el entorno de desarrollo, la construcción debería realizarse a diario para detectar problemas en el proceso de construcción. Existe un gran número de alternativas de código abierto: Hudson, Team City y comerciales. Entre estas últimas destacamos otra herramienta de Atlassian: Bamboo.
  5. Gestión Documental y wiki colaborativo. En un equipo ágil la comunicación debe ser máxima por lo que las herramientas colaborativas de gestión documental y creación online de información tienen una gran importancia. La implantación de este tipo de herramientas deberá ir acompañada de planes específicos de formación y seguimiento para asegurar de que desde el equipo se entiende la necesidad de invertir esfuerzo. Además de la oferta de código abierto destacamos una herramienta comercial que complementa perfectamente el resto de la suite: Confluence.

5. Mejora Continua

Aplica el modelo de crecimiento orgánico al proceso, identificando obstáculos (impedimientos) que tienen impacto en la productividad del equipo y diseñando acciones para eliminarlos o minimizar sus efectos. Comienza manteniendo reuniones formales (retrospectivas) donde el equipo aporte ideas e invita al cliente y otras áreas involucradas. Un momento ideal para realizar una sesión retrospectiva es tras una entrega. Realiza restrospectivas de manera frecuente (idealmente una por iteración), identifica impedimentos y diseña acciones correctoras. Resolver impedimentos será una tarea más en la próxima iteración…

Aplica el mismo principio para mejorar el producto favoreciendo la mantenibilidad del código. Si el diseño de una clase o solución supone un impedimento para construir nueva funcionalidad (o mantener la existente), refactoriza el código. ¿De verdad piensas que si algo funciona no debería cambiarse? Vuelve al principio del artículo y mira otra vez la gráfica del coste del cambio!

Pero, ¿por dónde empiezo?

El objetivo de esta entrada es agitar las conciencias de aquellos que todavía no saben si deberían cambiar el proceso en cascada por uno ágil. También pretende aportar una visión de conjunto sobre el calado de los cambios necesarios para agilizar un equipo de desarrollo de tecnología. Si ya has decidido iniciar el cambio en tu organización, te sugerimos algunos pasos en la buena dirección:

  1. Evangeliza: Es muy importante que la organización comprenda y acepte los cambios de paradigma en la forma de trabajar. Contrata a un experto que entienda las necesidades de un equipo (tanto ágil como tradicional) para que te ayude a marcar la hoja de ruta y las características de un método personalizado. Si la organización no está preparada TODAVÍA para el cambio, ajusta tus expectativas y busca ayuda para implantar aquellas prácticas ágiles compatibles con la cultura corporativa.
  2. Aplica el nuevo paradigma durante la implantación. Identifica un proyecto preferiblemente nuevo o que suponga un cambio de tecnología en el equipo y realiza un piloto durante algunas iteraciones. En nuestra experiencia, trabajar sobre un proyecto real a modo de piloto permite la introducción iterativa e incremental de prácticas ágiles estableciendo objetivos y revisando las características del proceso más adecuadas para cada equipo.
  3. Solicita ayuda. Existe una extensa comunidad de agilistas que aportan sus experiencias y conocimiento a la comunidad (http://agile-spain.org/). Si es posible, solicita ayuda profesional para conseguir los mejores resultados: en nuestra experiencia, un Scrum Master puede ayudar en la implantación de prácticas ágiles mediante un proyecto piloto en unas pocas semanas.

Espero que esta breve compilación de ideas os sea de utilidad.

Eduardo Mayor

Eduardo Mayor

CEO

Eduardo Mayor is a software engineer with 20+ years of experience. He is also the founder of Novagenia Information Technologies, a company focused on introducing agile methods and tools to companies worldwide.

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar