Diario de Programación

Buscando y leyendo sobre metodologías ágiles en internet, no recuerdo dónde, pero me he encontrado en varias ocasiones con cosas como "Para hacer Scrum y ser ágiles hay que seguir los principios de scrum a rajatabla. Las reuniones diarias deben ser diarias y si no, no le sacaremos todo el partido a Scrum". O cosas como "En programación extrema hay que seguir estrictamente todas sus reglas. No podemos, por ejemplo, hacer programación extrema y no hacer la programación en parejas".

Este tipo de afirmaciones me lleva a pensar si no estaremos perdiendo el horizonte de las metodologías ágiles. Uno de los principios del manifiesto ágil es "Individuos e interacción frente a procesos y herramientas". En el momento que ponemos unas reglas para una metodología ágil y decimos "hay que seguirlas a rajatabla", estamos contradiciendo el espíritu de las metodologías ágiles.

Es cierto que Scrum o Programación extrema han demostrado su valía en muchas ocasiones. También es cierto que las reglas de dichas metodologías han salido como fruto de la experiencia y han demostrado ser útiles. Por ello, alguien que lleva aplicando metodologías ágiles unos pocos años y en unos pocos proyectos no es posiblemente la persona más indicada para decidir si esas reglas son buenas o no. Pero tampoco es correcto decir "hay que seguirlas a rajatabla, siempre y en todo momento".

Lo ideal, si empezamos con metodologías ágiles o las estamos usando, pero no somos gurús del tema, es que cojamos aquella metodología que creamos que se ajusta mejor a nuestros entorno y la sigamos a rajatabla. Siempre es mejor seguir reglas que sabemos han funcionado en muchas ocasiones que rechazar algunas de ellas o reinventarlas sin una buena base previa de experiencia. Más adelante, podremos aplicar en profundidad la verdadera filosofía de las metodologías ágiles, cuando tengamos experiencia en la metodología, veamos qué cosas se pueden mejorar y podamos comprobar  que efectivamente mejoran, podremos empezar a aplicar cambios. Pero debemos ser realistas, el realizar cambios y que realmente mejoren la metodología, sólo lo conseguirán unos pocos con mucha experiencia e ideas claras: los verdaderos gurús del tema.

Un sitio que me ha gustado Dos Ideas : La visión de Sistemas desde el Desarrollo. Contiene una serie de artículos interesantes y amenos de leer sobre desarrollo de software, metodologías ágiles, etc. Y lo mejor de todo, en perfecto argentino. Creo que ya tengo entretenimiento para unos días.

Uno de los valores del manifiesto ágil es valorar "Individuos e interacciones sobre procesos y herramientas". Este es posiblemente el más importante de todos ellos y quizás, el que menos en cuenta se tiene cuando se intenta implantar una metodología ágil. No por la parte de "interacciones", ya que cosas como programación en parejas, los daily scrum meeting, y demás tipos de interacciones sí se tienen muy en cuenta, sino por la parte de "individuos".

Según mi experiencia, precisamente la parte de "individuos" es la más importante de todas y sin ella, todo lo demás se va al garete.

Con la parte de individuos se quiere decir gente preparada y adecuadamente motivada, es decir, gente que sabe hacer bien su trabajo y que tiene ganas de hacerlo. Y eso es lo realmente importante. Si la gente no es técnicamente adecuada o no tiene ganas de hacer las cosas, da igual que hagan o no reuniones diarias, que trabajen en parejas, que se les den herramientas o que interaccionen con el cliente: el trabajo no sale bien.

Y eso es algo que estoy viendo continuamente en el trabajo. Según qué personas caigan en qué proyectos, estos pueden ir bien o mal, incluso aplicando la misma metodología con las mismas herramientas.

Así, hay proyectos que cuando llegan a los programadores están totalmente sin definir, no se sabe muy bien qué es lo que hay que hacer en ese proyecto, qué es lo que quiere el cliente y ni siquiera se sabe cuales son los requisitos. Mientras, otros proyectos llegan a los programadores bastante bien definidos, con una idea clara de lo que hay que hacer (aunque luego cambie) y llega con algo de documentación en condiciones, al menos, para las partes con más incertidumbre. Casualmente, las personas responsables de proyecto suelen coincidir en los casos que llega o no llega el proyecto definido. Si el responsable es "Fulanito", su proyecto llega bien definido. Si es "Menganito", no se sabe qué hay que hacer en ese proyecto.

Luego, entre los programadores, siempre hay módulos que llegan en plazo más o menos bien y sin demasiados problemas, incluso aunque esa parte no esté bien definida. Otros módulos, llegan mal y con muchos problemas, aunque estén bien definidas. Casualmente, las partes que llegan bien suelen estar hechas siempre por las mismas personas y las que dan muchos problemas, por otras. Un programador bueno técnicamente, con iniciativa y bien motivado, cuando le llega un algo para hacer mal definido, empieza a dar la paliza al responsable del proyecto para enterarse qué tiene que hacer, hace sus propias propuestas si no lo consigue, hace su código bien hecho y fácilmente modificable y finalmente entrega algo que funciona y que sirve para lo que quiere el jefe, incluso aunque el jefe no sabía qué quería. Un mal programador, sin iniciativa y sin motivación, cuando le llega una cosa sin definir, no hace nada salvo protestar y se entretiene con internet o con otra cosa. Al final, cuando la cosa corre prisa, hace lo que le puede deprisa y corriendo, lo hace mal porque técnicamente tampoco es bueno y el proyecto tiene problemas y se retrasa.

Obviamente, no debería llegar a los programadores cosas sin definir, pero aquí puedes ver que aunque el procedimiento y las herramientas sean las mismas, si se junta un mal jefe de proyecto con malos programadores, el proyecto va de culo, mientras que si se junta un buen jefe de proyecto con buenos programadores, ese proyecto suele ir de cine.

Cuando fallan las personas en una de las dos partes, la otra puede "arreglar" la situación. Ante un jefe de proyecto incompetente, los buenos programadores acaban prácticamente definiendo y llevando ellos el proyecto. Ante unos programadores incompetentes, un buen jefe de proyecto lleva mucha supervisión, define mucho las cosas, prueba mucho y sabe sacar lo máximo posible de los programadores que le han tocado.

Y todo esto es real, es lo que voy viendo en varios años de trabajar en proyectos con bastante gente, tanto de currito como llevando programadores.

No recuerdo dónde, así que no puedo poner el enlace, pero hace unos días leí en un foro a una persona que comentaba haber hecho un proyecto/programa de software y que ahora le pedían hacer la documentación del mismo. Dicha persona preguntaba por herramientas que hicieran algo de ingeniería inversa y le facilitaran el proceso de generar dicha documentación.

Ese post tenía algo así como tres mil respuestas y alguna más. Todas ellas, sin excepción y hasta donde alcancé a leer, criticaban a la persona diciendo cosas como "primero se hace la documentación y luego el código", "hay que pensar antes de codificar", "te pones a codificar a lo loco y así te va".

Bien, esa es la idea generalizada de todo el mundo. Todos "sabemos" que hay que hacer el diseño y la documentación antes que el código. Y lo hacemos porque "sabemos" que hay que hacerlo … pero ¿realmente hay que hacerlo?

La persona del foro no daba detalles en absoluto de su proyecto, pero por cosas como "he hecho" y "ahora me piden" podía perfectamente ser un trabajo de clase. No sé la envergadura de dicho programa, pero si es un trabajo de clase y no un proyecto fin de carrera, posiblemente sea un pequeño software de prácticas que se hace en unas semanas a ratos perdidos (cuando no estás en clase o estás estudiando otras asignaturas y no tienes la resaca del día anterior).

¿Por qué hay entonces que hacerle antes la documentación? ¿Por qué hay que plasmar en un papel lo que vas a hacer antes de hacerlo?

Este señor, posiblemente si pensó antes en lo que iba a hacer. Es más, ante un programa cuyo esfuerzo no se mide en hombres/mes, sino en persona/ratos libres, es perfectamente posible pensar sólo un poco la idea general antes y dejar para mientras se programa el pensar los detalles. Al ser sólo una persona y un programa pequeño, no necesita en absoluto dejar un documento oficial con su "declaración de intenciones", diseño preliminar, detallado, trazabilidad de requisitos, plan de proyecto, protocolos de pruebas…. Si lo hace, nadie nunca va a leerlo o usarlo y además se le pasará el curso. Es posible que esta persona mientras lo programa necesite consultar algo que haya apuntado previamente, pero lo había hecho en una hojilla guarra de papel, que le sirve perfectamente.

Si suponemos que el programa es para una práctica. Es decir, una vez que apruebe, nunca nadie jamás de los jamases va a volver a mirar ese programa. Posiblemente, incluso se pierda. Tampoco es necesaria en absoluto una documentación para su mantenimiento. Es más, salvo que sea con fines académicos, posiblemente el código ni siquiera necesite comentarios, que nunca nadie jamás va a leer.

Me da la impresión, sobre todo en gente con poca experiencia, que se cogen las cosas como "dogma de fé" sin pararse a pensar el por qué. Las cosas hay que hacerlas "así" porque se hacen "así".

Casi con seguridad al 100%, toda la necesidad y buenas costumbres de documentar antes de empezar el proyecto, partió de grandes empresas con grandes proyectos, plazos largos y muchos, muchos programadores involucrados. Ahí sí es imprescindible hacer una documentación seria al principio, de forma que todo el mundo tenga claro como encajan las cosas y que tiene que hacer o no hacer. Pero eso no hace en absoluto que documentar antes sea una buena práctica en TODAS las demás situaciones. Un claro ejemplo es el programa de prácticas de nuestro amigo, que posiblemente le "han pedido" la documentación como parte de su trabajo de clase, pero que no tiene ni tendrá nunca utilidad ninguna.

Y de hecho, para proyectos no demasiado grandes y con un grupo reducido de programadores, posiblemente también sea excesiva e inútil una documentación excesivamente oficial. Cuatro o cinco programadores pueden pensar en reuniones lo que van a hacer, plasmar si hace falta en papel los bloques principales de su proyecto, cómo se relacionan, y ponerse a codificar, con reuniones y pruebas de integración frecuentes. ¿no os suena de algo? Pues sí, justo lo que dicen la mayoría de las metodologías ágiles.

Cada vez estoy más escéptico con el tema de la planificación de proyectos. No me refiero a hacerla, revisarla periódicamente, rehacerla, que es "relativamente sencillo" (ni de coña, hace falta mucha disciplina y experiencia). Me refiero a hacer una planificación que luego se cumpla.

Quizás gente con experiencia en planificaciones puede planificar más o menos correctamente un proyecto que dure unos meses y con unos pocos programadores (dos, tres, quizás cuatro). Pero, en nuestro caso, estamos hablando de varios proyectos con funcionalidades similares, pero lo suficientemente distintas como para requerir modificaciones, todos en paralelo, con alrededor de treinta programadores en total y plazos de entrega de uno a tres años.

Cualquier cosa que leas de planificación que te dice que hagas tareas muy granulares, del orden de tiempo estimado de uno o dos días por tarea. Si echamos unas cuentas, treinta programadores durante dos años, con tareas de 1 día, son aproximadamente …. ¡¡Buff, ni me atrevo a calcularlo!!.

Obviamente, no se puede calcular a priori todas esas tareas. La solución supuestamente es fijar pequeñas entregas cada uno o dos meses, dividir a la gente en grupos y planificar las tareas para esos dos o tres meses. Estupendo. ¿Y el resto del proyecto? ¿Y las demás entregas?. Por supuesto, todas ellas están fatalmente planificadas, porque ni se han detallado lo suficiente, ni se tiene muy claro que es lo que se tiene que hacer. ¿De qué sirve tener perfectamente planificado el primer mes o reajustar la planificación del primer mes si no se sabe nada fiable del resto del proyecto?

Al final da la impresión de que lo que hay que hacer es tener claro qué cosas son importantes y dedicarse a ellas primero, dejando lo secundario para el final por si da tiempo. Al final es algo así como "estará lo que dé tiempo a hacer en plazo y el resto no se hace", por lo que efectivamente es importante hacer lo más importante primero para que al menos eso esté. Pero ninguna planificación nos dirá a priori cuántas de esas cosas van a estar hasta que estemos ya muy cerca del final.

Quizás hay que dividir el plazo total entre las funcionalidades a implementar y hacer entregas cada uno o dos meses con esas funcionalidades. Pero para que se cumpla el plazo total, va a haber que pasado el tiempo de la primera entrega, dejar las funcionalidades que entren en ella como estén y pasar al segundo grupo. Por supuesto, en cada momento habrá que decidir si se continúa con las que no se han acabado (a costa de quitar otras) o se dejan como están para seguir con las siguientes. En cualquier caso, NO es una planificación para que se cumpla, sino es más que nada saber cómo se va para asumir el retraso y quitar cosas.

Cada vez estoy más decepcionado con este tipo de cosas.