Tecnolack - blog de cultura geek

Curso básico de agile: Los cuatro valores del manifiesto (Parte 2)

account_circle Por Sagara access_time 23 de enero del 2020

Esta es la continuación de la publicación ¿qué es agile?. La filosofía agile se basa en el manifiesto que consta de cuatro valores y 12 principios. Para dar continuidad con nuestro curso básico de agile ahora analicemos los cuatro valores del manifiesto.

Desde su sitio oficial pueden leer aquí en Español los cuatro valores del manifiesto. Sé que la simplicidad de los valores puede llegar a ser complicados, confundir sobre su significado y hacer casi imposible su interpretación para aplicarlos en la práctica.

 

Los cuatro valores

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

Antes de poder dar una interpretación, entendamos el texto bajo los valores del sitio oficial: «Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.»

La palabra sobre sirve como una guía para entender qué es lo más importante para agile. La parte izquierda de cada valor es más importante. Pero esto no quiere decir que la parte derecha sea omitida o desechada.

Analicemos y ejemplifiquemos cada uno de los cuatro valores

  • Individuos e interacciones sobre procesos y herramientas

El primero de los valores, nos dice que se le debe dar más importancia a las personas antes que todo lo demás. Esto no quiere decir que no se deben seguir los procesos o dejar de usar las herramientas establecidas por las empresas. Pero se debe dar voz y realmente escuchar a los empleados o clientes para hacer cambios necesarios. Esto es de extrema necesidad para cambiar y mejorar las interacciones.

Podemos adoptar este valor al analizar los procesos actuales paso por paso y encontrar si todos esos pasos son en verdad necesarios o cuáles dejaron de serlo. Encontrar lo que no genera valor y solo se hacen por mera «tradición».

  • Software funcionando sobre documentación extensiva

Antes que nada, si se debe documentar, pero solo la documentación mínima necesaria para dar prioridad al software o aplicación que se esta desarrollando, antes que tener manuales de uso sobre un producto que no hace lo que tiene que hacer. Esto no solo se limita a manuales o guías de uso, también a esos cientos de reportes, métricas o evidencias de «pruebas» (test cases).

Podemos adoptar este valor al incluir prácticas de ingeniería en el equipo de desarrollo (pairing, BDD, TDD, etc.). Otra forma es la de permitir a los testers colaborar en conjunto con los developers, en el mismo lugar de ser posible, para revelar riesgos del software. Y no mantener a los testers alejados, siguiendo flujos herméticos no reales para satisfacer porcentajes o métricas absurdas. Por ejemplo, el revisar solo el happy path, no dándoles libertad para que en verdad aprendan y prueben profundamente la aplicación. Y entre todo el equipo aseguren desarrollar una aplicación funcional.

  • Colaboración con el cliente sobre negociación contractual

Para agile es muy importante la colaboración con nuestros clientes o partes interesadas. Si es verdad que puede llegar a ser abrumador pensar en contratos pero ser agile es transformarse desde la cúspide. De nada servirá ser un equipo agile, si tu cliente o tu líder no lo es.

Se puede pensar en contratos de tal forma que den la bienvenida a esa colaboración. Por ejemplo, clausulas del tipo «Si el representante del cliente asiste a todas las demostraciones semanales del software, se le regalara al cliente 1 semana de desarrollo gratuito».

La clave es la colaboración constante para desarrollar algo que en verdad sirva a nuestros clientes.

  • Respuesta ante el cambio sobre seguir un plan

La industria del TI ha alejado a muchos clientes en el pasado, al no responder a los cambios de sus industrias. Es por ello que debemos aceptar cambios de manera rápida y de una manera que sea beneficiosa para ambas partes.

Tradicionalmente recibíamos los requerimientos y al final de un periodo largo de desarrollo, entregábamos el software. Para este punto ya había cambiado el panorama del cliente, si este requería correcciones o cambios, por norma general, se hablaba de peticiones de cambios (change request) que costaban más a nuestro cliente.

Los cambios de último momento a causa de la necesidad del cliente, interpretaciones malas o asunción de requerimientos, rechazo o desagrado del cliente ante experiencia de usuario o diseño.

Para todo ello, se deben de abrir oportunidades para los cambios, comentarios o nuevas peticiones, de acuerdo a las necesidades del cliente, considerando las capacidades del equipo de desarrollo y teniendo en claro un flujo previamente acordado a seguir, de tal forma que sigamos respetando cada uno de los valores del manifiesto.

Para discutir, compartan en los comentarios:

  1. ¿En su empresa, equipo o área de trabajo siguen los cuatros valores?
  2. ¿Qué dudas tienen sobre los valores?

Es muy complicado ser agile únicamente con los valores y sus interpretaciones, en la siguientes publicaciones explicaremos los 12 principios para ayudarnos a entender mejor cómo ser agile.

Fuentes:

@Mail
Recibe actualizaciones vía email.