Se hace camino al andar…

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

Archive for 2010

Simetría

Dec 31

Posted by jmbeas in Programando | 9 Comments

Lo siento, si alguien espera un post navideño (a pesar de los copitos cayendo por el blog) al estilo retrospectiva o propósitos de nuevo año, que se vaya buscando otro artículo. Creo que soy de esos que no tiene mucho apego por la Navidad. Sin embargo, ¡Feliz paso de año y que el 2011 os trate mejor que el 2010! (A todos, aunque hayamos sido -algo- malos) :-)

Bueno, al tema.

Picado por no haber podido estar ayer en el codingdojo de (la comunidad de Ruby en Madrid a la que, por fin, se acercó mucha gente que conozco), estaba yo practicando la codekata de los números romanos (una parte de ella, realmente, la de pasar a “romano”) y se me ocurrió hacer un pequeño cambio. En vez de usar un java.util.Map (sí, en Java, qué pasa :-) ) pensé en usar un array. Pensé que no debería afectarme mucho porque había escrito mi código haciendo mi mejor TDD (lo cuál no quiere decir que lo haga bien).

Para que tengáis una primera imagen de lo que hablo, mi método “String to_roman(int n)” es como sigue:

asdf
asp
fds
';document.write(content);
1

NUMERALS es un Map<Integer,String> ordenado para que “int find_biggest_numeral_that_fits(int i)” sea más fácil (y de paso eficiente). Pero lo que os quiero contar no es si es mejor usar un Map o un array para guardar esta tabla. De hecho, sobre esto se me ocurre otro artículo muy chulo sobre SRP (aunque no pueda superar éste de Hadi Hariri, claro). El caso es que, al cambiar la estructura de datos que soporta esto, mi algoritmo ha tenido que cambiar incluso hasta el método de más alto nivel de abstracción “to_roman”.

Recordemos el “Implementation Patterns” que, aunque no lo tengo a mano, recuerdo que hace hincapié en cuidar que nuestros métodos mantengan un nivel de abstracción coherente. En este caso es evidente que estamos llamando a “find_biggest_numeral_that_fits” para abstraernos de los detalles técnicos pero luego, en el mismo “to_roman” usamos NUMERALS para obtener el valor correspondiente. Hemos introducido una asimetría que no es muy dañina (en este caso que el problema es pequeño, que por eso es pequeño, para que podamos practicar sin que nos duela tanto como “en la vida real”).

Al refactorizar he cambiado “find_biggest_numeral_that_fits” por una llamada a “find_biggest_numeral_using_an_ordered_map” y ahí, al cambiar mi solución basada en un array y llamar al nuevo “find_biggest_numeral_using_an_ordered_array” me he dado cuenta de que no he cambiado NUMERALS y que sigue siendo un Map. .

He renombrado NUMERALS a NUMERALS_AS_MAP para que sea más evidente y así, he ocultado ese “código feo” en un bonito “String get_numeral(int i)”, lo cuál deja el método “to_roman” mucho más limpio.

asdf
asp
fds
';document.write(content);
1

Por cierto, observad también el leve cambio que he hecho en el orden de la linea 6, donde inicializo el StringBuffer. Me ha parecido que inicializarla “tan lejos” de donde la uso le daba un cierto tufillo que no me gustaba nada. ¿A que se lee mejor ahora? :-)

Espero vuestros comentarios. Seguro que se puede mejorar mucho aún.

Ea, lo dicho, ¡Feliz 2011!

Tags: , ,

Eclipse en colores

Dec 21

Posted by jmbeas in ecosistema, Programando | 5 Comments

Por si queréis probar con los colores en Eclipse. El leer mejor (más fácil) nuestro código nos puede ayudar a escribirlo mejor. :-)

Yo he cambiado el color de fondo y he resaltado algunos elementos sintácticos:

El color de fondo:
Window > Preferences > General > Editors > Text Editors > Appearance color options:

  • Background color = color personalizado R:217, G:217, B: 236 (un gris clarito para distinguir la ventana de edición del resto pero suficientemente clara para no tener que hacer muchos cambios en el resto de colores)

Colores “sintácticos”:
Window > Preferences > Java > Editor > Syntax Coloring > Java:

  • Inherited Method Invocations : Pink (R: 255, G: 0, B: 255). Esto hace que las llamadas a métodos heredados destaquen pero no demasiado.
  • Method Declarations: Orange (R: 255, G: 128, B: 0) y negrita. Esto hace que el inicio de un método destaque sobre el resto del código.
  • Methods: Dark green (R: 0, G: 128, B: 0) y negrita. Esto hace que los verbos destaquen frente a los sustantivos.

En fin, espero que os resulte útil. :-)

Tags: ,

La Movida Madrileña 2.0

Dec 18

Posted by jmbeas in Profesión | 13 Comments

En tiempos de crisis el ser humano exprime su imaginación. Un ejemplo que se me viene a la cabeza es la Movida Madrileña de los ochenta. (Me encanta eso de la Madrilenian groove scene). Una crisis social y cultural hace que la juventud madrileña busque maneras diferentes de hacer sociedad y cultura. Salvando las distancias (o no), creo que la crisis del dichoso modelo productivo está llevando en estos momentos a muchos jóvenes, en todo el mundo, en España y en particular en Madrid, a reinventar maneras de ser productivos.

Iniciativas como las de Jesús Jiménez o la proliferación de iniciativas similares (o diferentes) que se están viendo desde un tiempo a esta parte creo que demuestran lo que digo. Hay algo en común entre todos nosotros: las ganas de hacer. Sabemos que nuestro sector (el desarrollo de software) tiene un modelo en el que claramente no estamos a gusto. No nos permite hacer lo que sabemos, podemos, queremos… y como consecuencia, sólo parece haber una salida inteligente: crear otro modelo. Pero no tenemos más herramientas a nuestro alcance que nosotros mismos. En general no disponemos de grandes recursos financieros que nos permitan cambiar nuestro modelo y hacer las cosas de otra manera. Así que nos dedicamos a buscarnos entre nosotros y a explorar otras maneras de hacer las cosas.

Algunos, como Carlos Blé (con Mavencharts) o (con Wiseri) o Martín Pérez (con Jobsket) … o muchos otros, yo hablo de los que conozco (y me acuerdo ahora mismo) son tan valientes que se arriesgan mucho más y ponen su carrera en manos de un sueño. Otros nos dedicamos a “cantar nuestras canciones por los garitos”. Pero todos, absolutamente todos, tenemos algo en común: queremos cambiar nuestro mundo y hacemos algo para ello. Igual que la Movida Madrileña en su momento eran vistos por muchos como algo cutre, seguro que muchos (sobre todo compañeros de profesión) nos ven ahora como una panda de “frikis”, “talibanes de la tecla” o lo que sea. Pero es algo que, al menos a mi, no me preocupa lo más mínimo. Me gusta programar. Quiero poder llegar a los 67 (e incluso más) programando y, si puede ser, disfrutando de ello. Quién sabe, algún día, quizás, lleguemos a conseguirlo. Algunos seguro que lo consiguen. Mientras tanto, tampoco es que me preocupe mucho no conseguirlo porque me lo estoy pasando muy bien. (Lástima que los Hombres G no sean estrictamente de la Movida Madrileña, habría encajado muy bien). ;-)

Corrección: Me dicen y que Hombres G sí son de la Movida Madrileña. (Aunque la canción se publicó en 1989)

Corrección 2: me sugiere este video de La Mode, que es mucho más representativo de La Movida, pero… me quedo con la letra del que elegí originalmente.

Envidia

Dec 5

Posted by jmbeas in Personal | 4 Comments


envidia.

(Del lat. invidĭa)

1. f. Tristeza o pesar del bien ajeno.

2. f. Emulación, deseo de algo que no se posee.

Pues sí, el artículo de hoy va dedicado a la envidia. Hay dos tipos de envidia: la buena y la mala. Podría dedicarme a hablar de la mala, que tan cercana la tenemos en nuestro país, pero después del hemos entrado en el #positicember, así que hablaré sólo de la envidia de la buena. De ésa que te hace ponerte las pilas cuando ves que a tu alrededor pasan cosas buenas y tú te las estás perdiendo. Porque estoy que me muero de envidia desde hace una semana porque ha comenzado su internship en Eden Development. Ya me estoy imaginando a muchos diciendo eso de que lo están explotando porque está trabajando sin cobrar. Je, je. Bueno, no es eso lo que parece por sus posts. Alguno quizá diga que se trata de una secta, que con el buen rollito le están lavando el cerebro para luego ponerlo a picar Javascript en las mazmorras. Hombre, no sé. Ya te digo, no lo parece. Ayer estuve chateando con él y me pareció de lo más feliz. Pero si dejo que salga el envidioso (el malo) que llevo dentro, te diré que sí, que seguro que es así. Porque no es posible que gente que trabaja y que da resultados excelentes a sus clientes, sean capaces de tener ese nivel de buen rollo entre ellos. Simplemente: NO ES POSIBLE. Buaaaa, no es posible, no es posible, no es posible. NO PUEDE SER POSIBLE. El mundo real no puede ser también así…. [por favor, querido lector, haga una pausa dramática llegado a este punto]…. [y use ahora el tono más lastimero que pueda]… no puede ser así…

Y lo peor (mejor) de todo es que ES ASÍ. Alberto nos lo ha ido contando durante toda esta semana. Le está costando la pasta estar allí (y lo que le seguirá costando) y el tío está supercontento. Y el resto de Eden también lo está con él. Y ha aprendido. (Un montón, mucho más de lo que él siquiera es consciente ahora mismo). Y me atrevería a decir que Eden también ha aprendido (un poquito por lo menos) de él (aunque tampoco sean conscientes ahora mismo). Porque cuando las personas dejamos la envidia de la mala (y el resto de sentimientos negativos) a un lado, y nos centramos en mejorar nosotros mismos y a los demás que están junto a nosotros, ocurren estas cosas. Y eso es para estar muertito de la envidia. Porque nuestro dichoso “mundo real” también podría ser así. Pero claro, cuesta, hay que hacer esfuerzos para cambiarlos. Mucho mayores que ir todas las mañanas a trabajar, aguantar a tu jefe y a algún compañero c…ete… y todas esas cosas del “mundo real”. Alberto ha dejado su trabajo y muchas otras cosas (familia, novia, amigos…), ha hecho la maleta y se ha marchado en busca de su sueño. Eso sí que es un sacrificio. (Al menos a mí sí me lo parece) Y por eso lo envidio mucho más. Y por eso no quisiera que se le acabara. Enrique tuvo la idea de abrir una hucha para recibir donaciones para Alberto. He puesto un “widget” en este blog y yo ya he puesto mi aportación. Modesta, eso sí, porque tampoco está la cosa para muchos dispendios (que se acercan las Navidades y tengo que hacer las compras aún). ;-)

Bueno, en resumen, que este artículo está dedicado a un sentimiento de mucho más valor que la envidia (aunque sea de la buena): la felicidad. Estoy muy feliz porque Alberto es, por fin, el programador feliz y quería compartirlo con todos (los poquitos) que leéis esto para que también tengáis la oportunidad de alegraros por él.

Tags: , ,

Nueva vida: sin palabras

Nov 29

Posted by jmbeas in Nueva Vida | Comments off

Bueno, parece que ya no puedo seguir contando lo que pasa en este proyecto.

Gracias a los seguidores y a los que me habéis ayudado con vuestros comentarios.

Lo siento, ahora no puedo ser más explícito, quizás dentro de unos meses. Quién sabe…

Je ne peux pas plus écrire.

Nueva vida: seguimos vivos

Nov 28

Posted by jmbeas in Nueva Vida | 4 Comments

Hace casi 4 semanas que no escribo sobre el . No es que nos haya fagocitado a todos sino que he estado tan descentrado que hasta la retrospectiva de este viernes no he vuelto en mí mismo.

El ir a Barcelona para el Agile Open Spain 201o y luego a Donosti para un nuevo coderetreat con Enrique Comba ha ayudado, sin duda, a que en lo personal y lo profesional estuviera descentrado. Para colmo, en medio, más actividad social con el grupo de Agile-Spain en Madrid () y una interesantísima cena en casa de Enrique Comba, que prácticamente sirvió de despedida informal al tímido @plagelao, que algún día será conocido como Alberto Peña. ;-) Alberto es la persona que más envidio ahora mismo sobre la faz de la tierra: se va a hacer lo que más le gusta, hacer software, con gente que también le encanta hacer lo mismo y que, por si fuera poco, lo hacen muy, pero que muy bien. No hace falta decirle que lo disfrute porque seguro que lo hará. Así que sólo me queda envidiarlo. :-)

Aprendizaje: No se puede tener una vida social tan ajetreada con un entre manos. No es profesional.

Pero durante estas cuatro semanas han pasado muuuchas cosas en el proyecto. No todas malas. Algunas buenas. Por ejemplo, el nuevo analista para el backend se ha puesto las pilas y ha empezado a conocer la aplicación rellenando las paredes con pantallazos y flechas que explican la navegación. Poco a poco comienzan a darse discusiones frente a esos pantallazos y, lo mejor de todo, comenzamos a identificar defectos antes que los usuarios. También, poco a poco, vamos teniendo el modelo de datos en las paredes. Pero, como suele suceder en estos casos, las malas noticias se comen a las buenas. Es lo típico: basta que dejes un día el coche mal aparcado para que te pongan la multa. (Bueno, en nuestro caso es que dejamos el coche mal aparcado casi todos los días, ¡ya nos vale!)

Durante este mes hemos tenido sólo una retrospectiva (llegamos al convencimiento de que una retrospectiva por iteración era demasiado, porque nuestras iteraciones son -pretenden ser- de una semana). Y la que hemos hecho este viernes en realidad llevaba retrasada una semana porque no pude estar la semana anterior y luego la he ido aplazando hasta que ya me dolió demasiado. Eso sí, salí escaldado de la retrospectiva: me lo merecía.

Retrospectiva-20101126-menos

Bueno, es evidente que el equipo sabe que la cosa no va bien, que el “Jefe de Proyecto” no está haciendo bien su trabajo y por eso la cosa va a peor. Echan de menos lo que se había ganado al principio. Analicemos un poco todo lo que el equipo señaló como cosas con las que se encuentra incómodo y quiere eliminar.

Lo que más nos preocupa es que no tenemos un tablón. Ahora tenemos varios tablones abandonados. Al principio improvisé un tablón en un papel de embalaje pegado en la pared y nos sirvió para ir adquiriendo foco en nuestras actividades diarias. Ahora tenemos unos “lujosos” tablones de cartón-pluma que me costaron un dineral y que aún no he pasado como nota de gastos a Kotasoft (que amablemente se ofrecieron a pagarlo). Pero estos están abandonados. Así que… (y de los grandes). Quería que tuvieramos un tablón para la iteración en curso, otro para ir preparando la iteración siguiente, otro para el product backlog y otro para tener todas las tareas que se deben hacer periódicamente (todos los días, todas las semanas, todos los días 20, etc). Pero he cedido al día a día y no he cuidado el tablón (ninguno de ellos). Ya lo sé, no tenemos dueño de producto, pero eso no es óbice para que yo no haya puesto la energía necesaria para tener, al menos, el tablón de cada iteración actualizado. Es una herramienta fundamental para enfocar al equipo (a todo el equipo).

Durante estas últimas semanas habíamos conseguido ya un cierto ritmo sostenible, donde habíamos empezado a encontrarnos cómodos poniendo en producción de manera controlada todas las semanas, para ello tuvimos incluso que forzar a que fallara una puesta en producción. Pero no sé bien en qué momento nos dejamos ir (especialmente yo) y el ritmo sincopado de este proyecto nos ha ido absorbiendo. Y como consecuencia hemos empezado a no tener clara la gestión de la configuración. Incluso hemos tenido un despiste que nos ha llevado a poner un war viejo en producción. Vaya cagada. . (Otro más). ¿Cómo mejorar esto? ¿Más concentración? Bueno, seguramente ayudaría, pero no creo que ésa sea la solución a la mayoría de los problemas. Es evidente que tenemos que automatizar mucho más. El paso a producción es aún demasiado manual y no tenemos muy claro cómo probar que todo está correcto. El amigo (compañero de Kotasoft) se está currando un screencast (o una serie, ya veremos) sobre cómo incorporar Selenium a nuestra integración continua con Hudson. Ya uno de los “javeros” del equipo ha estado jugando con Selenium, así que calculo que será fácil incorporar un par de “smoke tests”, lo que nos ayudará a asegurarnos diariamente de que no estamos rompiendo cosas evidentes y, poco a poco, a que vayamos teniendo una batería de pruebas y automatismos que nos vayan dando más seguridad. Sabemos que esto no es una solución definitiva, pero es un paliativo necesario.

Otro frente donde tenemos que hacer más hincapié es una de las anotaciones en rojo (las que hemos señalado como acciones a tomar tras la retrospectiva): un calendario de tareas semanales en torno a la gestión de la configuración. Algo como: “¿cuándo arrancamos una iteración?”, “¿cuándo congelamos el código y abrimos la rama correspondiente?”, etc. Eso y un radiador de información claro donde se indique cuáles son los entornos y las versiones desplegadas en cada momento serán muy útiles. Esto es fácil de hacer y nos puede ayudar mucho a reducir los errores.

El jueves y el viernes estuve programando. (Cosa que me ha reprochado abiertamente Víctor: “sé que te apetece mucho programar pero ahora necesitamos que priorices”. ¡Vaya! Es la primera vez que en una retrospectiva en España alguien del equipo es tan honestamente sincero. ¡Bravo!)

El caso, y vaya en mi descargo, tenemos un proceso de negocio que consiste en la generación de unos PDFs que terminan llegando a manos de los clientes finales y en el que tenemos a un miembro del equipo involucrado hasta tal punto que si él no está el proceso de negocio falla y no se envían esas comunicaciones. Este proceso, antes de yo llegar pasaba por las manos del jefe de proyecto anterior, que con buena voluntad se había involucrado, pero que sinceramente creo que era un error porque ponía en manos de un equipo de desarrollo la responsabilidad de controlar un proceso de negocio, cosa que NO es de nuestro negociado. Así que, desde el principio he dejado claro que el control de ese proceso (mientras fuera una actividad manual) quedaba fuera del equipo de desarrollo porque somos desarrolladores, no gerentes ni administrativos ni nada por el estilo. Por fin parece que el “management” se ha decidido a hacerse cargo de él y, como era de esperar, se ha provocado un pequeño caos. Bueno, en realidad ha sido algo peor de lo que yo esperaba. Nos ha provocado más revuelo interno y no hemos podido digerirlo bien. Por eso me centré el jueves y el viernes en rediseñar la parte de la aplicación que se encarga de esto, para ser capaces de tener piezas bien desacopladas y configurables y así poder quitarnos de enmedio. Pero no pude terminarlo (de hecho lo he dejado incluso sin compilar en el PC de mi compañero… ejem, otro más en mi debe) y eso me va a obligar a ponerme las pilas el lunes por la mañana y llevar tareas “de gestión” hechas desde casa. Pero esta tarea es MUY IMPORTANTE y tenemos que dejarla lista cuanto antes si no queremos tener más problemas.

Las anotaciones sobre DESORGANIZACIÓN y el RETROPLANNING (poner fechas y contar hacia atrás para hacer el plan) son muy interesantes. Por una parte, tengo la sensación de que la autoorganización comienza a funcionar, aunque en general el equipo siente la necesidad de que se les diga lo que deben hacer. En este asunto siempre he tenido una duda muy fuerte: debo forzar la situación y dejar que el equipo se autoorganice sin más, o debo ejercer de Jefe de Proyecto que dirige y reparte tareas para, poco a poco, ir dejando que el equipo se vaya autoorganizando. No sé. Sé que este tipo de cosas hace salir de su zona de confort a más de uno y provoca mucha incomodidad y se añade a otros cambios que se están provocando que contribuyen a la sensación de caos. Pero bueno, tampoco es que estemos desorganizados porque yo esté provocando un cierto caos controlado. No es eso. Es cierto que estamos desorganizados porque no estoy (como “coach”) manejando bien la transición desde el modelo tradicional al ágil y eso hace que el resto de dinámicas que deberían estar más controladas se hayan salido un poco de madre. Afortunadamente, nuestra Directora ha conseguido reducir la presión y priorizar el aseguramiento de lo que está en producción. Bueno, inmodestamente he de decir que en parte fue después de una reunión muy tensa con el malhumorado (y maleducado) Presidente, donde me salió el James Cagney que llevo dentro, pero que al final creo que fue bien porque hemos conseguido dejar claro que el proyecto está en una situación muy delicada y que requiere la implicación de toda la compañía si quieren salvarlo. Es un proyecto crítico, donde hay muchos intereses en juego y fracasar no es una opción para nadie. Y parece que esto es algo que, poco a poco, se va asumiendo y se están priorizando sólo tareas con fechas legales con el objetivo de que podamos consolidar la aplicación y los procesos que actualmente están en producción. Esperemos que sea suficiente. En cualquier caso, en la retrospectiva el equipo ha indicado esto como algo positivo, aunque también están preocupados porque parece que las fechas que se han establecido son demasiado justas. Cierto, son fechas que realmente no se han podido negociar porque casi todas son obligaciones legales o de marketing establecidas desde hace tiempo.

Por último, que ya veo que me ha salido un ladrillo como los que acostumbra Enrique Amodeo, resumir que, a pesar del rapapolvo que el equipo me ha dado en la retrospectiva, he de decir que estoy muy pero que muy orgulloso del resultado de esa retrospectiva porque es un ejemplo de honestidad por parte de todos. Han dicho abiertamente lo que piensan, por el bien del proyecto, sin más. Y eso, para mi, es muy importante, porque quiere decir que tenemos un equipo. Sólo hay que conseguir recuperar el ritmo sostenible y lo demás (la autoexigencia y la autodisciplina) vendrá por sí mismo. :-)

P.S.

ya ha comenzado a retomar el contacto con su hijo deforme (el #proyectodelamuerte). Se va a ir incorporando poco a poco y no hemos tenido tiempo de arrancar ese kanban del que hemos hablado para tener una lista de tareas que podemos ir abordando con su ayuda. Me ha encantado el cariño con el que todo el mundo lo ha recibido, yo diría que incluso la gente que no lo conocía. :-)

A ver si podemos consolidar esta semana que viene el fichaje de y con esto tendríamos un equipo listo para recuperar al paciente en la parte Java.

Tags:

Agile Open Spain 2009

Nov 12

Posted by jmbeas in Agile, Profesión | 3 Comments

Sí, sí, no me he equivocado al escribir el título. 2009. Debería estar haciendo la maleta porque en unas horas me monto en un AVE para compartir en Barcelona unos días que seguro serán muy enriquecedores en lo personal y lo profesional. Voy al Agile Open Spain 2010. Pero y han escrito sendos posts en sus blogs que, con su tono evocador, me han hecho emocionarme. Porque, aunque sólo sea un poquito, yo he tenido que ver en que estas dos personas (yo diría más incluso: amigos) ahora sean más felices. Yo no sé a vosotros, pero para mi eso es a lo más que una persona puede aspirar en la vida: ayudar a que la gente sea feliz. Y yo, aunque sea un poquito, sólo un poquito, he ayudado en eso.

Pero basta de sentimentalismos. Que yo quería hablar del Agile Open del año pasado. El primero en España. Sí, el primero. No voy a hacer otra glosa histórica de “cómo se hizo Agile-Spain” pero sí me gustaría recordar el espíritu pionero de aquellos días, donde me recuerdo comentando a Joserra que si al final estábamos 50 ya sería un éxito. Y al final nos reunimos allí más de 130. ¡Qué pasada!

Sin el apoyo de la UPM, Agustín Yagüe y su equipo de investigación,  seguro, seguro, seguro que el Agile Open Spain 2009 habría sido mucho más modesto, más que nada porque no habríamos podido conseguir un sitio tan amplio. ¡Más de 130 personas! ¿Pero sabéis lo más alucinante de todo? Que la mayoría no era de Madrid. Había gente de todos sitios. Y todos teníamos algo en común: buscábamos algo… una luz… algo que nos guiara. ¿Y sabéis qué? Que muchos encontramos esa luz… en nosotros mismos. Gente como Xavi Gost nos dijeron:

¡No esperes que ellos cambien, cámbialos tú!

Y desde entonces hasta ahora ha llovido muchísimo y muchas cosas han cambiado. ¡Ya te digo que si han cambiado! Hay grupos de agilistas en muchas ciudades… y cada vez hay más. Yo he pasado de ser el primer presidente de la asociación Agile-Spain (creada para poder organizar eventos como éste o como la Conferencia anual) a ser el primer ex-presidente de la asociación Agile-Spain. :-) Y con mi amigo Xavi Gost, y ese logo tan chulo que se curró para agilismo.es, y el apoyo económico inestimable de otros amigos (sobre todo Autentia), hemos hecho mini-eventos (siempre gratuitos) donde sembramos la semilla del profesionalismo y el gusto por el código limpio y bien hecho. He podido cenar con Brian Marick (firmante del Agile Manifesto y un programador como la copa de un pino) e incluso comparto confidencias con Enrique Comba (otro de los culpables de que este sector esté cambiando). He conocido a profesionales excelentes (y mejores personas) tanto en el grupito de como fuera de Madrid. ¿Qué más puedo pedir?

Hasta tal punto ha cambiado que hoy, sin ir más lejos, he entrevistado a un candidato para mi “proyecto-de-la-muerte” y, sorpresa, sorpresa, había oido hablar del Agile Open Spain 2010. Bueno, no estaba muy seguro… ¡pero había oido hablar! ¿No os parece alucinante? Hace un año, si nos hubiéramos reunido 50 nos habría parecido todo un éxito.

Pero en lo personal también he cambiado mucho. En un año he pasado de preguntarme dónde está la gente que quiere hacer buen software en España a decirle (perdón: exigirle) a los que me rodean que tenemos la responsabilidad de hacer buen software. Y lo hago con convicción.

¿Y cómo se pasa de un escenario a otro? Pues fácil. Cambiando tu escenario habitual cada día un poquito. (Tan fácil y tan difícil). Vale, hay pasos que nos cuesta dar. Díselo a o . Así que bienvenidos eventos como estos si sirven para que los que ya tenéis el gusanillo de asumir nuestra responsabilidad como profesionales del desarrollo del software, dejéis de quejaros de lo mal que está todo, deis un paso adelante, como lo han hecho y , y os unáis a nuestro ejército de agilistas que, armados con nuestros principios y sobre todo muchas ganas de mejorar y (como diría Xavi Albaladejo, el actual presi de Agile-Spain) “ser más felices en nuestro trabajo”.

Nos vemos en el Agile Open Spain 2010. Sí. 2010. :)

Tags: , ,

Nueva vida: semana 5

Nov 2

Posted by jmbeas in Nueva Vida | 3 Comments

La semana pasada ha sido una semana un poco rara. Hemos puesto en producción la versión 1.3.0, después de poner en un entorno nuevo (DEMO) la 1.3.0-RC1 el lunes por la noche y la 1.3.0-RC2 el martes por la noche. La negociación para lo que debía entrar en la 1.3.0-FINAL creo que tuvo más que ver con que no tenemos aún rodado este nuevo proceso con la falta de confianza que da el estado actual de una de las funcionalidades que queremos poner en producción para liberarnos de procesos manuales. Así que tuvimos un poco de ruido de fondo. El equipo estuvo “casi” trabajando sin verse afectado. Pero yo tuve discusiones por teléfono con nuestros ¿dueños de producto?. Mi inglés a nivel negociación deja algo que desear, pero mi inglés a nivel defensa creo que no está mal.

La puesta en producción fue “casi fina”. Se nos olvidó ejecutar un script que actualizaba unos datos y eso nos provocó un poco de desasosiego al principio de la mañana. Lo resolvimos bien, aunque debemos aprender para el futuro a tener mucho más controlado lo que hay que hacer para los pasos a producción.

Pero la ley de Murphy es implacable y, tras el paso a producción, un par de problemas sin conexión alguna con el nuevo código hicieron que el viernes tuvieramos a medio equipo dedicado a encontrar qué estaba pasando. Sólo puedo decir que, efectivamente, es una cagada importante que nos va a impactar bastante, pero bueno, hay que vivir con estas cosas. “El mundo real” creo que le llaman algunos. ;-)

Además de este ruido, inherente al pasado y presente del proyecto, tuvimos una visita de quien yo diría que es lo más parecido a nuestro dueño del producto. Estuvimos todo el día haciéndole preguntas, tratando de averiguar cuáles son las verdaderas prioridades (aparte de los compromisos que algunos tengan en forma de project plan) y, sobre todo, haciéndole entender la esencia del nuevo proceso. Yo, en mi linea de sinceridad “estilo House” (la verdad aunque te duela), me la desayuné diciéndole que el proyecto estaba medio muerto, que soy el quinto jefe de proyecto que pasa por aquí, que el código está muy mal, que hay funcionalidades sobre las que no tenemos el control y que no podía comprometerme ahora mismo con ninguna fecha porque no tenía ni idea de cuánto podíamos tardar en hacer una funcionalidad cualquiera. La cara de esta buena señora fue pasando del rosa pálido al blanco mortecino. Me preguntó: “¿Tienes un plan?”. Je, je. Me encantan esas preguntas. “¿Un plan con fechas? No. Pero tengo un plan: el equipo va a entregar todas las semanas un poco. Y siempre lo más importante.” Bueno, creo que llegados a ese punto, no era suficiente. Le enseñé ufano mis tablones. (No están del todo bien, pero ya me valían para lo que quería enseñarle). Le dije: “¿Ves?” Mmmm. Creo que tampoco la convencieron. Hasta que recurrí a las metáforas. ¡Benditas metáforas que todo lo pueden!

Quiero que el equipo sea como un ciclista. Quiero que empiece a pedalear. Primero pedaleará un poco despacio, pero a medida que se vaya encontrando cómodo irá pedaleando mejor y más rápido. Sin cansarse. Todo lo que haga falta. Así, si vamos pidiéndole pequeños esfuerzos todas las semanas, los podrá ir consiguiendo.

Le expliqué lo importante que es para nosotros, ahora mismo, enfocarnos en las tareas y tener claro lo que se considera “acabado-acabado”. Por eso le expliqué lo interesado que estoy en que seamos capaces de entregar a su equipo de QA pequeñas funcionalidades para recibir feedback lo antes posible y poder revisar lo que estamos haciendo para no propagar malentendidos por toda la aplicación. Y parece que, entre mi machaque metodológico y de sinceridad brutal, que “los chavales” la acribillaron a preguntas sobre dos o tres funcionalidades que no estaban claras, y que le enseñamos la generación de un informe que antes tardaba cerca de una hora y ahora apenas unos segundos… sus defensas bajaron. (Bueno, también tuvo que ver que la tuvimos sin desayunar y la llevé a comer bastante tarde, pero resulta menos literario). :-)

Después de comer (por cierto, Ramón, pagué yo) nos pusimos a escribir tarjetitas. Resulta que su prioridad es muy parecida a la nuestra: tener el control sobre lo que está en producción y luego ser capaces de tener para fin de año funcionalidades que deben estar “sí o sí” porque son obligaciones legales. Así que estuvimos escribiendo historias de usuario (bueno, lo más parecido que pudimos) para tratar de tener más claro que ahora que lo que está en producción actualmente es correcto. Si comprobamos todo eso junto a uno de sus compañeros, que va a estar con nosotros esta próxima semana, y sacamos las dos o tres tarjetas que el cliente final-final está esperando:

Eso sí, hemos escrito un montón de tarjetas nuevas pero no hemos negociado qué otras cosas se quedarán fuera de esta iteración: .

También se nos ha quedado en el tintero escribir (aunque sea por encima) las tarjetas de las otras prioridades importantes (aunque no urgentes). Así que me toca hacerlo a mi. :-(

Con tanto ruido el viernes, alguien (creo que fue Victor, el ScrumMaster en prácticas) me preguntó: “¿vamos a hacer la retrospectiva?” Diossss, ¡ni me acordaba! La verdad es que como coach y como scrummaster dejo mucho que desear. Bueno, total, puse en la balanza los beneficios de hacer la retrospectiva el viernes o dejarla para otro día. Ganó el dejarla para otro día. No sabría si considerarlo un . Un poco sí, porque rompemos el ritmo (que aún no tenemos), pero creo que los beneficios de estar trabajando con nuestra “dueña de producto” eran más interesantes.

Por cierto, que no se me olvide. Uno de los “javeros”, que resulta ser el pistolero más rápido al Oeste del Pecos (ya sabéis, es de los que dispara y después pregunta), se ha llevado el libro de TDD de Carlos Blé y el Implementation Patterns de Beck. Sé que el segundo no se lo leerá a pesar de las dos semanas de vacaciones que se lleva. ¡El inglés, esa gran barrera! Pero tengo muchas esperanzas en él y no descansaré hasta que, como mínimo, sea capaz de hacer un “extract method” (aunque no tenga tests) <– ¿He dicho yo eso?

Y por último, un poco de autobombo y autocomplacencia: mi jefa me presentó como “il grande mago”. Por suerte, el equipo tiene los pies en la tierra y en la anterior retrospectiva ya habló de que, de momento, contamos con el efecto “cambio de jefe de proyecto” pero que no podemos caer en pensar que hemos conseguido nada. Ea, a acostarse que mañana hay mucho que hacer. Hemos cambiado un poco la fecha de releases porque esta semana hemos tenido un día menos y nuestros QA no querían tener menos tiempo para probar. No es grave. Seguimos buscando nuestro ritmo sostenible.

Actualización:

Se me olvidaba. Esta semana también se incorporó un nuevo compañero. Debo agradecerle su comprensión porque mi falta de previsión me ha hecho tenerle prácticamente abandonado y sin ni siquiera un ordenador con el que trabajar. Ya tengo planes para él. Los pondremos en común y a ver cómo los podemos poner en práctica. :-)

Tags: , , , , , , , , ,

Por qué programar es divertido

Nov 1

Posted by jmbeas in Profesión | 4 Comments

Hace unos días vi que uno de los asistentes a la conferencia SC2010 ha publicado el video del discurso de despedida de Jason Gorman (os recomiendo sus videos de la serie “The Code Smell of The Week”), en el que Antony Marcano (os recomiendo sus videos de PairWithUs) hizo una lectura muy inspiradora de un extracto de “The Mythical Man-Month”: “The Joys of The Craft”. (Para los que queráis ir directamente a la lectura: min 4:15)

Me he atrevido a traducirla. Espero que no haya perdido demasiado la poesía del original.

¿Por qué programar es divertido? ¿Qué placeres puede esperar como recompensa el que lo practica?

En primer lugar está la pura alegría de hacer cosas. Igual que el niño se divierte jugando con el barro, el adulto se divierte construyendo cosas, especialmente cosas que él mismo diseña. Creo que este disfrute debe ser una imagen del disfrute de Dios al crear las cosas, un disfrute que se muestra en la diferencia y novedad de cada hoja y cada copo de nieve.

En segundo lugar está el placer de hacer cosas que son útiles para otra gente. En lo más profundo, queremos que otros usen nuestro trabajo y que lo encuentren útil. En este sentido, el sistema de programación no es esencialmente diferente del primer portalápices de arcilla que hace un niño “para la oficina de Papá”.

En tercer lugar está la fascinación de modelar objetos complejos como rompecabezas de piezas móviles que se encajan y verlos trabajar en ciclos sutiles, extrayendo las consecuencias de principios presentes desde el inicio. El ordenador programado tiene toda la fascinación de la máquina de petacos o el mecanismo de la gramola, llevado hasta el extremo.

En cuarto lugar está el goce de aprender siempre, que surge de la naturaleza no repetitiva de la tarea. De una manera u otra el problema es siempre nuevo, y quien lo resuelve aprende algo: a veces práctico, a veces teórico y a veces ambos.

Finalmente, está el deleite de trabajar en un medio tan dúctil. El programador, como el poeta, trabaja apenas ligeramente separado de pensamientos puros (inmateriales). Construye sus castillos en el aire, de aire, creando mediante el esfuerzo de la imaginación. Pocos medios para la creación son tan flexibles, tan fáciles de limpiar y reconstruir, tan rápidamente capaces de hacer realidad grandes estructuras conceptuales. (Como veremos más tarde, esta gran ductilidad tiene sus propios problemas.)

Sin embargo el programa, a diferencia de las palabras del poeta, es real en en el sentido de que se mueve y funciona, produce señales de salida visibles y separadas del programa en sí mismo. Imprime resultados, pinta dibujos, produce sonidos, mueve brazos. La magia del mito y la leyenda se ha hecho realidad en nuestro tiempo. Uno escribe el encantamiento adecuado en el teclado y una pantalla vuelve a la vida, mostrando cosas que nunca antes fueron ni pudieron ser.

Por lo tanto programar es divertido porque gratifica los deseos creativos que llevamos en lo más profundo de nosotros y deleita las sensibilidades que tenemos en común con todos los hombres.

Y como dice Antony Marcano al final de esta lectura: “Y por eso es por lo que amo la artesanía del software”.

Por cierto, otra lectura recomendable sobre este tema sería “La ética del hacker” (tranquilos, en español y, de hecho, epilogado por un español: Manuel Castells).

Tags:

Nueva vida: semana 4

Oct 25

Posted by jmbeas in Nueva Vida | 5 Comments

Con retraso. Este fin de semana llegaba con las pilas descargadas y encima tenía faena familiar (el cumple de niño1) y que madrugar para ver a Fernando Alonso ganando en una especie de circuito de F1.

Estuve a mitad de semana a punto de escribir algo porque teníamos el segundo paso a producción, no pudo ser y me quedé un poco chafado. No poner en producción no era realmente lo que más me fastidiaba. Hombre, hubiera estado muy bien poder seguir progresando y poniendo software que funciona en producción para que el cliente fuera viendo que las cosas van a mejor y reduciendo la presión sobre las capas de arriba y, consecuentemente, sobre el resto de los implicados/afectados. Pero bueno, visto con perspectiva, tampoco ha estado mal. He pensado en qué cosas hemos estado haciendo mal (especialmente yo, que soy quien está impulsando el proceso de cambio).

Tengo la sensación de que no he hecho bien (e.d. he hecho mal) varias cosas que nos han llevado a no poder controlar la situación y, simplemente, poner en producción lo que había listo. Que hubiera sido lo razonable.

Ya he contado antes que este proyecto es muy chungo, pero eso no quiere decir que sea aceptable caer en fallos típicos como:

  • ceder a las urgencias
  • no ir acabando historias en el orden de prioridad establecido

así que ya sabía cuáles eran las grandes fuerzas contra las que tenía que luchar. Y sin embargo, se me olvidó lo más importante: para lograr el cambio es necesario ser fiel a los principios, que son la verdadera fuerza que contrarresta a las otras. No soy yo la fuerza que logrará el cambio. Eso, además de una pedantería, es una necedad. Hoy he leído un twit que viene muy al pelo:

Si quieres ir rápido ve solo. Si quieres ir lejos ve acompañado.

Se me olvidaron dos cosas fundamentales:

  1. Delegar. El equipo puede hacer muchas, muchas cosas que yo, por muy superhombre que me pueda sentir en un momento dado, no puedo hacer solo. Lo único que estaba consiguiendo al no delegar era desgastarme y perder el foco, es decir, NO hacer bien mi trabajo.
  2. Ritmo sostenible. Estaba haciendo un gran esfuerzo buscando el hacer posibles ciertas tareas. Al final, el cansancio me pudo y cometí errores y descuidé otras tareas más importantes. Se me olvidó que el ritmo sostenible es para todos, no sólo para los demás.

Así que, viendo la inevitabilidad del fracaso en el paso a producción (se nos descontroló el encoding en los ficheros de propiedades con los literales de los mensajes que aparecen en la aplicación, alguna funcionalidad que no estaba del todo bien cerrada y mi propio desenfoque en las tareas necesarias para controlar cuáles eran las funcionalidades que queríamos poner en producción), organicé una reunión para revisar el proceso de paso a producción y la organización interna del equipo.

Así, hemos oficializado la separación del equipo de desarrollo y de soporte a la producción. He delegado las tareas de todo lo relacionado con el soporte a la producción. Ojo, se delegan las tareas, no la responsabilidad. Si algo no se hace como es debido será mi culpa. Pero sé que he delegado eso en la persona más apta para hacerlo. Es lo mejor para todos y, en el fondo, lo único que estamos haciendo es reconocer una organización de las tareas que estaba ocurriendo de facto.

El otro cambio consiste en hacer (o tratar de hacer) entregas en producción todas las semanas. Como diría UncleBob: “¡como lo hacen los verdaderos hombres!”. Aceleramos el ciclo de release para obtener feedback mucho más rápido y, sobre todo, para poder forzar a toda la organización a desembarazarse del “efecto release”. Estoy empujando mucho para que todas las funcionalidades se troceen en cachitos pequeños. Requisitos que dejen de tener títulos generales, de esos que aparecen en el primer nivel del dichoso documento de Análisis Funcional que NADIE-ABSOLUTAMENTE-NADIE se ha leido, por más que se haya pagado por él.

Poco a poco los compañeros se van acercando a los libros que tengo sobre la mesa. El otro día uno de ellos, un viejo programador de COBOL y NATURAL me pidió el “User Stories Applied” de Mike Cohn. Casi me echo a llorar de alegría. Y mañana le llevo el “Implementation Patterns” a otro compañero. Veremos si éste se lo lee. El inglés, ese viejo enemigo… :-)

Y finalmente. El viernes tuvimos nuestra segunda retrospectiva. Estuvo menos bien que la primera, fundamentalmente porque no la facilité bien. Perdí el foco varias veces y no conseguí que la gente participara con la frescura que lo hizo en la primera. Debo prepararlas un poco mejor. La retrospectiva es clave para tomarle el pulso al proyecto desde el punto de vista del equipo. Aun así salió bastante bien y el equipo sacó temas muy interesantes:

  • Queremos un protocolo para gestionar bien las peticiones que nos llegan desde el exterior. Normalmente al equipo se le interrumpía muchísimo con peticiones por correo, por teléfono, físicamente, y todas urgentísimas. Evitar esto es algo que les preocupa muchísimo. Afortunada o desgraciadamente los que pueden hacernos de PO (dueño de producto) están muy lejos y se está usando Mantis para tratar de organizar la comunicación con ellos. Así que el equipo ha reclamado un flujo de trabajo bien definido para esto.
  • Algunos miembros del equipo nos hemos incorporado hace bien poco, por lo que no tenemos NI IDEA de qué va la aplicación y ni siquiera el negocio que trata de resolver la aplicación. Por eso hemos reclamado una formación específica en ambos terrenos.
  • Las reuniones diarias se siguen alargando demasiado. Hemos identificado que hay un miembro del equipo (concretamente yo) que alarga mucho sus intervenciones y que a veces nos descentramos y no nos dedicamos exclusivamente a responder a “las tres preguntas” (hombre, a veces hay que comentar un poco, para que fluya la información, pero a veces nos pasamos…). Hemos decidido que un voluntario, ¡Bravo Víctor!, tomará el rol de moderador. Bueno, será el martes porque hoy lunes se nos olvidó a todos. :)

Hubo dos cosas que me llamó la atención en esta última retrospectiva:

  • la primera es que nadie (ni yo mismo) nombró el hecho de que había sido un fracaso no poder poner en producción (bueno, sí, fue llamativa la frase “no pasamos a producción pero no hubo gritos como otras veces”). Yo diría que eso es bueno, pero no sé…
  • y la segunda es que a mi pregunta de si el nuevo proceso les gustaba o les resultaba molesto alguien contestó: “nos sentimos mejor aprovechados” y “nos sentimos más equipo”.

¡Subidón!

Tags: , , , ,