En estos más de 12 años de trabajar directamente con la agilidad y más de 20 como profesor universitario, constantemente en entrenamientos y cursos he hablado del manifiesto ágil, y cuando lo hago sigo el siguiente proceso:
- Muestro el manifiesto en inglés (no difiero mucho con la traducción) - agilemanifesto.org
- Lo presento en español - agilemanifesto.org/iso/es/manifesto.html
- Lo explico y discuto.
- Explico quiénes son los que firmaron el manifiesto ágil e invito a que los busquen y sigan en redes, blogs, empresas, Twitter, Facebook, Youtube, LinkedIn (como dicen modernamente, los invito a stalkear).
- Luego paso a los principios en español - agilemanifesto.org/iso/es/principles.html y similarmente los explico y discuto en detalle.
- Business people and developers must work together daily throughout the project.
- Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
- Los responsables de negocio y los desarrolladores debemos trabajar juntos diariamente durante todo el proyecto.
- Los responsables de negocio y los desarrolladores tenemos que trabajar juntos diariamente durante todo el proyecto.
- Los responsables de negocio y los desarrolladores tenemos la obligación de trabajar juntos diariamente durante todo el proyecto
- Working software over comprehensive documentation
- Software funcionando sobre documentación extensiva
- Software funcionando sobre documentación completa
- Software funcionando sobre documentación integral
Pongamos foco en el punto de dolor
Áreas de negocio perdidas en el contexto del desarrollo de software
- El proceso de desarrollo software es un proceso de adquisición de conocimiento (4), entre más se interactúa con el cliente, mejor se entiende su necesidad y lo solución es moldeada de acuerdo con el entendimiento de esta.
- Como lo afirmaba Watts S. Humphrey (conocido como padre de la calidad del software) "Para un nuevo sistema de software, los requisitos no serán completamente conocidos hasta después que los usuarios hayan usado el sistema", por lo tanto, implica una validación de la constante del software para descubrir la solución deseada (5).
- La complejidad creciente del software, la cantidad de conexiones de este y las posibles interacciones y comportamientos requiere de un proceso de acompañamiento de quien lo solicita.
- De una solución de software solo el 20% es usado frecuentemente, 30% usado algunas veces, 50% poco o nunca usadas (6). Por lo tanto, si queremos llegar a construir software más rápido debemos evitar a toda costa construir software que no será usado y esto solo se logrará con un ejercicio constante de priorización y validación por parte del cliente del área usuaria.
- Los requisitos de software son inestables en un mundo cambiante o VUCA (7). Actualmente los requisitos tienen una vida útil de seis meses o menos (8). Ver imagen continuación
Define un poco* de software a ser construido
↪ Construye lo poco anteriormente definido
↪ Entrega a los usuarios lo construido lo antes posible para validar si es lo requerido o no
Cerrando
Imagen generada con Dall-e (9) |
- Participa activamente en las sesiones del marco de trabajo
- Prioriza por valor el trabajo a realizar o Product Backlog
- Proporciona retroalimentación sobre el software funcionando
- Interactúa diariamente con el equipo
- Interactúa con tus usuarios y conócelos, valida sus expectativas y valida el uso de la aplicación una vez la comiencen a usar
- Si careces de tiempo para estar con el equipo solucionador, y quieres entregar los requerimientos y que otros lo construyan sin tu compromiso; la agilidad y el construir soluciones de software de alto valor y retorno no es lo que tu o tu organizacion están buscando; y con seguridad construirás software de desperdicio.
- Involucra y compromete al cliente
- Muéstrale el valor de participar con el equipo
- Enséñale a priorizar
- Garantiza a que comprenda el valor de las entregas tempranas
- Compártele experiencias de otras personas en la industria acerca de usar marcos ágiles
- Instrúyele como puede generar valor más rápido con menos alcance
- Convéncelo que en escenarios de incertidumbre su interacción diaria y continua es garantía de éxito.
- Demuestra progreso con software de valor funcionando en periodos de un mes o menos, con preferencia al periodo más corto.
Ahora, respecto a las traducciones del tercer principio del manifiesto,
usa la que mejor se adapte a tu entorno.
Nota de agradecimiento
- Openess, traducido como apertura normalmente, pero una traducción más fiel sería Franqueza
- Accountability: que significa responsable de que algo se haga, aunque no sea el ejecutor, pero en español no tiene traducción directa y quedó con la palabra de responsabilidad que significa lo mismo, sea que se delegue o no.
Comentarios, referencias y aclaraciones
- Sí, es cierto, si estás haciendo cuentas, luego de firmado el manifiesto en el 2001 comencé a compartirlo en las clases de ingeniería de software y taller de ingeniería de software en la Universidad Eafit en Medellín www.eafit.edu.co
- Cotidiano, na: diario - dle.rae.es/cotidiano
- Comprehensive - https://www.oxfordlearnersdictionaries.com/definition/english/comprehensive_1?q=comprehensive
- Esta frase se la escuché a mi gran amigo y agilista Hernán Wilkinson y resueno bastante con ella.
- https://es.wikipedia.org/wiki/VUCA
- https://www.infoq.com/articles/contract-model-failure
- Imagen generada con Dell-e https://labs.openai.com/s/ml4XX2e8frHQ8yc2sRidpG9u
- Algunas imágenes de referencia