Cita:
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.
Cita:
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,