Mina

Ayer fuimos a cenar al restaurante Mina. No suelo comentar este tipo de cosas por aquí, pero es que fue una experiencia excepcional, tanto en lo culinario (apecto en el que no voy a entrar) como a nivel de trabajo en equipo. Tienen una modalidad de cena que consiste en cenar en la barra del bar, viendo como trabajan en la cocina, que es totalmente abierta. Y la verdad es un placer verles trabajar:

  •  Cero prisas en todo momento. Limitan el aforo del local a 25 comensales, que es el número que han visto que manejan bien, o mejor dicho, muy bien. Calidad sobre cantidad.
  • Esa ausencia de urgencia les permite cuidar el detalle a todos los niveles. Presentación de los platos, explicación de los mismos… Mucho que aprender de como no trabajar demasiado permite a la larga trabajar más y mejor, porque evitas el trabajar dos veces.
  •  Cero indicaciones. Todo el mundo sabe lo que tiene que hacer en todo momento, como mucho se susurran al oído.
  •  Coordinación visual. Tienen un tablero en el que recogen la información de como va cada mesa, lo que han servido… el menu degustación tiene 10 platos, así que más nos vale saber donde vamos en cada momento.
  • Punto extra ver al chef y propietario fregar la cocina al terminar junto con toda la brigada.
  • Colaboración, colaboración, colaboración… todo funciona con un mecanismo bien engrasado, como si estuviera coreografiada toda la actuación.

En resumen, quiero que mi equipo trabaje como estas personas, como Alvaro mismo dice, “no tengo un equipo, tenemos un comando“, un sitio en el que evolucionar y mejorar. Amén.

¿Que voy a hacer mañana? Lo mismo que ayer, seguir trabajando.

Anuncios

Contrastes

Siempre que acudo a una conferencia, evento o socialización con otros profesionales (de mi gremio o de otros), lo que me gusta encontrar son contrastes. Espejos en los que mirarte, para no verte reflejado, o al menos no completamente. Que te devuelvan una imagen nueva de ti mismo, de lo que deberías ser, o al menos tender hacia ello. Que te hagan pensar sobre ti, lo que haces y como lo haces. Que te movilicen, en definitiva.

Estos días encontré un reflejo diferente de mi mismo. Alguien que dejo un trabajo buscando ser más feliz. Me suena un poco. Y evidentemente me vi reflejado, pero distinto. Me obligo a la retrospectiva de tres semanas de trabajo en un minuto. La verdad que que ya la tenía hecha, porque he aterrizado tan de golpe en un campo de batalla donde se libra una guerra feroz, que en principio vamos perdiendo, que se me ha olvidado (un poco) porque vine. Y como terapia voy recordármelo.

Vine a ser más feliz trabajando. Vine a trabajar en un equipo autoorganizado de alto rendimiento. Vine a buscar la excelencia técnica que nos permitiera ser más efectivos desarrollando el software maximice el valor que aportamos al cliente. Vine a enderezar el rumbo de una nave que se estaba desviando, intentado transformar o al menos contribuir en ese cambio hacia equipos autoorganizados intraemprendedores. Vine a ser ágil, con TODO lo que significa.

No vine a una consultora normal, y no quiero estar en una consultora normal. Así que hagámosla especial. Un poco cada día. Empezando hoy.

Gracias, #aos2k14

Salam, agur

No me ha dado tiempo de comentarlo antes (supongo que no ha sido lo suficientemente prioritario), pero hace una semana que he dejado de trabajar para el Ayuntamiento de Vitoria-Gasteiz y he empezado en Init Services, concretamente en el area de salud con InitHealth.

Han sido un montón de años trabajando allí, y me hacía falta un cambio de aires para recuperar un poco la ilusión. Además me apetecía ver cosas nuevas, maneras distintas de trabajar en incluso objetivos nuevos: por ejemplo, hacer producto, que es parte de lo que hacemos ahora.

En todo este tiempo en Vitoria-Gasteiz (además de la costumbre de escribir el nombre completo y oficial de la ciudad) he hecho de casi todo, y he vivido de todo. he trabajado con un grupo de personal estupendas con las que he aprendido muchas cosas, e incluso la gente con la que más he discutido me ha aportado mucho tanto personal como profesionalmente.

En resumen, estoy muy agradecido a toda la gente con la que he tenido la oportunidad de trabajar en este tiempo, y aunque evidentemente dejo la oficina porque quiero, ahora mismo tengo una mezcla de nostalgia e ilusión en el alma. Para toda esa gente mi agradecimiento por todo lo vivido. Salam, agur.

¿TDD ha muerto?

Vaya liada que ha organizado DHH con su entrada, afirmando que TDD ha muerto y tal y cual… Varias personas le han contestado, y la verdad es que la discusión ha tenido momentos con un tono digamos no moderado… He leído ya algunas opiniones (Jorge, Jose) y aquí está la mía.

Hace ya mucho, mucho tiempo que acepté que los equipos (o no equipos, hablo en general) de desarrollo de software son una cosa muy, pero que muy compleja. Que lo que a mi mismo con mi mecanismo me funciona estupendamente, puede que no sea exportable al resto del mundo con facilidad. Es más diría que las personas humanas que desarrollan software son en ellas mismas un sistema muy complejo, y que a mi me gusta esto y me va bien, pero al resto del mundo no… la cuestión es que nos encanta enredarnos en discusiones sin fin en torno a mil temas (IDE, sistema operativo, editor de texto, aplicación para ver pelis…) que simplemente no tienen respuesta correcta. Hace ya muchos años, la verdad es que no recuerdo cuantos, @fxn empezó una keynote en la ya extinta conferencia Rails (escribo esto solo para que anotéis lo mayor que soy) que este tipo de discusiones mejorarían mucho si empezaran así:

“En mi opinión … “

A partir de ahí ya puedes decir lo que sea, que será cierto. Pero pretender que lo mío es la verdad absoluta y que funciona para todos, es, en mi opinión, demasiado presuntuoso.

Así que, en mi opinión, TDD está bien. Me sirve para ir definiendo el software que escribo, incluso cuando lo tengo más o menos claro, además de que como consecuencia tengo una batería de pruebas para ver si sigue funcionando como debe. Aunque también es verdad que a veces algunas pruebas son tal mierda que es mejor borrarlas.  También es verdad que para llegar a este punto me he empeñado bastante, y que no creo que sea especialmente bueno en esta disciplina (más bien bastante malo). Y a veces hay cosas que no sé muy bien como hacerlas con TDD, y no las hago así (pero al menos he pensado un rato sobre el tema).

Por otro lado, he encontrado muchas dificultades para transmitir a los equipos con los que he trabajado que no sólo el TDD, sino las pruebas automáticas son útiles. Así que es un caso claro de que lo que funciona para mí, no siempre funciona para mi equipo, no hablemos de otros equipos en otras empresas en otros paises. Creo que fue @jbrains el que dijo que con los equipos solo se puede bailar, vas para un lado y ves si te siguen, y si no pruebas otra vez (o algo así, no lo recuerdo exactamente 🙂 )

* Conste que opino que DHH es un programador excepcional y esta claro que ha hecho una cantidad excepcional de pasta programando. Eso no quita para que a veces se pueda equivocar, o no. Es lo bueno de tener ideas contradictorias, siempre tienes razón.

** He dejado esta entrada en borrador demasiado tiempo y ahora todo el mundo ha escrito sobre el tema: Aquí un resumen con un montón de referencias.

 

 

 

Predictivo Vs Ágil

Escuchando el podcast de Workos.cat sale el tema de si el desarrollo ágil es para todo tipo de proyectos (escúchalo, ellos también tienen su conclusión :). Parece evidente que no, si sabes exactamente lo que vas a hacer, como se hace y quién lo va a hacer, lo más razonable es usar una metodología predictiva. El diagrama de Gantt te va a quedar muy chulo, y encima lo vas a clavar (recordemos que sabemos el qué, el como y el quien de pe a pa, por lo que deducir el como es sencillo). No les quito la razón, pero yo opino que…

  • Es muy fácil “creer” que sabemos todo eso, cuando no lo sabemos. De hecho, nos hemos basado en que lo sabemos, o en que podemos averiguarlo rápidamente, durante décadas a la hora de hacer software.
  • Es muy fácil porque los humanos somos especialistas en distorsionar la realidad de distintas maneras: El cliente cree que sabe lo que quiere, el desarrollador cree que le entiende, el que sea que mida todo esto y lo traduzca a dinero cree que conoce la tecnología y lo puede estimar… Pero la realidad es que existen ciertas leyes en la gestión de proyectos software que insistimos en ignorar, y nos hemos dado tortazos contra esta realidad durante mucho tiempo (y aún seguimos).

Por todo esto, si crees que lo sabes todo, adelante, gestión predictiva. Pero asegúrate de saberlo todo, todo, todo.

En muchas ocasiones (2) me he encontrado con gente que ya lo sabía todo o casi todo. En la mayoría de los casos, programadores, desarrolladores, analistas o lo que seamos, que sabían más que el usuario, que se equivocan nunca o casi nunca, que hacen notar los errores ajenos más que los propios… y a los que el desarrollo ágil les parece ineficiente, “por que ya sabemos como hacerlo” (y más cosas, pero el tema es el que es). Siempre les digo lo mismo: si estamos seguros, es mucho más eficiente la gestión predictiva. Siempre pasa lo mismo (las dos veces que me ha pasado), seguimos igual, tan seguros no estaríamos.

2013

Acabo el año revisándolo a nivel global. Teniendo en cuenta algunos objetivos marcados, el 2013 ha sido el año en el que:

  • No he recaído de mis dolencias físicas. Un diez en eso, me encuentro estupendo.
  • He participado activamente en la organización de la CAS 2013, y no ha ido mal. Siempre hay margen de mejora, pero en general la sensación es buena.
  • Esto se ha llevado una gran parte de mi energía este año, así que no he hecho gran cosa en otros ámbitos.
  • He estado (por destacar algo) en la Software CrapmanShit de Barcelona. Soy efectivamente más crap&shit que CraftmanShip, pero aún así un montón de gente interesante y buenos ratos, y mucho material para pensar…
  • A nivel laboral, hacemos progresos pero muuuuuuuuy despacio. Si tengo una oportunidad en otro sitio, me gustaría aprovecharla, porque creo que me hace falta un cambio de aires, mucho tiempo para ser saludable en la administración (quizá demasiado para ser recuperable para la vida moderna).

Para este 2014 quiero:

  • ACLARARME, que tengo mucho lío.

Normas higiénicas

En el SCBN Xavi Gost habló en una sesión sobre ciertas normas que observa a la hora de programar, las llamó prácticas higiénicas.  En un hilo de Agile-Spain se han recopilado, y ahora las recojo aquí, sobre todo para no perderlas:

* Todo es privado hasta que no se demuestre lo contrario.
* Encapsular siempre las colecciones.
* No usar primitivas en los niveles altos de abstracción.
* Los métodos públicos sólo deben tener llamadas a otros métodos, nunca elementos del lenguaje y siempre deben leerse como si fuesen pseudocódigo.
* Hacer sólo programación defensiva en las interfaces públicas de nuestro API.
* Utilizar siempre el Null Object pattern a la hora de devolver referencias vacías.
* Crear wrappers para librerías externas que utilicemos.
* No propagar excepciones que no son mias y que vienen librerías o componentes externos.
* Evitar los bloques try/catch vacíos.
* No hacer métodos de clase (“static” en java). En ocasiones pueden estar justificados, pero sobre todo cuando no se tiene experiencia en OO se tiende a abusar de ellos y se termina con código que en realidad es más procedural que OO.
* Un nivel de indentacion por método. Este esta claro porque ¿no?.
* Solo usar herencia de implementación como ultimo recurso y nunca más de un nivel de herencia.
* Preferir siempre composición, esto nos obliga a poner el foco más en el paso de mensajes entre objetos que en construir jerarquias de objetos.
* 3 parametros por método como máximo. Obliga a construir ValueObjects para modelar conceptos que a menudo están “desperdigados” por nuestro código.

Inceptions

El pasado miércoles asistí a la reunión mensual de Agile Norte, en la que se hablaba del Inception deck (gracias a Iñaki Elkoro y Gorka Armentia). Resumiendo mucho es una técnica para arrancar un proyecto de manera ágil (más información en el artículo enlazado). Para mí tiene varias ventajas sobre las técnicas más tradicionales (que como en otras ocasiones suelen ser una mezcla de nada y alguna metodología, tipo CDMLDAE (Como Dios me lo dió a entender)), que os paso a comentar. En realidad lo siguiente es una mezcla de mis reflexiones al respecto con comentarios que se hicieron durante la charla, mi propio refrito de todo:

  • Involucran a mucha gente (idealmente a todos los interesados) en el mismo espacio-tiempo, con lo que se suelen provocar discusiones varias porque cada uno entiende las cosas a su manera, y a veces estos malentendidos se mantienen hasta estadios muy avanzados del proyecto. Provocar estas discusiones por medio de las distintas herramientas que te proporciona el inception es bajo mi punto de vista más que saludable. Tiene otro efecto, y es que en estos casos no puede “tener razón” todo el mundo. Saber desde el primer momento que no eres infalible, y lo que es más, que no pasa nada y que es habitual que suceda es también muy saludable. Además es bastante acongojante que no lo sepamos ya, pero es increíble  la cantidad de personas que no son conscientes de que se pueden equivocar, incluso se van a equivocar seguro.
  • Proporciona un mapa de como va a discurrir el proyecto. Esto depende un poco de como lo plantees, porque a la hora de definir el detalle de lo que incluimos o no en el proyecto la cosa puede quedar un poco, digamos deficiente. Yo lo que he empezado a hacer últimamente es complementar la inception con unas sesiones de “Story Mapping” para tener un mapa más concreto de por donde vamos a ir. No me voy a liar a explicar la técnica (más sobre Story Mapping), quizá otro día.
  • Permite empezar más o menos igual a todos. Un problema con el enfoque tradicional de recogida de requisitos es que después los ingenieros ya lo tenemos todo solucionado en nuestra cabeza (entre otras cosas porque es el objetivo), no existe el diseño emergente y es cuasi-imposible meter baza en como lo vamos a solucionar, aunque la propuesta sea buena. Si nos pillas un poco desprevenidos somos más receptivos a propuestas, aunque nuestra mentalidad hace que nos pongamos un poco nerviosos por ponernos a hacer cosas sin tener todos los puntos sobre las íes. Esto no deja de ser realmente curioso, porque luego lo normal es cambiar todos esos puntos de sitio, pero si no están sentimos un estremecimiento en la fuerza.

También hay algunos puntos en los que hacemos cosas un poco distintas… dadas nuestras distintas circunstancias 🙂

  • Normalmente cuando hacemos esto, el proyecto se va a hacer. En principio no existe la posibilidad de no hacerlo. Digo en principio porque para mi si existe la posibilidad de que no se haga, si el resultado de la inception nos dice que no es recomendable, o al menos de replantearnos cosas, esta parte si, esta no. Esto difiere un poco del planteamiento original, cuando la inception es clave en saber si el proyecto se lleva a cabo o no.
  • Tampoco hacemos valoraciones económicas, lo cual simplifica el proceso, porque es un tema delicado. Cuando me llega, el proyecto ha sido ya tasado económicamente (perspectiva guapa, ¿eh?) y hacemos lo que podemos. Normalmente el tiempo y el dinero han sido fijados, pero podemos jugar con el alcance y si la cosa va bien no suele haber problemas con estirar un poco el tiempo, lo cual nos da posibilidades para casar las cosas de manera satisfactoria.
  • Normalmente a estas alturas ya tenemos incluso el equipo conformado (aunque con posibilidades de ser modificado en función de las necesidades), asiste todo el mundo a la inception. A veces el equipo de desarrollo no aporta demasiado, pero recibe un montón y sólo asistir le involucra mucho en el proyecto.
  • Algunas cosas no las hago, como diseñar la caja de producto. Aunque veo valor en diseñar la caja del producto, la verdad es que me parece una dinámica a la que se le ve poco valor, me suelo quedar en proponer las ventajas y un eslogan.

Dicen que es una reunión muy cara porque tiene que asistir mucha gente importante, y cuesta dinero tenerles juntos durante mucho tiempo. Yo diría que sale relativamente barata, porque minimiza muchos riesgos y maximiza la posibilidad de éxito. Es un argumento ganador, porque si no estás de acuerdo no tengo muy claro el sentido de hacer una reunión muy cara que no sirve, aunque si puede existir en algunos ámbitos dificultad para justificarla.

En resumen, una manera de comenzar con un proyecto de manera ágil, que nos permite consensuar objetivos, alcance (aunque sea a muy alto nivel), compartir conocimiento en torno al proyecto y en definitiva, dar el banderazo de salida intentando al menos que todos esperemos cosas parecidas en un rango de tiempo similar.

Si estás interesado la técnica aparece descrita en el Agile Samurai, y existe otro libro dedicado exclusivamente a la técnica: Agile Inceptions.

Actualización:

Me apuntan en los comentarios un par de enlaces interesantes:

Be code – Le petit inception

Be code – Le petit inception II

Fin del Nanowrimo my way

Un mes, 30 días consecutivos escribiendo una entrada en este blog. Son ahora mismo las 23:37 del día 30 de noviembre, lo que quiere decir que acabo a tiempo con la escritura de estas 30 entradas, aunque en algunas ocasiones he escrito las entradas con dos o tres días de retraso.

¿Conclusiones? Que es una labor complicada de compaginar con la vida diaria, aunque es evidente que podría escribir mucho más de lo que escribo, porque en este mes he escrito más entradas que en los últimos seis años. Aunque la pregunta clave es si tengo algo que merezca la pena ser compartido, porque otra conclusión es que soy un coñazo que habla más que nada sobre desarrollo de software ágil, lo que probablemente interesa al 0,0000001% de las personas humanas. Y esto me lleva a una tercera conclusión (aunque esto ya lo sabía), y es que escribo para mi mismo. Para recordar determinadas cosas, para poder releer dentro de unos años algunas reflexiones que quizá me parezcan ingenuas, o quizá me sorprenda lo listo que era (casi seguro que no), o simplemente comprobar que la mayoría de los enlaces no van…

En fin, veremos cuanto tiempo pasa hasta la siguiente entrada.

 

Desarrollo ágil en la administración pública

Buscando información sobre el estado del arte en la administración pública en cuanto a desarrollo ágil, me encuentro con este artículo de Juan Palacios. Viene a decir que el desarrollo ágil en la administración en imposible. La verdad es que tiene cierta razón. La administración pública es un entorno hostil para la filosofía ágil, pero la verdad es que no estoy de acuerdo con las razones que da. En concreto da cuatro razones que me voy a permitir copiar aquí, y comentar entre líneas:

– En el marco ágil se paga por un esfuerzo, pero no por un resultado concreto. Esto no puede funcionar en la Administración.

¿en el marco ágil paga por esfuerzo? Otra cosa será que se juegue con el alcance, pero produce un resultado más allá del esfuerzo.

– Los departamentos se gestionan con presupuestos aprobados y cerrados para obtener resultados concretos.

Estos resultados concretos son en realidad una falacia, yo creo que son más resultados imaginados. Partiendo de la premisa de que es muy difícil caracterizar un producto software a priori, el resultado será por definición no igual a ese resultado concreto que se busca. Yo diría que más bien se tiene una idea concreta del problema a solucionar, no de la solución.

– La Administración está obligada por ley a seguir reglas de contratación abierta, lo que significa comparar diferentes licitadores sobre una base de igual a igual y decidir la mejor relación calidad-precio. La agilidad no da por adelantado ni una descripción detallada del resultado, ni un precio cerrado. ¿Cómo cumplir con el requisito legal de que los contratos públicos son justos y abiertos?.

Igual igual que se cumple ahora por parte de los proveedores clásicos. Decir que vale, que se hará, cuando saben positivamente todas las partes que habrá cambios, modificaciones en el alcance… pero ya lo veremos cuando estemos delante. También se puede dar esa descripción detallada del resultado que TODOS sabemos que es mentira. Otra opción es intentar sacudirnos la burocracia absurda, aunque claramente es la más difícil.

– La administración opera con un modelo de toma de decisiones centralizado hacia arriba, mientras que la agililidad se basa en la autonomía y la delegación de decisiones hacia abajo. Esta es la clave para que pequeños equipos descentralizados puedan reaccionar con rapidez y adaptarse a nuevos escenarios.

Efectivamente, esto es así. Habrá que trabajar para modificarlo, y eso no quita para que las decisiones desde arriba deban ser (y son) asesoradas desde abajo, desde la parte técnica que conoce el día a día, realidad que habrá que conjugar con otro tipo de razones e impedimentos para tomar las decisiones correctas.

Pero para mí el mayor impedimento es la cultura. La cultura de la administración es resolver todo por la vía de la normativa, el decreto, el procedimiento administrativo, en resumen, la cultura de la desconfianza y de la ineficiencia. Papeleo por triplicado y comprobaciones múltiples que aseguran… que se rellenan los papeles tres veces y se comprueban las cosas múltiples ocasiones, pero no que el objetivo se cumple. Porque para que alguien haga algo de manera eficiente y bien, lo primero que tiene que suceder es que este convencido de ese es el modo correcto de hacer las cosas, no que alguien vía normativa se lo imponga. Y eso es algo que no tenemos nada claro en la administración pública.