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.

Las metodologías ágiles no es un tema muy de moda en los ambientes académicos y universitarios, puesto que el desarrollo de software no es algo que se haga de forma práctica en esos entornos (se realizan más actividades de tipo docente e investigación), por lo que el tema les sonó a todos nuevo y fresco.

Fuera de aburrir al personal, la charla, aunque larga (hora y media), abarcó muchos aspectos de lo que se refiere al desarrollo del software e incluí una visión práctica de cómo lo tengo montado en la empresa en la que trabajo.

Quizás una futura presentación la haga realizando un scrum de verdad seleccionando a algunos asistentes y proponiendo una actividad a realizar que, aunque no tenga que ver con la programación, se pueda llegar a emplear un tablero sin probleas, así como asumir los roles específicos de dueño de producto, scrum master y el resto de integrantes del equipo.

Dejo la presentación aquí:

NOTA: la presentación en sí, aunque tiene algunas diapositivas explicativas y un montón de imágenes, no aporta todo el texto que se dictó, por lo que, es muy posible que resulte incompleta, extraña y carente de sentido en algunas partes.

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.

En la Gente del Bosque y la Gente de la Montaña, el antropólogo Colin Turnbull dibuja el contraste de dos sociedades. En las montañas, los recursos eran escasos y la gente estaba siempre al borde de la hambruna. La cultura a la que evolucionaron era horrible. Las madres abandonaban a sus bebés, los entregaban a hordas de niños salvajes errantes en cuanto tenían opciones mínimas de sobrevivir. Violencia, brutalidad y traición estaban a la orden del día.

En cambio, en el bosque había plenitud de recursos. Una persona tenía solo que emplear media hora al día para cubrir sus necesidades diarias. La cultura del bosque era la imagen en el espejo de la cultura de la montaña. Los adultos compartían el cuidado de los niños, quienes eran nutridos y amados hasta que estaban preparados para cuidar de sí mismos. Si una persona, accidentalmente, mataba a otra (el crimen deliberado no se conocía), era exiliado, pero solo tenían que ir a otra parte del bosque y solo por unos meses, y la gente del bosque le llevaba comida.

Xtreme Programing es un experimento que responde a la pregunta, ¿Que pasaría si tuvieras suficiente tiempo? Ahora, no tienes tiempo extra, porque esto es un negocio, después de todo y estamos jugando a ganar. Pero si tuvieras suficiente tiempo, escribirías tests; podrías reestructurar el sistema cuando aprendieses algo; podrías hablar con muchos colegas programadores y con el cliente.

Tal mentalidad de suficiencia es inhumana, al contrario que la incesante pesadez de lo imposible, imponiendo fechas de entrega que desperdician el talento en la programación en el mundo de los negocios. La mentalidad de suficiencia es también buena para los negocios. Esta crea sus propias eficiencias, al igual que la mentalidad de escasez crea sus propios perjuicios.

Este texto explica el uso de Xtreme Programming y los beneficios que conlleva. Leyendo esta introducción, queda claro, tal y como intenta transmitir el autor, que lo que propone esta metodología, no es solo producir más rápido, sino mejor, en sentido de que los desarrolladores no terminen quemados, como suele suceder en la mayoría de los casos.

Este tipo de metodologías, contribuyen a seguir haciendo la programación divertida, incluso en el trabajo.

Agradecer a mi amigo Jonathan la ayuda en la traducción, que sin él el texto habría quedado en inglés o muy mal expresado

La semana pasada, tuvimos, en la empresa en que trabajo, la presión de entregar un proyecto de forma rápida. Pensé que, en estos casos, lo que más se necesita es, como no, la organización. No se puede estar haciendo una actividad de desarrollo entre varias personas y estar con la cabeza preguntando siempre: ¿qué queda por hacer?; así que, me lancé, cogí dos tacos de post-it, uno de tamaño normal para las partes a desarrollar y otro de tamaño más pequeño, para las tareas que hay dentro de cada una de las partes.

En la imagen se puede apreciar el cómo quedó la pared de la oficina cuando comenzamos la experiencia. Comento un poco como lo hicimos, aunque la verdad, fue algo muy básico.

Usando Scrum

Lo primero que hicimos fue localizar los grandes grupos a desarrollar. En este caso, lo que había que desarrollar, principalmente, era una interfaz web para un cliente específico. Así que nos encargamos de convertir, cada parte importante de la interfaz en un bloque de tareas.

Dentro de cada uno de los bloques (alrededor), se agrupaban las tareas que había que realizar para completar ese bloque.

Los papeles se ordenan de arriba a abajo, según su prioridad, de más alta a más baja, respectivamente. Todos ellos, a su vez, se colocan en la parte izquierda del marco que se vaya a emplear para el proyecto de scrum. La idea es que, cuando una tarea se esté realizando, se pase a una zona central y, cuando haya sido terminada, se pase a la zona derecha. Nosotros usamos la separación física existente entre vidrio y vidrio, considerando la parte central justo la línea de unión entre ambos.

¿En qué beneficia?, pues básicamente en que cuando una tarea se finaliza, todos ven que se ha finalizado y que, cuando alguien no sabe que hacer, se puede levantar y mirar las tareas que hay por realizar.

Cabe señalar dos aspectos muy importantes y a tener muy en cuenta:

• Hay que definir, y muy bien, lo que significa terminado. Ya que alguien puede considerar una tarea terminada cuando ha terminado de codificarla (sin probarla), mientras que quien la solicita, considera que se termina cuando ya no se debe de tocar más, ha sido comprobada, validada y está lista para producción.
• El scrum master es la única persona que debe de mover los papeles, así como agregar nuevos o eliminar, según se dé el caso. Esto es para controlar que, realmente, se ha terminado, como se decía antes, la tarea. Además, el hecho de agregar/eliminar tareas es una actividad muy sensible, que no se debe de dejar a todos, puesto que sino, podrían sucederse situaciones indeseables.

Y un poquito de Xtreme programming

Hay otra práctica que realizamos ese mismo día, y es la del empleo del Xtreme Programming, otra vez, a nivel muy básico. En esencia, se trataba de realizar la programación más costosa (o la que se hacía ya con sueño ) entre dos personas, una haciendo de piloto (al teclado) y otra haciendo de navegante (cabeza pensante).

Los beneficios de esta técnica fueron la velocidad a la hora de desarrollar ciertas partes, puesto que la presión que ejerce el navegante al piloto y la dinámica que se crea, hace que el desarrollo carezca de partes de inactividad y cada tarea se acabe antes.

Algunas conclusiones

Puedo decir que la valoración acerca de estas técnicas, en sus inicios dentro de la empresa, han sido muy positivas, llegándose a conseguir los objetivos deseados, por lo que seguiremos empleando dichas técnicas, así como implementando cada una de ellas de forma más completa para ganar en eficiencia y conseguir que los proyectos se puedan medir de forma más precisa en el tiempo.

Pero de eso ya contaré más adelante…

En esencia, es eso, que cada analista/programador se involucre en lo que está haciendo, llegue a un diseño y una finalidad y, sobre todo, que la información sobre lo que se hace, fluya sin que las interrupciones hagan que el trabajo se pare.

Recomiendo la lectura del documento, puesto que muestra cómo funciona Scrum, XP y algunas técnicas más, en el día a día de varios grupos de desarrollo de Scrum, de la mano de un coach y gerente, encargado de llevar a cabo el desarrollo de productos dentro de una empresa.

Yo, por mi parte, en la etapa en que me encuentro, usaré lo que buenamente pueda para hacer que mi equipo de desarrollo sea más óptimo y, sobre todo, nos divierta lo que hacemos.