Cuanto mas rápido empieces a programar más tarde terminaras

Que tal Israel, pues es un tema interesante y algo de lo que más me apasiona aunque claro soy un novato en ello.

Te confieso que soy enemigo de varias de las ideas que compartes. El desarrollo de software erróneamente se ha tratado como otras Ingenierías como la Mecánica y la Civil, en donde sus problemas si son suceptibles de un análisis matemático y un modelado, "Si aplicamos X fuerza, obtendremos Y resultado" y entonces simulamos un comportamiento que seguramente si pasara en la realidad, de ahí que la filosofía es "Predictiva".

El 90% de los proyectos de sw son dinámicos (no predictivos), es decir, no hay requerimientos estables y es un error hacer un análisis detallado del problema con modelos de dominio, diagramas de flujo, diagramas de contexto, UML, Casos de Uso, etc., Así mismo veo como una perdida de tiempo el desarrollo de una "Arquitectura de Software" detallada. Al inicio, los diagramas de clases, componentes, etc,, se ven bien en papel, pero al momento de codificarlos, surgen dudas, problemas y muchos cambios, por lo cual es dificil predecir una arquitectura detallada.

El problema de las prácticas y teorias que mencionas, es que en primera instancia, la lógica es estupenda, suenan bien, se escuchan obvias... "Ah primero analizo bien y luego codifico... OBVIO!!!"... pero en la realidad esto es terrible, los requerimientos cambian mucho, y los Casos de Uso que al inicio se detallaron mucho, al final de un proyecto de 2 años, quedan por completo desactualizado... ¿volverlos a actualiza?... ups, que lio, el que los desarrollo ya ni trabaja en la empresa! Incluso hasta el Líder de Proyecto puede cambiar!

El hecho de que las empresas gasten mucho dinero en licencias de Microsoft Project para sus planeaciones detalladas, es absurdo! O será que un Gannt puede hacer la diferencia en que un proyecto sea o no exitoso?

Te cuento que hace aprox 1 año y medio, quise creer en muchas de las teorías y prácticas de la Ing de Software, en una empresa muy pequeña donde trabajaba, llego el punto en el que incluso quise creer en el Personal Software Process y aplicarlo, después de todo dije, "Lo ideo el Dr. Watts Humphrey!! el creador del CMMI.. debe funcionar"... al paso del tiempo, me di cuenta que era una perdida de tiempo.

Concuerdo bastante bien con los principios Ágiles, Scrum&XP, varias filosofías como la de Lean Software Development han sido bastante funcionales en transnacionales como TOYOTA y eso ha dado como resultado que sea TOYOTA el maximo fabricante de Autos y el número 1 en calidad y atención a clientes, gracias a su modelo empleado y que ha sido pasado al desarrollo de SW y popularizado por los esposos Poppendieck.

Hay artículos interesantes de eminencia como Martín Fowler (The New Methodology) y Tom DeMarco (La Ingeniería de Software ¿Una idea Obsoleta?) donde cuestionan seriamente las prácticas actuales.

Hace tiempo, pegue un artículo aquí de mi blog, donde recopilo ideas que algunos autoridades en el software han vertido en los últimos años,

Saludos!!

Muchas gracias por tus comentarios y la información de tu blog.

Como bien lo dices, no hay metodología que pueda ser absoluta y tampoco se trata de entrar en una parálisis de Análisis, sino de equilibrar los esfuerzos
y llevar en porciones objetivas el desarrollo del proyecto, tal que te permita ir adaptando los cambios que se vayan necesitando. Tratar de definir todo el detalle al inicio es realmente es complejo y no recomendable caundo los proyectos tienen una complejidad media a alta, por eso existen las iteraciones (Iteraciones incrementales) pero bien controladas, apoyadas por técnicas de integración continuas (muy aplicadas en los desarrollos de open source). Por otro lado los proceso solo es el mecanismo por el cual se le da cierto orden al trabajo no deben de determinar cuanto debe desarrollarse, sino como establecer la comunicación efectiva tal que permita fluir el trabajo.

Es muy común que los desarrollo en México se hagan en cascadas muy extensas (mayor a 6 meses) y debido a ello los procesos se vean muy burocráticos y densos; eso normalmente se le debe a los PM´s o Líder de proyecto por falta sensibilidad con las actividades de desarrollo, de visión y abstracción del sistema; es ahí donde quien ha trabajado desde la trinchera quien debe de apoyar en las decisiones y recomendar como entregar el producto, los programadores, diseñadores y arquitectos de software ellos son los que pueden tener mejor perspectiva de lo que hay que hacer, por ello manejar las Iteraciones de manera multidisciplinaria permite proveer el valor agregado al cliente. Lamentablemente hay fuerza económicas o inclusive políticas que no dejan que los equipos exploten el potencial creativo que tienen.
El Rol de Análisis esta muy devaluado en México, ya que quien lo realiza son personas que no han tenido experiencia en el campo, que no tienen una mentalidad analítica y mucho menos de abstracción, el poder conceptualizar los modelos de objetos utiles para desarrollo ni pensarlo.
El Análisis no debe de dejarse en manos de solo una persona, esto debería de trabajarse en conjunto tanto con el Experto del dominio como los equipos de trabajo (Arquitectos, diseñadores o líder técnico además de los lideres de pruebas) acordando la cantidad de funcionalidad, niveles de servicios y esfuerzos que se aplicaran.

Pero bueno, mi objetivo no es evangelizar en una metodología u otra, sino compartir e intercambiar vivencias tales que nos permitan mejorar y fortalecer las prácticas de desarrollo en México, ayudar a quienes van comenzando que sepan que el desarrollo de software no es solamente codificar,sino que hay un sin numero de tareas alrededor de ello y que solamente con equipos altamente preparados y sincronizados es cuando disfrutas y vives plenamente el desarrollo; de otra manera se vuelva un kaos de frustaciones.

Precisamente el punto es que las metodologías y prácticas predictivas son complejas de aplicar y seguir, que su utilización apenas si es recomendable a ciertos tipos de proyectos, por ejemplo, proyectos de la NASA deben ser bien planeados y sus requerimientos son casi fijos, por lo tanto las metodologías predictivas son las mejores.

Los que me conocen, generalmente saben que soy objetivo, por ejemplo, soy javero de corazón, pero he programado en .NET y me gusta la plataforma! Es decir, no creo que Java es lo mejor! Sin embargo, en definitiva que desde mi punto de vista y desde las estadísticas, entiendo que los desarrollos de software han fracasado por muchos años utilizando prácticas tan formales y pesadas.

Los principios ágiles centran su atención en las personas, en el equipo de trabajo antes que procesos (ver manifiesto ágil). La Integración Continua, las pruebas unitarias y la programación en pares son prácticas que nacieron en el agilismo.

Saludos!!

Muchas veces (cómo comenta WinDoctor), las metodologías están orientadas de diferente manera. En la comunidad Ruby se habla mucho de que en varias plataformas (entre ellas Java) son ideadas para tener contentos a los programadores y no a los clientes.
Creo también que para la mayoría de proyectos es bueno usar metodologías ágiles y herramientas (frameworks) que se enfoquen en máxima productividad. Una experiencia personal es con un software, que lo podemos llamar fork. Este software lo realizaban en cierta organización, pero cómo el código le pertenecía a mi jefe decidió hacer un fork. Este proyecto se empezó en Struts y llegamos a un punto en que nuestro software mejoró demasiado con respecto a la versión de dicha organización. Sin embargo hace 2 semanas empezaron a hacerlo en Ruby on Rails; ahora la organización nos lleva una ventaja tremenda. Sin embargo mi jefe dice: "¿para que reescribir?, hay que dejar eso deprecated, y hacer las cosas nuevas en otra cosa."; pero creo que no toma en cuenta el valor integración (por ejemplo si las nuevas cosas están en python o ruby o incluso algún otro framework java).

En fin, casos hay muchos; soluciones hay muchas, pero los jefes a veces toman decisiones muy (¿)obtusas(?).

Muchas veces (cómo comenta WinDoctor), las metodologías están orientadas de diferente manera. En la comunidad Ruby se habla mucho de que en varias plataformas (entre ellas Java) son ideadas para tener contentos a los programadores y no a los clientes.

Que curioso, en varias comunidades de Java, se habla mucho de que en varias plataformas (entre ellas Ruby) son ideadas para tener contentos a los programadores y no a los clientes.

Sin embargo hace 2 semanas empezaron a hacerlo en Ruby on Rails; ahora la organización nos lleva una ventaja tremenda. Sin embargo mi jefe dice: "¿para que reescribir?, hay que dejar eso deprecated, y hacer las cosas nuevas en otra cosa.";

No entendi... reescribir es dejar lo viejo deprecated, y hacer las cosas nuevas en otra cosa... que es lo que quiere tu jefe? hacerlo todo de nuevo? o ir componiendo lo que ya tiene?

Ojo, CMMI no es incompatible con las metodologías ágiles, se pueden hacer ambas correctamente.

También hay que recordar que una mala administración hará que un proyecto falle sea cual sea la metodología que se utilice.

No creo que la ingenieia de sw este obsoleta pienso que nos falta madurar un poco mas, me encuentro trabajando en una empresa con CMMi y el proceso de software que llevamos es basicamente lo que menciona Israel-69 en los temas que propone y nos a funcionado, hacemos diagramas y demas cosas (analiisis, diseño, diagramas de todo), el problema con la ingenieria de software o con las metodologias como CMMi esque piden evidencia de todo y ahi es donde las cosas se ponen feas, por ejemplo si estamos usando una libreria para hacer alguna funcionalidad y si a medio codificar nos damos cuenta que no nos funcionara para funcionalidad que equeremos realizar, me tardo mas documentando que voy a cambiar la libreria por otra y hacer revisiones y evidenciar el porque del cambio que recodificar el trabajo ya echo. O si el cliente pide un cambio nos tardamos mas "documentando" el cambio que realizarlo. En mi opinion y experiencia eso muy particular en mi caso es uno de los problemas de la ingenieria de sw, como que a las empresas son muy borucraticas en esos asuntos.

Oscar,

Se que dentro de la agilidad hay quienes intentan utilizar CMMI y principios Ágiles y claro que es válido, hay podcast donde se habla de ello, pero toma en cuenta lo siguiente:

- Se intenta combinar CMMI y la Agilidad por que CMMI es algo tan "Pro" que aquella empresa que tenga un CMMI nivel 2 en adelante ya muchos dicen "Wowww" y los directivos en primera ni saben que es CMMI pero como es algo "Pro" pues lo quieren implementar.

- Como la tendencia es CMMI gracias a que tiene un gran respaldo como el SEI, obviamente los directivos y Gerentes no se van a animar a dejar CMMI y cambiarlo por la Agilidad, así que muchos de ellos dicen "Ok,.. CMMI no me da los resultados que yo espero, vamos a probar la Agilidad, pero no puedo dejar CMMI por que es un buen anzuelo para los clientes", de ahí que muchos agilistas se vean en la necesidad de combinar CMMI.

Como lei hace tiempo un artículo en Navegapolis.net ¿Es posible tomar Cafe y Té de Tila al mismo tiempo? Por un lado el Cafe me quita el Sueño y por otro el Té de tila es para el insomnio, lo tomamos al mismo tiempo?

Una cosa es tomar ideas de principios ágiles a CMMI y viceverza y otra muy diferente es que ambos trabajen en conjunto! En México, las empresas ni siquiera tienen la capacidad de implementar CMMI por lo pesado que es, el mismo SEI se dio cuenta de ello y como sabe que es un buen negocio, tuvo que idear algo como el PSP/TSP que ayudan a las empresas como las existentes en México y la mayor parte de LatinoAmerica a ir gradualmente alcanzando la madurez con el paso de los años para llegar a un CMMI.

Luiguisf,
Correcto, las empresas son burocráticas, pero en el caso del desarrollo del SW, las mismas consultoras son burocráticas por que el mismo CMMI es burocrático.

¿Por que cuando un proyecto fracasa, se sale de tiempos, tiene muchos errores, aumenta su costo, etc., siempre se piensa en que hubo una mala planeación, en que no se limitaron los requerimientos, en que es necesario agregar una capa más de rigidez en procesos, hay que hacer más documentos de análisis, hay que recabar más firmas del cliente? ¿Por qué?, en realidad los principios son más sencillos (ver principios de Lean Software Development).

Saludos!!

Por cierto,

Cuando se tiene un excelente equipo de desarrollo, una metodología ágil o formal no necesariamente es la que hace el éxito de un proyecto, incluso se puede CASI se podría presindir de ella. Pero como sucede generalmente, los equipos son generalmente mixtos, habemos muchos novatos en el desarrollo por lo cual requerimos ir creando habilidades mediante principios ágiles o formales.

Si hubiera un equipo donde estuviera ezamudio, benek, OscarRyz, de un proyecto medio-alto en complejidad, seguramente no se necesitaria mucha metodologia, pero como no todos los equipos son de ese calibre, necesitamos apoyarnos de ciertos procesos y principios, que en mi caso estoy convencido, los que mejor funcionan son los ágiles!

Jejeje...pues a mi no me a tocado ver un tema en Javalobby o en cualquier foro de Java en donde se hable de Ruby de esa manera; lo que he encontrado en Java con respecto a Ruby son muchas críticas, la más común: "Ruby es un lenguaje de juguete". En fin no entra de todo en este trapo.

Con la experiencia del software en donde trabajo, es que la otra organización (que hace un software parecido al de nosotros) comenzó utilizando Ruby on Rails (hace 2 semanas) y ya tienen un software casi tan completo cómo el de nosotros. ¿Qué cambios hubo?: De Struts (1) a Ruby on Rails; de planeación similar a la que se plantea en este post por una planeación en base Ágil (XP & Scrum). Y hablando mi jefe y yo le dije: "Sería bueno que cambiaramos de framework, no a RoR; puede ser Roo o Play o AribaWeb, para no tener que reescribir cosas cómo los modelos."; a lo que el me dijo: "No, lo que ya está hecho hay que dejarlo deprecated y lo nuevo hay que hacerlo en otra cosa."

¿Reescribir sería en vano?: Desde mi punto de vista no lo sería ya que de los clientes mi jefe ha recibido quejas así tal y cómo lo escribiré: "Tu sistema no nos gusta, de plano no lo queremos usar" ó (esto me lo dijo un conocido mío de hace años que es cliente de este sistema) "No te preocupes sí no tienes tiempo de hacer los cambios; al fin que nadie en la empresa usa el sistema". Digo, en este caso el ser purista orientado a objetos y (en varias ocasiones) sin hacer "código JSP" que nos podría salvar en el momento (para tener contento al cliente) y después buscar la manera de hacerlo bien con Struts. Por lo que si un sistema no gusta hay que ver los requerimientos de los clientes (obviamente, no reescribiremos a cada cliente; y los clientes actuales que se queden con la versión actual); el problema que veo es que a la gente no le gusta, por lo tanto hay que hacer algo que les guste.

O tú luxspes que tienes más experiencia, ¿cómo lo ves?

PD: No tendrás entre tus curiosidades algún libro de AribaWeb que me puedas recomendar, porqué la documentación del sitio de Ariba no está terminada o son ejemplos muy simples. Saludos.

Sorry que difiere de tú último comentario y con el respeto que merecen cada uno de los miembros que mencionas; la probabilidad de éxito de un proyecto sin haberse identificado s sus objetivos y acordado el alcance con las partes es casi nula (labor de Análisis).
Que seguro que por su experiencia alguien del equipo tomaría dicho rol, para asegurar que el trabajo de los demás tenga un fin común.
Por el comentario de “Poca Metodología” no estoy seguro si te refieres a crear menos artefactos o menos burocracia, pero de que abría un metodología en su desarrollo, seguro y mucha, pero la diferencia estaría en la fluidez de la comunicación que es lo que lo que los Ágilistas buscan.

Por algún lado leí una comparación entre CMMi y las metodologías Ágiles, indicaban que la última tenia un mayor grado de complejidad para su implementación(no documentación); que esto lo puedes salvar cuando el equipo de trabajo tiene una amplia experiencia en las mejores prácticas así como un alto grado de disciplina.

Ágil no es igual a Fácil.

Saludos

Pues con lo que dices del "dreamteam" de JavaMexico no creo. Recuerda que en un equipo no importa las individualidades de cada quien, sino el trabajo en conjunto. Esto pasa en el rubro que quieras, no sé incluso lo podemos ver en fútbol que no es garantía tener en un mismo equipo a los mejores jugadores del mundo. De lo contrario en la liga española siempre ganaría el Real Madrid, por decir algo.

A lo que voy es, no importa las genialidades individuales de cada miembro sí estas no se pueden mezclar. No digo que un equipo de las personas que has mencionado fallaría, pero no porqué estén ellos es un éxito garantizado, porqué quizás (no sé la verdad cómo trabajen) ellos ya son líderes de un equipo y cuando hay más de un líder en un equipo es más difícil.

Considero que un buen equipo no es el que más conocimientos tiene, sino el que mejor se sabe autodirigir, coordinar y delegar tareas.

El comentario va al "Casi", es decir, si, hay una labor de análisis, esto siempre es así, la diferencia es que el hacer un análisis y definir un alcance del proyecto no supone estar usando una metodología, al menos no un RUP u similar, más bien sería una metodología "propia". Analizar el proyecto y definir alcanses en cada etapa deben ser algo que se tome por norma.

Ágil = principios fáciles de diger
Ágil != Principios fáciles de aplicar

Formal o Predictivo = Principios dificiles de digerir y aceptar.
Formal o Predictivo = Principios dificiles de aplicar.

Los principios ágiles no son para todas las personas, pero con la ayuda de un experto si es posible implementarlo con cualquier equipo, solo es cuestion de dejar de pensar de forma "formal o predictiva"

Saludos!

Antes que nada, gracias por aquello del "dreamteam" jajajajajajaja, me hicieron el día.

En mi experiencia, sí he podido trabajar un par de ocasiones en equipos formados exclusivamente por gente con mucha experiencia. Equipos pequeños hechos para sacar adelante un proyecto considerado muy difícil o importante. Y aunque ciertamente no se avientan por la ventana todas las metodologías, por la experiencia de los integrantes lo que termina pasando es que se crea una especie de metodología ad-hoc al proyecto, mezclando lo que cada uno conoce y puede aportar al equipo. Al principio se discute acerca de si seguir una u otra metodología, las tecnologías a usar, etc. La metodología no se lleva de manera tan estricta en cuanto a burocracia pero sí hay que ir dejando algo de documentación, porque finalmente son cosas que ayudan a corregir y prevenir errores. Ahora, algo importante es la forma de dicha documentación. No siempre son tal cual archivos .doc con un chorazo y una bola de diagramas; a veces una simple prueba unitaria y comentarios en el código pueden ser documentación suficiente para un módulo sencillo.

Lo que sí es muy cierto es que la comunicación es muy importante, y la diferencia principal que he notado en equipos tipo "dreamteam" es que nadie duda en expresar inquietudes, dudas, preguntar acerca de lo que no se conoce, admiitir que no se tiene experiencia o conocimiento de alguna tecnología que se va a usar, o de un algoritmo, etc. Y eso ayuda mucho porque los demás ayudan a resolver el tema. También hay mucha proactividad en cuanto a investigación para poder encontrar las mejores opciones de lo que se va a usar para el desarrollo, la arquitectura del sistema, etc. Y aunque varios hayan tenido ya experiencia como líderes, queda muy claro que en ese equipo para ese proyecto hay un líder, pero a ese líder también su rol le queda muy claro y no es que se sienta superior a los demás, sino que simplemente es quien tiene que estar coordinando ciertas tareas con otros involucrados en el proyecto (el cliente, jefes, proveedores, etc) y no duda en consultar a los miembros del equipo cuando tiene alguna duda o inquietud. Manejando las cosas de manera más transparente es que se pueden lograr mejor las cosas.

En equipos donde nadie tiene experiencia a veces se quedan paralizados como de miedo y esperan que alguien de fuera venga a ayudarlos de alguna forma. El líder tiene miedo de exponer falta de conocimiento o experiencia; los demás tienen miedo de admitir ignorancia de algun aspecto del proyecto, etc.

En equipos donde hay uno o dos miembros con amplia experiencia y los demás tienen muy poca experiencia, muchas veces pasa que los más novatos en vez de aprovechar el conocimiento de los más senior, les tienen algo de miedo y se tardan mucho en preguntar cómo hacer algo. A mi me tocó algunas veces en equipos así que de repente llegara un programador super preocupado a decirme que no tenía idea de cómo hacer algo... le decía "por qué no pruebas de tal o cual manera, o simplemente hazle así" y luego salían con que "ah muchas gracias, sí, eso voy a hacer, qué bueno que te pregunté porque llevo 3 días atorado intentando de esta forma y no sale" y ahí sí yo ya me enojaba, "por qué no me preguntaste hace 3 días? ya perdiste 3 días y eso va a causar un atraso en otras cosas, entiendo que quieras aprender por tu cuenta pero ahorita tenemos un calendario muy apretado", etc. O a veces si oyen que uno de los senior dice que no tiene idea de cómo hacer algo, se apanican, como que piensan que si el senior no sabe, ellos menos van a poder resolver esa parte, en vez de simplemente ponerse todos a investigar la manera de resolver las cosas.

Todo eso a fin de cuentas se resuelve teniendo una buena comunicación entre los miembros del equipo. Creo que siempre es bueno preguntar cuando hay dudas, a ver si los demás tienen una mejor idea de cómo resolver el problema. La finalidad de cualquier metodología es estandarizar los procedimientos que realizan los miembros de un equipo en un proyecto, precisamente para tener una especie de lenguaje común. El propósito ya puede ser distinto en cada metodología... algunas van orientadas a mejoramiento personal, que lleva al mejoramiento del equipo (por ejemplo PSP/TSP aunque son muy engorrosos, al final tanta estadística te permite conocerte mejor como programador, sabiendo la velocidad a la que programas, la cantidad de defectos que insertas en tu código, el tiempo que te toma corregirlos, etc). Otras metodologías están más bien orientadas a que la gente sea intercambiable o tratan de sustituir la falta de talento para poder llegar al concepto de "fábrica de software" donde idealmente cualquier programador puede participar en cualquier proyecto haciendo cualquier parte de la programación porque todo ya fue super digerido y super bien definido por los arquitectos. Pero todo es ya es otra historia.

Seria genial si comentaran sus experiencias así como lo ha hecho Enrique, digo, muchos ya han trabajado como líder o como miembro de un equipo.
Creo que seria un aporte de conocimiento muy bueno, es mas creo y que hasta seria mejor que ponerse a comparar metodologías. Pues con experiencias
ya son pruebas y hechos.
Saludos.

que "estadística" no es el plural de "anécdota". Porque podemos contar historias de cómo nos fue muy mal en un proyecto llevando X metodología, pero eso no significa que X sea mala; puede que estaba mal implementada, que no se supo coordinar, que faltaron recursos, que no era la apropiada para ese tipo de proyecto, o simplemente circunstancias externas causaron esa mala experiencia. Igual cuando alguien dice que le funcionó muy bien Z en otro proyecto, no significa que sea infalible. Se necesitan datos consistentes.

Pero sí estaría interesante escuchar algunos puntos de vista de experiencias que se han tenido con distintas metodologías.

Saludos,

Soy nuevo en esta comunidad ( de hecho no soy de mexico, sino de Rep. Dom).

He leido el contenido de esta discusion casi completa, y debo felicitarlos... Veo que tienen mucho conocimiento y sobre todo muchas experiencias.

Mi mayor experiencia en el desarrollo (otra cosa en contra) es con .net y poco profesional, pero creo que el desarrollo presenta los mismos problemas no importa el lenguaje que uses.

He notado que los proyectos en los que uno se dedica de inmediato a codificar, se les complica como bien explican algunos. Pero, tambien me ha pasado que cuando se planifica mucho un proyecto, se hace dificil cubrir todo el campo.

Cuando no se tiene mucha experiencia (y me atrevo a decir que aun cuando se tiene mucha), los problemas seguiran latentes. Pues imaginar y diseñar cada detalle, es un poco dificil. Un buen diseño de software depende no solo de tu habilidad como programador, sino tambien del conocimiento que tengas del proceso y del area a la cual estará destinado soportar el software en cuestion.

Por lo que estoy de acuerdo en que el exito va a depender de una buena combinacion entre metodologia, habilidades, experiencias y tecnicas de desarrollo adecuadas.

Por otra parte, lo que dice Zamudio, es totalmente cierto. Los integrantes de un equipo pueden sentir que si no saben o no estan claros en algo, seran considerados incapaces. Se resuelve con un buen manejo del lider y fomentando la confianza y el trabajo en equipo.

En definitiva, quiero felicitarlos. Pues, veo que han creado una organizacion que promueve la interaccion y la investigacion, para desarrollar y soportar una comunidad de profesionales que permitirá el avance del desarrollo a nivel profesional.

Saludos.

Con la experiencia del software en donde trabajo, es que la otra organización (que hace un software parecido al de nosotros) comenzó utilizando Ruby on Rails (hace 2 semanas) y ya tienen un software casi tan completo cómo el de nosotros.

Bueno, no se de que se trate tu aplicacion, pero lo que si se es que Struts 1.x es de los frameworks mas dolorosos de usar, y te obliga a dar muchas vueltas para hacer cosas muy simples, asi que tal ves si deberian pensarn en cambiar a algo mas agil como Ariba, Roo, Play o Seam ( o como quiza Spring-MVC que quiza no tiene tanto factor Wow, pero es una framework muy solido y que da muy buenos resultados con poco esfuerzo)

Desafortunadamente, que yo sepa, todavia no hay libros de AribaWeb :'-(

Por otro lado. que version de Struts esta usando? por que de Struts 1.x a Struts 2.x hay muchos pero muchos cambios y la experiencia de desarrollo mejora mucho y probablemente seria una trancision mas natural para ustedes

¿Reescribir sería en vano?: Desde mi punto de vista no lo sería ya que de los clientes mi jefe ha recibido quejas así tal y cómo lo escribiré: "Tu sistema no nos gusta, de plano no lo queremos usar" ó (esto me lo dijo un conocido mío de hace años que es cliente de este sistema) "No te preocupes sí no tienes tiempo de hacer los cambios; al fin que nadie en la empresa usa el sistema".

Bueno, algo que es importante recordar es que no por esta hecho con Ruby, con Ariba o con Struts es garantia de que le guste o le deje de gustar al usuario, si no le esta gustando el sistema los usuarios, tal vez deberian de examinar como usar el usuario el sistema, y que tareas le esta resultando molestas, innecesariamente complicadas o innecesariamente repetivas y buscar mejorar el diseño de la interfaz (que es con lo que los usuarios interactuan mas) antes de decidir rehacerlo en otra tecnologia, seria muy importante tener evidencia clara de que es lo que hay que mejorar, por que sistemas desagradables para los usuarios, se puede construir con cualquier tecnologia.

Estoy de acuerdo con lo que comenta Zamudio, como lo comenta en su experiencia, una parte fundamental en el éxito de un proyecto es la Comunicación, algo que es fundamental en los principios ágiles, mucha comunicación entre el equipo y alguien capaz de hablar con el cliente. Cuando se tiene un equipo de ese calibre, una metodología formal prácticamente no es utilizada y la metodología "propia" que utiliza el equipo es más parecida a una filosofía ágil.

Perdon por ensañarme tanto con las metodologías formales, pero de verdad, no les miento que hace 1 año y medio aun creía en ellas, pero a la fecha me dan mucha flojera.

El error esta en que los tradicionalistas, piensen que en lo Ágil no se documenta, claro que hay documentación, pero se tiene la idea que la mejor documentación son las pruebas unitarias y el código comentado, más allá de documentos en Word (que también los hay).

Quizá el día de mañana les cuente mi experiencia en el anterior trabajo donde estabamos certificamos en MoProSoft!

EZamudio comenta: "pero eso no significa que X sea mala; puede que estaba mal implementada,"... Quizá si son buenas pero insisto en que las prácticas formales y rigurosas inyectan solo malos hábitos que a primera vista parecen buenos, pero son "habitos" que no aportan ningún valor al cliente y el resultado final es un Sistema con varios defectos, medio que funciona, y con mucha documentación que el Cliente no utiliza y que cuando se trata de dar mantenimiento al Sistema, quien lo hace no Lee la documentación, prefiere ver el código, pero ohh sorpresa, el código no esta comentado!!

La concepción del Software es experimental, es dinámico, y una metodología que intenta "predecir" y limitar los cambios tratandolos como "incidencias" es algo que seguramente fallará ó si no falla, el resultado será un cliente no satisfecho x ke tiene algo que no pidio o no esperaba!

Por muchas cosas estoy de acuerdo con TomDemarco y su idea de si la Ing de Software es una idea obsoleta,

¿Quien es TomDeMarco?

SI LA RELATIVIDAD, ES VISTA DESDE UN PUNTO TETRADIMENSIONAL PUDIERA SERLO. PERO PREFIERO LA REINGENIERIA, Y LA REUTILIZACION, SI REINVENTAR ES EL CAMINO ENTONCES SE JUSTIFICA SINO ES UNA PERDIDA D TIEMPO........

Gracias por responder.
Primero que nada, sé que no es factor de éxito de un software en qué lenguaje está escrito. Sin embargo a lo que me refiero es máxima productividad y buena respuesta a cambios; es por ello que a nuestros clientes no les parece buen software. Consideran que tardamos mucho en corregir errores o darle mantenimiento, que si lo hacemos, sin embargo considero que con otro framework -de los que has mencionado- seríamos capaces de hacer las cosas en menos tiempo.

Actualmente usamos Struts 1.3.8 (si mal no recuerdo); y secundo tu opinión: "pero lo que si se es que Struts 1.x es de los frameworks mas dolorosos de usar, y te obliga a dar muchas vueltas para hacer cosas muy simples". Sin embargo no considero buena idea movernos de lenguaje pero si de framework, con ello podemos conservar muchas cosas (principalmente los modelos y los algoritmos de los controladores). Así cómo también considero que en nuestro caso aplicaría más una metodología ágil en lugar de la "monástica" que estamos usando actualmente (de este proyecto nació mi odio hacia JavaEE).

¿Cómo lo ves?

Cómo muchas veces ha comentado luxspes todo es en función del contexto. Habrá proyectos en los que reescribir sea necesario, otros en los que no, todo depende del contexto.

Primero que nada, sé que no es factor de éxito de un software en qué lenguaje está escrito. Sin embargo a lo que me refiero es máxima productividad y buena respuesta a cambios; es
por ello que a nuestros clientes no les parece buen software.

Es posible, aunque en realidad, si lo que te dicen es que "Tu sistema no nos gusta, de plano no lo queremos usar" ó "No te preocupes sí no tienes tiempo de hacer los cambios; al fin que nadie en la empresa usa el sistema", me suena mas al tipo de problema que se resuelve revisando los requerimientos y casos de uso del usuario, para ver por que la interfaz resulta problematica.

Consideran que tardamos mucho en corregir errores o darle mantenimiento, que si lo hacemos, sin embargo considero que con otro framework -de los que has mencionado- seríamos capaces de hacer las cosas en menos tiempo.

Tal vez, pero no olvides la curva de aprendizaje, y todo lo que el codigo existente ya sabe hacer y que al vovler a inventar el proyecto, tendras que redescubrir, ese error lo cometio Netscape, y el castigo fue la quiebra (resultado de esa quiebra, crearon una fundacion no lucrativa que años despues dio lugar a Firefox, lo cual no sonaria tan mal, si no fuera por que Netscape tenia el 99% del control del mercado de los navegadores y ahorita, Microsoft tiene mas del 88%, reescribir desde cero fue el peor error que Netscape pudo cometer).

Actualmente usamos Struts 1.3.8 (si mal no recuerdo); y secundo tu opinión: "pero lo que si se es que Struts 1.x es de los frameworks mas dolorosos de usar, y te obliga a dar muchas vueltas para hacer cosas muy simples".

Lo mas natural para ustedes, que tendria una curva de aprendizaje minima, y fuerte mejora de la productividad seria pasarse a Struts 2.x... por que no han hecho eso? Struts 2 existe de Febrero del 2007!... Inclusive ya hay version 2.2.1 de Struts...

Sin embargo no considero buena idea movernos de lenguaje pero si de framework, con ello podemos conservar muchas cosas (principalmente los modelos y los algoritmos de los controladores)

Y por que no, antes de probar con un nuevo framework, empiezan por utilizar la version mas reciente del framework que ya conocen, si estas todavia con Struts 1.x, estas trabajando con tecnologia que cuando muy nueva seria de de 2004!

Migrar de Struts 1.x a 2.x es facil, inclusive se puede usar ambas versiones del framework al mismo tiempo sin que haya conflictos (Dual processor, shared resources), y asi, conforme vas haciendo mantenimiento, puedes ir modernizando tu codigo para aprovechar las nuevas caracteristicas de Struts 2.x (que son las mismas de las que presumen todos los frameworks de ultima generacion:convention over configuration, reduccion del numero de archivos XML, uso de @Anotattions, etc, etc)

Así cómo también considero que en nuestro caso aplicaría más una metodología ágil en lugar de la "monástica" que estamos usando actualmente (de este proyecto nació mi odio hacia JavaEE).

¿Como lo ves?

Creo que les haria bien modernizar la tecnlogia, pero pienso tambien que cambiar de framework completamente podria ser un riesgo bastante grande, y me preocupa que esten pensando en cambiar de framework sin haber explorado primero la posibilidad de utilizar la version mas reciente del que ya conocen... Recuerda que el framework del vecino siempre parece mas poderoso y natural, hasta que lo conoces a fondo y te das cuenta de tambien esta limitado y tiene limitaciones que te parecen artificiales.

Cualquier metodología o método falla si no se implementa correctamente. Y esto va para Scrum, Lean, CMMi, MoProSoft, TSP/PSP o cual sea. Hay factores críticos en cada una que garantizan (o no) llegar a buen término, un proyecto Scrum sin el compromiso y proactividad del equipo sirve para dos cosas, un TSP/PSP sin veracidad de los programadores al registrar sus tiempos sirve para otras dos, proyectos bajo CMMi se ven sentenciados comúnmente por definiciones incorrectas en etapas tempranas.

Yo siempre he pensado que es importante seguir un método, en algunas ocasiones podremos elegirlo y en otras no, o podrá gustarnos o quizá no, quizá tendremos que ocuparlo por ser lo que la organización en la que estamos utiliza, pero lo importante es seguirlo y seguirlo bien. Esto me parece igual de importante que la elección de qué método será.

Ahora...

Las metodologías son también como los lenguajes de programación, cada una fue diseñada para propósitos y situaciones diferentes. Por aquí arriba leí que alguien comentó que en CMMi te pierdes en evidencias y documentación, y francamente es cierto, de hecho es muy común ver proyectos en compañías en nivel 5 de CMMi en las que las horas hombre estimadas para documentación se llevan el 50% del tiempo del proyecto. A nosotros como desarrolladores esto nos parece descabelladísimo, porque regularmente a nosotros nos interesa que el desarrollo sea rápido, simple, sencillo, y francamente nos caga hacer documentación (por eso nos gusta tanto Scrum). Pero no tomamos en cuenta que existe una organización compleja en la empresa para la que estamos trabajando que quizá sí necesita todas ésas evidencias, validaciones, verificaciones, autorizaciones, minutas, etc... por cuestiones de auditoría, estadística, monitorización, manejo de riesgos, QA, etc... que quizá en nuestra mente "no compilan" pero que la empresa sí ocupa. Es más, ni siquiera es de su preocupación que el tiempo de documentación esté al 50% simple y sencillamente porque ese tiempo también lo cobran a sus clientes, y no precisamente por gandallas, la mayoría de los clientes de este tipo de empresas son los que piden un nivel de madurez mínimo en X metodología. En fin... A lo que voy, es que todo este "corporativismo" no es necesariamente malo, todo debe girar al rededor de: si te funciona, igual con ágiles o métodos estadísticos (TSP/PSP).

"En opinión de $ROLE podría ser bueno o malo implementar $METHODOLOGY", algo así.

Saludos.

PD. Aquello del "dreamteam" estuvo priceless!! jaja.

Benek.

Le daré una mirada a Struts 2, a ver que me parece. Si dices que es simple migrar de Struts 1 a 2 lo haré; ya te diré que me parece con respecto a productividad (que lo poco que he visto de Struts 2 es más de lo mismo). Otra cosa es que mi jefe me dice: "No uso Struts 2 por el hecho de que Struts 1 no me gusta, el problema es que en la época en la que el producto fue producido Struts era lo más wow."...Igual ya veremos si también es tan convention over configuration, y que bueno que te pregunté ;), de nuevo gracias.

Le daré una mirada a Struts 2, a ver que me parece. Si dices que es simple migrar de Struts 1 a 2 lo haré; ya te diré que me parece con respecto a productividad (que lo poco que he visto de Struts 2 es más de lo mismo).

Ten cuidado al medir la productividad, muchos frameworks que presumen de super-productivos, parecen serlo solo mientras uno hace cosas simples (esas las super simplifican) y en cuanto quieres algo mas complejo, en vez de ayudar, estorban.

Otra cosa es que mi jefe me dice: "No uso Struts 2 por el hecho de que Struts 1 no me gusta, el problema es que en la época en la que el producto fue producido Struts era lo más wow."

Extraña afirmacion... me suena a "No uso Windows 7, por que Windows 2 no me gusta" o, a: "No uso Java 1.6, por que Java 1.0 no me gusta". No debería sacar la conclusión contraria? precisamente por que no te gusta la versión vieja es que te pasas a una nueva... que no?

el problema es que en la época en la que el producto fue producido Struts era lo más wow

Es cierto, alla cuando se invento Struts 1.x, era lo mas Wow... pero querer quedarte en la version 1.x es, creo yo, es la razon por la que con los años Struts ha ido agarrando mala fama despues de ser el framework mas exitoso de Java (de hecho, por ahi hay paginas que dicen que todavia es el que tiene mas programadores).

Tal vez hasta podrias escribir articulos aqui de las ventajas de las nuevas caracteristicas de Struts 2?

No me estoy dejando llevar por la publicidad de Struts 2, de hecho por lo que he visto Struts 2 no se le acerca en fama a Struts 1 en sus respectivas eras. Me estoy dejando llevar el actualizar a Struts 2 por el hecho de qué se supone no tendría que hacer tantos cambios y el poder conservar la mayoría de las características de la aplicación (poca reescritura, que lo veo cómo reestructuración -uso de @nnotations, cambio de implementar una clase abstracta por clases de Action más simples, etc.)-. Además que algunas personas (tú entre ellas) me dicen que ha mejorado mucho. Ya veremos y de actualizar serás el primero (o casi) en ver un post mío sobre Struts 2.

El paso de Struts 1 a 2 no lo veo tan sencillo, Struts 2 no se basa completamente en la versión 1, sino que fue la fusión de WebWork y Struts 1, y aunque WebWork fue un fork de Struts nació con la idea de innovar aunque se sacrificara compatibilidad. No es completamente una continuación.

Pero claro que sería bueno ver un post sobre Struts 2 por aquí.

***Actualización***

Encontré esta tabla comparativa que te puede ser útil:

Y también esta guía que no solo te dice los pasos de una migración sino te da el background del cambio:

Saludos.

@_benek

Creo que lo que planteas, depende mas del cliente y los requerimientos, que del equipo de programadores y lider de proyecto.

Me ha tocado trabajar con clientes que a nivel empresa piden CMMI 3 para arriba para hacer negocios, esto genera que ellos te exijan todos esos documentos que mencionan, son engorrosos, tediosos, cansados y consumidores de tiempo, pero viendolo por otro lado, si por eso le pagan a la empresa, pues que paguen. Esto vendria siendo como que eres un carpintero, llegas y dices yo tengo como hacer X muebles, se hacerlos y con la calidad que se requiere, pero la empresa te dice ok, hazmelos, dame tu precio y tus tiempos de entrega... ahh y tu RFC, por que requiero factura y tu no tienes facturas, entonces wopss, puedes hacerlo, tienes el material, etc, pero por ese papelito/tramite/certificacion ya no puedes jugar, asi que te quedas fuera, no es el gran problema, puedes jugar/trabajar en otro lado, pero si lo tuvieras, podrias hacerlo ahi, asi que muchas consultoras sacan CMMI express, por el hecho de poder competir/participar con mas clientes y cobrar mas, que por pensar es mejor para generar calidad.

El cliente, puede que pida CMMI, metodologia agil, etc. pero si no respeta los requerimientos, si no tiene claro que quiere y lo cambia a cada rato, ok, en papel tu podrias decir, de acuerdo a X artefactos, yo tengo la razon y merezco mi pago, pero ahhhh el cliente se pone de pesado... chin entonces se ve con juridico y ellos van a decir, ok, primero arreglense o dense con todo, por que llegando a las demandas, echenle 12 meses para empezar y otros tantos para seguirle en lo que resolvemos lo de este proyecto, ahh pero si el cliente tiene 10 proyectos distintos con la misma empresa, ok, seguramente va a darles carpetazo y pasarselos a la competencia y de mientras ya no hay flujo de efectivo, ya no hay para la nomina, entonces fuera programadores, lideres y PMs, hasta que se resuelva esa bronca (si se resuelve), asi que por eso mismo muchas consultoras evitan pelearse con el cliente a ese nivel y de todas formas agachar.
Si a todo eso le sumamos los Lideres de Proyecto y los PMs y/o X roles, designaciones que gusten, y que muchos tienen una vision algo rara de los proyectos y pocas ganas de pelear/discutir/negociar con el cliente o los otros equipos, entonces ya estamos mal, asi tengamos la mejor metodologia del mundo y el mejor equipo. =(

No son las etapas, fases o como le quieran llamar. Creo que el problema es que muchas veces no existe gente capacitada para usarlas en sus proyectos.

Muchas veces no comprendemos que actividades se deben llevar a cabo primero:

• ¿Cuál es el problema a resolver?
• ¿Cuento con personas realmente preparadas para llevar a cabo el proyecto?


• ¿Conozco las herramientas con las que voy a trabajar?
• ¿Tengo el tiempo suficiente para terminar el proyecto?

También considero que el trabajo en equipo es necesario, sin embargo muchas veces trabajar "con mi mejor cuate o con quien me cae mejor" no siempre da buenos resultados.

En México casi no se emplean las metodologías de desarrollo (DSDM, SCRUM, etc.), los proyectos se hacen sin ninguna planeación, y para colmo con gente sin verdadera preparación. Es común encontrarse con programadores PHP nivel Senior y Master que ante una simple sumatoria del 1 al 10 no saben cómo resolverlo y recurren al "copy & paste" de código sin que sepan para qué les sirve.

Y en consecuencia los proyectos fracasan. Considero que antes de emplear una metodología, una herramientas de diseño y de desarrollo y definir un plan de trabajo es necesario conocer si cuento con las personas REALMENTE capacitadas y preparadas para llevar a cabo el proyecto:

Proyecto=Personas_capacitadas_y_REALMENTE_capacitadas_para_el_Proyecto+todo_lo_demas;

Estoy preparando una guia de Struts 2, con ejemplos para que puedan apoyarse mejor y vean las nuevas caracteristicas, como comenta Benek no es transparente el cambio y ustedes decidan usarlo.

Solo denme un poco de tiempo

Wow! Esperamos con ansia esa guía, ¡gracias Marko!

@_benek

Pues sí, esperamos la guía.