style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

El Fracaso de los Proyectos de Software

Antes de comenzar, debo aclarar que yo no tengo nada en contra de las metodologías tradicionales, al contrario, creo que su aplicación es muy eficiente en algunos tipos de proyectos, pero sin duda en la mayoría de proyectos empresariales, han demostrado ser ineficientes. Por esta razón, debemos dar una mirada a una nueva alternativa que lleva utilizándose con éxito en Europa desde hace más de 10 años!

Esta serie de articulos bajo el nombre “El fracaso en los proyectos de Software” es simplemente una recopilación de ideas que muchos expertos realmente involucrados en el desarrollo de software han vertido durante los últimos años:

Y a tantas otras personas que directa o indirectamente han influido en la filosofía ágile. (ver).

Esta primera parte, da solamente un acercamiento del entorno actual en el que se vive en muchas partes del mundo, principalmente, en México. En la segunda parte que comenzaré a escribir en breve, hablaré más especificamente sobre la filosofía de las metodologías ágiles y sus bondades.
Durante mi corta experiencia, he podido ver muchos Sistemas de Software de mediana escala con una calidad increíblemente pobre, con un mantenimiento que resulta un tormento y un tiempo de desarrollo cada vez más corto. Cuando lo anterior no sucede, el proyecto se termina, pero no cumple con las expectativas del cliente y termina siendo muy poco utilizado. Por ejemplo, una de las casas de préstamo de efectivo en México recientemente ha iniciado un nuevo proyecto para migrar su sistema de cobranza en .NET a una plataforma Java! Indudablemente la razón de esta migración no es por que .NET se haya quedado “corto”, más bien habla de una pésima aplicación que a estas alturas ya es inmantenible por su terrible calidad, derivado de una mala administración!

El fracaso de estos proyectos se atribuye a diferentes perspectivas, desde un nivel meramente técnico (personal mal capacitado), hasta una mala visión de negocio entre los niveles gerenciales. Mi intensión en este artículo no es hablar sobre los errores o aciertos que cometen los niveles gerenciales ya que en estos momentos no tengo injerencia en este campo por mi nula experiencia, así que me enfocaré más al problema derivado de una mala Ingeniería de Software y abrir la pregunta que Tom DeMarco lo plantea en uno de sus artículos…. La Ingeniería del Software es ¿Una idea obsoleta?

Esta serie de artículos, involucran a estudiantes y académicos y a profesionistas del mundo laboral.
A los estudiantes, para que conozcan lo que se viene trabajando en reino unido y países europeos con éxito desde hace más de 10 años. Además con esto espero que sepan que no todo en la vida de los sistemas es un conjunto de tablas, relaciones, frameworks y lenguajes de programación! Quienes me conocen, saben muy bien que mi formación ha sido eminentemente técnica, así que en definitiva no podrán decir que me intereso en este tipo de proyectos por que “no se programar”.

Al sector académico es una llamada de atención para que dejen a un lado sus ideas obsoletas sobre la Administración de Proyectos de Software, se haga una revisión a las retículas académicas y se actualice a la planta docente. Es hora de que los catedráticos sepan que hay otras cosas que el modelo en cascada (muchos ni siquiera enseñan algo de RUP) y peor aún ¿Por qué seguimos perdiendo el tiempo en hacer que el alumno domine un Microsoft Project para hacer bonitos pero inútiles diagramas de Gantt? Es hora que el sector académico se pregunte ¿Realmente todas estas prácticas están agregando un valor real al producto?… En México la educación es obsoleta, mientras en otras partes del mundo se enseña PSP/TSP, RUP, Ágile, Testing, etc., en México seguimos encerrados con nuestros diagramas de flujo, diagramas de contexto, y tantas otras prácticas obsoletas. Mi antipatía por el sector académico siempre ha sido notoria para todos aquellos que me conocen en persona y he sido un crítico muy duro con ellos. Yo mismo he vivido la ineptitud de muchos catedráticos, mi asesor de titulación quería diagramas de flujo y de contexto argumentando que los Casos de Uso eran para personas técnicas y no para los usuarios!!! Lo más triste era ver que se encontraba en el departamento de Posgrado pues era un Maestro en Ciencias!

Finalmente, a los profesionistas de hoy, a los desarrolladores que aún no conocen a los métodos ágiles, es seguro que ustedes estarán con muchas cosas de acuerdo.

Sin más que esperar una mentalidad abierta por parte de ustedes lectores, es hora de ver algunas de las razones por la que los proyectos de Software fracasan y ver bajo una filosofía agile una alternativa, aunque no  necesariamente una solución completa a los problemas existentes en el desarrollo de SW, pero Ágile puede influenciar aún más los conceptos de la Ing de Software tradicional!

SITUACIÓN ACTUAL
En el año 2006, John Avellanet utilizó un estudio realizado por Accenture para establecer los puntos necesarios que se requieren para alcanzar el éxito de un proyecto. Los datos sobre el entorno en el desarrollo de proyectos de TI era desalentador, desafortunadamente del 2006 a la fecha, las cosas no han cambiado en mucho.

  • Solo el 27% de los proyectos de TI puede ser considerado un éxito. 
  • Los proyectos de TI sobrepasan su costo en un 56%. 
  • Se estima que los proyectos sobrepasan su calendario en un 84%. 
  • El 31.1% de los proyectos son cancelados antes de que sean terminados. 

Lo anterior son números rojos alarmantes, que sin embargo, no son nada nuevos , estos números han existido desde un inicio.

Este proyecto es extremadamente importante.
No hay calendario, ni guias, ni el personal necesario…
Y su fecha de entrega es mañana!! Así que esta es su oportunidad
de impresionar realmente a todos!

CAUSAS DE TAN DESALENTADOR PANORAMA
Las causas son diversas. El Dr. Daniel Tapia, Profesor Investigador del Centro de Investigación en Tecnologías de la Información (CITIS) de la Universidad Autónoma del Estado de Hidalgo, atribuye el fracaso de un proyecto de TI a las siguientes razones;

  • Se daba mayor atención a las cuestiones operativas que a la planificación. 
  • Planeación deficiente. 
  • Los objetivos del proyecto no estaban alineados con los objetivos de la organización. 
  • El entorno global hace que la planeación tradicional ya no sea suficiente. 
  • Una mera planificación de actividades y recursos no sirve de nada. 
  • Se requiere una gestión estratégica. 

Existen puntos interesantes en las presentaciones del Dr. Tapia que recomiendo leer (ver al final de este artículo), aunque en algunas cuestiones, no concuerdo del todo, como por ejemplo donde hace mención que se requieren procesos bien definidos y una documentación extensa. Fuera de esto, el Dr. Tapia concluye que un simple enfoque de Ing. de Software ya no es suficiente, lo cuál es extremadamente cierto, sin embargo, en este artículo nos enfocaremos en dicho aspecto.
A los puntos anteriores, voy a agregar uno que seguramente puede ser causa de polémica por ser tan directo y acusador.

Durante muchos años, el sector académico ha tenido erróneamente mucha injerencia en el desarrollo de software cuando su papel no es precisamente ser el protagonista en este ámbito. Las universidades estan más interesadas en crear pequeñas fábricas de software, que en preparar de forma adecuada a los alumnos. Las empresas por su parte, se están enfocando en capacitar en cuestiones básicas a los alumnos que egresan en lugar de desarrollar software, es decir, los papeles se estan invirtiendo!! Las universidades están desarrollando software y las empresas están capacitando!!.

Hace poco más de un año, escuche al Director General de QuarkSoft, Cesar Montes de Oca, decir todo lo anterior! Ellos como empresa tenían que capacitar a los recién egresados sobre temas tan sencillos como realizar una simple conexión a base de datos con Java! Sin duda que algo muy pero muy grave esta fallando con las Universidades, pero bueno, afortunada o desafortunadamente no es tema de análisis en este estudio.

Grandes universidades que sin duda han hecho grandes aportes a la Ing. del Software, como por ejemplo la University Carnegie Mellon (en conjunto con el SEI), han desarrollado varios de los modelos y procesos para el desarrollo de Software como por ejemplo (CMM/CMMI, PSP/TSP., etc., “Avances” mismos que al día de hoy han demostrado ser ineficientes para la mayoría de los casos reales. Aquí en México por ejemplo, se ha creado MoProSoft como un modelo de desarrollo de software para las empresas mexicanas, modelo que ha sido lidereado por la Dra. Hanna Oktaba, académico del IMAS en la UNAM.

Es importante hacer un pequeño paréntesis y aclarar todo lo anterior para no crear malos entendidos. El sector académico ha hecho no solamente grandes aportes, más bien ha hecho todos los aportes de la actualidad en cuanto a las Ciencias Computacionales [Ver Ing de Software de Ian Somerville para una diferencia entre las Ciencias Computacionales y la Ing de Software]. Debemos agradecer a nuestros maestros de la universidad por enseñarnos aquellas estructuras de datos, por hacernos entender el algoritmo de Dijkstra, por explicarnos la notación O, por aquellos difíciles proyectos en lenguaje ensamblador y por aquellas Series de Fourier, etc., sin embargo, han olvidado que mucho de su trabajo es eminentemente teórico que puede demostrarse y realizarse en laboratorios, pero un proyeto de desarrollo de software no puede ser simulado y demostrado fácilmente.

¿Cuál es el problema de las Metodologías actuales?

La filosofía que siguen los métodos formales están basados en procesos aplicados en otras ingenierías como la ingeniería civil y mecánica en donde se requiere una planeación detallada antes de construir! Este es el punto medular de este artículo… “La planeación detallada“… Martín Fowler un verdadero gurú a nivel mundial, escribió un muy interesante y famoso artículo donde habla sobre “La nueva metodología” y da unas pautas generales que describen el error de las metodologías tradicionales y los aciertos que han tenido las metodologías ágiles.

Ha sido un error tomar casi al pie de la letra la filosofía de otras ingenierías y aplicarlas al desarrollo de software. En la ingeniería civil por ejemplo, los problemas importantes son suceptibles de un análisis matemático que determina por ejemplo, la fuerza a aplicar a ciertos elementos, la resistencia de los materiales, etc. En pocas palabras, los métodos que se utilizan en otras ingenierías son “predictivos” [entiéndase por predictivo que es posible "predecir" el comportamiento de un Sistema bajo ciertas condiciones]y funcionan muy bien en ese ámbito. Sin embargo, en el mundo del desarrollo de software comercial, ¿Como es posible predecir un cambio de requerimientos? ¿Es posible predecir la duración de un proyecto?… Muchas personas podrían argumentar que si es posible predecir lo anterior, quizá sí, pero no bajo modelos matemáticos como en otras ingenierías y por ende esta filosofía debería desecharse.

Lamentablemente, esta predicibilidad es muy usada en procesos tales como el PSP [Ver Personal Software Process del Dr. Watts Humprhey] , en donde debes ir haciendo todo un registro de tus tiempos, de tus distracciones, e ir sacando promedios de cada actividad a la que te dedicas para que de esta forma, en actividades similares posteriores, puedas predecir el tiempo que llevaras en construir cierto componente de software, aunado a esto, toda una serie de procesos formales intentan mejorar tu productividad y calidad en tus desarrollos. Los principios del PSP pueden ser aun muy discutidos, yo mismo me encuentro aún valorando sus bondades en ciertos tipos de proyectos.

Las metodologías tradicionales, al ser meramente predictivas, dicen que debemos hacer una toma completa y detallada de requerimientos al iniciar un proyecto, posteriormente asentar en documentos y diagramas UML la arquitectura del sistema a utilizar, después comenzar la construcción del sistema y finalmente una etapa de pruebas. Nótese la gran similitud con la ingeniería civil, en donde primero se diseña y después se construye!

Cuando se trabaja con metodologías tradicionales, existe una resistencia nativa al cambio. Las personas que trabajan en el proyecto se resisten a cualquier cambio de requerimientos, cosa contraria a lo que pasa con los métodos ágiles, en donde se piensa que los cambios son bienvenidos, se trata sencillamente de convivir con ellos y transformar una debilidad en una fortaleza.
La toma de requerimientos tradicional, indica hacer una detallada documentación y casos de uso donde se plasmen los requerimientos. Hoy en día ya sabemos que un desarrollo iterativo es mejor, en donde al inicio del proyecto se de solo un panorama general de todo lo que el usuario quiere y en cada iteración se desglosen un poco más los requerimientos.

El diseño de una arquitectura antes de la codificación es otro problema fundamental! Teóricamente lo anterior suena bien e incluso lógico, pues a final de cuentas, esto mismo se hace en otras ingenierías! Pero la práctica nos ha demostrado que el definir una arquitectura anterior a la codificación resulta muy problemática a la hora de codificar. La filosofía agile, nos indica que la mejor arquitectura que podemos definir en un inicio son cuestiones generales como la plataforma de programación, la BD y los frameworks que utilizaremos, pero la arquitectura detallada, ira fluyendo durante la codificación!

La etapa de pruebas es un asunto discutido. Por un lado, los tradicionalistas opinan que debe haber un equipo aparte del equipo de desarrollo que se encargue de probar el sistema, además de esto, nos indica que la etapa de pruebas se realiza al final de la etapa de codificación! En el lado ágil, tenemos que no existe un equipo aparte del equipo de desarrollo, los desarrolladores son y deben ser los mejores testers, además de esto, la práctica de TDD, nos dice que primero debemos crear la prueba unitaria antes de crear el módulo! Es decir, debemos crear primero una prueba unitaria para algo que aun no existe!! Esto es raro al inicio, pero aporta muchas ventajas!

El error de las personas que practican metodologías tradicionales
Son muchos los errores que siguen los project manager tradicionales. Desde el hecho de que las empresas gastan o se desviven en piratear licencias de sofisticados programas para elaborar diagramas de Gantt y hacer un detallado calendario de todo el proyecto con fechas de entrega, personas que realizarán cada una de las tareas y/o módulos existentes, plan de trabajo que desarrollo una noche antes el departamento de ventas para poder vender un proyecto de miles de pesos etc., hasta el hecho de designar un equipo especializado en “pruebas de software” que sea diferente al del equipo de desarrollo que realizará las pruebas al software en base a un detallado análisis en casos de uso de 100 páginas.

Otro error que cometen frecuentemente los administradores de proyectos es,

Yo Administrador de Proyectos, soy el único que puede dialogar con el cliente! Tu programador, tienes prohibido hablar con el cliente de cosas relacionadas con el proyecto, cualquier duda que tengas en los requerimientos debes dirigirte a mi, cualquier duda que tenga el cliente en la estimación de tiempo debes indicarle que se dirija conmigo.

Acaso al construir una casa, el maestro de obra habla con nuestros papás en lugar de hablar directamente con nosotros que somos los clientes??

Algo más irónico es por ejemplo, cuando una vez que el departamento de ventas diseñó nuestro plan de trabajo y decidió que nos llevaríamos 2 días en construir la interfaz que comunicaría nuestro módulo de consultas de proveedores externos con la tabla que existe en DBASE y que la transmición de datos se haría mediante un certificado digital de seguridad web SSL, además claro esta, de tener la opción de enviar un correo electrónico a los directivos cuando el monto de las facturas exceda el monto planeado que se tiene en SAP. Una vez que en la primer reunión que tuvo el depto de ventas con el cliente y entrego dicho plan de trabajo, el cliente quedo asombrado ante la rapidez de desarrollo y le dijo al departamento de ventas que entonces comenzaran ese mismo día con el proyecto! Entonces el departamento de ventas, corre inmediatamente a darle la excelente noticia al equipo de desarrollo que tiene 2 días para mostrar un primer entregable, que de el plan de trabajo y las estimaciones de tiempo, que ya ni se preocupen, que ellos muy amablemente ya lo hicieron por nosotros!

Entonces el equipo de desarrollo, manda rápidamente a su analista estrella a la toma de requerimientos. Este llega al siguiente día con unas 30 hojas de las cuales unas 25 contiene información redundante! Entonces el equipo de desarrollo tiene ya solamente 1 día para terminar el primer entregable!!!!

Lo anterior, obviamente es una descripción subjetiva que no esta muy alejado de la realidad. Por un lado, tenemos a muchosStakeholder como el cliente, el depto de ventas, gerencia, etc., que piensa que hacer software es como manufacturar algo o hacer enchiladas, que en cuestión de horas estará listo para funcionar!!

Por otro lado, tenemos a métodos formales que nos exigen hacer una detallada toma de requerimientos en extensos casos de uso y más importante aún, estar persiguiendo al cliente para que firme dichos requerimientos y así “asegurar” que estos no cambien en un futuro y si cambian entonces tenemos a un “cliente que no sabe lo que quiere” y nos negaremos a realizar el cambio y si lo realizamos, será con un costo adicional sobre lo planeado. Por si esto fuera poco, se nos ha enseñado que antes de iniciar la etapa de codificación, debemos elaborar una detallada arquitectura del sistema y plasmarla en muchos diagramas UML y documentos que puedan servir como referencia “más adelante”.

Esta idea de una Arquitectura detallada y modelado UML, funciona bien en la Ingeniería Civil, pero no en el desarrollo de software… Incluso, el hecho de que muchos catedráticos piensen que el UML es la octava maravilla del mundo, es debido a que los diseños en papel o en una herramienta UML son consistentes y se ven bien! De la misma forma en el mundo real y productivo, los diseños UML en un principio parecen ser correctos y el modelo parece ser lo suficientemente bueno para generar una buena arquitectura, pero los problemas surgen a la hora de la codificación, y es cuando vemos que los diagramas UML solo nos han servido para perder el tiempo!! Cuando lo anterior pasa, es entonces que vociferamos a todo mundo que el cliente tiene la culpa por no saber lo que quiere, que nuestro analista no “predijo” como si lo hubiera hecho Walter Mercado lo que el cliente iba a querer más adelante y que nuestro arquitecto de software no supo diseñar una arquitectura escalable y preparada para el cambio!! Y es que aún si suponemos un modelo exitoso con UML, el constante cambio de requerimientos hará que sucedan dos cosas posibles:

  • Se actualiza toda la documentación existente y además se procede con dicho cambio a nivel de codificación. Al actualizar los cientos de documentos existentes y dejarlos actualizados y acorde a los nuevos requerimientos, hemos perdido tiempo valioso en aquello que realmente aporta un valor o ventaja competitiva a nuestro cliente! Por lo tanto, ya tenemos un retraso de más de un 50% y no entregaremos a tiempo la funcionalidad o si la entregamos, estará llena de errores por la premura del tiempo. 
  • Dejamos de lado la documentación y nos enfocamos a lo que realmente aporta un valor al cliente! Desafortunadamente, a mitad del proyecto, este enfoque resulta triste, ya que hemos perdido la mitad de tiempo en elaborar documentación que, conforme el proyecto fue avanzando y evolucionando ha quedado obsoleta y ya no sirve de “base” para el mantenimiento del sistema, pues lo que comenzó como un simple sistema de facturación, terminó acercándose más a lo que es un ERP. Finalmente, la documentación pasa a ser un bonito recuerdo! 

No faltara quien a estas alturas pueda argumentar algo a favor del modelado detallado en UML y pueda decir:

“Uhmm, pero un diagrama de clases o de componentes, nos da una visión general de la estructura del sistema y esto es muy útil para saber como interactuan los componentes del sistema, así que es necesario realizar estos diagramas. Además los diagramas de despliegue por ejemplo son muy útiles cuando tratas con un cliente técnico.”

Lo anterior, es una idea desesperada por encontrarle un sentido a la existencia del modelado excesivo en UML. Bastaría hacer un refactoring a nuestro código fuente para obtener un diagrama siempre actualizado de clases o de componentes del sistema! Y todo en cuestión de minutos!!… ¿Para que perder el tiempo diseñando y planeando algo de naturaleza intangible que con el tiempo irá cambiando y evolucionando? Ahora bien, no todo en el UML es malo, los diagramas de despliegue por ejemplo son útiles, los diagramas de actividades son una versión más bonita de los diagramas de flujo, en un momento dado podrían ser útiles 2 o 3 diagramas de secuencia, etc. El punto aquí es el “exceso” que se comete con UML.
Aunado a lo anterior, todavía podemos decir mucho más….

  1. Los líderes y clientes, piensan que el hacer software es tan sencillo y rápido como introducir una fórmula en excel, por esto mismo, obligan a los desarrolladores a trabajar jornadas mayores a las 8 horas! 
  2. Los líderes de proyecto no están dispuestos a perder su autoridad! Es común que en los equipos, siempre exista una autoridad que tome todas las decisiones [programadores extrella, líderes absolutos]. Cuando un desarrollador sugiere o habla algo con el cliente, el líder siente perder autoridad, reacciona y entonces prohíbe una comunicación con el cliente! 
  3. Los equipos de trabajo siempre están a la espera de recibir órdenes, a que se les asigne una tarea, muchas veces a que se les diga como hacerla, etc. Mientras en la forma tradicional perdemos el tiempo esperando recibir ordenes, en las metodologías ágiles se fomenta a equipos auto-dirigidos! 

¿Es importante estar certificado en una norma ISO, CMM/CMMI/, MoProSoft, etc?
Muchas empresas no ven lo anterior como una posibilidad para realizar un cambio y mejora en sus procesos, en vez de eso, lo ven como algo superficial del cual pueden alzar el cuello y presumir ante sus clientes que tienen una certificación ISO xxxx-xxxx y que entonces son la mejor opción ya que sus competidores hacen software basura y ellos al tener una ISO, hacen desarrollos de calidad!

Yo mismo he vivido lo anterior. En mi primer trabajo profesional que tuve en el desarrollo de software, yo aún era estudiante y me toco vivir como la empresa para la que trabajaba, se preocupaba más por dar a conocer a los clientes que se contaba con la certificación MoProSoft nivel 1, cuando internamente no se conocía muy bien la forma de aplicar efectivamente dicho modelo.

El presidente de la empresa, siempre aseguraba que no podíamos presumir nuestras miserias al cliente! Ciertamente algo muy cierto, el problema era que nunca se preocupo por hacer un verdadero cambio de fondo. Pero bueno, el asunto original es si realmente es importante estar certificado en alguna de las anteriores normas y procesos formales para tener éxito en el desarrollo de software! Me permito citar nuevamente al Dr. Tapia:

No existe interés por métodos formales de aseguramiento de la calidad del software. Las empresas mexicanas están más preocupadas por conseguir la certificación de sus procesos con un distintivo de calidad, aunque dicha certificación no garantice la satisfacción de sus clientes.

Finalmente
Para terminar esta primera parte del artículo “El fracaso en los proyectos de Software”, debemos sacar las concluciones más relevantes.

  • Los métodos tradicionales, siguen un enfoque utilizado en otras ingenierías como la Ingeniería Civil y Mecánica, en donde, sus problemas son susceptibles a un análisis matemático que determinará el comportamiento de un sistema bajo ciertas condiciones. En el desarrollo de software, no es posible determinar con exactitud el comportamiento de los sistemas de software. 
  • Los métodos tradicionales y las personas que trabajan con ellos, siguen un riguroso esquema, en donde se aleja mucho al equipo de desarrollo y al cliente. El desarrollo ágil fomenta la comunicación desarrollador/cliente e invita al cliente a ser parte del equipo, mientras que los tradicionalistas sostienen que el líder de proyecto debe ser el responsable de hablar con el cliente. 
  • Cuando los proyectos fracasan, se cree que todavía debe agregarse una capa más detallada de procesos aún más formales y definidos, de planes aún más detallados, de más documentación, de más juntas de 3 horas, de una mayor vigilancia al equipo de desarrollo y de más horas de trabajo, cuando en realidad los principios deben ser muy sencillos. [ver el artículo de Emilio Osorio] 
  • Las empresas se preocupan más por tapar hoyos superficiales, por presentar un mundo de caramelo en sus desarrollos con el cliente y de obtener certificaciones aunque no entiendan como aplicarlas. 
  • En muchas empresas, la gerencia toma decisiones que no le corresponden y debe dejarlas a los verdaderos expertos. Muchas veces son estos niveles los que fijan el costo de un proyecto de software y la duración del mismo. Cuando menos lo esperamos, ya nos entregan un plan de desarrollo con fechas ya establecidas!. 
  • Durante más de 10 años, los métodos formales no han dado tantos resultados positivos. Lo preocupante de esto, es que al no dar los resultados esperados, día a día se piensa en agregar más formalidad y rigidez a su proceso. Los métodos ágiles tampoco son la solución a todos los problemas, pero si dan unas buenas pautas para reformular las actuales ideas de la Ingeniería de Software. 

En la segunda parte de este artículo, comenzaremos a ver a la filosofía de los métodos ágiles y veremos en ellos una mejor herramienta para tratar de resolver los problemas actuales en la administración y desarrollo de software.

Visita el blog próximamente para leer la segunda parte que será mucho más interesante! No olvides vertir tus comentarios que serán muy útiles para enriquecer este artículo! Tanto si eres un estudiante con o sin experiencia, un académico dando o no dando clases de Ing de Software, o un profesionista desarrollador o líder de proyecto! Todos los comentarios, buenos o malos, pero constructivos, son bienvenidos!

REFERENCIAS BIBLIOGRÁFICAS

    Comentarios

    Opciones de visualización de comentarios

    Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
    Imagen de gabo

    Concuerdo en alguno puntos...

    Concuerdo en algunos aspectos mi estimado, sin embargo por eso estamos cada uno desde su trinchera (Blog, foros, reuniones en el starbucks etc.) advirtiendo y corrigiendo de estas deficiencias en los planes de estudios en sitios como estos.

    saludos

    Gabriel Martínez.
    Mi sitio personal
    Coatzacoalcos, Veracruz México

    Excelente info

    Es verdad, en México no tenemos conocimiento que existen nuevas metodologías de desarrollo nos quedamos con las antiguitas

    Si quieres resultados distintos haz cosas de manera diferente

    Excesivamente interesante como complejo

    Los puntos que tratas son bastante reales, en un mundo ideal bastaría únicamente con aplicar un conjunto de ideas preestablecidas para obtener el mejor resultado posible, sin embargo; todo cometemos el error de preocuparnos por las constante y no dedicarnos a que el proyecto fluya con todas sus variables.

    Gracias por compartir tu tiempo y conocimientos.

    Imagen de beto.bateria

    Existen personas con estos

    Existen personas con estos conocimientos, y tambien ya hay empresas que tienen implementadas estas tecnologias.

    Imagen de paranoid_android

    El factor humano olvidado.

    Mi opinión:

    Esta época es como cuando las corrientes sicológicas salieron y las enseñaban en las universidades había posturas en contra y a favor lo que pasó después es que las nuevas generaciones intentaban tomar lo mejor de cada una usando su criterio.

    Yo no hablaría de metodologías que son mejores que otras podría decir que hay mejores implementaciones de una metodología que otra, una metodología es algo cultural por lo regular no es individual por esta razón desde una universidad lo que importaría es conocer una base solamente.
    Algunos dicen que en la universidad se aprenden bases mientras que cuando uno es profesional se especializa. (No siempre)

    El aspecto humano.

    Platicando con un consultor de recursos humanos extranjero me comento que hay culturas organizacionales con estructuras jerárquicas muy marcadas (Mucho en latinoamerica), mientras que existen otros extremos donde es muy difícil organizar a la gente debido a la falta de mando.(Algunas en latinoamérica)

    Con exceso de creatividad mucha innovación y riesgo de poco rendimiento, y viceversa con mucho control poca innovación.
    Ambos extremos son malos (La virtud está en medio diría un filósofo). Hay empresas que van de un lado al otro perdiendo en el camino caso Nokia.

    Imagen de bferro

    Deberías cuidar un poco tus mensajes al sector académico

    Para WinDoctor
    No nos conocemos y por tal razón NO conozco tu "notorio rechazo" al sector académico. Deberías cuidar un poco tus menajes cuando generalizas y te diriges al sector académico en su totalidad y generalizas diciendo que la educación en México está obsoleta .Si esa es tu experiencia de la institución donde estudiaste, mencionala con nombres y apellidos y no generalices pues no conoces lo que puede suceder en otras instituciones.
    Tu mensaje me ofende y por supuesto que ofendería a muchos de mis colegas que de obsoletos no tenemos un pelo.

    Imagen de Cid

    Las universidades no son culpables

    Hola que tal creo que eso que dices de las universidades igualmente no es cierto, nadamas que algunos acostumbramos a no hacer nada si no me lo piden, el aprendizaje no solo depende de un profesor o instructor, muchas veces hay temas que por lo grandes o complejos no se alcanzan a impartir, pero en la mayoria de los semestres de una carrera o cursos de capacitación, bueno si se dicen llamar asi tendrían que darte el temario y es ahí donde viene al caso lo que mencione que no depende del profesor o instructor únicamente. A lo mejor en el curso o semestre solo se le dio relevancia a ciertos aspectos y algunos solo se mencionaron sin profundizar mucho, y es tarea del estudiante o aprendiz buscar información acerca de los temas como complemento a lo impartido en su semestre o curso.
    Imagen de ingscjoshua

    mmmm

    Pues como dice Bferro no estoy de acuerdo en que culpes a las instituciones si el sistema esta mal yo te pregutnaria tu q haces para cambiarlo? te ofrcieste a dar un curso o un taller en extender el aprendizaje? lo que menciones respecto a eso me suena al tipico MExicano que se queja de todo!! y solo no hace nada!!!! No solo es decir ha esto esta mal q se pudran todos!!l la pregunta es que hacemos para que esto cambie!!!!

    Imagen de ezamudio

    PFFF

    Sí claro porque sucede que el único lugar en la Tierra donde fracasan los proyectos de software, es en México.

    Sólo en México hay sistemas tan mal hechos que alguien decide mejor reescribirlos en algún otro lenguaje/plataforma porque ya son inmantenibles. Y los programadores mexicanos somos los únicos que cometemos errores garrafales y trabajamos en el caos total; el resto del mundo es ordenado y metódico.

    Ve a TheDailyWTF.com y lee un par de historias, para que veas las estupideces que se cometen en Europa y USA. No es ningún consuelo, pero estás diciendo que en México estamos jodidos en sistemas y citas las razones como si fueran únicas a nuestro caso cuando en realidad son las mismas que en otros países. Si acaso excepto la educación, que bueno ya te corrigieron de que no en todas las universidades de México está mal, y además podemos ver que en otros países aunque tengan egresados del MIT eso no los exime de hacer estupideces.

    Imagen de WinDoctor

    ???

    No había leido los comentarios, pero....

    ¿En que lugar dije que México es el único lugar donde fracasan los proyectos? Por el contrario, cite a John Avellanet de un estudio del fracaso de software hecho a nivel mundial. Con todo el respeto que me mereces ezamudio, me parece que ni siquiera has leido completa mi publicación que es algo extensa quizá ó si la has leido no estoy seguro de que comprendieras el contexto, quizá convenga que me indiques una sola parte donde dije que en México solo se cometen errores?? :o

    bferro,
    ¿En que momento generalice al sector académico? Por un lado, cite material de un profesor investigador llamado Daniel Tapia que esta dentro del SNI nivel 1 y tuve la oportunidad de tomar clase con él. Por lógica, eso quiere decir que no generalizo. En una parte comenté "yo mismo he vivido la ineptitud de mucho".... jamás dije TODOS.

    El contexto de la publicación es extremadamente sencillo. Jamás dije que solo aquí cometemos errores garrafales, ni siquiera toque temas de codificación o arquitecturas, simplemente he dicho que mientras en otras universidades como la carnegie mellon, enseñan otras cosas como PSP/TSP (que tampoco comparto), en México se sigue enseñando el modelo en cascada y solo eso! Si consideran que generalizo por que el 90% de las universidades lo hacen, entonces me declaro culpable.

    Yo no estoy hablando de que los egresados del MIT, de la universidad de san paulo, de la unam o del Tecnológico de Pachuca cometan o no errores, yo estoy hablando sencillamente que en México, el sector académico en términos generales, (que por lógica siempre hay excepciones para que nadie se sienta ofendido) les gusta enseñar cosas obsoletas y sin mucho sentido. Para mi proyecto de titulación, mi asesor nos pidió unas cosas llamadas Diagramas de Contexto los cuales son absurdos.

    En conclusión, mi artículo en todo momento dice que en México las Universidades se preocupan más por otras cosas que en educar, las empresas tienen que educar en lugar de "reforzar" lo ya aprendido y aplicarlo para su beneficio propio y esto es algo que no digo yo, sino varios directivos de importantes empresas en México con los que he platicado. Quizá el título del artículo es el que falla en todo momento y basta con que lean solo el primer parrafo para que emitan una crítica a mi artículo cuando en ninguna parte he dicho lo que ustedes comentan!

    Imagen de WinDoctor

    AHHH

    Y con lo anterior no estoy diciendo que estoy pensando que aplicar las metodologías ágiles ya resuelve el problema. El artículo era una crítica constructiva al sector académico, la idea también era escribir una segunda parte donde mencionaba mi opinion del sector empresarial a donde se siguen cometiendo muchas prácticas burocráticas y obsoletas en la pàrte de sistemas, pensando que haciendo documentos extensos, recabando firmas y utilizando herramientas de IBM para checar las horas trabajadas por nosotros, con eso se consigue un mayor control.

    Como decia Emilio Osorio en una de sus conferencias.... Es absurdo pensar que cuando algo falla en el proyecto de software, es por qué necesitamos una capa más de control y rigidez, cuando en realidad las cosas son tan sencillas.

    Vamos señores, no se ofendan y mejor lean bien el artículo :)

    Imagen de luxspes

    Waterfall era un ejemplo de "así no", lo iterativo no es nuevo

    Interesante articulo, aunque creo que inicias con una premisa que es un tanto imprecisa:

    Antes de comenzar, debo aclarar que yo no tengo nada en contra de las metodologías tradicionales, al contrario, creo que su aplicación es muy eficiente en algunos tipos de proyectos, pero sin duda en la mayoría de proyectos empresariales, han demostrado ser ineficientes.

    Por esta razón, debemos dar una mirada a una nueva alternativa que lleva utilizándose con éxito en Europa desde hace más de 10 años!

    Bueno, empecemos por el principio, Waterfall siempre fue un error. En 1970 su "inventor" escribió de el como un ejemplo del modo incorrecto de llevar proyectos. La gente que leyó el documento con prisa interpreto como una recomendación a favor lo que era una recomendación en contra.

    Luego entonces, en realidad, el enfoque iterativo no tiene nada de nuevo. Y no tiene 10 años... tiene mas de 40 años. Creo que esto es algo que todos deberiamos de saber, especialmente cuando nos dicen cosas como "vamos a hacer esto de la forma tradicional, aquí somos conservadores y sentimos que hay que esperar a ver si esos enfoques iterativos funcionan o no en la industria", bueno, pues funcionan, y han funcionado, por mas de 40 años

    En cuanto al "éxito en Europa".. solo lo mencionas en la introducción... hasta donde se estos métodos nacieron en Bell Labs, en USA, no en Europa...

    Así pues, si bien estoy totalmente a favor de que le hagas promoción a estos metodos, no debemos olvidar su historia, no son "nuevos", son antiguos, pero gran parte de la industria (y la academia) sencillamente a permanecido ignorante a pesar de los años.

    Imagen de luxspes

    Generalizaciones: El aprendizaje es emergente

    Cierto es que generalizar apresuradamente es mala idea, yo estudie en la Universidad Veracruzana (UV), y tuve algunos maestros muy buenos, otros regulares y otros de los que prefiero ni hablar. Quiza estoy mal, pero por lo que he escuchado de amigos y familiares en diferentes universidades, y la convivencia que he tenido con profesionales del sotware en los últimos 13 años (he conocido gente que estudio en la UV, en la UNAM, en la Ibero, el ITESM, el Poli, la UVM, la UDLA, etc, etc) puedo decir que no he podido observar una correlación directa entre el lugar donde estudiaron y su rendimiento en el trabajo.

    He conocido excelencia en todas todas ellas, y malos profesionales también en todas. A la conclusión que he llegado... es que es como el sabor del cilantro. Resulta que el sabor no es una característica del cilantro... ni de la lengua que lo prueba, si no de el cilantro y cierta lengua, ¿cuantos otros alimentos no serán también así?. ¿Que es el sabor entonces? El sabor es una propiedad de que emerge de la relación entre la planta y la lengua del que lo come....

    Pasa igual con la habilidad en el trabajo, es emergente, es una función de la persona, el lugar en donde estudia, y el lugar a donde termina trabajando (y quizá muchos muchos factores mas), todos los factores contribuyen. Nos gustaría creer que es algo simple y determinado por un solo factor.. bueno, pues no lo es

    Por otro lado, y sin ánimos de ofender a nadie, lo que veo en la industria es que a pesar de las décadas que han pasado desde que Bell Labs propuso el desarrollo iterativo, me encuentro con profesionales que creen que waterfall "es la manera". Y a juzgar por los blogs y entrevistas de personajes como Kent Beck o Ken Schwaber, parece que este es un problema a nivel mundial...

    En cuanto al ambiente académico... si el enfoque ágil fuera la norma, si las escuelas lo supieran, funcionarían así: EduScrum.

    Yo no se de ninguna institución educativa (excepto la de la liga) que aplique los principios iterativos / ágiles a ese nivel, pero no quiero generalizar diciendo que es la única en el mundo ¿alguno de ustedes si conoce otro lugar que funcione así? (por que si no.. bueno, quizá habría que reflexionar... en que quizá la critica de WinDoctor no esta tan mal ubicada después de todo)

    Imagen de luxspes

    Conclusiones

    Los métodos tradicionales, siguen un enfoque utilizado en otras ingenierías como la Ingeniería Civil y Mecánica, en donde, sus problemas son susceptibles a un análisis matemático que determinará el comportamiento de un sistema bajo ciertas condiciones. En el desarrollo de software, no es posible determinar con exactitud el comportamiento de los sistemas de software.

    De hecho, los proyectos de Ingenieria Civil y Mecanica fracasan mucho mas seguido de lo que les gusta admitir. El problema es que nos confundimos. El ingeniero que diseña un nuevo carro enfrenta mil problemas, una vez diseñado, la fabricación en serie ocurre casi sin defectos. Pasa lo mismo en el software, solo que en el software el paso de "fabricacion en serie" no existe (a menos que consideremos al proceso de "quemar el CD" como la fabricación.

    Si, por ejemplo, la ingenieria automovilistica (mecanica) fuera facil, tendriamos autos hibridos hace años y no habria "bug lists" tan largas como esta. No confundamos diseño de nueva funcionalidad con fabricación en serie.

    O la ingeniería aeronáutica (en cierto sentido tambien es mecanica) y los problemas con las baterias que no terminan de quedar bien

    Los métodos tradicionales y las personas que trabajan con ellos, siguen un riguroso esquema, en donde se aleja mucho al equipo de desarrollo y al cliente. El desarrollo ágil fomenta la comunicación desarrollador/cliente e invita al cliente a ser parte del equipo, mientras que los tradicionalistas sostienen que el líder de proyecto debe ser el responsable de hablar con el cliente.

    De acuerdo... aunque recordemos que los metodos agiles son tan o quiza mas antiguos que los otros.

    Cuando los proyectos fracasan, se cree que todavía debe agregarse una capa más detallada de procesos aún más formales y definidos, de planes aún más detallados, de más documentación, de más juntas de 3 horas, de una mayor vigilancia al equipo de desarrollo y de más horas de trabajo, cuando en realidad los principios deben ser muy sencillos. [ver el artículo de Emilio Osorio]

    Tambien de acuerdo.

    Las empresas se preocupan más por tapar hoyos superficiales, por presentar un mundo de caramelo en sus desarrollos con el cliente y de obtener certificaciones aunque no entiendan como aplicarlas.

    El problema es en mi opinion, aun mas profundo que eso, muchas de esas certificaciones no esta diseñadas a partir de experiencias exitosas de desarrollo iterativo, si no que derivan de "wishful thinking", en donde se "sueña" con el enfoque rigido perfecto, siendo que estan mal desde la raiz. Asi pues, la presión por conseguir esas certificaciones "waterfalleras" es en si mismo parte del problema.

    En muchas empresas, la gerencia toma decisiones que no le corresponden y debe dejarlas a los verdaderos expertos.

    Mmmm, no lo se... a menudo si bien el desarrollador es el experto tecnico, la gerencia es la experta en el negocio, otra vez la situacion del sabor del cilantro, las decisiones deben emerger de la colaboracion entre los participantes, y no provenir de un solo lado.

    Muchas veces son estos niveles los que fijan el costo de un proyecto de software y la duración del mismo. Cuando menos lo esperamos, ya nos entregan un plan de desarrollo con fechas ya establecidas!.

    Lo cual, coincido, es una muy mala practica.

    Durante más de 10 años, los métodos formales no han dado tantos resultados positivos.

    Mas bien: Durante mas de 40 años...

    Lo preocupante de esto, es que al no dar los resultados esperados, día a día se piensa en agregar más formalidad y rigidez a su proceso.

    Mas epiciclos.

    Los métodos ágiles tampoco son la solución a todos los problemas, pero si dan unas buenas pautas para reformular las actuales ideas de la Ingeniería de Software.

    De acuerdo

    Imagen de Eduardo Vargas

    ¿Hubo una segunda parte del artículo?

    Hola Windoctor,

    Tal vez algunos piensen que este tema ya es "viejito", que lo posteaste hace varios años, pero seguimos viendo que es un tema actual, y es mejor seguirle aquí que andar abriendo temas nuevos y luego para no decir nada nuevo o bueno.

    Tienes un excelente rollo y veo que estás muy bien documentado. Trataré de enfocarme a lo importante y creo que serán ideas para tranquilizar nuestra conciencia cuando nos encontramos ante un esclavista que con cara de angelito y de buena persona, nos trata de convencer que debemos ponernos la camiseta e inclusive perder nuestra salud o morir en el intento de algo así como querer salvar al Titanic cuando ya está entrando el agua y todo porque el angelito no siguió las normas de seguridad o aceptó un puesto a sabiendas de que el barco estaba mal hecho o no tenía elementos básicos de seguridad.
    Seguramente casi ningún cliente (o ninguno) nos estará leyendo y tal vez lo mismo suceda con los dirigentes de las instituciones educativas (muchos maestros no tienen la culpa. De algo tienen que vivir)

    Esto ya lo he comentado como réplica a varios posts que han surgido sobre el tema. Al menos en México, las causas del fracaso de la mayoría de los proyectos de software se deben a corrupción.

    Nos mostraste algunas causas del fracaso: Planeación deficiente, y... ¡vaya! encontré que prácticamente todas las causas que pusiste se deben a una mala planeación. Y, ¿cuál es la causa de la mala planeación? En México, la mayoría de las veces es: corrupción. No siempre, pero la mayoría de las veces dicen no tener tiempo para planear, pero no contratan más gente que participe en la planeación porque se tienen que estar clavando la lana. Quieren maravillosos proyectos, pero que no les cuesten mucho porque si no, entonces ya no se pueden clavar la lana para satisfacer sus vicios. Siquiera se clavaran la lana para cosas buenas.
    .

    Concuerdo contigo y con los autores que has citado en que es imprescindible una Ingeniería de Desarrollo de Software y que esta ingeniería no debe ser rígida, al menos en la mayoría de los casos. Tal vez sí se deba ser rígida si van a sacar la nueva versión de Windows, Java 12, o la última versión de ORACLE, pero la mayoría de los proyectos no son así, así que puede resultar perjudicial mucha rigidez o mucha flexibilidad.

    Sigo pensando que a la construcción de software no se le pueden aplicar en forma estricta la ideas y controles que se tienen para construir un auto, una casa, un puente, etc.; porque la mayoría de los proyectos de software requieren de ideas innovadoras o necesitan que se hagan cambios durante el desarrollo del proyecto. Nada más imagínense que estuvieran construyendo el 2o. piso en el Distrito Federal y que a la mitad del proyecto salieran conque los carriles los quieren más anchos, o que los hicieran con otro material, o que fuera "más altito" o "más bajito" y estas lindezas se dan con demasiada frecuencia en el desarrollo de software.
    .

    Sobre la metodología "ágil" y el deseo de los expertos de interactuar directamente con el cliente, pues a veces es conveniente y a veces es inconveniente. Hay proyectos enormes en donde va a ser muy impráctico y contraproducente que todos los genios y estrellas que están programando en java se pongan a intercambiar ideas con el cliente. Alguien tiene que coordinar y si la mayoría de las veces los coordinadores o líderes son un estorbo, no es que esté mal la idea de que haya líderes de proyecto que interactúen con los clientes, sino que la planeación es pésima y no se ha contratado a buenos líderes de proyecto.

    Y sobre lo "ágil", pues ya muchos autores opinan que a simple vista se podría tener la idea de querer programar como se hacía al principio, sin metodologías. Claro que no se trata de eso; pero es más o menos lo que se hacía en la niñez de la computación, en donde no había proyectos tan grandotes, tan complejos y la necesidad de que se hicieran en un tiempo tan corto debido a que se quieren robar una lana tan grande. Se hacían prototipos, el programador interactuaba directamente con el cliente, el programador mismo era el líder y muchas veces el prototipo se quedaba como producto final.

    Otra cosa que es causa principal del fracaso de los proyectos: La falta de documentación de los procesos que se desean automatizar. Claro que esta falta de documentación obedece a la causa principal: Corrupción. No querer pagar gente que documente o, por corruptos, no poder quitarle el poder que tiene la persona experta que con los años se ha hecho mañosa y no quiere soltar la sopa de lo que sabe.
    .

    Bueno, y... ¿sí hubo segunda versión de tu tema Windoctor, o te desanimaste porque muchos no te entendieron debido a que no te leyeron bien e interpretaron otra cosa?

    Saludos,

    style="display:inline-block;width:728px;height:90px"
    data-ad-client="ca-pub-5164839828746352"
    data-ad-slot="7563230308">