Page 50

P

MÉTODOS

¿Cuál es el Algoritmo del Éxito? UNA REFLEXIÓN SOBRE LA METODOLOGÍA EN EL DESARROLLO DE SOFTWARE — Por Marco A. Dorantes

Crear una solución basada en software es algo que puede conseguirse sin necesidad de poner mucho énfasis en la metodología ejercida; hay casos así. Pero también hay casos en que el éxito de una solución previa provoca el aumento de la demanda por mayor funcionalidad y más soluciones a una mayor diversidad de problemas. La complejidad aumenta conforme se incrementa la funcionalidad de los sistemas así como el número de proyectos simultáneos. La dificultad para repetir los logros previos aumenta en la medida en que se encuentran situaciones distintas y nuevas. El costo, tiempo y esfuerzo para mantener una pauta constante de entregas exitosas suelen aumentar con relativa rapidez si la complejidad no es administrada. Además, la calidad empieza a disminuir o verse afectada debido a los atajos que suelen tomarse en los intentos por lograr más entregas. A menor calidad, más defectos; por lo que aumenta el tiempo, costo y esfuerzo para entregar, y se entra en una espiral descendente hacia posibles cancelaciones de proyectos y pérdida de clientes y personal interno. En algún punto en tal travesía, tarde o temprano suele mencionarse la necesidad de “una metodología” que supuestamente ayude a aliviar o evitar tanto los dolores de parto de entregas futuras como también los crecientes dolores de sustentabilidad en producción de entregas previas. En ese punto, incluso, suele mencionarse la necesidad de estrategias para lograr una cultura de “ingeniería de software”. Muy bien por tan buenas intenciones en tanto no se pierda de vista que muchos otros proyectos en muchas partes del mundo, a lo largo de muchos años, han hecho múltiples recorridos de ida y vuelta a partir de las mismas intenciones. No podemos ignorar las lecciones aprendidas y reportadas acerca de las “metodologías” para desarrollo de software. Además, tampoco se justifica ignorar los esfuerzos metodológicos en otras disciplinas análogas a la creación de software; por ejemplo las ciencias o la literatura creativa que también han evolucionado sus metodologías. Antes de continuar, es pertinente aclarar algo para evitar que las buenas intenciones descarrilen: una cosa es el esfuerzo metodológico —el estudio de los métodos— y otra muy distinta, es la aplicación de un método en particular. Si se confunde un método particular como si fuese metodología entonces aumenta el riesgo de intentar aplicar el mismo método a toda posible situación sin considerar los problemas relacionados con potenciales incompatibilidades entre el método y el objetivo general que se intenta lograr. Un esfuerzo metodológico suele identificar el esquema subyacente que guarda un conjunto de métodos. En el caso de la creación de software se ha identificado, por ejemplo, que algunas

familias de métodos se componen de los siguientes elementos: un conjunto de conceptos interdependientes, un proceso de desarrollo y un conjunto mínimo de herramientas necesarias que soporten a dicho proceso. Los métodos con estas características se denominan “métodos sistemáticos”; es decir, se derivan de una conceptualización de la creación de software como un conjunto de elementos interrelacionados (valores, principios, prácticas y patrones) que siempre estarían presentes en todo proyecto exitoso. La breve historia de aproximadamente 70 años de programación de computadoras ha visto varias familias de esos métodos sistemáticos que han gravitado alrededor de distintos paradigmas de desarrollo —estructurado, orientado a objetos, adaptativo, etcétera. Todo bien, pero ¿cuál método es el más adecuado para un proyecto en particular? ¿Quién está en posición para prescribir los valores, principios, prácticas y patrones a observar por parte de los integrantes de ese grupo particular de proyecto, que tienen en sus manos la encomienda de resolver un tipo de problema en específico? El esfuerzo metodológico es muy importante para un proyecto de desarrollo de software a gran escala, eso no está en duda. Sin embargo, la dimensión de su importancia es tal que ese esfuerzo no debe dejarse principalmente en manos de alguien externo al proyecto. Pretender normar y prescribir desde fuera lo que debe pensar y hacer un equipo de proyecto es una receta para el fracaso. Los grupos de proyecto que ejercen por sí mismos el pensamiento metodológico suelen auto-gestionarse e interactuar con sus clientes y usuarios en términos del valor de negocio entregado en producción con una pauta continua y con un nivel de calidad sostenido; es decir, el patrón de confianza construido sobre los hechos de la experiencia de clientes y usuarios habla de la calidad de lo entregado. Para tales grupos de proyecto no hay necesidad de intentar una prescripción desde el exterior acerca de sus métodos internos y sus procedimientos de interacción con sus clientes y usuarios, sino que ellos mismos practican la autocrítica de manera habitual y adaptan su mentalidad y su proceder con base en la retroalimentación tanto interna como externa, que ellos mismos buscan con interés propio. Pero, ¿cómo ayudar a un grupo de proyecto que no ejerce ni cultiva el pensamiento metodológico sino que pretende basar su proceder en la mera obediencia a prescripciones externas? Por otro lado, ¿qué ayuda sería efectiva para un grupo de proyecto que no piensa de manera metódica pero tampoco ofrece mecanismos de visibilidad, gobierno y predictibilidad para sus esfuerzos?

Marco A. Dorantes es un consultor en el desarrollo reflexivo y cooperativo de sistemas computacionales que retornan ganancias. Diseña sistemas de cómputo desde 1987. Su principal interés profesional es la aplicación tanto de las teorías como de las prácticas del pensamiento sistémico para la creación de soluciones de negocio basadas en software. http://agilidad.blogspot.mx

046

SG.48

SG Software Guru #48  

DevOps, Argentina, Mexico, ethical hacking, Swift.

Read more
Read more
Similar to
Popular now
Just for you