archivo

Archivo de la etiqueta: programación extrema

Supuestamente dentro de un proyecto de desarrollo de software todo el equipo tiene acceso al código que se está desarrollando y, por tanto, se podría considerar que existe una propiedad colectiva del mismo, sin embargo esa apreciación es más teórica que real, porque lo que suele suceder es que los desarrolladores pongan reparos en que otros toquen lo que han construido. Somos así, ¿qué le vamos a hacer?.

Considero un acierto por parte de XP que considere como práctica la propiedad colectiva del código, es decir, que se fomente que cualquiera pueda trabajar y mejorar con cualquier sección del código la hubieran desarrollado ellos o no. Y no lo comento solo por motivo de dar una mayor flexibilidad o disponibilidad al equipo, sino porque otro punto de vista generalmente suele ser positivo (por eso ese mismo enfoque de desarrollo tiene entre sus recomendaciones la programación por pares).

Para que este concepto se aplique de manera efectiva en un proyecto es fundamental el respeto. En el momento en que se pierden las formas por la solución en que una persona ha realizado un desarrollo, se empiezan a levantar muros. Y es que es fácil reirse o llevarse las manos a la cabeza por determinadas codificaciones pero realmente haríamos lo mismo si revisásemos código nuestro construido hace años (o tal vez no desde hace tanto tiempo).

También es importante no olvidar que se tiene que desarrollar con intención con propiedad colectiva o sin propiedad colectiva, es decir, no se trata de ponerme a retocar tal o cual funcionalidad o a refactorizar tal o cual clase o módulo, sin un propósito o poniendo en riesgo los compromisos que el equipo ha pactado para el sprint.

La gestión del conocimiento en una organización suele ser uno de sus puntos débiles. El día a día y la orientación exclusiva a la ejecución de los trabajos hace que queden en un segundo plano medidas orientadas a que el conocimiento no sea algo exclusivo de las personas sino un bien de la organización.

Además, muchas personas tienden a acumular conocimiento sobre determinadas materias y hacerlos estanco para los demás, creando de esta forma una parcela de poder (un cortijo) que lo haga fuerte tanto en su continuidad en la organización como en su promoción.

Es cierto que siempre habrá alguien que domine mejor una tecnología, un área de negocio o conozca mejor a un cliente, eso resulta lógico y razonable y además puede ser una ventaja importante personas tan especializadas. En estos casos lo que hay que intentar hacer es que su conocimiento llegue a más compañeros y en lo posible que lo más significativo quede registrado por escrito.

Si nos centramos en marcos de desarrollo fuertemente colaborativos como por ejemplo la programación extrema el conocimiento debería ser algo colectivo por la rotación existente de manera interna en un equipo donde una semana uno puede estar haciendo programación por pares de un módulo con una persona y la siguiente estar con una funcionalidad totalmente distinta en otro subsistema.

Jeff Sutherland en relación a la acumulación de conocimientos por parte de personas concretas opina lo siguiente: “No debe haber un tipo que acumule todo el conocimiento sobre un tema. Yo despediría a aquellas personas que tienen todo el conocimiento sobre un dominio concreto ya que no se debe tener un único punto de error”.

La utilización de tarjetas CRC (Class-Responsibility-Collaboration) es una técnica de diseño orientado a objetos propuesta por Kent Beck (introductor de la metodología de programación extrema) y Ward Cunningham (también muy conocido entre otras muchas materias, por sus aportaciones a dicha metodología).

El objetivo de la misma es hacer, mediante tarjetas, un inventario de las clases que vamos a necesitar para implementar el sistema y la forma en que van a interactuar, de esta forma se pretende facilitar el análisis y discusión de las mismas por parte de varios actores del equipo de proyecto con el objeto de que el diseño sea lo más simple posible verificando las especificaciones del sistema.

Un esquema típico de tarjeta CRC puede ser aquel en el que se indiquen los siguientes datos:

– Nombre de la clase.
– Nombre de las superclases y subclases (si procede).
– Las responsabilidades de la clase.
– Las clases con las que va a colaborar para poder realizar las responsabilidades indicadas.
– Autor, fecha, etc…

La incertidumbre en el desarrollo de software existe, es evidente, que los requisitos, contexto, usuarios, etc… cambian, y de la noche a la mañana (cuando no en la misma mañana). Que ante el cambio la respuesta debe ser adaptarnos a él, para lo cual la metodología con que se está trabajando debe tener en cuenta este detalle y en donde los stakeholders deben entender ese hecho como natural y que tiene un coste económico y que también afecta a los plazos.

Pero hay más y es el que la arquitectura y codificación del software deben facilitar el cambio. El parámetro velocity, qué determina la cantidad de trabajo que se puede abordar en una iteración depende de las buenas prácticas y de la deuda técnica que acumule el software durante el proceso de programación. No es el único factor, ya que también influye de manera importante la cualificación del equipo que está trabajando y de su experiencia en el desarrollo de este producto concreto, de la arquitectura y framework elegido, etc…

Por ese motivo las metodologías ágiles, como por ejemplo la programación extrema hacen tanto hincapié en la necesidad de que el código sea de la mayor calidad posible, lo que obliga a ir realizando periódicamente actividades de refactorización.

Cuando desde técnicas ágiles como la programación extrema (XP) se hace especial hincapié en que el mejor comentario del código es el propio código, no se hace por simple capricho sino porque la inclusión de comentarios incorpora un elemento más a tener en cuenta en el mantenimiento del software (esto no supone la prohibición de utilizar comentarios, sino la concienciación de lo que supone utilizarlos de manera que solo se utilicen cuando sea preciso y en la medida de lo posible en aquellas zonas del programa menos susceptibles a cambios).

Sobre este aspecto Dave Storer piensa lo siguiente (traducción libre): “No te dejes embaucar por los comentarios, son terriblemente engañosos. Depura solo el código”.

Elisabeth Hendrickson es fundadora de la empresa Quality Tree especializada en consultoría y coaching en calidad del software y testing. Su trayectoria profesional, desde 1984, ha estado centrada en ambas materias además de en la programación, si bien en los últimos años se ha centrado en las metodologías ágiles, concretamente la Programación Extrema.

La gran especialidad de Elisabeth Hendrickson es el testing, por lo que hay que tener muy en cuenta su siguiente reflexión (traducción libre): “He tenido exitos y fracasos con la automatización del testing. Mis mayores éxitos proceden de la aplicación de una estrategia efectiva en la utilización de las herramientas e instrumentos que se encontraban a mi disposición. Mis mayores fracasos son el resultado de la creencia en la necesidad de automatizar todo”.

Esta idea, válida en el mundo de la automatización de las pruebas, es perfectamente aplicable al desarrollo de software (adaptándola convenientemente). En demasiadas ocasiones se realizan sistemas pensando en que el usuario no tiene ni idea del negocio y se le trata de guiar en todo, implementándose unas restricciones que restan flexibilidad y añaden complejidad, provocando en muchos casos una reducción en la productividad en el uso de la herramienta y en otros el fracaso de la aplicación.

Cuando nos planteamos una estrategia de desarrollo basada en ciclos de vida iterativos e incrementales, como tenemos por ejemplo en las metodologías ágiles, se suele plantear la entrega de evoluciones del producto en períodos constantes de tiempo. Esto es lo que en algunas metodologías se conoce con el nombre de sprint.

La cantidad de trabajo que cabe en una entrega no deja de ser una combinación de estimaciones, ya que por un lado tenemos el parámetro velocity, que constituye la cantidad de unidades de trabajo que puede asumir el equipo de proyecto en una iteración (y que no podemos considerar estable, hasta que se hayan completado algunas de ellas) y por otro la estimación de esfuerzo de las diferentes historias de usuario o casos de uso que se van a implementar en este ciclo, pudiéndose utilizar para ello diferentes técnicas, como por ejemplo Planning Poker.

Contingencias en un proyecto de desarrollo de sofware puede haber muchas, así como errores en las estimaciones, por lo que no siempre será posible implementar lo previsto en cada iteración. Ante esto, hay diferentes opciones, por un lado está el overtime y será el equipo de proyecto en consenso con el cliente el que determine si merece la pena invertir ese tiempo extra, debiéndose tener en cuenta si se ha acudido recientemente al mismo.

Kent Beck cuando describe los principios y recomendaciones de la programación extrema indica que el overtime es un recurso que se debe utilizar solo en causas muy justificadas y de manera muy espaciada y yo estoy totalmente de acuerdo con él.

Otra opción será replanificar la fecha de entrega o entregar los hitos cerrados a la fecha de finalización del ciclo. La metodología en unos casos determinará qué camino utilizar. Soy de la opinión de que si las iteraciones se producen en períodos constantes de tiempo, no se debe romper el ritmo, sin embargo si no lo son, sí que se puede abrir la puerta a la replanificación.

También habrá que tener en cuenta las demandas del proyecto y el tiempo entre iteraciones. Por ejemplo, si no ha dado tiempo de corregir una incidencia y la siguiente iteración no es hasta dentro de cinco semanas, tal vez sí que habría que plantear un cierto retraso en la entrega.