diciembre 29, 2011

Pequeña recopilación por el 7º

El 29 de Diciembre de 2004 inauguraba este blog, hace ya 7 añazos. Es una edad importante, debería estar en Primaria, controlando ya las sumas, restas hasta con llevadas... y yo aquí, de tantas cosas que tengo en la cabeza, no sé ni que planes contaros para el próximo año.
Así que he hecho una pequeña recopilación de mis posts que más me marcaron de todos estos años (emocionalmente hablando, en realidad).

Bueno, gracias por seguir ahí unos cuantos :) Este año 2012 promete ser muy interesante y espero que pronto os contaré muchas novedades.

¡Feliz 2012!


noviembre 01, 2011

Las sesiones de CAS201: personas y retrospectivas

En esta pasada Conferencia Agile-Spain participé en dos sesiones, y me gustaría contar aquí mis impresiones. En mi personal visión de la conferencia comenté que me habían parecido el nivel de las charlas un poco irregular, y me debo incluir con esa misma evaluación:
Al final, os pongo los documentos y las presentaciones. Me encantaría que si estuvisteis en alguna, me dieseis el feedback que estimeis oportuno. Ya sabeis, ¡mejora continua! ;)

"Equipos autoorganizados, ¿deberíamos haber estudiado psicología?"

Esta sesión la hicimos entre mi compañera Olatz Zamora y yo. Aunque tenemos visiones diferentes en algún tema concreto, compartimos la misma idea esencial sobre los equipos. El feedback que nos ha dado la gente ha sido bastante bueno, encajando las ideas presentadas con las experiencais de mucha gente.
Las partes positivas de esta sesión:

  • Convocamos a mucha gente, por lo intuyo que acertamos con la temática.
  • Creo que transmitimos una idea muy clara, aderezada con un juego y nuestra propia experiencia.
  • El juego encajó bastante bien, aunque cada vez que lo veo jugar, saco conclusiones diferentes. La pregunta de "Yo que soy el 11 en el equipo, ¿qué hago?" todavía me sorprende!!
  • Olatz lo hizo fenomenal, y eso que era su bautismo de conferencias! :)
Las cuestiones mejorables:
  • No preparamos el sitio antes, y el juego lo tuvimos que hacer en el pasillo.
  • Deberíamos haber cuidado más la presentación, estilos de letra.
  • Tenemos que trabajar más el hilo de las presentaciones, y mantener el estilo de historia, durante toda la presentación.

    Taller de retrospectivas

    Esta segunda sesión considero que me salio más floja que la primera, aunque es cierto que el feedback que he tenido, de momento ha sido principalmente positivo. Sin embargo, no quedé demasiado satisfecho, veamos a continuación por qué:
    Aspectos positivos:
    •  Hubo mucho debate, se compartieron muchas ideas. Aunque generó un punto negativo que luego veremos.
    • El material de la charla creo que va tomando fuerza. En esta ocasión le añadi la idea de retrospectivas de creación de equipo y de creación de futuro.
    • Los participantes se lo curraron de verdad.
    • Siguiendo en esta linea, creo que voy a tener material para hacer un taller de pago de seis u ocho horas, que realmente merecerá la pena ;)
    Las cuestiones mejorables:
    • Mala gestión del tiempo: Como tenía dos horas, puse más material en la presentación, pero los debates se me fueron de la mano, y del reloj. Al final, acabamos con prisas y mal.
    • Me falló el hilo del taller. El planteamiento que hice de los ejercicios no funcionó bien, y no pude ligar el primero con el segundo, de la manera adecuada. Tuve que improvisar y se notó.
    • También en esta sesión no había previsto el formato de la sala, y era realmente incómoda para que la gente trabajase en grupo.
    A continuación os pongo las presentaciones realizadas, que las disfruteis :)




    octubre 23, 2011

    CAS2011. Ya ha pasado

    Ya hemos estado en la 2ª Conferencia Agile Spain, y quiero comentar mis impresiones.
    Nosotros finalmente pudimos llegar al "warm-up" un rato el miercoles, y escuchar un rato la presentación de artículos. Me alegra muchísimo ver el esfuerzo que hace Agustín en la universidad para enseñar estas cosas del agilismo a los alumnos. Y para mi fue un descubrimiento ver a Juan Gasca presentando una aproximación de Scrum a un proceso de "Design Thinking". Me encanta que podamos enriquecer nuestras ideas con otros mundos paralelos. Creo que voy a intentar liarle para hacer alguna colaboración :)
    El jueves daba comienzo por fin la conferencia. Arrancamos con la ponencia de Xavier Quesada. A mi personalmente me gustó mucho por que hizo referencia a un par de temas que estoy interesado últimamente: la eliminación de silos y enfoque sistémico. Nos introdujo al concepto de "Failure Demand", porqué es importante hacer bien las cosas a la primera. Y casi se me cae la lagrimita cuando puso la foto de las personas que estábamos en la refundación de Agile-Spain en Madrid, hace ya tres años. Gracias :)

    Así que después empezaron las sesiones. Tres tracks en paralelo. Genial la organización que grabó todas las sesiones y después podremos disfrutar de ellas. Me voy a forzar a ser binario, y voy a separar las sesiones que no me aportaron, y las que sí. Por supuesto, en mi situación personal, no por que fuesen malas charlas o geniales :)

    Las sesiones que más disfruté fueron:
    • From Dev To DevOps, de Carlos Sánchez. Tenía ganas de conocer a Carlos y me acerqué a su charla. No conocía mucho el tema, y me parecio un movimiento muy interesante para mejorar problemas concretos, al topar con el muro de sistemas en algunas ocasiones. Saqué ideas y alguna herramienta a la que echar un vistazo: Puppet.
    • Cosas que nunca te dije, de Aventia, con Javier Gomez. Otra implantación más de agilismo en una empresa, pero me sorprendió el enfoque. La idea de generar comunidad antes de empezar, de hacer ruido, de crear un grupo ágil antes que empezar un proyecto en una organización me rompio un poco los esquemas :) Y me dio que pensar.
    • Stop the line, de F-Secure. La idea de implementar esta idea de Lean, la he aparcado de mi cabeza muchísimas veces, y ahora que he visto una implantación real, y que sacan conclusiones positivas, la voy a recuperar. :)
    No me aportaron demasiado:
    • Workshop Kaizen, de Juan Felipe Pons. Buena introducción a Lean, pero yo pensaba que era un workshop la propia charla, pero contaba cómo hacerlo. si quereis un vistazo rápido a Lean, echadle un vistazo.
    • Un paso adelante, de Enrique Comba. Me temo que no llegué a captar el verdadero mensaje de la sesión. Eso sí, la entrada en escena espectacular, aunque luego no la hilase con la sesión :D
    • BKOOL, de Arturo Herrero y Marcin Gryszko. La puesta en escena muy original, y la charla muy currada, ya que hablaban de un producto para ciclistas con las etapas del Tour, muy currado. Aún así, muchas cosas era como verse reflejado un poquito de mi propia historia, sobre todo en las miserias :)
    • Show me the money, de José M. Beas. Pensaba que iba a tener un enfoque más de mercado, sin embargo, hizo un repaso, original sin duda, de los principios desde el punto de vista de ingresos o gastos.
    De todas maneras, os aconsejo que dediquéis tiempo a bucear por los videos, esto solo son mis experiencias personales.
    Además de estas sesiones hubo otra keynote de J. B. Rainsberger, que también disfruté y os recomiendo que veais el video en cuanto esté disponible. De las sesiones plenarias, lo más flojo fue la mesa redonda, pues no hubo discusiones demasiado enriquecedoras. 
    Finalmente terminamos con la retrospectiva. La verdad que no atendí demasiado, pues estábamos ya más pensando en el viaje de 5 horitas en coche y salir pronto. (De hecho, finalmente fueron casi 8 horas de viaje, pero eso es otra historia... :D) Y luego leyendo tweets y blogs sobre la conferencia, me he quedado un poco preocupado por la sensación que capto, pues intuyo un poco de insatisfacción.

    Mis conclusiones son las siguientes:
    • Felicidades a la organización: Raquel, Emma, Amalia, Juan, Ricardo y Xavi se lo han currado. Y organizativamente, fue casi excelente. Además había por allá mucha gente que supongo serían compañeros de Ricardo en la universidad. A todos, GRACIAS. Sin ellos, no hubiese sido posible.
    • El nivel de las charlas fue irregular. Para el futuro creo que deberíamos cuidar más el proceso de selección de las mismas, incluyendo un proceso de feedback por el comité. Los ponentes podríamos tener unas primeras críticas, que nos ayudasen a preparar mejor las sesiones, y con más tiempo. Por supuesto, mis sesiones, podéis situarlas tranquilamente al nivel que creáis, no me pongo por encima de esto, y lo hablaré en un post más concreto.
    • La idea de los eventos patrocinados me parece genial. La paella de Atlassian, la comida del viernes por OpenFinance, y sobre todo la cena del jueves en una sala de fiestas, por PlasticSCM me parecieron la guinda del pastel en la organización.
    • En un evento así, si no haces networking es por que no quieres, por que momentos los había. Aunque tengo la impresión de haber dejado unas cuantas conversaciones a medias, pues íbamos siempre con un poco de prisa, o encontrabas a alguien al que saludar.
    • El movimiento ágil en España todavía necesita quitarse complejos. Es bueno hablar con sinceridad de lo malo que nos puede haber pasado, como experiencia de aprendizaje, pero también es bueno "chulear" de los éxitos, y compartirlos.
    • Una mesa redonda debería girar alrededor de una pregunta más concreta, en la que los ponentes tengan visiones diferentes. Y quizás cinco personas son demasiadas para una hora.
    • He visto mucha gente "nueva", y esto cada vez lo vamos a ir notando más, si consolidamos esta conferencia. Lo que he visto es menos ponencias internacionales, el año pasado existieron unas cuentas en inglés.
    Esta conferencia básicamente depende de dos cosas: de lo que curren los organizadores y del nivel de las sesiones. Así que el año que viene, animo a todo el mundo a hacer una de las dos cosas como apoyo a la comunidad :) 
    En una sola frase, estoy muy contento de haber asistido a esta CAS2011. Espero impaciente CAS2012.

    Nota: Podeis leer más comentarios sobre la conferencia en esta recopilación.

    octubre 07, 2011

    Personas y retrospectivas en la CAS2011

    Dentro de unos días será la Conferencia Agile-spain 2011, y si os acercais por allá podreis disfrutar de una seguro fabulosa conferencia. Yo estaré en un par de sesiones:

    La primera será la titulada "Equipos autoorganizados, ¿deberíamos haber estudiado psicología?", que copresento junto a mi compañera Olatz Zamora. Intentaremos contar nuestras experiencias de estos últimos años en la creación y gestión de equipos. Nuestra impresión es que conseguir equipos autoorganizados es difícil, y sin embargo no hay demasiada literatura en el mundo ágil sobre ello.

    La segunda sesión será un taller sobre retrospectivas. Básicamente será el taller del AOS2011, pero algo ampliado, y con más tranquilidad para desarrollarlo.

    Espero veros por allí... si estas no os interesan, os aseguro que hay muchísimas cosas más interesantes! :)


    septiembre 06, 2011

    Visual Management Open Space 2011, mi resumen

    De nuevo tuve la suerte de poder asistir a un Open organizado en Decide por Raquel Laina -esta chica se merece otro aplauso ;) - y esta vez era para hablar sobre la gestión visual. No tenía muy claro el alcance del tema, pero se refería a lo siguiente:

    • Visual Thinking
    • Visual Management
    • Información visual
    El tema abarca bastante más allá de los tablones que usamos en metodologías ágiles, y podía ser un gran aprendizaje. Os cuento ahora un pequeño resumen del evento:
    Por supuesto, hicimos la parrilla el día anterior sacando temas entre todos, pero esta vez los clasificamos para organizar la parrilla del día siguiente. Se prepararon dos tracks. Una idea muy interesante fue el realizar una "red social de baja tecnología", vamos un dibujo de nuestra propia red social de la gente del evento, que se iba completando conforme teníamos contacto con más gente.


    Creo que deberíamos experimentar más con esta idea. Con una pantalla táctil, con elementos arrastables sería genial, aunque ya no de baja tecnología :D

    La primera sesión a la que asistí fue a la tablones, por X. Quesada.

    Esta era una sesión que seguro que se iba a producir, y teniendo a X. Quesada en el Open estaba claro que íbamos a aprender de los mejores. Recordad que Xavi que es uno de los expertos en Visual Management. Nos enseñó fotos de los tablones de los proyectos en los que participa en Belgacom. Proyectos de decenas y varios equipos reflejados fielmente en un panel, algunos de ellos realmente impresionantes.  Algunas ideas con las que me quedé:
    • Colocar en algún lugar del panel las tareas de las personas ajenas al proyecto pero que nos influyen.
    • Destacar el area de impedimentos en el panel.
    • Se pueden representar las épicas con la división gráfica de sus historias de usuario, con las dependencias.
    • Muy interesante el planteamiento de un panel Kanban, limitado físicamente, con casillas, para marcar el WIP. 
    Alguna idea además me llevé para el equipo de coaches de Biko :)

    La segunda sesión estuve entre Doodle y Paper prototyping.

    La sesión de Doodle no me enganchó, y enseguida fui a la de prototipado de baja fidelidad. Se trata de una especia de TDD de la usabilidad :) y vas testeando la aplicación antes de realizarla, con prototipos muy muy sencillos pero que intentan reflejar la realidad sobre papel. Es una técnica para trabajar junto con el cliente en las fases iniciales de los requerimientos. Aquí podeis ver un video de ejemplo.

    La tercera sesión fue la de tablones no estandar.

    Enrique Amodeo nos explicó un panel en círculos para Kanban, donde cada círculo representa un grupo de especialistas. A ver si alguien nos indica pronto una foto de su idea, por que no sé explicarla demasiado bien.
    Yo conté el primer panel que hicimos en un proyecto Scrum, y resultó que gustó bastante la idea :). Se trata de representar la aplicación en una pizarra (historias de usuario, pantallas, relaciones, etc.) e ir marcando el avance del proyecto sobre la misma. No necesitamos post-its, pues basta con indicar qué cuestión está trabajando cada persona, y diferenciar por color lo realizado de lo pendiente. Es una idea que necesita más exploración.
    X. Quesada nos presentó como visualizan el backlog en sus proyectos. Con la lista de historias de usuario en un listado, pinta de amarillo las que se están en progreso, que una vez son finalizadas se pintan de azul y se mueven al final del backlog. De esta manera, parece que sube el nivel de agua :) Fácil y muy gráfico

    Cuarta sesión. Mapas mentales

    Me temo que no saqué demasiado provecho de esta sesión. Yo iba con intención de hablar de mapas mentales como representación de ideas/pensamientos, pero estuvimos hablando de mapas mentales como soporte de mapas de historias de usuario.

    Ultima sesión: Brainstorming Visual

    Raquel Laina nos presentó una variante del brainstorming y su análisis posterior para hacerlo más visual. La primera variante se trataba de agrupar los conceptos obtenidos por brainstorming, y sacar las relaciones a modo de mapa mental. De esta manera obtenemos una visualización de los problemas o temas obtenidos por el grupo.
    La segunda variante me parecio muy interesante, y se trata de realizar el brainstorming, pero partiendo de una representación visual del proceso o tema a tratar. De esta manera da ideas y ayuda a hacer relaciones entre conceptos.

    Conclusiones

    Lo primero, otro aplauso para Raquel ;) Es una maravilla poder asistir a estos eventos, de calidad por gente con ganas de compartir y de aprender. Sobre todo de compartir. Me vuelvo con muchas ideas interesantes de un tema del que soy un ignorante, pero que seguro podré aprender ahora:

    Me gustó mucho también el realizar "lighting talks" con los temas que no habían salido en las votaciones. La autoorganización hizo que pudiesemos hablar un rato de retrospectiva visuales o "user story mind mappings". De esta manera, ningún tema se queda sin tratar si interesa a alguien. O sea, un Open Space :)





    agosto 24, 2011

    Libros en castello (original) sobre agilismo

    El otro día preguntaba por Twitter sobre libros, originalmente escritos en castellano, en el tema de desarrollo de software ágil. No iba la pregunta por buscar material en castellano, si no por ver la fuerza que tenemos los hispano hablantes de generación de contenido en este mundillo. De momento tengo estas referencias:

    • Navegapolis: Juan Palacio tiene el primer libro que yo me compré sobre este tema. Aunque en realidad era una recopilación de sus posts, era contenido original y de gran calidad (y tenemos versión actualizada en su blog). Actualmente no lo encuentro en la web, pero dispone de otro "Flexibilidad con Scrum"
    • Diseño ágil con TDD: Carlos Ble escribio este magnífico libro sobre desarrollo guiado por tests. Tuve la suerte de poder ayudarle un poquito con la revisión del mismo.
    • Ingeniería de software ágil: No conocía este libro, y no lo he leido (todavía). ¿alguien que pueda decirnos algo?

    Así que no tenemos mucho material, aunque supongo que se me pasa más de uno. ¿no generamos libros la comunidad hispanohablante por que somos todavía más consumidores de conocimiento/experiencia? ¿ conocéis más libros sobre metodologías/gestión ágil/Lean originalmente escritos en castellano?

    Llega la Conferencia Agile-Spain 2011

    Ya está muy avanzada la organización de la CAS2011, y desde aquí quiero avisar, difundir y apoyar este seguro magnífico evento que tendremos en Octubre.
    Cuando lancé la organización de los dos eventos de Agile-Spain este año, pensaba dedicarme a la organización de la CAS fundamentalmente, sin embargo, las circunstancias han hecho que este año vaya a ver esta conferencia desde la barrera. Eso sí, espero que sea como ponente, ya que prepararé un par de sesiones.
    Tanto si estáis introducidos en el mundo del agilismo como si no, si simplemente os dedicáis a desarrollar software o gestionáis empresas donde juega un papel fundamental, deberíais acudir a esta conferencia. Se reunirán las mejores personas con las experiencias más interesantes. Se hablará de cómo enfocar los desarrollos y su gestión, y decenas de temas que no te puedes perder. Además, vamos a poder escuchar a dos ponentes de excepción: Xavier Quesada y J.B. Rainsberger.
    Yo estaré allí sin dudarlo, si coincidimos, compartiremos una buena charla :)

    junio 28, 2011

    Mi "elevator pitch" del agilismo

    Si solo dispusiese de unos segundos para explicar los beneficios de sumarse al agilismo, diría algo parecido a esto: 

    La clave con el agilismo es proporcionar el marco adecuado para que los trabajadores puedan demostrar todo su potencial. La gestión por control permite un trabajo tan bueno como lo es el que ordena y controla (o menos!). El cambio de paradigma hacia lo ágil permite multiplicar la potencialidad de los equipos al multiplicar las de sus integrantes.
     Para dejar que un equipo madure, debes permitirles fallar y que encuentren su propio camino. Las metodologías ágiles fomentan el fallo temprano, para minimizar riesgos. 
     Además, los principios ágiles fomentan la creatividad (personas sobre procesos), la búsqueda de resultados (software que funciona sobre documentación) , la mejora continua y la excelencia (responder al cambio sobre seguimiento del plan) y la orientación al cliente (colaboración sobre negociación).

    junio 21, 2011

    Resumen AOS2011

    Pues por fin pasó el #aos2011 que tantas horas de sueño me ha hecho "perder" :) Mi primera impresión es que el evento ha sido muy satisfactorio para la gran mayoría de asistentes. Como organizador, eso es lo que más tranquilo me deja. Y como propio asistente a uno de ellos, la verdad que también me fui muy contento, con el desarrollo de mis dos sesiones, con las que acudí y, por supuesto, por la gente con la que conversé.
    Durante la recepción del viernes estuve un poco nervioso ante tanta gente, culpa mía, ya que debía haber preparado un poco más el guión :). Pero salvo que he aprendido que si tu hablas con la persona de la derecha, el de la derecha debería hablar con el de su izquierda, creo que fue bastante bien :o)
    La gente del CEIN se portó de manera impresionante con el tema de la logística, y las instalaciones inmejorables, estuvieron siempre perfectas gracias a ellos.
    Os cuento un poco las sesiones por las que pasé durante el sábado:

    • Taller de retrospectivas: Mi primera sesión fue una sorpresa hasta para mi, pues algún elemento de agile-norte salio en mi nombre a presentarla el viernes. Y fue bastante votada. :) Así que después de cenar, y antes de dormir (¡la una de la mañana!), tuve que preparar brevemente lo que iba a hacer, a ¡primera hora del sábado! Se me ocurrio que podría hacer una retro sobre cómo hace la gente la retros. Yo no tenía que currar demasiado ;) y el resultado podía ser interesante.
      Intenté hacer los típicos pasos de las retros según la biblia de las retrospectivas, Agile Retrospectives, e ir usando una técnica que me gustase en cada uno de ellos, trabajando en grupo. Además, intenté dar alguna idea que les aportase un poco más de valor según mi experiencia. Espero haberlo logrado.
      La imagen muestra el diagrama de Ishikawa del más común del problema en las retros: la confianza.
      Creo que este taller en un formato de 3/4 horas puede quedar perfecto. Con una hora creo que parecí una ametralladora, pero al menos, obligue a todas las personas a fijarse una acción concreta para llevarse a casa. :)
    • Seducir a las empresas: Raquel y Amalia proponían que nos planteasemos el modo que accedemos y que nos mostramos a las empresas en las fases de selección de personal. Me gustó por que salio el concepto de marca personal, y se abrió un debate interesante sobre el valor que podemos y queremos mostrar de nuestro trabajo, mucho antes que una entrevista tradicional. Se debe trabajar de manera constante tu imagen, puesto que vas a ser buscado en Google en cuanto llegues a manos del seleccionador de la empresa. ¿Has probado a "googlearte"? Ten en cuenta la imagen que transmites, pues llegará a la empresa que te entreviste.
    • Talento: La tercera fue conducida por Raquel e Israel, donde debatimos de la idea de qué era el talento, si lo necesitamos en las empresas y cómo conseguirlo o retenerlo. Bajo mi punto de vista quizás abundaron un poco demasiado los tópicos, pero fue interesante. La idea que me quedó, es que la gente con talento va donde quiere, cuando quiere y como quiere. :)
    Después de esas tres charlas por la mañana, la última sesión matutina me la tome de descanso y estuve charlando por los pasillos. En realidad, una de las sesiones más interesantes, hablando con Xavi Gost, GermanDZ, Teresa Oliver o D.Bonilla entre otros... 
    • El equipo eres tú: Mi segunda charla volvía a sacar mi tema favorito: la construcción de equipos. Quería debatir la idea desde el punto de vista de alguien dentro del equipo, de las acciones que podía tomar una persona para llegar a mejorar y crear equipo de alto rendimiento. Raquel tiene un verdadero conocimiento de estos temas, y demostró su capacidad de análisis de las situaciones complicadas. Así que trabajamos sobre la pizarra las ideas para que funcionen los equipos de alto rendimiento, y las acciones que podía tomar una persona para dirigirse hacia ello. Confianza y un objetivo comun parecen las claves.
    • Comunidades ágiles: Por último asistí a la sesión que charlamos sobre las comunidades locales. Salieron acciones concretas que podeis encontrar en los post-its :)
    Así que terminamos las sesiones y pasamos a la retrospectiva. Hicimos un sencillo ejercicio, identificando lo que queríamos dejar atrás, lo que nos llevábamos, y lo que no había habido pero nos gustaría. La gente salio a comentar sus temas, y salieron ideas interesantes. Por supuesto, tratamos de fijar acciones concretas como una buena retro, y algunas cosas ya salieron. Podeis ver el acta (1, 2 y 3), con unas preciosas notas de Xavier Verges.
    Intenté que salieran directamente voluntarios para el siguiente AOS, pero lo que salieron fueron dos lugares como candidatos: Zaragoza o las islas Canarias. Bonita pugna :) No les envidio en la organización, que el listón está muy alto :P
    Y con esto terminamos este largo AOS2011. Agotador. Enriquecedor. Un poco sorprendente, y muy estimulante.

    NOTA: Podéis encontrar mucha más información en el site de agile-spain. Y Carlos Ble grabó un podcast especial de podgramando con algunos de los protagonistas.

    junio 12, 2011

    Visión del desarrollo ágil de software

    Me liaron para dar una charla en The Mêlée (yo encantado, claro), y me propusieron hablar desde mi experiencia con metodologías ágiles. Así que lo que intenté finalmente es exponer mis razones para considerar las metodologías ágiles, y cuales son las partes que más valoro actualmente.
    Os escribo un pequeño resumen, y podeis encontrar alguna explicación más en la documentación adjunta en slideshare (desarrollo ágil de software). Mis tres razones básicas por las que he llegado al convencimiento de que las metodologías ágiles son las más adecuadas para desarrollar software son las siguientes:

    1. El axioma Equipo = Producto
    2. El software es un juego coaborativo, de comunicación y finito
    3. El desarrollo de software se realiza sobre un sistema complejo
    El primer punto fue el que empezó realmente a hacerme plantearme mi manera de pensar en este mundo del software. Yo debía hacer equipos capaces y sobresalientes, más que proyectos y productos. Ese cambio de responsabilidad, me implicaba centrarme más en las personas con las que trabajaba.
    En ese momento, el manifiesto ágil encajó perfectamente en mi cabeza. Mi conclusión es que el objetivo principal es entregar valor al cliente, obviamente bajo la perspectiva de paso sostenible. Y los valores que he ido adquiriendo son:
    • Colaboración: búsqueda de la visión compartida
    • Mejora continua, sin descanso, y adaptándonos al cambio.
    • Autoorganización de los equipos, obtener lo mejor cada persona.
    • La Calidad es incuestionable.
    • Las buenas prácticas son indispensables, pero cuidado que a veces nos hacen perder el objetivo.
    • El camino de la mejora de gestión y técnico deben ir unidos.

    mayo 25, 2011

    Eventos en zona norte:

    Este mes y poco que resta hasta finales de Junio se presenta muy intenso, te invito a que te unas a cualquiera de estos eventos que tenemos por esta zona del norte, donde podremos coincidir!

    • 28/Mayo: Katayuno y Merendojo, donde estaré haciendo un pequeño taller de historias de usuario (esa es la presentación en que me basaré), cortito pero intenso, ya que Luis me lo propuso. Te puedes apuntar!
    • 1/Junio: Reunión habitual de la zona norte de agile-spain. Más info en el blog apuntado.
    • 3/Junio: Reunión del grupo The Mêlée, al que tenía demasiado abandonado lamentablemente, y resulta que ahora vuelvo con charlita incluida :) , acompañando a Guillermo que nos hablará de control de versiones.
    • 17-18 Junio: El Agile Open Spain vuelve con fuerza, tras vender en 4 horas (¡4!) las 150 entradas disponibles. Este año he vuelto a colaborar con la organización de tan magno evento, así que... ¡¡Allá nos veremos!! Quizás esteis a tiempo de apuntaros en la lista de espera si no lo habeis hecho ya.
    Creo que me toca sudar la camiseta antes de las merecidas vacaciones.

    mayo 12, 2011

    Peligro, las herramientas te cambian de objetivo

    Generalmente buscamos en las herramientas que empezamos a utilizar la respuesta a un problema. Tenemos una necesidad que queremos cubrir, y creemos que una determinada herramienta la cubre: necesidad de llevar el control de incidencias, necesidad de orden en el desarrollo, necesidad de comunicarnos,...

    Generalmente estas herramientas acaban fagocitándonos y cambiandonos el objetivo que queríamos alcanzar con ellas. Nos olvidamos de nuestra necesidad inicial, y alimentamos al monstruo en que se convierten.
    En vez de minimizar las incidencias, nos quedamos satisfechos con que estas estén en la herramienta de control. En vez de procurar aprender a desarrollar software, nos quedamos tranquilos sabiendo que seguimos los pasos de una metodología -herramienta- que nos dicen que es buena. En vez de hablar, nos comunicamos por messenger o por correo electrónico.

    ¿cuando ha sido la última vez que pensaste que las herramientas te dominaban?

    mayo 09, 2011

    Retrospectivas: Busca necesidades y no problemas

    Cuando planteamos problemas en una retrospectiva, generalmente tenemos una idea ya prefijada de las causas que los pueden estar produciendo. Esto nos lleva a plantear muchas veces la lo que creemos que es la solución como el propio problema o impedimento a solucionar que tenemos.

    Sin embargo, creo que hay que llevar a las retrospectivas la verdadera necesidad que tenemos, aquello que si lo conseguimos, podremos hacer mejor nuestro trabajo. Esa necesidad es la que debe ser compartida con el equipo, para entre todos, buscar sus causas posibles de que no suceda.
    En un sistema complejo como un desarrollo de software (Management 3.0), la causa-efecto no es linear. Las cosas que suceden pueden tener más de una causa, y por tanto no siempre las mismas causas desencadenan los mismos efectos. Esta complejidad añade más valor a analizar los problemas por el equipo, con más visión que sólo la de una persona. Si planteas tu necesidad al equipo que no puedes conseguir, es más facil averiguar las causas de manera colaborativa.
    En resumen, podrías plantear situaciones ideales en vez de problemas. Y averiguar cómo llegar a esa situación, eliminando las causas que te lo impiden. ¿no favorecería esto el aprendizaje y la visión compartida, al establecer la meta antes que el camino?

    Me gustaría compartir además algunas ideas que he ido obteniendo a lo largo de unas cuantas retrospectivas (algo más de dos años, al menos una cada 15 días,...):
    • Piensa siempre lo primero que el problema es sistémico, no de las personas. Soluciona primero el sistema, generalmente éste limita a las personas.
    • No evites los conflictos, genera un ambiente donde sea sano que florezcan.
    • Plantea las necesidades a resolver, no lo que pensamos que son las causas. Esto también ayuda a la eliminación de la figura del "culpable"
    • Aprende técnicas de retrospectivas y conoce cuando se debe aplicar cada una. Ayudan, y mucho.
    • El brainstorming es la técnica más conocida y peor implementada. Pon reglas claras desde el principio para hacerlo bien: elimina las críticas que impiden una verdadera libertad de ideas.
    • Siempre obtén acciones de las retrospectivas, o no serán retrospectivas, solo "reunión de desahogo". Que no vienen mal de vez en cuando, pero esas, con una cerveza en la mano mucho mejor.

    abril 27, 2011

    ¿Es TDD la hermana pequeña de la validación formal?

    Hace un tiempo, al crear el grupo de TDD en castellano, hacía esta pregunta del título. ¿Es TDD la hermana pequeña de la validación formal? Hay un artículo del gran E. W. Dijkstra, "Sobre la crueldad de verdaderamente enseñar ciencias de la computación" que me parece muy revelador tal y como hoy entendemos la ingeniería del software, y cómo se veían las cosas hace tan solo poco más de 20 años.
    Básicamente Dijkstra proponía enseñar a los estudiantes de informática, como introducción en el primer curso, la validación formal de los programas sin siquiera tocar un ordenador para programar. Bastante sorprendente.
    ¿podremos un día verificar formalmente que un programa hace lo que esperamos que haga, y nada más? Lo que pasa, que el principal problema no es verificar, si no CONOCER, aprender, asimilar, conceptualizar lo que tiene que hacer.
    Os dejo con este video, del 2001, con una pequeña entrevista a tan interesante personalidad.



    Podeis encontrar todos sus manuscritos, algunos de ellos traducidos a castellano en la universidad de Texas.
    Computer science is no more about computers
    than astronomy is about telescopes
    E. W. Dijkstra
    Siempre me ha intrigado el verdadero sentido de esa frase...

    abril 15, 2011

    Presentación: "Agilismo como proceso de Innovación"

    Os comparto la presentación utilizada en la Feria #KreaBidasoa. Expresé las ideas de mi anterior post: Agilismo como proceso de Innovación, terminando con una pequeña introducción a Scrum.

    marzo 31, 2011

    Agilismo como proceso de innovación

    Siempre he tenido bastante claro que el desarrollo de software es un proceso de aprendizaje. Los desarrolladores no podemos plasmar en código aquello que no hemos aprendido de un sistema o del dominio del negocio. Ahora también lo veo como un proceso de innovación. Todo desarrollo de software es en sí mismo innovador, por que no existe antes aquello que quieres construir, teniendo cada desarrollo particularidades, que precisamente, llevan a tener que construir de nuevo por n-sima vez, un ERP.

    Ser ágiles nos proporcionará un marco para la innovación, y para el aumento de la productividad en pos de la misma.
    Para innovar, algunas recomendaciones pueden ser:
    1. Fomentar la creatividad. La creatividad no tengo muy claro cómo fomentarla, pero sí cómo liquidarla: con un poco de "command&control". Se debe permitir a la gente equivocarse, reforzar el poder de los equipos para que sean sitios seguros.
    2. Excelencia como hábito de trabajo. Debes cuidar cada detalle, huir de la mediocridad en cada cosa que haces. Si no, nunca inventarás el iOS.
    3. Orientarte a resultados: La innovación debe producir algo tangible, y en estos tiempos, cuanto más rápido mejor. Mejor producir valor poco a poco, que hacerlo tarde.
    4. El feedback hoy en día es fundamental. Para a analizar cómo lo estás haciendo, y reorientate de nuevo, hacia el buen camino.
    Si te encajan esas cuatro recomendaciones en busca de la innovación, también verás que están algo dirigidas hacia donde me interesa: los principios ágiles. Y es que refuerzan, o se apoyan, no sé en qué orden :), en los cuatro principios básicos de todo agilista.
    Hay muchos más consejos alrededor de la búsqueda de la innovación que encajan como un guante en los principios. O quizás, es que los principios son una base sólida para fomentar la innovación.

    marzo 25, 2011

    Equipos autogestionados y liderazgo... ¿oxímoron?

    En la búsqueda del equipo perfecto, me preguntaba si la autogestión en un equipo y el liderazgo son cuestiones contrapuestas. Jorge me decía que pueden parecer por falta de comprensión de la palabra liderazgo, y JMBeas le ha dedicado un post, hablando más del liderazgo individual.


    Mi pequeño tweet iba más bien por otro lado. A un equipo autogestionado le considero así, por que son capaces de organizarse cómo hacer su propio trabajo entre ellos. Pero cuando dentro de un equipo hay un líder, en cierta manera creo que se pierde la verdadera autoorganización. Se rompe un principio de igualdad que considero básico entre los miembros del equipo, para llegar a ser un equipo de alto rendimiento.

    Considero que si hay un líder claro en un equipo, este no es un equipo de alto rendimiento. Pero atención, creo que para llegar a ser un equipo de alto rendimiento autogestionado, es casi imprescidible pasar por la figura de un líder. Precisamente hoy A. Medinilla lo ha explicado genial en un hilo de agile-spain.
    La democracia está sobrevalorada, lo importante es la unanimidad.
    Esta frase, que creo haber leído a Jim McCarthy (pero que ahora no soy capaz de encontrar la referencia), me parece que da alguna clave importante a la hora de evaluar equipos. Si un equipo no es capaz de tomar decisiones por unanimidad prácticamente siempre, quedarán personas sin ver satisfechas sus expectativas. Aquel equipo que resuelve por unanimidad sus problemas, es un equipo unido, y alineado con una visión compartida.
    Cuando existe un líder dentro del equipo, apostaría que algunos miembros de los equipos siempre aceptan decisiones suyas, sin hacerlas propias. ¿es entonces un equipo autogestionado, o uno con "jefes", pero internos en el equipo?

    En una charla sobre liderazgo en equipos interfuncionales, pregunté al ponente si no podía existir equipos sin esa figura de líderes. Su respuesta es que sí, cuando se juntan un grupo de personas, por propia voluntad, y todos expertos y con mucha experiencia en su campo de actuación, con un objetivo claro. Estoy bastante de acuerdo. Si para ser experto se necesitan al menos 10 años, ¿cuantos equipos tienes preparados para una verdadera autogestión?

    Por último, dos notas rápidas. Un coach en un equipo, no es lo mismo que un líder, por que ayuda al equipo, pero nadie le sigue. Y ojo, que puede haber equipos sin líderes, pero que ni sepan autogestionarse ni mucho menos sean de alto rendimiento :)


    marzo 07, 2011

    Agilismo a nivel táctico

    Hace unos días discutíamos entre los "javeros" de Biko2 sobre las mejores prácticas, herramientas, librerías, automatizaciones que cada proyecto debería llevar en busca de la verdad, o sea, la calidad perfecta :)

    Se empezó a hablar mucho de cuestiones concretas, y divagamos un poco sobre algunas herramientas o prácticas a incorporar o reforzar, que para eso nos encanta discutir como al que más. Estas cuestiones las asocio al nivel táctico de aplicación del agilismo en una organización, maniobras en corto plazo que son directamente aplicables para conseguir un fin sobre el campo de batalla. Pero me dio la impresión de que nos perdimos en siglas y nombres, y desglośe un poco por niveles lo que hallaba importante. Os extraigo pues un pedacito del email que envie en ese momento a mis compañeros, sobre los niveles de actuación para la calidad, como desarrolladores en labores técnicas:

    • Programación: PMD o checkstyle (herramientas de análisis de código) nos ayudan a no cometer errores varios, aún teniendo que repasar las posibles reglas que pongamos. Pero cada linea que escribimos es una decisión que tomamos sobre la aplicación, y eso solo se resuelve con la inteligencia del desarrollador. Hay que saber cosas de SOLID, de gestión de excepciones, de gestión de logs,... etc. que NO SE PUEDEN AUTOMATIZAR.

    • Ecosistema: El ecosistema nos puede comprobar que no rompemos el build, que tenemos buena cobertura de tests, que tenemos infraestrucutra pra hacer TDD, buenas métricas del sonar, despliegues automáticos, la gestion de merges/branches.... pero todo esto,no hay manera que nos lo haga solo... solo depende de la inteligencia, y ahora, también, el trabajo duro del desarrollador. Hay que saber de integración continua, de gestión de ramas,...

    • Aplicación: A nivel aplicativo tenemos la definición de terminado-TER-MI-NA-DO, las pruebas de aceptación, o sea, la parte funcional. Aquí entra en juego lo anterior: la inteligencia y el trabajo duro, pero sobre todo, la responsabilidad y el compromiso del desarrollador, las ganas de hacer las cosas bien y emocionar al cliente.
    Un saludo a mis colegas de Biko, que sé que me leen ;)

    febrero 21, 2011

    Equipos, equipos, equipos,... y luego ágil

    El ideal de los equipos autoorganizados, es eso, casi siempre -me temo-, un ideal. En mi personal investigación sobre el tema de los equipos de alto rendimiento (¿alguna vez habeis participado en uno? - la sensación es "diferente"-) estoy trabajando en dos areas principalmente:


    1) La organización de las personas como equipo. Es decir, ¿qué diferencia un grupo de personas trabajando juntas, de un equipo? En esta linea, estoy otra vez releyendo el libro "Software for your Head". Libro difícil de leer donde los haya, pero que da la impresión de esconder un tesoro oculto entre sus páginas.
    Las mecánicas de un equipo de alto rendimiento ¿se pueden reproducir, inducir, insertar en cualquier grupo de personas con un objetivo común? La charla de Jim McCarthy en Agiles2008, me parece interesantísima.
    Por otro lado, me pregunto si el equipo autoorganizado no es una quimera. Por ejemplo, asistí a una charla sobre "Tácticas para liderar equipos interfuncionales", dónde el ponente dijo que no puede haber equipo autoorganizados sin lider, excepto en casos dónde todos los componentes del equipo son expertos en la materia en la que trabajan. Así que esta idea refuerza la labor del ScrumMaster como lider-y coach- dentro de un equipo que utilice Scrum.

    2) Elevar el nivel de las personas de cada equipo. A mayor nivel personal y técnico de cada individuo, el equipo ganará exponencialmente comunicación, colaboración, y por tanto, velocidad de desarrollo.
    "Oh, you want to be an artist? A great artist?" "Yes" "That's easy! Become a great human being and then paint."
    Supongo que aplica lo mismo a un gran desarrollador.

    No se puede ser un gran equipo de desarrollo ágil, sin ser antes un gran equipo.

    enero 26, 2011

    Testeo defensivo, o que disparen a ese API

    A raíz de una entrada de @sergioazo y su correspondiente conversación, he recordado una técnica que leí en algún sitio para minimizar los problemas en el trabajo con librerías externas de terceros en tu proyecto.
    Se puede usar para varias cuestiones:
    • Comprender el funcionamiento real de una librería (no el esperado)
    • Defenderte frente a cambios en el comportamiento futuro de la librería
    • Documentar el uso de una librería, su API.
    Se puede decir que vamos a generar test unitarios, en los que no podemos escribir el nombre del método de test hasta el final. Si hacemos TDD, el nombre del test deberá indicar que comportamiento queremos asegurar, y después programamos ese test. En este caso, podremos poner un nombre al método realmente coherente al test, cuando ya tenemos los assert ejecutando y comprobados en verde. Quizás coincida con lo esperado, o quizás no. Sugiero que se guarden los dos nombres, para comprender las diferencias encontradas, que probablemente también desconcierten al próximo programador que coja tu código que usa esa librería.

    Si tenemos tests de los usos que hace nuestra aplicación de una librería, el cambio de versiones de la misma, puede ser testeado. Basta con ejecutar nuestra suite de integración, para que nos corrobore si la librería sigue funcionando tal y como esperamos.

    Veamos un ejemplo. Imaginemos que tenemos un API tal que así:

    public String guardaDocumento(String docType, byte[] data);
    public byte[] obtenerDocumento(String docCode);

    Y no tenemos más información, parece bastante obvio lo que hace, pero queremos asegurarnos, y sobre todo tener cuidados con los cambios con esa librería que se está desarrollando. Podemos hacer un test de la siguiente manera:

    public void deberiaDevolverElMismoDocumentoPorCodigo(){
    Repositorio repositorio = new Repositorio();
    String docCode = repositorio.guardaDocumento("tipo1", "Hola Mundo".getBytes());
    assertArrayEquals("Hola Mundo".getBytes(),
    repositorio.obtenerDocumento(docCode));

    }
    Pero, este test, tan simple como almacenar un documento y obtenerlo de nuevo, se queda en rojo. ¿por qué? Por que resulta que el código necesita después, no es el mismo código que devuelve
    Por lo que finalmente tras unas pruebas (o un telefonazo a alguien harto de tus preguntas) llegamos a la conclusión, que el código que necesita el "obtenerDocumento" es la concatenación del tipo de documento y el código devuelto al guardarlo.
    Por tanto, modificamos el test, y después modificamos el nombre del test.

    /**
    * was:deberiaDevolverElMismoDocumentoPorCodigo
    */
    @Test
    public void deberiaDevolverElMismoDocumentoPorTipoDocumentalYCodigo(){
    Repositorio repositorio = new Repositorio();
    String docCode = repositorio.guardaDocumento("tipo1", "Hola Mundo".getBytes());
    assertArrayEquals("Hola Mundo".getBytes(),
    repositorio.obtenerDocumento("tipo1" + docCode));
    }
    ¿conseguimos con esto los objetivos inicialmente planteados?

    (nota:basado en hechos reales)