{"id":7008,"date":"2022-01-25T10:25:00","date_gmt":"2022-01-25T10:25:00","guid":{"rendered":"https:\/\/www.cybermedian.com\/es\/?p=7008"},"modified":"2026-04-20T09:13:56","modified_gmt":"2026-04-20T09:13:56","slug":"por-que-scrum-proceso-definido-vs-proceso-empirico","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/es\/why-scrum-defined-process-vs-empirical-process\/","title":{"rendered":"Por qu\u00e9 Scrum: proceso definido vs proceso emp\u00edrico"},"content":{"rendered":"

Hay proyectos que son bastante sencillos y relativamente predecibles, donde se pueden aplicar herramientas racionales de planificaci\u00f3n y toma de decisiones.\u00a0Otros proyectos que son m\u00e1s complejos o impredecibles requieren un enfoque diferente que se base m\u00e1s en la autoorganizaci\u00f3n y la innovaci\u00f3n.<\/p>\n

La mayor\u00eda de los proyectos de desarrollo de software se consideran de naturaleza compleja e impredecible debido a la convergencia de tres factores: personas, requisitos y tecnolog\u00eda.\u00a0Los diversos enfoques utilizados para entregar y administrar proyectos podr\u00edan entenderse m\u00e1s f\u00e1cilmente en el contexto de los modelos de control de procesos y la complejidad del proyecto.<\/p>\n

Tipos de control de procesos<\/figcaption><\/figure>\n

Proceso definido: un enfoque tradicional basado en un plan<\/strong><\/p>\n

Tradicionalmente, una vez que comienza un proyecto, se crea un paquete de requisitos y luego se “aprueba”.\u00a0El gerente del proyecto asume que esta aprobaci\u00f3n da como resultado un conjunto fijo de requisitos y que ahora puede comenzar la planificaci\u00f3n.\u00a0El director del proyecto estima cu\u00e1nto tiempo llevar\u00e1 completar los requisitos y crea el plan del proyecto.\u00a0El plan predice que el proyecto estar\u00e1 terminado en una fecha determinada, y esa fecha se comunica al cliente.<\/p>\n

El defecto fundamental de este enfoque es que el plan, que impulsa todo, se basa en la suposici\u00f3n de que los requisitos son fijos y no cambiar\u00e1n.\u00a0La experiencia nos ha demostrado que este nunca es el caso;\u00a0los requisitos nunca son fijos, siempre cambian.\u00a0Cuando los requisitos cambian, el plan se ve afectado;\u00a0y como resultado, la fecha de finalizaci\u00f3n tambi\u00e9n debe cambiar.\u00a0Desafortunadamente, en muchos casos, eso es imposible y el equipo tiene que entregar en la fecha a la que se comprometieron.\u00a0Es entonces cuando se produce una gran crisis y el proyecto empieza a salirse de control.<\/p>\n

Proceso emp\u00edrico: enfoque \u00e1gil impulsado por el valor<\/strong><\/p>\n

El enfoque \u00e1gil impulsado por el valor se basa en el\u00a0\u00a0empirismo\u00a0<\/strong>\u00a0que cambia toda la mentalidad.\u00a0Asume desde el principio que los requisitos que existen por adelantado no son fijos y que cambiar\u00e1n.<\/p>\n

La mentalidad \u00e1gil tambi\u00e9n supone que debe entregar en una fecha determinada.\u00a0Este enfoque fija el tiempo y los recursos y deja los requisitos sin determinar.\u00a0Para nosotros, este enfoque se parece m\u00e1s a la realidad de crear software.\u00a0Ahora toda la noci\u00f3n de impulsado por el valor tiene mucho sentido.\u00a0Cuando tiene una cantidad fija de tiempo en la que no est\u00e1 seguro de poder cumplir con todos los requisitos (porque cambiar\u00e1n y, por lo tanto, cambiar\u00e1 el tiempo necesario para terminarlos), la reacci\u00f3n natural es priorizar los requisitos y terminar primero. aquellos que agregan m\u00e1s valor al cliente.<\/p>\n

Puede estar pensando: “\u00bfQu\u00e9 pasa con los requisitos que no est\u00e1n terminados para la fecha de entrega?”\u00a0Esa es la raz\u00f3n por la que utiliza el enfoque basado en el valor.\u00a0Usted reconoce el hecho de que no todos los requisitos se completar\u00e1n en la fecha de entrega.\u00a0La pregunta importante que debe hacerse es si ha proporcionado suficientes funciones para admitir un sistema que proporcione valor al cliente.<\/p>\n

Tasa de fracaso de los proyectos de software<\/strong><\/p>\n

El Informe CHAOS<\/a>\u00a02015\u00a0\u00a0\u00a0ha sido publicado recientemente por\u00a0\u00a0Standish Group<\/a>\u00a0.\u00a0Los Informes CHAOS se han publicado todos los a\u00f1os desde 1994 y son una instant\u00e1nea del estado de la industria del desarrollo de software.\u00a0Este a\u00f1o, el informe estudi\u00f3 50 000 proyectos en todo el mundo, desde peque\u00f1as mejoras hasta implementaciones masivas de reingenier\u00eda de sistemas.\u00a0Este a\u00f1o, el informe incluye una definici\u00f3n mejorada de \u00e9xito que analiza algunos factores adicionales que se cubrieron en encuestas anteriores.<\/p>\n

Los resultados indican que a\u00fan queda trabajo por hacer para lograr resultados exitosos de los proyectos de desarrollo de software.\u00a0Esta tabla resume los resultados de los proyectos durante los \u00faltimos cinco a\u00f1os usando la nueva definici\u00f3n de factores de \u00e9xito (a tiempo, dentro del presupuesto con un resultado satisfactorio).<\/p>\n

Tasa de fracaso del proyecto de software<\/figcaption><\/figure>\n

Con la adopci\u00f3n de m\u00e9todos de desarrollo \u00e1giles en los \u00faltimos a\u00f1os, fue posible comparar los resultados de los proyectos entre los proyectos en cascada \u00e1giles y tradicionales.\u00a0En todos los tama\u00f1os de proyectos, los enfoques \u00e1giles dieron como resultado proyectos m\u00e1s exitosos y menos fallas absolutas, como se muestra en esta tabla<\/p>\n

<\/figure>\n

\u00bfCu\u00e1les son los problemas del enfoque tradicional?<\/strong><\/p>\n

El enfoque tradicional basado en un plan no es defectuoso en s\u00ed mismo;\u00a0simplemente no es adecuado para la industria del software actual.\u00a0El enfoque basado en planes se bas\u00f3 originalmente en los conceptos tradicionales de gesti\u00f3n de proyectos, que se originaron en la industria de la construcci\u00f3n.\u00a0En la industria de la construcci\u00f3n, el enfoque basado en planes es adecuado: los planos, que son los requisitos, son fijos y probablemente no cambiar\u00e1n mientras se construye el edificio.\u00a0Puede estimar cu\u00e1nto tiempo llevar\u00e1 construir los pilares de acero, verter el hormig\u00f3n, etc.<\/p>\n

La raz\u00f3n por la cual el enfoque tradicional basado en planes es adecuado para la industria de la construcci\u00f3n pero no para la industria del software se remonta a la diferencia en la forma en que controlamos los sistemas emp\u00edricos (como el desarrollo de software) y la forma en que controlamos los sistemas definidos (como la construcci\u00f3n o la fabricaci\u00f3n). ).\u00a0La siguiente tabla muestra las diferencias entre las caracter\u00edsticas de un proceso definido y las de un proceso emp\u00edrico.<\/p>\n

Proceso definido vs proceso emp\u00edrico<\/figcaption><\/figure>\n

Despu\u00e9s de leer la tabla, es f\u00e1cil ver que el desarrollo de software es definitivamente un proceso emp\u00edrico, no un proceso definido.\u00a0El problema es que llevamos a\u00f1os abordando el desarrollo de software como un proceso definido, y ese enfoque no funciona.<\/p>\n

Referencias<\/span><\/h3>\n
    \n
  1. Informe de Caos 2015 de Standish Group<\/a><\/li>\n
  2. Volverse \u00e1gil en una palabra imperfecta \u2014 por Greg Smith y Ahmed Sidky<\/li>\n<\/ol>\n

    Otras lecturas de Scrum<\/span><\/h3>\n