Recién acabada la conferencia Agile 2010, organizada por la Agile Alliance, varios “pesos pesados” del agilismo a nivel internacional (UncleBob, Corey Haines, Cory Foy… incluso organizadores como J.B.Rainsberger) han señalado que la mayor conferencia sobre desarrollo ágil de software que se organiza en el planeta parece haber olvidado que hay algo muy relevante en esto del desarrollo de software: la programación. Como bien señala Martin Fowler en su blog, los “soft skills” son muy importantes para hacer bien nuestro trabajo, pero igualmente indica que “la programación juega un papel central en el desarrollo de software e intentos para marginarla correlacionan bien con caminos muertos” (como véis, Fowler es de origen inglés y eso se nota cuando escribe).

Hace ya 10 años de la primera conferencia centrada en el agilismo (la XP2000), por lo que ya debe haber opiniones más que maduras al respecto. Es evidente que, como toda “marca” en un mercado, “Agile” está en pleno crecimiento a nivel masivo y eso implica que los “early adopters” ya están buscando un producto mejor. Así, ya tenemos en el paraguas de lo “agile” en relación al software, ideas venidas de otros sectores y las viejas ideas revisitadas como mejoras de las antiguas. También hay que tener en cuenta que hay países (como el nuestro) donde tanto el desarrollo de software como el agilismo van a diferentes velocidades a las marcadas en los países anglosajones y nórdicos (que son los que parecen marcar la tendencia principal). Y estas diferentes velocidades hacen que haya una mezcla de consumidores “ilustrados” y consumidores “ignorantes” (con todos los respetos para ambos “colectivos”). Ante esta heterogeneidad, el libre mercado hace de las suyas y convierte a consumidores “ignorantes” en productores “presuntamente ilustrados” y, sobre todo, potencia los productos de más fácil consumo. Como la tele.

Mi opinión es que es inútil intentar evitar que haya consultores, gestores, directores, certificadores, entrenadores, formadores… que vivan, con más o menos ética, con más o menos fortuna, de cada nuevo “buzz” y que nos aborden cada poco con su marketing. Entiendo que algunos prefieran seguir bajo el paraguas de lo “agile” porque les garantice clientes. También entiendo que algunos prefieran distinguirse de lo “agile” porque está empezando a desvirtuarse del conjunto de valores y principios que originaron el movimiento. ¿En el término medio está la virtud? Puede que sí, pero yo no soy muy dado a mezclar colores porque la experiencia me dice que cuando mezclas sin saber sólo te sale un color indeterminado que yo suelo denominar “caca” (quizás por exceso de rojo sangre y verde ecológico)

No quiero decir con esto que prefiera llevar todos los contenidos de programación a una conferencia aparte. Como decía alguien en twitter, hay que mantener en sincronía el mundo de gestión ágil con el de ingeniería ágil, o de lo contrario no habrá cambio cultural posible en las organizaciones. (Es mi opinión, claro)

Yo quiero ser un buen programador y quiero rodearme (intelectualmente) de buenos programadores. Creo que para llegar a ser un buen programador hay que practicar mucho (y bien) con otros. Para eso creo que tenemos que buscar dos cosas: foros donde poder adquirir estas habilidades prácticas, para poder dejar de comportarnos como onanistas de la programación, y un cambio de actitud en los programadores, para darnos cuenta de que se aprende mucho más y mejor en compañía (aunque ese “onanismo” pueda resultar placentero). Creo que en, en mi experiencia, la mayoría de las disfunciones de los equipos son debidas a miedos individuales, normalmente debidos a la falta de autoconfianza. A partir de ahí probablemente podamos empezar a tener confianza en nosotros mismos y pasar al siguiente escalón: ampliar nuestra visión “sólo técnica” y, de verdad, ser capaces de entender a las capas de gestión y comerciales de las empresas para las que trabajamos (los que trabajéis para una empresa por cuenta ajena, claro). En esa etapa ya seremos capaces de entender por qué hay gente que necesita una estimación fiable de cuánto va a costar desarrollar una funcionalidad. Pero también en esa etapa seremos capaces de defender con seguridad nuestras estimaciones (aunque no sean todo lo fiables que se necesiten) porque habremos perdido esa falta de autoconfianza que nos bloquea y nos pone a la defensiva.

Por todo esto defiendo la necesidad de potenciar eventos como la Conferencia SC2010 a la que asisitiremos unos cuantos desde España, o la XP Universe (que están arrancando Corey Haines y Cory Foy). Quiero aprender de estas Conferencias de Artesanos del Software para ser capaces de traer algo similar a nuestro país. Quiero que los programadores nos acostumbremos a participar en nuestras comunidades locales y a organizar eventos ligeros donde transmitir nuestras habilidades e ignorancias. Quiero que todos seamos aprendices y, con humildad y orgullo, busquemos el convertirnos en maestros. Quiero eso para poder pasar a la siguiente fase.

Con la ayuda de Xavi Gost y otros a los que ya he enredado en el pasado, estoy enredando en el presente y enredaré en el futuro, hemos creado hace casi un año agilismo.es con la intención de poner estos valores en un lugar relevante. Nos gusta nuestra profesión y queremos mejorar en ella. Pronto veréis que le vamos a dar una vuelta de tuerca a lo que hemos estado haciendo hasta ahora. Pero eso quedará para otro artículo.

Hoy he podido comprobar como hasta el más convencido de los agilistas cede a las presiones de la gerencia porque es a lo que estamos acostumbrados y no se nos ocurre defender nuestra profesionalidad con argumentos sino con excusas. Como el agraviado es un buen amigo, daré su nombre. (Vaya uno a tener amigos para esto)

@semurat dijo hoy por twitter lo siguiente:

Después de varias “puyitas” (por mi parte) creo que @ialcazar lo clavó al decirle que:

En definitiva, Jorge podría haber explicado esto mismo a sus jefes. ¿De qué habría servido? A largo plazo estaría sentando las bases de la credibilidad de Jorge como profesional. A corto plazo estaría dando la oportunidad (convendría explicitarla, por si acaso) de que la gerencia priorizara los objetivos, dando la oportunidad a Jorge de entregar lo que más valor ofrezca a sus jefes, lo que podría llevar a una mayor credibilidad como profesional. En ambos casos, no hay nada que perder y sí mucho que ganar.

Si a alguien le interesa la opinión autorizada de UncleBob al respecto de estas situaciones, justamente refiere una muy, muy parecida en su charla “Clean Code I”. La podéis descargar desde el BitTorrent de la NDC2010 (Conferencia que se celebró recientemente en Noruega).

Por favor, si alguna vez véis a algún compañero en esta situación, recordadle que tiene más opciones que “aceptar lo inevitable”. Ayudad a salvar al soldado ágil.

Estaba ayer preparando mi participación en el panel de la Conferencia Agile-Spain 2010 en el que hemos hablado sobre “El presente y el futuro del agilismo en España” y me encontré con este poema de Walt Whitman. Me pareció tan inspirador que no pude por menos que arrancar con él.

NO TE DETENGAS

No dejes que termine el día sin haber crecido un poco, sin haber sido feliz, sin haber aumentado tus sueños. No te dejes vencer por el desaliento. No permitas que nadie te quite el derecho a expresarte, que es casi un deber. No abandones las ansias de hacer de tu vida algo extraordinario. No dejes de creer que las palabras y las poesías sí pueden cambiar el mundo. Pase lo que pase, nuestra esencia está intacta. Somos seres llenos de pasión. La vida es desierto y oasis. Nos derriba, nos lastima, nos enseña, nos convierte en protagonistas de nuestra propia historia. Aunque el viento sople en contra, la poderosa obra continúa: Tú puedes aportar una estrofa. No dejes nunca de soñar, porque en sueños es libre el hombre.

Walt Whitman

NOTA: No, no fue porque la foto de Whitman me recordara a Xavi Gost por lo que elegí un poema suyo.

Termino la serie de entregas que comencé hace un par de semanas. Respecto del original que envié como contribución a la Conferencia Agile-Spain 2010 (en la que espero veros a muchos) he introducido referencias y datos que ayuden a salir del terreno de la opinión y queden más cerca del de la deducción lógica, aunque desgraciadamente creo que ni la cantidad de estudios ni la fiabilidad de los mismos va a mejorar mucho nuestra percepción.

Cómo puede el agilismo impulsar un cambio en el modelo productivo

El cambio de mentalidad que exige el agilismo es, en sí mismo, un agente de cambio del modelo productivo. Es un cambio cultural en las personas y, sobre todo, en las organizaciones.

Los métodos y prácticas ágiles persiguen la eficacia evitando el retrabajo, realizando entregas frecuentes y manteniendo estrictos controles de calidad interna. De esta manera, además, se reducen los costes de producción evitando trabajar en partes del sistema que luego no van a ser usadas o que deben ser corregidas porque no cumplen con las expectativas del cliente o incluso porque son defectuosas. Y todo esto, dentro de una contexto que permite ser más competitivo porque se entrega valor a los clientes mucho antes, lo que permite obtener más pronto un retorno de la inversión al recibir antes las primeras versiones del sistema funcionando.

El agilismo se basa en aportar valor al cliente, buscando relaciones de confianza mutua, donde todas las partes se benefician. Incluso las relaciones con los empleados es diferente. Se confía en su autodisciplina y su autoexigencia, cediendo el control de muchas decisiones que tradicionalmente están centralizadas en pocas personas, que además no están al cabo de los detalles, por lo que suelen equivocarse o no ser lo más eficaces posibles.

Se busca acabar con los grandes esfuerzos dedicados a entregar a tiempo los productos. Para ello se establecen estrategias que fomentan trabajar al principio en aquellas tareas que aportan mayor valor al cliente, entregándolas completamente acabadas en cuanto es posible y revisando las prioridades frecuentemente. Y esto siempre a un ritmo sostenible. Para los proyectos que siguen metodologías tradicionales, aceptar un cambio provoca un desgaste en las relaciones con los clientes y empleados y unos costes directos y de oportunidad importantes. Con las metodologías ágiles no sólo se aceptan bien sino que incluso son bienvenidos porque así se evita trabajar en partes del sistema que luego no son utilizados¹ o que deben ser corregidos más adelante. En este escenario, todas las partes ganan: los equipos de desarrollo pueden conciliar su vida personal y profesional y los clientes obtienen un mejor producto y más pronto. Esto es: estamos siendo más productivos.

¿Qué se necesita para hacer posible este cambio?

En general, cualquier cambio podríamos decir que necesita de un agente de cambio² (individual o colectivo) que actúe como germen del mismo. Los seguidores que podrá conseguir en primera instancia serán los más propensos a adoptar cualquier cambio o a asumir los riesgos que el cambio conlleva (los “early adopters”). Pero una vez ganados estos primeros adeptos, para conseguir dar un paso más es necesario obtener apoyos dentro de la organización que queremos cambiar, y para conseguir estos apoyos siempre es bueno contar con:

• casos de éxito para que den confianza
• una comunidad que sirva de apoyo
• estrategias de capacitación para conseguir que el cambio se haga efectivo

De todo esto, ¿qué tenemos ya?

Como decíamos más arriba, en España hay pocos casos de éxito conocidos porque, entre otras cosas, estamos en un sector que da poca difusión a lo que hace. Es evidente que eventos como los que organiza la asociación Agile-Spain, respaldada por una comunidad en crecimiento, y sinergias que se están buscando con otras instituciones son fundamentales para lograr que los casos de éxito que se están consiguiendo en España se puedan dar a conocer y generar la confianza necesaria de los que no gustan de ser pioneros y asumir riesgos, lo cuál es muy lícito en tiempos de crisis.

Poco a poco, y al calor de esta comunidad, comienzan a surgir empresas de capacitación y de consultoría que tratan de ayudar a las empresas y a los profesionales a adaptarse a este nuevo paradigma. Es un camino largo, pero al menos ya hemos comenzado a dar los primeros pasos. Una prueba de ello es que también comienzan a surgir las primeras bibliografías en castellano sobre estos temas. Esto es muy relevante porque, a los problemas ya citados de la economía española, la falta de dominio del inglés, a la que no es ajena del todo el sector de las TI, hace que los contenidos en castellano sean muy necesarios.

¿Qué falta?

Ya vemos que hay una pequeña llama, pero si queremos un fuego es necesario un acelerante, algo que permita que la llama se avive y vaya más allá. Es decir, necesitamos el apoyo de todos los que crean que este cambio es posible. Desde los pequeños empresarios que arriesgan su futuro hasta las instituciones con posibilidad para influir. Por ejemplo, sería muy positivo que las administraciones públicas comenzaran a exigir a sus proveedores relaciones de confianza y colaboración con entregas frecuentes y que abrieran el abanico de posibles colaboradores a pequeñas empresas que YA saben y pueden hacer esto. Iniciativas como Abredatos, por ejemplo, demostraron recientemente parte de lo que pueden hacer equipos de alto rendimiento, con buenas prácticas y con muy pocos recursos, para ofrecer servicios a los ciudadanos.

También se puede influir para que las metodologías y prácticas ágiles lleguen a los alumnos de las Universidades y centros de Formación Profesional de nuestro país. Porque necesitamos ser competitivos cuanto antes. No podemos esperar a que, poco a poco, este conocimiento vaya calando a base del impulso de una pequeña comunidad. Es necesario el impulso de entidades más influyentes.

Pero tampoco es necesario un “Pacto de Estado” para todo esto. Podemos empezar cada uno desde nuestra posición. Sin necesidad de plantear un cambio profundo de todo el sector, sino muchos pequeños cambios, cada uno en nuestro pequeño mundo en el que podemos influir. En este sentido, tener una red de apoyos (una comunidad) creo que es fundamental. Éste es nuestro verdadero reto. Somos un colectivo de más de 200.000 personas (según el estudio “Las Tecnologías de la Información en España 2008″ elaborado por AETIC) que trabaja en un sector clave para la economía española. Somos un colectivo descreido y desorganizado, pero es evidente que algo está cambiando. Y ese cambio lo estamos haciendo nosotros mismos. No es un cambio impulsado desde sindicatos, colegios profesionales, ministerios ni nada por el estilo. Lo estamos haciendo NOSOTROS.

Conclusiones

El sector del desarrollo de software en España necesita un impulso renovador que contribuya a mejorar la competitividad y la satisfacción tanto de los receptores de los proyectos como de los equipos que trabajan en ellos. Y aquí es donde las metodologías ágiles que promovemos pueden ayudar, dado que se basan en la creación de valor para el cliente, fomentan la innovación y aumentan la productividad mediante la mejora continua. Pero además, estas metodologías no se olvidan del verdadero corazón de nuestra industria: los desarrolladores de software, el capital humano que lo hace posible. Para hacer posible este cambio es necesario incorporar a la difusión del agilismo en España no sólo a profesionales, empresas e incluso a las administraciones públicas sino también a las universidades, puesto que sin formación ni investigación es muy difícil vertebrar un cambio como el que proponemos en este artículo. Si conseguimos este cambio de paradigma, la calidad de los desarrollos y la satisfacción del cliente con los servicios de TI ofrecidos por España se verán fortalecidos y, como consecuencia, la propia Sociedad de la Información en nuestro país. Esto también representa una sinergia con muchos esfuerzos institucionales y privados orientados a favorecer la innovación y la exploración de oportunidades en la Internet del futuro. Ése es el cambio del modelo productivo: un cambio cultural tanto en las empresas como, sobre todo, en las personas que las mueven en todos sus escalones.

Muchas gracias por llegar hasta aquí. Ahora espero vuestras reacciones…

Y recordad que mañana y pasado estaré en la Conferencia Agile-Spain 2010. No dudéis en tuitearme, escribirme o abordarme allí directamente. Siempre es un gusto “desvirtualizar a gente”.

Los artículos anteriores son:

• Primera parte: http://jmbeas.iexpertos.com/el-agilismo-como-motor-de-cambio-del-modelo-productivo-en-espana-i/
• Segunda parte: http://jmbeas.iexpertos.com/el-agilismo-como-motor-de-cambio-del-modelo-productivo-en-espana-ii/

Notas:

Me acaban de confirmar que el próximo 11 de junio formaré parte del panel de la Conferencia Agile-Spain 2010 en el que trataremos sobre “el presente y el futuro del agilismo en España”. Estará moderado por Jorge Uriarte, a quien respeto muchísimo (modo @pelotator = ON) no sólo por el palizón que se está pegando ahora para organizarnos esta estupenda conferencia sino también por el que se pegó también para el primer Agile Open que hicimos en 2009.  Además, Jorge está en Agile-Spain desde su “refundación” y, si podéis aguantar hasta el final este video, escuchad cómo alguien que se autodefine como “descreído” es a la vez capaz de poner tanta pasión en esta profesión que (como dice Jorge) “tanto le gusta”.

Si no estoy equivocado, estaré en la mesa redonda con Angel Medinilla (Proyectalis), Juan Garbajosa (UPM), Xavier Quesada (Agilar) y Diego Cenzano (Biko). Echo a faltar gente, claro, pero estoy seguro que la organización habrá tenido muchos problemas para organizar una mesa suficientemente representativa a la vez que manejable. No me quiero imaginar una mesa de 20 personas. ¡No me hagan corrillos, por favor!

Hombre, me hubiera gustado que estuviera Juan Palacio. A mi personalmente es quien me puso en la pista de esto del Scrum en España. ¡Demonios! Regalaba su libro. ¿Cómo? ¿Regalar un libro? ¿Cómo es posible? Y además, creo que la iniciativa ScrumManager es muy interesante y que requeriría de una reflexión colectiva el ver por qué no se habla más de ella, por ejemplo en la lista de Agile-Spain.

También me hubiera gustado que estuvieran Carmen Vidal (ay, esas traducciones del bliki de Martin Fowler…), Jorge Ferrer y Jesús Pérez. Ellos fueron los que arrancaron hace mucho, mucho tiempo, el Agile-Spain 1.0 (o 0.9 quizás, je, je).

Y si no hubiera sido por los que tomamos el testigo… ahora no estaríamos aquí. ¡Que suban al estrado los refundadores! Xavier Albaladejo, Jose Ramón Díaz, Xavier Quesada, Juan Gutiérrez, Ricardo Roldán, Leo Antolí, Jorge Uriarte… espera, Jorge ya está en la mesa. No puede estar dos veces. Y Xavier Quesada también. Esto empieza a ser un lío. Demasiada gente. Bueno, hacemos la mesa más grande, ponemos más micrófonos y damos más tiempo (cinco o seis horas) y creo que así…

Por supuesto, que no se me olviden todos los que no pudieron estar en aquella reunión refundacional pero que tuvieron el compromiso para participar en la organización del Agile Open Spain 2009 y cuyos nombres aparecen para la posteridad en el Acta Fundacional de la asociación Agile-Spain.

Y claro, puestos a pedir, también estaría bien que estuvieran en la mesa, Carlos Blé, Gregorio Mena y otros más tanto de la Oficina de Software Libre como de la incipiente comunidad agilista en Canarias, que andan por allí intentando que el agilismo agarre. Por cierto, muchas gracias por invitarme a la TenerifeLanParty 2k9 (huelga decir que estaría encantado de ir todas las veces que me lo pidiérais).

Hombre, y si invitamos a los de Canarias, estaría feo no invitar a @semurat y @amaliahern (perdón, Jorge Jiménez y Amalia Hernández) que andan por Castilla y León dando guerra y apuntándose a casi tantas citas ágiles como Jerónimo “el espartano” (que no se perdía ninguna del grupo local de Madrid hasta que fue absorbido por un proyecto con una cobertura en los tests que no se atreve a publicar). Ostras, y a ver con qué cara podemos empezar a hablar si no está también David Esmerodes, el liante de los cafés ágiles. Y claro, no voy a invitar a todos los de los grupos locales y no voy a invitar a Alfredo Casado, Alberto Peña y el resto de gente de IPSA, que siempre nos acogen tan bien, o a Raquel Laina, Germán DZ, Adrián Silva… buff, creo que ya hay más gente en el estrado que en la platea.

Pero hombre, si me pongo a hablar de agilismo sin tener a Xavi Gost al lado… como que me faltaría algo.

En fin, creo que el esfuerzo por intentar ser pioneros y explorar caminos nuevos merecen un reconocimiento. Y si no puede ser sentándolos a todos en una mesa (que ya sé que no puede ser) que sea al menos en este pequeño rincón de la blogosfera.

¿Se me olvida alguien?

Continúo con la segunda parte del artículo que comencé la semana pasada y que tantos y tan buenos comentarios sugirió. Espero que os guste.

Actualización: La tercera (y última) parte ya está disponible.

Qué es el agilismo

El desarrollo de software ágil (más conocido fuera de España por el vocablo inglés “Agile”) se origina en los años 90 con las llamadas metodologías livianas, en contraposición a las metodologías pesadas, basadas principalmente en procesos burocráticos y prescriptivos, es decir, que suponían que era posible conocer desde el principio todos los detalles del sistema a construir y que, por tanto, estos no iban a cambiar durante el desarrollo. Las metodologías ágiles están basadas en un cambio de paradigma en el desarrollo de software que acepta los cambios durante el desarrollo como una realidad ineludible en la mayoría de los proyectos. Se busca la entrega continua y temprana de valor al cliente, y la excelencia técnica de los desarrolladores e integrantes del equipo, lo cuál incluye al propio cliente y a departamentos tradicionalmente separados del desarrollo como Marketing o QA (Quality Assurance). Por un lado, la gestión de los proyectos se centra en la colaboración con el cliente, el trabajo basado en la priorización de sus necesidades y el retorno de la inversión en el proyecto (ROI). Por otro lado, se buscan técnicas ingenieriles para asegurar la calidad y la estabilidad de los productos desarrollados, durante el desarrollo, no al final, haciendo responsables de este aseguramiento al propio equipo, buscando no volver a trabajar sobre una pieza de software, por ejemplo para resolver un defecto, pues esto se considera desperdicio.

Entre las metodologías ágiles más conocidas podemos citar: eXtreme Programming (XP), Scrum, Crystal Clear o Lean Software Development. El punto de inflexión en la adopción de estos métodos es la firma en 2001 del Manifiesto Ágil, donde Kent Beck (creador de XP) y otros miembros relevantes de la comunidad definen los valores y principios fundamentales de una metodología ágil a partir de las buenas prácticas que, en base a su experiencia, han visto que dan mejores resultados. Actualmente se está dando una convergencia entre estas metodologías surgidas de la observación y las surgidas de la adaptación del sistema de producción Toyota (Lean Software Development), y por ello no es extraño leer términos como “Lean-Agile” o adaptaciones de conceptos como el Just-In-Time o Kanban.

¿Qué ventajas nos aporta el agilismo?

El cambio de paradigma que representan las metodologías ágiles persigue tanto un soporte para la innovación en el desarrollo de productos como una mejora de la eficiencia en base a una mejora de los procesos, un cambio de cultura enfocado a la calidad en los resultados y la satisfacción de todos los implicados: desde el usuario final del producto hasta el propio desarrollador. En un estudio de 2008 realizado en EEUU se destaca que la adopción de métodos ágiles había representado una mejora para el 60% de las empresas mientras que para el 22% había sido una gran mejora, es decir, la abrumadora mayoría mejoran.

Otro nuevo cambio de paradigma, el de la Internet del Futuro, es una revolución que está cambiando los modelos de muchas industrias. Los nuevos líderes de Internet, como Google, Facebook, etc. tienen un fuerte componente tecnológico y se distinguen por ser muy ágiles en el desarrollo de las iniciativas. Porque, en Internet, el posicionarse es algo crítico para el futuro del desarrollo de los proyectos empresariales, como han supuesto ejemplos tan conocidos como YouTube. España no sólo necesita un fuerte sector de TI, sino también un cambio de cultura a la hora de gestionar los proyectos. Necesitamos adoptar modelos de gestión que nos permitan adaptarnos a este entorno de incertidumbre. Modelos dirigidos por valor y donde el estado de “beta” (producto no acabado con el que se busca el “feedback” temprano de los usuarios) sea compatible con un trabajo profesional, donde haya un punto de encuentro entre la ingeniería y la necesidad de adaptarse de manera continua a un entorno en constante evolución. Esto permitirá a España posicionarse como una potencia en el desarrollo de software, pero lo más importante, como uno de los países con equipos de TI capaces de aportar el valor añadido necesario para abordar los retos del futuro.

Pero conseguir estas ventajas tiene un coste. No es simplemente cambiar unos procesos por otros, sino un cambio de cultura profundo en individuos y organizaciones. Esto toma tiempo, como cualquier aprendizaje. Por eso debemos tomar acciones YA; porque, como hemos explicado antes, está demostrado que el cambio de paradigma es una ventaja competitiva importante y debemos buscar este impulso para crear innovación en nuestro sector de las TI en España.

El agilismo fuera de España

Hoy día, las metodologías ágiles se han impuesto como una realidad incontestable en los países punteros en el desarrollo de software (EEUU y su área de influencia, países del norte de Europa y potencias emergentes como India o China). Ejemplo de esto son empresas tan conocidas como Google, Yahoo! o Nokia. El agilismo es una realidad incontestable y en muchos casos un requisito para empresas y trabajadores españoles que quieren competir fuera de España.

Es evidente que nunca podremos competir con India o China en precio: tenemos que tratar de ser innovadores y entregar productos de calidad. Éste debe ser nuestro objetivo.

Hay muchísima literatura bien contrastada con realidad de empresas con éxito implantando métodos ágiles por todo el mundo y multitud de consultoras ayudando en la difícil tarea de implantar estos cambios, pero además también hay comunidades internacionales alrededor de estos temas. El agilismo a nivel internacional está representado por la Agile Alliance, con más de 5000 miembros repartidos por todo el mundo y organizadora de conferencias internacionales de gran prestigio. También cabe mencionar a la Scrum Alliance, que expide las certificaciones profesionales en torno a Scrum más reconocidas a nivel internacional. Y por último, nombrar a la comunidad Ágiles, nacida en Argentina pero con vocación latinoamericana. De hecho, Ágiles va ya por la 3ª conferencia internacional que organizan en 2010 en Perú, lo cuál, de alguna manera, indica un grado de madurez más elevado que el que existe en España actualmente, que apenas vamos por la primera.

Hay otras iniciativas menos relevantes a nivel internacional, pero que poco a poco se están haciendo su hueco, como ScrumManager, fundada en España por Juan Palacio, y que persigue la certificación profesional en Scrum en un marco más abierto que el de la Scrum Alliance.

Incluso organizaciones muy alejadas del agilismo, hasta no hace mucho vistas como antagónicas, como son PMI (certificadores del Project Manager Professional) o SEI (evaluadores del estándar CMMI) ya están incorporando mucho del cuerpo de conocimiento ágil al suyo propio. De alguna manera, estas organizaciones están certificando que hay mucho en el agilismo que merece la pena ser absorbido para sus propios cuerpos de conocimiento.

¿Agilismo en España?

En España, desgraciadamente, el agilismo es muy poco conocido por los profesionales, empresas e incluso en las universidades. Hay muy pocos ejemplos de empresas relevantes en el sector y hay muy pocos estudios y proyectos de investigación al respecto, lo cuál nos está llevando a un cierto analfabetismo en el sector. En poco tiempo, nuestros profesionales y empresas no serán competitivos ni podrán siquiera colaborar con profesionales y empresas extranjeras porque no nos habremos adaptado a estas nuevas formas de trabajar. Mientras otros crean equipos capaces de responder al cliente con incrementos de valor frecuentes, en España seguimos dividiendo los equipos según sus funciones, sin una visión global del proyecto.

Como ejemplo de empresa de relevancia que ha apostado por el agilismo en España podemos nombrar a Telefónica I+D. Hay una interesante sesión en la Conferencia Agile-Spain 2010 sobre cómo han ido integrando prácticas ágiles en Telefónica I+D. Sabemos de experiencias muy aisladas dentro de la administración pública (otra interesante sesión sobre esto en la CAS2010) y de grandes corporaciones como Indra, por ejemplo, pero hoy por hoy no es algo generalizado ni mucho menos. Sin embargo, son las pequeñas startups en Internet las que están apostando decididamente por el agilismo porque son conscientes de que es un valor diferencial que les puede distinguir de su competencia al permitirles, entre otras cosas, reducir el “time to market” (el tiempo que pasa desde que conciben una nueva idea o detectan una necesidad hasta que la pueden poner a disposición de sus clientes) y aceleran el retorno de la inversión, lo cuál es vital en este tipo de emprendimientos, especialmente en el contexto financiero actual, donde el acceso a los créditos está muy difícil.

Me queda la última parte donde explico cómo puede el agilismo impulsar un cambio en el modelo productivo. Como siempre, espero vuestros comentarios.

Suena un poco pedante el título, especialmente si se piensa que se trata de la contribución que me acaban de rechazar en la Conferencia Agile-Spain 2010, la primera conferencia 100% agilista que se celebra en España. Lo cierto, y aunque suene a excusa barata, es que no había pulido lo suficiente el entregable. Vaya en mi descargo que había entendido que se entregaba un primera versión y que, si era aceptada, entonces debía pulirla. Bien, no hay mal que por bien no venga, y ahora tengo material para varias entregas. Espero que, si aún queda alguien por ahí leyendo este blog, me ayudéis a completarlo con vuestros comentarios. Aunque nunca lo vaya a presentar a ningún sitio, quien sabe, quizás algún político navegando por la blogosfera se tope con este artículo y le dé por poner algo en su programa electoral.

Actualización: Ya está disponible la segunda parte. Y también la tercera (y última).

Aquí es donde lo dejamos para pensar un poco y dejar hueco para la siguiente entrega, donde haré un repaso del “estado del arte” del agilismo en España y fuera de España. Aportaré datos (cosa que no hice para la Conferencia) y trataré de demostrar con ellos que el sector del desarrollo del software en España puede ejercer un factor multiplicador sobre la economía.

Seguramente dejaré para una tercera entrega la verdadera tesis de esta contribución: cómo creo yo que podemos forzar un cambio estructural en la economía española desde el sector del desarrollo del software y, en particular, desde las pequeñas y medianas empresas que desarrollan software. De momento, espero vuestros comentarios, escritos o en persona durante la Conferencia Agile-Spain, a la que asistiré porque, entre otras cosas, haré un nuevo CodingDojo con Xavi Gost y todos los que os apuntéis.

Después de varias semanas de retiro en las lejanas tierras de Huelva, obligado por razones familiares, y después del fenomenal éxito del libro “Diseño Ágil con TDD” que mi buen amigo Carlos Blé me ha dejado prologar, debo reconocer que ahora mismo no tengo mucho que aportar en este blog salvo extraer ese prólogo. Me siento bastante orgulloso de él, no sólo porque es original, sino porque creo que resume bastante bien cómo enfocar un desarrollo de software guiado por las pruebas además de reflejar el espíritu del cambio (aunque tardío) que se está produciendo en nuestro sector y que desde iniciativas como Agile Spain o agilismo.es trato de apoyar en primera persona. Espero que os guste:

Érase una vez que se era, un lejano país donde vivían dos cerditos, Pablo y Adrián, que además eran hermanos. Ambos eran los cerditos más listos de la granja y por eso el gallo Iván (el gerente de la misma) organizó una reunión en el establo, donde les encargó desarrollar un programa de ordenador para controlar el almacén de piensos. Les explicó que quería saber en todo momento cuántos sacos de grano había y quién metía y sacaba sacos de grano del almacén. Para ello sólo tenían un mes, pero les advirtió de que en una semana quería ya ver algo funcionando. Al final de esa primera semana, eliminaría a uno de los dos.

Adrián, que era el más joven e impulsivo, inmediatamente se puso manos a la obra. “¡No hay tiempo que perder!”, decía. Y empezó rápidamente a escribir lineas y lineas de código. Algunas eran de un reciente programa que había ayudado a escribir para la guardería de la vaca Paca. Adrián pensó que no eran muy diferentes un almacén de grano y una guardería. En el primero se guardan sacos y en el segundo pequeños animalitos. De acuerdo, tenía que retocar algunas cosillas para que aquello le sirviera, pero bueno, esto del software va de reutilizar lo que ya funciona, ¿no?

Pablo, sin embargo, antes de escribir una sola línea de código comenzó acordando con Iván dos cosas: qué era exactamente lo que podría ver dentro de una semana y cómo sabrían que efectivamente estaba terminada cada cosa. Iván quería poder conocer cuanto antes cuántos sacos de grano había en cada parte del almacén porque sospechaba que en algunas partes del almacén se estaban acumulando sacos sin control y se estaban estropeando. Como constantemente tenían que entrar y salir sacos del almacén, no podía saber cuántos había ahora mismo, así que acordaron ir contabilizando cuántos había en cada zona del almacén y que cada vez que entrara o saliera un saco apuntarían a qué zona iba o de qué zona venía. Así, en poco tiempo podrían tener una idea clara del uso que se estaba dando a las distintas zonas del almacén.

Mientras Adrián adelantaba a Pablo escribiendo muchas líneas de código, Pablo escribía primero las pruebas automatizadas. A Adrián eso le parecía una pérdida de tiempo. ¡Sólo tenían una semana para convencer a Iván!

Al final de la primera semana, la demo de Adrián fue espectacular, tenía un control de usuarios muy completo, hizo la demostración desde un móvil y enseñó además las posibilidades de un generador de informes muy potente que había desarrollado para otra granja anteriormente. Durante la demostración hubo dos o tres problemillas y tuvo que arrancar de nuevo el programa, pero salvo eso, todo fue genial. La demostración de Pablo fue mucho más modesta, pero cumplió con las expectativas de Iván y el programa no falló en ningún momento. Claro, todo lo que enseñó lo había probado muchísimas veces antes de hacer la demostración gracias a que había automatizado las pruebas. Pablo hacía TDD, es decir, nunca escribía una linea de código sin antes tener una prueba que le indicara un error. Adrián no podía creer que Pablo hubiera gastado más de la mitad de su tiempo en aquellas pruebas que no hacían más que retrasarle a la hora de escribir las funcionalidades que había pedido Iván. El programa de Adrián tenía muchos botones y muchísimas opciones, probablemente muchas más de las que jamás serían necesarias para lo que había pedido Iván, pero tenía un aspecto “muy profesional”.

Iván no supo qué hacer. La propuesta de Pablo era muy robusta y hacía justo lo que habían acordado. La propuesta de Adrián tenía cosillas que pulir, pero era muy prometedora. ¡Había hecho la demostración desde un móvil! Así que les propuso el siguiente trato: “Os pagaré un 50% más de lo que inicialmente habíamos presupuestado, pero sólo a aquel de los dos que me haga el mejor proyecto. Al otro no le daré nada.”. Era una oferta complicada porque por un lado, el que ganaba se llevaba mucho más de lo previsto. Muy tentador. Por el otro lado, corrían el riesgo de trabajar durante un mes completamente gratis. Mmmmm.

Adrián, tan impulsivo y arrogante como siempre, no dudó ni un instante. “¡Trato hecho!”, dijo. Pablo explicó que aceptaría sólo si Iván se comprometía a colaborar como lo había hecho durante la primera semana. A Iván le pareció razonable y les convocó a ambos para que le enseñaran el resultado final en tres semanas.

Adrián se marchó pitando y llamó a su primo Sixto, que sabía mucho y le aseguraría la victoria, aunque tuviera que darle parte de las ganancias. Ambos se pusieron rápidamente manos a la obra. Mientras Adrián arreglaba los defectillos encontrados durante la demo, Sixto se encargó de diseñar una arquitectura que permitiera enviar mensajes desde el móvil hasta un webservice que permitía encolar cualquier operación para ser procesada en paralelo por varios servidores y así garantizar que el sistema estaría en disposición de dar servicio 24 horas al día los 7 días de la semana.

Mientras tanto, Pablo se reunió con Iván y Bernardo (el encargado del almacén) para ver cuáles deberían ser las siguientes funcionalidades a desarrollar. Les pidió que le explicaran, para cada petición, qué beneficio obtenía la granja con cada nueva funcionalidad. Y así, poco a poco, fueron elaborando una lista de funcionalidades priorizadas y resumidas en una serie de tarjetas. A continuación Pablo fue, tarjeta a tarjeta, discutiendo con Iván y Bernardo cuánto tiempo podría tardar en terminarlas. De paso aprovechó para anotar algunos criterios que luego les servirían para considerar que esa funcionalidad estaría completamente terminada y eliminar alguna ambigüedad que fuera surgiendo. Cuando Pablo pensó que, por su experiencia, no podría hacer más trabajo que el que ya habían discutido, dió por concluida la reunión y se dispuso a trabajar. Antes que nada resolvió un par de defectos que habían surgido durante la demostración y le pidió a Iván que lo validara. A continuación se marchó a casa a descansar. Al día siguiente, cogió la primera de las tarjetas y, como ya había hecho durante la semana anterior, comenzó a automatizar los criterios de aceptación acordados con Iván y Bernardo. Y luego, fue escribiendo la parte del programa que hacía que se cumplieran esos criterios de aceptación. Pablo le había pedido ayuda a su amigo Hudson, un coyote vegetariano que había venido desde América a pasar el invierno. Hudson no sabía programar, pero era muy rápido haciendo cosas sencillas. Pablo le encargó que comprobara constantemente los criterios de aceptación que él había automatizado. Así, cada vez que Pablo hacía algún cambio en su programa, avisaba a Hudson y éste hacía, una tras otra, todas las pruebas de aceptación que Pablo iba escribiendo. Y cada vez había más. ¡Este Hudson era realmente veloz e incansable!

A medida que iba pasando el tiempo, Adrián y Sixto tenían cada vez más problemas. Le terminaron echando la culpa a todo el mundo. A Iván porque no les había explicado detalles importantísimos para el éxito del proyecto. A la vaca Paca porque había incluido una serie de cambios en el programa de la guardería que hacía que no pudieran reutilizar casi nada. A los inventores de los SMS y los webservices porque no tenían ni idea de cómo funciona una granja. Eran tantos los frentes que tenían abiertos que tuvieron que prescindir del envío de SMS y buscaron un generador de páginas web que les permitiera dibujar el flujo de navegación en un gráfico y a partir de ahí generar el esqueleto de la aplicación. ¡Eso seguro que les ahorraría mucho tiempo! Al poco tiempo, Sixto, harto de ver que Adrián no valoraba sus aportaciones y que ya no se iban a usar sus ideas para enviar y recibir los SMS, decidió que se marchaba, aun renunciando a su parte de los beneficios. Total, él ya no creía que fueran a ser capaces de ganar la competición.

Mientras tanto, Pablo le pidió un par de veces a Iván y a Bernardo que le validaran si lo que llevaba hecho hasta aquel momento era de su agrado. Les hizo un par de demostraciones durante aquellas 3 semanas, lo que sirvió para corregir algunos defectos y cambiar algunas prioridades. Iván y Bernardo estaban francamente contentos con el trabajo de Pablo. Sin embargo, entre ellos comentaron más de una vez: “¿Qué estará haciendo Adrián? ¿Cómo lo llevará?”.

Cuando se acercaba la fecha final para entregar el programa, Adrián se quedó sin dormir un par de noches para así poder entregar su programa. Pero eran tantos los defectos que había ido acumulando, que cada vez que arreglaba una cosa le fallaba otra. De hecho, cuando llegó la hora de la demostración, Adrián sólo pudo enseñar el programa instalado en su portátil (el único sitio donde funcionaba a duras penas) y fue todo un desastre: mensajes de error por todos sitios, comportamientos inesperados… y lo peor de todo: el programa no hacía lo que habían acordado con Iván.

Pablo, sin embargo, no tuvo ningún problema en enseñar lo que llevaba funcionando desde hacía mucho tiempo y tantas veces había probado. Por si acaso, dos días antes de la entrega, Pablo había dejado de introducir nuevas características al programa porque quería centrarse en dar un buen manual de usuario, que Iván había olvidado mencionar en las primeras reuniones porque daba por sentado que se lo entregarían. Claro, Adrián no había tenido tiempo para nada de eso.

Moraleja:

Además de toda una serie de buenas prácticas y un proceso de desarrollo ágil, Pablo hizo algo que Adrián despreció: acordó con Iván (el cliente) y con Bernardo (el usuario) los criterios mediante los cuáles se comprobaría que cada una de las funcionalidades estaría bien acabada. A eso que solemos llamar “criterios de aceptación”, Pablo le añadió la posibilidad de automatizar su ejecución e incorporarlos en un proceso de integración continua (que es lo que representa su amigo Hudson en este cuento). De esta manera, Pablo estaba siempre tranquilo de que no estaba estropeando nada viejo con cada nueva modificación. Al evitar volver a trabajar sobre asuntos ya acabados, Pablo era más eficiente. En el corto plazo, las diferencias entre ambos enfoques no parecen significativas, pero en el medio y largo plazo, es evidente que escribir las pruebas antes de desarrollar la solución es mucho más eficaz y eficiente.

En este libro que ahora tienes entre tus manos, y después de este inusual prólogo, te invito a leer cómo Carlos explica bien clarito cómo guiar el desarrollo de software mediante la técnica de escribir antes las pruebas (más conocido como TDD).

Un cordial saludo,
Jose Manuel Beas

Espero que después de leer esto, los que no hayáis comprado el libro de Carlos sintáis un impulso irrefrenable y lo hagáis rápidamente, y los que ya los hayáis comprado, o al menos leído, dejéis un comentario aquí sobre qué os ha parecido. ¿Cómo mejoraríais la historia? ¿Qué le quitaríais? ¿Le daríais otro enfoque?

La foto de hoy es en parte un homenaje a uno de mis maestros en esto del agilismo: Ángel Medinilla. El martes de la semana que viene (día 22) será el primer Coding Dojo “agilismo.es powered by autentia”, en el que podré compartir un buen rato con otro de mis maestros, Xavi Gost y de ahí la foto de Ángel practicando aikido.

En el artículo de Robert C. Martin (@unclebobmartin) que hemos traducido en Agile Spain por “¿Qué es toda esta tontería de las katas?”, el maestro UncleBob lo dice bien claro:

(…) la ejecución no es el objetivo. Ni los expertos de artes marciales practican su arte para que puedan realizarlo en un escenario. Un artista de artes marciales practica para alcanzar la perfección personal en el arte de la defensa personal. El hecho de que la práctica se pueda realizar es un (agradable) efecto secundario.

Y ése es justamente el objetivo de agilismo.es (Xavi Gost y yo mismo) a la hora de plantear este coding dojo: conseguir ese (agradable) efecto secundario mientras practicamos por el mero placer de mejorar individual y colectivamente.

Tengo pendientes ya demasiadas cosas. Tantas que me van a salir hasta telarañas (como las de la foto). No sé si tengo justificación para todas, pero tampoco es que vaya a cambiar nada el poner excusas. Así que voy a hacer un pequeño resumen (otro) del estado de mi vida y así, de paso, me ayudará a poner en orden mis prioridades.

Contenidos recuperados

Tengo pendiente la segunda parte de la explicación de cómo conseguí importar mi viejo blog usando Groovy y la API de Google Reader. Esto es algo que requiere bastante esfuerzo pues, aunque tengo el código escrito, hay que explicarlo convenientemente (no es mi mejor pieza de código y no es suficientemente autoexplicativa) y además tengo que buscar un plugin de Wordpress o algo que permita que el código fuente se vea decentemente. Se admiten sugerencias.

Claro, ahora que Google ha tenido a bien devolverme el viejo blog, algunas tareas de mejora sobre el proceso de recuperación pierden interés (me refiero a que hay anuncios que han quedado empotrados en los artículos importados y a que los enlaces han quedado apuntando al viejo blog) y aparecen necesidades nuevas. Lo primero que he hecho ha sido hacerme una copia de seguridad tanto de los contenidos -incluyendo los comentarios y la plantilla- y lo segundo poner un aviso de que me he mudado “para que conste”. Así que ahora he pensado que lo ideal sería importar esa copia de seguridad al nuevo blog, pero tengo que hacer una prueba en local y todo eso antes de hacer el cambio… y me está dando una pereza…

En cualquier caso, prometo escribir (pronto) la segunda parte del artículo sobre cómo importé el contenido del viejo blog. Aunque sólo sea porque lo prometido es deuda.

Reunión Agile Madrid

Tengo también pendiente el resumen de la última reunión del grupo local de Agile Spain en Madrid. Lo que pasa es que Alberto Peña (@plagelao) ha hecho tan buen resumen en su blog que casi que me voy a quedar en dejar constancia y poco más. Ya he subido las diapositivas que utilicé, pero no subiré las notas que escribí para ayudarme porque realmente no aportan nada a la presentación. Sólo para quede constancia: no es ni mucho menos mi mejor presentación; y me alegro mucho, mucho, de que se me olvidara comprobar el espacio en disco antes de empezar a grabar el video, y vuelvo a pedir disculpas públicamente a mis compañeros del grupo de Agile Spain por no haberme preparado bien la presentación. Podríamos haber aprovechado mucho más la reunión. Aunque son gente estupenda: no hicieron sangre conmigo y además me ayudaron a que el resultado final de la reunión fuera muy positivo.

Mi resumen de la discusión es el siguiente:

La confianza es el valor más difícil de alcanzar dentro de un equipo que se quiera autoproclamar ágil. Confianza en sí mismos, confianza entre ellos y confianza hacia el exterior (incluyendo a otros departamentos y, sobre todo, al cliente).

Yo siempre había pensado que la clave estaba en el coraje y la autoexigencia, pero después de esta reunión me di cuenta de que éstos son valores individuales, que requieren un esfuerzo individual. Pero el mayor obstáculo para ser ágil es un obstáculo colectivo: la confianza. Es relativamente fácil confiar en uno mismo, pero confiar en los demás… ay, ay, eso ya es otra cosa. Y que los demás confíen en nosotros… eso ya ni te cuento. ¿Verdad?

Agilismo.es

También estoy arrancando agilismo.es con el inefable Xavi Gost. Queremos hacer de agilismo.es un portal de referencia para el agilismo desde su perspectiva más de las trincheras. Hay ya muchos portales en español sobre Scrum y en general desde un punto de vista de la gestión de los proyectos. Por ejemplo, Proyectos Agiles (que dirige Xavier Albaladejo) es muy buen punto de referencia para esto. También Scrum Manager (iniciativa de Juan Palacio). Pero hemos visto que hay una gran carencia de contenidos de calidad cuando nos ponemos a buscar, desde el punto de vista de los desarrolladores, referencias en español sobre Extreme Programming, Integración Continua, TDD, Programación por Parejas, etc.

Ahora mismo es poco más que una “página güeb” donde este tipo y yo nos ofrecemos para dar coaching, pero no dudéis que va a ir creciendo rápidamente, con contenidos propios y de calidad.

iExpertos.com

Con Carlos Blé y su iExpertos.com tengo una relación muy curiosa. Además de proporcionarme “por la cara” el wordpress donde tengo mi nuevo blog, Carlos se ha empeñado en que yo puedo dar cursos. Bueno, a mi también me ha parecido buena idea, claro. Yo le había propuesto dar un taller sobre Integración Continua, pero no cuajó. Ahora parece que hay posibilidades de uno sobre Refactoring. Éste es más complicado porque requiere preparar muy bien el material. Pero me parece un taller muy, muy bonito. Ya veremos si sale y si lo puedo hacer yo o lo hace el propio Carlos, que de eso también sabe.

Por otro lado, hace tiempo le comenté que podríamos hacer un podcast “agilismo.es powered by iExpertos.com” y el tío ya tiene casi todo montado. Hasta hemos tenido que decir que no a Jorge Rubira para grabar un podcast de JavaHispano sobre el Agile Open Spain 2009, porque queríamos sacar el primer podcast antes de Navidades y Jorge ya no tenía hueco. Carlos es un tipo muy emprendedor e incluso se ha buscado un amigo que nos ha hecho una sintonía para no tener que pagarle a Ramoncín. Je, je.

También estamos pendientes, junto con Gregorio Mena, de arrancar una serie de webinars. Esto último es mucho más complicado incluso que el podcast, que ya tiene miga. Pero si conseguimos darle forma va a ser un bombazo.

¡Ah! Y el ya casi famoso libro de TDD de Carlos… adivinad quién ha escrito el prólogo… y no es el típico prólogo. Pero para saber de qué va lo tendréis que descargar. ¡Que será gratis!

Trabajo

Y la noticia de la semana es que ya tengo trabajo. La verdad es que ya casi tenía trabajo. Estaba a punto de cerrar un acuerdo para teletrabajar de “freelance” programando un par de aplicaciones JSF en un equipo scrum de tres personas (una jefa de proyecto, un junior y un servidor). Iba a ser mi primera experiencia como trabajador por cuenta propia. Pero hablo en pretérito imperfecto porque ayer por la mañana fui a una entrevista a la que había llegado convocado a través del INEM. (Sí, ya sé que es un poco extraño, pero ha sido así). Y resulta que he aceptado trabajar en un proyecto de 6 meses para el Ayuntamiento de Alcobendas. Bueno, y ellos también han aceptado trabajar conmigo, claro.

Estoy seguro de que va a ser un proyecto muy bonito en el que voy a poder aprender mucho. Creo que será muy bueno también para el Ayuntamiento, para los empleados a los que voy a ayudar y en última instancia para los ciudadanos. Durante la entrevista les expliqué por encima esto del agilismo y “alucinaron”. Claro. Les gusta mucho eso de ir teniendo “software que funciona”. Pero a continuación les cambia el gesto cuando se acuerdan de “las cosas de palacio van despacio”. Je, je. Dentro de un par de meses ya veremos quién ha sido más testarudo: si yo y mi “agilismo de guerrilla dentro de la recalcitrante administración pública” (parece el título de una peli de miedo) o ellos con su “no, no nos moverán”. Sospecho que ganaré yo. Mis armas son mucho más poderosas. Estoy dotado de un optimismo a prueba de bomba y ellos no. Todavía.

Coding Dojo

¡Pero esto NO es todo, amigos! El día 22 (el día de la Lotería) estamos montando un “coding dojo” en las intalaciones que Okuri Spaces tiene en el barrio de Tetuán (en Madrid). El maestro Xavi Gost vendrá a darnos una clase de su kung-fú programando en Java una aplicación para hacer un “pomodoro”. Y eso en un “pomodoro” de duración: 25 minutos. La sala es pequeña (apenas cabrán sentados unas 20 personas), pero lo grabaremos, tranquilos. Será gratis y la idea es que nos sirva para promocionar “agilismo.es powered by autentia“, que si todo va bien será una iniciativa muy interesante relacionada con la formación de calidad y de la que por el momento no os puedo comentar más porque tampoco hay mucho más y porque, ¡qué caramba!, hay que crear un poco de expectación.

En fin, esperemos a ver qué tal nos lo pasamos en el Dojo y si alguno de vosotros se decide a venir, no olvidéis saludarme, que a todo bloguero le hace ilusión conocer a sus lectores.