FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Muy buen tema. Yo no sería capaz de definir qué metodología o modelo utilizo. Me gusta pensar que todo camino es válido mientras entregues en un tiempo razonable algo funcional, satisfactorio y que sea consistente y estético tanto por dentro como por fuera. En ocasiones hay suerte y hasta toca añadir alguna pequeña innovación.
Agrego: Eso sí, sigo pensando que algo como la DTE puede beneficiar mucho el trabajo en equipo. En ese sentido, tengo la fortuna de haber sido contratado para realizar solamente programación de bibliotecas de clases, exceptuando aquellas relacionadas con interfaces de usuario. Mis "clientes" son otros programadores, ya no el usuario final. Por fin estoy en mi elemento. Última edición por Al González fecha: 19-02-2016 a las 05:42:40. |
#2
|
||||
|
||||
Cita:
Aunque todavía no me termino de encontrar en mi elemento, más que nada debido a necesidades derivadas de haberme metido empresario, pero tengo esperanzas en el futuro. |
#3
|
||||
|
||||
Cita:
Todo este tema de las metodologias es mas que todo, el aspecto operativo. Como dicen en http://scrummethodology.com/ Cita:
Eventualmente toda persona con experiencia termina re-descubriendo las buenas practicas, aun sin saber que tiene tal o cual nombre. El reto ocurre cuando se juntan 2: Como concordar en como hacer las cosas? Ahi es donde estos temas importan.
__________________
El malabarista. |
#4
|
||||||||||||||
|
||||||||||||||
Cita:
Aquí ya deberías de terminar de seguirle la vuelta. ------ Cita:
Cita:
Cita:
El 4 sobra. Cita:
Te doy la respuesta: NO, no aplica para todo. Si tiene sus limitaciones. Cuanto más se intente estirar el modelo o una metodología para algo que no da, más se quiebra. Cita:
Las culpas son compartidas: tanto por un mal marco de trabajo elegido, como del equipo. Los factores externos también influyen pero sobre éstos no tenemos absoluto control, y cuanto mucho podemos mitigar su impacto. El defecto de scrum es que es mucho más dependiente de que las cosas salgan bien. Si tiene sus puntos de control de riesgos pero el problema es que no es intensivo, es reactivo. Otros enfoques en cambio tienen ya en su marco de trabajo un plan de riesgos y son más preventivos. Scrum es de avanzar rápido, luego piensa. Y no siempre eso es bueno. Cita:
Scrum tiene un plan muy centrado en la formación de equipo, por algo será. Pero otros enfoques también lo tienen, pero no de forma tan explícita. Creo que es por demás obvio que lo principal es tener un equipo aceitado y lo mejor capacitado. Esto va para cualquier enfoque que se adopte. El extra, y volviendo al tema de Scrum, es justamente que no está pensado para todo tipo de equipo y personas. Scrum es burocrático: que reuniones todos los putos días para ver que se va a hacer y que al final tener que pasar el informe de resultados puede ser muy molesto. No todos funcionan así, hay personas a las que resulta más cómodos planes generales y no le estén rompiendo las pelotas cada día, o hasta en tiempos por horas a ver que hiciste y que grado de avance hay. Scrum no es tan flexible como dices. Tiene un esquema rígido. Los modelos son rígidos también, pero al menos tienen muchas cosas "opcionales". Cita:
Sacate el papel de comercial, ya sabemos que haces de consultoría. Por lo que es más que obvio que intentarás vendernos el paquete scrum. Y más tarde nos vendrás a vender otro... Ahora que recuerdo, hace un tiempo tu nos estabas comentando sobre que aplicabas Modelo-V. El no reconocer que las metodologías y los modelos también pueden ser un dolor de cabeza y están provocando un desaguizado mental en los desarrolladores es un grave defecto de muchos pensadores y defensores de la Ingeniería de Software. Les faltan más "mea culpa". Tom DeMarco sacudió el bote hace un tiempo, pasó de ser un gran defensor de la Ingeniería de Software y ahora es uno de sus críticos. Cita:
Todo equipo debe ser dinámico, Scrum vende que lo es. Pero tiene una estructura rígida que no calza en todo. Es lo que vengo diciendo. Los Modelos incrementales en cambio a pesar de que tienen sus macro-actividades definidas, las actividades estructurales que uno le incorpore le permiten ser flexibles. Además por naturaleza el principio de los modelos incremental es trabajar según los riesgos y redefinen los incrementos según el avance. No hay esa presión que caracteriza y puede jugarle muy en contra a Scrum, de que esta actividad se hace en x hs y luego a llorar. Scrum es útil para proyectos que más o menos ya están estudiados, en donde el equipo ya tiene su base y se siente cómodo. Para cosas nuevas e innovadoras y que amerita ir estudiando a la marcha no viene bien. ¡Entiendelo! Lo deja la wiki tu dices, pero que de todas formas aún insiste en que es para todo. Cita:
Y por cierto, deberías repasar lo que es el ciclo de Cascada o Secuencial, porque es mucho más que atacar a los requerimientos desde el principio. Tienes un grave problema con los reduccionismos. Cita:
Cita:
No van a Google o a MS, van a empresas más chicas. Donde puedan sacar a lucir su corbatita y la lengua fácil. M$ tiene un buen equipito de estos que de vez en cuando salen a vender a quien más vender su "innovador método para proyectos exitosos". La red está repleta de testimonios de como el consultor termina resultando ser una enfermedad que una cura. Cita:
Scrum no sirve en proyectos de largo plazo, trabaja en media y baja escala. Si necesita gente entrenada y acostumbrada a trabajar de esa forma. Y para eso se necesita de disciplina, lo que implica haber pasado por un proceso en el que se da forma a la empresa. No sirve en ambientes star-up precisamente porque para poner Scrum, se requiere experiencia previa y tener YA LA CASA EN ORDEN. Si es una empresa que recién se está formando, Scrum es la muerte. Cita:
Aquellas ventajas de trabajar en cosas concretas, en tiempos concretos de Scrum es también su problema. Requiere de preparación, tener bien ordenado desde antes ya las cosas para que no aparezcan demasiadas sorpresas. No es tan flexible como dicen ser. Para un proyecto que se va armando en la marcha y que tiene muchas posibilidades de que aparezcan restricciones y/o condiciones ténicas-operativas y legales que lo modifiquen Scrum hace aguas. Scrum necesita medidas concretas. Estudios y experiencias previas. Para innovar no va. Insisto: no es para todo. Saludos, |
#5
|
||||
|
||||
No quisiera estar en los zapatos de Mario y tener un fan tan aguerrido.
|
#6
|
||||
|
||||
|
#7
|
||||
|
||||
Cita:
¿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: Cita:
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, |
#8
|
||||
|
||||
Cita:
Y con Delphius las ultimas conversas, pues ni tan en desacuerdo estoy, solo que enfatiza unas cosas con mas pasion
__________________
El malabarista. |
#9
|
|||
|
|||
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.
__________________
"La información tiene más valor cuando se comparte" |
#10
|
||||
|
||||
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.)
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
#11
|
||||
|
||||
Ese es otro tema peludo. Pero seria mejor un tema aparte de este...
__________________
El malabarista. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
siempre al centro | JoseSagas | Varios | 6 | 27-06-2012 19:25:36 |
¿Que metodologías usas para el analisis y diseño? | Delphius | Debates | 20 | 24-09-2010 18:00:35 |
Siempre StayOnTop | lfb | C++ Builder | 2 | 06-10-2008 07:32:10 |
Siempre Encima. | Cecilio | Varios | 4 | 23-11-2007 09:55:54 |
|