Scrum Manager – En busca de la excelencia del Código
Raúl Herranz
Rev. 1.0

El texto es conciso y no muy extenso, por lo que se hace amena su lectura. Lo más importante, es que expone una serie de criterios para definir lo que se considera la excelencia del código, así como prácticas y técnicas para hacer que se consiga. El libro nos da un repaso a temas tan interesantes como la automatización de tareas, con lecciones tan importantes como la colectivización del código; pasando por las revisiones de código, la programación por parejas y revisiones por pares; las pruebas: unitarias, de integración, de sistema, de implantación, de aceptación e incluso regresión; y por último, pero no por ello menos importante, la refactorización, esa tarea siempre olvidada y que nos ahorra a la larga mucha deuda técnica.

Me gusta el formato del documento y su narrativa. Lo que quizá cambiaría es que está muy focalizado en sus ejemplos a entornos de desarrollo Java. Los pondría más genéricos y/o orientados a diferentes lenguajes y entornos de desarrollo.

En conclusión, un buen documento que nos permite hacer repaso de las técnicas que ya aplicamos y las que aún no hacemos para poder mejorar nuestro quehacer diario con buenas prácticas, buena metodología y buenos consejos. Gracias Raúl por este material, y sobretodo por poder disponer de él de forma libre y gratuita.

Los datos y su acceso

En un principio, me resultó curioso, el sistema de ChicagoBoss había resuelto de una forma muy elegante un problema que llevaba tiempo intentando resolver en Erlang… la definición rápida de los modelos. Para un proyecto de ChicagoBoss, un modelo puede definirse tal que así:

-module(person, [Id, Firstname, Lastname]).

Algo bastante impresionante. Agregado con la posibilidad de conectar con base de datos tan variadas como: MySQL, PostgreSQL, MongoDB, Tokyo Tyrant o Mnesia.

Un “vista”zo

Otro factor bastante curioso, la forma en la que escribir código mezclado con el código HTML en modo de tags, tal y como hacen lenguajes como Ruby (con el erb de rails), JSP, PHP, ASP… me parecía muy curioso y potente al mismo tiempo. La solución acogida por ChicagoBoss ha sido la misma que se empleó en Django (en Python):

{% for person in people %}
 - {{ person.full_name }}
{% endfor %}

El código que hace esta magia es el ErlyDTL.

Por último… los controladores

Los controladores son tan simples de generar como lo son los de Rails. Para quien no haya manejado ninguno de estos sistemas, puede que un ejemplo le resulte aclarador:

-module(book_controller, [Req]).
-compile(export_all).
 
edit('GET', []) ->
   ok;
edit('POST', []) ->
   {redirect, "/somewhere"}.

Como se puede ver, si el controlador atiende a la ruta /book/edit, si lo hace mediante método GET, se ejecutará el primer método retornando simplemente ok. Si se tratase de un formulario con método POST, entraría por el segundo método y se redireccionaría la página a la ruta /somewhere.

La capacidad de gestión de los datos entre los modelos y el paso de estos a través del controlador hacia la vista, es igual de potente que en rails, django y frameworks similares. El controlador se hace bastante simple y puede contener código más volcado al flujo de las llamadas y la lógica propia del sitio web que se desee desarrollar.

Las rutas y la administración… bonus track!

Como agregados, aunque otros frameworks similares tienen también algunas de estas facilidades, como son los ficheros de rutas, nos encontramos por otro lado con la interfaz de administración. La cual nos brinda información del entorno, la posibilidad de escribir ficheros de idioma (para traducir la web) y visualizar las rutas.

Conclusiones

Hace tiempo comentaba la potencia que se comenzaba a ver en el desarrollo de proyectos erlang para la web, ahora, cada vez es más una realidad, gracias a trabajos de tanta calidad como Nitrogen, Erlyweb o este, ChicagoBoss.

Aún no llevo el suficiente tiempo jugando con la herramienta en sí, pero me ha resultado bastante cómoda la generación del entorno (aunque algo buggy… se nota que hay que pulir aún por ahí un poco) y la documentación aún es algo escasa… no obstante, se perfila como un entorno a tener en cuenta por su versatilidad y porque ofrece cosas que en otros entornos son bastante más complejas de conseguir: escalabilidad y redundancia.

Si pensamos en las librerías, en cualquier lenguaje, ya sean módulos, paquetes u objetos, siempre alcanzamos una funcionalidad encapsulada dentro de una forma específica a la que se la puede llamar para realizar una acción. Pero esto cambia radicalmente en los frameworks, u entornos de desarrollo, ya que estos entornos, normalmente, realizan un cierto trabajo, y te permiten extender esa funcionalidad base, con ciertas reglas, a través de código que se escribe.

Se podría pensar en los frameworks como piezas de software que permiten agregar una funcionalidad extra desarrollada por el programador que usa el framework, a modo de addon, plugin o extensión. Pero no es eso. Las extensiones (o llámese como se quiera) son trozos de código, que opcionalmente se puede ejecutar en un programa completamente funcional. Como es obvio, ningún framework es completamente funcional sin agregar ningún código por parte del programador.

Por lo tanto, la inversión de control es más una base sobre la que construir un elemento, es nuestra arquitectura de soporte, mientras que la base sobre la que se programa un plugin es un elemento completo y funcional que se extiende mediante el plugin, pero que no depende de él.

Este es otro de los grandes elementos en los que se basa la Ingeniería del Software al decir que, lo importante, es la lógica de negocio o el sistema en sí que se quiere desarrollar, dejando la parte de arquitectura de soporte y el trasfondo sobre el que se ejecuta la solución al framework.

Si aún se tiene alguna duda, puede que con este ejemplo se disipen (o aumenten ), tomado del artículo de Martin Fowler comentado antes, tenemos un trozo de código en Ruby tal que así:

puts '¿Cómo te llamas?'
nombre = gets
procesa_nombre(nombre)
 
puts '¿Qué buscas?'
busqueda = gets
procesa_busqueda(busqueda)

En este trozo de código todo está bajo control, el sistema se ejecuta de forma lineal, pide la información en el momento en el que se le ha escrito y descrito y el código se ejecuta, secuencialmente, de forma predecible.

Ahora veremos otro ejemplo:

require 'tk'
 
root = TkRoot.new
nombre_etiqueta = TkLabel.new() { text "¿Cómo te llamas?" }
nombre_etiqueta.pack
 
nombre = TkEntry.new(root).pack
nombre.bind("FocusOut") { procesa_nombre(nombre) }
 
busqueda_etiqueta = TkLabel.new() { text "¿Qué buscas?" }
busqueda_etiqueta.pack
 
busqueda = TkEntry.new(root).pack
busqueda.bind("FocusOut") { procesa_busqueda(busqueda) }
 
Tk.mainloop()

Aquí hay una gran diferencia en el flujo de ejecución, ya que los mensajes se ejecutan en el orden que el framework los llama, según la interacción del usuario. En este caso, el framework controla la ventana, los eventos que se suceden sobre los elementos gráficos y, en el caso de que haya un evento, si hemos desarrollado código para atender a ese evento, es el framework el que llama a nuestro código. Eso es inversión de control.

Por mi parte he sido siempre muy comunista con respecto al código, no tengo el menor reparo en mirar, ampliar y corregir código de otras personas y dejo que los demás vean, opinen y corrijan y/o agreguen cosas a mis códigos… es la mentalidad del software libre.

Pero en las empresas ocurre lo contrario. Es muy normal, yo diría que incluso enfermizo, llegar a ver cómo cuando entras en una empresa en la que hay más de tres programadores, cómo cuando algo falla, cuando hay que hacer una nueva mejora, ampliación, adaptación, siempre dice uno en voz alta: ese código es de fulanito; indicando que ni lo va a ver, ni lo piensa modificar.

Concepto de Propiedad del Código

Eso es a lo que se refieren muchos de los autores de las metodologías ágiles. El hecho de que un código sea de alguien, es nocivo, perjudicial, para el desarrollo conjunto de aplicaciones.

Si se quiere desarrollar una aplicación, normalmente, llega hasta el programador (o programadores) que comienzan a escribir el código que hará que esa aplicación funcione. Si nos ponemos en el caso de una aplicación comercial de gestión de clientes, que se separa en modo MVC, y tenemos tres programadores que, se han segmentado y trabaja cada uno de forma autónoma en cada una de las capas, tendremos que entre ellos se comunicarán para hacer peticiones del tipo: Necesito que el modelo valide este dato; No puedo seguir hasta que la interfaz no la termine mi compañero; …

Inconvenientes y Perjuicios

Como he mencionado antes, crear parcelas en una aplicación en desarrollo, cuando es muy normal que se tengan que hacer modificaciones que influyan en todas las partes, hace que cada cambio esté guiado por conversaciones aisladas con gente del equipo que opina que eso no es suyo, que hables con otra persona que es la que lo ha hecho, etc.

Esta actitud crea incertidumbre de vistas hacia arriba, ya que un arquitecto, analista, jefe de proyecto, o director técnico, puede pensar que su desarrollo está demasiado atado a una persona, que puede irse de vacaciones durante dos semanas quedándose todo el trabajo parado, o incluso irse de la empresa, teniendo que hacer herencia de ese código a otros que tendrán que comenzar a estudiarlo.

Desde el punto de vista del programador, realmente y visto en frío, con esta actitud está solo. Es decir, ante cualquier trabajo que haya que realizar nuevo sobre su área, cada error que se produzca, cada tarea o incidencia que caiga en el trozo de código que tiene en propiedad es responsabilidad suya y solo suya, no pudiendo aprovechar la visión conjunta que puede aportar un equipo multidisciplinar.

Propiedad Comunitaria del Código

El hecho de que un código sea de un grupo (no de un individuo) hace que el código sea creado, modificado y ampliado por un equipo, por más de una cabeza pensante, por lo que dará más riqueza al código y se evitarán muchos errores, al ser más ojos los que ven ese código.

En principio, de cara a la alta esfera de la compañía, se ve al equipo de programación como un todo, cada uno puede realizar el trabajo sobre el código que se le diga que debe trabajar (por asignación), ya que es parte del equipo o grupo que lo ha creado.

Puede rotarse la delegación de su tarea (por vacaciones, marcha de la compañía, o baja laboral) en cualquier momento, puesto que sus compañeros saben lo que hacen y sobre qué lo está haciendo.

Ante un error o una incidencia, hay un grupo, un equipo, que puede revisar el código y corregirlo.

Conclusiones

Es sentido común el pensar que esto debería de ser así en todas las compañías, pero aún queda bastante en tema de educación el hacer ver a muchas personas que las cosas que hacen no son suyas, sino que son de la compañía para la que trabajan y en esa misma compañía, junto a ellas, han contratado a compañeros para hacer el trabajo más llevadero, más rápido y más profesional. Si esto no se aprovecha, entonces, no se ganará del intercambio de conocimiento entre personas que sepan más de un campo concreto, ni de la riqueza a la que puede llegar un software cuando se programa por un equipo, no por un individuo.

Dentro del tema de la calidad, visto como un amplio abanico de elementos que la conforman, nos topamos con uno bastante confuso y complejo al principio: la calidad interna.

¿Qué es la calidad interna?

Cuando se desarrolla un software, se desarrolla con una calidad medida según sus requisitos que pueden determinar su alto grado de calidad, midiendo una serie de parámetros. Pero estos parámetros no reflejan ni tienen en cuenta la calidad del proceso de creación del software en sí, ni la calidad del software escrito, solo la calidad externa, es decir, la función que realiza el software.

La calidad interna, sin embargo, mide y tiene presente la forma en la que se ha desarrollado el código de modo que pueda mantenerse (corregirse, ampliarse y adaptarse) de forma rápida y sencilla, gracias a un diseño e implementación limpia, simple y clara.

La importancia que tiene este tipo de calidad se muestra de manifiesto en varios textos como Scrum y XP desde las trincheras (de Henrik Kniberg) y algunos blogs como el de José Manuel Beas, Joseba Enjuto, una entrada de Diego Gómez en la web Dos Ideas, o incluso en el propio estándar ISO/IEC 9126.

¿Por qué es tan importante?

Para un desarrollador, la calidad interna es tan o más importante que la calidad externa, puesto que si un software hace lo que debe, pero una de cada 1000 veces no funciona, puede deberse a un fallo interno difícil de detectar que, pueda incluso verse agravado por la mala calidad con la que se ha desarrollado (diseñado o implementado) el sistema en sí.

En base a tiempo, un software desarrollado con una calidad baja o nula, puede ser desarrollado en un tiempo muy pequeño, ya que no se tiene en consideración muchos aspectos necesarios y útiles, como por ejemplo, una buena orientación a objetos, modularización del código, reutilización, algoritmos excesivamente complejos u ofuscados, etc.

Cuando, por un fallo (mantenimiento correctivo) hay que volver al código para corregir un defecto, y se detecta un error de diseño, modificar un código mal oliente, es más complicado que corregir un defecto en un código que está mejor desarrollado en base a patrones y reglas básicas de análisis, diseño o codificación.

En otras palabras: un programa con calidad interna baja es un programa que generará deuda técnica.

El libro, escrito por Kniberg y Mattias Skarin (otro personaje dentro del mundo de las metodologías ágiles), explora ambas metodologías desde el punto de vista de la comparación. Vamos, que las compara entre sí para sacar los mejor de ambas en cada elemento específico, o cada situación en la que ambas pueden emplearse.

La lectura es muy amena y está plagada de imágenes que ilustran todas las situaciones que se van sucediendo a lo largo del libro, por lo que engancha de principio a fin.

La segunda parte del libro, además, es un ejemplo, con un proyecto real, de cómo se puede emplear kanban en el mundo real. Los problemas que pueden surgir y como este grupo los solventó.

No olvido también el mencionar que está disponible la versión en castellano (y en francés) tal y como la propia página oficial del libro informa. Así como agradecer a la comunidad ágil en español que se coordinase tan bien, bajo la dirección de Ángel Medinilla, para darnos la posibilidad de poder leer tan gran obra en nuestro idioma.

Recomiendo la lectura a todos aquellos que tengan o pertenezcan a un grupo de trabajo.

Este libro (y su traducción al castellano), han supuesto una guía práctica de cómo comenzar en el desarrollo ágil tomando a Scrum como referencia y empleando, en lo que se refiere a técnicas de programación, algunos ejemplos de la metodología de Xtreme Programming.

El libro brinda la visión personal de Henri, una persona que ha estado empleando estas metodologías como consultor con muchos grupos de trabajo a lo largo de muchos años de trabajo y, gracias a ello, y a su excelente labor pedagógica, ha conseguido escribir un buen libro, claro, conciso y bastante corto para todo el material que contiene. Son libros que se leen de forma rápida y te preguntas, cuando llegas a su última hoja: ¿ya se acabó?

La metodología de la programación extrema fue acuñada por Kent Beck, como un conjunto de buenas prácticas y una forma de realizar los desarrollos, siempre basándose en dar el mayor valor al cliente, tal y cómo se supone que debe de ser siempre.

No obstante, el propio Beck sabe que esta metodología, al igual que las demás, tiene sus ventajas e inconvenientes, ya que si se intenta seguir de forma inflexible, puede resultar en que los proyectos terminen siendo, en algunos casos infructuosos. En este sentido, Beck, nos llama hacia la agilidad como una forma de sacar nuestro sentido común y emplear nuestro saber hacer, y no los procedimientos tipo que aplicar.

Buen libro, de principio a fin, enseña no solo las bases y teorías, sino que plantea, desde el comentario de cómo funcionarían equipos dentro de la metodología, escenarios de cómo se puede aplicar.

Es de agradecer que se haya publicado en castellano un libro sobre esta metodología (o técnica) de programación que es el desarrollo dirigido por pruebas (o test driven development). Casi que puedo asegurar que es el único libro escrito hasta el momento en castellano sobre este tema, que ya abordaba hace muchos años Kent Beck, en su libro Xtreme Programming Explained.

El libro de Carlos está cargado de información sobre lo que significa la programación ágil, ser ágil y las ventajas que ofrece, sobre el modelo tradicional este tipo de técnica de programación, que roza a ser incluso una disciplina, la importancia de aprender y renovarse, así como una crítica y justificación al sistema de enseñanza universitario con respecto a la informática, con el cual coincido.

Además, las aportaciones de los co-autores realizadas al libro son de gran calidad, desde el prólogo, escrito por J.M.Beas hasta el Apéndice sobre integración continua, de Fran Reyes Perdomo, así como las aportaciones y correcciones de Juan Gutiérrez Plaza y Gregorio Mena.

Lo mejor es que el libro no es solo teórico, sino que aporta muchos escenarios y ejemplos, con lo que constituye uno de los mejores libros que he leído sobre el tema en bastante tiempo. Por lo que recomiendo su lectura, de principio a fin.

Esta técnica debe su nombre a un reloj de cocina con forma de tomate (pomodoro), ya que, la propia técnica se basa en la medición del tiempo con un cronómetro, como los utilizados en la cocina.

La lista de tareas

Básicamente, hay tres artecfactos que se emplean para poder realizar esta técnica:

• Inventario de Actividades: donde habrá que recoger todas las tareas a realizar.
• Tareas para Hoy: las tareas que se han planteado para hacer hoy. El criterio para su selección puede ser la prioridad, dificultad o antigüedad.
• Registro: donde, diariamente se apuntarán las tareas realizadas, junto con los pomodoros empleados para su compleción.

La gestión del tiempo

La técnica en sí, se basa en la gestión del tiempo mediante cortos periódos de dedicación exclusiva. Esto quiere decir que, cuando se comienza un periódo, se debe de estar completamente dedicado a esa actividad hasta que suene la campana.

Para desarrollar la técnica con precisión, necesitaremos un cronómetro o un sistema que nos alerte de cuando comienza y termina un pomodoro. Como su origen indica, puede ser un cronómetro fijo y real en la mesa del trabajador (lo cual puede ser algo incómodo en una oficina con muchas personas trabajando) o uno informático como este.

Los pomodoros (entendidos como los periódos de tiempo) deben de ser de no más de 30 minutos, con lo que, lo ideal, sería tener períodos de 25 minutos, con 5 minutos de descanso y, cada 4 períodos, hacer el descanso extensible de 15 a 30 minutos.

Cada tarea puede ocupar no solo un pomodoro, sino varios, esto se registra al final en el registro, poniendo las tareas realizadas, junto con el número de pomodoros invertidos en su realización.

Las interrupciones

Cuando se está trabajando en una tarea concreta y entra otra distinta con mucha prioridad, tanto que no puede esperar al final del pomodoro actual, se anula el pomodoro en curso y se comienza otro nuevo con la nueva tarea.

Este es el punto débil, quizás, de esta técnica, ya que si la dinámica de trabajo es hacerlo con incidencias y/o peticiones, podría producirse un momento en el que ningún pomodoro pudiese completarse en ninguna tarea, con lo que, llegamos al punto de que no se usa, realmente, esta técnica.

Conclusiones

Para las tareas de desarrollo y sobre todo en proyectos, sin incidencias, esta es una gran técnica equiparable a GTD y ZTD. No obstante, si el entorno de trabajo es más orientado a eventos, a interrupciones, esta técnica no aplica, puesto que las propias interrupciones son las que van marcando los tiempos a poder aplicar.

Para saber más:

• Getting Things Done
• Zend To Done (inglés)
• The Pomodoro Technique (inglés)
• La Técnica Pomodoro en Café Bar Ágil