Lo primero a tener en cuenta es que no fue una charla como tal, casi se podría decir que como no había demasiado tiempo pasamos directamente al turno de preguntas, ya que al inicio de la charla nos solicitó a los asistentes que le propusiéramos las preguntas que queríamos que él contestara para así poder centrarse en nuestras inquietudes. Y estas fueron las preguntas que se propusieron y las respuestas dadas:

¿Cuándo es el momento de ir a ver a un inversor?

Hay distintos tipos de inversores para las distintas etapas de un proyecto. Cuando se tiene hecho el plan de negocio y se tiene montado un equipo es el momento de ir a hablar con un Business Angel, antes de eso, para conseguir algo de dinero es mejor acudir a FFF (Family, friends or fools) porque hasta que la idea no está cuajada en un plan de negocio no se puede evaluar. Cuando ya tienes capital vas al venture capital o capital de riesgo y cuando tienes beneficios con otro. En cada etapa tienes que ir a hablar con un inversor porque dependiendo del inversor te preguntará distintas cosas sobre el estado del proyecto y es importante que cuando hables con un inversor sepas contestar a las preguntas que él te haga.

¿Qué se puede esperar de un inversor?

El inversor sólo debe aportar dinero, porque participa en muchos proyecto a la vez y no puede estar presente en cada uno de ellos. De él solo cabe aportar dinero. El inversor pone dinero y el emprendedor “curra” y luego le devuelve el dinero multiplicado al inversor pero el inversor no añade valor, captura valor.

¿Qué espera sacar el inversor de un proyecto?

Tiene que multiplicar por 10 o por 20 su inversión. Porque si de cada 10, 9 le salen mal, necesita cubrir con el que sale bien las pérdidas de los restantes. Para que un negocio sea invertible tiene que tener un potencial increíble, que no es lo mismo que un negocio viable.

¿En cuánto tiempo espera el inversor el retorno?

Entre 6 y 7 años.

¿En qué se fija un inversor?

Hay algunos que son intuitivos simplemente. Hay otros que son sistemáticos. Evalúan un proyecto de internet igual que un bono de inversión. Su modelo es  una ecuación racional y sistemática en la que el emprendedor no importa, importan únicamente 6 variables.

1. Viable: Si tiene un mercado(clientes, pero clientes con nombres y apellidos identificando así quiénes abren la cartera) clave.
2. Ventaja competitiva clara: No hay nada más peligroso que decirle a un inversor que no tienes competencia porque seguro que esa idea se le ha ocurrido a alguien y el inversor puede pensar que no tienes ni idea del mercado en el que estás. Aunque a veces puede que sea verdad, pero el inversor prefiere negocios donde sí hay competencia. No puedes tampoco decirle al inversor que es que los grandes son tontos y no saben aprovechar el mercado.
3. Factible: Lo puedes hacer con el equipo que tienes y ahora. Se necesita un equipo multidisciplinar y complementario.
4. Hay que explicar por qué es el momento de hacer tu idea “ahora”. ¿Qué ha cambiado para que se haga posible algo que antes no era?
5. Invertible: Tiene que ser escalable, muy escalable.
6. Salida: El dinero entra ahí para salir. La salida es cómo se traduce a euros el valor que se va a invertir.

El estereotipo de emprendedor lo tienen tanto los buenos como los que han fracasado, por eso no sirve como criterio para decidir sobre la inversión, sino solo se invertiría sobre consultores. Lo ideal sería poder hacer una evaluación del proyecto sin dejarte influir por la impresión que te dan las personas, ya que quien te lo presente puede que haya tenido un mal día.

¿Hasta cuándo está el inversor?

Todo inversor en cuanto entra está deseando salirse. Lo normal es que el inversor no tenga interés en dedicarle ni un minuto al proyecto y menos interés aún en controlarlo. Si el proyecto no funciona, no vale la pena que el inversor dedique su dinero y el emprendedor su tiempo.

¿Por qué las empresas cuanto más crecen más dinero necesitan?

Porque lo que más cuesta es crecer.

En estos momentos hay dinero para financiar el crecimiento muy rápido. Cuando se ve que un proyecto puede escalar y se puede replicar muy rápido los inversores están deseando darle dinero.

¿Negocios, tendencias o modas?

 El inversor no tiene ni idea, eso es cosa del emprendedor. Lo bonito de este negocio es que es imprevisible, no se trata de anticiparse, sino de intentar navegarlas.

¿Idea o equipo?

Es como en la fórmula 1, ¿qué es más importante el coche o el piloto? Aunque el emprendedor haga mucho, si el modelo (que no la idea) no vale, no tiene salida. Y de igual forma, si la idea vale, pero no tiene el equipo para realizarla, tampoco va a salir adelante.

¿Concepto o números?

Un concepto sin números es como una visión, algo que un inversor no entiende. No quiere decir que haya que traer muchos números y traer muchas hojas de Excel, pero es importante la cuenta de la vieja: ¿por qué es un buen negocio? ¿por qué vale la pena invertir?¿dónde está el multiplicador del dinero? Es mejor primero probar en pequeñito el modelo y luego cuando se vea que funciona lo haces crecer.

¿Se puede empezar con 18000 euros?

Sí, es un momento increíble para emprender porque para testar un modelo y ver si es bueno muchas veces basta con ese dinero.

Y eso fue todo lo que le dio tiempo a contar, ¡que no fue poco!

Para mí que estoy un poco verde en estos temas me resultó una charla muy útil y me aclaró muchos conceptos que espero recordar y tener presentes si algún día mi musa quiere que se me ocurra una buena idea sobre la que montar un negocio .

El encargado de inaugurar esa iniciativa fue Alberto Vilches, que tuvo la difícil labor de vender Groovy y Grails a unos desarrolladores Java algo reacios a cambiar (¡o que se hacían los reacios a cambiar para ponérselo difícil a Alberto!).

Hubo gente que siguió en directo la charla a través de una página que se habilitó a tal efecto, e incluso algunos hicieron preguntas a distancia para que David Bonilla las retransmitiera. Pero si te lo perdiste no te preocupes, puedes encontrar el vídeo aquí. Apenas le faltan cinco minutillos que se perdieron por los nervios del directo y de la primera vez.

Albertó empezó a contarnos cómo era su relación con Java y cómo su paso a Groovy.

Lo que nos contó fue que de Java les gusta su sintaxis de estilo C pero sin punteros y con recolector de basura, también que es multiplataforma y ser un lenguaje orientado a objetos. Para desarrollo de aplicaciones web en Java se tienen Servlets, JSP, JDBC… y muchas otras herramientas que hacen que sea un lenguaje bueno para la web. Además, más adelante empezaron a aparecer muchos patrones y muchas cosas en J2EE que hacían la vida más fácil, pero que a veces ofrecían soluciones a problemas que no tenían, introduciendo complejidad y se dependía demasiado del IDE que se utilizara para desarrollar. Para esos temas el OpenSource aportó muchas soluciones (Maven, Ant, Hibernate, Struts, Spring) pero el desarrollo seguía sin ser demasiado rápido.

Así que se necesitaba una solución que permitiera hacer desarrollos RAD, había que hacer aplicaciones y hacerlas ya, y Grails nació en este contexto para cubrir el hueco que Java dejaba sin cubrir, el desarrollo RAD en Java, desarrollando aplicaciones utilizando la máquina virtual.

Grails utiliza como lenguaje principal Groovy, aunque también puedes utilizar clases Java, utiliza herramientas para el patrón MVC como Spring MVC, sus vistas en lugar de estar en ficheros JSP están en ficheros GSP (aunque también podemos utilizar ficheros JSP), tiene herramientas de testing y es muy extensible con plugins. Además es más divertido que Java porque como tienes que escribir menos código le dedicas menos tiempo a escribir código y más tiempo a pensar en los problemas del negocio, y también al haber menos líneas de código las posibilidades de cometer un error y las líneas a revisar cuando se produce uno son menos.

Alberto nos contó la estructura de una aplicación Grails, puesto que se basa en convención sobre configuración: sus controladores, sus servicios, sus vistas y sus clases de dominio y nos hizo algunos ejemplos para que viéramos los distintos elementos en acción.

Y durante la charla se plantearon algunas preguntas bastante interesantes:

- ¿Qué otras opciones se pueden encontrar para el desarrollo de aplicaciones rápidas en Java? Según Alberto lo más parecido que existe es el framework Play que incluye muchas de las cosas que aporta Grails y lo siguiente más parecido Spring Roo, que te permite generar la estructura del proyecto, pero en su opinión ninguna es tan buena como Grails ni puede competir con él en velocidad de desarrollo.

- ¿No dificulta encontrar los errores que sea dinámico? Ciertamente puede dificultar encontrar algunos errores y por ello es realmente importante hacer muchas pruebas unitarias, ya que los lenguajes dinámicos te obligan a ser más disciplinado en ese tema. Y si tienes una aplicación muy mal hecha y sin tests, es mejor rehacerla ya que puedes tener serios problemas.

- ¿Se puede luchar contra el modelo anémico en Grails? Su respuesta fue que no hay ningún problema puesto que puedes añadirle a las clases del modelo cualquier método, aunque me hubiera gustado discutir más sobre ese tema porque creo que tiene bastante más miga, no sólo por los métodos que puedas crear, sino por poder delegar en colaboradores que le puedas inyectar. Espero tener la oportunidad de profundizar más en este tema ya que es algo a lo que me estoy enfrentando ahora y no tengo del todo claro cómo tratar.

- ¿Grails o Rails? La ventaja que tiene Grails frente a Rails es que corre sobre la máquina virtual de Java y te puedes aprovechar de la gran comunidad que tiene detrás, además de que la curva de aprendizaje viniendo de Java es menor.

A mí me pareció una charla estupenda y de la que pude sacar algunos puntos en claro que me vienen muy bien para el trabajo que tengo que hacer en Wiseri. El formato se irá refinando poco a poco para intentar hacerlo más colaborativo, pero dado el caracter introductorio que tenía esta charla creo que no había mucho margen de colaboración a parte de ir viendo de forma práctica las cosas y el ir introduciendo las preguntas tanto de los asistentes presenciales como de los asistentes virtuales ¡que en algunos momentos llegaron a ser 22!

Es de agradecer que se hagan cosas de este estilo y también el estupendo catering que tuvimos gracias a SixServix y que nos sirvió de comida y de merienda post-charla. Espero poder asistir a otras, ¡aunque intentaré no acaparar siempre una plaza para mí!

Debo decir que al principio dudé de si apuntarme puesto que mi perfil es técnico, pero sentía una cierta curiosidad por esto del coaching y la gestión de equipos, así que al final me animé, ¡y me alegro de haberlo hecho!

Como en todo Open, el viernes, tras una presentación de Raquel Laina (@rlaina) y Rachel Davies(@rachelcdavies), que fueron unas grandes anfitrionas del evento, empezamos a proponer los temas para las sesiones del sábado.

En esta ocasión sí que me animé a plantear una sesión, quería que la agente me ayudara a definir qué es un coach y cuáles son sus tareas, y como Rodrigo Corral(@r_corral) y Roberto Canales(@rcanales) tenían dudas parecidas ya que se planteaban también qué es un coach y qué no y si los coach son psicólogos, decidimos juntarlas todas en una misma sesión.

El tablón quedó definido y preparado, aunque iría sufriendo algunas modificaciones durante el día siguiente.

Había cuatro salas y daba tiempo a cuatro sesiones por la mañana y tres por la tarde, pero al final como no salían más sesiones decidimos dejar la última hora libre para que así la gente que venía de fuera y tenía que volverse el sábado a casa pudiera irse antes.

También aproveché para hacerle una foto a los principios de los Open Space ya que teniéndolos en cuenta es como se saca más partido a este tipo de eventos.

El sábado llegamos con muchas ganas, aunque con algo de sueño, pero con ayuda del café, el té, el zumo y los pastelitos varios que nos estaban esperando a nuestra llegada nos pusimos las pilas enseguida, ¡listos para comenzar con las sesiones!

Circle of 7, de Adrián Silva (@scyldinga)

Adrián empezó introduciéndonos qué era eso del Círculo de 7, un grupo de mujeres que se unió para buscar formas de ayudar a otras mujeres, un ejemplo de círculo de apoyo. Aquí hay una entrevista en la que cuentan mucho sobre ellas. La idea de Adrián era presentar ese círculo y plantear que quizás podría existir algo así para que las personas que se dediquen al coaching puedan apoyarse en otras personas y consultar nuevas opiniones y puntos de vista sobre los problemas con los que se encuentran en su camino. Empezamos a discutir de que puede ser cierto que el coach a veces se sienta solo y necesite de alguien a su alrededor con quien poder contar para que le ayude, pero muchas veces no tiene a quien pedir ayuda u opinión o con quien compartir las alegrías de los éxitos. Enrique Comba(@ecomba) propuso que contáramos con gente que conozcamos para hablar con ellos, aunque no sean personas que estén cerca, para ello tenemos herramientas como Skype. Pero, aunque hables con una persona un rato, ¿es de utilidad esa charla?¿puede alguien aconsejarte sin tener la misma información que tú tienes de primera mano? Creo que sí, y muchos de los allí presentes también, porque si la técnica del patito de goma funciona en los programadores, ¿por qué no va a funcionar con los coach? Y si además se lo cuentas a otra persona, te puede contestar, cosa que espero no me haga nunca un patito de goma :p. Además, Roberto Canales también apuntó otro dato relacionado con la programación neurolingüística, y es que a veces ante un problema tú ya tienes una solución pensada, pero necesitas que alguien te la reafirme.

Así que vista la necesidad que tenemos de hablar con otras personas, Adrián comenzó a hacer una lista para que todo aquel que estuviera dispuesto a escuchar lo que alguien quisiera contarle se apuntara y yo ya dije que quien quiera puede contar conmigo, ¿se apunta alguien más?

¿Qué es un coach?¿Qué no es?¿Qué funciones tiene?¿Son psicólogos? Rodrigo Corral, Roberto Canales y yo.

Esta es la sesión que tenía en mente desde el principio, ya que era la información que quería obtener de este evento. La primera definición de un coach con la que empezamos fue que un coach es un Scrum Master poco involucrado, cuya misión es la de guiar en el camino pero sin ser miembro del equipo para de esta forma tener una visión desde fuera. Es alguien que hace de mentor. Un coach es la persona que sirve de motivación para que se adquieran compromisos que sin una motivación externa no se alcanzarían, tiene que transmitir entusiasmo y saber hacer llegar los principios ágiles consiguiendo hacer que la gente sea consciente de la necesidad del cambio, tiene que ser capaz de aportar soluciones a los problemas claros y conducir las discusiones en los problemas en los que sea necesario discutir y sobre todo tiene que ser una persona que haga una escucha activa de lo que le cuentan las personas a quienes tiene que ayudar.

Pero en una empresa existen casi siempre distintos niveles, y según el nivel en el que te encuentres posees mayor visión en anchura o mayor visión en profundidad de distintos temas (no es igual la perspectiva que tiene el director de la empresa que el jefe de un equipo). Ante esto surge una pregunta, ¿entonces puede una sola persona ayudar en todos los niveles? Mi conclusión después de todo lo que se estuvo hablando es que una sola persona no te vale para todo, que si alguien quiere un coach tiene que saber para qué lo quiere y buscar una persona con las cualidades que necesite, porque no es lo mismo aconsejar a un equipo de desarrollo que al director de la empresa.

Otra forma de hacer retrospectivas, Raquel Laina

Las retrospectivas son una parte importante del proceso seguido en metodologías ágiles ya que nos permite revisar el camino que estamos haciendo para descubrir qué estamos haciendo bien, y seguir haciéndolo, y qué es lo que está fallando, para poder corregirlo, sin embargo, el modelo ‘tradicional’ de retrospectiva de cosas buenas/malas/mejoras a veces se queda corto y no se le saca todo el partido que se podría a esa reunión.

Raquel nos contó que ya se había encontrado con ese problema y había empezado a buscar otras formas de hacer las retrospectivas que facilitaran la colaboración de los miembros del equipo. La primera opción que probó consistía en hacer reuniones para preguntar a a los miembros del equipo qué tal les había ido la semana, utilizando un pomodoro para que las reuniones no se hicieran demasiado largas, pero este método tampoco le permitió obtener la información necesaria para mejorar en el proceso. Lo siguiente que probó fue a ir haciendo mapas conceptuales con los problemas encontrados consiguiendo que el equipo los fuera diciendo en una tormenta de ideas. Los problemas obtenidos los relacionaban unos con otros y se agrupaban en bloques grandes para de esta forma tener una visión más clara del problema, así que este método le resultó mejor que los anteriores, pero quería saber qué otros métodos podíamos proponer para hacer retrospectivas de otra forma.

Una de las cosas que se dijeron y que me pareció muy importante es que puede ser bueno recordar en cada retrospectiva el por qué es tan importante esa reunión, que todo el mundo tenga presente que esa reunión no es para buscar culpables, sino para que el equipo pueda revisar y mejorar para la siguiente iteración.

¿Y cómo se consigue que la gente tenga presente las cosas que han ido mal a lo largo de esa iteración? Hay quien se va haciendo una lista en el momento en que ocurren las cosas y después cada uno puede llevar su lista a la retrospectiva, o también hay quien cada vez que algo va mal lo apunta en un post-it que coloca junto al tablón para seleccionar de ahí el día de la retrospectiva las cosas que hay que mejorar o también simplemente dejar al equipo reflexionar al principio de la reunión. Personalmente me gusta más la de los post-its porque así no dependes de que cada miembro del equipo se acuerde de hacer su lista y además están más presentes.

Ya hemos obtenido las cosas que han fallado y les hemos buscado posibles soluciones, ¿qué hacemos para que no caigan en el olvido? Para esto me encantó una solución que alguien dijo y que consistía en poner en el tablón las cosas que se habían seleccionado para mejorar de forma que si cualquier miembro del equipo veía que no se estaban cumpliendo pudiera decirlo en la reunión diaria porque teniéndolas bien visibles es más fácil que la gente las tenga en cuenta.

Así que salieron muchas ideas que son fácilmente aplicables para mejorar nuestras retrospectivas y sacarles el mayor partido.

Overcoming the dip, Enrique Comba

En esta charla Enrique nos dibujó una gráfica parecida a esta:

En ella se muestra cómo puede estar relacionada la productividad de un equipo en el proceso de aprendizaje. Cuando se parte de un punto, el inicio, se está acostumbrado a trabajar de una forma y cuando se empieza a aprender algo nuevo primero hay un período de un poco de caos, para pasar después a un período en el que el equipo empieza a producir menos, pero no porque las nuevas técnicas no funcionen, sino porque en el proceso de aprendizaje es normal que haya una época en la que las cosas van peor, hasta que poco a poco se va aprendiendo y muy lentamente se van produciendo mejoras hasta que se llega a la meta planteada. Ante este problema surgen muchas preguntas: ¿cómo consigues que la gente no corra de vuelta al punto inicial en cuanto noten que no están mejorando inicialmente sino empeorando?¿cómo vendes que después de llegar a la meta se necesita que pase un tiempo hasta que se recuperen las pérdidas producidas por el aprendizaje y solo después de ese período obtendrás beneficios?¿cómo convences de que dependiendo del estado en el que se encuentre el equipo puede no merecer la pena el cambio porque el coste va a ser tan grande que posiblemente no se recupere?

De todas esas preguntas la única para las que salieron respuestas fue a evitar que el equipo vuelva al punto de partida. Una de las posibles formas puede ser que haya alguien con peso en la empresa que se haga responsable de los problemas y que el equipo sepa que esa persona va a evitar que nadie les meta presión o les recrimine a ellos el ir más lento y también para evitar esa tentación de volver a lo seguro es necesario que los cambios sean graduales y poco a poco para que la curva sea un hueco pequeño y no un socavón insalvable.

¿Y cómo saber después del camino que has llegado a tu meta? Cuando usas la práctica a la que querías llegar cuando llegan los momentos de estrés.

Después de tanta charla el hambre ya empezaba a apretar, pero por suerte los organizadores se encargaron de prepararnos esta deliciosa comida que nos sirvió a todos para reponer fuerzas.

Y en el ratito que quedó después de comer mientras algunos fomentaban charlas espontáneas que surgían en distintas salas, otros aprovechaban para poner un poco de orden en las ideas recibidas en el día.

Pregunta de la felicidad o el milagro nocturno, Roberto Canales

Cuando Roberto propuso esta charla nos dejó bastante intrigados con qué era eso de la pregunta de la felicidad, ¡quién no iba a querer saberla! La idea se basa en inteligencia afirmativa, no fijándote en lo que está mal, sino en cómo solucionarlo. Por ello el milagro consiste en lo siguiente:

Imagínate que por la noche ocurre un milagro y que cuando te levantas por la mañana todos tus problemas han desaparecido y eres completamente feliz, ¿qué habría cambiado?

Él aseguraba haber podido aplicar este ‘milagro’ no solo al trabajo, sino también a su vida personal, porque una vez descubres las cosas que habrían cambiado al despertarte tu tarea es intentar pequeñas medidas para propiciar que esos cambios ocurran, de modo que con pequeños cambios llegues a ser más feliz. ¿No puede ser esta una buena forma de empezar a hacer coaching?

¡Animaos a hacer este milagro realidad vosotros también!

Agile Coach Dojo, Rachel Davies

En esta sesión lo que Rachel nos propuso era practicar, igual que se practica en los Coding Dojo, pero no a escribir código, sino técnicas de coaching. Para llevar a cabo esta tarea nos dividimos en dos grupos de cuatro y en cada grupos nos repartimos los siguientes roles:

• 2 coach
• 1 persona que necesita el coach
• 1 observador

La dinámica entonces consistía en que la persona que necesitaba coaching hablara con las personas que hacían el papel de coach y estas intentaran cumplir con su labor, mientras el observador únicamente atiende a cómo están realizando su labor para, al terminar el tiempo establecido, poder dar una visión externa de cómo ha visto que se han ido desarrollando las cosas. Después se rotan los papeles para que cada uno pueda estar en cada uno de ellos.

Para mí fue una actividad muy divertida y de la que aprendí mucho porque en la primera ronda me tocó hacer de coach y la verdad es que no sabía ni por donde empezar pero pude sacar muchas cosas en claro con las indicaciones que el observador me dio y con las impresiones que tuve yo al verme en los otros papeles. Si os interesa el tema y tenéis la oportunidad de juntaos unos pocos os animo a que lo probéis!

En la retrospectiva hicimos una ronda en la que cada uno de los asistentes contaba un poco sobre con qué idea venía y qué cosas se llevaba o qué cosas cambiaría y prácticamente lo único que algunas personas habrían cambiado habría sido que no hubiera tantos tracks, así que creo que se puede afirmar que fue un éxito.

Gracias a Eden Development, a Decide, Raquel Laina y Rachel Davies por este evento porque, aunque no me vaya a dedicar profesionalmente a ser únicamente un coach, para mí ha sido una gran oportunidad de aprender muchas cosas que sé que puedo aplicar en mi día a día para intentar que mejore el entorno en el que me encuentre, haciéndome más feliz a mí misma y a los de mi entorno.

La idea, si no me equivoco, surgió en la retrospectiva del AOS2010, donde una de las cosas que se dijo fue que se habían echado en falta temas técnicos y se pensó la idea de que quizás se podrían hacer más eventos de ese estilo sin necesidad de estar meses organizándolo ni pensarlo para que sea algo para 200 o 300 personas. Así que dicho y hecho, Jesús Jiménez se puso manos a la obra y demostró que no hace falta mucho para organizarlo, buscó un sitio en el que poder juntarnos y no se buscó ni patrocinadores ni nada, total, ¡qué son 15 euros para cada uno de nosotros!¡Gracias por el esfuerzo!

Fuimos llegando tempranito para poder aprovechar el día.

La asistencia no estuvo nada mal porque al final fuimos unos 50 asistentes y en cuanto estuvimos todos empezamos a proponer temas. En esta ocasión creo que estuvimos más moderados a la hora de proponer y no salieron demasiados temas, pero aún así hubo mucho donde elegir durante todo el día.

El tablón inicial quedó creado, pero como aún quedaban algunos huecos contando como sitios de reunión el pasillo, la cocina, la cafetería de al lado o cualquier otro sitio que se nos ocurriera se dejó abierto para que si a alguien se le ocurría algún tema nuevo fuera libre de añadirlo al tablón. Esta vez, guiados por el consejo de Enrique Comba, no hicimos ninguna votación ni nada para así empezar más rápido, simplemente pusimos todas las charlas que fueron saliendo en el tablón y si luego hacía falta cambiar alguna de sala por la afluencia de gente se cambiaba y punto.

¡Y comenzamos!

La primera charla en la que me metí se titulaba “Doctor, Doctor… Modelo Anémico” y había sido propuesta por Kinisoftware y Jacegu.

En ella inicialmente se dio una definición simple y directa sobre qué es un modelo anémico: tener objetos del dominio con únicamente métodos getters y setters, sin más lógica, únicamente contenedores de datos. Empezamos a discutir por qué este modelo de datos no es bueno y se mostraron unos cuantos argumentos:

• Te cargas la encapsulación (¿de qué te sirve tener las propiedades de esa clase privadas si realmente las estás haciendo públicas con los getters y setters?).
• Estás usando clases como estructuras.
• Estás creando una capa de contenedores de datos y otra capa para actuar sobre esos objetos, poniendo la lógica de negocio lejos de los datos.

¿Y qué tenemos que hacer para buscar tener un modelo bueno? Pues por ejemplo seguir los consejos del “Tell, Don’t Ask” y la Ley de Demeter para decir a los objetos que hagan cosas en lugar de preguntarle a los objetos por elementos de su estado interno.

Un ejemplo gracioso respecto a esto que propuso Alfredo Casado es que si vas a pagar la compra en una caja no le das al cajero tu cartera para que el cajero saque el dinero de ella, sino que le das directamente el dinero, de igual forma nuestros objetos debería encargarse de dar la información necesaria, no de dar otros elementos para que otro desde fuera sea quien tenga que obtener la información.

Respecto a esto alguien preguntó que por qué el getter era malo y la respuesta fue simple: el getter no es malo, lo malo es usarlo para exponer los atributos internos de una clase para que alguien desde fuera opere.

Pero un problema que nos encontramos cuando intentamos evitar modelos anémicos es que podemos acabar creando objetos demasiado grandes y con demasiada responsabilidad y la única solución que hay es estar en contacto con el cliente todo lo posible para encontrar un buen diseño del dominio y para ir buscando objetos pequeños que respondan a preguntas pequeñas en lugar de tener un objeto que responda a todas tus preguntas.

¡Es duro pero hay que intentar ponerlo en práctica!

La siguiente charla en la que estuve fue “Mockear” propuesta por Emma.

En esta charla partíamos de la pregunta de si era buena realizar tests con mocks o no. Al principio no entendimos bien de dónde surgía la duda hasta que empezamos a aclarar algunos términos y es que antes de pensar si mockear o no tuvimos que explicar un poco algunos términos de los distintos tipos de dobles de objetos que algunos no estábamos viendo como diferentes pero que en el planteamiento de la charla sí eran diferentes:

• Stub: Permite manejar los resultados esperados en las llamadas a un objeto.
• Mock: Doble de un objeto que permite definir las llamadas que se esperan se produzcan sobre el objeto. Se tienen que definir las llamadas esperadas antes de la llamada que se está probando y luego las verificaciones en la zona de comprobaciones. Además, si se realiza una llamada sobre el doble que no se encuentra definida entre las esperadas el test falla.
• Spy: Es el doble de un objeto que almacena las llamadas realizadas a métodos de este objeto para poder verificar en la zona de comprobaciones si se han realizado las llamadas deseadas. Cuando se producen llamadas a métodos no esperados no falla el test y si devuelve algo el método, se devuelve un valor por defecto(por ejemplo null).

¿Y cuándo usar cada uno? Pues todo depende del problema al que te enfrentes, si quieres probar a qué métodos se llama asegurándote de que no se produce ninguna llamada más de las que estás comprobando, si sólo quieres asegurarte de que una llamada se realiza sin importarte si se hacen más llamdas o si quieres asegurar que un objeto devuelva un resultado.

Además hay que tener en cuenta que en los tests con mocks, stubs o spies el test queda acoplado al código, ya que si cambian las llamadas que estás haciendo el test puede fallar. Por ello, estos objetos dobles pueden servir para diseñar el código y olvidarte de una parte con la que tienes que integrar el código y que no depende de ti, pero es peligroso usarlos sin control ya que puedes caer en crear demasiados colaboradores dentro del código.

También hay veces que te puede interesar no recurrir a estos dobles de objetos, sino crearte tú tu propio doble del objeto que quieras probar, incluso es una técnica necesaria cuando quieres probar algunos métodos que los dobles no te dejan como el “toString”.

Así que la conclusión de esta reunión yo creo que fue que tienes que usar cada herramienta cuando realmente la necesites, no usar una siempre por el hecho de haberla aprendido y también que el mejor momento para usar estos dobles es antes de hacer el código puesto que si los escribes después es muy posible que hagas un test totalmente acoplado al código escrito que replique las llamadas realizadas en el código.

La siguiente charla en la que me metí fue “Código Expresivo” propuesta también por Kinisoftware y Jacegu, que llevaban tiempo hablándolo con Alberto Peña a quien al final la gripe le tuvo en cama gran parte del día.

La idea de esta charla era hablar un poco sobre el Clean Code, un libro que muchos consideran que debería darse a un programador nada más aprender a programar.

Uno de los puntos importantes que se tratan es sobre el “naming”. Es importante enseñar a nombrar las cosas desde el principio ya que si no eres capaz de ponerle nombre a algo es porque realmente no sabes lo que hace.

Pero si estás implementando en una clase un patrón de diseño, ¿deberías indicarlo en el nombre de la clase? Aquí hubo algo de discusión, ya que aunque en el libro se hace, quizás puede llevar a poner nombres que no sean realmente significativos para el dominio.

¿Y cómo de largos deberían ser los nombres? Lo mejor es buscar un equilibrio entre la longitud del nombre y que sea suficientemente expresivo y sobre todo tener en cuenta que si aparecen cosas como “y” u “o” en los nombres hay que repartir responsabilidades. En el libro se autoimpone una restricción de 120 caracteres para evitar tener nombres demasiado largos que pasen a ser ilegibles.

¿Y cómo se manejan los distintos niveles de abstracción con la legibilidad del código en un lenguaje natural? Está claro que escribiendo código tiene que haber código y que hay partes del código que al final tienen que tener nuestros algoritmos, lo importante es que en cada nivel de abstracción tengas un nivel homogéneo de información de forma que que se pueda leer de forma horizontal y cuando un usuario que esté leyendo el código quiera más información sobre una parte en concreto pueda navegar de forma vertical para ir encontrando una información más específica. Por ejemplo no sería coherente un código que fuera:

if (x + y == 4 && esDivisiblePorDos(x))

También tuvimos mucho en lo que entrar en materia cuando empezamos a hablar sobre el tema de excepciones, las cuales siempre deberían usarse para tratar casos excepcionales y no para controlar el flujo de una aplicación, aunque se acabó el tiempo y no tratarlo tanto como nos habría gustado.

En la siguiente hora me quería meter en una propuesta de Germán que me pareció muy interesante sobre programar unos robots para hacer una guerra de robots. Lo malo es que cuando llegué a la sala ya estaba bastante llena y no vi mucho sitio para meterme con mi ordenador y desistí, además fuera me encontré con gente con la que tenía ganas de charlar aprovechando la oportunidad de juntarnos y se nos fue la hora volando (¡en estos eventos es difícil no liarte hablando con la gente!)

Pero en la última sesión tenía claro que quería ver un poco de Clojure, así que me metí en la sesión “Clojure Koans“.

En esta sesión nos pusimos manos a la obra con más ganas que experiencia a experimentar con las Clojure Koans utilizando el formato de randori. Aunque sólo nos dio tiempo de hacer unas cuantas estuvo bastante bien como toma de contacto con Clojure, ya que para mí que vengo principalmente de lenguajes con orientación a objetos un primer vistazo a Clojure asusta jeje.

Después de las charlas hicimos una pequeña retrospectiva en la que valoramos el esfuerzo de Jesús para organizar todo y por demostrar que no hay que organizar mucho para hacer un evento de este tipo, algunas personas lamentaban que no se hubiera programado más, mientras que a otras les pareció positivo haber podido hablar y discutir sobre temas técnicos y hubo también discrepancias con si empezar temprano había sido buena o mala idea, pero qué se le va a hacer, nunca llueve a gusto de todos.

Fue un día como siempre divertido e instructivo, como no puede ser de otra forma cuando estás rodeada de gente que tiene tanto para enseñar y compartir. Hubo gente nueva que no había asistido antes a eventos de este tipo y eso es bueno porque quiere decir que la comunidad ágil crece y los desarrolladores preocupados por su profesión aumentan. Lo que sentí fue la poca participación femenina, ya que sólo estábamos 4 chicas y ninguna cara nueva, todas ya integrantes de las Agile-Girls, ¡habrá que predicar más!

Los libros de Ojo Mágico son unos libros que contienen una serie de fotografías en las que fijándose con determinadas técnicas se pueden ver figuras en 3D. En su página web hay más información y algunas imágenes que van publicando periódicamente.

Estas imágenes están basadas en esteogramas , una ilusión óptica con la que se crea sensación tridimensional en base a los distintos puntos de vista que tiene  cada ojo al mirar una imágen.

Yo los descubrí hace unos 17 años, cuando siendo niña mi padre me regaló el primer libro de Ojo Mágico y aún me sigue resultando algo muy curioso. Pero lo que he descubierto hoy, aunque seguro que existe desde hace mucho, es esta página en la que puedes dibujar tus propias imágenes y no he podido resistir la tentación de crear una que espero que os guste a aquellos que os animeis a intentar verla.

Para aquellos que os animeis a intentar verlo y que no conozcais las técnicas os las pongo:

Método 1

Sujeta la lámina de forma que te toque la nariz (en este caso tendrás que hacerlo con el monitor de tu computadora). Relaja tus ojos y fija la vista en el espacio, como si miraras a través de la imagen. Ponte cómodo/a para observarla, sin mirarla fijamente. Cuando estés relajado/a, y sin cruzar la vista, aleja la lámina de tu rostro (en este caso, retira la cabeza del monitor) un par de centímetros cada 2 o 3 segundos. Sigue mirando a través de la lámina (monitor). Párate cuando la tengas a una distancia correcta para leer. Cuando empiece a “entrar”, es necesario ser muy disciplinado/a porque, instintivamente, intentarás fijar la vista en la lámina (monitor) más que mirar a través de ella. Si no lo consigues, empieza de nuevo. Si la empiezas a ver, intenta mover lentamente la mirada por la imágen para intentar buscar el contorno de la figura.

Método 2

Mira fijamente la imagen a distancia de leer de manera que se nuble un poco la visión. Transcurridos unos segundos, percibirás la profundidad y, a continuación, desplazando la vista sobre la ilustración, distinguirás la imagen en tres dimensiones (3D), que se revelará como una foto instantánea.

Bueno, ¡contadme si la veis y si os gusta !

Del año que se nos escapa me llevo muchas cosas buenas:

• Aunque fue hace dos años cuando comencé a involucrarme en temas nuevos creo que este año me ha servido para crecer aún más tanto en lo profesional como en lo personal y mucho de ello se lo debo a @AlfredoCasado quien tiró un poco de mí hasta que conseguió que cogiera carrerilla.
• He conseguido involucrarme un poco más (con mayor o menor éxito en algunas cosas) en las iniciativas y actividades organizadas por la gente de la comunidad de agile-spain.
• He podido dar por finalizados algunos asuntos que arrastraba de hace tiempo y que parecía que nunca iban a terminar.
• Me parece un gran logro personal haber conseguido iniciar este blog con el que me presenté y gracias al que he conocido a mucha gente nueva.
• Me alegro de haber podido mover un poco la iniciativa de las agile-girls y de haber encontrado un grupo de chicas con las mismas ganas o más que yo de hacer cosas y de intentar demostrar que las mujeres en la informática no somos un mito jeje.

Pero de este año también hay algunas cosas que toca mejorar y que son mis propósitos para el año nuevo:

• Creo que profesionalmente en algunos aspectos he caído en la desidia y espero ponerle remedio lo antes posible  porque quiero disfrutar de lo que hago día a día ya que elegí esta profesión para ganarme la vida porque es lo que me gusta.
• Este año, además, seguiré buscando maestros de los que aprender, quizás no serán los ‘maestros artesanos’ porque no hayan alcanzado la perfección, pero sé que hay mucha gente que puede enseñarte y aportarte algo.
• También quiero dedicarle más tiempo a este blog y poder añadir más contenido porque aún tengo algunos posts que prometí escribir, como la continuación a la entrada sobre Jasmine, que por unas cosas o por otras se siguen quedando en mi tintero.
• ¡Y dejo constancia públicamente de que tengo intención de que el 2011 no termine sin que yo tenga la L de conductora en mi poder!
• Y cómo no: leer, leer y leer un poco más, que tengo muchos de estos libros pendientes.

No son muchos propósitos, pero algunos son bastante ambiciosos, y lo más importante de todo, como ha dicho kini entre sus objetivos para el nuevo año, es que espero poder llevarlos a cabo rodeada de esa maravillosa gente que se va cruzando en mi camino y con la que no sólo comparto profesión.

¡Feliz 2011 a todos, y cuidado esta noche con las uvas!

• Agile Testing: A practical Guide for Testers and Agile Teams
• Analisys Patterns: Reusable Object Models
• AntiPatterns: Refactoring Software, Architectures and Projects in Crisis
• Beyond Software Architecture: Creating and Sustaining Winning Solutions
• Clean Code: A Handbook of Agile Software Craftsmanship
• Continuous Integration: Improving Software Quality And Reducing Risk
• Debug It!: Find, Repair, and Prevent Bugs in Your Code
• Design Patterns: Elements of Reusable Object-Oriented Software
• Effective Java: Programming Language Guide
• Emergent Design: The Evolutionary Nature of Professional Software Development
• Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
• Implementation Patterns
• Java Puzzlers: Traps, Pitfalls, and Corner Cases
• Object-Oriented Software Construction
• Patterns of Enterprise Application Architecture
• Practices of an Agile Developer: Working in the Real World
• The Pragmatic Programmer: From Journeyman to Master
• Pragmatic Unit Testing in Java with JUnit
• Refactoring Databases: Evolutionary Database Design
• Refactoring HTML: Improving the Design of Existing Web Applications
• Refactoring to Patterns
• Refactoring: Improving the Design of Existing Code
• Release it! Design and Deploy Production-Ready Software
• Ship it! A Practical Guide to Successful software Projects
• Structure and Interpretation of Computer Programs
• xUnit Test Patterns: Refactoring Test Code
• The Timeless Way of Building

También aprovecho esta entrada para poneros al día de los próximos eventos que van a organizarse en Madrid porque estamos que no paramos:

30-12-2010: Reunión del grupo Madrid.rb(@madridrb) que va a tener como tema un Coding Dojo guiado con @ecomba. Podeis ver la información aquí.

04-01-2011: Reunión del grupo MadriAgil que también tendrá como temática un Coding Dojo en el que esperamos contar con @ecomba y @plagelao.

08-01-2011: Después de los Reyes (que seguro que vendrán cargados de regalos para todos porque hemos sido muy buenos )  tendremos un Open Space que @jjballano se ha encargado de gestionar de maravilla. Las plazas iniciales están cubiertas, pero si estáis interesados, apuntaos que existe la posibilidad de que se abran más o de que haya bajas de última hora. Aquí teneis la información.

¡Espero veros por alguno de los eventos!

Hoy os traigo un resumen de lo que pasó el miércoles 24 de Noviembre en la reunión de MadriAgil.

Antes de empezar hubo un cambio de última hora dado que la reunión se iba a hacer en las oficinas del Vivero pero como el anfitrión se encontraba enfermo cambiamos el lugar a las oficinas de IPSA.

El tema que se había propuesto para la reunión era hablar sobre la primera parte del libro Peopleware, y aunque algunos no llevábamos todos los deberes hechos, íbamos con tantas ganas como siempre de escuchar, aprender e intercambiar opiniones.

En esta reunión me acompañaron Arturo(@ArturoHerrero), Jerónimo(@jerolba), Alberto Peña(@plagelao),  Raquel(@rlaina), Marcin, José Luis(@reemplazable) y Jose Manuel Beas(@jmbeas).

Empezamos con un resumen muy escueto para contextualizar el libro. Escrito en 1987 por los consultores Tom DeMarco y Timothy Lister habla de cómo gestionar a las personas en una empresa. Se cuentan fallos detectados por los autores explicados con historias concretas y se van proponiendo posibles medidas a tomar.

El término Peopleware, como puede leerse en esta entrada de la Wikipedia, se utiliza para referirse a cualquier cosa que tenga que ver con las personas en el desarrollo o uso de software y sistemas hardware.

Y la mejor forma de empezar a abordarlo nos pareció ir por cada capítulo, resumiendo un poco la idea general que aporta y discutiendo sobre ella.

En la introducción de la primera parte se presenta la teoría de que muchos de los problemas se producen porque las personas que gestionan tienden a adoptar las mismas medidas que ya conocían con las personas. Se planteó que esta problemática viniera dada porque las personas que gestionan vienen de la rama técnica, debido a cosas como la gestión de carrera que hay en España, donde llegado a un punto, para seguir ascendiendo un técnico tiene que dejar de ser técnico para pasar a ser gestor. Sobre este punto surgieron discrepancias ya que algunos de los asistentes apoyaban esta idea, mientras que otros alegaban que, al menos en su experiencia, las personas que se habían encontrado en puestos de gestión no tenían experiencia previa en puestos técnicos.¿Qué opinais vosotros?¿Cuál es vuestra experiencia?

En el capítulo 1 se expone la gran cantidad de proyectos que fracasan. Si se analizaran las causas de muchos de los fracasos, cosa para la que nunca hay tiempo porque siempre hay cosas más urgentes, se comprobaría que la mayoría no han sido producidos por problemas tecnológicos, sino por problemas sociológicos que habría que abordar mediante habilidades sociales. Y es que, al contrario de lo que muchos piensan, ¡no trabajamos con alta tecnología! La mayoría de nosotros nos limitamos a trabajar utilizando el trabajo de aquellos que sí están en la cima de la tecnología.

Del capítulo 2 la idea principal es que esto es desarrollo de Software, no un McDonald, y la forma de gestionarlo no puede ser igual. En entornos tipo cadena de producción lo que se necesita es hacer y vender rápido, con gente altamente reemplazable, donde todo se hace siguiendo unas instrucciones sin necesidad de creatividad. Pero si se aplica la misma mentalidad en un área de desarrollo sólo se conseguirá minar el espíritu del equipo.¿Y cómo se puede mejorar la cultura de empresa? Pues hay algunas pautas que habría que seguir:

1. Permite fallos, no presiones a la gente para que no los cometa. Hay que fomentar que la gente no busque culpables en los demás, que asuma sus errores. Pero hay que tratar con cuidado el tema de los fallos, porque también hay que fomentar que se aprenda de los errores no dejar que se cometan una y otra vez.
2. Los trabajadores no son piezas completamente reemplazable. Reemplazar a un trabajador en entornos de desarrollo de software tiene un coste que hay que tener en cuenta, pero una empresa no puede morir porque se vaya uno de sus trabajadores, por lo que es necesario que se comparta el conocimiento.
3. En proyectos de desarrollo no existe un estado estacionario que no sea de rigor mortis. Además, no se puede medir el valor que las personas aportan a un proyecto únicamente midiendo características como la cantidad de código que escriben o cuánta documentación han escrito.
4. Otro punto a tener en cuenta es que no todo el tiempo puede ir dedicado a hacer algo, porque, si dedicas todo tu tiempo a eso, ¿qué tiempo le dedicas a pensar en lo que tienes que hacer? Es necesario dejar tiempo para investigar, probar o leer libros.

En el capítulo 3 se habla de la productividad, un tema siempre presente en cualquier equipo de desarrollo. Sobre este tema las ideas que nos surgieron es que muchos gestores se encargan de buscar la forma de ganar batallas haciendo que los trabajadores intenten cumplir con entregas imposibles, sin pasarse del presupuesto (muchas veces a costa de horas extras gratis), cumpliendo con su labor de atender al cliente… pero al final pierden guerras porque acaban perdiendo a esos empleados, perdiendo con ellos el conocimiento adquirido. Me gusta cuando se dice en el libro que la gente bajo presión no trabaja mejor, sólo trabajan más rápido, y para ello hay que saccrificar o bien calidad del servicio o bien calidad de trabajo de los propios empleados.

¿Y por qué en la mayoría de las empresas de España se cuida tan poco al personal cuando son una parte tan importante del negocio?

A veces también da la sensación de que sólo se mide el coste del desarrollo inicial perdiendo visión del coste total que se incrementa en gran medida cuando empiezan a aparecer los bugs y son necesarios los mantenimientos.

Todo esto viene por vender tiempo de desarollo en lugar de vender un servicion. En este punto Marcin nos aportó un punto interesante de vista con su experiencia en Alemania y es que allí vendían un desarrollo, no a x personas trabajando x tiempo y la calidad no queda en manos del cliente que pueda elegir si quiere que trabajen 4 becarios y 2 analistas o 1 becario y 3 analistas, quien da el servicio establece la calidad, el cliente únicamente decide si compra el servicio o no.

Y continuando con el tema de la calidad llegamos al capítulo 4, “Calidad, si el tiempo lo permite”. Y es que esa es la actitud que nos encontramos en nuestros entornos mayoritariamente. Si el tiempo apremia, ¿qué podemos dejar de hacer?¡Las pruebas y las refactorizaciones! Quizás hubiera sido bueno que hubiera gente de las ‘altas esferas de gestión’ que quizás hubiera aportado algún otro punto de vista, porque todos los asistentes estábamos de acuerdo en que la calidad no puede negociarse ni pasarse por alto. Por ello, en lugar de seguir discutiendo sobre eso, enfocamos el tema desde el lado de cómo conseguir que se valore la calidad porque a la mayoría de los clientes no puedes hablarles de tu artesanía y la forma más efectiva parece llevarlo al terreno del dinero y mostrar por qué de una forma y otra ganas o pierdes dinero.

El último capítulo del que discutimos fue el capítulo 5 que versa sobre la ley de Parkinson la cual afirma que “el trabajo se expande hasta llenar el tiempo disponible para que se termine”. Pero poniendo fechas límite no se consigue que personas que no pueden realizar las tareas por falta de competencia, falta de confianza o falta de afiliación con otras personas del proyecto o con los objetivos de este vayan a rendir más. Además, presenta estudios donde se demuestra que cuando son los propios programadores quienes ponen las fechas la productividad aumenta frente a proyectos en los que las fechas vienen impuestas.

Así que con todas estas cosas en la cabeza dimos por terminada la reunión para ir a tomar unas cañitas y seguir discutiendo sobre temas varios. Para más información lo mejor es leerse el libro, que es cortito pero tiene mucho que aportar.

¡Así fueron las cosas y así se las he contado! :p

No deja de sorprenderme que tanta gente con apenas un par de directrices y muchas ganas sea capaz de organizarse tan bien para conseguir que algo llegue a buen puerto. También, a todo esto ayudó que hubiera gente en la organización con mucho entusiasmo y que se han esforzado tanto.

El viernes por la tarde, tras una pequeña introducción, ¡pasamos a la acción!

Hubo muchas propuestas de charlas y creo que entre mis propósito de año nuevo, cuando me esté comiendo las uvas este 31 de diciembre, me voy a comprometer a presentar una en el Aos2011 (acabo de volver de una y ya estoy pensando en la del año que viene, cierto, pero seguro que no soy la única a la que le pasa).

Cuando todas las propuestas estuvieron hechas, llegó el momento de que cada uno aportara su granito de arena indicando a qué charlas prefería ir para poder organizar, en base a nuestros puntos de colores, las charlas en las salas disponibles. No había problema en que varias charlas convivieran en una misma sala o incluso que tuvieran lugar en la cafetería, ¡no queríamos que ninguna se quedara fuera!

¡Y así quedó nuestro tablón!

Ya lo único que faltaba para terminar un día tan bueno era un poco de agilidad nocturna, una cenita con buena compañía.

A la mañana siguiente, con un poco de sueño y muchas ganas por el gran día que teníamos por delante, emprendimos el camino del hotel a La Salle para empezar con las sesiones.

Xavi Gost(@Xav1uzz) – Software que funciona, es nuestra responsabilidad

Con la expectación que siempre causa Xavi Gost, empezamos la sesión con una gran pregunta, ¿por qué hay tanto software que no funciona?, y no es fácil darle una respuesta.

Durante esa hora estuvimos planteándonos varios factores que hay alrededor, el más importante es la necesidad de asumir nuestra responsabilidad sobre aquello que desarrollamos, ser profesionales y conseguir hacer cosas que nos permitan sentirnos orgullosos de decir ¡soy programador!

Pero ante eso, siempre surge la misma inquietud: no todo el mundo va a querer asumir esa responsabilidad. Para enfrentarse a eso necesitamos ser agentes de cambio para ir poco a poco intentando mostrar a los demás las virtudes del cambio, aunque no puedas cambiarlos a todos, y respecto a eso me quedo con la frase que le escuché a Enrique Comba que si la memoria no me falla decía algo así como “al que está dormido, déjalo dormir, pero si estás despierto y quieres soñar, ven y sueña conmigo”.

Y una vez convencidos de la necesidad de cambiar, es necesario también el valor de asumir los imposibles, de ser capaces de decir que no cuando no se puede conseguir lo que nos piden y para eso Xavi hizo una comparación que me encantó diciendo que si alguien te da tres piedras y te pide que hagas zumo, ¿cómo vas a decirle que sí? ¡Es también parte de nuestra responsabilidad el saber decir que no!

Y con esas ideas en la cabeza, y la de intentar conseguir disfrutar de lo que hacemos, dimos por finalizada la primera sesión.

Enrique Comba(@ecomba) – Software Craftmanship

Aquí Enrique nos presentó la artesaría del software contándonos su historia y recordándonos cosas del manifiesto. Vimos la visión de talleres de artesanos del software que tiene, con la que podríamos denominar la carrera desde ser un aprendiz hasta ser un maestro, porque para todo hay grados.

¿Y cómo se puede ir creciendo en este camino? Para aprender, hay que buscar mentores que te puedan ir enseñando y transmitiendo su conocimiento, porque lo importante de todo esto es que el conocimiento se pueda transmitir y que no se diluya y se pierda con el tiempo.

Roberto Canales(@rcanalesmora) y Xavi Gost – Debate sobre los frameworks

Esta fue una de las sesiones que causó más expectación, todos queríamos ver qué argumentos daba Roberto a favor de los frameworks y qué decía Xavi Gost para justificar su visión maléfica de los frameworks.

Se nos ocurrió la idea de que los propios asistentes nos dividiéramos a ambos lados de la sala en función de nuestra posición al respecto y me pareció una idea bastante buena, además cada uno de los debatientes iba escribiendo a un lado de la pizarra los argumentos que iba proponiendo.

Los argumentos que al final quedaron a favor de los frameworks fueron:

1. Nuestra industria también necesita a gente poco cualificada a la que un framework puede ayudar.
2. Es una herramienta creada para algo, pero si ese algo lo sacas del contexto para el que fue creado e intentas darle un uso distinto, su aplicación puede no valer.
3. La gente no sabe desde el principio hacer software de artesano, por ello hay que darles alguna base sobre la que poder empezar a trabajar, empezar a hacer cosas y desarrollar sus conocimientos.
4. Los frameworks automatizan cosas importantes que no vas a estar repitiendo cada vez que tengas un proyecto que necesite de esa misma base.

Los argumentos finales que quedaron para el no fueron:

1. Los frameworks hacen ‘monos’, es decir, gente falsamente cualificada.
2. Sólo son útiles en manos de un experto y cuando un experto quiere usarlo al final acaba hackeandolo para poder realizar lo que quiere.
3. Automatiza cosas importantes.
4. No es necesario únicamente saber usarlo, es necesario conocer lo que hace y ser capaces de hacerlo nosotros.
5. El argumento final es el lema que utilizó la marca de neumáticos Pirelli hace un tiempo, “La p0tencia sin control, no sirve de nada”.

La conclusión que yo saqué es que realmente no eran posturas tan enfrentadas como parecía al inicio del debate, Xavi los considera ‘evil’ por lo peligrosos que pueden ser si se les da un mal uso, pero todos coincidíamos en que ese no es motivo para no usarlos, solo para tratarlos con más respeto y cuidado.

Raquel Laina – Agente del cambio

La presentación que Raquel hizo de su tema a la hora de proponerlo gustó mucho, así que la sala se llenó con gente deseosa de saber cómo llevar el cambio a su entorno.

Empezamos con una introducción que Raquel hizo sobre su visión de la evangelización y sobre algunas pautas que considera importantes para poder llegar a los demás que son las siguientes:

1. Es necesario saber vender el cambio igual que venderías cualquier otro producto, incluso utilizando trucos y prácticas de marketing.
2. Debes mostrar a los demás el beneficio que les va a aportar el cambio, lo que ellos van a ganar si te siguen.
3. Hay que ser constantes y no rendirse.
4. No hay que esperar nada a cambio, si haces esto esperando algo a cambio, te vas a quedar a mitad de camino sitiéndote decepcionado.
5. Hay que considerar la resistencia como algo positivo, porque es la única medida que tienes de tu avance, el único feedback que vas a recibir.
6. Hay que ser pacientes e ir poquito a poco, porque los cambios no se producen de la noche a la mañana, hay que ser como el río que va desgastando poquito a poco.
7. Hay que saber adaptarse a la hora de introducir el cambio en distintas personas o en distintos entornos porque no todo el mundo es igual y ninguna técnica te va a valer para convencer a todo el mundo.
8. Es importante el lenguaje que uses para transmitir lo que quieres, ¡cuídalo!
9. Y lo último pero no menos importante, los fracasos no tienen por qué ser malos, te pueden enseñar y ayudar a ver qué es lo que has hecho mal.

Cuando terminó de presentar su visión hicimos una ronda de propuesta de dudas o problemas al respecto y votamos los que nos parecían más interesantes para empezar a discutir sobre ellos. En la foto podeis ver los temas que salieron y espero que muchos de ellos se retomen en la lista porque fue una pena que no se pudieran tratar todos.

Enrique Comba – Inceptions

En esta charla Enrique quiso compartir con nosotros la forma en que ellos abordan un proyecto en su origen, qué serie de actividades realizan entre mienbros del equipo de Eden y el cliente para poder analizar lo que el cliente quiere.

Dos o tres miembros de Eden se juntan con todas las personas que el cliente quiera que vayan, incluso si es con usuarios finales mejor, y se van planteando los siguientes puntos:

1. Realizan una pequeña entrevista con el cliente en la que le piden que les cuente por qué está ahí y para qué quiere lo que les está pidiendo, intentando así aportarle la mejor solución.
2. Le piden al cliente que, utilizando un formato que ellos le muestran, cree algo así como un discurso breve con el que si alguien le preguntara en un ascensor sobre su producto o proyecto pudiera describirlo y contar qué es lo que lo diferencia de la competencia.
3. Lo siguiente que realizan es un diseño de una caja pensando en cómo sería si se pudiera meter en una caja y venderlo así en tiendas.
4. Después, crean una lista sobre lo que es el producto o proyecto, pero sobre todo haciendo hincapié en qué no es.
5. Hacen un análisis de la comunidad que rodea al producto/proyecto, planteando quénes son los clientes, los proveedores, la competencia, quién va a adorarlo… y por cada grupo se van creando personas imaginarias que pertenezcan a ellos indicando las características de esa persona, su situación, las cualidades que tiene…, para de esta forma sacar las implicaciones que puede tener en lo que se quiere desarrollar.
6. A continuación, se analizan los miedos. Se identifican y se intenta encontrar la forma de evitarlos o mitigar su efecto.
7. Una vez que se sabe qué se quiere, se le da forma. Se hace una tormenta de ideas entre todos para las épicas de las que se compondría e incluso se intenta pensar en distintas posibilidades para las pantallas que puedan formar parte del sistema y se dibujan.
8. También es necesario que el cliente indique las limitaciones que tiene jugando con las variables del alcance, el presupuesto, el tiempo, la facilidad de uso, pero nunca la calidad.
9. Para terminar, definen quiénes van a formar el equipo tanto por parte de la empresa como del cliente, se define lo que se promete y se establece un coste y una duración buscando referencias anteriores, pero con un amplio margen como por ejemplo, entre 3 y 6 meses.

Parece, como cuenta Enrique, que este sistema les funciona bastante bien y les permite gestionar bien el trabajo para encontrar la forma de que el cliente esté contento, ¡puede servir para tomar ideas de que otros modelos son posibles!

Enrique Comba – Cobrar a clientes siendo ágil

Como última charla me metí de nuevo en una de Enrique porque me parecía interesante escuchar el planteamiento de cómo cobrar al cliente de forma ágil, sobre todo teniendo en cuenta que no es un modelo teórico, sino que ellos lo aplican y les va bien.

Principalmente consiste en el cobro al cliente por iteración, así vas poco a poco asumiendo el coste. Tienen distintas opciones en el inicio del proyecto. Una de estas opciones es pedirle al cliente el pago de la primera iteración por adelantado, realizar dos iteraciones y si al final de la segunda iteración el cliente está satisfecho y quiere seguir, paga la segunda iteración y se continua el resto del tiempo con pago por iteración. Mucha gente se mostró escéptica en que este modelo pudiera funcionar aquí en España, ya que hasta ahora no se ha hecho nada similar aquí y creo que aún tendremos que esperar un tiempo para comprobarlo.

Las charlas ya habían tocado a su fin y lo único que faltaba era hacer retrospectiva para que año tras año sigan haciéndose estas actividades y que siempre vayamos mejorando.

No quise perder la oportunidad de hacer un llamamiento a las chicas del evento que, por los datos que me han facilitado, rondábamos en torno al 10% de los asistentes, para intentar formar un grupo de chicas que podamos mover cosas y servir como referente a otras chicas demostrando que somos más y que podemos hacer, un poco de piña para vencer esas barreras que en realidad no existen y por las que quizás más chicas se mantienen alejadas de este mundo.

Aquí podeis ver fotos de algunas de las asistentes e  incluso alguna organizadora del evento como @amaliahern. No aparecemos todas las que estuvimos porque algunas se habían tenido que marchar, pero al menos tenemos pruebas de que las chicas en la informática, como dicen los gallegos de las meigas, ¡haberlas haylas!

Por supuesto esa noche tampoco pudo faltar la agilidad nocturna, porque al final nos juntamos tantos, que somos casi como una gran familia a la que no se puede reunir siempre, pero cuando llegan las cenas de Navidad en las que se juntan, se lo pasan en grande, que creo que es lo que pasa cuando juntas a tantas personas tan distintas pero con tanto en común.

En conclusión, yo una vez más, termino un fin de semana como este cargada de buenas sensaciones.

Una de ellas, como creo que nos pasa a casi todos, es una inyección de energía para poder empezar cosas nuevas y para mejorar, avanzando en el camino empezado, al ver que alguien que ya ha pasado por ese tramo en el que estamos nosotros nos guía y nos tiende la mano para que no nos perdamos.

Otra, es de haber cumplido objetivos. Estando allí me he dado cuenta de que el mensaje que quería transmitir cuando empecé este blog había llegado a bastante gente, y lo que me parece más importante, era compartido y apoyado.

¡Espero que siga habiendo muchas actividades como esta y que yo pueda estar en ellas!

Sin embargo, en mi equipo de trabajo nos hemos centrado bastante en el desarrollo de algunas aplicaciones web y me di cuenta de que no le teníamos el mismo ‘respeto’ al código Javascript que al código Java y ¡no nos habíamos planteado escribir tests para esa parte! Hay que decir en nuestra defensa que el código Javascript escrito hasta ese momento podía catalogarse de bastante sencillo, no llevaba mucha lógica con mucha lógica y se apoyaba principalmente en componentes JQuery.

La cosa  es que no iba a quedarme tranquila hasta que investigara el tema de pruebas de Javascript.

Iba a empezar a trastear un poco con QUnit, cuando en un code retreat Xavi Gost (@XaV1uzz) me dijo que a él Enrique Comba (@ecomba)  le había recomendado utilizar Jasmine, así que con esas recomendaciones merecía la pena echarle un ojo!

Jasmine es un framework estilo BDD para probar código Javascript. Y como a andar se aprende andando, nada mejor que empezar con un ejemplo sencillo para ir viendo su funcionamiento.

Como acostumbro a trabajar con maven hice una búsqueda para ver si encontraba algo que me facilitara una primera integración y encontré lo mejor que podía encontrar, ¡un arquetipo con ejemplos de uso!

En https://github.com/searls/jasmine-maven-plugin está la documentación del plugin de maven y del arquetipo.

Para empezar, necesitamos crear un proyecto a partir del arquetipo. En la página del plugin indican cómo crear un proyecto por línea de comandos, yo voy a hacerlo usando Netbeans.

Para crearlo vamos al menú File->New Project y seleccionamos Maven->Maven Project y seleccionamos añadir un nuevo arquetipo con los siguientes datos:

Group Id: searls

Artifact Id: jasmine-archetype

Version: 1.0.1-SNAPSHOT

Repository: http://searls-maven-repository.googlecode.com/svn/trunk/snapshots

El pom.xml que se nos crea es bastante sencillo de entender puesto que únicamente nos añade los repositorios necesarios, el maven-war-plugin para la generación del war con todos los ficheros y la configuración del plugin de Jasmine. La explicación de los goals que vienen configurados se encuentra en la página del plugin.

En la carpeta Other Sources tenemos una carpeta javascript. Dentro de esta carpeta es donde pondremos todos los ficheros javascript que usemos y que queramos probar. Si quisiéramos utilizar librerías como JQuery tendríamos que meter bajo esta carpeta también sus ficheros, no importa la jerarquía de carpetas que se cree ya que se cargarán todos los ficheros javascript que se encuentren dentro de ellas.

En la carpeta Other Test Sources hay otra carpeta javascript en la que pondremos los ficheros javascript con las especificaciones(specs) y las pruebas de nuestro código.

Con el arquetipo se crean  unos ficheros que pueden servir como ejemplos, pero yo prefiero practicar con una kata y para la ocasión he seleccionado la String Calculator.

El primer requisito es que creemos el método add que reciba una cadena con cero, uno o dos números separados por una coma y el resultado sea ’0′ si no hay números, el número si se pasa unicamente uno y la suma si se pasan dos números separados por una coma.

Tomamos la parte más sencilla del requisito: Devolver ’0′ al recibir una cadena vacía.

Para comenzar creamos un fichero javascript para las especificaciones en la carpeta ya indicada. En él creamos una suite para agrupar los tests relacionados con nuestro StringCalculator. La forma de crearla es usando la función describe():

describe(‘string_calculator’,function() {
//Aquí añadimos las especificaciones
})

Y creamos nuestro primer requisito. Para ello utilizamos la función it() que recibe una cadena con la descripción de la funcionalidad requerida y la función a ejecutar.

it(‘devuelve 0 cuando recibe una cadena vacía’,function(){
var resultado = Add(”);
//Aquí van las comprobaciones de los resultados esperados
});

Para las comprobaciones del código esperado se utiliza la función expect() seguido de algún matcher de los que se encuentran en la página de la documentación. De esta  forma la prueba para esta especificación quedaría:

describe(‘string_calculator’,function() {
it(‘devuelve 0 cuando recibe una cadena vacía’,function(){
expect(Add(”)).toBe(0);
});
})

Le estamos indicando que esperamos que el resultado de Add(”) sea ’0′. Si ahora le damos a test sobre el proyecto veremos que en la salida aparece fallo de compilación, indicando que hay fallos en las especificaciones de Jasmine. Si leemos la salida podemos ver el error que ha dado:

it devuelve 0 cuando recibe una cadena vacía <<< FAILURE!
* ReferenceError: “Add” is not defined.

También podemos ver la salida producida en el archivo target/jasmine/ManualSpecRunner.html.

Como no hemos definido el método Add no puede encontrarlo. Así que vamos a crear un fichero Javascript en Other Sources/Javascript con dicho método. Definimos en él la función Add(cadenaASumar), pero lo dejamos de momento vacío y volvemos a ajecutar los tests, si actualizamos ManualSpecRunner.html vemos que el error ha cambiado y lo que no sindica es que no se obtiene el resultado esperado.

Para arreglar el test lo más sencillo es que hagamos que el método devuelva siempre ’0′, quedando el código

function Add(cadenaASumar) {
return 0;
}

Y para comprobar que funciona no hace falta que volvamos a ejecutar la opción de test, únicamente bastará con que actualicemos ManualSpecRunner.html y como únicamente hemos actualizado ficheros que ya teníamos creados en javascript se actualizan todos los cambios, ¡y por fin vemos un bonito verde como resultado!

Creo que ya ha quedado bien introducido Jasmine, así que como tarea os dejo que probeis a continuar la kata.

En próximas entradas una futura entrada intentaré poner una solución a la kata.

¡Un saludo a todos y a practicar!