archivo

Archivo de la etiqueta: Ron Jeffries

Ron Jeffries, Ann Anderson y Chet Hendrickson en el libro “Extreme Programming Installed” hacen la siguiente reflexión: “Si tu cliente sabe ahora exactamente lo que quiere, y si en el momento en que haya terminado todavía va a querer lo mismo, puede ser la primera vez en la historia del software que esto ha sucedido. Probablemente habrá un premio para ti en algún sitio”.

Está bien que estos autores lo pongan en su libro pero probablemente tu propia experiencia te hará llegar a la misma conclusión.

La aparición de la agilidad y métodos de trabajo potencialmente ágiles (siempre os digo que realmente lo que la hacen ágil o no es la actitud de las personas en el proyecto) no fue un capricho, sino una respuesta a unos métodos de trabajo que no respondían a una realidad que se repetía de manera insistente en los proyectos de desarrollo de software y que se basaba generalmente en el ciclo de vida tradicional.

Pero las metodologías, marcos o estrategias de desarrollo son solo herramientas, es necesario entender el fundamento del enfoque iterativo incremental y se puede resumir perfectamente en la cita en la que se basa este artículo.

Los usuarios pueden tener claro lo que tienen (cosa que está por ver) e incluso que el contexto del proyecto se pueda mantener de forma más o menos estable y no influya excesivamente en la línea de desarrollo del producto pero lo más probable es que los usuarios vayan haciendo ajustes en su visión del producto conforme se trabaja con más detalle en el mismo y conforme van viendo versiones del producto mientras se está desarrollando o mientras se entregan sprints y eso es debido a que es muy difícil abstraer lo que se cree que se quiere, a algo concreto.

Si pese a que sois desarrolladores habéis sido usuarios (incluso vuestros propios usuarios) os habréis encontrado muy probablemente con situaciones en la que vuestra idea inicial del desarrollo ha sufrido cambios sensibles.

Avanzar no es no parar.

Ron Jeffries realizó la siguiente reflexión (traducción libre): “Cuanto de manera más frecuente nos tomemos un momento para reflexionar sobre cómo van las cosas, probablemente nos daremos cuenta más pronto en aquellas situaciones en las que nos estemos saliendo de la ruta más óptima”.

Huir hacia adelante no es la solución, ejecutar trabajo no tiene por qué acercarnos a la meta.

¿Cómo estamos?, ¿qué ha pasado?, ¿qué hemos hecho mal?, ¿en qué hemos acertado?, ¿en qué podemos mejorar?, ¿cómo podemos hacerlo?, de las medidas que tomamos anteriormente ¿qué ha funcionado?, ¿cuál ha sido su impacto real en el proyecto?.

De nada vale todo eso si no tienes la voluntad de asumir errores. Realmente ahí es donde radica la dificultad de todo, en asumir errores.

¿Comentar o no comentar?, ¿cuándo o qué comentar?. Soy de la opinión de que los comentarios en el código deben ser los menores posibles y que cuando se utilicen sea por una causa que lo justifique y que realmente aporte valor a quién lo lea.

Cuando se comenta hay que cargar con los comentarios en todo el proceso de desarrollo del software y en las fases posteriores de mantenimiento de lo contrario se darán situaciones de falta de coherencia entre comentarios y código.

Ya lo dice Ron Jeffies: “El código nunca miente, los comentarios a veces”.

Es fundamental saber hacia dónde se quiere ir, cuáles son los objetivos y esto es extensible tanto a las personas como a las organizaciones.

De lo contrario, al no tener referencias, se vive en un continuo cortoplacismo en el que los árboles te impedirán ver el bosque incluso en circunstancias que puedan resultar evidentes.

El cortoplacismo y la ausencia de referencias son muy peligrosos ya que en estas circunstancias te encuentras como un barco a la deriva.

Supongamos que tenemos objetivos, ¿qué tal si planificamos todas las acciones necesarias para alcanzarlo?. Pues que probablemente hayamos ganado en conocimiento de la situación por el análisis necesario para realizar la planificación y hayamos perdido tiempo ya que buena parte de lo planificado no servirá de nada una vez que el contexto previsto en el que se van a ejecutar las acciones varíe (y variará).

Comenta Ron Jeffries que (traducción libre): “Cómo podemos saber lo lejos que podemos llegar si normalmente no vamos tan lejos”.

Tiene razón y es uno de los riesgos de la planificación: plantear acciones sobre escenarios abstractos sobre los que no se tiene un conocimiento o un dominio concreto y sobre los que no se tiene un control.

Es por eso que resulta más adecuado el concepto de plan (planteo las acciones a realizar en mi contexto actual) y el concepto de evolución centrado en los objetivos (sé a dónde quiero llegar, probablemente no conozca el camino, pero si mido bien los pasos estaré más cerca de la meta).

El artículo publicado ayer en el que comentaba los beneficios de la refactorización, lo contextualicé con una cita de Ron Jeffries en la que venía a decir que una aplicación bien diseñada y programada de base podría convertirse en un elemento complicado de mantener si no se revisaba con la frecuencia necesaria el código, sobre todo en contextos iterativos, evolutivos o de mantenimiento del sistema.

Y es que queramos o no, si no se hace esta tarea el programa se convierte en un conjunto de parches cada uno de ellos con el sello de su programador y cada vez resulta más costoso de mantener a la vez de que se incrementarán las posibilidades de efectos colaterales.

Jeff Atwood realiza la siguiente cita que complementa perfectamente a la de Jeffries: “Si no te paras de vez en cuando (frecuentemente, en realidad) en revisar y limpiar el código que ya has escrito, terminará convirtiéndose en una gran y descuidada bola de código”.

No es necesario poner ejemplos sobre esto porque la mayoría de vosotros habréis tenido la oportunidad de padecer y sentir las consecuencias de código de baja calidad y/o parcheado. Pese a esto y como ya comenté en el artículo de ayer no se le presta en la mayoría de los casos la atención que se merece a la refactorización, algo que resulta todavía más sangrante cuando el producto que desarrollas es para tu organización ya sea de uso interno o para comercializarlo ya que en estos casos no se tiene la excusa de que el cliente no valora este tipo de esfuerzos.

La reducción de la deuda técnica y la mejora en la legibilidad del código, así como evitar la consolidación de antipatrones del tipo ancla de barco o lava seca son algunos de los objetivos principales de la refactorización.

Hay quienes incluyen la refactorización como una fase final del desarrollo de una determinada tarea y otros que la incluyen como tareas concretas. Habría que analizar qué es más conveniente en cada caso, lo que en cualquier caso resulta incontestable son los beneficios de la refactorización. Pese a ello, muchos equipos de desarrollo no la tienen en cuenta entre sus hábitos de desarrollo y muchos clientes no valoran la realización de este tipo de actividades (tal vez porque no se les ha explicado bien sus ventajas).

La siguiente cita de Ron Jeffries contextualiza perfectamente la refactorización: “La razón por la cocina es un desastre no es porque la cocina esté mal diseñada sino porque no se lavan los platos después de cada comida”.

La automatización del testing permite ahorrar importantes esfuerzos tanto para el equipo de programación como para los testers. Ahora bien, ¿dónde está el límite?, ¿conviene automatizar todo?.

Sobre esto habrá opiniones de todo tipo. La mía va muy en la línea de la que describe Ron Jeffries en la siguiente cita: “La automatización en el testing es algo bueno, eso es seguro. Pero no podemos y no deberíamos automatizarlo todo. Entonces, ¿por qué pedimos a los equipos que automaticen todos los tests?”.

Automatizarlo todo tiene un coste y además, teniendo en cuenta que el desarrollo de software es evolutivo, en cada evolución necesitaríamos de nuevo realizar ajustes en los tests automatizados. Además, el coste de automatizar la comprobación del funcionamiento de determinadas funcionalidades puede ser excesivo en sí o puesto en una balanza con los beneficios que se obtienen con dicha automatización.

¿Por qué se pide la automatización de todo? Pues porque no se evalúa la dificultad y esfuerzo que tiene realizar esa tarea. Es importante automatizar tests pero sabiendo elegir las áreas del código y del sistema de información donde se puede obtener el mayor aprovechamiento de los mismos (por su impacto y por el esfuerzo que requeriría una verificación manual) con el menos coste posible (elegir bien no es trivial).