tag:blogger.com,1999:blog-8719699543086886737.post4506929570254865360..comments2008-12-31T18:23:39.444+01:00Josep Ruanohttp://www.blogger.com/profile/14109656572101693870noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-8719699543086886737.post-44852793302849352042008-12-31T18:23:00.000+01:002008-12-31T18:23:00.000+01:00

por que tanta bronca contra el software???<BR/>yo les paso un enlace que para varios va aser util:<BR/>http://www.hispanosnet.com/software/<BR/><BR/>saludos!

estefanianoreply@blogger.comtag:blogger.com,1999:blog-8719699543086886737.post-36241781192089308022007-05-31T10:35:00.000+02:002007-05-31T10:35:00.000+02:00

Juan,<BR/><BR/>gracias por pasarte y comentar. <BR/>En el caso del que hablo, el cliente cree conocer a la perfección los requisitos, pero en realidad no los conocía del todo: faltaba hacer lo que se llama "requirements scrubbing", es decir, revisarlos y eliminar aquellos que son superfluos, contradictorios o innecessarios. Por lo tanto, lo que quiere lo conoce en detalle, pero quiere menos de lo

Josep Ruanohttp://www.blogger.com/profile/14109656572101693870noreply@blogger.comtag:blogger.com,1999:blog-8719699543086886737.post-13025074003088772432007-05-31T09:28:00.000+02:002007-05-31T09:28:00.000+02:00

Hola Josep.<BR/>Acabo de descubrir tu blog (perdón por el despiste :-) y...: ehnorabuena!.<BR/><BR/>El tema de tu post es tan tan típico y para mi tan difícil de construirle una solución de talla única.<BR/><BR/>No conozco para nada el sistema al que te refieres, Algunas sugerencias que quizá puedan encajar:<BR/>- Desarrollar un análisis de inventario del sistema para sentarse con el cliente y

Juan Palaciohttp://www.navegapolis.netnoreply@blogger.comtag:blogger.com,1999:blog-8719699543086886737.post-75859164110708924042007-05-26T13:51:00.000+02:002007-05-26T13:51:00.000+02:00

Hola Alberto,<BR/><BR/>uno de los motivos por los que no me gustan las metodologías ágiles es este. Las llamadas metodologías ágiles se centran mucho en tener equipos que funcionen con la mínima gestión y documentación; cuando lees casos de estudio, dónde han fallado dicen que el equipo no era bueno. Claro, con un equipo de gente senior, todos brillantes, es fácil que salga bien. Personalmente me

Josep Ruanohttp://www.blogger.com/profile/14109656572101693870noreply@blogger.comtag:blogger.com,1999:blog-8719699543086886737.post-82105045661271532942007-05-26T13:43:00.000+02:002007-05-26T13:43:00.000+02:00

Muy bueno el artículo (en tu línea, vamos)...<BR/><BR/>La metodología que comentas es muy buena sobre el papel, y de hecho con equipos preparados está demostrada su eficacia, pero se plantea la duda de ¿qué pasa si el equipo (o parte de él) simplemente <B>no sirve</B>?. Es decir, para entender y poner en práctica este tipo de metodologías hace falta tener una mínima base y algunos conceptos

Alberto Giménezhttp://www.blogger.com/profile/11427397556038993814noreply@blogger.comtag:blogger.com,1999:blog-8719699543086886737.post-35926133300881853212007-05-24T15:59:00.000+02:002007-05-24T15:59:00.000+02:00

jm,<BR/><BR/>estoy absolutamente de acuerdo contigo en tu reflexión. <BR/><BR/>Los gestores, en realidad, quieren y deben acotar el coste y el tiempo, pero no es necesaria una estimación al céntimo o al minuto. <BR/><BR/>En mi opinión, tal y como tu dices, SCRUM da en el clavo. En CAPSiDE usamos SCRUM para la construcción, y lo acompañamos de otras prácticas más "formales" para poder acotar

Josep Ruanohttp://www.blogger.com/profile/14109656572101693870noreply@blogger.comtag:blogger.com,1999:blog-8719699543086886737.post-24766890095313956672007-05-24T15:47:00.000+02:002007-05-24T15:47:00.000+02:00

Hola otra vez...<BR/><BR/>Tanto SCRUM como cualquier otra metodología ágil, se quedarán cojas en el tema de planificación y presupuestos.<BR/><BR/>Hay que tener en cuenta que las metodologías ágiles no son predictivas (no te dicen cuando acabas el proyecto), sino adaptativas (te dicen sobre duracte el desarrollo si vas bien o vas mal, para que puedas ir tomando medidas correctoras a tiempo).<BR/>

JMhttp://www.blogger.com/profile/03211832306694025005noreply@blogger.comtag:blogger.com,1999:blog-8719699543086886737.post-71720783306742744782007-05-24T14:49:00.000+02:002007-05-24T14:49:00.000+02:00

Gracias jm!<BR/><BR/>Creo que depende del grado de mala calidad al que haya llegado el producto. En la mayoría de casos en que me he encontrado, es prácticamente imposible aprovechar nada, porqué se ha hecho ya mal de base, empezando por la toma de requisitos, que siendo estrictos ha sido inexistente como tal. Eso ha llevado a que el proyecto viejo no sirva ni para tomar requisitos, porqué muchas

Josep Ruanohttp://www.blogger.com/profile/14109656572101693870noreply@blogger.comtag:blogger.com,1999:blog-8719699543086886737.post-2265436601423227432007-05-24T13:33:00.000+02:002007-05-24T13:33:00.000+02:00

Me parecen muy interesantes tus reflexiones sobre algo tan habitual (por desgracia) en el desarrollo de software.<BR/><BR/>Mi opinión al respecto (después de intentar recuperar unos cuantos proyectos) es que tirar el producto a la basura no es una buena decisión en la mayoría de los casos.<BR/><BR/>Mi modus-operandi suele ser algo parecido a esto (cada paso es un reto en si mismo):<BR/><BR/>1)

JMhttp://www.blogger.com/profile/03211832306694025005noreply@blogger.comtag:blogger.com,1999:blog-8719699543086886737.post-25795255875864232592007-05-24T12:30:00.000+02:002007-05-24T12:30:00.000+02:00

Hola Fernando,<BR/><BR/>efectivamente parece a SCRUM, cierto. Sin embargo, pretendía hablar a un nivel más generalista que entrar en metodologías concretas, que sería otro tema distinto. <BR/><BR/>En cuanto a los modelos ágiles tienen ventajas, pero también tienen sus problemas cuando no existe un equipo, sino un grupo de gente, o cuando el equipo no es suficientemente senior para ser "auto

Josep Ruanohttp://www.blogger.com/profile/14109656572101693870noreply@blogger.comtag:blogger.com,1999:blog-8719699543086886737.post-26421930307973084272007-05-24T12:19:00.000+02:002007-05-24T12:19:00.000+02:00

La solución me suena mucho a SCRUM. Solo en la parte de predecir los tiempos de salida no cuadra con un modelo totalmente ágil. Como contraparte se podría intentar con TSP, aunque no veo que tengas nada sobre levantar estadísticas individuales de rendimiento.

Fernando Andradewww.fjandrade.comnoreply@blogger.com