¿Cuál es la mejor metodología para desarrollar software?

Source: Artificial Intelligence on Medium

La creación de software lleva más de 50 años presente como una de las actividades productivas de nuestra sociedad. Se ha inmerso en nuestra cultura, dando origen a una tecnificación social. En el tiempo en que se comenzaron a construir los grandes sistemas, las actividades de implementación eran desordenadas. Una de las alegorías que se mantiene hasta el momento es la de “codifica y repara”. Siendo creados estos sistemas sin ningún planteamiento, el ciclo de vida del software se concentraba en establecer un sistema funcional, en un año o dos, y pasar un par de años más resolviendo los errores que se iban encontrando. Esta metodología de “repara al encontrar” es aún parte de los muchos sistemas productivos con los que nos podemos encontrar. A partir del año 1975 una corriente de reparación ágil comenzó a rendir frutos. Casi al mismo tiempo, la planeación comenzó a tener también un papel fundamental. En este punto nodal, comenzó la carrera de las metodologías de desarrollo, implementación y planeación. Nuestra pregunta favorita sigue siendo ¿cuál de ellas es la mejor?

Con el afán de centrarnos directamente en las características que describan las metodologías, dejaremos a un lado el recuento histórico. Existen varios estudios que son excelentes recuentos para ello. Otro aspecto que tomaremos en cuenta será el entrelazamiento entre estas, dando con esto una percepción de evolución que iremos comparando con el tamaño y capacidad de un proyecto como necesidades principales. Esperamos con esto poder crear una ayuda simplificada que sirva como base para construir “ingenuos” indicadores de decisión.

Metodologías “Heavyweigh”: Predictibilidad y madurez

Las metodologías derivadas de planeación secuencial conocidas comúnmente como “heavyweight” requieren especificar las funcionalidades del sistema antes de la construcción de estos. Por otro lado, las metodologías ágiles o “lightweight” comenzaron a orientarse en la parte de reparaciones. A este momento es donde la introducción de la satisfacción del propietario, consumidor o usuario cobró importancia. Evolucionando rápidamente, el movimiento genial fue su inclusión como parte de la cadena de vida de software. La barrera entre ambas categorías es ahora tenue, muchos modelos de estandarizados del mercado establecen una hibridación.

Para subsanar los riesgos de la mala interpretación funcional, la primera metodología de desarrollo en cascada o “waterfall”, estableció una estructuración secuencial. La parte fuerte es definir estos pasos, estableciendo que la ejecución de cada uno de ellos sea satisfactoria. Los pasos establecidos conciernen primero el entendimiento de las necesidades, seguido por el diseño de las soluciones, su implementación y verificación, dejando al último un espacio corto para el mantenimiento. La aplicación de esta metodología establece un conocimiento certero y bien documentado de los procesos empresariales a priori. Esta característica crea dificultades al momento de la creación de los nuevos requerimientos: el mapa de conocimiento de las empresas casi nunca es completo o es demasiado complejo

Una característica común de las organizaciones es el cambio y complejidad de sus procesos. Del primer aspecto, se derivan las necesidades momentáneas, las cuales crecen y se agrupan naturalmente para crear los procesos estables. En este sentido, la modificación basada en el entendimiento paulatino de los procesos empresariales y su transformación hacia procesos digitales requiere una variación incremental e iterativa. Ambos aspectos son capturados dentro de la metodología de desarrollo unificado de software basado en los procesos (“UP”, “Unified Process”, por sus siglas en inglés). Su base la podemos formar al tomar la secuencia de la metodología en cascada (o cualquiera similar), añadiendo extensibilidad de las etapas. De esta manera las modelación, análisis y diseño de los componentes informáticos permanece abierto. La implementación se transforma en iteraciones con un tiempo establecido. Cada una de estas iteraciones es restringida por la necesidad de contar con la funcionalidad en los sistemas productivos, siendo entonces importante tener establecido un proceso de transición hacia los mismo. En este último punto es sobre el cual se establece la creación de los sistemas de calidad, donde la mayor cantidad de pruebas son realizadas previo al paso hacia el sistema productivo.

Los tipos de empresas que pueden aplicar estas metodologías deben de tener un robusto grupo de desarrollo, un entendimiento completo de todo su software y una tradición de procesos sólida, frecuentemente documentada exhaustivamente. A partir de ello ganan un importante poder predictivo sobre la evolución de sus sistemas digitales, que es acompañada con una estrategia a largo plazo de desarrollo. Derivan estas características en una organización madura cuyo futuro tecnológico es completamente cuantificable. ¿Existirán tales empresas?

Metodologías ágiles: La diversificación

Las necesidades de adaptación a los mercados dinámicos y la inclusión de nuevos modelos de negocio establecen nuevas formas de desarrollo de software. El éxito de las metodologías ágiles se puede deber a un punto principal: están basadas directamente en los deseos de los usuarios. Partiendo de las correcciones que se hacían o hacen en los sistemas productivos, la actividad de “debugging” se transformó en una actividad cotidiana. La conjunción de las habilidades técnicas y de negocios se encuentran en esta actividad. En la mayor parte de los casos es un esfuerzo compartido, una unión con los expertos de procesos. Esta interacción puede crecer, transformarse en dogmas de desarrollo.

Como primera instancia propondremos la extensión de la retroalimentación entre expertos de procesos hacia otras áreas. Bajo esta consigna, la programación extreme (“XP — Extreme Programming”, enfatiza la colaboración en todas las líneas humanas, creando interacciones de unos cuantos minutos. Dichas interacciones, ordenadas, son ampliadas para conocer la opinión de en varios niveles y con varios tipos de expertos. Cada una de estas experiencias son vertidas en historias. Las historias son agrupadas desde una planeación, ejecutadas en pequeñas liberaciones de funcionalidad que sirven como metáforas entre desarrollador y usuario. La metodología adquiere la calidad de extremas debido a las refactorizaciones que se hacen para incrementar la calidad del código. La desmitificación antigua de que solamente la persona que realizaba el código podría ajustarlo es destruida por paradigmas de desarrollo tales como programación por pares.

Las metodologías XP añade también, no en su base, pero si como un derivado, la cualidad de crear integraciones continuas hacia los sistemas productivos. Requiere también fuertemente de la presencia de los usuarios definidores de procesos trabajando frente a frente con los desarrolladores. Esto conlleva a un fenómeno interesante de auto ordenamiento. Los equipos conciben sus tareas y establecen acuerdos gestionados internamente. De esta manera, el impulso y escalamiento de trabas se magnifica: varios sucesos o equipos requieren un grado de atención más continuo. Implícita esta la necesidad de complementar las metodologías ágiles con un soporte para gestión de proyectos. Una de las formas de gestión de proyectos con necesidades continuas que ha tenido mayor éxito es el Scrum (posiblemente sin una traducción correcta al español). Su principal característica es la de crear diversos artefactos para ordenar las peticiones de los usuarios -Backlogs, establecer longitudes para el desarrollo de los procesos iterativos -Springs-, así como la formalización de los ciclos de retroalimentación -Ceremonies-. La combinación entre scrum y programación extrema podría parecer ser la combinación ideal y final entre metodologías, sin embargo ¿puede cualquier grupo utilizarla? ¿se puede utilizar en cualquier proyecto?

Metodologías híbridas: ¿lo mejor de dos mundos?

Al incluir recurso fuera del de corte tecnológico dentro de los proyectos de software, estos se transforman ya en proyectos de desarrollos de productos hacia modelos de negocios. Las estructuras organizaciones se están adaptando a estas formas de operación: la interfaz entre operación de negocios y su soporte técnico desaparecen. En más, las empresas comienzan a utilizar sus procesos digitales como generadores de ingreso, especialmente las empresas de orquestación de servicios. A este punto, la colocación de recursos materiales y talento se transforma también en una necesidad continua de los proyectos digitales. Metodologías híbridas que combinan la predictibilidad y la agilidad son necesarias bajo estas circunstancias. El dinamismo es la clave, la posibilidad de utilizar recursos compartidos entre varios proyectos y la migración de talento entre ellos. Metodologías como el diseño de sistemas dinámicos (“DSDM — Dynamic System Development Method”). Las fases de desarrollo tecnológico cobran de nuevo vida, los ciclos de iterativos e incrementales son incrustados dentro de estas fases. Sin embargo, el punto clave es la toma de decisiones a momento precisos sobre lo que es necesario desarrollar, diferenciado de lo que es opcional, recreativo y lo que definitivamente no se puede desarrollar. Todas estas decisiones requieren roles y procesos de escalamiento de decisiones. Parte de ello crea eventos nuevos como el desarrollo de prototipos o productos mínimos viables antes de pasar a los sistemas de calidad o productivos. La autogestión se mantiene bajo historias aprobadas, manteniendo mucho cuidado en la capacidad de interoperabilidad de software que se desarrolla. En el ámbito ideal cualquier historia transformada en una funcionalidad digital goza de solidez dentro de los procesos de negocio y versatilidad dentro de su soporte tecnológico.

Perspectivas hacia las tecnologías exponenciales

A partir de aquí, la historia de la fusión ente estrategia de operaciones y desarrollo de software contiene nuevos y fascinantes elementos. Las operaciones digitales conforman ya una buena parte de cualquier modelo de negocios. La estrategia se ve impulsada por las cambiantes preferencias de consumo, incluyen ya dentro de ellas elementos de análisis o inteligencia de negocios. El desarrollo se ve ahora acelerado por técnicas nuevas, inteligencia artificial, big data y realidad aumentada, mixta o virtual, son algunas de ellas. Como ya mencionamos la interface entre ellas se difumina día con día, transformándose más en un proceso de un continuo entrelazamiento que potencia la una hacia la otra en una coreografía que es responsiva a los deseos humanos.

Referencias

Ahimbisibwe, A., Daellenbach, U., & Cavana, R. Y. (2017). Empirical comparison of traditional plan-based and agile methodologies. Journal of Enterprise Information Management.

Awad, M. A. (2005). A comparison between agile and traditional software development methodologies. University of Western Australia, 30.

F. Tripp, J., & Armstrong, D. J. (2018). Agile methodologies: organizational adoption motives, tailoring, and performance. Journal of Computer Information Systems, 58(2), 170–179.