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.

Es un tema polémico, posiblemente con tantas opiniones como personas, probablemente muchas de estas opiniones, incluso encontradas, tendrán parte de razón.

Desde mi punto de vista la dirección de proyectos software no debe ser vista como un elemento independiente al tipo de producto que desarrollamos, es decir, hacemos software y sabemos que este proceso presenta a lo largo de su ciclo de vida una serie de particularidades que hacen que su proceso de desarrollo sea especial y distinto a otros procesos de construcción o en general a otro tipo de proyectos.

Por tanto, al menos en el desarrollo de software, la dirección de proyectos no debería ser contemplada como algo que está por encima de todo, sino que debe adaptarse, contextualizarse y personalizarse a nuestro negocio, eliminándose interfaces o elementos de proceso artificiales que en nada benefician al proyecto.

Claro que existen buenas prácticas que pueden extender a proyectos software y no software, eso es indudable y no aprovechar el conocimiento existente puede suponer errores perfectamente evitables, ahora bien, también es un error pensar que se dispone de un martillo de oro o de una bala de plata que sirve independientemente del contexto (esto puede pasar con algunas buenas prácticas, pero desde luego no con todas).

El desarrollo de software requiere especialización y la gestión o dirección de proyectos no puede mantenerse al margen.

El término cargo cult surgió poco después de la Segunda Guerra Mundial en ciertas comunidades del Pacífico Sur donde con el objeto convocar como un Dios a los aviones que habían traído carga, regalos y provisiones durante la guerra, realizaban maquetas en madera de los mismos y simulaban pistas de aterrizaje.

Se ha establecido un paralelismo entre esa práctica y otras en el mundo de la programación, ingeniería del software y la gestión empresarial, considerándose cada una de ellas como antipatrones.

Todas ellas tienen en común la adopción de un aspecto que no se entiende, que se desconoce o que entendiéndose o conociéndose se ha incluido en una solución por el simple hecho de intentar mimetizar otra solución que ha tenido éxito en otro contexto.

En el caso de la programación consiste en copiar ciertas prácticas que podrían ser consideradas (no siempre) buenas prácticas sin saber muy bien los beneficios o ventajas que proporcionan. Esto provocará en muchos casos esfuerzo innecesario en el proyecto para incorporarlas y en otros casos incluso traerá consigo problemas (se están utilizando soluciones que no se sabe muy bien cómo funcionan o para qué sirven).

En el mundo de la programación también nos lo podemos encontrar con el propio copia y pega de código. Se sabe que este código permite realizar tal funcionalidad y lo trato de adaptar en el programa sin saber muy bien cómo funciona.

En el caso de la ingeniería del software, sucede lo mismo con la aplicación de metodologías, frameworks o tecnologías que se han visto que producen éxito en terceros (o por el simple hecho de que están de moda), sin saber muy bien qué ventajas ofrece respecto a cómo se venía trabajando hasta hora, por qué producen esas ventajas y si son adecuadas al proyecto.

En el caso de las metodologías ágiles hay mucho cargo cult, como ya comenté en el artículo: “Desarrollo de software. Ser ágil es cuestión de actitud, no de metodología“.

A nivel organizativo o de gestión de empresas el caso es el mismo. Se intentan copiar prácticas o estrategias de la competencia que se entiende que son las que les está permitiendo alcanzar un cierto éxito, sin realizar un análisis de si realmente esa conclusión es adecuada o no, de si esas prácticas se adaptan a la cultura actual de la empresa y a la tendencia del mercado, etc…

Se trata de otro antipatrón muy típico. Se dice que un sistema de información es una gran bola de lodo cuando su desarrollo no ha seguido una lógica, patrón o estructura común, es decir, no se ha respetado una arquitectura, no se ha gestionado adecuadamente el modelo de datos de la aplicación (nomenclatura no apropiada para los objetos, datos duplicados e incoherentes, etc…), no se han seguido prácticas comunes de programación y gestión de la configuración, no se han respetado buenas prácticas que minimicen la deuda técnica, se ha descuidado el rendimiento del sistema, etc…

Como podréis ver, este antipatrón se produce como consecuencia directa de la aplicación de otros antipatrones.

Se le denomina gran bola de lodo porque aunque el sistema funcione (y es cierto que aunque sea milagrosamente algunos sistemas así llegan a funcionar e incluso son aceptados por los usuarios) su mantenimiento es insufrible: requiere un gran esfuerzo (coste) y cada paso a producción de una nueva versión o un nuevo parche lo haremos con gran temor por mucho testing que hagamos, ya que el acoplamiento será tal que un cambio en un elemento podrá provocar errores hasta en el punto más insospechado de la aplicación.

¿Qué circunstancias puede llevar a sistemas de estas características? Muchas. Generalmente se tratará de sistemas en los que han participado diferentes equipos de trabajo sin existir una coordinación real o eficaz entre los mismos, en desarrollos donde los equipos de proyecto tenían una rotación alta y, como en el caso anterior, no ha existido una continuidad en la coordinación, en mantenimientos donde se han sucedido equipos distintos incluso de empresas distintas, etc…

Por supuesto, todo lo anterior se podría evitar o minimizar si además de esa coordinación, existieran unos mecanismos adecuados de control de calidad.