Se hace camino al andar…

Experiencias de un informático vocacional buscando la calidad y sus efectos colaterales.

Archive for category libros

La Nevera Vacía

Aug 5

Posted by jmbeas in libros | 3 Comments

Llevo un par de semanas leyendo un librito que me regaló uno de sus autores (Diana Clarke), a la cuál conozco de mi época en Degesys, donde recibí un par de cursos de autoayuda, perdón, de gestión del tiempo y de liderazgo. :) En serio, unos talleres estupendos, donde practicamos mucho y donde aprendí a conocerme a mí mismo un poco más. Diana es una verdadera experta en conseguir eso de las personas. Bueno, al grano, el libro se titula “La Nevera Vacía” y debe su título a un comentario de una alumna de Carlos Hernández (el otro autor):

La crisis es como una nevera casi vacía, y el líder es el cocinero, o la madre de familia, que es capaz de realizar la mejor de las recetas sin apenas ingredientes.

Lógicamente, aparte de por la relación personal, me interesa mucho este tema y me lo traje como lectura veraniega y, aunque
este tipo de lectura es muy parecida a los propósitos de Año Nuevo, sí que he conseguido acabarlo. ¡Hurra por mí! :-)

Para los fans de Pilar Jericó: el prólogo es de ella. No es tan bueno como el mío en el libro de Carlos Blé, pero se deja leer. :-D

Diana y Carlos explican el estado de crisis actual, desde un punto de vista muy centrado en el papel de los departamentos de Recursos Humanos, pero también aplicable a cualquiera de nosotros, porque todos somos parte, de una manera o de otra de una organización en crisis (la sociedad misma). Así, nos hablan de la crisis económica, con efectos evidentes; una crisis de sobra estudiada y que muchos siguen tratando de paliar. Pero también nos hablan de la crisis de valores, causa raíz de la propia crisis económica. Esta crisis de valores nos ha llevado hasta una crisis de confianza, “donde nadie confía en nadie”. Y por último nos hablan de una crisis de identidad, especialmente grave en aquellas personas orientadas al logro y que necesitan un nivel de reconocimiento legítimo (y la mayoría lo somos porque nos han educado así) porque “quieran o no, vinculan aún más su identidad a la profesión que eligen”.

Crisis de Valores

Todo el capítulo sobre la Crisis de Valores me ha gustado mucho porque me ha reforzado en varias creencias muy íntimas y que me guían desde hace mucho tiempo, probablemente desde que vi la película “Momo” (versión animación, lo siento, no he leído el libro), y más recientemente, cuando leí un librito muy recomendable de Galbraith titulado “La economía del fraude inocente”. En particular, me sentí muy alineado con los autores cuando leí esta frase en “La Nevera Vacía”:

El desarrollo, tanto en sus raíces como en su direccionalidad y resultados, ha negado y vulnerado la ética. La ética ha estado ausente del desarrollo.

Nota para los despistados: cuando dicen desarrollo se refieren al desarrollo económico, no al desarrollo de software, je, je, pero (y esto lo añado yo) como en la gran mayoría de las actividades económicas, perfectamente podría aplicarse a este caso porque muchas disfunciones que todos los días comentamos en foros, conferencias, listas de correo y demás pasillos tienen que ver con la aplicación de esos “principios de enriquecimiento a toda costa”. Me encanta la frase:

La dirección sin valores es pura mediocridad.

Me parece estar oyendo a Xavi Gost. :)

Hay otras referencias a la ética, como la que hacen a la “crisis de decencia” de Leopoldo Abadía o la crítica de un decano de escuelas de negocio muy importante que dice:

Las escuelas [de negocio] se han olvidado en gran parte de las cuestiones éticas dentro de los MBA y apenas les conceden importancia.

Yo ampliaría la crítica (constructiva) a muchos más ámbitos.

Crisis de Confianza

Aunque en mi opinión, la crisis de confianza viene dada no sólo por una crisis de valores sino que también contribuye a ella una crisis de aptitudes (cierto, que también viene dada por una falta de valores). Me refiero a que muchos cambian un “enriquecimiento a toda costa” por un “crecimiento sostenible” y entonces dejan de lado la capacitación en habilidades que les permiten, entre otras cosas, no perder la confianza en sí mismos, ser capaces de criticar a los que toman decisiones por ellos y, en general, no ceder responsabilidades en exceso.

Creo que estaremos todos de acuerdo en que es muy importante, individual y colectivamente, recuperar la confianza, tal y como la describen Diana y Carlos:

La creencia en que una persona o grupo será capaz de responder de forma positiva -y en línea con nuestras expectativas- en una determinada situación. (…) Es una especie de apuesta, un sentimiento fruto de percepciones.
Por ello, cuando se pierde la confianza, ello produce agotamiento emocional.

Y una de las pistas que aportan para esta recuperación es:

A todos nos gusta en mayor o menor grado: prevalecer, ganar, tener la última palabra, demostrar que somos listos y/o guapos y/o simpáticos, lograr que nos admiren, respeten y quieran. Lo que nos compensará por renunciar a esta necesidad de reconocimiento será la confianza de que pertenecer al grupo trae consigo ventajas.

Crisis de Identidad

Cerrando esta primera parte del libro, Diana y Carlos se centran en otra crisis de la que casi nadie habla: la crisis de identidad.

Las personas orientadas al logro, y que necesitan un nivel de reconocimiento legítimo, quieran o no, vinculan aún más su identidad a la profesión que eligen.

¿Qué pasa si te quedas sin trabajo? ¿Qué pasa si el tipo de trabajo que venías haciendo desaparece? ¿Desapareces tú también con él? Claro que no. Pero muchos no se dan cuenta de que, llegados a ese punto, no les queda más remedio que hacer algo diferente a lo que habían estado haciendo hasta entonces. Yo creo que, en muchos casos, la incapacidad para ver esto tiene que ver con una falta de confianza en uno mismo y, también, por una falta de capacitación que les impide reinventarse o incluso, siquiera adaptarse a los cambios.

Recetas

Si el libro se quedara ahí, francamente, lo habría tirado a la basura. (De buen rollo) :-) En serio, no me gusta nada que me digan lo mal que está todo, aunque sea de un modo tan certero. Es algo que me pone de mal rollo. :)

En la nevera falta confianza, valores, ilusión, pero aun así es posible cocinar un buen plato, y ésa es precisamente la función del líder. Hay pocos ingredientes, pero bien mezclados crearemos magníficos platos.

O como decía la abuela de un viejo amigo: Si todo lo que le echas a la comida está bueno, entonces seguro que está muy rico.. :-)

La Crisis como Oportunidad

Toda crisis genera oportunidades y supone, estimula y proporciona cambio. Pero para aprovechar esas oportunidades hay dos alternativas: ser capaces de reconocerlas y aprovecharlas o, más difícil aún, crearlas y aprovecharlas. En ambos casos, el factor común es ser capaces (estar-dispuestos-a) aprovechar las oportunidades.

No voy a destripar este capítulo porque me parece muy interesante, pero sí resaltaré lo que más me ha gustado de este libro CON DIFERENCIA:

Ser generoso genera más oportunidades de las que nos podemos imaginar. Sí, sí, hablamos de dar y no de pedir. Las personas que constantemente son generosas y ofrecen su ayuda a los demás incrementan notablemente su red de contactos, y ésta les devuelve dicha generosidad en forma de oportunidades.

Más claro, el agua. Pero además es que soy un firme creyente en algo que me enseñó Roberto Canales (al que, de paso, dedico este resumen del libro, si es que este tipo de cosas se pueden dedicar) y es que si das, con el paso del tiempo recibes mucho más de lo que has dado.

La Crisis como Cambio

Me ha gustado mucho cómo han tratado esta parte porque me he dado cuenta de lo mucho que tenemos en común. Yo hablo mucho de autoexigencia y ellos, por ejemplo, hablan de “disconformidad permanente” y que, además, es una actitud que hay que cultivar.

Es evidente que los cambios que provoca una crisis nos obligan a salir de nuestra zona de confort, lo que implica asumir riesgos, entre ellos asumir que nos podemos equivocar. Pero lejos de ser algo malo, deberíamos aceptar las equivocaciones como oportunidades para aprender y, por tanto, ponernos por delante de nuestra competencia. Esta combinación de humildad (para aceptar que somos falibles) y de arrogancia (para aventurarnos como si fueramos inmortales) es muy poderosa y creo firmemente en ella.

También proponen la necesidad de tener una visión y un plan específico, con el objetivo de aprovechar los cambios. Hay, sin embargo, una duda aquí que me surge: ¿no es algo contradictorio el tener una visión más un plan específico con darnos la oportunidad de explorar? No sé, yo soy más de los seguidores de la idea del Homo Ludens, y en este sentido me viene muy bien el post de hoy de David Bonilla: L’equip petit.

Motivación

El resto del libro ya se me vuelve un poco denso :-( , quizás porque cuando leo palabras como motivación siempre me sale un “pues te vienes motivado de casa, chaval”. Pero claro, es que soy poco empático. Sé que ambos son defectos que debo trabajar y lo explican muy bien en el libro, pero bufff…

Comunicación

Sin embargo, hay una sección dedicada a la comunicación que me ha gustado mucho, quizás porque ahora que tengo que cuidar mucho mi marca personal, me fijo mucho más en eso y en cómo es posible que la gente pierda la confianza en tí con mucha facilidad simplemente porque has comunicado mal. Seguro que todos tenéis en mente muchos ejemplos, y muy probablemente alguno tenga que ver conmigo. :-)

Me gusta cómo explican que la comunicación debe ser veraz y puntual (cubriendo esos aspectos éticos tan olvidados), debe transmitir calma y esperanza (¿tú seguirías a alguien completamente histérico?). Llegados a este punto me di cuenta de que encajaba bastante bien con lo que los autores denominan los cuatro pilares de la confianza:

  • Competencia (o Resultados)
  • Visión positiva (o Calma)
  • Integridad (o Ética)
  • Interés por los demás (o Empatía)

Sólo habría que complementar esta comunicación con aspectos centrados en la empatía y los resultados y tendríamos una estrategia de comunicación bastante potente.

Hay algunas partes densas del libro que, aun así, hay que leerlas con detenimiento porque hay algunas partes donde he visto muchos puntos en común con libros que me son muy cercanos como “Apprenticeship Patterns” o con detalles como:

A menudo, la máquina de café es el lugar ideal para comprender lo que se cuece en nuestra organización.

Creatividad

No sólo he aprendido detalles de cómo pensamos los seres humanos, sino que he entendido por qué hay que salirse de los cauces establecidos para innovar. Para innovar de verdad.

La clave está en atreverse y no censurarse.

Si esto es así (que lo es), yo también me pregunto por qué en las empresas se habla constantemente de la innovación pero no se entrena a las personas para romper esquemas. Esto (y es un aviso para navegantes) lo vamos a cambiar muy pronto. De hecho, ya lo estamos cambiando, ¿verdad? ¿O acaso iniciativas como el desksurfing no lo demuestran?

Hay muchos consejos más para facilitar la innovación que no voy a enumerar aquí para que os compréis el libro o para que contratéis a Carlos o Diana para que os ayuden. ;-)

Talento

Claro, tenía que ocurrir. Un libro de RRHH y que no hablen de talento… :-P ¡Qué rabia que no hubieran estado en el AOS 2011 en aquella sesión sobre el talento! Seguro que Arturo Herrero, por ejemplo, les habría enseñado alguna cosilla después de su larga lista de experiencias buscando su empresa ideal. Aunque también es seguro que habríamos estado de acuerdo en muchísimas cosas.

Hay muchos detalles en este capítulo que me reafirman en la necesidad de organizar algún tipo de evento donde asistan profesionales de los RRHH a los que podamos inocular el virus del agilismo, la artesanía, el aprendizaje, la creatividad… y nos ayuden a romper las reglas. :-)

Conclusiones

Voy a copipegar parte del último párrafo del libro, que a su vez es transcripción de las palabras de un ejecutivo asistente a alguno de sus cursos:

Seamos:

  • Serios, pero no tristes. (…)
  • ¡Sabios y audaces! (…)

Me parece estar, una vez más, escuchando a Xavi Gost. No puede ser casualidad. :-)

 

P.S.

¿A vosotros también os choca decir “Diana y Carlos“?

Tags: , , , ,

Érase una vez… el diseño ágil con TDD

Jan 24

Posted by jmbeas in Agile, libros, Testing | 4 Comments

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?

Tags: ,

Sin miedo a cambiar

Aug 7

Posted by jmbeas in Agile, Del viejo blog, libros | 2 Comments


Tengo pendientes otras revisiones de libros, pero acabo de terminar de leer (en primera lectura) “Fearless Change. Patterns for Introducing New Ideas” y me ha parecido tan, tan recomendable, que no puedo evitar bloguear un poco sobre él.

Este libro explica un conjunto de patrones que podemos usar si queremos introducir un cambio (las autoras hablan de una innovación, que suena mejor). Se lee muy rápido porque está dividido en tres partes bien diferenciadas: una primera donde explica cómo emplear mejor estos patrones, una segunda y muy breve con algunos ejemplos (casos de éxito) y una tercera con cada uno de los patrones explicado bien en detalle. La primera sería el Manual de Usuario y la tercera el Manual de Referencia. ;-)

Las autoras recomiendan comenzar haciéndose Evangelista dentro de la organización donde queremos introducir la innovación. Como Evangelista emplearemos patrones como Test the Waters, Time for Reflection, Small Successes y/o Step by Step, con el objetivo de contagiar la pasión, sin llegar al fanatismo, entre los Innovators (que son los más fáciles de ganar para la causa). Una vez conseguido el primer paso es necesario obtener la complicidad de más gente. Para ello podremos usar patrones como Connector, Guru on Your Side, Innovator, Ask for Help y/o Just Say Thanks. Hay un capítulo muy bueno sobre reuniones, con patrones como Piggybak, Brown Bag, Do Food, The Right Time, Plant the Seeds, External Validation, Next Steps, Stay in Touch, e-Forum y/o Group Identity.

Llegados a este punto ya podemos hablar de comunidad y entonces recomiendan el uso de Just Do It, Study Group, Mentor y especial cuidado con las relaciones personales (Personal Touch, Tailor Made, Shoulder to Cry On).

Y si finalmente todo esto funciona y estáis dentro de una organización capaz de valorar los beneficios que pueda aportar la innovación que defendéis, entonces estaréis en condiciones de convencerlos (probablemente con la ayuda de vuestro jefe, Local Sponsor o Corporate Angel) de que os convirtáis en un Dedicated Champion. Así podréis abordar el siguiente escalón: llegar a las masas (Early Adopters e incluso Early Majority). Hay varios patrones para usar en esta situación, pero seguro que los leeréis pronto. :-)

Para mi gusto personal, el mejor capítulo de todos es el último de la primera parte: “Dealing with Resistance”. Los patrones en este capítulo tienen nombres verdaderamente deliciosos: Fear Less (Sin miedo), Bridge-Builder (Constructor de Puentes), Champion Skeptic (Campeón Escéptico), Corridor Politics (Políticas de Pasillo) y Whisper in the General’s Ear (Susurrando al Oído del General). Suenan un poco a manipulación, pero no sé quién me dijo en cierta ocasión que gestionar y liderar gente consiste en parte en manipularlos.

Es curioso porque algunos de estos patrones los he ido usando a lo largo de mi carrera aun sin saberlo. De hecho, el renacimiento de Agile Spain en parte es debido a que algunos de estos patrones se han ido aplicando (insisto, aun desde el desconocimiento de los mismos). ¡Ay si me hubiera leído este libro antes!

Aún tengo que interiorizar muchos de estos patrones, pero probablemente sólo podré hacerlo cuando tenga la posibilidad de ponerlos en práctica. Espero que no sea dentro de mucho tiempo. ;-)

http://jmbeas.blogspot.com

Tags: ,

Salvando las distancias

May 13

Posted by jmbeas in Agile, Del viejo blog, libros | Comments off

Voy en metro, ilusionado, camino del segundo día del curso de Scrum de Medinilla. Y me he pillado el libro de Gojko Adzic “Bridging the Communication Gap” porque ayer surgió el tema de las especificaciones ejecutables y los roles dentro del equipo. Pero estoy un poco desentrenado porque hace mucho que no voy en metro con tiempo para leer, y el iPod lo tengo vacío de podcasts por escuchar, así que me he puesto la “música aleatoria” y mientras escucho de lo más variado (desde la deliciosa Joy Denalane hasta M-Clan, que no veas cómo me animan) he pensado en tomar notas para cumplir con una “cierta obligación”: explicar lo que me ha parecido el libro.

Gojko Adzic es un tipo que habla en inglés con un acento balcánico realmente difícil de seguir (al menos para mi), así que pensé que era buena idea comprar el libro para entender a qué se refiere cuando habla de talleres de especificaciones y de pruebas de aceptación ejecutables en entornos ágiles. Además, Gojko Adzic también imparte cursos sobre Domain-Driven Design y esa relación entre DDD y pruebas de aceptación es algo que me interesa bastante.

Voy a ser sincero, también compré el libro porque es el primero en el que se habla de Concordion, la herramienta open source en la que modestamente colaboro. Pero son apenas unas páginas y el valor del libro es mucho más que eso.

Adzic explica la importancia de que “la gente del negocio” hable el mismo idioma que “la gente técnica”. Esto muchos lo entienden como obligar a clientes y usuarios a que hablen en términos tecnológicos como “altas, bajas, modificaciones y listados (CRUD en inglés)”, o peor aún, de tablas, campos y relaciones.

En DDD hablamos de un lenguaje ubícuo, o único en todo el proyecto, y que es el que usan tanto técnicos como usuarios. Esto permite reducir los defectos producidos por malentendidos y tiende puentes entre ambos mundos, abriendo la posibilidad a una verdadera colaboración.

Un inciso melancólico. Voy ahora mismo montado (mientras escribo estas notas en mi moleskine) en el metro ligero y me he acordado de ese par de meses intensos que viví y trabajé (sobre todo lo primero) en Melbourne (Australia). Allí fui usuario del “tram” y he de decir que me parece un medio de transporte público de lo más interesante porque es a la vez rápido, cómodo y silencioso.

Pero sigamos con el libro. El grueso del mismo se basa en hablar del “agile acceptance testing” y de cómo buscamos ponernos de acuerdo en qué es lo que hay y lo que no hay que desarrollar. Para esto usamos ejemplos realistas en vez de requisitos abstractos. “Los ejemplos demuestran cómo debería actuar el sistema y cómo debería ayudar a los usuarios a hacer su trabajo”. Adzic propone que estos ejemplos sean creados por todo el equipo de implementación, no sólo por un “experto del dominio” (también conocido como “analista de negocio”) como en modelos de desarrollo más tradicionales. “Usamos los ejemplos para discutir el dominio y asegurarnos de que no hay malentendidos”.

Según Adzic, el uso de ejemplos realistas obliga a pensar más acerca de los problemas. De hecho, comenta cómo se producen muchas discusiones entre los expertos cuando se plantean ejemplos para casos extremos; discusiones que incluso les hacen a veces revisar sus propios procesos de negocio. ¡Vaya! Si resulta que podemos ayudar a nuestros clientes en vez de simplemente observar su comportamiento “desde fuera”, como si fueramos “supernanis con corbata”.

Damned! ¡Me he saltado una parada! Estaba tan concentrado… Menos mal que la frecuencia del metro ligero éste es alta y he podido llegar sólo un par de minutos tarde. Buff…

De vuelta del estupendo curso de Ángel Medinilla, sigo con el resumen del libro y me fijo en que no he explicado esto de los ejemplos. Vamos, que no he puesto ejemplos de ejemplos. :-) Adzic pone un ejemplo en la página 45 de una regla de negocio relacionada con el descuento que le podemos ofrecer a un cliente, pero a mi me gusta más el que explica David Peterson en la web de Concordion. Es bastante más completo porque nos lleva desde la historia de usuario (el requisito) hasta la prueba de aceptación automatizada (en forma de ejemplos). Es interesante cómo David hace mucho hincapié siempre en que debemos especificar con ejemplos que expliquen comportamientos muy elementales y dejar para otras especificaciones todo aquello que quedaría fuera. Son los “Further details” en el ejemplo. También Adzic habla de esto en su libro, pero menos; y yo creo que es importante esta anotación al margen para aquellos que queráis “tomar este camino” para hacer pruebas de aceptación.

En “Bridging the communication gap” también se explica cómo conducir estas reuniones (talleres de especificación) e incluso aconseja sobre algunas herramientas. Pero creo que es interesante explicar cómo pueden encajar estos talleres en nuestro calendario semanal (ágil).

Adzic sugiere lo siguiente:

Release es todo aquello que hacemos después de la demo para dejar bien cerrado el sprint. Etiquetamos en subversion, hacemos copias de seguridad, ponemos las versiones del nuevo sprint en los pom.xml (si usamos Maven y si es que tenemos que cambiar de versión), limpiamos las pizarras… y mientras esto lo pueden ir haciendo algunos desarrolladores (típicamente los becarios, je, je) pues el resto puede estar preparando el sprint primero revisando el backlog y luego, ya con los becarios incorporados, estimando las historias y decidiendo lo que se podrá hacer razonablemente en el sprint (las próximas dos semanas).

Ojo, es una manera de organizar el trabajo durante un sprint, pero lo importante de esto es que el dueño del producto (también conocido como jefe de proyecto, analista de negocio, o incluso tester, según vuestro “mapeo” preferido) se encarga de trabajar las historias de usuario (redacción y priorización) y de los ejemplos (criterios de aceptación) antes de los talleres de especificación, pero realmente es el equipo en su totalidad quien acuerda lo esencial de los criterios de aceptación mediante la discusión que se ofrece en esta reunión. Para los que ya estéis algo picados con esto del agilismo, me permito recordar “las tres Ces” (card, conversation, confirmation). Éste es el momento ideal para la conversación, aunque ya se haya tenido una conversación previa cuando se han estimado las historias de usuario en el Sprint Planning Meeting (usando terminología Scrum).

Bueno, y hasta aquí hemos llegado. Espero que os resulte útil. Y si alguien más se ha leido este libro y quiere contrastar aquí su opinión, estaré encantado de poder charlar con vosotros porque mi intención es preparar una presentación (o un taller, ya veré) sobre este tema y exponerla bajo el “paraguas” de Agile Spain.

http://jmbeas.blogspot.com

Tags: , , , , , ,

DDD in Practice

Jun 15

Posted by jmbeas in Del viejo blog, libros | Comments off

Hace ya varios meses que me estoy leyendo el libro de Eric Evans titulado “Domain Driven Design”. Su lectura está siendo muy reveladora porque, por ejemplo, me ha terminado de convencer de la necesidad de evitar los modelos anémicos frente a los modelos ricos. Pero hoy me he leido un artículo publicado en InfoQ sobre DDD que me “he bebido casi inmediatamente” y que ha resultado incluso más clarificador que el libro de Evans (que prometo terminar de leer, por supuesto).

El artículo de Srini Penchikala es denso: no es el típico articulito (como éste que estáis leyendo ahora mismo) que comenta de pasada, sin profundizar, uno o dos artículos más o menos conocidos, sino que aporta una estructura en el discurso y contenidos que aclaran mucho las ideas.

El autor explica qué aporta DDD en cada momento del desarrollo de una aplicación y cómo lo hace. Explica la sinergia entre DDD y SOA y llega incluso a hablar de cómo debe ser el framework en el que basemos nuestro desarrollo: POJOs, DI y AOP y, por supuesto, para todo debemos poder hacer pruebas unitarias lo más fácilmente posible.

Me gustaría destacar el comentario que hace sobre el uso de anotaciones y, en particular, la propuesta de uso de las anotaciones , o que ofrece Spring y que ya estoy tardando en probar.


Quiero sacar tiempo de donde sea para poder probar la aplicación de ejemplo. Tengo muchas ganas de ver cómo ha resuelto:
a) la separación finísima que suele existir entre capa de presentación y de aplicación
b) las distinción entre validaciones y reglas de negocio.
c) la separación a veces difícil de explicar (y justificar su existencia) entre objeto del dominio, “repositorio” y DAO

Creo que ahí es donde solemos fallar todos al implementar cualquier arquitectura, por bien definida que esté ésta en “la pizarra”. Bueno, yo más porque me temo que en mi proyecto actual tengo todos y cada uno de los “tufillos” (“smells”) que indica Penchikala que deberían ser evitados.

Me ha dejado absolutamente intrigado la referencia que hace sobre ROO (Real Object Oriented), que por lo que he podido encontrar haciendo “googling” ha sido que es un “toolset” que están preparando desde hace años los de SpringSource, pero del que aún no se ha liberado nada. De todos modos, quizás no sea mala idea echar de una vez por todas un vistazo a Grails, visto lo productivo que puede ser si se usa con la orientación adecuada.

Me ha gustado también mucho cuando enfatiza el uso de generadores de código porque coincido plenamente en la necesidad de identificar qué pasos del desarrollo se pueden automatizar y usar frameworks para ello. Éste es mi objetivo desde hace años, aunque todavía no he conseguido encontrar la combinación adecuada; quizás porque siempre termino cayendo en la trampa de los “dominios anémicos” y las “capas de servicio hinchadas” (“fat service layer”) con la vana esperanza de ahorrarme lineas de código.

Y por último, me apunto la idea de usar BNLs para especificar reglas de negocio o comportamientos de los sistemas (vamos, para hacer BDD o ATDD). Ahí, la sinergia con herramientas como Concordion resulta evidente…

Bueno, lo dicho, a ver si consigo sacar una tarde o dos para ver con detalle el código de la aplicación de ejemplo y saco alguna conclusión más. De momento, “en la pizarra” todo es muy, muy prometedor.

http://jmbeas.blogspot.com

Tags: ,

Libros

Feb 6

Posted by jmbeas in Del viejo blog, libros | Comments off

Mi último pedido a Amazon ha llegado:

Mucho para leer y poco tiempo…

http://jmbeas.blogspot.com