Comments on: El software no es sólo desarrollo http://www.manuelrecena.com/blog/archives/337 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: Qué aporta Clinker a devops? « klicap – ingeniería del puzle http://www.manuelrecena.com/blog/archives/337/comment-page-1#comment-5040 Qué aporta Clinker a devops? « klicap – ingeniería del puzle Sun, 20 Feb 2011 16:21:12 +0000 http://www.manuelrecena.com/blog/?p=337#comment-5040 [...] esa línea imaginaria (a veces totalmente física) entre desarrollo y operaciones. Esto es algo que muchos ya intuían y en lo que se lleva trabajando muchos años, pero como suele ser común en esta [...] [...] esa línea imaginaria (a veces totalmente física) entre desarrollo y operaciones. Esto es algo que muchos ya intuían y en lo que se lleva trabajando muchos años, pero como suele ser común en esta [...]

]]> By: Manuel Jesús Recena Soto http://www.manuelrecena.com/blog/archives/337/comment-page-1#comment-1407 Manuel Jesús Recena Soto Mon, 29 Sep 2008 15:07:59 +0000 http://www.manuelrecena.com/blog/?p=337#comment-1407 Hola Javier: Como ya comentaba en la entrada, de los libros blancos ya hablaré más adelante. Por ahora me quedo con la falta de comunicación entre los departamentos. La Junta de Andalucía precisamente está usando una wiki: http://www.juntadeandalucia.es/madeja Un saludo Hola Javier:

Como ya comentaba en la entrada, de los libros blancos ya hablaré más adelante.
Por ahora me quedo con la falta de comunicación entre los departamentos. La Junta de Andalucía precisamente está usando una wiki:
http://www.juntadeandalucia.es/madeja

Un saludo

]]> By: Javier Murillo http://www.manuelrecena.com/blog/archives/337/comment-page-1#comment-1406 Javier Murillo Mon, 29 Sep 2008 14:56:10 +0000 http://www.manuelrecena.com/blog/?p=337#comment-1406 Buenas Manuel, El problema que le veo a esos "libros" es que generalmente suelen quedar relegados en algún punto oscuro del gestor documental empresarial, no mantenidos como se merecen y son muy propensos a la desinformación ya que todo el que entre nuevo debería conocerlo, debería saber como "meterle mano", ... Me recuerda un poco a las normativas de codificación y estilo en los lenguajes de programación. En fin, desde que incorporas y configuras CheckStyle y/o FindBugs en tu IDE favorito y lo cuelgas en un servidor web accesible por todos los desarrolladores, piensas: por qué la hice ? (yo la hice :( jeje). Una proposición que yo haría a tu sistema es mantener toda esta información en un formato que pueda considerarse amigable al cambio, por ejemplo un wiki (aunque entiendo que esto pueda parecer "poco formal"). En la situación de que debas tratar con departamentos de Sistemas del cliente, habría que ver la disponibilidad de su departamento para compartir ese conocimiento del que hablas. En este caso no creo que exista una fórmula mágica, máxime teniendo en cuenta que quien paga tiene "la razón", así que cada cliente puede hacer que tus normativas sean un mundo de heteogéneas. En cualquier caso, si puede ser una buena idea el realizar esos "libros blancos" que comentas compartidos de algún modo para evitar problemas en los momentos de entregas, despliegues, ... Un saludo ! Buenas Manuel,

El problema que le veo a esos “libros” es que generalmente suelen quedar relegados en algún punto oscuro del gestor documental empresarial, no mantenidos como se merecen y son muy propensos a la desinformación ya que todo el que entre nuevo debería conocerlo, debería saber como “meterle mano”, …

Me recuerda un poco a las normativas de codificación y estilo en los lenguajes de programación.
En fin, desde que incorporas y configuras CheckStyle y/o FindBugs en tu IDE favorito y lo cuelgas en un servidor web accesible por todos los desarrolladores, piensas: por qué la hice ? (yo la hice :( jeje).

Una proposición que yo haría a tu sistema es mantener toda esta información en un formato que pueda considerarse amigable al cambio, por ejemplo un wiki (aunque entiendo que esto pueda parecer “poco formal”). En la situación de que debas tratar con departamentos de Sistemas del cliente, habría que ver la disponibilidad de su departamento para compartir ese conocimiento del que hablas. En este caso no creo que exista una fórmula mágica, máxime teniendo en cuenta que quien paga tiene “la razón”, así que cada cliente puede hacer que tus normativas sean un mundo de heteogéneas. En cualquier caso, si puede ser una buena idea el realizar esos “libros blancos” que comentas compartidos de algún modo para evitar problemas en los momentos de entregas, despliegues, …

Un saludo !

]]> By: Manuel Jesús Recena Soto http://www.manuelrecena.com/blog/archives/337/comment-page-1#comment-1405 Manuel Jesús Recena Soto Mon, 29 Sep 2008 10:57:56 +0000 http://www.manuelrecena.com/blog/?p=337#comment-1405 Hola Javier: En nuestra área de desarrollo hay perfiles para esas cosas que comentas, desde un diseñador gráfico hasta un UI Developer pasando por un QA. La situación que describo está relacionada precisamente cuando nuestro trabajo se ve afectado por esos libros blancos donde el cliente tiene departamentos (desarrollo, sistemas) que entre ellos no hablan lo suficiente. Un saludo Hola Javier:

En nuestra área de desarrollo hay perfiles para esas cosas que comentas, desde un diseñador gráfico hasta un UI Developer pasando por un QA. La situación que describo está relacionada precisamente cuando nuestro trabajo se ve afectado por esos libros blancos donde el cliente tiene departamentos (desarrollo, sistemas) que entre ellos no hablan lo suficiente.

Un saludo

]]> By: Javier Murillo http://www.manuelrecena.com/blog/archives/337/comment-page-1#comment-1404 Javier Murillo Mon, 29 Sep 2008 10:47:07 +0000 http://www.manuelrecena.com/blog/?p=337#comment-1404 Quebradores no es lo que queria decir, sino quebraderos :) Cosas del directo Quebradores no es lo que queria decir, sino quebraderos :)

Cosas del directo

]]> By: Javier Murillo http://www.manuelrecena.com/blog/archives/337/comment-page-1#comment-1403 Javier Murillo Mon, 29 Sep 2008 10:46:16 +0000 http://www.manuelrecena.com/blog/?p=337#comment-1403 Saludos Manuel, Sin duda que un proceso de desarrollo no es simplemente el "equipo de desarrollo". No se como trabajais en tu empresa la verdad ni si considerais parte del equipo de desarrollo gente como los diseñadores gráficos o quien realice las interacciones Ajax por poner un par de ejemplos básicos (o si son programadores esta gente también), pero este es otro de los puntos que creo que la palabra clave es COMUNICACIÓN. Puedo asegurarte que si antes de lanzar los scripts a Sistemas (o en nuestro caso los planes de prueba del departamento de Testing, ...) hablas con ellos sobre el tema, se lo propones, se discute, ... ahorrarás el 90% de estos quebradores. El tema de los DBA que comentas me parece bastante interesante, en nuestro caso al final también pasa por trabajar codo con codo con ellos en cuanto a las optimizaciones de las consultas, diseño de vistas, ... aunque es verdad que sus cambios afectan de forma bastante "interna" al equipo de desarrollo. Yo también me he visto en muchos casos mareado por necesidades de DBA´s. Un saludo y buen blog ! Un saludo Saludos Manuel,

Sin duda que un proceso de desarrollo no es simplemente el “equipo de desarrollo”. No se como trabajais en tu empresa la verdad ni si considerais parte del equipo de desarrollo gente como los diseñadores gráficos o quien realice las interacciones Ajax por poner un par de ejemplos básicos (o si son programadores esta gente también), pero este es otro de los puntos que creo que la palabra clave es COMUNICACIÓN.

Puedo asegurarte que si antes de lanzar los scripts a Sistemas (o en nuestro caso los planes de prueba del departamento de Testing, …) hablas con ellos sobre el tema, se lo propones, se discute, … ahorrarás el 90% de estos quebradores.

El tema de los DBA que comentas me parece bastante interesante, en nuestro caso al final también pasa por trabajar codo con codo con ellos en cuanto a las optimizaciones de las consultas, diseño de vistas, … aunque es verdad que sus cambios afectan de forma bastante “interna” al equipo de desarrollo. Yo también me he visto en muchos casos mareado por necesidades de DBA´s.

Un saludo y buen blog !

Un saludo

]]>