archivo

Archivo de la etiqueta: buenas prácticas

Es cierto que pueden existir ciertas reglas o patrones que se repiten con una cierta asiduidad en los proyectos de desarrollo de software pero en muy pocas circunstancias se da el caso de que la receta aplicada en otro proyecto garantice el éxito en el que estás trabajando.

Sí que es bueno conocer esas experiencias, esas buenas prácticas, esos patrones, esos antipatrones, ese cuerpo de conocimiento pero sabiendo que se trata de herramientas que están a nuestra disposición si entendemos que son de utilidad para el proyecto (y no siempre lo serán).

Se trata de conocimientos y experiencias de terceros y si le vas sumando tu propia experiencia la caja de herramientas ofrecerá más posibilidades y será más precisa. No obstante y por encima de todo se encuentra nuestra capacidad de entender que cada proyecto es distinto y que cada situación puede requerir soluciones particulares.

Alguna vez he comentado en el blog que no entiendo muy bien esos casos en los que vienen empresas o consultoras a proponer la implantación de un conjunto de procesos o metodologías sin haberse preocupado en conocer las particularidades de la organización del posible cliente, como si tuvieran entre manos una talla única que encaja en todas las situaciones.

Me parece muy interesante la siguiente reflexión de Alistair Cockburn: “Si se sigue una metodología tal cual, tendrás una que se adapte a algún proyecto en el mundo, pero probablemente no el tuyo”.

En el artículo de enero de 2001 en la revista IEEE Computer, que Barry Boehm y Victor R. Basili publicaron con el título: “Software Defect Reduction Top 10 List” y que ya mencioné en la entrada: “El impacto del esfuerzo evitable“, hay otra estimación que me pareció muy interesante: “Las prácticas personales disciplinadas pueden reducir la tasa de introducción de defectos en más de un 75%”.

Boehm y Basili en su artículo indican algunos datos empíricos en la aplicación de determinados tipos de metodologías como la PSP de Watts Humphrey, si bien lo importante no es realmente que el término medio sea un 75% o no, sino que todos sabemos en base a nuestra propia experiencia que si se siguen buenas prácticas y una cierta disciplina a la hora no solo de programar sino de probar lo que se desarrolla tanto a nivel de componente, de integración y de sistema el número de errores que se introducen es mucho menor, permitiendo además, detectarlos gran parte de ellos de forma temprana.

Pese a eso, sabemos que existe un mal endémico en los desarrolladores y es que “no se prueba” y eso no es siempre problema de actitud, sino más bien un problema cultural, algo que está ahí, que parece normal y que, sin embargo, provoca un sobrecoste en los proyectos, problemas en el entorno de producción, un desgaste en las relaciones con el usuario, etc…

Alguien resolutivo no es quien te codifica antes un determinado artefacto sino quién es capaz de hacerlo, dentro de un tiempo razonable con el menor número de defectos posible. Es preferible tardar más y hacer un trabajo limpio, que hacerlo en menos tiempo y después estar arreglando problemas mucho más tiempo que el que se entendió que se ganó por hacer el desarrollo tan deprisa.

El cambio de enfoque se puede hacer de manera progresiva, incluyendo esas buenas prácticas y controles de manera paulatina, de manera que las decisiones adoptadas se vayan ajustando a lo que el proyecto necesita. Conforme se vayan consolidando, se considerarán prácticas del trabajo diario, independientemente de que haya proyectos que, por sus condiciones especiales, requieran una mayor exhaustividad.

Nuestro conocimiento y nuestra experiencia constituyen nuestro verdadero background a la hora de afrontar un proyecto de desarrollo de software y las diferentes contingencias y cambios de contexto que se van a producir en el mismo. Todo lo demás: metodología, procesos, buenas prácticas, herramientas, etc… son instrumentos que utilizaremos según convenga y que en el caso de que haya alguno de carácter obligatorio (por si se quiere armonizar algún aspecto del desarrollo entre proyectos diferentes) debe ser lo suficientemente flexible para ofrecernos el margen de maniobra necesario para poder adaptarnos a la nueva situación e incluso prever la posible existencia de excepciones cuando exista una circunstancia que lo justifique.

La repetibilidad es algo deseable, ¿por qué no querer industrializar una manera de hacer las cosas que nos permita alcanzar el éxito con una alta probabilidad?, sin embargo en el desarrollo de software donde cada proyecto es algo singular y en donde los contextos cambian es buscar una quimera.

Por tanto, la repetibilidad basada en términos absolutos es algo que deberíamos descartar de base, lo cual no quiere decir que en función de las características de un proyecto apliquemos unas estrategias de fondo que nos puedan resultar de utilidad (pero como instrumento no como un martillo de oro).

Sobre esto, Jim Highsmith opina lo siguiente: “Los agilistas creen que las buenas prácticas y procesos puede mejorar la consistencia pero que la repetibilidad es una fantasía”.

En el artículo de ayer, la cita de Andy Hunt nos invitaba a rebelarnos contra las tendencias cuando entendemos que el camino debe ser otro.

Las tendencias y/o las buenas prácticas establecidas está claro que marcan un camino y tanto error es seguirlos a ciegas como no seguirlos por sistema.

El problema, por tanto, no son las tendencias sino la forma en que nos comportamos ante las mismas.

Otra reflexión de Andy Hunt que abunda en este tema es la siguiente: “Considera siempre el contexto”. No puedo estar más de acuerdo, no existen los martillos de oro o balas de plata en términos generales porque su validez se circunscribe a contextos concretos que dependen de muchas variables (si bien, en algunos casos el dominio de contextos donde podrían tener una aplicación válida puede ser proporcionalmente alto) y además los contextos varían, algo muy frecuente en los proyectos de desarrollo de software y que caracterizan su incertidumbre inherente.

Analiza el contexto, las circunstancias del proyecto, adapta tus prácticas a eso (no hablo de tu background porque ahí la capacidad de cambio es más limitada aunque tener una actitud abierta ayuda bastante) y prepárate para adaptarte al cambio porque lo más probable es que las condiciones de partida varíen a los largo del proyecto y no solo una vez.

Uno de los grandes problemas que me he encontrado en todos los niveles del desarrollo de software y de los Departamentos TIC es la falta de predisposición de muchas personas a escuchar opiniones de terceros, sobre todo si las mismas proceden de personas que se encuentran en niveles inferiores de la jerarquía o pertenecen a otros Departamentos.

Os puedo asegurar que cualquier persona, aunque tenga una experiencia laboral de un día puede tener una idea que sume al proyecto. Lo más fácil es no escuchar o tener un filtro por el que solo admitas opiniones de determinadas personas. Escuchar más implica también trabajar más pero los beneficios de ello superan al esfuerzo invertido porque incluso aún no siendo buena la propuesta, las personas valoran que se les escuche y sentirse implicadas.

No debemos olvidar que nuestro objetivo debe ser conseguir el éxito en el proyecto y no alimentar nuestro ego.

También debemos evitar antipatrones como el “No inventado aquí“. Hay una amplia experiencia pasada en la industria, ¿por qué dejarla en segundo plano sin ni siquiera analizar la conveniencia de su aplicación?.

En el lado opuesto tenemos la confianza ciega en determinadas prácticas procedan de la experiencia de otros o de la propia. Debemos dejar de lado la aplicación de martillos de oro y balas de plata sin analizar el proyecto y su contexto.

En resumen: todos los participantes en un proyecto tienen capacidad para aportar, para ello es necesario darles voz y tener la capacidad de escuchar, por otro lado existen las buenas prácticas de la industria en diferentes campos: programación, gestión de proyectos, etc… que no se deben descartar o admitir sin pasar por un proceso de análisis de las mismas en el contexto del proyecto y por último nuestras propias prácticas que también deben pasar por ese mismo análisis.

Como el contexto del proyecto varía se trata de un proceso de revisión continua, si bien, conforme vaya avanzando el mismo se reducirá el nivel de incertidumbre (por regla general) y por tanto los cambios en nuestra estrategia o prácticas serán menores.

Conforme vayamos adquiriendo experiencia en el desarrollo de software tendremos una visión más amplia ante cualquier situación que nos encontremos en un proyecto, también de manera paradójica tendremos más asentadas unas prácticas o enfoques que limitan nuestro margen de maniobra independientemente de que esa visión nos muestre que existen otras posibilidades o alternativas.

¿Qué hacemos si la solución más adecuada parece que se encuentra fuera de los límites de nuestras buenas prácticas y/o enfoques?

Analizar si realmente es así. Si tenemos esas prácticas es por algo, son consecuencia de nuestra experiencia en diferentes proyectos y de todo el conocimiento que hemos adquirido hasta ahora.

Volverlo a analizar.

Si realmente fuéramos infalibles, no seríamos humanos, por ese motivo siempre se debe dejar una puerta abierta a otras alternativas. Llegado el punto de tomar una decisión que nos lleve a unas acciones fuera de nuestras prácticas o enfoques, si la situación nos obliga, tendremos que hacerlo (no todo vale, hay líneas rojas, pero no puedo hablaros de ellas ya que cada uno tendrá las suyas).

Si al final tenemos que salir de nuestro camino y optar por otras soluciones podrá pasar que hayamos acertado o nos hayamos equivocado, en ambos casos habremos ganado conocimiento y experiencia y lo mismo nuestras prácticas o enfoques se han consolidado todavía más o bien abarcan ahora un mayor abanico de posibilidades, en caso de habernos equivocado tendremos que afrontar las consecuencias (en cualquier caso, eso es inherente a cualquier profesión, tenemos que convivir con el éxito y con el fracaso).

Si la refactorización no forma parte del proceso quedará a la voluntad de los desarrolladores aplicarla o no.

Pero, ¿es la solución introducirla como elemento de proceso? La respuesta es difícil. Todo es mejor cuando surge de manera natural, cuando entiendes que el desarrollo de software se tiene que hacer de esa manera. Sin embargo, llegar a asumir que el código debe ser lo más mantenible e inteligible posible no es algo que se encuentra de serie en nuestro ADN.

Por mucho que nos cuenten tendremos que ser nosotros mismos los que entendamos que esta forma de trabajar es la correcta, esto se descubre a veces al poco tiempo de empezar a desarrollar, otras veces se tarda mucho más y en algunos casos no se compartirá nunca esta visión.

Refactorizar lleva tiempo pero en términos de coste/beneficio siempre será mucho más rentable hacerlo que dejar más deuda técnica sirviendo de resistencia. Sin embargo ese tiempo es el que termina muchas veces impidiendo refactorizar, ya que si te piden un Death March Project en el que en dos meses tengas que desarrollar un proyecto de seis, te dedicarás a ejecutar y ejecutar trabajo, cuanto más y cuanto antes mejor, ya que con jornadas maratonianas prácticamente todos los días, tu cabeza por muchas buenas ideas o prácticas que tenga consolidadas no querrá otra cosa que ver la luz al final del túnel.

La realidad en este caso vence al deseo natural de querer refactorizar. Esta realidad hace mucho daño a nuestro negocio pero no por ello debemos dejar de obviarla pese a que intentemos combatirla a diario.