Principios Ágiles #4

Siguiendo con la temática de los principios ágiles, hoy voy a hablar del cuarto de ellos:

Business people and developers must work together daily throughout the project.

La gente de negocio y los desarrolladores deben trabajar de forma conjunta diariamente a lo largo del proyecto.

¿Gente de Negocio y gente de desarrollo?

Cuando se comienza un nuevo proyecto es lógico que el equipo de desarrollo (encargado de implementar una solución) no sea experto en el negocio del cliente. Por otro lado, un experto de negocio (encargado de explicar las reglas de negocio) casi nunca se interesará por el aspecto técnico (desde luego, ninguno que yo conozca). Ambos mundos están bastante separados, al menos sobre el papel, lo que provoca que sean incapaces de entenderse. No poseen un lenguaje común.

¿Por qué trabajar juntos de forma conjunta?
Obligar a que ambos mundos trabajen juntos de forma continua provoca que la separación entre ambos se reduzca. Obviamente, el objetivo no es que un desarrollador se convierta en un experto de negocio ni viceversa. Siempre existirá una cierta separación. El objetivo es construir un lenguaje común mediante el cual ambos grupos consigan entenderse y resolver sus dudas. Actualmente en el mundo ágil, dicho lenguaje común se plasma sobre todo en las pruebas de aceptación, definidas por la gente de negocio con ayuda del equipo técnico (Si queréis saber más sobre pruebas de aceptación pasaos por la próxima reunión de Agile-Spain Madrid).
Cuando ambos grupos empiezan a colaborar se empieza a reducir la brecha que los separa. Comienza a aparecer un sentimiento de equipo y una visión global del producto.

¿Por qué diariamente?
No vale con reuniones esporádicas, debe ser un esfuerzo continuo. No vale que los grupos se reunan una vez al mes para tratar ciertos temas y que después cada uno se marche a su cubículo. Si un desarrollador se encuentra con que tiene que tomar una decisión de negocio debe acudir a los expertos de negocio para que se la resuelvan. Si un experto de negocio quiere conocer que tal va el desarrollo de una funcionalidad X debe acudir al desarrollador para que le informe. Obviamente, esta colaboración no se puede llevar a cabo sin confianza y transparencia. No me sirve de nada que los desarrolladores estén siempre disponibles para el experto de negocio pero le mientan sobre el estado del proyecto.
Este trabajo diario no es sencillo de llevar a cabo. Muchas veces los desarrolladores no queremos levantar la cabeza del ordenador. Otras muchas los expertos de negocio no tienen tiempo (ni ganas) de reunirse con los "frikis". Por eso, es necesario un compromiso por ambas partes. Si alguno de los dos no se compromete se deja de ser ágil.

Conclusiones
El cuarto principo ágil:

• Busca que la gente de  negocio y la gente técnica hablen un lenguaje común que favorezca el entendimiento.
• Refuerza el sentimiento de equipo aumentando la confianza entre sus componentes.
• Implica compromiso.
• Obliga a la transparencia.

Imagen de "portada": Galería de thinkpublic, bajo licencia Creative Commons.