En la primavera de 2001 (no hace tanto), se reunieron unos señores en Salt Lake City (USA) y llegaron a escribir lo siguiente. (-> ) A continuación unas referencias por si alguien pregunta... Kent Beck (uno de los padres de XP y creador de JUnit), Mike Beedle, Arie van Bennekum, Alistair Cockburn (“Writing Effective Use Cases”), Ward Cunningham (el padre de wiki y otro de los padres de XP), Martin Fowler (“Refactoring”, “Analysis Patterns”, etc), James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries ( el padre que falta de XP ), Jon Kern, Brian Marick (especialista en Agile Testing, estará en Agiles 2009), Robert C. Martin ( UncleBob : los principios SOLID, “Clean Code”, Fitnesse), Steve Mellor, Ken Schwaber (el padre rico de Scrum), Jeff Sutherland (el otro padre de Scrum), Dave Thomas (“The Pragmatic Programmer”)
Los procesos y las herramientas deben facilitar las tareas de los individuos y no limitarlas . Por eso, p.ej. se utilizan pizarras y post-its.
Si le vamos presentando al cliente sucesivas versiones del producto para que nos vaya indicando (e incluso para que él mismo vaya averigüando ) si vamos bien encaminados o no. El resultado es que, indefectiblemente, el cliente tendrá algo que funciona (más o menos), mientras que si le damos documentación NO TENDRÁ NADA . el camino para llegar hasta lo que necesita el cliente no es un documento muy pesado sino acercamientos sucesivos (y funcionando) del producto. Esto es lo que dará el “feedback” necesario.
Debemos ganarnos la confianza de nuestros clientes y colaborar con ellos para darles valor en vez de parapetarnos detrás de los contratos y rechazar todas sus peticiones de cambio.
En un entorno tan caótico como los coches de tope hay que aceptar que no puedes ir durante mucho rato hacia donde has previsto ir. En el mundo de los negocios es algo parecido. Y los desarrolladores de software tenemos que aceptar esta realidad y ayudar a las empresas en esto .
