Diario de Programación

Llevo un par de semanas trabajando con XPlanner.  En él pones las tareas que vas a realizar y la estimación de tiempos de cada una de ellas. Día a día vas poniendo el tiempo que has trabajado en ellas y para ver cómo vas te saca unos gráficos. En el eje horizontal pone los días. En el eje vertical pone las horas estimadas de trabajo y las horas trabajadas.

En la situación ideal, las horas estimadas deberían ser una línea perfectamente horizontal, es decir, has sido capaz de estimar a priori todo lo que tienes que hacer y el tiempo que te va a llevar. El gráfico de horas trabajadas debería ser una línea que empiza en cero y día a día va subiendo hasta, al final del periodo estimado -una semana en mi caso- alcanza a la línea de horas estimadas. Justo en el momento de alcanzar a la de horas estimadas, el trabajo, si todo se ha planificado bien, debería estar terminado.

Pues bien, eso es la situación teórica. Ahí va mi gráfico de esta semana pasada

Ante todo, se puede ver que no tengo ni repajolera idea de planificación. El Lunes no hice absolutamente nada de lo planificado, salvo quizás hacer la planificación, pero que no está planificada la tarea de hacer la planificación. El Martes, Miércoles y Jueves sí hice algo, pero casi todo lo que hacía eran tareas nuevas necesarias que no había previsto. Por eso la curva roja de tiempo previsto, en vez de ser horizontal, va subiendo. El Viernes fue el día que capture el gráfico y por eso no hay todavía datos -por cierto, se me olvidó apuntar el tiempo trabajado al final de la jornada-. Al final, dos conclusiones:

• No he sido capaz de prever las tareas. Cada vez que me meto en ellas, me aparecen tareas previas que hay que hacer y no había previsto.
• El tiempo de trabajo a la semana en lo planificado es más bien escaso. Tengo muchas interrupciones que me ocupan tiempo en cosas que no son de esta guerra. Como excusa, es la semana previa a navidades y tenemos muchos jolgorios asociados.

En fin, lo más importante es no desanimarse y persistir. Como propósito de año nuevo -junto con los consabidos hacer algo de deporte, ponerse a dieta y dejar de fumar-, me pondré el de aprender a planificar.

Por cierto, este es el típico gráfico de Scrum para ver como va el Sprint.

En software, hay veces que en la teoría hay unas pequeñas ideas que son muy sencillas, pero que luego, a la hora de la realidad y del trabajo día a día son realmente complejas. Ya me he topado en varias ocasiones con ellas y he visto como caigo una y otra vez en los mismos problemas que teóricamente sé y no debería caer en ellos. Pongo unos cuantos ejemplos.

El primero y más tonto, es a la hora de  hacer componentes reutilizables. Tienes, por ejemplo, que hacer un gráfico que en el eje de las x pinte el tiempo y en el eje de las y el número de veces que te llega un mensaje por un socket. Cuando te pones a codificar ves que es un simple histograma, o un gráfico x/y en el que hay una función, y decides hacerlo general. Te haces un proyecto separado de gráfico-histograma, lo codificas y lo haces general. Es capaz de dibujar cualquier función por puntos o histograma. Curiosamente para pasarle las x has llamado al método setFechaHora() y setNumeroMesajes().

Sin embargo, hacer ese ejemplo bien, también es complejo. En cierta ocasión quise hacer una especie de traductor de palabras de inglés a español. Hice un fichero de propiedades con palabra_español=palabra_ingles. Me empece a hacer la clase que leía el fichero de propiedades y ponerle método getEnInglés(), getEnEspañol(), etc. Al final me doy cuenta que es más general que todo eso, puede servir para cualquier pareja de idiomas. Así que getEnIdioma1() y getEnIdioma2(). Pero claro, es más general todavía, sirve para cualquier pareja clave-valor. Vuelvo a cambiar los métodos… y al final tengo una copia hecha por mi mismo de la clase Properties de java.

Es difícil saber hasta dónde generalizar y hasta dónde dejar como específico.

Segundo ejemplo de cosa sencilla compleja. Actualmente estoy usando XPlanner, un poco para jugar, pero tratando de tomármelo un poco en serio. Tengo muy clara la idea que hay que pensar una historia de usuario -alguna funcionalidad concreta- y ponerle tareas concretas con tiempos y demás. El problema que tengo es que siempre acabo poniendo tareas generales que no son de una funcionalidad concreta. Por ejemplo, las historias deberían ser "dar de alta usuario nuevo", "borrar usuario existente", "modificar datos de usuario", etc. Las tareas deberían ser "hacer la gui de pedir usuario nuevo"; "hacer la inserción de usuario nuevo en bd", etc. Sin embargo, tiendo a poner "gestión de usuarios de la bd", en la que incluyo alta, baja y modificación de usuario con la base de datos. Supongo que el mal es excusable en el sentido de que tratas de hacer todo lo relativo a base de datos de una sola vez. Sin embargo, aunque quieras aprovechar a hacerlo todo de golpe, eso no quita que pongas TRES tareas separadas: alta, baja y modificación de usuario. Esto, además, debe ser así, porque obliga a pensar qué es exactamente eso de "gestión de usuarios en la bd". Independientemente de que se use o no XPlanner, este es un problema demasiado habitual en cualquier tipo de planificación: no definir claramente cual es la tarea exacta que se quiere hacer.

Es difícil concretar lo suficiente las tareas a hacer.

En cuanto al tercer ejemplo, el consabido Scrum que ya he comentado varias veces. Lees la teoría y es algo muy sencillo. Sin embargo, la práctica es bastante compleja. Requiere mucha, mucha disciplina, para hacer las reuniones diarias. Se junta con el problema que comenté antes de XPlanner/planificación: los sprint deberían ser concretos y no cosas como "gestionar usuarios en la bd". Y lo que yo veo más complejo, requiere gente que colabore y con buen rollo. Hace falta motivar a la gente, que vayan a priori convencidos de que el método es útil e intenten sacarlo adelante. De nada sirve que creas tú solo en él, andes todos los días tirando de la gente para las reuniones y el día que faltas nadie mueva un dedo por seguir con el tema.

Es dificil organizar a más de uno -incluso yo conmigo mismo tengo mis problemas-.

Bueno, al final lo de Scrum se ha ido un poco al garete.

La semana pasada no hicimos ninguna reunión, en parte porque yo tuve que faltar un par de días, lo de las reuniones diarias se me hace un poco cuesta arriba, etc, etc.

Entiendo que para convocar la reunión diaria y llevarla, el Scrum Master no puede ser una persona que hace/le gusta hacer código. Aunque hay excepciones, me hace la impresión de que en general es cierto que la persona cuya mente entiende los punteros, no es una persona que grandes dotes sociales. No quiero decir que sea un inadaptado, pero posiblemente no es el tipo de persona que gusta dirigir una reunión de ocho o nueve personas … todos los días.

Otro problema que nos tira abajo es el horario flexible de la gente. Desde que llega el primero hasta que llega el último puede pasar hora y media o dos horas. Cuando llega el último, los primeros no solo están ya enfrascados en su trabajo, sino que incluso pueden que no estén en su sitio liados con otras cosas.

También es difícil coordinar los finales de Sprint. Cuando se hace la versión ejecutable, siempre hay pequeños fallos de última hora, por lo que planificar la última reunión de demo y demás es complicado. Para que esa versión entregable salga bien y a tiempo, da la impresión de que es necesario reservar uno o dos días al final del Sprint para depurar los útlimos errores. También sabemos todos que depurar errores no es algo que se pueda planificar, un error se puede encontrar y corregir en dos minutos o en dos días, según le de.

Y otro problema más es la coordinación de la gente en esas etapas finales. En los últimos días del Sprint hay quien ha terminado sus tareas, mientras que otros todavía no o está depurando detalles. ¿Qué hacemos con los que han acabado?. Normalmente no pueden ayudar en las etapas finales de las tareas de otros, ya que les son ajenas y posiblemente entorpezcan más que ayuden.

En fin, no ha salido rápido y a mí, como buen inadaptado social, no me apetece seguir con ello -tampoco veo demasiado apoyo de los demás-. Así que seguiremos con algo similar -pequeñas entregas cada cierto tiempo-, pero de una forma un poco más tradicional -preguntando de vez en cuando a cada uno cómo va-.

De todas formas, este proyecto me pillaba un poco ajeno, simplemente estoy como ayudante/asesor o cosa rara similar. Es posible que si en algún momento me toca a mí llevar un proyecto de estos de forma más directa, vuelva a intentarlo.

Scrum parece un método sencillo. Sin embargo, veo en internet que hay cursos para asesorar a empresas que quieren implantarlo y parece que es un paso previo importante. Nosotros lo hemos intentando, un grupo de ocho personas, sin curso previo ni nada. Pusimos "Sprints" de una semana, quizás algo cortos, pero el proyecto sólo va a llevar un par de meses, así que necesitamos puntos de control más frecuentes.

Ya hemos terminado nuestro primer Sprint y bueno, tengo que reconocerlo, en algunos puntos ha sido un poco desastre. Ahí van las conclusiones y los motivos.

En primer lugar las tareas a realizar esa semana no estaban demasiado definidas. Alguna sí, la más importante, pero otras eran un poco "sin definir". Cosas como que estuviera una determinada ventana, pero sin aclarar si debería funcionar completamente, en parte o de ninguna manera, sólo verla.

También había gente que estaba haciendo cosas de las semanas anteriores relativas al proyecto y se puso como tarea el acabarlas, pero sin analizar exactamente qué estaban haciendo, qué quería decir "acabarla", etc.

Las reuniones diarias no se llevaron demasiado bien -culpa mía-, ya que aunque todos comentaban qué había hecho y que iban a hacer, así como posibles problemas/ayudas, la gente era un poco reacia a decir cuánto tardarían. Supongo que en gran parte porque tampoco tenían claro cual era exactamente el alcance de sus tareas. He visto además, que esto parece afectar más a los nuevos. Una tarea sin definir claramente, quizás uno con experiencia tenga más criterio para intuir que es exactamente lo que tiene que hacer y lo que le va a llevar, pero los más nuevos, por no conocer quizás los entresijos del proyecto, no saben exactamente el alcance de lo que se les pide.

Finalmente, el desastre del Viernes. Supuestamente era el momento de hacer la reunión del final del Sprint, en la que nos autohacemos una demo de lo conseguido y comentamos la forma de trabajar para buscar mejoras. Bien, interfirió otro proyecto, en el que el Lunes viene el cliente a  pasar un punto de control, por lo que de las ocho personas del proyecto actual con Srcum, cuatro tuvieron que dedicarse en exclusiva a preparar el punto de control del proyecto viejo, precisamente las cuatro personas con más experiencia. El resultado es que el Viernes ni hubo demo, ni reunión, ni nada de nada. Eso sí, al menos se entregó la verisón al Product Owner para que hiciera sus pruebas, así que el Lunes tendremos que hacer lo que no hicimos el Viernes y empezar otro nuevo Sprint.

Espero para este nuevo Sprint subsanar los errores que he visto, aparte de los que pueda comentar el equipo en la reunión. Trataremos de convencer al Product Owner de que ponga como tareas prioritarias las que actualmente están a medias y trataremos de concretar con más detalle qué quiere decir "acabarlas". Además, el proyecto viejo estará de "punto de control" con el cliente, por lo que espero que esta semana no interfiera mucho.

Una pequeña nota final. Quizás porque yo soy un poco "asocial" y tiendo a llevarme mejor con los ordenadores que con la gente, la reunión diaria se me hace un poco cuesta arriba …

Bueno, hoy hemos hecho la primera reunión para contar a la gente de qué va Scrum -ya lo sabían más o menos, porque les fuí dando la "paliza" individualmente, así que se lo veían venir-.

Llevamos la lista de tareas que nos había preparado nuestra Product Owner, y elegimos unas cuantas para hacer en una semana. El tiempo es quizás un poco corto, pero el proyecto no tiene un plazo largo y la jefa tiene interés en ir viendo las cosas más inciertas primero. Así que estamos en ello.

La reunión fue un poco de aquella manera por varios motivos. Lo de "primera hora de la mañana", como tenemos horario flexible y no todos estamos a primera hora de la mañana, se quedó para cerca de las once. Supongo que no tiene importancia siempre que mantengamos la hora más o menos, pero trataremos de hacerlas un poco antes.

Por otro lado, yo tampoco soy ningún relación públicas, y además nos falta experiencia en estos temas. En fin, ya iremos aprendiendo. A final de semana contaré qué tal fue el mini-Sprint este….

Bueno, ya está dado el paso.

He elegido uno de los proyectos que me quedan más cercanos y en los que hay gente más joven y abierta a nuevas ideas. Son precisamente con los que puse en marcha xplanner. En fin, no dejo de pensar que este proyecto me está sirivendo para hacer experimentos …

Esta mañana he hablado con la responsable del proyecto y no me ha puesto ninguna pega, aunque ya llevo varios días dándole la paliza con el tema y supongo que se lo veía venir. Hoy se ha dedicado a meter y ordenar en xplanner las tareas a hacer y ella será la que haga de "Product Owner".

El lunes haremos la primera reunión con el "Scrum Team", para explicar todo y para decidr nuestro primer "Sprint Backlog". No tenemos figura para clara para "Scrum Master", pero supongo que yo haremos las veces uno de los que tienen más experiencia y yo, al menos mientras empezamos a poner todo esto en marcha y veamos con unos cuantos Sprint que el tema va bien. Luego seguirá solamente la otra persona y yo me dedicaré a "incordiar" en otro proyecto.

Puesto que xplanner se adapta bien a esta metodología, lo seguiremos usando. Ya hay dentro de xplanner dos iteraciones. Una de ellas ficticia que hace de Product Backlog y otra que será nuestro primer Sprint, de momento vacío. El Lunes pasaremos algunas de las tareas de la iteración ficticia al Sprint Backlog, detallaremos las subtareas y estimaremos los tiempos. El mismo xplanner proporciona un buen gráfico de avance.

Entre todas las ventajas que tiene Scrum y que se leen por ahí, pensándolo, he encontrado otra que aplica bien a nuestro caso particular. Los proyectos que hacemos suelen ser bastante grandes y una queja generalizada de los programadores es que no conocen el sistema completo. Cada uno suele centrarse en alguna parte concreta y hay otras partes que ni siquiera sabe que existen.

La reunión diaria y sobre todo, la "demo" que se hace en la reunión del final del Sprint, van a dar a todo el mundo la posibilidad de ver y enterarse de todas las partes del sistema. Todo esto en principio va a crear más sensación de equipo y más conocimiento general del sistema global. Quien sabe, quizás con eso incluso la gente trabaje más motivada, viendo como encaja su parte en el resto de todo lo demás.

Bueno, sigo dándole vueltas a Scrum. No sé muy bien cómo, pero a ver si lo puedo poner en el trabajo.

El problema no es la metodología en sí. El problema es que hay gente con la que trabajo -más de la mitad- que es gente con varios años de experiencia, que no saben ni siquiera que existe la programación extrema, las metodologías ágiles, ni saben qué es JUnit y lo peor de todo, están acostumbrados a "programación heróica", en que lo más importante es el producto a entregar y no el hacer bien el software. Acostumbramos a trabajar sin especificaciones escritas, a entregar un trabajo de varios meses a una persona y dejarle a su bola hasta que acabe, a echar muchas horas y cualquier cosa que no sea ponerse a programar YA, es perder el tiempo. ¿Por qué sacar este trozo de código a un método separado sin con copy-paste acabo antes?.

Me horroriza pensar en la cara que me pondrán algunos cuando les cuente lo de llevar una lista de tareas, reuniones diarias, e incluso, cuando les diga que hay que pensar qué vamos a hacer antes de hacerlo, que vamos a hacer test unitarios, ¿algún patrón de diseño, aunque sea pequeñito? ¿un patrón observador nada más?, ….

En fin, sigo animado con el tema, a pesar de todo -me gusta aprender cosas nuevas-. Para aclararme las ideas y dejar por escrito lo que he ido leyendo, me he hecho mi propio resumen de scrum. Aprovechando que Rodrigo Corral parece saber mucho del tema y que parece que contesta cuando se le preguntan cosas -al menos en los comentarios de su blog-, le he pedido que le eche un ojo por si he metido la pata en algo.

En cuanto a la metodología de desarrollo paralela a scrum -scrum sólo gestiona equipos, no dice cómo desarrollar el software-, no puede ser XP por el tema de programación en parejas -aunque lo propondré-. Trataré de poner una en que el primer día o dos días de Sprint se haga un poco de diseño, se haga luego el código con test unitarios. Al final también habrá que hacer algo similar a un pequeño manual de usuario y diagramas de UML. Todo esto para que vaya sirviendo de base a la documentación final que el cliente nos pide.

Como herramienta, de momento estamos con xplanner, pero no me acaba de convencer. Está todavía en una versión 0.xxx y las fechas, al menos en la versión española, me dan problemas. Tampoco parece que coja bien los decimales. Si pones una coma, lo interpreta como de miles. Si pones un punto, lo ignora. En fin, que no puedo trabajar 1.5 horas, tengo que tardar por narices 1 hora o 2 horas.

He seguido investigando un poco sobre Scrum … y mi gozo en un pozo.

Scrum no es una metodología de desarrollo tal cual la conocemos. Más bien es una forma de gestionar un equipo de forma que trabaje de forma eficiente y de tener siempre medidos los progresos, de forma que sepamos por dónde andamos. Scrum no nos dice qué pasos debemos seguir para hacer un software correcto, de hecho, Scrum podría aplicarse a tareas que no son software, como jardinería. Básicamente, Scrum consiste en fijar unos objetivos a corto plazo, reunirse todos los días para ver cómo va el tema y solucionar los problemas que salgan. La idea es que todo el equipo, día a día, no pierda de vista el objetivo a corto plazo y trabajen todos en la misma dirección.

De hecho, no recuerdo dónde, he leído que una de las ideas fundamentales de Scrum es que al salir de la reunión diaria, todos tengan claro qué van a hacer ese día. No sé a los demás, pero eso a mí me parece una cosa fundamental. Yo mismo, que normalmente tengo catorce o quince cosas que tengo que hacer, pierdo mucho tiempo bailando entre ellas, mirando una y otra, hasta que me decido por una de ellas.

Sin embargo, la programación extrema, sin embargo,  va más allá, en el sentido que dice cosas como que hay que trabajar por parejas, hacer test unitarios antes que el código, etc, etc.

Lo que si he visto, es que Scrum y XP se llevan muy bien y son complementarios. Por lo que se ve, es buena idea utilizar ambos simultáneamente. XP nos dice cómo tenemos que hacer el software y Scrum nos dice día a día si vamos bien.

En ES KAsi UN blog, veo que llevan ambas técnicas en paralelo y aunque no siguen XP estrictamente, comentan como conviven ambas. De hecho, buscando en google ambas palabras juntas -scrum y programación extrema- salen bastantes páginas al respecto.

En resumen, aunque puede estar bien aplicar Scrum para lo que vale Scrum -que la gente trabaje con un objetivo claro-, parece que hay que aplicar en paralelo alguna otra metodología, como la programación extrema.

Entre las metodologías de desarrollo nunca me han gustados las metodologías "pesadas", basadas en hacer mucha documentación, procesos, etc. Siempre me ha parecido perder el tiempo hacer tanto documento que luego en la realidad nunca se mira ni sirve para nada y ni siquiera se parece a la realidad.

Se hace el documento -un diseño UML, por ejemplo- antes del código, cuando llevas tres líneas de código ya te tienes que salir del documento porque no contempla ciertas cosas, luego no tienes tiempo -ni ganas- de rehacer el documento. Si te obligan a hacerlo lo haces de mala gana y gastas tiempo y así el infierno durante todo el proyecto.

Cuando descubrí las metodologías ágiles me llamaron muchísimo la atención desde el principio. Se basan en no hacer o hacer sólo la documentación que realmente se necesite. Suplen esa falta de documentación a base de mucha comunicación entre el equipo de programadores, jefes y clientes. Normalmente se obliga a reuniones diarias cortas para contarse cómo va todo. El software se hace a pequeños trozos cada vez y se entregan versiones con un poquito más de funcionalidad cada pocas semanas.

Una de ellas, la que más me llamó la atención y posiblemente la más conocida, es la programación extrema. Me hubiera gustado mucho aplicarla en el trabajo -o al menos, intentarlo para ver qué tal-. Pero me surge un gran problema. Aunque sí soy lo suficientemente jefecillo como para organizar el tema, no soy lo suficientemente jefe como para justificar el "gallinero" que se montaría al poner a la gente a trabajar por parejas. Seguro que me acaba cayendo alguna colleja de arriba. De todas formas, trabajamos en salas diáfanas, en las que hay fácilmente sesenta personas y no todos son programadores. La programación en parejas parece que debería requerir un sitio adecuado, como una sala en la que trabajen sólo los programadores y no muchos, o bien despachos en los que se puedan meter de dos en dos.

Investigando un poco más sobre metodologías ágiles, otra de las que se oye mucho es SCRUM. La idea es la siguiente

Se hace una lista con todas las funcionalidades que se supone que tiene que tener nuestro programa. Puede que no estén todas al principio y cómo todo método ágil que se precie, esta lista se puede ir cambiando a lo largo del proyecto. La lista se llama "Product Backlog". Cualquiera puede añadir a lo largo del proyecto funcionalidades a esa lista.

Hay una persona, llamada "Product Owner", que es el responsable final de la aplicación que se va a hacer y que tiene también la responsabilidad de ordenar la lista "Product Backlog", de forma que las funcionalidades que se pongan primero en esa lista serán las primeras que se hagan. Sólo él puede ordenar esta lista.

De la lista "Product Backlog" se eligen las primeras funcionalidades y que son las que se implementarán en el plazo concreto de tiempo, del orden de un mes. La lista de funcionalidades a hacer. Las funcionalidades elegidas se descomponen en tareas concretas y se les asigna un tiempo para hacerlas y una persona. La lista de tareas a hacer en ese plazo de un mes se llama "Sprint Backlog".

Una vez elegida las tareas de "Sprint Backlog" hay una serie de reglas básicas que se deben cumplir:

• Durante un mes se trabaja en esa lista y esa lista no se cambia.
• Al final de mes se debe tener un software listo con las tareas del "Sprint Backlog" funcionando.
• Se hace una reunión corta todos los días, de menos de media hora, en la que todos cuenten qué han hecho ayer, qué van a hacer hoy y qué problemas tienen para hacer lo que están haciendo.
• Cada día, para cada una de las tareas que se está haciendo, se vuelve a estimar el tiempo que llevará a partir de ese momento. NO el tiempo que se ha trabajado en ella, sino cuánto queda. Supuestamente, cada día debería quedar menos tiempo para acabar las tareas. Un gráfico con  los días en el eje x y la suma de los tiempos estimados para cada tarea en el eje y daría un gráfico que empieza arriba y va bajando según pasa el tiempo. Esto nos dará una idea precisa de por dónde andamos.

Y listo, SCRUM no dice mucho más, al menos hasta donde he leído de momento.

Esta sí parece una metodología fácil de aplicar. Tenemos salas de reunión y una reunión diaria corta de seis o siete personas no parece que vaya a "cantar" mucho delante de los jefes -sobre todo porque a primera hora de la mañana los jefes todavía no han llegado-. Además se ajusta muy bien al estilo de programación caótico que tenemos, de que hacemos las cosas sobre la marcha.

Trataré de ponerla en marcha, a ver qué pasa….