Metodologías ágiles ¿Aplican siempre?

[[fer21unmsm]]

Sorry no me he podido leer todos los mensajes . Pero en mi caso si he aplicado la metodología Scrum en algunos proyectos, cabe mencionar que tiene que estar conformado por un equipo multidisciplinario, y como bien indica Azid, es de vital importancia que el scrummaster sepa lo que tiene que hacer, sino...., y que todos tengan claro lo que tienen que hacer. En mi caso ha sido una bonita experiencia, y todo salió bien, se cumplian con los sprints, las retroalimentaciones, la gestión de riesgos, se hacian los productlog, y demás; claro todo esto de la mano de la planificación por que si uno se pone a programar a la loca no salen las cosas. Por otro lado también tengo experiencias en otras metodologías como: XP (que no me gusta personalmente), RUP, MOPROSOFT, PAR (banco BCP), COM (metodología de Everis -España), MEGON (telefónica), ICONIX, y otras. También conozco de la metología del PMI (Gestión de Proyectos) . Si hay un chupo de metodologías y demás, pero siempre hay que saber cuando utilizar qué en donde como bien indica Azid.

Ahora en uno de los cursos que llevé en mi maestría se hizo un estudio del tema ¿por qué fracasan los proyectos de software?, y en este estudio se pudo observar que hay un gran porcentaje de proyectos (más del 70%) que fracasa por temas de gestión.

Pero, ¿qué sucede cuando, tienes un cliente que no sabe bién lo que quiere, y para cambiando de requerimientos?, algunos mencionan que el scrum se ajusta para el tema de cambio de requerimientos porque es ágil, pero ahí les suelto la pregunta, ¿cómo manejan ustedes a un cliente que no tiene en claro lo que requiere como software?

En mi experiencia personal, un ing. de software es un consultor que debe guiar al cliente y ayudar en este punto, esto es critico a mi modo ver, y también del por qué fallan muchos proyectos de software, en la cual el cliente no queda satisfecho con lo realizado. Ya he escuchado en muchos sitios a gente de este rubro decir, yo me limito a cumplir con los requerimientos y con lo que indica el triangulo (ahora es un hexágono) de la calidad y piensan que eso es suficiente. Sin pensar que muchas veces el cliente puede no conocer bien lo que quiere, y al final por más que hayas cumplido con los requerimientos no se siente cómodo con el resultado final.

¿Quisiera saber la opinión de ustedes, de como manejan como vuelvo a mencionar a los clientes que no tienen claro lo que desean ?


Saludos.

[[AzidRain]]

Es bastante interesante lo que planteas. Un buen porcentaje de clientes piensan que tienen bien claro lo que desean pero muchas veces esos deseos no se reflejan en necesidades. Es decir, casi siempre quieren cosas que no necesitan y necesitan cosas que no quieren. Pero bueno, partamos del caso de un cliente que tiene una idea de que es lo que necesita. El chiste de esto es ayudarle a modelar esas necesidades en función de como le resolverá n números de problemas. Sin embargo hay otros casos en donde el cliente se aferra a lo que el piensa que necesita y no importa cuantas juntas, correcciones, entregas e iteraciones hagas al proyecto, nunca está conforme con el resultado aunque éste se adhiera perfectamente a los requerimientos indicados.

Volviendo al punto de las metodologías en efecto pienso que no existe una "navaja suiza" que se pueda aplicar con éxito en todos los casos de desarrollo. Creo que el verdadero valor de un líder, gerente o cabeza de desarrollo es determinar la metodología que mejor se adapte a las características del proyecto aun y cuando no sea la que mejor domina o conoce. Scrum en efecto es muy divertido ya aplicado y con los elementos correctos (proyectos de rápido desplegado, equipos multidisciplinarios, equipos autogestionados, participación del usuario, etc.)

[mamcx]

Empezado por fer21unmsm

pero ahí les suelto la pregunta, ¿cómo manejan ustedes a un cliente que no tiene en claro lo que requiere como software?

Ese es otro tema peludo. Pero seria mejor un tema aparte de este...

[[AzidRain]]

En este momento releyendo el hilo me di cuenta de algo: Sin saberlo dos compañeros y yo (uno de ellos Q.E.P.D.) practicábamos la metodología XP, pues hacíamos largas jornadas de madrugada con uno al mando de la pc y otro al hombro observando y aportando. Ese esquema nos funcionaba porque se trataba de proyectos para concurso, que teníamos que terminar en un cierto tiempo sí o sí para poder participar y nos dio en su momento muy bien resultado. Hablo de por alla de 1990 cuando la OOP apenas estaba en pañales y Mr. Grady Booch era el referente, y en donde "Programacion I" se daba basado en Turbo Pascal 3.0. y más tarde en Turbo Pascal 5.0 y 6.0 que ya traían Turbo Vision y otras cosas que más tarde se convertirían en Delphi.

[[Al González]]

Empezado por AzidRain

[...] y más tarde en Turbo Pascal 5.0 y 6.0 que ya traían Turbo Vision y otras cosas que más tarde se convertirían en Delphi.

Turbo Pascal 6.0 presentó Turbo Vision. La versión 5.0 no tenía capacidad de orientación a objetos. Sin embargo, Turbo Pascal 5.5 introdujo el concepto de tipo de objeto y con ello se convirtió en el primer lenguaje de programación popular POO.

En aquellos buenos años los navegantes sostenían el timón, no los mercaderes.

[[Delphius]]

Empezado por fer21unmsm

Sorry no me he podido leer todos los mensajes . Pero en mi caso si he aplicado la metodología Scrum en algunos proyectos, cabe mencionar que tiene que estar conformado por un equipo multidisciplinario, y como bien indica Azid, es de vital importancia que el scrummaster sepa lo que tiene que hacer, sino...., y que todos tengan claro lo que tienen que hacer. En mi caso ha sido una bonita experiencia, y todo salió bien, se cumplian con los sprints, las retroalimentaciones, la gestión de riesgos, se hacian los productlog, y demás; claro todo esto de la mano de la planificación por que si uno se pone a programar a la loca no salen las cosas. Por otro lado también tengo experiencias en otras metodologías como: XP (que no me gusta personalmente), RUP, MOPROSOFT, PAR (banco BCP), COM (metodología de Everis -España), MEGON (telefónica), ICONIX, y otras. También conozco de la metología del PMI (Gestión de Proyectos) . Si hay un chupo de metodologías y demás, pero siempre hay que saber cuando utilizar qué en donde como bien indica Azid.

Ahora en uno de los cursos que llevé en mi maestría se hizo un estudio del tema ¿por qué fracasan los proyectos de software?, y en este estudio se pudo observar que hay un gran porcentaje de proyectos (más del 70%) que fracasa por temas de gestión.

Pero, ¿qué sucede cuando, tienes un cliente que no sabe bién lo que quiere, y para cambiando de requerimientos?, algunos mencionan que el scrum se ajusta para el tema de cambio de requerimientos porque es ágil, pero ahí les suelto la pregunta, ¿cómo manejan ustedes a un cliente que no tiene en claro lo que requiere como software?

En mi experiencia personal, un ing. de software es un consultor que debe guiar al cliente y ayudar en este punto, esto es critico a mi modo ver, y también del por qué fallan muchos proyectos de software, en la cual el cliente no queda satisfecho con lo realizado. Ya he escuchado en muchos sitios a gente de este rubro decir, yo me limito a cumplir con los requerimientos y con lo que indica el triangulo (ahora es un hexágono) de la calidad y piensan que eso es suficiente. Sin pensar que muchas veces el cliente puede no conocer bien lo que quiere, y al final por más que hayas cumplido con los requerimientos no se siente cómodo con el resultado final.

¿Quisiera saber la opinión de ustedes, de como manejan como vuelvo a mencionar a los clientes que no tienen claro lo que desean ?


Saludos.

A pesar de no tener tanta experiencia con muchos clientes, creo que así como no hay una única forma de encarar un proyecto; tampoco habrá una única forma mágica de sobrellevar y guiar a estos clientes. Depende de muchas cosas, la propia formación y el conocimiento/asimilación sobre informática que pudiera tener el cliente, del negocio/empresa/emprendimiento en que maneja, hasta incluso se podría debatir la situación personal del mismo.
No es lo mismo hablar por ejemplo con un ingeniero industrial que nos solicita ayuda para diseñar un sistema que controle el proceso de una fábrica de metales que hablar con un panadero que posiblemente apenas ha terminado la secundaria e hizo un curso sobre panadería. No es lo mismo hablar con alguien que vive envuelto en un mundo de mucha tecnología y tiene 30 años que hablarlo con un abogado de 90 años que se ha quedado en el tiempo y es reacio incluso a tener un celular.
Hay clientes y clientes... y no creo que se pueda generalizar.

Ahora bien desde el punto de gestión ahí si podríamos poner cartas en la mesa. Pero de nuevo: todo depende de como uno agarra el taco. En lo personal, y en mi poca experiencia, para situaciones como la que describes yo consideraría modelos basados en Prototipos, o en Espiral. O alguna combinación de éstos dos.

Empezado por AzidRain

Volviendo al punto de las metodologías en efecto pienso que no existe una "navaja suiza" que se pueda aplicar con éxito en todos los casos de desarrollo. Creo que el verdadero valor de un líder, gerente o cabeza de desarrollo es determinar la metodología que mejor se adapte a las características del proyecto aun y cuando no sea la que mejor domina o conoce. Scrum en efecto es muy divertido ya aplicado y con los elementos correctos (proyectos de rápido desplegado, equipos multidisciplinarios, equipos autogestionados, participación del usuario, etc.)

Por favor Azid, ¡que no todo es metodología! Existen los modelos.
Ya he dicho hasta el cansancio que una cosa es metodología y otra son los modelos de procesos. No se dan por aludidos.

Me extraña que no asimilen esto, o es que ya tienen medio oxidado lo que han aprendido de la universidad. Me inclino a por lo 2do.

Saludos,

[[Al González]]

Empezado por Delphius

[...] o es que ya tienen medio oxidado lo que han aprendido de la universidad

Yo no fui a la universidad, Marcelo. Por eso escribo "dislates".

[[Delphius]]

Empezado por Al González

Yo no fui a la universidad, Marcelo. Por eso escribo "dislates".

No lo dije por ti Al, sino a los demás. Que tuvieron formación académica y aún insisten en resumir todo a metodologías.
Lo cierto es que hay modelos de proceso y por el otro metodologías.

Lo del enlace y la palabra dislates no comprendo. El link apunta a un post tuyo de un hilo sobre TIOBE y la posición que ocupa Delphi... del año 2013

Saludos,

[roman]

Empezado por Delphius

Lo del enlace y la palabra dislates no comprendo. El link apunta a un post tuyo de un hilo sobre TIOBE y la posición que ocupa Delphi... del año 2013

Supongo que se refiere a esto :

Empezado por Al González

al evidente estancamiento de Microsoft (Windows 8, .NET, C#...), a la finalización de los cinco minutos de fama de Java y a la inevitable ausencia paulatina de los veteranos de C

Y, en cuanto al siginificado de dislate, use google, my friend.

LineComment Saludos

[[Delphius]]

Empezado por roman

Supongo que se refiere a esto :



Y, en cuanto al siginificado de dislate, use google, my friend.

LineComment Saludos

Pues justamente en que a ese post me cuesta entenderle el nexo con este hilo. Y pensé que quizá se ha confundido de post o enlace y quiso poner otro.

Yo se que el buen compañero Al es un excelente idóneo y su experiencia viene de forma totalmente autodidacta. Lo cual no digo que sea malo o de menosprecio. Todo lo contrario, es de un gran respeto. En el área Informática hay muchos idóneos que han sido (y siguen siendo) grandes ejemplos a imitar.

Yo espero que Al entienda que lo que yo he expresado post antes no es algo hacia el, sino de asombro por los otros miembros que han intervenido y que sabiendo que han recibido instrucción formal en alguna carrera de Informática y no hagan una correcta separación y distinción entre Metodologías y Modelos. Lo vengo advirtiendo desde el comienzo del hilo.
Es un grave error meter en la misma bolsa y confundir Modelos como si fueran metodologías. Es algo que se da mucha incapié en las cátedras de Ingeniería de Software, pero lamentablemente hay mucha literatatura tendenciosa, sobre todo en Internet, que desinforma y ponen por igual a ambos conceptos.

Es cierto que a nivel general se suele recurrir a la palabra Metodología para explicar tanto a los diferentes Modelos (Cascada, Prototipado, Espiral, etc) como a las Metodologías (XP, Scrum, etc) pero esto es un error. Y es justamente esa dualidad lo que hace y genera la confusión. Es deber nuestro corregir eso. Se aconseja, y mucho, que en lugar de emplear esa palabrita para referirse en términos generales se use el término Paradigma de Proceso o bien Ciclo de Vida de Proceso, Proceso de Software.
Y hago esa advertencia a los profesionales que siguen insistiendo en hablar de metodologías sin hacer las debidas aclaraciones. Voy a seguir insistiendo: una cosa son Modelos y otra son las Metodologías.

¿Tan difícil es pedir un mínimo de respeto a nuestra formación? El no hacer esas debidas referencias les quita valor a sus expresiones y con todo respeto, le baja la calidad profesional a sus argumentos.

Volviendo a lo que ha dicho Al, me queda pensando en el trasfondo de lo que ha intentado poner. Quizá se me ha activado el Chip Asperguiano y no logro encontrarle el buen sentido.
Yo se que Al al no haber recibido formación universitaria quizá se sienta un poco intimidado por como yo al menos le di giros al hilo. Pero no me cabe duda de que su capacidad Idónea no necesita de que alguien le diga que debe aplicar algún modelo o metodología.

En la práctica uno termina desarrollando su propio método (esta es otra palabra aconsejada para decirlo en forma general) y estoy convencido de que Al tiene el suyo. ¡Vuelvan a la frase de Grady Booch que he citado! Es muy probable que sin proponérselo haya redescubierto muchas de las máximas y de las buenas prácticas y concebido una versión mixta de algunos modelos y/o metodologías.

Yo espero que Al pueda sentirse a gusto con lo que ha logrado. Porque su rica experiencia bien le ha dado su calidad técnica y el bien reconocido valor que esta comunidad le da y recuerda cada vez que puede. Y sus palabras tienen peso, validez y capacidad de ver a largo plazo. La profesía de ese post sobre el repunte de Delphi se cumplió.

No me parece que sus expresiones sean un disparate, es más comparto lo que ha dicho en ese post enlazado. Hace tiempo que Microsoft viene preparando la muerte de .NET y volver a ruedo con un nuevo lenguaje... no lo suelta todavía porque tiene algo de "escuela" hecha y quiere sacarle el jugo hasta donde pueda y la burbuja caótica de los tropezones de un paso de versión a otra explote. Las escuelas de Java están empezando a perder prestigio, mucho JAVA todo bonito pero por querer dar las cosas rápida y a los bifes se ha perdido la base. Mamx citó una vez la crítica que Joel Spolsky supo hacer a las JAVA Schools. Estas escuelas se difundieron como un cáncer. Y si, en esta le estoy con Joel: hay algunos que tienen 10 en JAVA pero si le preguntas sobre lo que es recursividad o punteros se sacan un 1.

Hace poco se supo de una buena noticia, el gobierno de Sudáfrica eligió Delphi al nivel educativo. Ya antes Rusia también dió ejemplo al comprar 1 millón de licencias, y casi al mismo tiempo de que Joel publicase su artículo con la crítica a las Java Schools nos habíamos enterado de que el gobierno de Inglaterra aconsejaba seriamente abandonar estas escuelas y ponía mucho énfasis en la escuela basada en Pascal/Object Pascal.

La comunidad Pascalera/Object Pascalera pareciera ser un ave fénix que tiene ciclos de vida de 5 años, pone su huevo cuando todo pareciera morirse en su propia ceniza y de pronto el huevo se rompe y nace nuevamente con nuevos aires. Es Inmortal... es el que todos odian pero le guardan unos celos no confesados... me recuerda cuando una compañera de la universidad se quedaba maravillada en como de rápido terminaba los prácticos y ella se tardaba más en hacerlo en Visual Basic o en .NET. En una "discusión" en la que no nos poníamos de acuerdo para hacer un trabajo en grupo ella misma había sugerido Delphi... Nos odian, y nos celan. A ver si no se roban otro CEO más (si es que aún queda alguno en Idera... porque ya se fue el último del equipo original de CodeGear de la parte del equipo del compilador hacia Google)

Saludos,