Archivos Mensuales: noviembre 2013

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.

 

Anuncios

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.

Probando, probando…

Hace mucho tiempo que creo que las pruebas automáticas mejoran el software que desarrollamos, algo menos pero también bastante que empece haciendo TDD y me di cuenta que es una técnica que cambia tu manera de ver del desarrollo, pero hoy es el día en el que no consigo que los equipos con los que trabajo hagan pruebas automáticas de manera regular.

Todo esto de las pruebas tiene muchas escuelas, desde los que creen que todo debe ser probado con un test escrito con antelación, a los que le ven cierto valor pero no para todo, y por último los que le ven cero de valor. Todo esto en el tono de gris que prefieras, tenemos opiniones para todos los gustos.

Ayer estuve en la reunión de Agile Norte (cambien el nombre ya!!) con  @penguinjournals y @ggalmazor, dos crack giputxis que vinieron a repartir un poco de conocimiento por Bilbao. Resulta que Guille explico que últimamente está haciendo pruebas desde la perspectiva de una arquitectura Hexagonal, sólo desde fuera del hexagono, es decir, desde fuera de la aplicación, lo que hace que sus pruebas no se acoplen a la implementación que diseña, a la orquestación entre colaboradores que diseñas para solucionar un problema. Te quedas con pocas pruebas que desde fuera prueban comportamiento (la B del BDD).  Ya había oído hablar de estas cosas en este video: TDD, where did it all go wrong, y en la discusión posterior al respecto:

Estoy de acuerdo en que en ocasiones hay cierta cantidad de pruebas que deberíamos tirar, porque están muy acopladas a la implementación, y a la larga molestan. Pero para mi el proceso de diseño de esa solución está hoy por hoy asociado a ese proceso de TDD, de ir solucionando poco a poco el problema e ir viendo como salen colaboradores, como los separo en otra clase… pequeños pasos que me ayudan a resolver el problema. Igual la directa es tirar todos esas pruebas; a largo plazo aportan poco y lo más probable es que ralenticen el desarrollo. Lo mínimo sería tirarlos cuando se detecte que empiezan a cascar sin aportar valor, aunque esa decisión es difícil.

Guillermo hablaba de un proceso de TDD más flexible, sin ceñirse a baby steps, ni a probar absolutamente todo… la verdad es que yo nunca he sido tan estricto o tan radical, según como se mire… siempre me he saltado las normas estrictamente hablando, aunque intentando no desviarme demasiado, entre otras cosas porque cuando trabajas con un framework determinado (osea, casi siempre) hay decisiones que ya están más o menos tomadas si quieres sacarle partido al framework en cuestión.

En fin, otra forma de ver la siempre complicada tarea del testing…

scbcn 2013

Una de recuperar cosas que tengo en el tintero. Hace dos meses escribí esto en un aeropuerto, y ahí se quedó, gracias a que Sublime te guarda el texto automagicamente aunque no se lo digas.

Este fin de semana he estado en Barcelona, concretamente en el Software Craftmanship Barcelona, un evento donde se ha reunido desarrolladores de todo el estado para compartir sus prácticas, sus errores, sus acierto, en resumen para intentar mejorar un poco su labor desarrollando software. Bueno, eso creo, porque yo de Craftmanship, la verdad, ni idea. Pero creo que más o menos van por hay los tiros.

En una de las sesiones hablamos de principios SOLID, nada demasiado novedoso, pero de esas cosas que es igual las veces que las mires que si vuelves a intentar ponerlas en práctica hay algo que no tenias del todo claro, o que recuerdas, o las dos cosas u otras nueva… total que hicimos la kata FizzBuzz, que es como lo más fácil del mundo, y resultaron dos cosas: Primera, que la mitad del público deserto a otra sesión tras la pausa para el café, lo que no deja de ser curioso (hay quien afirma que es para atender a otras sesiones y hacer muescas en la culata), y segunda, que nadie completo la Kata. Vale que eran iteraciones de 20 minutos, que borrabamos el código en cada iteración, que todo el mundo no tenía el mismo nivel de TDD y había que explicar cosas… pero que es la kata FizzBuzz!!

Total que dije, “bueno, habrá que hacerla después” y iterando iterando pues resulta que tiene un montón de ciencia detrás, y un montón de conclusiones que no por conocidas dejan de ser conclusiones: como extraemos colaboradores, como mejoramos la semántica, como introducir nuevos requisitos nos rompen las pruebas previas porque se solapan…

Así que he pensado en rehacerla de nuevo, guardando cada caso y escribiendo un poco de las conclusiones que saco, más que nada como ejercicio personal, obligándome a documentar un poco lo que hago y a pensar durante más de 30 segundos, que es lo que he hecho mientras la hacía en las pausas de la #scbcn, en la habitación del hotel o ahora en el aeropuerto mientras me dicen la puerta de embarque… total que ya me la dicen… a ver si lo completo 🙂 Gracias a Javier Gómez por la inspiración.

Leyes del desarrollo…

Es una charla de la CAS2013, muy recomendable. Puedes ver el video y las slides, que te servirán para poder comprender el visual recording que he hecho (pdf):

leyes

Nativos digitales, o no tanto.

Me llama la atención la facilidad con la que consideramos a todos los nacidos últimamente como “nativos digitales”, lo cual parece que les otorga todo tipo de conocimientos sobre tecnología. Para mi la realidad es bien distinta, los así llamados están acostumbrados a determinadas tecnologías porque están ahí desde que nacieron. Una revista es un ipad que no funciona, y un teléfono es táctil siempre, lo otro son antiguallas.

Pero estar habituados a la tecnología no les hace más conocedoras de esta. En realidad somos un montón los que no tenemos ni idea de como funciona por debajo toda esa tecnología que utilizamos a diario. En fin, que dejamos en manos de unos pocos el manejar un montón de cosas. Y a mi me parece que tener unas nociones básicas de lo que hace la tecnología es en estos tiempos es primordial. También me parece que la educación no avanza acorde a los tiempos, la memorización ya no tiene ningún valor (en realidad hace mucho que no lo tiene, pero ahora más) y el papel del docente debería ser más un guía pedagógico que un maestro en su papel magistral, pero creo que no acabamos de encontrar ese nuevo modelo.

Existen algunas iniciativas a nivel estatal para arreglar esto, el coder dojo Bilbao, Zagales hacklab, Nanos hacklab…  y supongo que muchos más que no conozco enseñan desde Scracth a Html5 pasando por Java, Arduino… en fin, cosas que despiertan la curiosidad de los más pequeños, para que ellos mismos sean los protagonistas de su propia formación.

¿Qué hago yo?

Los “informáticos” somos un gremio con crisis de identidad. Para empezar, el resto del mundo en general no tiene ni idea de lo que hacemos. Desde lo ambiguo del término, “informático”, que representa para la mayoría de la población alguien que puede arreglarte cualquier aparato electrónico que tengas, acabando por la fragmentación de los roles que puedes acabar desempeñando. Se puede resumir con este dialogo extraido de la charla de Xavi Gost en la CAS2013 sobre el papel de los programadores en la sociedad.

– ¿Eres informático?
– Si.
– ¿Me arreglas el vídeo?
– No.
– ¿Eres programador?
– Si.
– ¿Me programas el vídeo?
– No.

Personalmente me situo en la subespecie de informáticos que se dedican a desarrollar software, y ese es el término que utilizo. “Programador” parece que te rebaja la categoría (aunque es lo que soy), “informático” es demasiado vago, “craftmanship” no me acaba de convencer del todo aunque tiene cosas que hago o quiero hacer, “agilista” es definitivamente ambigüo y se me hace raro… Es curioso que no se definirme ni yo mismo. A veces soy programador irredento, otras veces scrum master, en ocasiones formador y de vez en cuando manager, cuando no soy capaz de transmitir que lo que nos conducirá al éxito es el equipo y su implicación, no un manager con balas de plata en la canana.

Lo que está claro es que somos un gremio que va a tener en sus manos un gran peso en el futuro, aún mayor del que tenemos ahora mismo. Todo, absolutamente todo, pasa por un ordenador, por la red, por un dispositivo móvil… y nosotros todavía no hemos llegado como se debe ni siquiera a cosas que tienen 10 años de vigencia. Todavía no hemos descubierto las mejores formas de desarrollar software, y tenemos a una gran proporción de la profesión sumida en el conformismo, el pesimismo e incluso la desidia. Incluso hacemos llamamientos de salvación…

Este mundo evoluciona tan rápido que no puedes dejar de estudiar. Como dicen los Pragmatic Programmers, es como una rueda de molino, se mueve despacio (a veces no tan despacio) pero si te atrapa no te va a soltar tan fácil. Y eso no todo el mundo está dispuesto a asumirlo, no es fácil equilibrar tiempo de trabajo y tiempo de formación, conjugarlo con tu vidad personal, para empezar porque a veces no somos ni conscientes de que hay otras cosas que podemos y debemos conocer… hay tanto para estudiar al respecto… yo diría que me he dedicado bastante y la única conclusión es que la mejora es inexorable, porque hay un montón de cosas para conocer, estudiar y mejorar tu proceso, y además cada día tenemos nuevas tendencias y herramientas.

 

Sobre métricas y TDD

(Hace tiempo escribí esto en el contexto de un grupo de estudio sobre XP, y me ha parecido bien recuperarlo)

En cuanto al tema de las medidas de productividad, o comparativas utilizando la técnica X, unas líneas al respecto con ejemplo práctico. Todo viene de este hilo de agile-spain, que habréis visto:

https://groups.google.com/group/agile-spain/browse_thread/thread/594244567daa49e6

El título original del hilo es: ¿Si utilizamos TDD cuanto tiempo adicional me supone conseguir una cobertura de X%?, lo que deriva en un debate sobre si TDD es rentable o no económicamente y:

Por un lado se menciona que no existen métricas “científicas”, sino basadas en la experiencia (evidentemente personal). Se basan en lo que Fowler define como Anecdotal Evidence, y por otro lado se mencionan algunas métricas al respecto [1]:
1. http://mattberther.com/2004/04/19/tdd-metrics
2. http://www.rodhilton.com/files/tdd_thesis.pdf

Os las resumo que son un poco largas. El primer enlace referencia a un segundo enlace donde menciona cifras de mejora y rendimiento, pero cita un tercer estudio. En este estudio con 12 desarrolladores hacen 6 parejas y les dan un problema de menos de 200 líneas (a bowling game). Ellos mismos mencionan los problemas, grupo pequeño, problema pequeño, diferente grado de experiencia haciendo TDD…

El segundo es una tésis que analiza estudios pasados.

  1. Dos grupos de control resolviendo pequeños problemas.
  2. Distintos métodos de analizar resultados: métricas en el código resultante, encuestas
  3. Mismo equipo (en IBM) comparando la primera y la septima versión de un producto (esta última con TDD).
  4. Dos casos (enfrentando dos proyectos) en Microsoft:
    • 6 developers-6,000 lines-24 man-months using TDD Vs 2 developers-4,500 lines-12 man-months without using TDD.
    • 5-8 developers- 26,000 lines-46 man-months using TDD Vs 12 developers-149,000 lines-144 man-months without TDD.

En la tesis usa varias métricas para medir cohesion, acoplamiento, complejidad… (al final Eclipse Metrics) y el estudio es (¡ojito!) una encuesta entre desarrolladores de proyectos de código abierto, mencionando el proyecto, implicación y cuanto usan TDD para codificar. Aplica Eclipse metrics a los proyectos, y cruza los resultados.

En resumen las métricas miden… pero miden cualquier cosa, porque no se puede aislar al sujeto que hace TDD ni de su experiencia, ni de su conocimiento sobre el problema… Haciendo una traducción al atletismo (que también se mencionaba en el hilo).

  • Corres hoy una marathon sin saber el recorrido. Mañana otra, pero te comes una manzana a ver que tal. La haces más rápido, ya no te pierdes. Las manzanas son buenas para la marathon.
  • Hacemos dos grupos. A unos les damos una manzana, y a correr la marathon. Unos van más rápido. Sacamos conclusiones.
  • Hacemos una carrera a relevos. Por un lado 5-8 corredores, 26km por otro lado 12 corredores, 149 km. Pueden correr a la vez (son relevos chinos). A unos les damos manzana. A ver que pasa.
  • En una marathon, les preguntas a todos a ver si les gustan las manzanas. En función de la clasificación sacas conclusiones.

Claramente las comparaciones son una idiotez supina, pero los estudios… Yo diría que las únicas métricas válidas son las que podemos hacer en nuestros equipos, a lo largo de un período largo de tiempo, aplicando diversas técnicas. Aún así están condicionadas por factores externos de todo tipo como estados de ánimo, enfermedades, aplicamos tal técnica pero también un poco de esta otra o se me olvida aquello que dijimos… pero permiten sacar conclusiones, aunque estas estén parcialmente basadas en la “evidencia anecdótica”.

Además hay que tener en cuenta eso (que no recuerdo quien lo dijo) de que los equipos de desarrollo son sistemas complejos que no se pueden llegar a entender del todo. Lo único que puedes hacer es “bailar” con ellos. Ir por aquí… y ver si te sigue, ir para allá y ver si te sigue… si no es así vuelve sobre tus pasos. Así no todos los equipos “bailan” igual, es decir, no todo funciona para todos, máxima suprema que sirve para todas las prácticas, prueba y escoge lo que te va mejor.

[1] No puedo evitar reproducir este parrafo:
> …con una búsqueda de 5 segundos he encontrado una página con métricas, Si, las que han argumentado y asegurado QUE NO EXISTEN. En el mundo real, casi todos los procesos tienen métricas que se van actualizando
año a año.

Debe ser una persona que vive en el mundo real (no como otros que viven en el irreal), pero que no se lee los enlaces que manda.

### Desde el punto de vista de la Theory of Constraints

Si nos fijamos solo en un programador programando, obviamente se tarda más. Pero el problema está en la pregunta. Siguiente la **Theory of Constraints**, la correcta sería: ¿cuanto tiempo más tarda el equipo en entregar producto? En ese caso la respuesta es: se tarda menos.

#### Pero tenemos en pensar en:

* tiempo en resolver bugs
* tiempo en entender codigo de otros miembros del equipo
* tiempo de volver a probar toda la aplicacion antes de release

Despliegue automático

Aunque pueda parecer curioso, dentro de los proyectos de desarrollo de software muchas veces se hacen a mano un montón de cosas. Entre ellas esta el despliegue de las aplicaciones en los servidores de aplicaciones web (utilizamos tecnología JEE).

Además de hacerlo a mano, empeoramos la situación obligando a hacer un parte firmado por un responsable para realizar el despliegue. Esto último es directamente una sinsorgada heredada de modelo de trabajo del siglo XIX, como si el responsable pudiera comprobar de un plumazo lo que esta haciendo al firmar el despliegue lo mismo que pasa revista a las tropas de su majestad en cinco minutos y se da por satisfecho.

Desplegar una aplicación es una de las tareas más monótonas que puedes encontrar. Generas un war o ear a partir del IDE que uses, recordando que partes debes incluir (Ejb, web…) dependiendo del proyecto, y luego copias un montón de ficheros de propiedades, http, etc… para que todo funcione. Es fácil olvidarse de algo, por ser una tarea monótona y precisamente por eso es candidata ideal para la automatización.

Últimamente lo estamos haciendo 🙂 Desde un servidor de Integración Continua (el nuestro es Jenkins), montamos el proyecto desde las fuentes del repositorio, generamos un war, copiamos ese montón de ficheros y finalmente subes al servidor todo y despliegas la aplicación. Así conseguimos varias cosas:

* No te equivocas. La máquina siempre lo hace bien.
* No te cansas. Jenkins siempre sonrie cuando le dices que te haga el favor de desplegar.
* Lo haces más. Como no te cansas y no te equivocas, no da pereza y puedes hacerlo muchas más veces.
* Te aseguras de que todo esta en el repositorio de fuentes, de que no te has dejado nada en tu máquina, y evitamos ese sindrome de “en mi máquina funciona”.
* Consecuencia de todo esto, tu ciclo de desarrollo puede ser más rápido, y en consecuencia más ágil.
Si es tan acojonante ¿por qué no lo hemos hecho antes? Tienen que darse unos requisitos que parecen básicos, pero que no lo son tanto.

* Tienes que saber lo que estás haciendo y como montas el proyecto, porque sino no puedes automatizarlo. Es sorprendente la cantidad de veces que no tenemos clara las dependencias de otras librerías, y pasos que son manuales completamente y no podemos automatizar.
* Nos da miedo lo automático, porque “si lo hago a mano estoy más seguro”. Mi reacción este argumento siempre es “Mátame camión”, porque no puedo entenderlo, pero es así. Aprende como funciona el script de despliegue, no es tan difícil.

Finalmente, el gráfico de como funciona esto de automatizar en el tiempo. Es incalculable la de horas que hemos pasado desplegando a mano.

Pelotas en la oficina

Hace tiempo que tengo problemas de espalda, y últimamente he decidido utilizar una pelota de pilates como silla en la oficina, a ver que tal me va…