Metodologías ágiles ¿Aplican siempre?

[[Al González]]

No quisiera estar en los zapatos de Mario y tener un fan tan aguerrido.

[Casimiro Notevi]

Empezado por Al González

No quisiera estar en los zapatos de Mario y tener un fan tan aguerrido.

[[Delphius]]

Empezado por Al González

No quisiera estar en los zapatos de Mario y tener un fan tan aguerrido.

A mi lo que es Ingeniería de Software me atrae Al. Y en estos temas es imposible no entrarle.

¿Fan? Y... no se... puede ser che. Mamx fue una de las personas que más ha relatado sobre Ingeniería de Software en el foro, y eso lo aplaudo porque a pesar de que tengo mis críticas estoy seguro que hay una lección tras esto en la que el y yo concidiremos:

Empezado por Grady Booch

"Las buenas personas son más importantes que cualquier proceso.
Buenas personas con un buen proceso siempre actuarán mejor que buenas personas sin procesos"

Esa frase lo resume bien. Es preferible que siga trabajando la Ingeniería de Software y se enfoque en traer orden a la casa, antes que tirar a la basura todo y hacer las cosas a lo tin-marin-de-don-pingue.
El punto es que ha llegado el punto en que por traer orden a la casa hemos tirado la basura en el patio y los trastos en aquel placard viejo. Y ya no hay donde más pasar sin darnos cuenta que hemos creado un monstruo.

La Ingeniería de Software nos ha traído grandes maravillas, pero también nos la venden como espejitos de colores y nos enamoramos de ella y se ha perdido mucho en los años.
Tenemos que desenenamorarnos de algunas prácticas.

Yo, aún siendo defensor de las buenas prácticas de la Ingeniería de Software, me permito la crítica a este elefantiásico monstruo en que se ha convertido. Es necesario quitarles varios laureles y poner en la mesa la discusión eterna: La crisis del software no se superó.

Saludos,

[mamcx]

Empezado por Al González

No quisiera estar en los zapatos de Mario y tener un fan tan aguerrido.

Imagino que cierto Casimiro pensara lo mismo de mi

Y con Delphius las ultimas conversas, pues ni tan en desacuerdo estoy, solo que enfatiza unas cosas con mas pasion

[[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,