Najaraba.com: Software libre, metodologías ágiles y más.

Nueva etapa profesional: la inspiración

2012-01-23T09:25:00.000+01:00

No sería capaz de reflejar mejor estos últimos cinco años trabajando en Biko de cómo ya los ha reflejado Jessi en su blog.

Va de personas que son felices en su trabajo. Porque el desarrollo de software no es trabajar con ordenadores y picar código. El desarrollo de software es mucho más: son personas haciendo cosas grandes que disfrutan con lo que hacen, y sobre todo, con quien lo hacen.

Este análisis agradece, mejor de lo que yo lo puedo hacer, a la gente maravillosa con la que he compartido tantos momentos. Gracias.

Naturalmente, yo tendería a realizar un análisis más frío, centrándome en los fallos para analizarlos y no volverlos a repetir. Contaría un poco lo que creo que han sido los éxitos y los fracasos de estos años. Pero lo que me ha cambiado últimamente es la percepción del éxito. Y no puedo sino pensar que estos últimos años lo han sido, aunque quizás desde cierta perspectiva no lo parezca.
Así que esta vez no haré un examen de conciencia público, básicamente por que creo que no sabría reflejarlo bien. No analizaría datos ni cifras, proyectos de éxito ni de fracaso. De todo hemos tenido, obviamente: unos proyectos bonitos, otros muy duros; proyectos que han salido genial, y proyectos, que casi morimos en el intento... Resulta que en esta ocasión el análisis que me sale de las tripas serían relaciones personales, sentimientos, intuiciones e inspiraciones. Y no acabaría nunca :) Esta vez he dicho lo que tenía que decir a las personas que se lo tenía que decir ;)

La cuestión es que me lanzo a una nueva etapa: dejo de ser empleado de Biko, aunque no abandono esta empresa. Ahora voy a colaborar con Biko. Cambio sutil en este caso, pero importante. Voy a ampliar horizontes. Me hago autónomo. Voy a empezar a trabajar en ideas nuevas. En estos momentos tengo planes muy concretos a corto y medio plazo, de los que os iré informando puntualmente. Busco la inspiración un poco más allá de mi zona de confort,... de hecho, mucho más allá :) Biko es una de las mejores empresas por la que podéis pasar, y seguiré unido a ella mientras me dejen ;) pero ha llegado el momento.
Seguro que podéis imaginar muchos de vosotros en qué área voy a trabajar ;) ¡metodologías ágiles! Pero si espero a tener preparada la web, mi portfolio de servicios de consultoría/coaching en metodologías ágiles, mi plan de marketing, etc. no lo anuncio nunca. Pero aunque no tenga todo eso, podéis ir preguntándome para contratarme desde YA ;D

De lo racional a la inspiración. He ahí mi nuevo lema.
Necesitamos más inspiración en este mundillo. Y menos control. Los "trabajadores del conocimiento" respondemos a la inspiración mucho mejor que a la supervisión. Vamos a demostrarlo.

Organización ágil

2012-01-11T22:20:00.000+01:00

¿De qué hablamos cuando nos referimos a una organización ágil? ¿existe eso?
En general oigo que es la organización que se adapta a los procesos de creación de producto basados en equipos multidisciplinares que trabajan de manera ágil. Es decir, que con un enfoque bottom-up, creamos la organización ágil. Los equipos con la nueva manera de trabajar son "raros" y acaban demandando a su propia organización que se adapte para el mejor funcionamiento de todos.
Me suena un poco extraño. Generalmente la organización funciona como alguien ha impuesto, o ha establecido. Además, el cambio bottom-up lo veo limitado hasta que encuentras un escalón demasiado duro para seguir creciendo. Y la cultura se come la estrategia para merendar, que dicen.
La otra cuestión sería realizar el cambio desde arriba, pero entonces perdemos la perspectiva de lo que es el agilismo, pues lo ágil, estrictamente hablando viene de su manifiesto, escrito para el desarrollo de software, NO para la gestión de empresas. Y debemos basarnos en otras fuentes (Lean o las nuevas corrientes de gestión organizativa). Lo denominado ágil, se "inventó" en un manifiesto que trata del desarrollo de software. Es tan bonito y tan perfecto ;) que extraemos conclusiones que afectan a organizaciones enteras, pero ¿deberíamos hacerlo realmente?
¿qué claves nos da el manifiesto ágil para poder extenderse a toda una organización? Veamos los primeros puntos:
Valoramos

A los individuos y sus interacciones por encima de los procesos y las herramientas.

Trasladado al mundo organizativo: Confianza, coordinación, respeto.

El software que funciona por encima de la documentación exhaustiva

Trasladado al mundo organizativo: Orientación a resultados

La colaboración con el lcliente por encima de la negociación de contratos

Trasladado al mundo organizativo: Colaboración, compromiso

La respuesta al cambio, por encima del seguimiento de un plan

Trasladado al mundo organizativo: Aprendizaje, adaptación

Es decir, tenemos que basar una organización en la confianza, la coordinación y colaboración entre personas que se respetan, orientadas a resultados y comprometidas con los mismos, que aprende y se adapta al medio. Sin duda son un montón de cosas molonas y de buen rollo, pero, ¿cómo se trasladan a una organización? Sin duda también, se puede realizar.
Más en próximos capítulos. Stay Tuned.

Pequeña recopilación por el 7º

2011-12-29T14:01:00.000+01:00

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).

Creo que estos fueron los primeros en los que hable de metodologías ágiles: Ser programador y Centrarse en la metodología o en las personas allá por el 2004 o 2005.
Aunque todavía estaba mi blog centrado en el software libre, por aquel entonces anuncie mi tesina sobre el tema: Nuevos modelos de negocio basados en software libre. Tengo la impresión que ha envejecido muy mal :)
Me empezaron a preocupar cada vez más las ágiles: Diseño y XP.
Y las organizaciones: Organización empresarial en empresas basadas en software libre.
Aunque luego llego mi (nuestro ;) ) proyecto vital más importante.
Intentaba aprender de los que sabían: Metodologías ágiles, malas buenas,... y las de Google
Empezaba a verse claro por donde iba a girar mi vida profesional: La confianza y las metodologías ágiles. (2006) Aunque en el 2007 no sabía si se vendía bien: ¿Vende lo "ágil"?
Una de mis revelaciones personales, en el 2008: ¡El producto es el equipo! que me ha dirigido desde entonces, cuando ya empezaba a tener responsabilidades de gestión importantes.
Otra pequeña criatura salio en 2009: !Agile-Spain! De aquí han salido amigos, eventos,... y una pequeña revolución en muchoas ámbitos.
Y ultimamente, con el blog algo abandonado, iba a refugiarme a mis equipos: Equipos, equipos, equipos, y luego ágil. o sobre liderazgo.

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!

Las sesiones de CAS201: personas y retrospectivas

2011-11-01T22:16:00.000+01:00

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 :)

Equipos autoorganizados cas2011

View more documents from Jose Ramón Díaz

Taller retrospectivas CAS2011

View more presentations from Jose Ramón Díaz

CAS2011. Ya ha pasado

2011-10-23T17:04:00.000+02:00

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.

Personas y retrospectivas en la CAS2011

2011-10-07T17:15:00.000+02:00

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! :)

Visual Management Open Space 2011, mi resumen

2011-09-06T23:17:00.002+02:00

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 :)

Libros en castello (original) sobre agilismo

2011-08-24T20:52:00.001+02:00

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

2011-08-24T00:21:00.000+02:00

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 :)

Mi "elevator pitch" del agilismo

2011-06-28T22:36:00.000+02:00

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).

Resumen AOS2011

2011-06-21T23:27:00.000+02:00

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.

Visión del desarrollo ágil de software

2011-06-12T23:31:00.000+02:00

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:

El axioma Equipo = Producto
El software es un juego coaborativo, de comunicación y finito
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.

Desarrollo ágil de software

View more documents from Jose Ramón Díaz

Eventos en zona norte:

2011-05-25T23:45:00.007+02:00

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.

Peligro, las herramientas te cambian de objetivo

2011-05-12T10:05:00.001+02:00

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?

Retrospectivas: Busca necesidades y no problemas

2011-05-09T22:51:00.004+02:00

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.

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

2011-04-27T23:27:00.008+02:00

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...

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

2011-04-15T14:29:00.004+02:00

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.

Agiles como proceso de Innovación

View more presentations from Jose Ramón Díaz

Agilismo como proceso de innovación

2011-03-31T22:42:00.003+02:00

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:

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.
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.
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.
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.

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

2011-03-25T22:35:00.004+01:00

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 :)

Agilismo a nivel táctico

2011-03-07T08:00:00.003+01:00

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 ;)

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

2011-02-21T08:00:00.001+01:00

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.

Testeo defensivo, o que disparen a ese API

2011-01-26T23:29:00.007+01:00

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)

Otro cumpleaños, y van seis

2010-12-30T10:48:00.004+01:00

Este es el sexto año de este blog. Creo que ha sido uno de mis años más duros profesionalmente, y se ha notado en la frecuencia de los posts. Tan solo 6. Una miseria :) Además, el año empezó fuerte con la CAS2010, la organización del evento consumía mucho tiempo libre.
Lo cierto es que no sé por qué me da tanta pereza últimamente escribir en el blog, pero me la tengo que sacudir de encima. Este año que tendré una labor más de coaching con los equipos, y abandono definitivamente las labores de Product Owner, así que debería ser muy propicio a contar más historias ágiles sobre las experiencias que vayamos teniendo. Así que espero animarme más, y en Febrero nos vemos en el Coaching Gathering de Madrid.

Os dejo con lo mejor del 2010 para mi: mi segundo hijo. Al primero le dedique un post completo, así que este no puede ser menos :)

¡¡¡ FELIZ AÑO 2011 !!!

Coderetreat y TDD, en Donosti

2010-11-26T17:45:00.001+01:00

El sabado estuve en el #coderetreat de Donosti. Contamos con la presencia de Enrique Comba, que hizo de maestro de ceremonias, planteando el problema y dándonos los pasos a seguir para las prácticas en cada iteración.

Os animo desde aquí a que os organiceis un evento de estos dónde podais, en realidad no hace falta traer a ninguna estrella, solo tener ganas de aprender un día, y de pasarlo bien.

Ha sido un día muy interesante, practicando un poco de programación, con TDD. Me he dado cuenta, primero, de que estaba muy oxidado, y segundo, de que tengo mucho que practicar para comprender en profundidad las implicaciones de TDD. Por que hacer bien TDD implica programar bien, preguntándote en cada momento por qué estás poniendo el código que estás escribiendo, y entendiendo las razones del diseño.

Lo que hicimos este día fue intentar resolver el juego de Conway. Es un problema sencillo de entender, pero con suficiente complejidad para que pueda salir un bonito diseño orientado a objetos, merezca más de una discusión trabajando el diseño desde TDD.

Las dos primeras itearaciones, que eran libres, sin "putadillas" sugeridas por Enrique, creoq ue casi todos empezamos a diseñar o un Tablero, un universo, unas celdas, etc... hubo quien diseño a un dios contemplando el juego :)

Mi principial descubrimiento es que empezabamos a hacer TDD desde un punto del problema en el que para empezar los tests habíamos tomado decisiones de diseño de modelado del problema. Sí, antes de empezar siquiera con los tests.

Esto ya me puso nervioso y en la segunda iteración, con @sharpbites propuse empezar por lo que sería el inicio, una interfaz del juego, que resolviese el asunto. Un test de aceptación, vamos, más en la linea (creo) de un enfoque BDD. Y nos atascamos, vaya si nos atascamos. ¿por qué? Por que intentábamos llegar a la solución que teníamos en la cabeza. En general, a todos nos resultaba más facil empear desde niveles inferiores de la solución, con un enfoque bottom-up.

Enrique propuso una solución que me convenció, pero que tendré que poner en práctica unas cuantas veces. Se trata de partir del test de aceptación, de la definición del problema (top-bottom), y realizar un rápido desarrollo que nos lleve a una primera solución, aunque sea grosera. Después, hacer el bottom-up e ir completando los desarrollos que falten para tener la certeza de tener suficientes casos de prueba y un buen diseño generado.

Lo que conseguimos es tener enseguida una primera versión, y después fortalecer el diseño y desarrollo con el detalle.

Definitivamente, fue un día muy aprovechado, por compartir experiencias con otra gente, y por aprender algo de cada uno de ellos. Tendremos que hacer más de estas por la Zona Norte :), no os las perdais, seguid informados en Agile-Spain.

Gracias a todos los asistentes, y a Gailen por patrocinar el evento, que pudimos comer de gorra! ;)

Y pasó el tiempo...

2010-09-08T22:44:00.004+02:00

... y desde mayo que no he escrito en este blog! Unas cuantas cosas me han tenido ocupado desde que en el último post anunciaba que se habían abierto las inscripciones de la CAS2010 (ahora ya hasta podeis encontrar las presentacione realizadas, pero a estas alturas, ¿quién no lo sabía?).

La organización de la conferencia nos dejó exhaustos a unos cuantos, no voy a hacer un resumen a estas alturas, ya no tiene mucho sentido, pero fue un éxito más que razonable, por lo que estoy personalmente muy satisfecho.

En realidad se puede decir que no he escrito nada serio en el blog desde el año pasado, y la verdad que me estoy planteando abandonarlo definitivamente. Sin embargo, es algo que me ha dado muchas satisfacciones, y he conocido a mucha gente a través de él. Para mi marca personal ha sido un hito importante, y que creo que debería explotar más, y mejor.

No será por falta de temas y experiencias que ahora podría comentar. En Biko, en momentos difíciles, nos embarcamos en un gran cambio hacia una organización ágil, y da para aprender y comentar muchos temas. Yo hice saltar la chispa, A. Medinilla fue la palanca de cambio, y decenas de profesionales han sido eso: verdaderos profesionales (Sé que me preguntareis por los clientes,... pero eso lo dejo para otra vida :P).

Ahora el reto es no caer en las retros "aburridas", conseguir una organización que aprenda de cada equipo, e implantar una verdadera mejora continua. No caer en el tedio. No me parece nada fácil :) Todavía tenemos mucho trabajo por delante.

Por otro lado, hay también temas técnicos en los que nos hemos embarcado este año en el equipo, especialmente TDD e integración continua. Elevar el nivel técnico siempre ha sido una de mis obsesiones, y sin embargo, siempre veo que el camino por delante es infinito.

El camino de la agilidad es insondable, y no sé hacia dónde me va a llevar :) . Allá se quedó mi interés por el sotware libre por el que inicie este blog. En realidad, busco aprender a desarrollar software de la mejor manera posible, lo que me creo absolutamente es el juramento de no lealtad, así que ahora es el agilismo, mañana ya veremos, quién sabe. Ahora que me animado, a ver si abandono un poco twitter, y vuelvo al blog :) Siempre que me deje mi segundo hijo,... que está a punto de nacer! (¿me dejarán twittear desde el paritorio? :P)

Y pasó el tiempo... ¡hasta pronto!

Apúntate a la CAS2010. Inscripciones

2010-05-10T22:07:00.002+02:00

Resucito un rato este blog para anunciar que ya se ha abierto el plazo de inscripción de la conferencia Agile-Spain.

Se ha configurado un panel de sesiones y talleres que va a ser muy interesante. Se recibieron muchas sesiones que lamentablemente han tenido que quedar fuera, y han generado un nivel muy alto. Henrik Kniberg también ofrece un taller, pero rápido, que solo para 15 personas.

Podeis apuntaros desde aquí.

Conferencia Agile-Spain 2010 (CAS2010)

2010-02-25T22:13:00.000+01:00

Hoy tengo una gran noticia. Ya se ha dado el pistoletazo de salida para la primera conferencia sobre Ágiles en España. En Agile-Spain la estamos organizando: CAS2010.
En la web podeis encontrar toda la información necesaria. En estos momentos están abiertos los procesos para la selección de sesiones, contribuiciones y talleres. Cualquier planteamiento relacionado con las prácticas y metodologías ágiles es bien recibido para poder plantear una charla, donde podamos compartir experiencias.

Conferencia Agile-Spain 2010

Contaremos además con la más que interesante visita de Henrik Kniberg.

Henrik Kniberg será el orador principal de la conferencia. Henrik es autor de “Scrum y XP desde las trincheras” y de “Kanban vs. Scrum – Obteniendo lo mejor de ambos”, además de ser Certified Scrum Trainer, miembro de la junta directiva de la Agile Alliance, y uno de los máximos divulgadores de la aplicación práctica de las metodologías ágiles internacionalmente.

No te lo pierdas, las inscripciones se abrirán próximamente. Y si te seleccionan como ponente para una sesión, podrás asistir gratuitamente a la conferencia ;)

Scrum vs. Kanban: Más libros en castellano

2010-01-28T22:19:00.004+01:00

Vuelvo a hablar de libros, esta vez para presentar la traducción de un libro Henrik Kniberg y Mattias Skarin al castellano. Se trata del libro Kanban vs. Scrum publicado inicialmente a través de InfoQ. Ahora, gracias a Agile-Spain podemos disponer de este pequeño gran libro en castellano.

Ha sido un trabajo colaborativo, coordinado por Ángel Medinilla, donde han participado personas del grupo de Agile-Spain, que con ganas de contribuir a la comunidad hispano-parlante han realizado un gran trabajo. Desde aquí gracias a Angel, Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano
Ángel os dará más detalles del libro en su blog, y podeis descargarlo desde este enlace.

Libro de TDD en castellano

2010-01-11T23:15:00.004+01:00

El primer libro sobre Desarrollo Guiado por las Pruebas (TDD) en castellano acaba de ver la luz. Carlos Ble junto a algunos colaboradores ha editado un libro más que recomendable para cualquiera que esté interesado en esta metodología de desarrollo, o en las metodologías ágiles en general.
Es un libro que además aporta conocimientos generales de diseño basado en objetos, o metodologías ágiles. Hace un repaso con ejemplos de cómo desarrollar con TDD, e introduce el desarrollo guiado por las pruebas de aceptación (ATDD).
Sin duda un libro que debes descargar, es de libre distribución, y estudiar con profundidad. Seguro que aún mejor si se lo compras o le haces una pequeña donación :), que merece la pena. Yo he tenido el placer de poder seguir el proceso de creación del libro como pequeño revisor, y el material creado por Carlos es muy bueno, espero impaciente su próximo libro ;)

Diseño Ágil con TDD

Aprovecho para recordaros la existencia del grupo de TDD en castellano!

Quinto cumpleaños

2009-12-29T16:33:00.003+01:00

Hoy hace cinco añitos este blog. Casi abandonado y en la pobreza de posts sobrevive a mi poca dedicación al mismo. Pensaba que este año había sido el más triste en el mundo Najaraba, pero ahora he visto que el 2007 fue incluso más parco en la publicación de posts.
Así que solo saludo al personal que siga leyendo este blog, y que informo que sigo vivo :)
Aunque este año ha ido bastante activo en otras areas de "lo ágil", publiqué un par de artículos, en REICIS y en CES Navarra. Di una charla en la Navarparty, y sobre todo, he colaborado en la fundación de agile-spain y su primer evento. Así que aunque no me leais mucho por este blog, podeis verme por otros lados.
Por otra parte, me da rabia no haber terminado mi serie sobre Lean, y no poder dedicar más tiempo a leer y comentar mis experiencias en el desarrollo de software.
Este año incluso me abrí una cuenta de twitter :) , y sobre todo, intento dedicarle mucho más tiempo a mi hijo!!
¡Os deseo un feliz 2010!

Primer Agile Open Spain: Fabuloso #agileopenspain2009!

2009-10-25T15:51:00.016+01:00

Pues finalmente llegó el Agile Open Space, y pasó rapidisimo de lo interesante que resultó.
Después de unas semanas de ajetreo con la organización, finalmente validamos nuestras expectativas. Afluencia masiva de los inscritos, y muchísimo nivel en las charlas organizadas el sábado.
El viernes, tras los últimos detalles de preparación del evento, empezó a llegar la gente hacia las 18:00, y a las 18:30 empezó la presentación del evento. Agustín Yagüe hizo de maestro de ceremonias, ya que se celebraba en "su casa", y Jose Manuel Beas y Xabi Albaladejo dieron unos pequeños discursos de presentación de Agile-Spain y la agilidad. Creo que Jose Manuel Beas estaba realmente emocionado de ver tanta gente congregada en este evento, y no era para menos.

Así que tras las presentaciones y un pequeño piscolabis -- gracias a los patrocinadores, de los cuales Biko era uno de ellos-- , se procedio a presentar los spaces que cada uno quería hacer. Aquí fue cuando realmente respiré tranquilo, y se vio que el evento iba a funcionar: una cola de gente para presentar y finalmente más de 50 sesiones ("únicamente" había 30 slots de tiempo disponibles). Tras preparar las sesiones para el sábado en el panel, se cerró el día.
La gente de la organización nos fuimos a cenar el viernes, me encantó volver a charlar con los que un día nos juntamos hace 7 meses para mover el tema de Agile-Spain, conocer a Carlos Ble y disfrutar de una cena muy agradable, aunque fuese de trabajo! :)

El sábado empezó con el desayuno en la UPM, para tomar fuerzas mientras podías repensar las sesiones a las que asistir mirando el panel. Se habían distribuido 6 sesiones simultaneas, durante 5 franjas temporales, 3 por la mañana y 2 más retrospectiva después de comer.
Las sesiones a las que asistí fueron muy interesantes y participativas. Además se respiraba camaradería y ganas de aprender. Nos movíamos rápidamente entre el panel para tomar las últimas decisiones de asistencia y las salas de los spaces. Se compartieron muchas experiencias, conocimientos y también muchas preguntas interesantes.
Las sesiones a las que asistí fueron:

Lean: Era una sesión propuesta por Robyn Dymond, que lamentablemente no llegó a tiempo. Pero X. Quesada condujo la sesión a buen puerto. Hablamos de los principios de Lean, y nos preguntamos cómo aplicarlos a la empresa.
El factor humano: Daniel Lopez (creo que era su nombre) nos habló de las personas, que son las que soportan las cabezas pensantes de los desarrolladores, y hay que tenerlas en cuenta. Hizo una dinámica muy divertida, como ejemplo del castigo contra el premio como forma de motivar a las personas.
Telefónica: Mónica Izquierdo y Carmen Lasa nos hicieron una presentación sobre la implantación de Scrum en Telefónica I+D. Muy interesante por que ciertamente va muy en paralelo con la implantación que estamos haciendo también en Biko, y charlamos un rato después durante la comida, y los problemas y retos son muy parecidos.
Agile Coaching: Se trataba de debatir sobre las funciones de un Agile Coach, y ciertamente lo que más claro quedó, es que no estaba claro. Había varias versiones sobre lo que se suponemos que hace un coach Agile, yo creo que se perdio un poco el rumbo de la sesión por que se mezcló con la idea de un coach personal o de marca propia.
Externalización y outsourcing: Angel Medinilla condujo una sesión para contar experiencias sobre proyectos de este tipo, sacando unas conclusiones finales.

En definitiva, una experiencia como conferencia. Podeis buscar más comentarios, fotos, etc. en la web de agile-spain. Pronto tomará forma la asociación, y ya estamos preparando nuevos eventos, así que no descansamos ;). Súbete al carro del agilismo, y únete a Agile-Spain!

Artículo en REICIS

2009-10-15T19:42:00.002+02:00

Han publicado la revista REICIS --"Revista Española de Innovación, Calidad e Ingeniería del Software"--, y en este número me han incluido un artículo, titulado "Las metodologías ágiles como garantía de calidad del software". Espero que os guste!
Lo podeis encontrar en: http://www.ati.es/spip.php?article1328
Muchas gracias a Jose Manuel y Carlos, que me ayudaron a darle el toque final de calidad ;)

Charla sobre desarrollo de software ágil (2)

2009-10-06T21:57:00.000+02:00

Aquí os dejo la charla que di el otro día en la Navarparty, junto con una breve descripción de lo que conté, sin entrar en detalles. Teneis el video disponible en la web de la Navarparty.

Desarrollo Agil

View more presentations from jrramon.

[2] Generalmente se presentan los típicos problemas en el desarrollo de software, en los que caemos una y otra vez, como razones para cambiar a lo ágil: clientes insatisfechos, equipos quemados, calidad insuficiente, fechas nunca alcanzadas,...
[3] pero aquí prefiero dar dos razones por las que creo que las metodologías ágiles se adaptan mejor.
[4] Por que creo que primero, el producto es equivalente al equipo que lo ha creado, y que el producto de un gestor de proyectos es crear un equipo, y que
[5] el software es un juego colaborativo. [6] Estos dos libros inciden en estas ideas.
[7] Así que ahora debemos elegir el nuevo camino, tomar la pastilla azul que ofrecieron a Neo (jope, ¿o era la roja?).
[8] Las metodologías ágiles más comunes fueron creadas en los 90,
[9] pero el manifiesto ágil les dio el espaldarazo definitivo.
[10-15] El manifiesto ágil condensan en cuatro frases los conocimientos y experiencias en gestión de proyectos de software de algunos de los mayores expertos en este mundo.
[16-22] Y los principios que se desprenden de ellos son las bases de estas metodologías.
[23] ¿cómo podemos llevar al terreno práctico estas ideas?
[24] Aplicando por ejemplo este esquema metodológico (como ejemplo, no olvidemos que hay muchas metodologías ágiles), que actua a nivel técnico, sobre el ecosistema software (prácticas de XP) , a nivel de gestión de proyecto (Scrum), y a nivel organizativo (aplicando los principios de Lean).
[25-35] XP nos da herramientas para garantizar una buena calidad e integridad de los desarrollos (TDD, Integración continua, Pair programming) , pero no debemos olvidar que puede ser tomada como una metodología de gestión completa. Lean nos da unos principios que buscan mejorar la organización en todos sus niveles. Y Scrum, la metodología "de moda", nos da el framework para gestionar los proyectos centrándonos en la entrega de valor al cliente y la mejora continua.
[37] Dos palabras básicas para ser ágiles: confianza y colaboración.
[38] ¡No olvides visitar agile-spain!

http://najaraba.blogspot.com/2008/02/el-producto-es-el-equipo.html
http://www.amazon.com/Software-Your-Head-Protocols-Maintaining/dp/0201604566
http://alistair.cockburn.us/Software+development+as+a+cooperative+game
http://agilemanifesto.org/
http://www.extremeprogramming.org/
http://www.proyectosagiles.org/que-es-scrum
http://poppendieck.com/
http://www.agile-spain.com

El arte de la guerra

2009-09-23T23:29:00.003+02:00

Tenía curiosidad hace tiempo por leer "El arte de la guerra", de Sun Tzu, un libro muy conocido que es un tratado sobre la estrategia de la guerra. No soy muy belicista, pero es sin duda un libro que merece la pena leer, curioso.
El caso es que he leido un par de versos que me han resultado similares a situaciones que se viven muchas veces en los proyectos:

Capitulo III: Estrategia Ofensiva
19
Existen tres caminos con lo que un soberano puede
llevar a su ejercito al desastre
20
Cuando ordena al ejército que avance o retroceda,
ignorando que es estratégicamente inadecuado. Esto se
describe como "maniatar al ejercito".
21
Cuando se inmiscuye en los asuntos militares sin el
conocimiento necesario. Esto confunde a los oficiales.

Sustituye soberano por político|director general|CEO, ejército por equipo, y oficial por jefe de proyecto... :D

Charla sobre ágiles en la Navarparty

2009-09-20T19:42:00.005+02:00

Este viernes, 25 de Septiembre de 2009, 17:30, estaré en la Navarparty, en Pamplona, dando una charla introductoria a las metodologías ágiles.

Las conferencias son de libre acceso para todo el público y se realizarán como el año pasado en la sala 04 (Fernando Remacha) del Edificio del Sario, anexo al Pabellon deportivo de la UPNA donde se celebra la Navarparty 7 (ver mapa )
Programa de charlas

La charla va a ser de introducción, contaré los principios ágiles, un poco de historia y algo de Scrum, lo típico para explicar en qué consisten, y por qué creo en estas metodologías. :)
Agradezco a la organización su confianza con su invitación, y espero veros por allí!

Buscamos desarrolladores JAVA para Biko

2009-09-10T14:08:00.002+02:00

En Biko estamos ampliando el equipo JAVA en San Sebastian (Guipuzcoa). Si quieres trabajar con nosotro, escríbemos a unete[at]biko2.com, referencia "desarrollo JAVA".

¿Qué hacemos? Desarrollamos productos con metodologías ágiles, intentamos mejorar tras cada retrospectiva, estamos en implantación de TDD, utilizamos integración continua,... nuestro ecosistema software es: Maven2 + SVN + Hudson + JIRA (GreenHopper). Y las herramientas de desarrollos, las más típicas, Spring e Hibernate, y el viejo Struts que pronto debemos migrar. (¿te atreves a venir a decirnos a cual y enseñarnos?)

Bueno, meto esta cuña publicitaria para encontrar (Septiembre 2009) gente que se venga a trabajar con nosotros. Nunca había comentado cosas en el blog de la empresa, pero quizás os interese este tema.

Ven al Agile Open Spain: 23 y 24 Octubre

2009-08-11T19:54:00.003+02:00

Se va a organizar el primer evento a nivel nacional de Agile-Spain, os copio el texto que podeis encontrar en la propia web.

Con los objetivos de difundir las metodologías ágiles en España (Scrum, eXtreme Programming. Lean Software Development) y compartir experiencias, el viernes 23 de octubre por la tarde y el sábado completo tendrá lugar el primer Agile Open Spain en las instalaciones de la Escuela Universitaria de Informática en el Campus Sur de la Universidad Politécnica de Madrid. Ctra Valencia Km.7. 28031 Madrid (Localización Google Maps)

El Agile Open Spain es un evento sin ánimo de lucro organizado de manera muy participativa. Esta diseñado para compartir entre los asistentes sus experiencias, ideas, experimentos y retos sobre metodologías ágiles (despliegue, planificación ágil, retrospectivas, ingeniería, herramientas, gestión de producto, calidad, etc.), basándonos en el formato de Open Space, para promover la colaboración y que la conferencia se convierta en aquello que sus asistentes deseen. No existe una agenda fijada, sino que entre todos crearemos la conferencia, elegiendo temas y participando. Contaremos con algunas de las personas que más saben de metodologías ágiles en España, así que ten por seguro que la conversación será interesante.

Si quieres:

Compartir tus experiencias como experto o principiante en el uso de prácticas Ágiles.
Escuchar a algunas de las personas que más saben de metodologías ágiles en España.
Encontrar el futuro antes de que éste te encuentre a ti.

entonces, inscríbete aquí (notar que el evento es gratuito pero las plazas son limitadas).

¿somos ingenieros los del software?

2009-07-22T22:59:00.004+02:00

Seguro que ya te has enterado del revuelo que se ha armado con el artículo en IEEE de Tom diMarco, sobre su cambio de parecer con el control y métricas en los proyectos de software.

Las métricas que inicialmente expuse en mi libro Controlling Software Projects: Management, Measurement and Estimation, han definido la forma en la que muchos ingenieros construian el software y planificaban el trabajo. Con un ánimo de estado reflexivo, ahora me pregunto: ¿Fué correcto el asesoramiento en métricas? ¿Sigue siendo pertinente? y ¿creo todavía que las métricas son una necesidad para el éxito de cualquier desarrollo de software?. Mis respuestas son no, no y no. [*]

Yo no creo que sea un cambio en el parecer de Tom, no tienes más que leer PeopleWare escrito 20 años más tarde que el tema de control y métricas en los proyectos de software, para darte cuenta de su evolución.
El post que más me ha gustado sobre este tema ha sido el de Juan Palacios, y coincido en gran medida con lo que explica en él. El verdadero bombazo ha sido otro post de coding horror, preguntando si la ingeniería del software está muerta, y entronca con el nuevo movimiento que defiende al mundo del desarrollo de software como "artesanía". No sé, quizás debería ser una ciencia experimental -Conocimiento ordenado y, generalmente experimentado, de las cosas- de manera que vayamos aprendiendo posibilidades de hacer bien las cosas...
Cuando salía de la carrera, siempre recalcaba que no era informático, si no -ingeniero- informático. Ahora, aunque esté mal visto, siempre digo que me gusta programar, pero que hay que saber las bases matemáticas y conceptuales necesarias para hacerlo bien. La respuesta a esto muchas veces suele ser: "¿pero los ingenieros seguís programando tras 10 años de experiencia? (sic)

La ingeniería entendida como un conjunto de procesos plausibles y realizables para solventar un problema, no existe -todavía!- en la informática. Algunos pensaron que CMMI-5 lograba eso, pero se equivocaron.
La ingeniería civil trasladada al control de proyectos de software no es lo adecuado para todos los proyectos. El "rebote" de las metodologías ágiles así lo confirman.
Las métricas están sobrevaloradas en los proyectos de software, y sus equipos. Forman parte de una burocracia que genera poco valor cuando se abusa.
No se trata -o no debería tratarse- de una guerra entre bandos. Somos niños con un juguete nuevo, y cada uno cree que se usa de una manera diferente. Debemos aprender.
Hay una parte de "juego cooperativo", de "problemas sociológicos" que se ha olvidado en la gestión de proyectos tradicional.
Las metodologías ágiles resuelven algunos problemas, pero no tardarán en salirles puntos débiles, debemos auncar esfuerzos para seguir mejorando.

Finalmente, cada proyecto es diferente. No solo por que el resultado deba ser diferente, si no por que se va a realizar con equipos diferentes. Quizás todos los proyectos del mismo tipo podrías gestionarlos igual, pero nunca gestiones igual equipos diferentes. Debes estudiar personas, perfiles, intereses,... y eso es dificilmente medible. Ignoro si CMMi, por ejemplo, tiene un area de trabajo sobre este tema, la creación de verdaderos equipos de trabajo. Un libro sorprendente en este area, que me recomendó Mario, es Software for your head. Se supone que habla de desarrollo de software, y "solo" ¡de gestión de equipos!

PD: Seguiré con mis posts sobre Lean que prometí, pero ha sido una temporada dura!

Equipos vs. personas

2009-05-19T22:29:00.002+02:00

Si algo me gusta de Scrum como metodología ágil es que intenta sacar el máximo potencial a los equipos. Entendiendo equipo no como un grupo de personas que trabajan juntas, si no como un grupo de personas que comparten una visión y una motivación que les une con lazos especiales.
La medición de métricas en Scrum está muy orientada al equipo: La velocidad y el burn-down son elementos a nivel de esta agrupación. Las personas son controladas por el mismo equipo de manera secundaria. Si en cada daily-scrum, se ve una persona que no avanza, hay motivos y datos para que el resto de personas le ayuden o le den un toque, pero el foco está puesto en el equipo.
Ya decía Alistair Cockburn que construir software es un juego cooperativo, que sin equipo no hay juego, o al menos no hay juego satisfactorio. Lean nos habla de la calidad en integridad conceptual, que se note que la calidad del producto por que aflora la integridad del equipo que lo realiza.
Ahora me pregunto yo cómo realizar métricas para evaluar el desempeño de las personas... por qué, ¿es necesario en un ambiente ágil? Las personas que no "funcionen" serán rápidamente detectadas por los equipos y no las querrán con ellos. ¿hay mejor métrica que esa?
Si las métricas personales dependen de las estimaciones, ratios de cumplimiento de sus tareas,... ¿es posible formar así un equipo con una motivación común? ¿no lo estaremos tensando demasiado? Supongo que debe haber un equilibrio, pero yo desde luego pondría má peso en el equipo. Nadie construye software solo.
En fin, más preguntas para Agile-Spain ;)

Computación y Ajedrez

2009-04-26T22:27:00.004+02:00

Ciertamente tengo el ajedrez bastante olvidado, y hace años -demasiados- que no juego ni una partida. Un día volveré a recuperarlo de mis aficiones, al menos para enseñarle lo básico a mi hijo. Pero el ajedrez y sus conexiones con la informática son bastante interesantes. Ya hace unos meses escuché la historia de Deep Blue de mano de uno de sus "entrenadores", Miguel Illescas, y resultó muy entretenido.
Ahora el CEIN, en Pamplona, organiza el Campeonato del Mundo de Ajedrez con Ordenadores y una Conferencia Internacional sobre Juegos y Computación -¿los ordenadores hacen deporte? :P - y lo arropa con varios eventos dignos de asistencia, os copio un extracto del anuncio en CES.

Tanto desde el BSC [¿Qué es la supercomputación? Una explicación orientada al mundo empresarial.] como desde el CESGA [Necesidades de supercomputación en la empresas españolas.] sólo nos ofrecieron facilidades para venir a contarnos a qué se dedican. Y lo mismo podemos decir de las empresas que vendrán a explicarnos cómo la aplican en su día a día.
¿Pero tan importante es el ajedrez en el campo de la computación? ¿Y realmente sirve para algo más que calcular miles, millones de variantes de una posición? La respuesta nos la dará Leontxo, el jueves 14 de mayo.
Y ya que CEIN anima el espíritu emprendedor, uno de ellos (editor, gran maestro, entrenador de un antiguo campeón mundial) nos contará cómo hay mecanismos que se aplican en las partidas de ajedrez que pueden aplicarse en un tema clave en la gestión empresarial: la toma de decisiones.

Espero veros por ahí!

Scrum y TDD

2009-03-25T21:56:00.002+01:00

En realidad este post es solo dos anuncios ;)

Hemos abierto un grupo para hablar de TDD en castellano. ¡Apúntate!
Los afamados cursos de Scrum de Proyectalis vuelven.

Y os cuento, que nosotros estamos en fase de adopción de TDD, y ya trabajando con Scrum. La adopción de TDD no es sencilla, y actualmente estamos invirtiendo en mejorar nuestros desarrollos de testeo unitario, para después cambiar el chip-o más bien invertir- del orden de desarrollo. Pasito a paso, pero seguros.

No hablamos de programar, es del cliente!

2009-03-19T00:01:00.003+01:00

Estaba echando un vistazo a la metodología ágil EVO (Evolutionary Project Management), una metodología no muy conocida por estos lares, creada por Tom Gilb. Básicamente contiene todos los principios recogidos en el manifiesto, pero llama la atención que esta metodología data de 1980. Es curioso como nos olvidamos, o se sumergen en el olvido, cuestiones que en su momento habrían sido de los más innovador. Es curioso como Scrum se ha tragado el resto de metodologías.
Por lo que veo, esta metodología va algo más alla de Scrum y XP y trata el negocio como un sistema completo. Es más probable que se asemeje un enfoque Lean, tratando de dar valor desde la concepción de un proyecto, gestionando temas que se salen de la parte de desarrollo puro para entrar en la gestión del negocio.
EVO se basa en 10 principios, con la idea general de los principios de las metodologías ágiles. El que me ha llamado la atención, me ha gustado, es:

Evo is holistic systems engineering - all necessary aspects of the system must be complete and correct - and delivered to a real stakeholder environment - it is not only about programming - it is about customer satisfaction.

No se trata de programar! si no de proporcionar valor al cliente. Muchas veces este es un punto dificil de transmitir a los desarrolladores; cuando nos gusta programar generalmente perdemos el enfoque en el cliente, y hacemos cosas complejas cuando no son necesarias por que son bonitas, o cuestiones que dejamos "a medias" por que son aburridas.
Tener en mente siempre al cliente, siempre - en cada linea de código- es muy duro. Pero sería realmente provechoso, realmente reduciríamos los desperdicios de nuestro proyecto. Muchas veces los desarrolladores se limitan a hacer lo que dicen las especificaciones, o lo que les pasa el analista, y sin embargo deberían tener también la visión del cliente. Exactamente igual que todo el resto del equipo.

La web de Gilb, que no conocía, me parece que tiene documentos bastante dignos de investigar, por si os interesa... ;)

Lean: Construir con calidad

2009-03-16T23:00:00.001+01:00

Este principio -verdad subyacente que no cambia con el tiempo o el espacio-nos indica que debemos construir el código desde el principio con calidad suficiente, no testearla únicamente al final. Para asegurar la calidad puedes hacer dos tipos de inspección: después de que los errores ocurran, o para prevenirlos antes de crearlos.
La falta de calidad en la construcción genera deuda técnica -una deuda que se cobrará posteriormente sus intereses: falta de mantenibilidad, disminuirá la eficiencia, bugs insospechados-, que más tarde se convertirá en un problema. Además significará que tenemos trabajo a medias por hacer, así que hemos generado desperdicio en el proyecto.
No basta con estar preparado con buenas herramientas para llevar el control de defectos, listas de bugs. Todo eso es desperdicio, trabajo a medio hacer, por que significa que cada funcionalidad en la que has encontrado un error está a medio terminar realmente. La tarea de testeo debe prevenir los errores, no encontrarlos, participar en la mejora del proceso de creación de software. Las metodologías ágiles han desplazado muchas tareas tradicionalmente de equipos de testeo hacia los roles más de programación o desarrollo. Para ello algunas de las principales técnicas recomendadas en el desarrollo son:

TestDrivenDevelopment: Crea primero los tests, escribe código, comprueba más tests, refactoriza y vuelve a empezar. Por cierto, acabamos de crear un grupo en castellano para hablar de TDD.
Integración Continua: Complemento perfecto para las pruebas unitarias, ayuda a la integración entre código de distintos desarrolladores y versiones.
Refactorización: Básicamente es cambiar el código fuente sin modificar su comportamiento. Permite mejorar la estructura del código, por mantenibilidad, rendimiento,... para permitir un crecimiento adecuado y sostenible de las aplicaciones.

Pero los Poppendieck identifican un concepto más alla de lo que comunmente entendemos como calidad -en su versión más típica de comprobación de defectos-, y es la integridad del producto software:

Integridad percibida: Se refiere a que el producto logra un balance entre la funcionalidad entregada, usabilidad, estabilidad y economía que emociona al cliente.
Integridad conceptual: Indica que el los conceptos principales del sistema colaboran juntos como un todo cohesionado de manera fluida. La integridad conceptual es un prerrequisito de la percibida, puesto que si el sistema no dispone de una manera consistente de presentar los temas, el tratamiento de datos o las metáforas, la percepción del usuario no podrá ser completamente favorable.

La clave para mantener la integridad es una buena comunicación entre todas las personas implicadas. Es muy típico que en proyectos medianos o grandes, no se compartan la visión de la globalidad del producto, lo que conduce a problemas de integridad conceptual. A veces hasta es dificil conseguirlo con tres o cuatro desarrolladores! :\

El cambio mental es que la calidad no solo se debe controlar, sino que se debe construir. No basta con recolectar métricas, si no que hay retroalimentar el sistema para disminuirlas.

Agile-spain

2009-03-03T17:21:00.000+01:00

El sábado me fui a Madrid a la "refundación" del grupo agile-spain. Este grupo intenta promover las metodologías ágiles de desarrollo en España, un elemento de la ingeniería del software poco practicado por estos lares. La reunión fue realmente amena, y podeis vernos en acción en unas cuantas foticos que Xavier Quesada ha colgado.

De Reunión refundacional

Ciertamente compartíamos la idea de que estas metodologías son un paso adelante en la mejora del mundo del desarrollo de software, y estuvimos mirando pasos a dar para reforzar la comunidad y dar a conocer esta faceta en la que otros paises nos llevan un par de años de ventaja. Así que nos podeis ver en la fotos jugando con los post-it, sacando y priorizando ideas. Pronto contaremos con más detalle qué se nos ocurrio, así que no olvides suscribirte a agile-spain, y sobre todo ¡a la comunidad!
Para ponerte en contacto con la comunidad agile-spain lo mejor es que te des de alta en el grupo de Google en el que comentamos cualquier tema relacionado.

Actualizacion: Una verdadera exposición de los hechos, por Jose M. Beas

Lean: Crear Conocimiento

2009-02-26T21:42:00.000+01:00

Este principio -verdad subyacente que no cambia con el tiempo o el espacio- trata sobre la importancia del aprendizaje. El desarrollo de software es radicalmente distinto a los procesos de producción. La creación de software es un ejercicio de descubrimiento, mientras que la producción intenta limitar las variaciones entre elementos. Para mejorar este ejercicio debemos maximizar el aprendizaje en cada etapa.
Las herramientas propuestas para maximizar el aprendizaje son:

Feedback: Cualquier ciclo que termina con una evaluación de su desarrollo y resultado proporciona una oportunidad inmejorable para el aprendizaje. Las metodologías tradicionales plantean pocos puntos para el feedback, por que parece que cuestionan la planificación o el saber-hacer de la gestión de proyectos.
Iteraciones: Las iteraciones permiten aprender poco a poco sobre el proyecto, de manera incremental, probando y desarrollando sobre lo que se va aprendiendo.
Sincronización:Es imprescincible una buena sincronización entre las partes involucradas en desarrollos complejos. Se debe fomentar compartir el conocimiento entre las personas. Muchas metodologías ágiles comparten la idea de la propiedad del código compartida.
Desarrollo basado en conjuntos: Para aprender bien las cosas debes probarlas, hacerlas, ofrecer un rango de soluciones que podrían funcionar. Hay que ser capaz de desarrollar un conjunto de pruebas que muestren qué hipótesis eran las correctas sobre la solución de un problema.

El aprendizaje por tanto puede ser visto desde dos puntos de vista: el equipo que aprende a desarrollar software cada vez mejor, y el equipo que aprende cada vez más sobre el proyecto (funcionalidades, lógica) que está construyendo. Es importante que se crea en el concepto de mejora continua, de lo contrario, estas tareas de retrospectivas, feedback,... puede acabar quemando a gente que hubiese preferido un entorno más conocido (¿hay de esos por ahí?). Debe ser una situación gradual, de aprendizaje continuo, pero relajado.

Lean: Eliminar la basura

2009-02-16T22:00:00.001+01:00

Este principio -verdad subyacente que no cambia con el tiempo o el espacio- trata sobre la necesidad de eliminar los elementos que producimos y que no son realmente necesarios para crear el producto software que necesitamos hacer, que no le añaden valor.
El primer punto por tanto es averiguar qué es lo que da valor y lo que no. Identificar los procesos, artefactos o tiempos que no añaden nada a lo que el cliente necesita. Algunos ejemplos [1] de basura dentro de un proyecto pueden ser:

Requerimientos que no se van a utilizar. Recordemos siempre la regla de Pareto. El 20% de las funcionalidades proporcionarán el 80% del valor del producto.
Complicaciones de diseño/interfaz que no eran necesarias.
Esperas entre etapas:

Tiempo desde que se obtiene la información hasta que se usa.
Tiempo desde que alguien necesita información hasta que la obtiene
Tiempo desde que se crea un error hasta que se detecta/corrige.

Otro tipo de esperas muy peligrosas, las producidas por la multitarea (o la procrastinación)
Escribir demasiado código. Puede estar relacionado con el tema de la complejidad, o quizás simplemente es que no se supo hacer de una manera más sencilla. Pero si algo lo puedes hacer con la mitad de código, estás creando basura.
Trabajo a medio hacer, sin terminar. Equivalente al inventario en sistemas de producción.
Errores, cada bug creado en el desarrollo es un desperdicio. Suena obvio, pero a veces ponemos más enfasis en encontrar la basura que en no generarla.
Actividades de gestión. Estas actividades no aportan valor directo a los productos, y aunque obviamente son muy importantes para el correcto funcionamiento de organizaciones y equipos, hay que vigilarlas para que no se conviertan en focos de desperdicio. Lo más típico: la burocracia.

Uno de las dificultades de este principio es discernir qué factores se pueden reducir o aligerar para eliminar basura. Identificar qué pasos en los procesos no producen valor para el cliente. No siempre valen las mismas conclusiones para todos los entornos. En algunos proyectos algunos tipos de documentación pueden ser un desperdicio, pero en otros, que por ejemplo ya sabes que después los vas a ceder a otro equipo o van a tener un mantenimiento muy prolongado, puede ser vital documentar exhaustivamente.
La herramienta propuesta por Lean[2] para la identificación de la "basura" es la creación de mapas de cadenas de valor, para analizar el flujo de aporte de valor de los procesos utilizados por el equipo para la creación del producto, desde su concepción hasta que llega al cliente. Los mapas ayudan a visualizar los tiempos que se pierden de manera gráfica.
Debes trabajar para poder ver las pérdidas de tiempo en un desarrollo de software. Determinadas veces serán obvias (burocracia, procesos de documentación que generan artefactos que nadie usa ni usará,...), pero otras no son tan claras, o lo que es peor, pueden no ser bien aceptados los cambios que necesitarías llevar a cabo para eliminarlos. La burocracia y las costumbres pueden ser dificiles de erradicar por que dan (falsa) seguridad y confianza[3].
Por lo tanto, ¿es este principio beneficioso para el desarrollo del software? Sin duda. Aporta mejoras en dos de las areas que comentamos en el primer post sobre Lean:

Mejora la productividad de la "tubería-desarrollo". Hacemos más eficaz los equipos y la organización por que dejamos de realizar tareas que no aportan valor al cliente, que al final, es quien determina nuestro éxito o fracaso.
Mejora las interacciones entre desarrollo y el resto de la organizacion. Recordemos que Lean se centra en la organización global. No debes dibujar un mapa de creación de valor para el departamento de desarrollo, si no para la organización completa! Seguro que salen muchas ineficiencias interdepartamentales.

Bibliografía:
[1] Implementing Lean Software Development
[2] Lean Software Development: An Agile Toolkit
[3] Eliminando obstáculos
[4] Gestionando la recesión con Lean, Agile y Scrum
[5] Los Poppendieck

Tres preguntas

2009-02-10T22:57:00.003+01:00

Acabo de leer un post sobre Agile: ¿la evolución de las metodologías tradicionales? En general hace una comparativa sobre los métodos tradicionales y los ágiles de desarrollo de software. Expone algunos problemas que tienen las metodologías ágiles desde su punto de vista, que me han resultado interesantes por la experiencia en testeo del autor.
Pero lo que me han interesado han sido las tres preguntas con las que acaba el post:

¿Existe la evolución de las metodologías Agiles?

la revolución

¿Surgieron por si solas o son adquiridas y formadas en reacción a la complejidad propuesta por las metodologías tradicionales?

¿Las metodologías Agiles de alguna nueva generación no serán en si mismas las adaptaciones y evoluciones de metodologías tradicionales?

Un saludo a Javo, me ha gustado mucho su blog. No todo va a ser leer bonanzas sobre "las ágiles" ;)

Desarrollo software Lean

2009-02-08T22:08:00.004+01:00

Uno de los temas en los que estoy más interesado ultimamente en este mundo del desarrollo de software es el "Lean Development". Es un conceto que surgio de la adaptación del modelo de Toyota de fabricación al software. Orginariamente parece que fueron "los Poppendieck" los inventores del término, en un par de libros que no te puedes perder:

Implementing Lean Software Development: From Concept to Cash.
Lean Software Development: An Agile Toolkit. Este lo tengo hace unos meses y me parece muy bueno. Enfoques diferentes para problemas tradicionales.

Lo importante de Lean, es que se basa en unos principios, adaptados del TPS. Y esto es una de las claves para su futuro éxito, que no son herramientas, no son pasos a dar o procesos a seguir. Son principios cuyo valor reside en su aplicabilidad independientemente del "estado del arte" en el que te encuentres. Las medidas las decides tú, los cambios guiados por principios son efectivos si los principios son adecuados. Así que llegamos a la cuestión, ¿son los principios Lean acertados para lograr un mejor desarrollo de software? (Ahí es nada, definimos mejor como de mejor calidad, mejor satisfacción del cliente, mejor ganancias para el proveedor,... mejor lo que quieras!)
¿Cuales son estos principios? (el orden no importa)

Eliminar la basura
Crear conocimiento
Construir calidad inherente en el producto
Retrasar el compromiso
Entregar rápidamente
Respetar a las personas
Mejorar el sistema global

Iremos viendo cada uno, intentando adivinar si son beneficiosos para el desarrollo de software. (!me acabo de obligar a escribir al menos 7 posts!).
Otra pregunta que te sueles hacer cuando empiezas a conocer Lean es su relación con las metodologías ágiles. Básicamente creo que hablan de lo mismo, pero Lean está un paso por encima a nivel organizativo. Las metodologías ágiles (XP y Scrum al menos, que son las que más conozco, no olvidemos que existen otras) se focalizan en el equipo que desarrolla un proyecto. Lean complemente esa visión con principios aplicables a la organización que soporta los equipos, y que debe gestionar un portfolio de proyectos y equipos. Hay cuatro cuestiones que se deben lograr:

Seleccionar las cosas adecuadas en las que currar (Lean Management). ¿te interesan todos los proyectos?
Ajustar la carga de trabajo a la capacidad. Muchas veces ni siquiera conoces tu capacidad.
Mejorar la productividad de la "tubería-desarrollo" (Lean-Scrum). Aumentar la capacidad del sistema.
Mejorar las interacciones entre desarrollo y el resto de la organizacion. Recordemos que Lean se centra en mejorar el sistema global.

Recapitularemos tras ver los principios, y volveremos sobre estas cuatro cuestiones. Si quieres ir adelantando las ideas, aquí tienes una pequeña recapitulación de los principios.

P.1 Eliminación de la basura.
P.2 Creando conocimiento
P.3 Construir con Calidad

Aprendizaje como mejora continua - Retrospectivas

2009-02-02T22:17:00.000+01:00

Las retrospectivas son una de cuestiones en las metodologías ágiles más útiles. Una pieza clave en la mejora continua que se espera de un equipo ágil (bueno, se esperará de cualquiera, ¿no?). Pero lo realmente fundamental es el aprendizaje continuo, que lleva a una evolución mucho más profunda que una simple mejora de los procesos.
La rotación de las personas que asimilan el aprendizaje continuo entre diferentes equipos, puede enriquecer cada uno de los diferentes proyectos en los que participen. Es dificil elevar los procesos entre diferentes equipos, cada uno puede mejorar a su ritmo, o ir en direcciones diferente. Pero el conocimiento se queda en cada una de las personas que participan. Esa es la mejor manera de que la organización adquiera el conocimiento en la creación de software. Puedes crear wikis, blogs y usar twitter para registrar toda la información, pero nunca podrás replicar la experiencia de haber participado en un proceso de mejora continua, de ver los porqués de los procesos, de los cambios, de las ideas.

Cuatro años y feliz año nuevo

2008-12-29T19:00:00.000+01:00

No todos estos últimos años he celebrado el cumple de este blog. Pero este año es (debe de ser) diferente.
Hace cuatro años ya que empecé a escribir: 200 posts, aunque no es mucho, este es un blog modesto :) . Empecé hablando de software libre, para dar a conocer mi tesina sobre ello. Después pasé a temas más de programación y que leía por otros blogs, pasando por temporadas de muy pocas publicaciones, y últimamente hablo especialmente de gestión de proyectos: me ha invadido el "gusanillo ágil". El año que viene espero seguir con un ritmo un poco constante de publicaciones, ahondando en este tema del desarrollo de software. Quizás entre todos podamos encontrar la nueva síntesis surgida de las metodologías ágiles y formales.
Así que aprovecho para felicitaros el nuevo año a todos, y desearos que descubrais el mejor camino a seguir!!

Retrospectiva anual

2008-12-15T22:22:00.002+01:00

Dos libros me tienen enganchado últimamente: "Software for your Head", y "Agile Retrospectives: Making good Teams Great". Y con estos, he preparado una retrospectiva anual, basándome en algunos conceptos y actividades interesantes que plantean.
Ya decía anteriormente que un concepto muy importante de las metodologías ágiles es la comunicación de banda-ancha entre los miembros del equipo. Sin duda, "Software for your Head" es uno de los libros que más te puede aportar en ese sentido.
Las retrospectivas en las metodologías ágiles son una práctica muy útil para la mejora continua de los procesos de desarrollo, del equipo, de las metodologías. Así que ahora que vamos introduciendo poco a poco metodologías ágiles en el desarrollo, se me ocurrio hacer una retrospectiva no ligada a una iteración o un proyecto, si no al año que termina. Una retrospectiva anual para establecer objetivos de mejora por el equipo para el año siguiente.
Y por si a alguien le interesa, estos pueden ser unos buenos pasos para hacerse la suya en casa (al menos creo que a nosotros nos han sido útiles), basados en el libro de Derby.

Set Stage:
Actividad 1: Check-in. Los participantes comentan su estado de ánimo.

Introducción a la retrospectiva: Objetivos: Aprender y mejorar.
Actividad 2: ECRP (Decide your role in this retro: Explorador/Consumidor/Relajado/Prisionero)
Gather Data:
Actividad 3: Timeline. Se desglosan por equipos los eventos/hechos ocurridos el año 2008 en el equipo, pintándolos sobre una linea temporal.
Generate Insights:
Actividad 4: Brainstorming. Desglose de cosas que podemos mejorar. En resumen, y sin orden de importancia, todo lo que salga.
Decide What To Do:
Actividad 5: Definir objetivos SMART. Decidir qué hacer. Objetivos para el 2009 de todo el equipo, como equipo.
Close:
Actividad 6: +/Delta. Retrospectiva de la retrospectiva. ¿les ha gustado?

Esto es simplemente un esquema, los libros están realmente detallados. Se podrían hablar de muchas cosas de cada punto o actividad, pero me gustaría que me contaseis si haceis vosotros este tipo de cosas en vuestras empresas, o si creeis que sería interesante. ¿Haceis retrospectivas a todos lo niveles?

Actualización (30/12/2008): Acabo de descubrir que han hecho un pequeño resumen del libro sobre Retrospectivas en castellano. Utilísimo como referencia una vez que te has leido el libro! Gracias Juan por tu trabajo!

El declive y caida de lo ágil

2008-12-07T23:21:00.001+01:00

Un reflexión de tic-tac (sobre una frase: "El hombre que actúa con métodos, ignorando los principios, es seguro que tendrá problemas.") me hace pensar en la carga de profundidad que tiene este otro artículo de James Shore: The Decline and Fall of Agile.
Habla sobre los problemas que está dando la proliferación de implantaciones que se están haciendo del método Scrum, pero haciendolo sin preocuparse de los principios que lo sustentan.

"These teams say they're Agile, but they're just planning (and replanning) frequently.. ""Agile is hard, and you can't master it by sitting through a two-day course."

Ciertamente hay una serie de cuestiones que escapan al "método Scrum", que deben ser parte fundamental de una metodología ágil. En el mismo artículo comenta algunas:

shared workspaces: La comunicación en espacios compartidos fluye mejor, es más fácil compartir una visión y el trabajo.
high-bandwidth communication: El equipo debe mantener en todo momento un canal de comunicación de alta capacidad. No hay excusas para guardarse información, no preguntar, o no compartir.
on-site customers: Es muy importante la disponbilidad del cliente cuando sabemos que los requerimientos van a evolucionar, y el equipo necesita aclaraciones en cualquier momento.
work in cross-functional teams: Los equipos multidisciplinares deben estar intrgrados en la solución del proyecto, deben ser un equipo al completo, no una serie de grupos de personas que resuelven cada uno su papel. Así se pierde enseguida la visión compartida.
let alone deliver releasable software: El avance de los proyectos se mide por producto terminado.
use good engineering practices: El concepto de deuda técnica aclara muy bien este punto. Si te hipotecas tecnicamente, el futuro del software no será sostenible.

Pero, ¿realmente son necesarias todas estas prácticas anteriores para ser ágil? Pues... ¡quizás no! Hay que conocer los principios, y aplicarlos para cada problema, que necesita una respuesta adaptada. En un comentario del grupo de Yahoo de lean-agile-scrum, la genial Mary Poppendieck lo dice en una respuesta muy interesante:

It sounds to me like you are taking the Scrum recipe much too seriously. If you want to be successful, you have to spend some time thinking creatively about what will work in your world. Lifting recipes from others and expecting them to work in your environment doesn't have a good track record of success.

Creo que por aquí estamos bastante lejos de pensar en el declive de Scrum, cuando no me parece que esté demasiado implantado por estas tierras. Pero si podemos llegar a la lección antes de qué nos peguemos con los problemas, eso que habremos ganado.

Libros de desarrollo de software

2008-11-30T22:18:00.001+01:00

Creo que este es el primer post que recupero "bajo demanda". Me acabo de fijar que tenía empezado uno con el mismo título desde mayo... ¡del año pasado!.
En fin, que ya me he decidido a haceros un listado con algunos de los últimos títulos que tengo en mi biblioteca relacionados con el desarrollo/gestión de software. He seleccionado algunos y los he ordenado más o menos por lo que me han resultado de interesantes o productivos. De todas maneras, sigo con una lista interesante de libros por comprar, esto no se acaba nunca! :)

Peopleware : Productive Projects and Teams, 2nd Ed.. Si no lo tienes, compralo. NO lo dudes. Es un clásico, pero no ha dejado nunca de tener vigencia.
Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers,... Joel Spolsky es otro de los que no te puedes perder. Y no hace falta comprarse sus libros por que todos los artículos están en su web. Habla la voz de la experiencia, y mucho sentido común. En algunas cuestiones es de la vieja escuela, pero tiene grandes ideas.
Leading a Software Development Team: A Developer's Guide to Successfully Leading People and Projects: Todo lo que cuenta este libro lo aprendí primero de uno de mis jefes -en una vida anterior-. Desde un enfoque tradicional de gestión de proyectos, repasa las estrategias y actitudes para gestionar los equipos y proyectos. Recomendado sobre todo si acabas de ganar responsabilidades de liderazgo de equipos o proyectos.
Lean Software Development: An Agile Toolkit (The Agile Software Development Series): Un libro genial. Hablá de técnicas que se pueden aplicar en los proyectos, sin centrarse en metodologías. Basado en el concepto de Lean, que tanto éxito ha tenido en procesos industriales.
Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision. Un libro curioso, al principio me decepcionó, pero luego te das cuenta del valor que aporta. Podía haberse llamado "Gestión de equipos", o prácticamente no relacionarlo con el desarrollo de sw. pero la cuestión es que son prácticas y patrones obtenidos de equipos de desarrollo. Cuestiones como la visión compartida, el compartir las emociones o el sistema de toma de decisiones son expuestas en este revouvionador libro. Todavía estoy por aplicarlas en serio.
The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition: Otro de los clásicos junto Peopleware. Hay que leerlo, pero me decepcionó un poco, aunque simplemente por que cuando cayó en mis manos ya había leido tantas referencias a él, que ya no me sorprendio. Te lo recomiendo para asentar conocimientos.
A Practitioner's Guide to Software Test Design. Conocí al autor -Lee Copeland- en el hotel de las jornadas de Valencia sobre testeo de software, allí todo el mundo le tenía como un gurú, así que le compré el libro posteriormente. Una buena recopilación de métodos de testeo, muy interesante para tener una idea general o si vas a empezar a montar un dpto. de QA.
Agile Retrospectives: Making Good Teams Great. Numerosas técnicas para esta parte tan importante de la mejora continua de las metodologías ágiles como son las restrospectivas. Muy práctico.
Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly)): Simpatico libro, únicamente si de verdad te gusta programar. Hay que leerlo con paciencia, pero se disfruta. Solo por vicio :)
Interface Oriented Design: With Patterns (Pragmatic Programmers): Para principiantes, es el único libro técnico que me he comprado en mi vida (¡gracias Google!), y me arrepentí, por que es bastante básico. No me suele gustar comprar libros para mi biblioteca personal que tienen fecha de caducidad.

Otros libros que no son propiamente de desarrollo de software, pero que he comprado ultimamente, relacionados con lo que yo creo que es el mundo de la gestión de equipos:

Marcapropia: El mejor libro en castellano explicando el concepto de marca personal, por Andrés. El año pasado presté un libro a cada persona de mi equipo a la que hacía la gestión por competencias de la empresa, pensando en sus labores a desempeñar. Este año había pensado regalarles a todos una copia de este libro. (otra cosa es que ya no lo vaya a hacer en vista del poco éxito de la iniciativa pasada :( )
My Job Went to India: 52 Ways to Save Your Job (Pragmatic Programmers). Relacionado con el concepto de marca personal, cualquier momento es bueno, para este libro pero sobre todo si no tienes muy claro por donde ir en tu carrera profesional relacionada con el software.
Certain to Win: Un libro sobre estrategia empresarial, pero basado en las estrategias militares de John R. Boyd. Viene a insitir en la idea de la agilidad y los ciclos de PDCA.
Fearless Change: Patterns for Introducing New Ideas: Otro libro de patrones, pero esta vez dedicados a la introducción de cambios en organizaciones. Es interesante ver como muchas situaciones las puedes reconocer en determinados elementos de la empresa.
Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers): Introducción a la gestión de equipos, cuando debes asumir esa responsabilidad. Me parecio un poco simplón, pero me gustó que te da ideas concretas para realizar.

Bueno, estos son algunos de los libros que he adquirido estos últimos dos años, posiblemente los que más me han impresionado o enseñado. Eso sí, todavía tengo que poner muchas cosas en práctica, que es con lo que de verdad se aprende... :)
Lamentablemente, ahora me fijaba lo poco que se traduce al castellano de todos estos temas. Me pregunto si es que no habría suficiente demanda para la traducción de un número mayor de libros.

Calidad testeada vs calidad creada

2008-11-17T22:50:00.000+01:00

La calidad de un producto software se puede medir, ahora bien, lo dificil es escoger la métrica adecuada. Pero además, también puedes tener la impresión de que se ha hecho con calidad, si se han seguido unos procesos correctos, el equipo ha cuidado sus diseños técnicos, se han seguido patrones de diseño,...
Desde que estuve en la jornada de testeo de software tengo la idea en la cabeza de como comunicar el mundo del testeo y el del desarrollo (eso claro, si cuentas con un equipo propio de QA, que no conozco muchos).

Los testeadores no se pueden quedar unicamente en encontrar fallos, además deben dar ideas desde su posición provilegiada de cómo mejorar el desarrollo del software.
Así mismo los desarrolladores no deben unicamente desarrollar, deben comprometerse con la realización cada vez más exhaustiva de pruebas y cómo facilitarla.

Podemos tener dos aproximaciones poniendome en el lugar de una empresa que desarrolla muchos proyectos de medio tamaño:

Equipo de testeo independiente de los equipos de desarrollo: Esta opción es la que nos contaron la gente de Google en las jornadas de testeo de sw. Podría existir un equipo que valide cada resultado de los sprint, realizando pruebas de caja negra sobre el sistema. Los posibles defectos encontrados, retrasarían la velocidad en el siguiente sprint del equipo de desarrollo.
Gente de QA integrada en el equipo: Los testeos más formales se realizarían dentro del sprint mismo de desarrollo, estas personas podrían realizar tanto testeo de caja negra como "blanca".

Pero una de las cuestiones más interesantes, y que en las jornadas de Valencia me parecio un mundo aparte, es la integración entre los dos equipos. Cuando hablamos de "Equipo=software", debemos incluir a todas las personas implicadas. Cada especialista puede aportar una visión muy importante al resto del equipo, que hace mejorar exponencialmente el trabajo en equipo.
Actualmente muchas pruebas se han trasladado a los desarrolladores, no solo por que no existen muchisimas veces equipos de QA, si no por que técnicas como el testeo unitario, se ha trasladado la responsabiliad del equipo de testeo a los desarrolladores.

Framework, o esa palabra maldita

2008-11-12T22:44:00.000+01:00

¿Qué piensa un desarrollador cuando le dicen que tiene que utilizar un framework inventado por la consultora MAJITICA SA para su nuevo proyecto web?

- J***d*r,... la que me ha caido... con la de frameworks libres que existen por el mundo y ahora tengo que usar uno que no tendrá más de 500 horas de pruebas y que no puedo ni ver su código.

Y es que mira que nos empeñamos en reinventar la rueda. Una cosa es desarrollar un API orientado al negocio, y otra sobreescribir el MVC de moda pegándole un IoC para que parezca que hemos hecho algo. ¿Cuantos de estos conoceis?

¿Es SCRUM una ventaja competitiva en una empresa de servicios?

2008-11-02T22:41:00.001+01:00

Como ya sabeis, estamos "tonteando" con Scrum en la empresa. Puede ser que sea un idilio largo o no. El otro día nos dieron un curso francamente bueno, fue la empresa Proyectalis. Podeis echar un ojo al blog de Angel Medinilla, quien nos impartio el curso de dos días, muy bien planteado e interesante.
Lo que ahora me pregunto es hasta qué punto Scrum puede ser una ventaja competitiva frente a las demás empresas proveedoras de servicios en este mundo del desarrollo de software. Tengo claro que no debemos de tratar únicamente de cumplir con los requisitos del cliente cerrados en el contrato y punto final, si no asegurarnos que esos requerimientos son los que hacen "feliz" al cliente. En esa filosofía, la base de las iteraciones ayudan: el cliente pone el foco en lo que quiere realmente mucho antes.
Sin duda Scrum en estos momentos puede suponer una diferenciación en el mercado actual. Pero eso sí, posiblemente especializandose en determinado tipo de cliente. La estrategia ganadora no puede ser en este momento una diferenciación para todo el mercado, sino una especialización en un nicho muy concreto de clientes. ¿Aceptarían todos los clientes un desarrollo "Scrum"? ¿podrías competir con grandes consultoras en mega-proyectos? ¿puedes dar servicio a administraciones públicas que te piden METRICA3 (o 2)?... ¿interesa hacer todo esto?

Esta es solo una entrada de dudas/preguntas, pero mi opinión es que SCRUM es el buen camino, hacia el "norte verdadero" que nos decía Angel en su curso.

El círculo proceso-persona

2008-10-20T23:40:00.001+02:00

Leyendo esta entrada sobre la idea recurrente de que lo más importante para hacer software son las personas, me ha venido a la cabeza una reunión de hoy que hemos tenido en Biko. Las mejoras en el desarrollo de software no se acaban nunca, y cuando tienes a medio hacer algo (podeis echar un ojo al documento libre sobre la implantación de técnicas ágiles con CMMI) ya estás pensando en lo siguiente.
Como decía, el post referenciado, me recordaba lo que hacemos cuando intentamos mejorar las cosas. En la mente tienes que lo importante son las personas, pero lo más facil ¿qué es? ¡¡Definir procesos!! Te pones a pensar: si hacemos las cosas así, o de esta otra manera, y luego nos sale esta otra situación, entonces lo que hay que hacer es... definimos cómo se debe hacer esto, para que después se haga igual...

Así que nos hemos ido a los procesos y parecería que nuestra intención es implantar CMMI nivel 4 o 5. (uf, y por cierto, no os olvideis de la encuesta, gracia). Yo siempre acabo diciendo que lo mejor es usar el sentido común, conociendo bien las herramientas disponibles y con la experiencia, se pueden tomar decisiones acertadas que son totalmente diferentes en el marco de un proyecto u otro. Pero siempre parece que tiras a definir los procesos, más que a pensar que la gente que tenga que resolverlos ya sabrá hacerlos, o que precisamente, a los que no sepan les vas a formar.

Es una dialéctica complicada, la de procesos contra personas planteada en el manifiesto ágil. Y cuesta romper. Supongo que tenemos hecha la cabeza de una manera (dura) que es dificil de cambiar la forma de pensamiento.
Todo esto está relacionado con lo que ya he comentado en otras ocasiones: ¿buenas prácticas o procesos? Al final, depende de la gente, a unos los puedes matar de aburrimiento siguiendo procesos muy formales, y a otros perderlos por el camino si no les pones las luces de aterrizaje bien claras.

Encuesta sobre CMMI

2008-10-16T22:31:00.002+02:00

A raiz de este post que menciona que hay 85 empresas más en España este año que han obtenido una certificación CMMI, me ha picado la curiosidad, yestoy montando una pequeña encuesta con intención de recoger información de aquellas personas que trabajen en una empresa con certificación CMMI. He reducido bastante el número de preguntas que quería hacer, para que no se haga pesada (que es lo que a mi me suele echar atrás para rellenarla, sobre todo, ;) si como en este caso no hay premio por hacerlo).

Si te apetece, aquí tienes el enlace: Encuesta sobre CMMI.

Y si conoceis a gente que pueda encajar en el perfil para rellenarla, por favor, me encantaría que les distribuyeseis el enlace.
Obviamente, después publicaré los datos y la información que pueda extraer de ellos en esta misma página. ¡GRACIAS!

Dos cosas

2008-10-09T22:50:00.001+02:00

Ayer recogí del correo el libro de Andrés Perez sobre MarcaPersonal. Me hizo mucha ilusión ver mi dedicatoria escrita en papel "de verdad". Me imagino que será como volver a leer de nuevo su blog, que ahora estaba pensando, es uno de los primeros que sigo desde el tiempo que llevo leyendo blogs. !Gracias Andrés, eres un crack!
No deberíais dejar de echar un vistazo al blog de Andrés, sobre todo si ahora en época de crisis os encontrais dudando sobre vuestras opciones profesionales.

Por otro lado, otra conexión con el mundo real por el blog, me invitan !por fin! a escribir un post a cambio de dinero. :D Bueno, a cambio de una suscripción a GTDagenda, que la verdad, tiene buena pinta, pero de momento me quedo con lo que tengo, ya que necesitaría dedicar un rato que ahora no tengo para probar el sistema. Bastante tengo perfeccionando mi implementación de GTD... Si alguien lo usa sí que me gustaría conocer sus comentarios, a mi de momento RTM me funciona bastante bien, con su buena integración con GMail.

Organización del tiempo: GTD

2008-10-07T22:55:00.001+02:00

Hace unas semanas, tras leer el famoso libro de David Allen "Getting Things Done" (también está en castellano), me decidí a poner en marcha mi aproximación al que parece uno de los mejores métodos de organización existentes a nada que consultes un poco en Google. En realidad, había leido el libro a principios de año, y lo volví a releer para empezar con el método.

Si no sabes de qué va GTD, brevemente te explicaré que trata de un sistema para la organización personal. Un sistema muy metódico, que tiene muchos seguidores por la red. No te voy a explicar aquí de que va, si no lo conoces, aparte del libro, te recomiendo este magnífico post de David Santo Orcero sobre GTD. Dice que es el primero, así que siguele la pista por que es una de las mejores explicaciones sobre una implementación concreta que puedes encontrar en castellano que no sea el libro mismo.
Mi aproximación no es tan completa todavía como la que puedes leer a David Santo, pero ahí vamos poco a poco.

Mis bandejas de entrada son el correo electrónico, y una bandeja tanto en la oficina como en casa. Utilizo rememberthemilk para gestionar mis listas, y me va muy bien la integración que tiene con GMail, ya que es el correo tanto personal como en el trabajo. Tengo mis listas (proyectos, acciones siguientes, en espera,...) organizadas por contexto con los tags de cada tarea, usando @xxxx cuando se trata de separar por trabajo, personal, telefono,... y les pongo +yyyy para indicar con qué persona está relacionada. Luego tengo creadas "SmartList" para las más usadas. El plugin de RTM además me relaciona las tareas con el correo electrónico desde el que las cree.
Estoy intentando rematar mis sistemas de ficheros, de momento me he organizado mejor las carpetas en los ordenadores, que no es poco, y veremos como voy haciendo las de papel, que en realidad son las que menos uso.

Suelo llevar una Moleskine encima cuando me acuerdo (y me cabe en algún bolsillo) para llevar notas, y que sirva también de bandeja de recopilación en cualquier parte. El problema que le veo precisamente es que necesito demasiado estar "online" para conocer todo el tema, creo que voy a empezar a imprimir las listas en mis revisiones semanales para poder llevarlas encima.

¿Funciona el método? Bueno, si eres un poco desorganizado por naturaleza: ¡pruebalo! Aunque únicamente apliques tres o cuatro cosas, seguro que te mejora la organización, y para mi, es un alivio ver que llevo el correo al día (¡¡llego a tener el INBOX vacio!!), y que sé que no se me escapa nada debido a un despiste.
Estos son un par de blogs sobre organización y productividad interesantes:

Confianza Mutua, equipos y desarrollo

2008-10-04T23:41:00.001+02:00

Uno de los posts que más visitas me ha traido, es en el que hablo sobre la confianza y las metodologías ágiles. Comentaba el porqué de que la confianza es básica para las metodologási ágiles. Ahora he encontrado un "post-it" que apunté hace tiempo, cuando leía un libro -lo malo es que no recuerdo cual, no sé si era uno de John Boyd o alguno sobre "Lean Software"- sobre que la clave de buen funcionamiento de un equipo es la confianza mutua, que basaba en cuatro pilares fundamentales:

Visión compartida: Uno de los típicos problemas en un equipo de desarrollo es que cada uno va a su aire, y demasiado tarde se dan cuenta que van hacia ideas diferentes del producto o de su implementación. Para Scrum, por ejemplo, este es un punto muy importante que intenta reslver con la implicación de todas las personas afectadas en el royecto con reuniones periodicas, y con los desarrolladores en reuniones diarias.
Comunicación: Una buena comunicación es fundamental para que puedas confiar que lo que entiendes te ha llegado de la manera adecuada y por tanto has entendido lo que la otra parte de verdad te ha intentado transmitir: que no es fácil.
Toma de decisiones compartida: Obedecer ordenes predispone a la desconfianza de los datos con los que se ha tomado, o por qué se ha tomado. Que el conjunto del equipo asuma las decidiones que tienen que afrontar, implica que también asumen su responsabilidad, y que pueden confiar los unos en los otros, por que la decisión es de todos.
Ética: No es sorprendente que un punto que pueda parecer que técnicamente no influye en una gestión de equipos, sea una clave fundamental para su buen funcionamiento. La falta de ética de uno de sus miembros corrompe cualquier atisbo de posterior confianza en esa persona, y por tanto, aumenta las suspicacias. No recuerdo ahora haber leido ningún libro sore metodologías ágiles que hablase explicitamente de este punto, pero cuando lo lei aquí, me parecio bastante básico y de sentido común. Una mala persona es capaz de envenenar cualquier equipo.

Y tú, ¿confías en los miembros de tu equipo? ¿confían ellos en ti? ¿crees que sois un equipo si esto no es así?

A la carga

2008-10-02T22:31:00.000+02:00

Bueno, pues desde mi última entrada ayer... ah no! en Abril! hablaba sobre SpringSource, y ahora resutla que van a cambiar el modelo de licencias de Spring. Parece que no es tan fácil hacer dinero con el software libre.
Pero Andrés no me deja estarme quieto, y tiene toda la razón. Así que vuelvo tras los San Fermines, las vacaciones, la tranquilidad de Agosto y el agobio de trabajo de Septiembre. Tras el inicio del cole para mi hijo, mis primeros pasos en la implantación de GTD, varios libros leidos y releido y algún disgusto importante, pero superado. De estas y otras cosas espero volver a hablar con más asiduidad por aquí.
Hoy tenía planeado haber ido al evento "Por propia experiencia", al que habíamos enviado un trabajillo, sobre implantación de metodologías ágiles con CMMI. Podeis descargaros el documento y echarle un vistazo: Metodologías ágiles sobre CMMI. Tenemos mucho camino por hacer en este sentido, espero poder ir reflexionándolo por aquí. Ahora espero impaciente a leer los comentarios de Julen sobre el evento.

Escenarios ante "SpringSource Application Platform"

2008-04-30T23:13:00.000+02:00

Tenemos una nueva plataforma de aplicaciones JAVA: SpringSource Application Platform. Es una plataforma que no cumple JEE completamente, y de hecho no parece que lo vayan a hacer. Soportan los módulos web como WAR, pero no se asoman los EJBs.
¿Necesitamos otra plataforma de aplicaciones en el mundo JAVA? Creo que no. El punto fuerte de esta nueva plataforma parece que va a ser la utilización de una plataforma OSGI. Esto puede ser un respaldo muy fuerte para esa arquitetura que no acaba de despegar en las aplicaciones reales. Pero tampoco es tan necesario, ni las ventajas que aporta son tan decisivas, nada que no se pueda hacer en el estandar JEE.
Como comenta Martín, esto podría ser un punto de inflexión en el mndo JAVA empresarial. Si se rompe la unidad sobre la plataforma JEE, podemos acabar con una de las ventajas más importantes: la interoperabilidad. Es cierto que ya hay muchas lineas de arquitecturas diferentes en JEE, pero la fuerza de Spring actualmente en muchos desarrollos pueden dar una fuerza muy importante a esta nueva plataforma.
De todas maneras, siempre es genial ver cómo hay gente que no se cansa nunca y tiene ideas novedosas y mejoras en un mundo en el que para algunos las cosas se han anquilosado demasiado. Y además, ahora ya tenemos un juguete nuevo para cacharrear :).

Patrones y mejores prácticas

2008-04-29T23:50:00.000+02:00

Una de las ideas que me rondaba la cabeza hace tiempo es cómo aprendemos, y cómo enseñamos. Los últimos libros que he leido plantean estas cuestiones en base al concepto de patrones. Y me gusta. Patrones de cómo hacer las cosas en determinados contextos, proponiendo determinadas soluciones. También puedes aprender las tareas a realizar para resolver algo, si alguien te dice qué pasos debes dar, los aplicas y listo.
Lo situo un poco en la linea de procesos vs. personas de las metodologías ágiles. Si quieres que alguien aprenda gestión de proyectos (¡de equipos!-tengo que hablar un día sobre "Software for your head"), ¿le das los procesos que debe seguir? ¿o le explicas las situaciones, las posibles soluciones, los problemas,...? Si quieres establecer cómo se deben de hacer las cosas, puedes establecer procesos, o puedes explicar las cosas, su porqué y su cómo, pero ¿cuando hacer una cosa u otra?
Acabo de leer un artículo que me parece muy clarificador, desde mi punto de vista, que solo llevo menos de un año con responsabilidades de jefe de proyecto, para aprender a enseñar y enseñar: Better Best Practices.
Plantea la evolución de las "buenas prácticas" en una empresa apoyándose en el modelo de Dreyfus del Aprendizaje. Este se basa en poner cinco etapas al aprendizaje, dónde cada etapa tiene unas necesidades para realizar bien sus tareas y aprender con ello. Hay cinco niveles, resumidos más o menos:

Novice - Needs to be told exactly what to do. Very little context to base decisions off of.
Advanced beginner - Has more context for decisions, but still needs rigid guidelines to follow.
Competent - Begins to question the reasoning behind the tasks, and can see longer term consequences.
Proficient - Still relies on rules, but able to seperate what is most important.
Expert - Works mainly on intuition, except in circumstances where problems occur.

La conclusión que he sacado después de leer el libro "Acerca de Internet" (que me compré por que ese artículo me picó la curiosidad), es que los procesos impiden la excelencia y la brillantez en los trabajos, pero que son necesarios para llegar a un nivel medio de desempeño, especialmente útiles en las fases de aprendizaje.
De aquí podemos llegamos a dos conclusiones de manera un poco más formal que creo ya he comentado otras veces, sobre las metodologías de desarrollo:

Sobre las metodologías ágiles, que es dificil integrar a gente más "novata" en ellas. No hay procesos, y la gente sin experiencia necesita una guía más centrada en qué hacer. No se desenvuelven bien en entornos que aún no controlan.
Sobre las metodologías basadas en procesos: Que impiden que la gente experta sobrepase el listón establecido de "media"(¿mediocridad?) en los procesos, y no sé aprovechan las experiencias completamente.

Testeo, cerdos y gallinas

2008-04-08T22:48:00.000+02:00

¿El equipo de testeo de software -si existe :)- tiene una implicación como cerdos o como gallinas desde un enfoque ágil del desarrollo?
En las jornadas de la semana pasada JTS2008, se habla mucho de equipos independientes de testeo de software, de equipos separados que hacen el testeo y se comunican con desarrollo prácticamente para comunicarles los bugs. Entonces, ¿qué implicación tienen como equipo? Si no recuerdo mal, salvo la persona de Google (Julian Harty), nadie más habló de implicar gente de testeo con el equipo de desarrollo para ayudarles a mejorar su proceso de creación del software. Y esto me estuvo dando vueltas toda las jornadas.
Cualquier proceso de calidad que se precie tiende hacia la mejora continua, pero esto no creo que se deba entender en software como simplemente la eliminación de bugs de los producto, si no como la búsqueda de la eliminación de las causas de creación de bugs. El equipo de testeo puede ayudar identificando areas donde el desarrollo mete más la pata, detectar dónde es más necesaria formación, o un rediseño, o un mayor hincapie en las pruebas unitarias...
Así que lo veo complejo, por que empiezo a creer que es genial tener un equipo externo que haga testeo del software, en plan gallinas,... pero también creo que deben estar implicados como cerdos para la mejora continua "hasta el infinito y más allá!", y para eso necesitan plena involucración con el equipo de desarrollo.
Algunas pruebas típicas de testeo las estamos moviendo poco a poco hacia el equipo de desarrollo, como las pruebas unitarias, por que realmente... ¿que % de proyectos cuentan con un equipo de testeo? y las metodologías ágiles nos han dado las técnicas necesarias para ello (al menos las han popularizado). Este es uno de los puntos por los que mejoramos el proceso para eliminar la creación de bugs, pero queda mucho por hacer...

Usabilidad de los funcionarios

2008-04-07T22:01:00.000+02:00

Biko2 ha publicado un informe sobre la usabilidad en webs de las Comunidades Autónomas. Podeis descargarlo en esta dirección de Biko2.

El equipo de consultoría y experiencia de usuario de Biko ha analizado los portales de las 17 Comunidades Autónomas españolas identificando aquellas que son punteras, presentando buenas prácticas e identificando los aspectos más críticos a mejorar.

Es un interesantísimo informe si te atrae el tema de la usabilidad o las administraciones públicas online. Lo que yo no sé es por qué nos preocupamos tanto por las situaciones online, cuando no sé si los de las ventanillas aprueban!
Veamos a la imagen típica de los funcionarios, tal y cómo es apreciada por multitud de nuevos aspirantes a un puesto "seguro para toda la vida", haciendo el paralelismos con lo que han aportado desde Biko2. :)
• Posicionamiento. "Como me posicione en la silla con plaza fija no muevo el culo de ahí ni para levantarme al café... bueno, eso sí."
• Servicios al ciudadano. "El ciudadano soy yo!"
• Ventana al visitante. "Siempre y cuando no vengan a verme a la hora del café!"
• Presencia Institucional. "Estaré presente siempre que venga el político de turno a llevarse las medallas"
• Factores motivadores. "¿motivación? ¿para qué?"

Sé de buena tinta que la gran parte de los funcionarios curran de verdad, y lo que me preocupa no son los que ya están en el sistema sin pegar sello, si no la imagen que tienen muchos jóvenes de que irse de funcionario es el chollo, pero no por las buenas condiciones de trabajo o su interés, si no por que ya lo tienes todo hecho e incluso puedes aprovecharte de ello-forzando la situación-.

Jornadas de testeo de software

2008-04-06T11:02:00.000+02:00

El jueves estuve en el primer día de las jornadas sobre testeo de software JTS2008. La verdad que me han sorprendido la cantidad de conceptos que manejan en esta area, y que desconocía.
Hay varias cosas que tengo que analizar mejor. Me llama la atención que casi parece que son diferentes paralelos los procesos para la calidad mediante pruebas que la generada por los desarrolladores. Hablan de los testers por un lado, de sus pruebas, y no lo ligan demasiado a cómo eso afecta a los desarrolladores más que en que tienen que corregir los bugs que encuentran.
Y es curioso, por que yo tengo otro concepto más cíclico. Más que nada por que el concepto de fabricación con calidad, me resulta más atractivo que el de su control. Después de las pruebas, en algún momento se debería analizar lo que está pasando, para ver que se puede mejorar en el desarrollo que minimice en el siguiente ciclo de pruebas el número de errores.
Lo que sí coincido es que hace falta una persona (al menos) dedicada a diseñar/hacer pruebas de los sistemas en el equipo de un proyecto, y que no sea desarrollador.
¿Controlar la calidad, o fabricar con calidad? Yo que veo más cercano el equipo de desarrollo que el de testeo, me inclino a poner primero los medios en este primero para asegurar que hacemos software de calidad: lo que sea, pruebas unitarias, integraciones continuas, reuniones diarias, formación exhaustiva, mejores capturas de requerimientos, entregas iterativas,... y luego, pondría un equipo de test :)
Nos ha contado una persona de Google cómo tienen organizados los tests de sus apliciones: la palabra que más ha mencionado es "divertido". :) Curioso como cuenta que no tienen procesos establecidos, si no que cada uno es responsable de lo que hace y de cómo lo hace. Hay grupos de testeo en la empresa que apoyan a los creadores de productos, especializandose en las pruebas.

Anyway, bastante interesante la jornada, ya os daré más datos... o no,... :P os contaré más de la jornada del viernes, con más empresas contando sus experiencias. Idme contando, ¿teneis departamente de testeo de software?

Devolver el tiempo

2008-03-11T22:47:00.003+01:00

Si hay una empresa que me guste ahora, esa es Atlassian. Buenos productos y una imagen envidiable en la red. Comparten sus ideas, y distribuyen sus productos con una licencia muy interesante para los usuarios.
Ahora acaban de publicar el "experimento" que van a realizar con sus ingenieros: "El 20% del tiempo". Y además van a blogear los resultados de sus experimentos, así que hay que seguir atentos. Este asunto trata de permitir dedicar a los desarrolladores el 20% de su tiempo en la dirección que elijan, de innovación, tecnologías o mejoras en los productos que soportan.
Me direis que esa es la famosa regla que Google aplica en su empresa, pero primero, tampoco dan tanta información, y segundo, tengo la impresión que es el 20% de 11 o 12 horas diarias de trabajo, no de una jornada normal. Atlassian reconoce que "copia" esa regla. :)
Dar esa confianza a los desarrolladores, puede significar sacar a flote grandes ideas que permanezcan escondidas tras la burocracia y las jerarquías. Supongo que se trata de recuperar, o no perder, la ventaja competitiva que tiene una "startup", a la vez que crecer de manera controlada.

A startup engineer must be all things - he (or she) is a full time software developer and a part-time product manager / customer support guru / internal systems maven.
As a company grows, an engineer spends more time doing the software development - but paradoxically he spends less time building the things he personally wants in the product.

Ahora le doy vueltas a cómo este tipo de resolución se puede aplicar a una empresa de servicios. Una empresa de servicios factura por horas, no hay un producto dónde se pueda producir un retorno de la inversión claro, ni donde centrar los esfuerzos personales-divergentes dedicados en ese 20% de tiempo. ¿Qué os parece? ¿cómo se podría trasladar este tipo de iniciativas a una empresa de servicios de software, que funciona por proyectos?

JIRA y CMMI

2008-03-10T22:23:00.001+01:00

En nuestra empresa hemos implantando CMMI, acabamos de pasar un reluciente SCAMPI y pronto seremos nivel 2 oficialmente. Pero lo que ahora voy a hablar es del uso de JIRA como herramienta de gestión de proyectos. Quién conozca la herramienta y un poco de CMMI pensará que va ser un poco dificil conseguir que JIRA de soporte a algún tema de CMMI, si no que será más fácil usarla como herramienta PARA los desarrolladores, puesto que en realidad es una herramienta de "bugtracking".
Pero al final le hemos hecho algunos cambios, y JIRA nos va a dar soporte al EDT (Esquema de Descomposición de Tareas) para la fase de ejecución de proyectos. Cada incidencia creada en el sistema JIRA ahora podemos clasificarla en un tipo de Actividad (o Area de Conocimiento): Planificación, Desarrollo, Configuración, Sistemas, Implantación, etc,... Y con las versiones de JIRA podemos basarnos en desarrollo iterativo e incremental.
Esto nos da bastante flexibilidad tanto para desarrollar proyectos a precio cerrado, como para un día poder saltar a modelos más "ágiles" de desarrollo y comercialización.
Pero la gran mejora que podremos tener es obtener la verdadera visibilidad del desarrollo del proyecto, puesto que cada tarea puede ser reestimada en cualquier momento por cualquier persona implicada como responsable de sus tareas asignadas. Ahora tenemos que ir valorando la fecuencia de esas reestimaciones, la exactitud de las mismas dependiendo de la experiencia, y sobre todo, el impacto del cambio en la gente, que seguro será positivo.

Adopción ágil

2008-03-05T22:25:00.004+01:00

Me envió Luis un enlace a una encuesta sobre la adopción de metodologías ágiles en las empresas.

Not aware	13%	26%
Not using	13%	16%
Investigating	14%	14%
Analysed and rejected	4%	3%
Pilot projects	8%	4%
Partial implementation (adoption of some agile practices)	17%	17%
Partial deployment (some projects are using this approach)	14%	12%
Deployed (all new projects are using this approach)	17%	8%

Fuente: www.methodsandtools.com

Según esta encuesta, obviamente han pasado dos años, el desconocimiento de las metodologías ágiles ha disminuido significativamente. Sin embargo de lo que no me fío, es de la fiabilidad de los ratios de adopción, parcial o completa, por que principalmente lo que decimos que es adopción de metodologías ágiles, no se trata más que de una aproximación a sus "buenas prácticas". Esta perfectamente explicado en este artículo de Version Cero: "Nosotros hacemos Scrum".
De todas maneras, si quereis más estadísticas:
Google Trends:

cmmi

agile

Esta última comparo CMMI y ágiles, por que la semana pasada pase mi primer SCAMPI en una empresa, y ha hablare de ello en otro próximo post.

Los grandes programadores

2008-02-28T21:11:00.002+01:00

Hace unos años me regalaron (a mi y a Virginia, fue un regalo compartido de un jefe) un libro que leí con mucho interés. Ahora el autor del regalo, escribe sobre él en esta entrada del CES Digital:
Los maestros programadores.

El hoy arquitecto jefe de software de Microsoft, Ray Ozzie, se explayaba así: “los proyectos complejos de programación dirigidos por directores que no son programadores están frecuentemente condenados al fracaso, porque ellos no comprenden los intricados entresijos de los componentes del proyecto, ni las personalidades de los trabajadores. Los directores de proyectos de software han de comprender a las personas que trabajan para ellos. Yo conozco lo mejor que puedo la situación familiar, el estilo de vida y los hábitos de trabajo de cada una de las personas que trabajan conmigo. Sé que no podemos trabajar jornadas de nueve a cinco y sacar el proyecto adelante. También sé que no puedo presionar a la gente para que trabaje 24 horas durante todo el proyecto. Pero sé que, cuando llega el punto decisivo, puedo contar con ellos para trabajar día y noche si es necesario. Ahora, también tengo que saber cuándo hay que aflojar”.

No voy a sacar el recurrente tema de si los jefes de proyecto deben tener un perfil técnico o basta con un perfil de gestión. Lo que me interesa destacar son dos puntos:

Hay que planificar los proyectos para que la gente los pueda hacer "de nueve a cinco", durante todo el proyecto. Ya vendrán problemas que no se te habían ocurrido. Seguro.
Al tomar la responsabilidad de dirigir proyectos me he dado cuenta que esto no es realmente la informática. Dejas de enfrentarte a problemas matemático-lógicos, para enfrentarte (otras veces, afortunadamente, para colaborar) con las personas.

Ahora tengo encima de la mesa este artículo sobre "A scalable concurrent malloc implementation for FreeBSD". Un artículo que desde luego no tiene nada que ver con la gestión de proyectos, ni siquiera con la programación que hago actualmente. Pero es interesante.
La informática intenta resolver problemas de la gente, mejorar sus procesos, automatizar trabajos,... etc... pero los problemas realmente interesantes para un informático-programador son los que la propia informática genera a bajo nivel. Esos que nos empeñamos en dejar cada vez más abajo y dejarselos a los frikis de las universidades, o de las grandes empresas.
Ahora que busco desesperadamente mi marca personal, he pensado muchas veces en que los problemas que más me gusta resolver son los que no resuelven problemas de personas, si no problemas de computación. Aunque ya no tengo la experiencia necesaria.
Me gusta ser responsable de proyecto, decidir estrategias, implantaciones, tácticas, técnicas... enseñar todo lo que sé al equipo, hacer que trabajemos todos coordinados... pero... me gusta programar.
Si no podeis conseguir leer el libro Programers at Work, al menos leete el artículo de C. Urtasun.

Scrum y XP desde las trincheras castellanas

2008-02-27T20:54:00.005+01:00

No puedo dejar de recomendar y agradecer la traducción que se han trabajado en Proyectalis del magnífico libro publicado en InfoQ Scrum and XP from the Trenches. Ahora tenemos este libro en un primer borrador traducido a castellano en: Scrum y Xp desde las trincheras .
Si eres de los que le da pereza leer en inglés, ya no tienes excusa.

El producto es el equipo!

2008-02-15T23:42:00.002+01:00

He empezado a leer "Software for your Head" siguiendo la recomendación de Mario, y la verdad es que promete. Lo recomendó comparándolo con "Peopleware", así que tiene el listón muy alto.
Pero la idea básica que da en las primeras páginas, ya te lleva a reflexionar. Se plantean una investigación con equipos de desarrollo de software, y su estudio bajo esta sencilla premisa:

Equipos = Software

Y buscan los patrones que hacen funcionar a un buen equipo para desarrollar software de calidad y en plazos. Ahora bien, la primera idea interesante es cuando sben de nivel en la jerarquía. Ahora que soy responsable de proyectos, o eso que llaman mando intermedio también, he seguido pensando que mi trabajo es desarrollar software. Con más responsabilidad, más radio de acción, etc... pero que básicamente me encargo de desarrollar software con un equipo de personas.
Pero es por que no me he dado cuenta que ahora para mi, mi producto como resultado de mi trabajo, no es el software.

Mi producto es el equipo

Y plantearte eso te hace cambiar bastante algunos conceptos. El primero y más obvio, ¿qué narices sé yo de fabricar buenos equipos? El segundo un poco , un poco desasosegante... si hasta ahora lo que me gustaba es producir software... ¿qué hago yo aquí? Aunque, ¿puedo producir equipos que produzcan software si yo no sabría hacerlo? Juraría que no, y por ahí también intuyo que va el libro cuando habla de que el equipo debe tener las características que le pedimos al software que fabrica: estabilidad, escalabilidad, que no tenga/cometa errores,...
Otra idea me lleva a apoyar aún más con estos argumentos a las metodologías ágiles de desarrollo. "La persona sobre el proceso", ¿no implica el equipo sobre la gestión?.

Creo que me va a gustar mucho el libro, por que ya os digo que no he leido más de una pequeña introducción... y me ha dado mucho para pensar, aunque afortunadamente para vosotros, lo dejo para otros posts ;)

La chispa de la vida

2008-01-22T22:50:00.002+01:00

Hoy hemos acabado discutiendo si los proyectos de software son como los de construcción o los de hacer tortillas de patatas (sic).
La gestión "clásica" de los proyectos (tipo CMMI, con toda la literatura que eso implica) con todas las técnicas y procesos de gestión de requerimientos, gestion de riesgos, planificaciones,... pueden ser usadas para todos los proyectos que creamos las personas. Pero un nivel 5 de CMMI no implica un éxito garantizado de los proyectos de software.
Tampoco la gestión ágil de los proyectos (XP, o SCRUM,...), como contraposición al modelo anterior garantiza que el desarrollo del proyecto vaya a ser un éxito. Tiene otro enfoque, ni mejor ni peor, depende de la ocasión y el contexto.
Sin duda Juan Palacio lo presentaba acertadamente como la tesis y la antítesis, de la que saldrá una síntesis en gestión de proyectos. Pero ¿puede existir algo que haga exitosos todos los proyectos software? Quizás demasiado complejo para implementarlo, pero ¿podría existir? Unos pasos previos que nos pongan en alerta ante cualquier fallo de software ANTES de que ocurra.
Un arquitecto sabe si se le va a caer el edificio o el puente antes de construirlo, le basta con simularlo. Pero no podemos simular un software, su simulación real requeriría la construcción del propio programa, con lo cual no lo simulamos, si no que lo probamos.
Un cocinero sabe qué queda despues de mezclar los huevos con las patatas, pero un desarrollador no puede estar seguro como va a ser la integración de dos componentes interactuando juntos, si tendrán problemas de integración, hasta que no los prueba.
En definitiva, que sabemos que no existe la "bala de plata", y que esta no va a existir. Esto hace mucho más divertido e interesante nuestro trabajo, o ¿no nos reiríamos más si de vez en cuando se cayese un puente o la tortilla de patatas no cuajase por más que la cociesemos?

Al final Oracle compra BEA, ¡y SUN mysql!

2008-01-16T22:47:00.000+01:00

Pues al final la compró. Ahora solo hay que poner la cuenta atrás a ver cuando lo estropea :).
Y no sólo eso es interesante. SUN ha comprado mysql.
¿SUN puede hacer daño a Oracle con mysql en su mejor terreno, las bases de datos? Este movimiento me parece que puede tener mayor repercusión en el mercado que el de Oracle y BEA. Al final, Oracle volverá a cambiar de servidor de aplicaciones, lo que apostaría que echará a sus clientes más hartos, pero el mercado no cambiará demasiado.
Pero si SUN se plantea hacer frente a OracleDB con mysql, creo que estos se pueden poner algo nerviosos. ¿será casualidad que se comuniquen estas noticias el mismo día? SUN reforzará su mercado de software libre, e inyectará un buen capital para rematar algunos desarrollos que pueden hacer a mysql enfrentarse en grandes instalaciones a Oracle.

Me entero por Pensamientos.

El libro

2007-11-22T22:39:00.001+01:00

Otra vez voy a hablar de un libro que no tiene nada que ver con el tema general de este blog-o lo que queda- pero que es muy cercano a mi.
Se trata de un libro titulado "El médico rural que tocaba a J.S.Bach", y lo ha escrito mi padre, Luis Carlos Díaz, sobre la vida de mi abuelo basándose en sus diarios. Vamos, más personal no puede ser.
No conocí a mi abuelo paterno, era médico rural en extremadura, y luego forense en San Sebastian-el juicio de Burgos le tocó, por ejemplo, como cuentan en el prólogo del libro-. Recuerdo cuando íbamos a San Martín de Trevejo (Extremadura) y todavía se usaba como mesa en la "boiga" una vieja tabla de madera que se usaba para los Rayos-X... ¡y la batería estaba en una esquina llena de telarañas! Ahora espero impaciente a hacerme con una copia del libro para conocer un poco más a mi abuelo.
Si os apetece leer algo diferente, os invito a acercaros a este libro. Podeis leer un pequeño resumen en una entrevista al autor. (Si quereis comprarlo, mejor poneros en contacto conmigo para obtenerlo directamente del autor ;) ).

Oracle a por BEA

2007-10-12T16:35:00.000+02:00

Y no se trata de BEA la fea. Oracle va a intentar comprar BEA, ofreciendo un jugoso 25% de incremento sobre el valor actual de la acción. Ya hablabamos antes (mucho antes) de que Oracle necesitaba una posición más fuerte en el segmento de los middleware, y desde luego BEA es joya de la corona en ese segmento en mi opinión.

REDWOOD SHORES, Calif., Oct. 12, 2007—Oracle Corporation (NASDAQ: ORCL) today confirmed that it delivered a letter to the Board of Directors of BEA Systems, Inc. (NASDAQ: BEAS) on October 9 in which Oracle proposes to acquire BEA for $17.00 per share in cash. The $17.00 per share offer is a 25% premium over yesterday's closing price of $13.62.

Con semejante adquisición (aparte de que los desarrolladores de Oracle deberán otra vez liarse la manta a la cabeza y aprender nuevas tecnologías adquiridas) Oracle podrá hacer frente a las amenazas de Microsoft, SAP y RedHat/JBoss.
Para "variar", Oracle prefiere comprar la innovación o la tecnología a crearla -afortunadamente para ellos viendo como hacen algunas cosas :)-. Y este movimiento puede dar una ventaja muy importante a Oracle en los entornos empresariales de gran tamaño, el mismo suministrador con un middleware decente, y una base de datos consolidada.
Supongo que ahora estará en manos de los accionistas el vender la empresa, pero si yo fuese cliente de BEA la verdad que sabría si este movimiento me perjudicaría o favorecería. Veremos qué da de sí esta noticia.

Actualización: Parece que BEA ha rechazado la oferta. Una opinión interesante de alguien que dice ser empleado de BEA.

Lockpicking

2007-10-04T22:38:00.000+02:00

Hace un tiempo escribí un post describiendo un simil que se me había ocurrido entre el software libre y el conocimiento de cerrajería [Cerrajeros y seguridad], y me he sonreido al leer un foro donde los propios cerrajeros se plantean la misma cuestión de libertades pero asociada a su profesión, así que aquí les hago trackback-back-again: Lockpicking Sport. Echadle un vistazo, es curioso ver otro punto de vista, no sé si extrapolable o no, pero curioso.
Un saludo a todos los cerrajeros :)

Free Burma!

2007-10-04T15:14:00.000+02:00

Estrategia Open-source: No lo sé

2007-08-10T11:17:00.000+02:00

What is the business model for this? (for Open-source)

What's the business model? I don't know. But if you don't have adoption, it won't matter what business model you use. Companies that sell open source are prioritizing community and adoption over instant monetization. We will win.
Q&A: Jonathan Schwartz on Sun's open-source business strategy

El oráculo

2007-06-21T12:42:00.000+02:00

¿Habeis visto últimamente Oracle.ES? Así empieza su nuevo mensaje :)

Estimados visitantes:

En primer lugar presentarme, soy P.P.G. , actual propietario del dominio ORACLE.es , y escribo para informarles personalmente y como es justo del estado de la página, que había estado usando con referencia a los oráculos antes de este escrito, y 6 meses después de mi registro me van a quitar para dársela a Oracle Iberica SL.

Hay que ser muy muy [?] para que se "te olvide" un dominio de semejante importancia. Pero bueno, estas cosas pasan... y yo sin enterarme.

Tus series favoritas de médicos y su "código fuente"

2007-06-20T18:31:00.000+02:00

De vez en cuando la "inspiración" viene de sitios insospechados. Esto he recibido por email hoy mismo, de un aficionado al ajedrez.

¿Por qué en las series como 'Hospital Central', 'Anatomía de Grey' o 'House' el que más sabe de medicina, aunque sea el director del Hospital, el que más cobra, está a pie de mesa de quirófano o visitando pacientes y, en cambio, en el desarrollo de software el que tiene más responsabilidad no ve ni una línea de código, ni igual un mapa de la arquitectura de la aplicación.

Quizás leo demasiados blogs...

2007-06-18T22:06:00.000+02:00

Puede ser que tenga en mi cuenta de Bloglines demasiados "feeds"(105), pero cada vez que me interesa un tema, "casualmente" veo referencias a comentarios en blogs que lo tratan.
Lo que sospecho es que siempre leo entradas sobre cientos de temas diferentes, y dada la amplitud y selección de temáticas a los que estoy suscrito, siempre al focalizar mi mente en algún tema en concreto durante un tiempo, "aparecen" posts sobre ese tema. Aunque claro, no es que aparezcan y me interesen, si no que me interesa el tema y entonces los marco como interesantes.
Si estoy mirando cómo vender lo "ágil" o entrevistar a futuros candidatos, Juan Palacio hablará sobre ello. Si quiero averigüar como reorientar mi carrera, Andrés Perez comentará siempre algo interesante para mi marca. Si me harto de tanta bienaventuranza webdoscera, Rogelio tendrá un comentario irónico que me reconciliará con la red. Y si estoy poco inspirado en mi vida, Telémaco soltará algun post genial que me de una buena idea. Y así podría seguir con mis otros 100 blogs...

Ahora tengo un problema, no sé que va antes, si mi pensamiento, o el de la blogsfera... :)

¿Vende "Lo Agil"?

2007-06-05T22:56:00.000+02:00

Vender proyectos sin asignar un presupuesto cerrado al inicio es dificil... ¿o imposible? Vale, sé que Juan Palacio los hace, pero ¿quién vende proyectos sin ir contra presupuesto cerrado? La confianza necesaria para ello con un cliente no nace de la "fama" que pueda tener la empresa o el equipo, si no solo posiblemente tras una relación larga de éxitos.
Mi duda, que planteaba también hace cinco minutos en este interesante post de Rodrigo Corral, es cómo encajar una metodología ágil dentro de proyectos con requerimientos y presupuesto cerrados en la primera fase. Obviamente, rompe dos esquemas importantes del manifiesto ágil:

Customer collaboration over contract negotiation
Responding to change over following a plan

Las buenas prácticas de las implemenaciones de las metodologías ágiles están aquí para quedarse y son de gran ayuda, pero rompiendo dos de las cuatro frases objetivo del manifiesto... ¿usarás una metodología ágil?

Infraestructura web JAVA

2007-05-28T22:25:00.000+02:00

¿Qué harías si sabes que cualquier cosa (herramienta, framework,...) que elijas sabes que la vas a tener que cambiar en unos años? Pues prepararte para el cambio: buscándolo.
El montaje que hemos realizado para los desarrollos JAVA sigue la clásica configuración de tres capas: presentación, servicios y persistencia, intentando no atarnos a ninguna tecnología demasiado de la que nos sea imposible prencindir en un momento dado.
La elección de las tecnologías depende de muchos factores que no son solo tecnológicos, como el conocimiento con el que puedes contar en la organización para empezar a trabajar, o la disponibilidad de personas formadas para una posible contratación. Después ver que eficacia y eficiencia puedes esperar de ellas.

Presentación: Necesitas un framework ágil, en el que se pueda ser eficiente y rápido desarrollando la interfaz. Ese framework no es Struts 1.X., ¿podrá ser Struts 2, o Wicket? Hay muchas opciones en esta capa. Ahora hemos elegido Struts 1.x... jeje, sí, ese que no es ágil y es pesado de desarrollar (muchos xml, clases), por que era donde teníamos mayor conocimiento y experiencia.
Servicios: Al decidir seguir una arquitectura basada en servicios, debes decidir también como va a ser el acceso a los mismos: EJBs, clases locales, servicios web... La opción que parece que ofrece más flexibilidad es Spring. Permite la utilización de IoC de manera que nos facilita el acceso a los servicios inyectándolos en la capa de presentación, y además tiene utilidades para hacer transparente el cambio de EJBs a clases o viceversa.
Persistencia: Para proyectos que no requieren de excesivo énfasis en el rendimiento, un framework de persistencia objeto-relacional parece hoy en día la opción más interesante. Aquí vamos con Hibernate.

Spring es una pieza muy importante en esta arquitectura que estamos implementado. Es un poco el pegamento entre las capas, y además ofrece muchas prestaciones interesantes: gestión de transacciones, aspectos, soporte de pruebas unitarias,...
La evolución de esta arquitectura está clara:

Migración de Struts 1.x a otro framework, que sea más ágil, ofrezca una velocidad de desarrollo mayor y basado en plantillas que la gente de diseño pueda tocar más fácilmente. Wicket parece una gran opción.
Eliminación del trabajo manual de modelado de la persistencia. Hibernate Annotations simplifica el trabajo de mantenimiento de la persistencia, pero la automatización del proceso es un objetivo más ambicioso. Estuve probando androMDA, pero la verdad que no lo hice funcionar satisfactoriamente.
Despliegue automático de las aplicaciones en versiones EJBs o clases locales o servicios web. Una vez que se tiene las clases de implementación de los servicios, un objetivo sería poder desplegar los mismos de manera automática en cualquier plataforma.

¿Qué más ideas se os ocurren? Obviamente hay mucho más que hablar sobre arquitectura, estais invitados. :)

Camino sin Destino

2007-02-27T11:11:00.000+01:00

Al final llegué a la conclusión que con mi cambio de hace unos meses no acerté. El trabajo que estaba desarrollando no me resultó demasiado interesante, y las ventajas que tenía no han podido convencerme.
Así que justo cuando ya me planteé en serio el hecho de cambiar de trabajo me llamó un amigo que necesitaban un jefe de proyecto, para una oficina que ~~van a abrir~~ hemos abierto en San Sebastian. Casualidades de la vida, así que ahora que voy descubriendo, o intentando convencerme, de que lo bueno no es el Destino si no el camino que te lleva a él, me embarco en mi sexta aventura profesional. Con muchas ganas, por que es el tipo de trabajo que quizás llevaba buscando algún tiempo. Intentaré hablar algo más sobre él.
Llevaba algo más de tres meses sin escribir por aquí. Pero nos os he dejado de leer...

Empresas piramidales

2007-02-19T14:32:00.000+01:00

Al de arriba le pinchan, canta la canción... y todos intentan hacerle el coro.

Esta es la manera de los que tienen miedo.
Esto debe ser el efecto de la fiebre. Quizás necesite otro chute de Nolotil.

Bissines Intelligence - Open Source

2007-02-15T22:17:00.000+01:00

Hace tiempo que les había prometido en un comentario que les iba a dedicar un post a este blog tan interesante de TodoBI. Aquí ya sospechamos ;) que en un futuro solo quedará el software libre, y en el campo de Bussines Intelligence en Stratebi lo plantean realmente bien. Cuatro packs para el acercamiento a sus soluciones, de manera gradual y según las necesidades.
Ahora han preparado un curso preparado especialmente para la gente que quiera iniciarse en este mundo e iniciar su carrera profesional en esa linea. El precio me parece bastante ajustado, así que si os interesa el tema, no dudeis en echarle un vistazo.

Especialmente dirigido a recién licenciados, a punto de concluir o con reciente experiencia profesional !!

Queremos crear un gran equipo!!

Este curso es el primer paso para que podáis desarrollar vuestra carrera en el mundo del Business Intelligence con tecnología Java Open Source y Stratebi os ofrece grandes oportunidades para comenzar.

Publicidad "contextual" en videos

2007-02-14T16:40:00.000+01:00

Acabo de ver el video sobre el N95 de Nokia en El Mundo, y no sé como establecen la publicidad que meten al inicio, pero me han puesto publicidad del Tomate Orlando. Vamos, que muy contextualizada no me ha parecido.
Espero que las campañas de publicidad que se ciernen sobre nosotros en los videos sean un poco más refinadas.

Cita de masas

2007-01-31T22:22:00.000+01:00

Este es el mayor peligro que hoy amenaza la civilización: la estatificación de la vida, el intervencionismo del estado, la absorción de toda espontaneidad social por parte del Estado; es decir, la anulación de la espontaneidad histórica, que en definitiva sostiene, nutre y empuja los destinos humanos. Cuando la masa siente alguna desventura o, simplemente, algún fuerte apetito, es para ella esa permanente y segura posibilidad de conseguir todo -sin esfuerzo, lucha, duda, ni riesgo- sin más que tocar el resorte y hacer funcionar la portentosa máquina. La masa se dice: "El Estado soy yo", lo cual es un perfecto error. El Estado es la masa sólo en el sentido en que puede decirse de dos hombres que son idénticos, por que ninguno se llama Juan. Estado contemporaneo y masa coinciden sólo en ser anónimos. Pero el caso es que el hombre-masa cree, en efecto, que él es el Estado, y tenderá cada vez más a hacerlo funcionar con cualquier pretexto, a aplastar con él toda la minoría creadora que lo perturbe -que lo perturbe en cualquier orden: en política, en ideas en industria.

Jose Ortega y Gasset
La Rebelión de las masas

Este es uno de mis libros de mesilla favoritos. Y perdón por la pedantería.

Firebug: Desarrollo Web Evolucionado

2007-01-31T17:31:00.000+01:00

No suelo dedicarme a relatar herramientas, pero ésta merece el post: FireBug ha visto la luz en la versión 1.0. Una herramienta indispensable para cualquiera que haga desarrollo web, con numerosas utilidades que nos facilitan la vida para pegarnos con JavaScript, CSSs y HTML.

Si todavía no la habeis probado, os la recomiendo encarecidamente. Eso sí, únicamente para FireFox, ¿o acaso utilizais otro navegador? :)

Conclusión inteligente

2007-01-19T12:21:00.000+01:00

No tiene desperdicio la tira de Dilbert de hoy.

- Jefe: (a la secretaria) Carol, prepara una reunión de la plantilla.
- ¿sobre qué tema?
- Planeo fusionar 6-sigma con las metodologías ágiles para eliminar la diferencia entre nuestra estrategia y nuestros objetivos.
- Vale, simplemente diré: "Pérdida de tiempo"

¿cuantos jefes son "valorados" de esa manera? ¿se lo habrán ganado a pulso, como el de Dilbert?

No tiene precio

2007-01-09T15:51:00.000+01:00

Me voy de rebajas:

comprar unos zapatos Clarks,... 65€
regalar una cazadora,... 120€

movil nuevo, descuentos del 50% en las llamadas,... !no tiene precio¡

La campaña de Euskaltel da un poco de pena, no pareces buen vasco si no te quedas con nosotros, en casa, viene a decir. Genial argumento para una compañía de telecomunicaciones. ¿y por qué no me haceis mejores precios por ser vasco? N.T.J.
Así que me voy a Orange, que no creo que sean mejor compañía, pero por lo menos esta vez se lo han ganado haciendo la mejor oferta.

PD: Para los que no seais del País Vasco esta polémica de Euskaltel-Orange no os toca ni de refilón, pero la verdad que está haciendo correr ríos de tinta (electrónica).

Dos añicos, dos...

2006-12-27T11:24:00.000+01:00

...son los que ya tiene este blog.
El año pasado ni siquiera puse un post conmemorativo de su primera onomástica, pero esta vez me apetecía reseñarlo. Al principio hablaba sobre todo de software libre, ahora de vez en cuando escribo sobre temas de metodologías también, y ultimamente escribo poco :). Pero espero que vaya a más.
Algunas de las búsquedas más raras, me encuentran...

intentando abrir una puerta en la que se han dejado las llaves puestas por dentro (aquí),
o intentado hacer helado (aquí).

Todo empezó hace dos añitos, con un sosete primer post. En Febrero de 2004 colgué en la red mi trabajo sobre nuevos modelos de negocio de soft. libre, que ha sido descargado unas miles de veces desde entonces, e iba contando cosas aquí sobre él. En Julio de 2005 este blog fue añadido a Planeta Código, una creación de Juanjo Navarro (¡gracias!), una comunidad de blogs sobre programación, y este hecho fue sin duda el que más lectores le ha proporcionado a Najaraba. En Noviembre de 2005, gracias al trabajo sobre nuevos modelos de negocio sobre soft. libre y este blog, me invitaron a una charla en Mallorca sobre software libre. Este año 2006 que termina no ha sido tan interesante en estos aspectos, la verdad que desde que nacio el "peque" le dedico menos tiempo, y sigo casi un centenar de blogs, de los que no doy abasto para llevar al día todos sus post: algunos que hoy son referencia de la blogsfera, los hemos ido viendo crecer en estos dos años, mientras otros nos hemos quedado más modestos ;)

También hubo un intento en el 2005 de poner en marcha otro blog, también idea de Juanjo, sobre niños: Locos Bajitos, pero lo fui abandonando. Ahí queda Juanjo escribiendo un post de vez en cuando.

Más personalmente, este año he cambiado de casa, y otra vez de trabajo. Voy por "mi" quinta empresa (eresMas, Reuters DSS, Editorial Aranzadi, Indaba y ahora IZFE) desde que empecé a trabajar en el año 2000 y me imagino que no será la última. Aunque me parece que el año que viene va a ser mucho más tranquilo, a no ser que me lie la manta a la cabeza y por fin me decida a instalarme por mi cuenta (se admiten sugerencias ;). Por cierto, aquella serie con la que empecé a escribir sobre como convertir las ideas en software (2, 3, 4, 5, 6, 7, 8) se quedó en "código mojado", pero quién sabe...

En definitiva, que el barrio me gusta, y no me cambio, me quedo por aquí otro añito más.

La confianza y las metodologías ágiles

2006-11-28T17:07:00.000+01:00

Llevaba varios días dándole vueltas a una idea, que acabo de plasmar en un corto comentario en este interesante post sobre los " 7 paradigmas para ser ágiles". Es algo tan sencillo como que para moverse hacia las metodologías ágiles en una empresa, la idea fundamental es la C-O-N-F-I-A-N-Z-A. Confianza .
Al abandonar paulatinamente el control basado en procesos, empiezas a confiar en que las personas desarrollarán su trabajo de la manera adecuada por que saben hacerlo y quieren hacerlo. Esto tiene numerosas implicaciones. De repente el departamento de calidad no tiene que vigilar el obligado cumplimiento de normas, procesos y burocracia. Los jefes deben confiar en sus empleados (no me gusta decir "la empresa debe...". La empresa no confía, la empresa no siente ni padece). Los empleados y jefes deben confiar en sus compañeros.Confianza en los conocimientos de los empleados, en su sabiduría y buen hacer. Confianza en la palabra de las personas. No necesitas poner exhaustivamente todo por escrito. Confías en ellos, si te dicen algo, lo harán.
Pasar a un modelo colaborativo exige confiar. Cuando en una organización se han creado los procesos para controlar el trabajo, es dificil volver atrás. Pero no debe ser imposible.
Por algo Joel Spolsky dice que hay que contratar a los mejores, únicamente en las personas en las que estés convencido.

In principle, it’s simple. You’re looking for people who are

Smart, and
Get things done.
That’s it. That’s all you’re looking for.

Así puedes confiar en ellos.
Sin duda no es un paso fácil en muchas empresas.

Existen subcontrataciones que se controlan exageradamente por que "vete tú a saber qué hacen". Pero entonces ¿por qué se les contrato? ¿se confiaba en ellas? O quizás se ha perdido la confianza a lo largo del proyecto. Entonces el problema no es controlarlas, si no volver a confiar en ellas, analizar qué se hizo mal.
O a veces hay jefes de equipo que controlan al milímetro lo que hacen sus subordinados, cargándose un exceso de trabajo que no les corresponde, y siendo un cuello de botella en el proyecto.
Incluso cuando los trabajadores no se fían del trabajo de los demás, o lo desprecian si lo han hecho en otro equipo, se ponen zancadillas al buen desarrollo de los proyectos.

¿Se puede corregir esto con normas y procesos? Pues quizás a veces sí. Pero, si queremos movernos hacia las metodologías ágiles, por que creemos que pueden ser beneficiosas en un buen número de proyectos, centrándonos más en las personas que en los procesos, el objetivo debe ser recuperar la confianza.

Actualización, para los que no soleis leer los comentarios (!¿por qué nooo?!) :)
escéptico comenta:

1.- Un Jefe de Proyecto debe ser paranoico respecto a los procesos ("Las cosas pueden fallar") pero confiado respecto a las personas ("Mi equipo saldrá adelante").
Por desgracia a veces ocurre lo contrario: se desconfía de las personas pero aun así se mantienen planificaciones irreales.
2.- Realmente los que saben realizar el trabajo son los miembros del equipo. El Jefe de Proyecto se dedica a coordinar los esfuerzos, no a repasar, revisar lo que se hace.
Por desgracia hay Jefes de Proyecto que piensan que si se pudiesen clonar ellos mismos y reemplazar a su equipo, las cosas irían mucho mejor.
3.- Un Jefe de Proyecto está solo en cuanto a sus temores pero debe escuchar y prever los de su equipo.
Por desgracia hay Jefes de Proyecto que desaniman a su equipo con su actitud.
4.- Un Jefe de Proyecto debe defender a su equipo ante su Supervisor y filtrar los aspectos negativos de éste a sus colaboradores.
Por desgracia muchos Jefes de Proyecto se quejan de los malos mimbres que les han proporcionado y hacen de mera correa de transmisión de la presión ejercida desde arriba.

2ª Actualización: Para los futboleros, Oscar me hace notar que la confianza es importante en cualquier campo (¡hasta de fútbol!): La confianza y las caderas ágiles.

La publicidad de Microsoft sobre ¿software libre?

2006-11-18T14:06:00.001+01:00

Lleva unos días saliendo este anuncio en mi bitácora, sobre Software Libre (también lo he visto creo que en Meneame alguna vez):

Y un día por curiosidad descubrí... !que se trata de un anuncio de Microsoft! Y te lleva aquí: http://www.microsoft.com/spain/hechos/default.mspx, donde te cuentan alguna historieta sobre una tal teleflora.

Ojalá estas maniobras, de "información" y competencia fuesen las únicas que utilizasen, y no la intimidación y el juego sucio del que han hecho gala hasta ahora.

Relacionado: Vivir del software libre

Bruce Lee hasta en los punteros

2006-11-16T12:57:00.000+01:00

Vía messenger, de vía email, de vía vete-tu-a-saber... Si eres programador, te toca el punterito que todos llevamos dentro.

Empty your memory,
with a free()...
like a pointer!
If you cast a pointer to a integer,
it becomes the integer,
if you cast a pointer to a struct,
it becomes the struct...

The pointer can crash...,
and can Overflow...

Be a pointer my friend...

Esta versión me ha gustado mucho... ¿cuantas más conoceis?

Un añito

2006-11-15T22:20:00.000+01:00

Y es que con esa carita no me he podido resistir a ponerle aquí.

Por qué los programadores se llevan el trozo grande del pastel (sic)

2006-11-15T08:45:00.000+01:00

Dice Joel Spolsky que hay que saber ser flexible para cambiar de contexto cuando sea necesario. Critica que en un desarrollo de un proyecto con una metodología ágil, no se fuese capaz de cambiar al programador para algo quizás más importante por no perder un día de éste en ese proyecto. Lo que parece en realidad es falta de comunicación o conocimiento, ¿qué era más importante para la empresa en ese momento? O el desarrollo del nuevo producto, o la atención al problema que ha surgido sin planearlo. Alguien tenía que decidir. En realidad creo que la crítica a las metodologías ágiles en este caso no está bien traida, pues en realidad como afirma al final el problema es del "manager"

But every decision has pros and cons and when I hear a manager who is just talking about the cons without considering the pros, that manager is not doing their job.

Sim embargo lo que más me ha llamado la atención es esta frase:

This Is Why Programmers Get The Big Bucks. The whole reason you gave them Aeron chairs, unlimited M&Ms, free catered lunches, and the kickass computers with the 30" LCDs is so they can deal with new bugs Microsoft introduced in their code by messing up a DLL that used to work.

No cabe duda de que Joel Spolsky sabe cuidar a sus trabajadores, M&Ms ilimitados :) , comidas incluidas, los mejores ordenadores... y lo que de verdad importa, una valoración excepcional del trabajo que realizan sus programadores. Sabe que su trabajo no es fácil, y lo valora. No es el primer comentario en el que Joel da muestras de saber tratar a sus empleados.
Vamos, como aquí por España, lo mismo. ¿alguién quiere seguir siendo programador toda su vida?

Arte e informática

2006-10-31T22:34:00.000+01:00

Hoy hablando con un compañero de trabajo, al que me he enterado que le gusta el diseño y las artes plásticas (echad un vistazo a su trabajo, muy interesante), he llegado a una exposición de arte que se realizó hace un año en la Facultad de Informática de San Sebastian: El Bosque Virtual. Una curiosa iniciativa. Para los que hemos pasado por ese insulso edificio es toda una alegría ver el hall de la FISS de esa guisa.
Arte e informática unidas.
Espero enterarme por adelantado si se repite otro año :)