Comments on: Lecciones aprendidas http://www.manuelrecena.com/blog/archives/369 Donde escribo sobre cosas que forman parte de mi vida profesional Mon, 23 Jan 2012 13:01:37 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Mi espacio » ExtJS en nuestra caja de herramientas http://www.manuelrecena.com/blog/archives/369/comment-page-1#comment-5006 Mi espacio » ExtJS en nuestra caja de herramientas Wed, 22 Dec 2010 00:40:55 +0000 http://www.manuelrecena.com/blog/?p=369#comment-5006 [...] este excelente framework en el año 2008. Desde entonces no ha faltado en mi caja de herramientas. Son más de 5 proyectos en los que he [...] [...] este excelente framework en el año 2008. Desde entonces no ha faltado en mi caja de herramientas. Son más de 5 proyectos en los que he [...]

]]> By: Manuel Jesús Recena Soto http://www.manuelrecena.com/blog/archives/369/comment-page-1#comment-1570 Manuel Jesús Recena Soto Sun, 12 Oct 2008 10:16:23 +0000 http://www.manuelrecena.com/blog/?p=369#comment-1570 Hola Joserra: Efectivamente, el punto 2 daría para hablar muchas horas. Nosotros lo que procuramos es confiar plenamente en el analista y que sea él quien -bajo sus criterios- determine cuando existe una primera versión estable del catálogo de requisitos. Tanto él como el resto del equipo saben que esa información no es un teorema y que muy probablemente sufrirá cambios. Como sabemos que eso es así lo que estamos haciendo es aprender a gestionar el cambio. Ahí tiene mucho que decir el marco tecnológico en el que trabajes, la experiencia del equipo y sobre todo la metodología. Me preguntas sobre nuestra metodología y no sé qué responderte. Reconozco que he leído bibliografía al respecto, sin embargo, mi mayor fuente de conocimiento viene de nuestro propio día a día y de grupos de trabajos como http://groups.google.com/group/ecosistemas-software. De forma bastante frecuente incorporamos nuevos conceptos a nuestra forma de trabajar. Recientemente hemos decidido que semanalmente, por proyecto, el equipo se reunirá -por las tardes y no más de 90 minutos- para hacer una puesta en común de ideas, resolución de ambigüedades, toma de decisiones, perspectivas, etc... Durante la semana, cualquier cosa que surja se comunica a través de una lista de correo que hay para cada proyecto. De esta forma, todo lo que se comente queda en conocimiento de todos los miembros del equipo. Evitamos así que el analista por ejemplo resuelva dudas de forma particular con situaciones como: "después de café te viene a mi mesa y vemos los requisitos de información sobre expedientes". Lo que sí te podría asegurar es que nuestra metodología sería imposible (en términos de productividad y rentabilidad) llevar a cabo sin nuestro ecosistema software (DEIN). Un saludo Hola Joserra:

Efectivamente, el punto 2 daría para hablar muchas horas. Nosotros lo que procuramos es confiar plenamente en el analista y que sea él quien -bajo sus criterios- determine cuando existe una primera versión estable del catálogo de requisitos. Tanto él como el resto del equipo saben que esa información no es un teorema y que muy probablemente sufrirá cambios. Como sabemos que eso es así lo que estamos haciendo es aprender a gestionar el cambio. Ahí tiene mucho que decir el marco tecnológico en el que trabajes, la experiencia del equipo y sobre todo la metodología.

Me preguntas sobre nuestra metodología y no sé qué responderte. Reconozco que he leído bibliografía al respecto, sin embargo, mi mayor fuente de conocimiento viene de nuestro propio día a día y de grupos de trabajos como http://groups.google.com/group/ecosistemas-software. De forma bastante frecuente incorporamos nuevos conceptos a nuestra forma de trabajar. Recientemente hemos decidido que semanalmente, por proyecto, el equipo se reunirá -por las tardes y no más de 90 minutos- para hacer una puesta en común de ideas, resolución de ambigüedades, toma de decisiones, perspectivas, etc… Durante la semana, cualquier cosa que surja se comunica a través de una lista de correo que hay para cada proyecto. De esta forma, todo lo que se comente queda en conocimiento de todos los miembros del equipo. Evitamos así que el analista por ejemplo resuelva dudas de forma particular con situaciones como: “después de café te viene a mi mesa y vemos los requisitos de información sobre expedientes”.

Lo que sí te podría asegurar es que nuestra metodología sería imposible (en términos de productividad y rentabilidad) llevar a cabo sin nuestro ecosistema software (DEIN).

Un saludo

]]> By: Joserra http://www.manuelrecena.com/blog/archives/369/comment-page-1#comment-1560 Joserra Sat, 11 Oct 2008 21:19:58 +0000 http://www.manuelrecena.com/blog/?p=369#comment-1560 Muy interesante! El punto 2 es crítico... nos empeñamos todos en que nos "validen" un análisis, pero luego, todo sufre modificaciones, ni siquierea podemos estar seguros de que lo implementado cumple el análisis, que no hubo un telefonazoq ue cambio algo importante sin dejar rastro,... ¿de gestión del proyecto que hacíais?¿algo concreto como Scrum o RUP? Muy interesante!
El punto 2 es crítico… nos empeñamos todos en que nos “validen” un análisis, pero luego, todo sufre modificaciones, ni siquierea podemos estar seguros de que lo implementado cumple el análisis, que no hubo un telefonazoq ue cambio algo importante sin dejar rastro,…

¿de gestión del proyecto que hacíais?¿algo concreto como Scrum o RUP?

]]> By: Manuel Jesús Recena Soto http://www.manuelrecena.com/blog/archives/369/comment-page-1#comment-1557 Manuel Jesús Recena Soto Sat, 11 Oct 2008 19:10:53 +0000 http://www.manuelrecena.com/blog/?p=369#comment-1557 Hola Javier: Es normal que no hayas oído hablar de DEIN, es la primera vez que lo menciono aquí. DEIN es el nombre que le hemos dado en el GMV a nuestra solución de Ecosistema Software. Llevamos tiempo trabajando en ella y con ella. Algunos de nuestros clientes la tienen implantada. Un saludo Hola Javier:

Es normal que no hayas oído hablar de DEIN, es la primera vez que lo menciono aquí.
DEIN es el nombre que le hemos dado en el GMV a nuestra solución de Ecosistema Software. Llevamos tiempo trabajando en ella y con ella. Algunos de nuestros clientes la tienen implantada.

Un saludo

]]> By: Javier Murillo http://www.manuelrecena.com/blog/archives/369/comment-page-1#comment-1555 Javier Murillo Sat, 11 Oct 2008 17:48:29 +0000 http://www.manuelrecena.com/blog/?p=369#comment-1555 Hola Manuel, Interesantes puntualizaciones. Si con algunas especialmente me identifico son con la 1, la 2 y la 4. Si al menos no es posible cumplir la 1 estrictamente, al menos si que haya variedad entre los entornos de desarrollo y el de integración / despliegue o como queramos designarle. Y llamémosle DEIN, Continuum, Cruise Control, Team System, ... la IC es un concepto que aporta en mi opinión mucho a un proyecto. Por cierto no me sonaba de nada el nombre de DEIN. Un saludo Hola Manuel,

Interesantes puntualizaciones.

Si con algunas especialmente me identifico son con la 1, la 2 y la 4. Si al menos no es posible cumplir la 1 estrictamente, al menos si que haya variedad entre los entornos de desarrollo y el de integración / despliegue o como queramos designarle.

Y llamémosle DEIN, Continuum, Cruise Control, Team System, … la IC es un concepto que aporta en mi opinión mucho a un proyecto. Por cierto no me sonaba de nada el nombre de DEIN.

Un saludo

]]>