Introducción
¿Quién, entre todo agilista que se precie, no conoce el Manifiesto Agile? Si leen estas líneas, este documento no les es desconocido. Quizá conozcan algunos de sus valores, incluso todos, y para los más académicos, los principios … de memoria.
Pero, ¿conocen la declaración de los derechos Agile? ¿No? No es sorprendente, esta declaración claramente no se ha hecho un lugar bajo los focos como lo hizo su primo el manifiesto. ¿Por qué digo primo? Porque fue una parte de los firmantes del manifiesto, en esa misma reunión en Snowbird, quienes escribieron esta declaración. (« sous la plume de Kent Beck, Ward Cunningham, Ron Jeffries et quelques autres »)
Fue leyendo el excelente «Agile Proprement» de Robert C. Martin que lo descubrí. Si aún no lo han leído, no puedo más que animarles a conseguir un ejemplar de este libro y a devorarlo, como una historia cautivadora que les contaría su gran-tío aventurero. Seguramente haré un artículo especial para hablar de él más extensamente, pero por ahora, quiero darles a conocer esta pepita desconocida que es la declaración de los derechos Agile, descubierta tras las 50 primeras páginas de este libro.
Declaración de los derechos
| Derechos del cliente | Derechos del desarrollador |
|---|---|
| Tiene derecho a obtener un plan de conjunto y a saber qué puede realizarse, cuándo y a qué coste. | Tiene derecho a saber qué se espera de usted, con una declaración clara de las prioridades. |
| Tiene derecho a obtener el máximo valor posible al final de cada iteración. | Tiene derecho a producir código de gran calidad en todo momento. |
| Tiene derecho a poder constatar el avance de un sistema funcional, cuya calidad ha sido probada por pruebas reproducibles que usted ha especificado. | Tiene derecho a pedir y a recibir ayuda de sus colegas, sus managers y sus clientes. |
| Tiene derecho a cambiar de opinión, a reemplazar una funcionalidad por otra y a modificar las prioridades sin sufrir un sobrecoste exorbitante. | Tiene derecho a hacer sus propias estimaciones y a actualizarlas. |
| Tiene derecho a ser informado en todo momento de los cambios en el planning y en las estimaciones, y con suficiente antelación para poder decidir reducir el ámbito funcional si necesita hacer respetar una fecha fija. Debe poder cancelar el proyecto en todo momento y obtener un sistema funcional en proporción al presupuesto ya consumido. | Tiene derecho a aceptar las responsabilidades en lugar de verlas infligidas. |
He presentado voluntariamente los derechos de las 2 partes en forma de tabla, porque, como dice el autor del libro, cada derecho responde al otro y viene a completar el derecho de la otra parte. Les dejaré descubrir las explicaciones detalladas de cada derecho en el libro, pero sin parafrasearlo, voy a permitirme darles mi visión.
Punto de vista
-
(cliente) Por asombroso que pueda parecer, empieza por decirnos que hay que hacer estimaciones ¡y sobre el conjunto del proyecto! Pero con cierto matiz: esta estimación debe ser lo más precisa y exacta posible, en el estado actual de los conocimientos del equipo. Tampoco debe conducir a un compromiso de fecha o de perímetro. Recomienda proporcionar probabilidades de plazos de realización. Lo que permite al cliente un pilotaje correcto de sus actividades
(dev) Por su parte, es la priorización la que está en el punto de mira. Este precioso conocimiento puede parecer en oposición a la acogida del cambio, que es normal en agilidad. Por eso no puede ser fija para el conjunto del proyecto; solo, como mínimo, para la iteración en curso, en el mejor caso, para 2 o 3 iteraciones. -
(cliente) Es un derecho que se muerde un poco la cola, pues es el cliente quien prioriza la producción, pero es responsabilidad de los dev respetarla
(dev) Es un derecho que a menudo se recorta, aunque es esencial e inalienable. Toca la razón de ser de todo desarrollador que se precie. Burlarlo se paga caro a largo plazo. -
(cliente) Todo cliente que haga un mínimo de seguimiento debería ser muy exigente con este derecho. Es su dinero y su tiempo los que consumen los dev. Tanto vale verificar que se usa bien.
(dev) La comunicación es el centro de este derecho. Comunicar los conocimientos, las exigencias, las prioridades. Sin ello, ¿cómo exigir a los dev estimaciones, calidad, producción de valor? -
(cliente) Por la naturaleza inmaterial de un software, todo cambio debería ser posible, aceptando al mismo tiempo los sobrecostes generados.
(dev) ¡Son quienes hacen quienes saben! Y es haciendo como se puede apreciar mejor la carga de trabajo necesaria. Sin embargo, sigue siendo una estimación, que puede ser falsa o inexacta, por lo que no es un compromiso firme. -
(cliente) El derecho del cliente aquí es el de ser mantenido informado; no tiene derecho a exigir el cumplimiento de los plazos. Esto le es esencial para reaccionar en función de los acontecimientos, aunque sea cambiando de opinión, de orientación o directamente cancelando el proyecto si es necesario, sin que eso pueda reprochársele. Al fin y al cabo, no es más que el derecho a ser un buen gestor
(dev) Por un lado, se puede ver algo de Lean con un flujo tirado. Por otro lado, se puede ver la apreciación del dev. ¿Se siente legítimo? ¿Es legítima la petición? ¿Va en contra de sus convicciones? Este derecho es, al final, bastante importante y cargado de sentido. Nadie debería verse obligado (astucia o manipulación incluidas) a realizar una tarea que va en contra de su bienestar.
Conclusión
Esta declaración de los derechos de los clientes y de los dev no es revolucionaria. Viene a apoyar y a reforzar lo que ya se encuentra en el manifiesto. Pero su ángulo de ataque diferente permite iluminar mejor la relación que deberían tener los clientes y los equipos de dev. Fue escrita con esa intención: « réparer la fracture entre l'entreprise et les développeurs ».
