Published
por
Comparte este post:

Comentarios

# Miguel Sierra said on Thursday, October 30, 2008 10:27 PM

Bienvenido Juan!!

Seguro que vas a aportar un montón...

Que no se diga que en Cantabria no hay potencial!!

# Jorge Serrano said on Thursday, October 30, 2008 10:37 PM

Bienvenido a esta tu casa Juan.

Espero ansioso que nos cuentes tus avatares.

Me he visto reflejado en muchísimas de las cosas que has comentado, y la verdad es que da gusto ver a alguien que ha evolucionado casi al mismo ritmo que la tecnología, lo cual es admirable. :-)

Yo no sé tú, pero cuando leía tus comentarios, me acordaba de cuando en la casa de mis padres me conectaba a la BBS de Microsoft o la BBS de marras por las noches para no ocupar la línea de teléfono y poder descargarme así los grupos de discusión de Fidonet o esos ficheros de ejemplo, tutoriales o recursos que a veces te sacaban de un aprieto... ¡¡¡que lento que era aquello y con un terminal MS-DOS ANSI con colorines o en blanco y negro!!!.

Ahora las personas tienen accesibilidad a muchísima más información que la que teníamos nosotros hace unos años, pero los 1 y 0 siguen siendo los mismos (de momento). :-)

Bienvenido.

# Rodrigo Corral said on Thursday, October 30, 2008 10:56 PM

Bienvenido Juan!!!

Te leeré con atención... eso si, no pasa nada si pones saltos de línea... :P

¡Un saludo!

# Rodrigo Corral said on Thursday, October 30, 2008 10:58 PM

Joder... en mi opinión tiene buena pinta... desde la arquitectura hasta la interfaz.

# Alonso Morales said on Friday, October 31, 2008 3:47 AM

Justo lo que necesito... un desarrollo de este tipo comentando paso a paso... espero la otra entrada

saludos.

# skno said on Friday, October 31, 2008 5:35 AM

Colega que excelente aporte el tuyo...

Pues mira que yo también estoy en medio de un desarrollo de un ERP, pero tipo freelance, estoy yo solo y he decidido trabajar n-capas, vs2005, y mysql5, y también me decidí por winforms, por varias razones, como por ejemplo el diseño de la interfaz de usuario es mas lento que el de winforms, muchas veces algo simple en winforms puede ser muy aparatoso en aspnet... El proyecto no esta tan bien estructurado en cuanto a análisis y diseño de tiempos y recursos, mas bien cada cosa que me pide el usuario la voy realizando... Yo se que esta mal hecho pero un desarollo "uno solo" es muy complicado hacer todo...

Esperamos mas detalle del proceso de tu proyecto... y hablanos un poco de como te ha ido con esos controles de terceros... por que tienen buena pinta...

Sabes que me parece interesante el manejo de la seguridad, es muy detallado y por medio del treeview se le facilitan mucho las cosas al admin, pero hacerlo es un poco maluco, yo lo hago igual al tuyo manejo una tabla de permisos que tienen su nodo padre y su identificador nodo, y hay una tabla que se relaciona con los permisos y con los usuarios y esta tabla tiene permisosXusuario...

Un saludo...

# Eduard Tomàs i Avellana said on Friday, October 31, 2008 8:10 AM

Pues nada... bienvenido Juan!! :)

Te leeré con atencion... xD

Saludos!

# Javier Crespo said on Friday, October 31, 2008 8:11 AM

Pinta muy interesante...

# Jorge Serrano said on Friday, October 31, 2008 9:35 AM

Juan, felicidades por tu entrada. La interfaz me ha encantado, y tus explicaciones generales son muy claras.

Seguro que nos vendrá muy bien a todos dar un repaso teórico-práctico y debatir a través de nuestras impertinentes preguntas o comentarios.

Ya que nadie ha preguntado nada, aquí va el primer comentario o pregunta (sencilla) al respecto. Sé que un proyecto está repleto de toma de decisiones, así que te pregunto acerca de alguna.:

Dices lo siguiente: "La capa de presentación  está basada principalmente en librerías de controles personalizadas que utilizan controles de terceros de la marca "devexpress", ...".

Luego comentas también: "...todos los formularios maestros heredan de un formulario base que realiza todas las llamadas de forma genérica a la capa de negocios."

Mis preguntas son las siguientes:

Cuando dices que la capa de presentación se basa en librerías de controles personalizadas, ¿te refieres a que utilizais "a saco" los controles devexpress o a que creais vuestros propios controles heredando de los controles de devexpress?. ¿Habéis utilizado controles estándar Windows o solo los de devexpress y los que vosotros os hayais creado?. ¿Porqué os decantásteis por los controles de devexpress principalmente?.

¿Habéis tenido algún problema con los controles en la herencia del formulario base del cuál heredan los formularios maestros?. ¿Existen controles estándar dentro del formulario base?.

Espero que se me entienda.

Felicidades por tu exposición. Espero ansiosamente las siguientes. :-))))

# Pedroafa said on Friday, October 31, 2008 9:45 AM

Jajajaja, veo que tú tambíen has picado con esto de los blogs!!!!.

# Quique said on Friday, October 31, 2008 9:46 AM

Estimado jefe:

Espero que tu nueva aventura en geeks sean productiva y por cierto solo cuenta cosas buenas del proyecto :-p

# PabloNetrix said on Friday, October 31, 2008 12:44 PM

Otia macho, ¿qué os pasa a los 'cantabrones' últimamente? Tenemos aqui ya a todo el CIIN en bloque, ahora tu tambien con blog... Vamos que a mi personalmente me congratula que tu tierra esté un poco "despertando" en tecnología, Cantabria es un sitio donde parece que nunca pase nada... ¡qué tranquilidad! Sois muy buena gente, con muy buenos paisajes y con aún mejor gastronomía. ;-)

Saludos de otro "precoz" friki, de cuando los frikis no nos llamábamos frikis, que empezó allá por 1984 con su Spectrum de 48K...

# sac087 said on Friday, October 31, 2008 2:49 PM

Colega un excelente aporte....

Pues mira que yo también estoy en medio del desarrollo de un ERP diciendo también por winforms, ya que me parece que el manejo de la interfaz en aspnet es mas trabajoso por mas ajax q exista...

Mi proyecto esta bajo vs2005, con mysql y n-capas...

Lo que mas me ha aburrido ha sido el manejo de la seguridad, el cual creo que manejamos de manera similar por medio de treeview y tres tablas, una permisos que indica el nodopadre de cada uno y el identificador nodo de cada uno, una tabla usuarios y una tabla permisosXusuario...

Lo otro que también me ha aburrido ha sido el manejo por la filosofía capas de los reportes... Ya que por cada reporte debo hacer un report document y con un solo reportviewer puedo visualizar el resto pero manejar por capas estos documentos ha sido lo menos intuitivo que haya visto, quisiera conocer tu metedología en cuanto ha seguridad y en cuando a reportes...

Un saludo y esperamos mas detalles de tu proyecto y tips que no falten ;)...

# Lluis Franco said on Friday, October 31, 2008 3:28 PM

:-)

Bienvenido Juan,

Joer, al ir leyendo iba pensando... ¡que viejos somos!

Un saludo desde Andorra,

# Juan Irigoyen said on Friday, October 31, 2008 6:00 PM

Muchas gracias a todos por la bienvenida.

Jorge y Luis Franco, en el último evento, creo que fue el techday del 2007, hicieron una pequeña encuesta, mandaron levantarse según diferentes edades a los desarrolladores que ocupaban la sala, de las más de 2000 personas que asistían al evento casi al finalizar preguntaron “y ahora que se levanten aquellas personas que lleven más de 20 años desarrollando”, creo recordar que nos levantamos tres. Eso si los demás se conservaban peor que yo...

Cuando veo a la gente joven decir ¡mira!… que maravilla… ahora reconocimiento de voz, fíjate puedo diseñar con las manos, me echo a temblar… (Porque alguien vendrá y dira, has visto tal y tal aplicación, esto tenemos que implementarlo).

Sé que todos los que estáis aquí tenis vocación por vuestro trabajo y desde luego en esta profesión no podría ser de otra forma. Espero estar a la altura.

Rodrigo no se qué carajo paso, estaba usando firefox, el caso es que los espacio se borraron, como dice el responsable de sistemas yo creo que el antispan ese que habéis instalado se ha comido los espacios, deberías vigilar el estado de las fibras…

Pedrito, aquí deberías escribir tu, me encanta tu blog, del que como te habrás dado cuenta he copiado la famosa frase, te sigo con atención, no te rindas y paciencia con los Ilitios, que no se diga que en Cantabria no sabemos jugar al golf….

Para los interesados podéis seguirle en http://www.sectorsieteg.net/, no tiene desperdicio.

Quicote, sobre todo hay que contar lo malo, es de los errores de lo que verdaderamente aprendemos, aunque tranquilo, no contare lo de esa relación que tenéis tu compañero y tu…

PabloNetrix, siento desilusionarte, pero veras, nací en Madrid, me nacionalice Guatemalteco y he vivido en Cantabria toda la vida, de la gente de Cantabria prefiero no comentar mucho, te diré que la esencia de los cántabros se vio bastante reducida con la llegada de los romanos, aún así me siento de esta tierra. Qué tiempos aquellos los del spectrum…

# Juan Irigoyen said on Friday, October 31, 2008 11:42 PM

Gracias a todos por vuestro comentarios.

Jorge, Por adelantarte algo la mayoría de los controles que utilizamos son de devexpress, pero encapsulados en XtraUsersControls que es similar al  UserControl de windows con la particularidad de que soportan skins y otras funcionalidades del framework de devexpress.

Debido a que algunos no soportan muy bien la herencia visual y otros introducen gran cantidad de código en el Initialize Component, y que tienen varias funciones y propiedades que hemos implementado  aumentando en algunos casos la funcionalidad de algunos, optamos por encapsularlos.

Desde luego hemos tenido muchos problemas ya que son poco intuitivos, a veces utilizamos controles estándar como el treeview debido al que el XtraTreeView de devexpress es bastante diferente, pero la mayor parte son de devexpress. Te puedo decir que disponen de una librería amplísima, de hecho no utilizamos ni la cuarta parte de los controles que dispone.

La elección de los controles vino fundamentalmente por la necesidad de incorporar un Gestor de Informes, no quería utilizar Cristal Reports. El generador de informes de Xtra es uno de los mejores que he visto, está en c# con lo que el código de cada informe es c# que puedes manipular de forma similar a como lo haces en un formulario windows y el Grid es magnífico para mí el mejor con diferencia de todos los que conozco, los demás vinieron poco a poco, pero si aprendes a utilizarlos son muy buenos.

Creo que el tema de los controles merece él solito un Post aparte, tratare de darte más información ahí.

sac087, efectivamente la seguridad la resolvemos a través de un treeView, con la particularidad de que es interactivo, es decir podemos añadir, borrar, mover, copiar nodos y realizar otras operaciones en tiempo de ejecución, hemos implementado soporte de grupos de usuarios y lo hemos reducido a una sola tabla, eso si es necesario implementar algunas procedimientos recursivos en Sql Server, pero ha resultado interesante.

Nuestro sistema de reports está aislado en un proyecto independiente, con su propia capa de negocios y datos, soportamos XtraReports y Reporting Services, y es bastante compleja ya que guardamos los informes serializados en la base de datos, soportamos herencia visual, traducción en varios idiomas en tiempo de ejecución, gestión de informes anidados, etc.

La aplicación lo hace todo de forma automática crea informe, copia, edita de forma visual, una vez implementada no tenemos más que manejarla como si de un usuario mas se tratase, la única parte complicada es conformar las fuentes de datos a través de de consultas sql, que internamente se transforman en dataset y que son utilizados por el generador de devexpress o reporting services para generar los informes. Lo tratare mas en detalle a lo largo de los Post.

# Jorge Serrano said on Saturday, November 1, 2008 9:13 AM

Juan. Muchísimas gracias. Muy claro todo.

Estaré atento a las próximas entradas.

Creo que es interesantísimo abordar entradas de este tipo, teórico-prácticas que darán mucho que hablar, porque como muy bien sabes, no existe una única forma de hacer las cosas, así que... ¡a disfrutar de tus entradas y de los comentarios que surjan!. :-)

# David Daniel Arroyo Zari "Ddaz" said on Saturday, November 1, 2008 6:15 PM

muy deacuerdo contigo, sobre eso de que ahora salen muchos " arquitectos ", lo bueno es que en la mayoria de casos terminan quemandose solos... a la hora de la ejecucion..., pero sobre eso de los titulos... en si veo un afan desmedido por " mostrar titulos y papelitos" ... recuerdo que una vez vi a alguien que tenia " mcp, mcad, mcsd..." ... jeje...

Sobre la solucion final que tuviste, seria bueno si explicaras mas  como quedo  :)

Salu2

DDaz

# Juan Irigoyen said on Saturday, November 1, 2008 8:03 PM

David, tengo previsto realizar un Post detallado sobre la arquitectura de la aplicación, quizás en un par de semanas, por anticiparte algo te diré que la solución paso por la utilización de generics, que en esos momentos acababa de aparecer con visual studio 2005, esa fue la clave para poder reducir el código de los managers de la capa de negocios y la capa de datos, en la capa de presentación tuvimos que utilizar un interface común, ya que hasta día de hoy todavía no han solucionado el problema de la utilización de generics en la invocación de los formularios.

# Miguel Sierra said on Saturday, November 1, 2008 11:20 PM

Hola Juan!

En estos tiempos que corren existe un virus muy extendido, se llama "titulitis", muy al hilo de lo que comentas...

Me ha despertado la curiosidad los ultimos posts que has escrito ... estaría muy interesado en ir una mañana a visitarte y conocer tu trabajo.

Saludos!!

# Juan Irigoyen said on Sunday, November 2, 2008 1:36 AM

Miguel y Daniel, no me refería a la titulitis, entiendo que haber estudiado en una universidad, haber sido capaz de sacar titulaciones como mcp, mcad, mcsd, etc, tienen un mérito enorme y sobre todo dicen de ti que tienes un nivel  técnico suficiente como para abordar casi cualquier proyecto con arquitecturas de Microsoft.

Hoy en día hay que tener una gran capacidad para sacar cualquier carrera técnica.

Me refiero a que determinado estatus no se puede alcanzar únicamente con una experiencia de 2 o 5 años, convertirte en un experto en c#.net puede llevar más de ese periodo.

La preparación y a la experiencia, son características que simplemente llevan tiempo y que se dan en determinadas circunstancias, por muy bueno que sea un informático si solo ha trabajado con dispositivos móviles a lo largo de su carrera, seguro que será un experto, pero será difícil que pueda desarrollar la arquitectura de un proyecto web si nunca a participado en uno, ya que su experiencia no será suficiente.

Por eso digo que muchos se creen Arquitectos cuando en realidad su experiencia no les permitirá elegir correctamente la solución más adecuada y por eso es tan difícil encontrar buenos arquitectos, por que se tienen que dar un cumulo de circunstancias para que alguien alcance este estatus.

Miguel al hilo de conocernos, claro¡¡¡ cuando quieras, envíame un correo y quedamos.

# Sergio Tarrillo said on Sunday, November 2, 2008 3:09 AM

Quería recalcar el uso de sentido común, que hace tiempo lo escuche de un maestro que dijo: hay que usar el sentido común... y como dices el sentido común no te lo da el haber varios libros (por lo menos el sentido común que se necesita para hacer y resolver problemas de software), el sentido común te lo da la experiencia sea exitosa o no, hable un poco de eso en esta entrada (geeks.ms/.../89195.aspx)

Que sigan tus post, estoy siguiendo la serie :D

Saludos,

# David Daniel Arroyo Zari "Ddaz" said on Sunday, November 2, 2008 3:24 PM

Hola:

Lo de la experiencia, me habia quedado mu claro, aunque no olvides que en estos tiempos, es relativamente facil -para el que solo busca un papel - encontrar preguntas  en la www  y memorizarlas...

pero bueno al parecer no captaste bien lo que puse, si te fijas... mcp, mcad, mcsd.. es lo mismo...(ya que uno contiene al otro), cual seria el motivo de poner los  3 a la vez  en una misma linea??, algo que e visto muy comunmente, es que las personas que sufren de titulitis ( como lo puso miguel) son las que a la hora de la practica -cuando las papas queman- son las que primero caen..., en cambio hay muchos, que el titulo es lo de menos, pero en la practica, te dejan asombrado por todo lo que saben, el detalle es que esto no solo pasa con " arquitecto", o " programador con experiencia", sino tambien con " administrador de servidores, dba, etc...

Salu2

Ddaz

# sac087 said on Sunday, November 2, 2008 3:35 PM

Colega muy enriquecedoras tus experiencias, yo apenas tengo un año como desarrollador y aun no me he graduado de ingeniero, pero si he visto mucho en este campo el egocentrismo que se maneja...

En fin, colega quisiera que detallaras muchísimo mas el uso de generics, por que la verdad no tenia conocimiento de esto y he desarrollado el proyecto sin generics, y creo que es tiempo de parar y cambiar la forma de trabajo...

He buscado en internet acerca de generics, he encontrado material pero muy teorico y solo hablan de su funcionamiento y su desempeño... Quisiera que hablar de una clase en especifica de tu proyecto y nos mostraras algo de código, como es el DAO en generics como es el uso de una identidad en generics...

Colega un saludo y espero pronto mas posts interesantes de tu proyecto y experiencias...

# Jorge said on Monday, November 3, 2008 8:38 AM

En mi casa, y utilizando parte del poco tiempo de ocio que tengo, estoy "escribiendo" y definiendo la arquitectura (la que será base del desarrollo) de un programa de gestion ERP que iré enriqueciendo poco a poco (hasta que tenga algo presentable). En ella intentaré utilizar todos los conociemientos de programación que tengo bajo las premisas de "hacerlo todo bien desde el principio", "intentando hacer los componentes genéricos pensando mucho ahora para tener que escibir poco luego" y "hacerlo luego las pantallas lo más en producción en cadena posible (automatizando)". Seguiré con mucha atención tus post.

De momento creo que esto a lo mejor te será útil.

blogs.sqlxml.org/.../patterns-amp-practices-app-arch-guide-2-0-beta-1.aspx

Un saludo y mucha suerte.

# Juan Irigoyen said on Monday, November 3, 2008 6:39 PM

Sergio, gracias por la entrada, no la había leído.

Sac087, no te preocupes, intentare detallar con código parte de la arquitectura,  y  que sea compresible para todo el mundo, espero terminar el post a lo largo de la semana.

# Julio Trujillo Leon said on Monday, November 3, 2008 6:55 PM

Una pregunta Juan ¿Que opinas de poseer un framework? Yo he sido siempre partidario de ellos poero me ha sorprendido ver a gente de plain concepts "sonreirse" cuando le comentas algo del framework, no te dicen nada pero no estan muy en su favor ¿que opinas tu? ¿crees que es necesario tener un framework o al menos una fina capa en interface de usuario y acceso a datos que te permita hacer manipulaciones gordas tocando en un solo sitio? A lo mejor es que yo me he quedado anticuado, no sé, ummmmmm

# Juan Irigoyen said on Monday, November 3, 2008 8:20 PM

Julio, no sé muy bien si te refieres a un framework de terceros, si es así, te voy a intentar responder con otra pregunta ¿Cuanto control necesitas tener sobre tu aplicación? Si tu respuesta es:

A mí el control sobre mi aplicación no me importa excesivamente,  la funcionalidad que quiero implementar me la ofrece el framework, te diría adelante, utilizalo, lo erróneo seria no utilizar algo que se supone esta hecho, probado y lo utiliza más gente que tu.  

En cambio si tu respuesta es, el framework me ofrece muchas cosas, pero hay alguna que necesito implementar y con las reglas del propio framework se me hace muy difícil. Entonces si tienes un framework que no te puede ofrecer aquello que necesitas porque añadirle cualquier cosa es más complicado que hacerlo tu mismo, no lo utilices.

La principal ventaja de los Frameworks es que el desarrollo es muy rápido, incorporan gran cantidad de utilidades Autentificación, Seguridad y otras que permiten que el desarrollo sea increíblemente rápido, en algunos, los desarrolladores hacen una labor de parametrización más que de programación.

En proyectos en los que prima la rapidez y los requerimientos son sencillos o los recursos limitados, me refiero a “personal, capacitación, presupuesto y otros factores”, puede ser una buena idea utilizar un framework.  

Las posibles desventajas son:

- Pierdes el control de tu aplicación, si utilizas funcionalidad ya creada, no sabes cómo funciona internamente, realizar cambios y modificaciones suele ser más costoso.

- Cuando quieres añadir algo de funcionalidad, tienes que aprender cómo funciona el internamente, esto a veces es una tarea larga y tediosa.

- Algunas veces no puedes romper sus reglas de negocio, estas suelen ser estrictas para hacer que  todo siga funcionando.

- Los framewoks muchas veces implementa gran cantidad de funcionalidad que nunca vas a utilizar, esto hace que las aplicaciones consuman más recursos de los necesarios.

- Creas dependencia del proveedor. Para aumentar la funcionalidad del desarrollo dependes de su  proveedor, si este abandona el proyecto, estas condenado a que tu aplicación no pueda evolucionar.

En cualquier caso debes pensar una cosa .net es un framework excelente y todo el mundo lo usa, porque su construcción está muy bien realizada y se puede extender con facilidad.

Así que la decisión es muy fácil, pon tus especificaciones en una balanza y elige aquella que más se adapte a tus necesidades.

Espero haberte ayudado.

# Rodrigo Corral said on Monday, November 3, 2008 10:52 PM

@Julio: Si quieres saber por que nos sonreimos en Plain Concepts cuando oimos hablar de frameworks: geeks.ms/.../el-requeteframework.aspx

Iba a ser un comentario... pero me he alargado...

¡Un saludo!

# David Daniel Arroyo Zari "Ddaz" said on Tuesday, November 4, 2008 5:38 AM

algunas imagenes no se logran ver... :(

# Julio Trujillo León said on Tuesday, November 4, 2008 9:03 AM

Hola Juan, gracias por tu respuesta

Hola Rodri, saludos a Jose Luis Soria.

Haber, antes de nada, comento mi entorno o mi mundo, he pecado de no hacerlo, creo que con eso entenderemos la potencia de un framework

A principios de los años 90 en la empresa donde entonces trabajaba nos hicimos un framework (en lenguaje C), y todas las aplicaciones se basaron en él (aplicaciones de paquetes estandard), cuando llegó windows 95 y sucesores, solo tuvimos que cambiar la parte del framework de interface de usuario, y encima nos la hicieron fuera; se la encargamos a un partner de Microsoft que hacía outsourcing, es decir, de la noche a la mañana tuvimos TODAS las aplicaciones de modo consola a modo grafico (diálogos windows). Lo mismo ocurrió con el acceso a datos, pasamos de gestor de ficheros a una BBDD con un esfuerzo muy poco costoso.

Ahora trabajo en otra empresa muy parecida, tenemos software de aplicaciones estándard y estamos migrando a .Net, cuando hablo de framework hablo de desarrollarnos uno nosotros, no muy extenso pero que cubra areas de acceso a datos, interfaz, seguridad, publicación de información etc...

¿Que opinais?

PD Si quereis posponemos el tema para otro post, avisarme y me suscribo.

Un saludo

# Juan Irigoyen said on Tuesday, November 4, 2008 7:26 PM

Daniel lo siento, ya esta corregido.

# Eduardo Obregón said on Thursday, November 6, 2008 8:25 AM

En mi opinión tienes razón en muchos de los puntos que comentas, pero yo resaltaría que cuando dices que es necesario integrar al cliente en el equipo de trabajo, lo más importante es encontrar a la persona dentro del cliente, la cual esté suficientemente preparada y motivada para ser ese punto de conexión fundamental para lograr que el proyecto tenga éxito. Si nos confundimos de persona o no existe no hay nada que hacer.

# Rodrigo Corral said on Thursday, November 6, 2008 9:05 AM

@Eduardo, yo creo que lo importante es que el equipo oiga a través de una única voz las necesidades del cliente. Si esta voz, es del propio cliente, perfecto, sino, pues alguien del equipo tendrá que preocuparse de descubrir y priorizar esas necesidades.

@Juan, espero que comentes cosas sobre como os ha ido con Scrum.

¡Un saludo!

# Julio Trujillo Leon said on Thursday, November 6, 2008 9:08 AM

Si esto te parece compilcado (que lo es) imagínate el desarrollo continuo sobre productos estandard que se versionean cada año.

En este plano que comentas al menos cuentas con un cliente que te va diciendo por donde ir.

Pero el desarrollo de aplicaciones estándar es lo mas chirriante para los oidos (y para el alma) que puedas encontrar: un grupo de usuarios te reclaman un conjunto común a todos ellos de mejoras que justo otro grupo de usuarios te advierte que "eso" entorpece la operabilidad de la aplicación y es algo por lo que no piesan pagar.

En informática, lo fácil es difícil, y lo difícil es el dia a dia.

# Miguel Sierra said on Thursday, November 6, 2008 9:11 AM

Hola Juan!

Estoy muy de acuerdo en lo que dices, de todos modos cambiar el sistema es muy complicado ya que cuando ciertas entidades(Gobiernos, ayuntamientos, empresas grandes...) sacan un pliego, quieren una oferta del coste total del proyecto y esto es algo complicado...

Ahora estoy en pleno proceso de implantación del modelo CMMI y aunque no tenía plena confianza en este sistema de trabajo, soy de una manera de penbsar mas "agil" ;), he observado que los métodos de estimación son muy buenos, y que mejora con la experiencia y que se puede abordar y presupuestar un proyecto grande, con una tasa de error muy baja.

# Rodrigo Corral said on Thursday, November 6, 2008 10:36 AM

@Miguel, CMMI no dice nada sobre cómo debes estimar. Así que los métodos de estimación serán los que vosotros o vuestro consultor de CMMI elijáis.

Dicho, esto, hay un cambio radical, absoluto y espectacular entre estimar de manera explicita, sea como sea y no estimar de manera explicita.

Las administraciones no son reacias a Scrum o el desarrollo ágil, el problema es que nadie se lo explica. Yo cuando he hecho el esfuerzo siempre a sido fructifero. Los clientes sean los que sean, lo que quieren es ver que tienes un camino claro para cubrir sus necesidades y aportarles valor. CMMI es un camino claro para trasladarles tus costes metodológicos, y para diferenciarte mediante una certificación, pero no tengo tan claro que sea un camino para trasladar valor. Pero bueno todo el mundo sabe que yo prefiero un efoque ágil frente a un enfoque CMMI :).

@Julio, precisamente en la situación que describes es cuando es más importante tener un Podruct Owner o Product Maneger que aune las voces de los clientes actuales y potenciales y haga un trabajo de continua priorización de las necesidades. Seguro que hay más peticiones de los clientes que las que podéis abordar, la clave está en hacer aquellas que aportan valor y evitar aquellas que solo aportan valor a un número muy limitado de la base de clientes. Hay técnicas para asegurar que aciertas, en la medida de lo posible, en este proceso.

¡Un saludo!

# Miguel Sierra said on Thursday, November 6, 2008 11:34 AM

@Rodrigo, a mi me exigen tener unas tablas de estimaciones donde quede muy claro, por ejemplo, la complejidad del formulario (nº de controles, grids, busquedas, ordenaciones...), tipo de formulario (web, ajax, disp. movil, wpf, forms...), la habilidad y la categoría del desarrollador y eso genera la estimación que mas el factor de ajuste del jefe de proyecto da la estimación, todo esto debe quedar registrado en un histórico que de una media... el objetivo es no dejar la estimación completamente al estado de ánimo, optimismo y experiencia del que estima... el caso es que esta es la exigencia, para acceder a CMMI nivel 2, esperando llegar al 3 en un año... Yo al igual que tu, tenia mis dudas (vamos que no confiaba en que aportase valor, solamente coste) el caso es que yo ya estoy empezando a ver las ventajas del modelo y en concreto la estimación me parece muy buena.

Mas que nada veo que CMMI evita riesgos y dependencias de personas, si todo está documentado y organizado.

Volviendo al ejemplo de la estimación, si cambia el jefe del proyecto..., en que se basa para estimar ¿? pues con este sistema tendrá unas referencias sólidas para realizar sus estimaciones.

Voy a escribir un post de mis esperiencias con CMMI (las buenas y las malas) y lo discutimos sobre él ¿os parece?

# Juan Irigoyen said on Thursday, November 6, 2008 11:40 AM

Eduardo, te contesto lo mismo que a Rodrigo.

Rodrigo, entiendo lo que dices de tratar que el equipo oiga a través de una única voz para no distorsionar el contenido, si bien, tengo mis dudas con esta afirmación.

En el caso de que la persona elegida no tenga un perfil adecuado, es decir “sea capaz de captar y comunicar perfectamente las necesidades de la empresa y de aquellos que trabajan en ella”, el desarrollo se realizara de manera errónea.

En mi opinión si hacemos esto, corremos un riesgo enorme, nos apoyamos en el “saber hacer de una sola persona”, he descubierto a través de la experiencia, que la mayor parte de la gente desconoce el trabajo de otras personas y que muchas veces se crea una opinión errónea de su trabajo, incluso con aquellos que les rodean, creo que es importante hablar con las personas que realizan los cometidos de forma individual, ya que son ellos los mejores conocedores de su trabajo.

Lo ideal para mi, seria obtener la información del responsable conjuntamente de las personas que realizan el  trabajo,  entiendo que esto pueda entrañar ciertas dificultades, creo también que la persona responsable la encargada de realizar este trabajo, pero obtener dos puntos de vista de forma directa nos puede aportar visión de ciertos aspectos que de otra forma desconoceríamos.

Intentare hablar, solo un poco de nuestra experiencia con Scrum, ya que no me considero un buen ejemplo a seguir, sin bien estoy completamente de acuerdo con la metodología, fallamos en que no tenemos la suficiente disciplina para sacarle el partido que realmente merece.

Julio, simplemente es una cuestión de disciplina, si llevas a cabo un solo proyecto utilizando una metodología como “Scrum”, te darás cuenta de forma inmediata de sus beneficios, es lo mismo que trabajes con un proyecto a que trabajes con cien, entiendo la problemática con “ciertos clientes”, ya que en esta vida me ha tocado lidiar con todo tipo de gente, pero te puedo decir que metología se adapta a tu trabajo y no como piensan algunos “tú te adaptas a la metodología”, es un método que te facilitara el control de tu proyecto y te dará información importante sobre tu velocidad de desarrollo pudiendo realizar una estimación mucho más real, fomenta el trabajo en equipo  y aporta muchas otras ventajas.  Pero no pienses que es la solución a todos los problemas de un desarrollo y de la relación con tus clientes.

Miguel, siento decirte, que, de lo poco que conozco de CMMI, me parece de todo menos una metodología ágil, me parece más un proceso que burocratiza todo lo que haces, pero no me hagas mucho caso, no soy ningún experto de CMMI, y pienso que es mejor utilizar una metología que no utilizar ninguna. Siempre se aprende algo.

# Miguel Sierra said on Thursday, November 6, 2008 12:31 PM

Sobre CMMI, yo pensaba lo mismo, Juan, pero tras unas formaciones y experiencias, ya empiezo a ver la luz al final de este tunel (CMMI) y creo que va a aportar control a los proyectos... bueno, ya os contaré mas ;)

# Juan Irigoyen said on Thursday, November 6, 2008 12:56 PM

Miguel Sierra, perfecto, esperamos tu post.

# yazquez said on Thursday, November 6, 2008 2:18 PM

Hola a todos.

@Miguel, no entiendo muy bien como podeis estimar en función de criterios como el numero de controles, grids y ese tipo de cuestiones ¿significa que un formulario con 8 controles es el doble de complejo que uno que sólo tiene 4? ¿no tendrá más complejidad la lógica de negocio asociada a esos controles que los controles en sí?. No sé, a mí esto de estimar siempre me ha parecido harto complejo y los intentos que hemos realizado con criterios parecidos al que propones no nos han dado mucho resultado. La verdad estoy intrigadísimo porque cuentes como os va con ellos.

Un saludo.

# Lucas Ontivero said on Thursday, November 6, 2008 2:36 PM

Hola Juan,

Yo veo acá algunos conceptos que si bien están muy relacionados entre si, no son lo mismo. En tu post tocas, sin hacer una segunda lectura más profunda, 4 temas distintos:

- Estimaciones.

- Presupuestación (relacionado pero un tema aparte)

- Negociación (por lo menos en cuanto a los cambios de requerimientos que mencionas como ejemplo)

- Metodologías.

En cuanto a las estimaciones...ummm.. que decir, son todo un temas, hay mil técnicas y a mi entender no hacen mucha diferencia ya que por el concepto de "cono de la incertidumbre" todas te dan un valor bastante alejado. Cuando usas mas de una técnica  podes reducir un poco el error, pero bueno, EL libro es el de McConnell (imprescindible leerlo).

La presupuestación es un tema totalmente aparte. Contempla las estimaciones pero no es una función directa. Es otro tema.

En cuanto a los cambios en los req. (cuando el cliente quiere cambiar cosas que no le gustan) ese es un "nuevo trabajo" que se debe estimar y presupuestar nuevamente, no significa que si el cliente quiere cambiar todo el sistema uno lo tiene que rehacer gratis. No hay que confundir esto, es importante.

Las metodologías no tienen mucha relación con las estimaciones más allá del marketing. Por ejemplo, si quiero estimar una tarea y estoy utilizando una metodología agil nada me impide utilizar una que usan mis amigos en sus proyectos con CMMI 5. Lo que pasa es que el m'arketing hace que las cosas mal sonantes se relacionen con CMMI (ej: cocomo II) y a s m'as naturales y habituales les ponemos la palabra "ágil" para que suene mejor (ej: tecnicas de estimación agiles). No existen las tecnicas de estimación agiles, son solo tecnicas de estimación y algunas ultraconocidas pero rebahutizadas. No hay nada nuevo bajo el sol en cuanto a estimaciones.  

# Juan Irigoyen said on Thursday, November 6, 2008 7:46 PM

Lucas, te agradezco mucho tus comentarios, te sigo desde hace tiempo.

Sobre el post te diré varias cosas:

Yo estoy hablando de gestión de proyectos en general, para mí la estimación, presupuesto, negociación, metologias, equipos de trabajo, etc, son partes de un proyecto, del que solamente me interesa una cosa, que sea exitoso, entiendo que un proyecto está compuesto por infinidad de factores relacionados, los que comento en este post son dependientes unos de otros, es muy raro verlos por separado aunque admito que se puede dar el caso.

No soy un experto en estimaciones, tan solo expongo la que utilizo con Scrum, sé que hay muchas formas de estimar, te agradezco lo del libro, tratare de leerlo.

Yo nunca he dicho que los cambios no tengan que repercutirse al cliente, digo que es una posibilidad que se abre para que el cliente pueda realizar modificaciones y adaptar mejor su programa en la misma fase del desarrollo, con lo que los efectos colaterales serán menores.

La presupuestación desde luego que tiene factores añadidos, pero la estimación suele ser uno de los valores que más relevancia tienen en esta fase, aunque no siempre, estoy de acuerdo con lo que dices.

En Scrum, estas estimando cada tarea y en cada sprint evalúas las tareas que puedes realizar durante un periodo de 20 a 40 días, sin estimación perderia mucho de su valor.

En cualquier caso aprovecho para hacerte una pregunta ¿Podría funcionar cualquier metología agíl sin estimación?

Me gustaría hablarte de lo que pienso de la estimación, pero no quiero alargarme más, intentare pensarlo bien, y dentro de unas semanas quizás escriba un Post.

Saludos y gracias por tus comentarios.

# Lucas Ontivero said on Thursday, November 6, 2008 8:42 PM

Creo que estamos de acuerdo en todo. Yo solo expongo algunas cuestiones y nada mas que eso. Es un tema dificil. Este es el segundo año que tomo el curso obligatorio de estimaciones (16hs en dos dias solo de esto parace mucho, al menos a mi me parece) y siempre se dan discusiones que a veces resultan muy interesantes como las que planteas aquí.

Casi siempre por mi defensa sobre ciertas formalidades me acusan de antiagil o ridiculeces por el estilo pero realmente no es así, es solo que reconozco mucho marketing en todo esto. Cualquier pibe que nunca ha trabajado "sabe" que las metodologias agiles son mejores que las ingenieriles y eso solo se logra mediante marketing. Todo el que toma un curso sobre estimaciones formales sale como hipnotizado, como si hubiese tomado la pildora roja, y ese lavado de cerebro es marketing también.

Lo que dices sobre las estimaciones de los sprints de scrum creo que es una de las mejores cosas que hay. Estimando por sprints hace que la incertidumbre se reduzca muchísimo y eso redunda en mejores estimaciones ya que no tenemos un cono gigante sino muchos conitos. Ahora, es posible que para presupuestar debas entregar una rom a tu cliente. Como lleves adelante tu proyecto luego es cosa aparte. Se que muchos quisieran no tener que hacer esto y simplemente pactar con el cliente cada parte del proyecto pero el mundo no es así. Aunque todo es relativo, no todo lo que funciona para proyectos de 3 meses aplica para proyectos de un año, ni es lo mismo hacer soft para una cadena de comidas rápida que hacerlo para el gobierno, bancos, aeropuertos. Todos se pactan de manera diferente.

Un ejemplo que no se si viene al caso pero hace dos meses que en mi equipo trabajamos con timeboxs (tenemos un deadline definido) y estimamos con wideband para estimar cuanto podemos hacer en ese tiempo y luego lo negociamos con el cliente. Aquí, los conceptos que te mencionaba están muy divididos ya que el presupuesto es muy simple: un ing x mes = $xxxx --> 4 ing. x 3 meses = 12 x $xxxx.

Las estimaciones no se relacionan con el presupuesto en este caso. Y la metodología es una mexcla infernal, en este momento nosotros no la hemos elejido todavia y nuestro cliente interno usa scrum y en general todos conocemos cmmi y así.

Bueno... me fuí por el teclado :) sorry.

Un abrazo.

# Rafa said on Tuesday, November 11, 2008 12:38 PM

Hola Juan, es mi primer comentario en tu blog, pero no he podido resistirme al ver tu post y los comentarios.

He acudido a varios cursos de Rodrigo sobre administracion de proyectos, metodologias agiles y demas. Con la experiencia que tengo en este mundo, ya van 11 años, mi opinion es que estas metodologias solo sirven para grandes o grandisimos proyectos en los que esten metidos asesores externos y personal tecnico del cliente o para proyectos internos, es decir para los propios proyectos de empresas de software. ¿Por que?, yo creo que primero el cliente no sabe lo que quiere, o mejor matizo, sabe perfectamente lo que quiere pero no sabe como plasmarlo en un desarrollo informatico. El cliente solo paga cuando el trabajo está hecho, es muy bonito que el cliente vaya pagando segun los modulos entregados, pero la verdad es que si el cliente no tiene todo, la tipica frase es: "No tengo nada". La implicacion del cliente o del maximo responsable de tu cliente la mayoria de las veces es escasa o mas bien nula, y lo entiendo, esto es diferente a todo lo demas, yo si me compro un armario empotrado le digo lo que quiero al carpintero, pero no me va ensañando las baldas que va haciendo, si me compro un coche, pues no me voy a la fabrica, si me compro una casa, esta en la mayoria de los casos es "estandar" como el software y cuando esta me la entregan no se adapta a mis necesidades (como dicen mis clientes con sus programas), pero lo unico que puedo hacer es joderme y esto esta asumido por la gente, no asi en el caso del software. Realmente es un mundo y un tema para tesis doctoral, yo en este mega comentario no aporto nada, lo se, pero es que no tengo ni idea de que aportar.... Esto sirve muchas veces de terapia, lo se, los psicologos deben de tener sus consultas llenas de jefes de producto.

# Juan Irigoyen said on Tuesday, November 11, 2008 4:55 PM

Rafa, me he extendido, tus comentarios son muy interesantes, te contesto en otro post surgido en base a la respuesta de este.

geeks.ms/.../191-debemos-cambiar-la-forma-de-vender-software-continuaci-243-n.aspx

Saludos.

# Fidel said on Tuesday, November 11, 2008 5:35 PM

Bueno Juan , en el fondo de la cuestión entiendo que tienes razón , aplicar metodologías repercute en el beneficio nuestro y en el proyecto , pero creo que se te escapa un parámetro adicional muy importante que es la dimensión del proyecto y el tipo de cliente . Si tenemos que realizar un proyecto donde el factor primordial y básico es el coste ( y que este sea mínimo )  evidentemente  pese a sú importancia  tienes que reducir costes de desarrrollo , y entre ellos la aplicación de metodologias en el proyecto , evidentemente no es lo mismo desarrollar un proyecto por 6.000€ que uno de 100000€ ;por eso entiendo lo que quiere decir Rafa ; el tema de aplicación de metodología pese aser ideal a veces es inalcanzable por la propia ideosincrasia , limitaciones  del proyecto  y aunque no sea recomendable ni quieras hacerlo no te quedan más narices que tomar la decisión de no aplicar metodologías .

Saludos

# Ibon Landa said on Tuesday, November 11, 2008 8:47 PM

@Fidel: si el coste es un factor primordial, con más razón para aplicar una metodología.

Usar una metodología no tiene por qué implicar más tiempo de proyecto. La metodologías están por algo, no están por tener o por decir qué tengo algo. No aplicar puede implicar más tiempo de desarrollo por no tener bien los requisitos, por no gestionar los riesgos, los impedimentos y todos los problemas que pueden surgir por trabajar a salto de mata...

Me viene a la mente esta dicho popular: "visteme despacio que tengo prisa."

Eso sí, el proceso de pasar de no tener nada a trabajar con una implica una inversión, que hasta la adaptación tendrá un coste que posteriormente tendrá una gran recompensa. Las implantaciones implican inversión.

Un saludo,

# Juan Irigoyen said on Tuesday, November 11, 2008 9:44 PM

Fidel, estoy completamente de acuerdo con lo que te dice Ibon, añadiría también que la metología está formada por un conjunto de normas  que hacen que la realización de nuestro trabajo se realice de una forma más ordenada y nos permite controlar y estimar mejor el proyecto, no sé porque se miran las metologías como algo que nos va a costar dinero, bueno rectifico, en el caso de CMMI, seguramente si queremos certificarnos esto tenga un coste, pero si hablamos de Scrum que es la que comparte las ideas del post no. Está claro que si la usamos por primera vez necesitaremos algo de tiempo y sobre todo disciplina para sacarle partido, pero esto pasa con cualquier tecnología nueva que abordemos.

El coste del proyecto no tiene nada que ver, para mi es más fácil utilizar una metodología que no utilizarla, independientemente del coste y complejidad del proyecto, si lo hago es porque me proporciona ventajas que de otra forma serían muy difícil de obtener.

# José Fortes said on Tuesday, November 11, 2008 10:31 PM

Defendiendo y pareciéndome excelente una metodología como Scrum, estoy de acuerdo con algunos comentarios que ponen de manifiesto algunos problemas que surgen con los clientes en la estimación del costo de un proyecto.

Pese a todo lo que hablemos sobre lo importante que es convencer al cliente de las ventajas que va a obtener si no fijamos un precio cerrado hoy, sino que es mejor una estimación viva sobre entregas parciales, o incluso si simplemente le decimos que no podemos afinar en el presupuesto sino a "nivel orientativo" debido a que el grano fino se tratará cuando se aborde un determinado módulo, muchas veces el cliente no pasa por ahí y se niega en redondo.

Es decir, por mucho que le expliquemos que tendrá una lista de funcionalidades sobre la cual podrá modificar su orden de implementación, añadir nuevas, eliminar, extender, etc. y que esta ventaja y flexibilidad hará que no podamos darle un presupuesto cerrado desde el principio, muchas veces la respuesta será que eso es inviable porque hay que pasar un presupuesto al departamento que aprobará el proyecto, porque se necesita saber el presupuesto ahora y no embarcarse en algo "indefinido", porque...

Con esto quiero decir que en mi experiencia, hay casos en los que es imposible convencer al cliente de esto y la única manera de aceptar cierto proyecto es dando una estimación de costo de la que luego habrá que desviarse muy poco. En este caso la toma de requisitos toma un papel crucial (más si cabe) desde el principio, ya que serán un factor determinante para dar ese presupuesto. En estos escenarios siempre he pensado que Scrum no da una respuesta satisfatoria para la gestión del proyecto de cara al cliente, otra cosa es internamente en el equipo de desarrollo.

En resumen, creo que no se puede achacar todo a la necesidad de "convencer" de que estamos proponiendo la manera correcta de gestionar el proyecto de cara al cliente, ya que al final, esta decisión es cosa de las dos partes y si una parte se niega no se podrá llevar a cabo.

Ya me comentan qué piensan sobre esto.

¡Saludos!

# Rodrigo Corral said on Tuesday, November 11, 2008 10:32 PM

Comparto todo lo dicho por Juan y por Ibon, pero no me resisto a escribir... aunque sea en la misma línea.

Entiendo perfectamente lo que comenta Rafa... durante mucho tiempo se ha pensado que el cliente era el enemigo y eso lo pagamos. Pero hay que cambiar la manera de relacionarse con el cliente. Es necesario establecer una relación basada en la confianza y la colaboración. Es indispensable hacerlo así para que los proyectos sean exitosos.

Pero la confianza empieza por nuestro lado, nosotros debemos confiar en los clientes y dejarles patente que queremos colaborar. Que necesitamos sus feedback, que el software es mucho más complejo que las baldas y que solo si tenemos feedback podremos llegar a una solución que les sirva.

Además una diferencia sustancian es que no tiene sentido entregar un coche por etapas, un coche sin ruedas no sirve. Un software sin un par de informes y un par de pantallas y sin el manual pero con tooltips en los campos puede servir, aunque a la larga sea necesarios esos informes o el manual o las pantallas que falta.

Es necesario un cambio de mentalidad, algunos ya estamos en ese cambio y ya estamos promoviendo ese cambio también en nuestros clientes. Evidentemente, no todos los clientes querran andar este camino, ni todos los equipos de desarrollo...

Hace mucho escribí sobre esto en mi blog, creo que sería interesante y que viene al caso, por si os interesa: geeks.ms/.../No-les-vamos-a-volver-a-enga_F100_ar.aspx

¡Un saludo!

# Eduardo Obregón said on Wednesday, November 12, 2008 7:20 AM

Buenos dias a todos; me gustaría dejar una pregunta al hilo de tu post Juan, ¿Se deben descartar clientes según su nivel participativo(a la hora de involucrarse), al igual que se descartan por su solvencia? Tiene esto que ser un parametro más?, Porque todos conocemos clientes imposibles..merecen la pena??

Saludos.

# Juan Irigoyen said on Wednesday, November 12, 2008 9:06 AM

Rodrigo. Excelente post que lei hace tiempo y que comparte la esencia de lo que se dice aqui.

Eduardo, yo creo que no debemos descartalos, sino convencerlos de que la importancia de la comunicación y la colaboración entre ambas partes es vital para el correcto desarrollo del proyecto.

Si decimos a un cliente: si no estas dispuesto a colaborar, el proyecto tiene grandes posibilidades de ser un fracaso, este seguramente se lo piense antes de adjudicarnos el proyecto si no quiere participar.

El problema es que desde las empresas que venden software esto no se hace, la empresa suele decir, bueno si usted no colabora tenemos a una persona muy experta en estos temas que desarrollo algo parecido o frases similares.

Esto es debido a que no estan dispuestas a marcar sus reglas con tal de no perder el proyecto, entiendo la dificultad que entraña decir que no, sobre todo para las pequeñas empresas que tienen mas dificultades, pero hay veces, que es mejor hacerlo a realizar un proyecto sobre el que tenemos muchas posibilidades de fracasar.

Si informamos al cliente de su error y este asume el riesgo de realizar el proyecto de esta forma, podremos realizarlo, sabiendo que le hemos informado correctamente de los riesgos que conlleva, al menos no le estaremos engañando...

# Rafa Serna said on Wednesday, November 12, 2008 12:16 PM

Hola Juan otra vez, lo primero agradecer que un comentario mío sirva para generar una nueva entrada en tu blog y seguir dándole vueltas a este tema.

Voy por partes. Lo primero insistir, quizás no lo deje bien claro o se me malinterpreto que yo estoy 100% a favor de las metodologías de trabajo, me encanta Scrum, lo que yo quería decir es que me parece complicado llevarlo a cabo dependiendo de qué proyecto queramos afrontar.

Segundo, en efecto el cliente no es el enemigo. Es nuestro mejor amigo mas bien. Lo digo yo que estoy todo el día intentando inculcar a mis compañeros que se olviden de comentar las típicas frases "este tío es un pesado", "no sabe lo que quiere", "y ahora me lo hace cambiar todo", etc... A todos nos fastidia trabajar, y si que es cierto que parece ser que los informáticos de profesión somos los únicos que sabemos manejar ordenadores y que el resto de mortales están en este mundo solo para tocarnos las pelotas y no hacernos caso. Eso está impreso en la cabeza de todo desarrollador y luego eso en la relación con el cliente se nota.

Creo que el problema no es si utilizar o no una metodología de trabajo. Utilizarla por si es muy bueno, nos ayuda en el día a día. Pero creo que no es lo mismo eso que hacer que el cliente "trabaje" con nosotros. Yo puedo en mi equipo de trabajo hacer las cosas muy bien, pero lo que el cliente "persé" espera de mí y de mi trabajo puede no parecerse en nada a la realidad.

Me explico con un ejemplo espero que claro. Yo trabajo en una empresa de software "pequeña". Realizamos desarrollos a medida para pymes, y tenemos nuestras aplicaciones paquetizadas, envueltas en una cajita muy mona y puestos en una estantería para vender. Bien, cuando un cliente nos contrata suele ver una demo de nuestro software, comentarla y decir lo que le vale y lo que no. Tras esto se analiza de forma más minuciosa la situación y se redacta un análisis mas detallado. Ahora nos ponemos a trabajar. La mayoría de las veces el cliente (y lo digo por mi experiencia, si alguno es de otra manera, suerte que tiene), no tiene tiempo para probar lo que tú le vas haciendo, muchas veces tu software reemplazara a otro ya existente y la gente te dice (creo que con razón), "no me voy a poner a hacer las cosas dos veces". Bien con esto ya empiezas a no tener el feedback del cliente, el lo puede probar, pero no usar, que son dos concepto totalmente diferentes.

Cuando tu acabas tu trabajo, se sustituye como digo, el software anterior empiezan los problemas.

Cliente: "Esto no hace esto, esto y esto otro".

Jefe de producto: "Pero si tengo un análisis de hace 2 meses, en donde no hemos especificado nada sobre lo que me está contando".

C: "Para tener un programa que me haga lo mismo que el anterior, para eso no cambio".

JP: "Pero si usted me dijo que el análisis lo hiciéramos viendo pantalla por pantalla lo que ya había implementado?".

C: "Pero si no está hecha la parte de taller, el jefe de taller cuando se hizo el análisis estaba de vacaciones y utilizaba un programa hecho en cobol del año de la polca que solo tenía en su ordenador".

JP: "¿?¿?¿?¿?¿?¿?"

La solución a todo esto, es fácil, ampliación de presupuesto y vuelta a hacer un análisis, fase 2. Mala cosa esta, una ampliación de presupuesto significa más dinero, el cliente no está dispuesto, la aplicación ya esta coja desde el primer día, malos rollos, los trabajadores de la empresa tiene que hacer lo que en un principio no querían, trabajar con dos programas a la vez. Solo hay dos salidas o te comes las horas de rehacer/terminar, o discutes con el cliente y la batalla ya está en marcha.

Mi conclusión es la siguiente. Métodos de trabajo, por supuesto que si, relación con el cliente también, implicación de este, fundamental. Estoy totalmente de acuerdo con Eduardo Obregón, yo no trabajo con un cliente que no se implique porque se lo que pasa luego. Por eso decía en mi primer comentario que si el cliente posee personal técnico implicado o un asesor/consultor externo las cosas suelen salir mejor y es más fácil implicar al cliente.

Otra de las afirmaciones que decía yo en cuanto a que esto solo funciona con clientes grandes y grandes proyectos, me reafirmo en lo que digo, ya que para cosas pequeñas, yo no puedo estar todo el día codo a codo con el cliente, visitando, haciendo pruebas de concepto, etc.. lo que me va a pagar no compensa ese esfuerzo de horas invertidas. Por eso creo que los desarrollos a medida deben de costar dinero, y el cliente debe de ser consciente de ello, obviamente esto sobraría decirlo, pero es que creo que es el principal problema, la relación entre los conceptos "CLIENTE <-> COMERCIAL <-> DESARROLLO"

# Fidel said on Wednesday, November 12, 2008 12:35 PM

Efectivamente , es ideal todo lo que contais , pero también es cierto que muchas veces la realidad es diferente sobre todo en pequeñas empresas de desarrollo de software , época de crisis , necesidad de aceptar el proyecto por necesidades económicas o por situación estrategica de la empresa , o pese a las pegas que  pongas al proyecto  la empresa lo acepta  ,...etc ; muchas veces la realidad por mucho que no queramos nos sobrepasa pese a la ideonidad de de aplicar metodologías al proyecto. Yo sigo pensando y llevos más de 12 años desarrollando proyectos , que las cosas no son tan sencillas , cada empresa , cliente , proyecto es un mundo  , a veces es muy dificil realizar un análisis profundo y detallado de un proyecto , evidentemente en un mercado tan competitivo como el que tenemos  y por desgracia para nosotros el cliente final en un alto porcentaje de casos " se la suda las especificaciones y metodologias" lo que miran es la "pela"  además de que las personas que toman las decisiones de a que empresa asignar un proyecto son normalmente personas de los departamentos de compras que lo único que miran es el precio  , y es muy dificil o imposible vender un producto un 50% más caro que la competencia aunque sus análisis o informes del proyecto sea un papel de 1 hoja con 2 líneas .

Además existe otro tipo de cliente  , el listillo , que no quiere análisis ni especificaciones ni nada , porque de esa manera te puede exigir practicamente lo que le de la gana  , evidentemente hay que huir de estos casos , pero puede pasar que pese a la pegas que pongas  la "dirección" decida que adelante ....

Yo creo , y tengo bastante experiencia en el tema , pese a la idoenidad del uso de metologías ,muchas veces es imposible y pese a que estoy de acuerdo de que debemos vender no solo el producto sino que "como lo hacemos" y "porque somo diferentes y mejores  que la competencia"  , pero muchas veces te encuentras con la realidad , y más ahora en época de crisis  , que para el cliente lo único que importa es la "pela" ; te acabará diciendo si todo muy bonito , perfecto pero la competencia me lo hace por menos

Saludos

# Rafa Serna said on Wednesday, November 12, 2008 12:54 PM

Totalmente de acuerdo con Fidel.

# Ibon Landa said on Wednesday, November 12, 2008 1:22 PM

Hola!

No quiero entrar en mucho detalle porque sería otro post tan grande como el de Juan pero según leo algunos comentarios, parece ser que trabajar sin metodologías es mucho más rápido y más barato. Este me parece un grave error.

Que no siempre se puede contar con la ayuda del cliente porque no colabora tanto nos gustaría, perfecto....

y eso significa que no vamos a gestionar nuestros riesgos? que no vamos a tener un listado de requisitos? que no vamos a tener nuestras tareas registradas y estimadas? que no necesitamos métricas para saber cómo vamos? que no vamos a ver cómo es la mejor manera de generar buen código? que no nos vamos a marcos hitos? que no vamos hacer pruebas? que no.....

# Fidel said on Wednesday, November 12, 2008 2:07 PM

Hola Ibon

Que sí que todo muy bien y bonito , que el uso de metologías repercute sin ninguna duda en beneficio de todos , pero sigo insistiendo en que las cosas no son tan sencillas, depeden de un montón de parámetros  , y uno de ellos es la envergadura del proyecto y el coste  ; en un proyecto de 6000€ olvídate de todo lo que comentas , tendrás que tirar de la experiencia y de otros mecanismos que te permitan llevar a buen puerto el proyecto con los menores costes posibles.

Estoy convencido de que más del 70% de los proyectos informáticos que se desarrollan hoy en día  no se usa ningún tipo de metodología , aunque pienso que es un error , es la realidad . Es  más  , al comienzo de vida laboral después de acabar mi licenciatura en informática entre a trabajar en una de la mayores empresas informáticas de este país , concretamente Ibermática , pues te puedo aseguar que en departemento que yo estaba pese a que eramos más de 40 personas trabajando en diferentes proyectos , muy importantes algunos de ellos  , algunos de ellos de largísima duración de años y con unos presupuestos enormes , no existía ningún tipo de metodología de trabajo.....y yo en aquella época era nada más que un simple e inquieto  programador .

Salu2

# Lucas Ontivero said on Wednesday, November 12, 2008 3:41 PM

Llegué muy tarde a este debate parece.

@Fidel: que a uno cuando ingresa no le digan "nosotros usamos scrum" o "nosotros usamos rup" no significa necesariamente que no tengan una "manera de hacer las cosas".

Yo concuerdo con vos en esos porcentajes, es mas o menos el número que yo manejo (70%) y también trabajé en 3 empresas que no usaban ninguna metodología. No obstante en dos de ellas, si bien no tenian un nombre, si habia un m'etodo, un orden y todas las buenas prácticas. Por esa razón yo escribí un post en el que comento que lo importante no son las metodologias con nombre y apellido sino el que cada empresa arme SU propia forma de trabajo que le de mayor resultado.

En este caso yo entiendo que todo lo que dice Ibon es correcto, todo.

La tercera empresa en la que trabajé y la cual no tenia una metodología, era un completo desastre!!! un verdadero y absoluto desastre, era una cosa increible.

Bueno, seguramente alguien dirá que es mejor utilizar una metodologia ya probada y conocida como scrum u otra antes de "inventarse una". Esto puede ser preferible en muchos casos y en otros no tanto. En mi primer trabajo haciamos un trabajo excelente con un producto gracias al liderazgo del que en ese momento era mi jefe. Nunca termin'e de entender el porqué se quizo implementar CMM allí donde las cosas funcionaban bien sin una metodolog'ia de terceros.

Uyy, me fuí.

# Ibon Landa said on Wednesday, November 12, 2008 3:56 PM

@Fidel, por terminar que sino nos enfrascamos en una discusión que no tiene fin :-)

Vuelvo a repetir que el uso de una metodología no tiene por qué implicar mayor coste de proyecto, por lo que no usar una metodología si el proyecto es de 6.000 euros no me vale.

Que en la gran mayoría de los proyectos no se use no significa que sea mejor no usarlas. Yo tb he estado en muchos proyectos sin metodologías sí...retrasos, horas extras, luchas con los clientes, clientes descontentos, fines de semana, código chapuza y en muchos casos, apelando a la heroica para salir adelante :-) Exagero un poco, pero bueno, la idea es esa.

Desde que uso o intento usar una metodología las cosas me van mucho mejor y los grupos de desarrollo con lo que he trabajado tb están bastante más contentos...al menos eso decían.

Un saludo!

# Juan Irigoyen said on Wednesday, November 12, 2008 4:27 PM

Rafa, estoy de acuerdo con lo que expones, en tu ejemplo detallas a la perfección lo que sucede si la implicación del cliente no es adecuada, tan solo decirte respecto a tu último párrafo en que dices que en proyectos pequeños no puedes estar todo el día codo a codo,  utilizar una metología no implica que tengas que estar todos los días codo a codo con el cliente, el esfuerzo es directamente proporcional al tamaño del proyecto.

Fidel, es cierto que muchas veces factores económicos y de otro tipo, hacen muy difícil la relación con el cliente, pero insisto, somos nosotros quien ponemos las normas, entiendo que decir que no a un proyecto en estos tiempos sobre todo para una empresa pequeña es muy complicado. Pero te pregunto, ¿En base a tus convicciones cuantas empresas dicen que no a un proyecto? o al menos trasladan al cliente las implicaciones que tiene no hacerlo de esta forma.

Entiendo que cada cliente es un mundo, pero depende de nosotros transmitirle la necesidad de trabajar en equipo, en cualquier caso cometemos el error, de aceptar las normas del cliente sin estar de acuerdo y la mayor parte de las veces ni siquiera se lo comentamos. El verdadero error está en que aceptamos hacerlo sin resistirnos.

He estado al frente de dos empresas de informática durante varios años, he visto de todo y he tenido que hacer de todo para subsistir, y créeme, se de lo que te estoy hablando. Aceptar un desarrollo de antemano sabiendo que no vamos a contar con la colaboración del cliente y que no vamos a poder establecer las reglas en las que creemos es un error. Esto lo he aprendido a base de tropezar con diferentes proyectos a lo largo de mi trayectoria profesional y no me lo ha enseñado ninguna metología.

La metología ofrece una solución para estos problemas y depende sobre todo de nosotros utilizarla y sacarle valor, surge como una necesidad de muchas empresas que observan que su trabajo no se realiza correctamente.

Creo que el dinero y el tamaño del proyecto no tienen nada que ver, para utilizar la metología de la que hablo, es más, si la utilizas, estoy seguro de que vuestros costes serán menores. Al menos los míos si lo son. No entiendo como los vuestros no.

Ibon, estoy completamente de acuerdo, la metología aporta valor no genera costes, si una metología genera costes, no tiene mucho sentido utilizarla, la metología nos enseña a hacer las cosas bien y obtenemos grandes mejoras y beneficios, mejores estimaciones, mejor forma de trabajar, mejora de la relación del equipo de desarrollo, mejora de la relación con el cliente, mayor control, etc.

buff, como me he enrollado....

# Quique said on Wednesday, November 12, 2008 9:26 PM

Juan,

no estoy deacuerdo cuando dices que: "el esfuerzo es directamente proporcional al tamaño del proyecto", el esfuerzo es el mismo pero tendrás menos reuniones con el cliente o más. El esfuerzo tiene que ser lo mismo para uno grande que para uno pequeño. Puede ser que el esfuerzo del pequeño sea mayor que del grande, porque requiera que calcules cuantos planetas hay en el universo, y el grande sea 100000 formularios que cada uno haga una operacion distinta pero la mayor complejidad sea sumar 1 + 1... uno es en tiempo el otro en complejidad, en tiempo mas reuniones, pero sin complejidad...

# Juan Irigoyen said on Wednesday, November 12, 2008 10:59 PM

Quique, el tamaño de un proyecto, parte de una lista de tareas, como sabes, estas tareas tienen información sobre su duración, la duración esta basada principalmente en la complejidad de cada una de ellas, la suma de la duración de cada una de las tareas nos da el coste total del proyecto o al menos realiza una aproximación, por eso digo que el esfuerzo es directamente proporcional al tamaño del proyecto.

# Quique said on Wednesday, November 12, 2008 11:44 PM

Juan,

A que te refieres con esfuerzo, economico? esta claro que no es lo mismo un proyecto de 1 dia con uno de 100 dias, economicamente hablando. Pero quizas requiera mas esfuerzo el proyecto pequeño por la complejidad, que el grande que puede ser bastante repetitivo. por eso sigo pensando que el esfuerzo NO es directamente proporcional al esfuerzo.

# Pedroafa said on Thursday, November 13, 2008 1:10 AM

Pues fijaros que yo creo que un proyecto puede tener éxito sin utilizar ninguna tecnología. Eso sí, el cliente debe de tener una implicación del 200%. Es  una herramienta para conseguirlo, pero si el cliente no quiere participar, ya puedes usar Scrum, que la metodología más puntera del momento… En un 90% de los casos el cliente no va a tener lo que quiere.

Además, a mí me parece mucho más caro conseguir la participación del cliente, que la inversión necesaria para aprender una metodología e implementarla en un equipo de desarrollo. En cada proyecto que no lo consigas, estás perdiendo dinero. Al final se reduce a n al cuadro de cambios en la funcionalidad, unas funcionalidades, que el equipo acabe hasta las narices de rehacer cosas y que un proyecto de 6 meses se convierta en uno de dos años, sin que el cliente este satisfecho con el producto.

Ahora claro, conseguir que el cliente se involucre es muy costoso porque ya no sólo tiene el coste propio del proyecto en sí, sino que tiene un adicional, y es que el tiempo que te dedique no es gratis para él. Pero a mí me parece que es la llave para que el cliente piense que tiene el mejor producto del mundo mundial.

Un saludo, Pedro.

# Juan Irigoyen said on Thursday, November 13, 2008 8:23 PM

Pedro, estoy de acuerdo, sin la implicación del cliente es muy difícil sacar un proyecto adelante, está claro que la implicación del cliente tiene un coste para el, pero creo que al final se compensa abaratando el coste del proyecto, puesto la comunicación mejora y se evitan gran parte de los errores, que luego nos obligan a rehacer el desarrollo.

Saludos.

# Julio Trujillo Leon said on Tuesday, November 18, 2008 10:23 AM

Muy bueno Juan

Los usuarios siempre nos solicitan que las busquedas se las puedan hacer ellos solitos (y no les falta razón, cada cual tiene sus propias necesidades)

¿Has pensado en mejorar con una busqueda natural de tipo internet?

Imagínate un textbox en la cabecera donde pudiera el usuario teclear algo como esto:

"+nombre:*construcciones*"

y que el grid devuelva todos los clientes que en su campo "nombre" albergue la palabra "construcciones" el signo más indicaría que deben de contener al menos una ocurrencia de esa palabra en dicho campo, el signo "-" sería para excluir, etc...

# Juan Irigoyen said on Tuesday, November 18, 2008 5:51 PM

En principio no habíamos pensado añadir esa funcionalidad, ya que los filtros permiten resolver la mayoría de las operaciones de búsqueda, aunque vamos a ampliarla para datos relacionados utilizando cubos OLAP.

Gracias y saludos.

# Miguel Salvador said on Tuesday, November 18, 2008 10:06 PM

Hola Juan:

Super interesante la forma como simplificas las opciones de busqueda, una luz en el camino, pero queria preguntarte si esa misma tratativa de busqueda la usan para procesos algo complicados, por ejemplo para la interfaz de emision de un comprobante de pago (en mi caso un punto de venta jeje), en la que dentro de los pasos a realizar para dicha emision tenemos que buscar a un cliente dentro de una ventana de busquedas, elegirlo e incorporarlo en nuestro comprobante. Lo mismo con los articulos a facturar que deberiamos hacer una busqueda de dichos articulo e incorporarlos, luego tambien las formas de pago... para al final recien hacer la grabacion. Como te preguntaba, para algun mantenimiento de una situacion similar... manejan ese mismo esquema? mmm Algun tip?

# Juan Irigoyen said on Tuesday, November 18, 2008 11:53 PM

Miguel, en algunos casos utilizamos otros métodos, por ejemplo en el formulario de Cartera de Clientes, tenemos que introducir el cliente, factura o recibo, en base a cualquiera de los datos se rellena un grid con los datos de esta primera consulta conformado por varios recibos, cuando pulsamos doble click sobre alguno de los recibos que aparecen en un grid, se muestran finalmente todos los datos del recibo. En otros casos introducimos controles dentro de los grid que permiten por ejemplo la búsqueda de un artículo, también desarrollamos funciones especificas para realizar búsquedas concretas. Es decir combinamos varias técnicas, entre ellas la que explico aquí, para realizar búsquedas más efectivas, que dependerán del proceso que queramos desarrollar y los requerimientos del usuario.

En los sistemas TPV se suelen utilizar objetos gráficos, inclusión de teclados virtuales si tienen pantalla táctil y diferentes técnicas para delimitar la búsqueda de elementos.

Espero haberte ayudado.

# Miguel Salvador said on Wednesday, November 19, 2008 8:41 PM

Juan:

Gracias por la atencion, efectivamente me parece que tiene otra tratativa los mantenimientos de procesos mas orientados a la parte comercial, como el dichoso punto de venta que mencione (o la generacion de ordenes de pedido, los ingresos de articulos a almacen) en los cuales hay busquedas a veces personalizadas para dicho proceso y ahi entra a tallar lo que mencionas en cuanto a objetos dentro los grid.

Gracias por el ayuda.

SAludos

# Juan Irigoyen said on Wednesday, November 19, 2008 9:46 PM

Novato, tenía pensado hacer un pequeño ejemplo cuando termine los post sobre la arquitectura, pero te diré que no tiene mucho sentido basarte en la arquitectura de “Maldivas”, ya que cuando se diseño no contábamos con las ventajas que existen hoy, como Entity FrameWork.

Msdn Video es una aplicación excelente, sobre todo para aprender de arquitectura, en esta aplicación puedes mejorar algún aspecto, como la realización de consultas de forma genérica que tratare más adelante, y es un punto de partida excelente para comenzar, si quieres hacer algo similar de nuevo, te recomiendo el estudio de Entity Framework , en el podrás adaptar funcionalidad similar a la que presento aquí.

Gracias y saludos.

# capitanpir said on Wednesday, November 19, 2008 11:19 PM

Viva Maldivas!!! más post !!!

# yazquez said on Thursday, November 20, 2008 2:05 PM

Hola Juan, me parece interesante el enfoque que le estáis dando a la Arquitectura y te quería dar una idea, es en el apartado de la exportación, veo que habéis puesto un botón para cada uno de los formatos soportados (PDF, Word, etc.), a mí personalmente me gusta poner para ese tipo de cosas un botón con el formato por defecto y un desplegable con el resto de opciones disponibles (puede ser un botón desplegable depende de lo que te permita la librería de controles utilizada), esta lista de formatos soportados se nutre de algún archivo de configuración (en el que también podría indicarse cuál de ellos es el por defecto), de manera que si en el futuro añadís un nuevo formato (por ejemplo OpenXML o cualquiera que surga/se os ocurra) basta tocar ese fichero, el sistema llamaría a un componente (el cual debiera cumplir una interfaz o similar… para gustos los patrones) que sería el que “sabe” como exportar a ese formato. De esta manera implementado el componente “exportador” y tocando el fichero de configuración, TODA tu aplicación tendría esa nueva funcionalidad.

Un saludo.

# Juan Irigoyen said on Thursday, November 20, 2008 7:13 PM

Hola yazquez, te agradezco tus comentarios, nosotros utilizamos ese tipo de controles en muchos de nuestros grid, en concreto utilizamos este

www.devexpress.com/.../ImageComboBoxEdit.xml al que hemos aumentado la funcionalidad agregándole checkbox múltiple para permitir la selección de varios elementos al mismo tiempo, lo mostrare en otros post sobre Interfaces.

 

De esta forma al estar basado en una clase, podemos alterarlo agregando o eliminando opciones en un solo lugar. También hemos creado uno basado en un grid en el que cada línea está compuesta por un ImageComboBox con gráficos que permiten realizar esta funcionalidad, con la ventaja que se puede expandir mostrando más opciones.

 

En este caso optamos por no utilizarlos, ya que nos parecía más útil que los usuarios visualizaran todas las opciones, pues es un módulo muy utilizado y ciertos usuarios si no ven la opción ni siquiera se ponen a buscarla. Además la accesibilidad a las opciones es más rápida pues evitas tener que desplegarlo.

Gracias y saludos.

# Juan Irigoyen said on Thursday, November 20, 2008 10:18 PM

Gracias capitanpir, me alegro que te guste.

# Rodrigo Corral said on Monday, November 24, 2008 8:34 AM

Jajjaja... divertida fabula sobre el eterno dilema entre validaciones y seguridad y usabilidad... en mi opinión la seguridad no es opcional, pero toda validación qeu afecte seriamente a la usabilidad tiene que ser replanteada ¿alguien se acuerda de lo que ha pasado con UAC? Los usuarios lo odian (y eso que a mi me encanta UAC)...

¡Un saludo!

# Miguel Sierra said on Monday, November 24, 2008 10:39 AM

Muy bueno Juan!! jajajaja

El sentido común es el menos común de los sentidos ;)

# Juan Carlos González Martín said on Monday, November 24, 2008 4:43 PM

Je Je...muy buen post Juan,...anda que ya te gustaría tener a una moza como la de la foto en lugar de...:P

Saludos

JC's

# Juan Irigoyen said on Monday, November 24, 2008 5:06 PM

Rodrigo, no sé qué es eso del UAC... recuerdo vagamente una opción similar que deshabilite en el vista hace tiempo.... :)

Miguel tienes toda la razón, aunque creo que lo están empezando a vender en los chinos.

Juan Carlos, ya te digo, además tiene una pinta de saber de tecnologías .net....

# Rodrigo Corral said on Wednesday, December 3, 2008 10:50 PM

E x c e l e n t e ! !

No hay más que decir...

# Millan Sanchez said on Thursday, December 4, 2008 1:39 AM

Muy bueno el artículo y directo al punto!!

# Sergio Tarrillo said on Thursday, December 4, 2008 5:01 AM

Algo que no me queda claro es: ¿Cómo maneja Scrum (y en general un metodología Ágil como XP) la documentación?, o sólo es una metodología de implementación, que asume que la documentación ya esta realizada?

Saludos,

# Juan Irigoyen said on Thursday, December 4, 2008 8:22 AM

Sergio, Scrum no dice como debes gestionar la documentación, en nuestro caso utilizamos Team System y la plantilla de conchago para utilizar scrum, en cada tarea adjuntamos los documentos necesarios para realizar proceso, podemos introducir gráficos, hojas de cálculo y todo lo necesario para realizar la tarea. Los bugs suelen llevar adjuntos el error que se produce. No se suele realizar una documentación exhaustiva a no ser que el proceso lo requiera realmente. La verdadera documentación esta en el código. Te recomiendo el articulo de Rodrigo que habla al respecto geeks.ms/.../exprimiendo-scrum-scrum-y-la-documentaci-243-n.aspx.

# Juan Carlos González Martín said on Thursday, December 4, 2008 11:09 AM

Muy buen post Juan!

JC's

# Jorge Serrano said on Thursday, December 4, 2008 5:14 PM

Ma ha gustado mucho como lo has expuesto Juan.

Puntos de vista coincidentes y muy claros sin duda. Se agradece mucho que se cuenten experiencias propias. :-)

# El Bruno said on Thursday, December 4, 2008 10:31 PM

Excelente post ... nada mejor que comentar la experiencias personales para demostrar una idea (en este caso una realidad :D).

Ahora bien, la pregunta de Sergio es clave, porque mucha gente todavía piensa que SCRUM = no Doc; y nada mas alejado de la realidad (y les juro que a esto lo sufro día a día, y mis pequeñas vicorias saben a grandes batallas).

En todo momento la documentacion en un proyecto debe tener una audiencia clara y un objetivo concreto, no es lo mismo trabajar con tus compañeros hombro a hombro, que trabajar con un equipo distribuido geográficamente con más de 9 horas de diferencia horaria. En el primer caso, si el equipo es un equipo homogeneo, seguramente nos encontraremos con escenarios bien definidos y poco más ya que el dominio específico del negocio se puede "sentir dentro del equipo".

En el 2do caso, es necesario ser un poco más prudente y adaptar el proceso a un punto que el resultado permita que las decisiones puedan ser tomadas en entornos no presenciales. Pero siempre teniendo en claro, que la doc debe brindar un valor al proyecto, todo lo que se haga demás, es trabajo perdido.

Saludos y congrats por el post de nuevo

# Juan Irigoyen said on Thursday, December 4, 2008 11:04 PM

Gracias a todos por la valoración.

@Bruno gracias por el apunte, agradezco mucho tus comentarios.

# Sergio Tarrillo said on Friday, December 5, 2008 12:24 AM

Mi pregunta iba más la fase de anáslis, cómo considera Scrum la fase de análisis?

Un proyectillo de 4 o 5 meses. Primero, tengo que saber que quiere el cliente no?, es decir tengo que hacer análisis, que puede tomar un mes, menos o mas. En este tiempo que hago el análisis, Scrum no esta presente o sí? O Scrum asume, que el análisis ya esta realizado? A eso me refería como una metodología de implementación...

Saludos,

# Juan Irigoyen said on Friday, December 5, 2008 1:01 AM

@Sergio. Desde luego Scrum no propone análisis exhaustivos, todo lo contrario, esto es así porque está probado que realizar este tipo de análisis no aporta mucho valor, sobre todo en proyectos de desarrollo de software en los que las necesidades y los requerimientos suelen ser factores muy cambiantes a lo largo de todo el proyecto, normalmente se ponen sobre la mesa todos los requisitos y se le asigna un orden de prioridad, para ello se utilizan técnicas de estimación como el Planning Poker. Scrum comienza desde el inicio, para mi incluso antes que el análisis, a mi juicio la metologia debe cambiar la forma en la que vendemos un proyecto como relato en el post:

http://geeks.ms/blogs/jirigoyen/archive/2008/11/05/191-debemos-cambiar-la-forma-de-vender-software.aspx

No tiene mucho sentido que te hable de análisis de requisitos, ya que Rodrigo y Juan Palacio lo relatan en sus blogs.

Te recomiendo la lectura de los siguientes posts y sus correspondientes enlaces:

geeks.ms/.../exprimiendo-scrum-scrum-y-la-gesti-243-n-de-requisitos.aspx

geeks.ms/.../planning-poker-distribuido.aspx

www.navegapolis.net/.../62

www.navegapolis.net/.../58

Espero haberte ayudado.Saludos.

# Sergio Tarrillo said on Friday, December 5, 2008 7:27 AM

Gracias Juan por las aclaraciones, ya todo esta más claro :)

Saludos,

# Miguel Sierra said on Friday, December 5, 2008 10:04 AM

Que bueno Juan!!!

Comentas que cada día te encuentras a mas empresas que adoptan metodologías por estrategias!!

No tendrá nada que ver este comentario con nuestra última reunión??? ;)

Esto es muy bueno siempre que la estrategia es mejorar y ofrecer un mejor servicio de calidad...

El artículo me ha parecido sensacional!!! ;)

# Juan Irigoyen said on Friday, December 5, 2008 5:01 PM

Miguel, desde luego entiendo que vosotros buscáis una mejora a la hora de realizar vuestro trabajo, la metodología debe ser el medio, no el fin para conseguir vuestros objetivos, no es debido a última reunión con vosotros, la adopción de metologías tipo CMMI están siendo adoptadas por numerosas empresas debido al requerimiento de organismos oficiales y otros factores, no es mi intención desencadenar una guerra sobre cuál es la mejor metología a utilizar, entiendo que cada uno utiliza la que le parece más adecuada en base a sus necesidades y requerimientos y que desde luego es algo que conocéis mucho mejor que yo, ya que nunca he utilizado CMMI, tan solo he leído sobre ella, en mi opinión, CMMI es todo lo contrario a lo que propone Scrum, se centra en los procesos y no en las personas y genera una burocracia excesiva, si bien pueden existir puntos en común los puntos clave me parecen totalmente alejados. En cualquier caso, respeto vuestra elección y creo que estáis sobradamente capacitados para sacar valor a cualquier metología.

Aprovecho para recordarte que esperamos tu post sobre CMMI.

Agradezco mucho tus comentarios

Saludos.

# David Daniel Arroyo Zari "Ddaz" said on Saturday, December 6, 2008 2:52 AM

por cierto.... han escuchado de " Moprosofot " ? ??  :)

Salu2

Ddaz

# Juan Irigoyen said on Saturday, December 6, 2008 4:06 AM

buff, Moprosoft se basa en los modelos de procesos ISO 9001:2000, prefiero no opinar al respecto...

# Miguel LLopis said on Tuesday, December 9, 2008 8:30 AM

Muy buen dicho, Juan. Totalmente de acuerdo contigo.

No hay mejor equipo de trabajo que aquél en que el rendimiento colectivo es superior a la suma de los rendimientos individuales de todos sus miembros. Ese rendimiento extra es el que debe derivarse de la motivación y coordinación que un jefe de equipo sea capaz de transmitir.

Saludos,

Miguel

# null said on Tuesday, December 9, 2008 9:20 AM

Hola.

El artículo es pa'descojonarse ... muy bueno.

Considera que hay jefes de equipo que son unos inútiles totales (vamos "no saben hacer la o con un canuto"), además muy celosos de su puesto ("huelen a cuerno quemado por todos los lados") y por último aprovechan la máxima de "lo bueno de trabajar en equipo es echar la culpa a los demás".

Estos son capaces de estropear un buenísimo equipo en cuestión de un par de meses, comprobado en mis propias carnes.

Sobre el tratar la oveja negra, lo mejor es aislarla donde no infecte/joda a los demás.

Saludos.

# Eduardo Obregón said on Tuesday, December 9, 2008 1:18 PM

A pesar de que el post me gusta, no estoy de acuerdo con el contenido, es como me gusta llamarlo, "figura de marmol" bonita de aspecto pero muy fria en el interior.

Un dia le pregunté a un jefe que es lo más importante en esta empresa y él con dos copas de más me dijo "que los trabajadores creais en ella", y esa frase de las 4 de la mañana tenía toda la razón el trabajo debe ser como una religión, el trabajador debe creer en lo que hace y en quien le dirije pensando que juntos van a un destino mejor, un jefe se puede ganar el respeto de dos formas, mediante el respeto profesional o mediante el respeto personal, yo confio ciegamente en el modelo de los HOPLITAS, por favor reviselo el q no lo conozca.

# Juan Irigoyen said on Tuesday, December 9, 2008 7:37 PM

@Miguel, gracias por tus comentarios.

@null, en todos los trabajos podemos encontrarnos con jefes inútiles y compañeros inadaptados, intentar ir un poco más allá mejorando la relación y el conocimiento de las personas nos puede permitir al menos mejorar la situación. Siempre estaremos a tiempo de deshacernos de la oveja negra, el problema es que quizás no es tan negra como parece…

Agradezco tus comentarios.

@Eduardo, he leído un poco sobre los Hoplitas, pero no he encontrado ninguna referencia a su modelo de trabajo, no sé si te refieres a que los hoplitas eran soldados solidarios en los que la obediencia se basaba esencialmente en el consenso y la disciplina, si es así, estoy de acuerdo, aunque llegar a esto pasa necesariamente por entender a las personas con las que trabajas.

Creo que, para confiar en la empresa primero debes confiar en tu equipo de trabajo y en las personas que la conforman, una cosa no puede darse sin la otra, la creación de un entorno adecuado y de un equipo disciplinado pasa necesariamente por valorar, motivar y entender a las personas. La valoración de un Jefe, ya sea a través del respeto profesional, personal o ambos, no es lo único necesario para crear un grupo de trabajo óptimo, en un equipo de trabajo todos deben ser valorados y respetados.

Saludos.

# Quique said on Tuesday, December 9, 2008 7:37 PM

Estoy deacuerdo con Edu al 100%, aunque me parece bien la comparación creo que no estoy deacuerdo con la misma. El resultado de un jugador de poker es ganar el de un equipo de desarrollo es que gane el equipo, osea, el proyecto; aunque quizas pensandolo un poco mejor sea ese el fondo de la cuestion...

Juan, por mucho que digas un jugador de poker con malas cartas hace 3 cosas, arriesgarse (puede perder mucho o ganar mucho ahí entra los ... de cada uno), descartarse (sin temblarle la mano aunque le pese aunque le cueste mas o menos se quita las cartas que el considera malas su vision es la de ganar) o retirarse y no jugar esa mano (una retirada a tiempo es una victoria).

# Juan Irigoyen said on Tuesday, December 9, 2008 7:53 PM

@Quique, quizás la comparación puede dar lugar a confusiones, lo que trato de decir es que, al contrario que un jugador de pocker los responsables de un grupo de trabajo si pueden cambiar las cartas, a través del entendimiento de las personas, la motivación y valor del equipo.

# oskarpaz said on Sunday, December 28, 2008 8:51 PM

Polivalencia tecnológica y cierta especialización en "negocio", en mi opinión se puede resumir en la frase "soluciones fáciles a problemas difíciles".

La Tecnología debe estar siempre al servicio del "negocio" (cliente). Por lo que es necesario:

* entender, muy pero que muy bien, al cliente (empatizar con él)-> especialización en "negocio"

* buscar la solución más sencilla (NO especialización) y que no tiene porqué ser la que está de "moda"

# Miguel LLopis said on Sunday, December 28, 2008 9:12 PM

Buen post. En mi opinión, el debate podría llevarse también a la comparación "sabiduría" vs "inteligencia"; entendiendo por sabiduría el disponer de una amplia base de conocimiento en una, dos, o más tecnologías; y por inteligencia la capacidad para enfrentarse a problemas nuevos.

Generalmente, nadie ha podido llegar a sabio sin ser inteligente. La cuestión radica en la capacidad para renovarse (más en nuestra profesión). Por otra parte, mucha gente inteligente carece de experiencia, con lo cual es muy probable que (además) carezca de una amplia base de conocimiento, pero a la vez dada su capacidad para asimilar, dispondrá de una curva de aprendizaje "rápida" a la hora de enfrentarse a nuevos problemas, cuyas soluciones incorporará automáticamente a su base de conocimiento para el futuro.

Como casi siempre en la vida, la virtud está en el equilibrio entre ambos extremos, tanto a nivel individual como a nivel colectivo de un equipo.

Saludos,

Miguel

# Rodrigo Corral said on Sunday, December 28, 2008 10:31 PM

Interesante la reflexión que planteas en el post... 

Yo creo que los perfiles más deseables en todo equipo son los 'especialistas generalizadores' (generalizing specialists) tal y como los describe Scott Ambler: www.agilemodeling.com/.../generalizingSpecialists.htm

Escribí sobre este tema hace bastante: geeks.ms/.../Taylor-se-equivoco_2E002E002E00_.aspx

Yo no creo que sirva un especialista puro ni en casos como el de 'los servidores se colapsan en puntas de acceso'. Si en una situación como esa, solo sabes de la parte de base de datos por poner un ejemplo, puede que solo puedas proponer una solución parcial o que ni siquiera seas capaz de encontrar una solución.

Un guru 'de solo Sql Server', por ejemplo, podría encontrar una solución mirando solo a Sql Server. Muy probablemente lograse poner la aplicación en margenes aceptables de rendimiento, pero quizás forzando los límites de Sql Server y puede que esto no sea siempre la mejor opción. Quizás sería mejor una solución basada en una mejor politica de cacheo en Asp.Net o usar una cache tipo Velocity o tuner el IIS y no solo la base de datos... Si eres un puro especilista, quizás se te escapen muchas opciones... y quizás caigas en que cuando solo se tiene un martillo, todo parecen clavos.

Mi experiencia es que si el Debbuging & Optimizacion Team de Plain Concepts funciona, no es por que tengamos gente que es especilista solo en un tema concreto, que lo son. Sino por que además todos ellos tienen amplísimos conocimientos en todo el rango de las tecnologías de Microsoft. Pueden ser especialistas en A o en B, pero son capaces de intuir que el problema puede ser la tecnología C o que la solución pasa por D, y que en ese caso lo mejor es hablar con otro miembro del DOT y plantear una solución fuera del ámbito de su especialización. Los problemas en la aplicaciones modernas a menudo son de arquitectura y de malas prácticas de desarrollo y tocan a más de una tecnología o incluso tienen su raiz en como ciertas tecnologías trabajan juntas.

¡Equipos multidisplinares y 'especialistas generalizadores' son la clave! o al menos esa es mi opinión.

¡Un saludo titán!

# PabloNetrix said on Monday, December 29, 2008 12:42 AM

"cuando solo se tiene un martillo, todo parecen clavos".

Esta va para mis Favorite Quotes! ;)

# José Fortes said on Monday, December 29, 2008 12:56 AM

Interesante post Juan. Estoy de acuerdo con lo que plantea Rodrigo. Creo que el perfil más valioso es aquel que "sabe o conoce de todo y además es experto en algunas cosas". Leyendo el artículo de Scott Ambler que enlaza Rodrigo, esta frase viene a expresar precisamente eso:

"A generalizing specialist is more than just a generalist.  A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few"

También creo que perfiles así no abundan demasiado y precisamente eso los hace aún más valiosos.

# Juan Irigoyen said on Monday, December 29, 2008 9:48 AM

@Oskarpaz, desde luego la tecnología debe estar siempre al servicio del “negocio” y la clave está en “empatizar con él cliente”, pero, buscar la solución más sencilla, normalmente pasa por conocer y a veces utilizar las últimas tecnologías, que muchas veces nos pueden ayudar mucho en el trabajo, por ejemplo la adopción de tecnologías como Entity FrameWork nos pueden simplicar mucho el trabajo con datos.

Saludos.

@Miguel, estoy de acuerdo con lo que dices, aunque difiero en una cosa, para mí la inteligencia es la capacidad innata que tienen algunas personas para resolver problemas, pero es algo con lo que se nace y difícilmente se puede mejorar, creo que se puede llegar a ser sabio sin necesidad de ser inteligente y estoy completamente de acuerdo en que en la virtud esta en el equilibrio entre ambos extremos.

Gracias por tus comentarios.

@Rodrigo, como siempre, eres una “referencia”, aunque estoy de acuerdo, creo al final tal y como expones en tu post y transmite Miguel en la mezcla de ambas esta la virtud, por eso lo de “especialista generalizador”, aunque tengo mis dudas, es decir, está llegando el momento, en que convertirte en un especialista generalizador, va a ser algo cada vez más difícil, ya que el número de tecnologías que aparecen va a desbordarnos, de hecho es algo que creo, está pasando a muchos de los que trabajamos en IT. En mi opinión a partir de ahora, quizás, nos veamos obligados a tener personas capacitadas en determinadas aéreas y compartir el conocimiento con otras para complementarlas entre sí, creo que la clave, en poco tiempo, será la distribución del conocimiento entre las personas y la mejora del trabajo en equipo. Tal y como expones vosotros tenéis el Debbuging & Optimization Team, con el tiempo, quizás, estarán más especializados al no poder asumir tantas tecnologías y complementaran a los demás equipos de trabajo como hacen ahora, independientemente de que tengan conocimientos en otras muchas aéreas, cada vez estos serán más limitados y adaptados de acuerdo a sus necesidades.

Por otra parte estoy de acuerdo en que para dar una solución a un problema no bastara con que la persona sea un experto en Sql Server, pero quizás si logramos disponer de un equipo con  expertos en Sql Server, Asp.Net, IIS, Depuración y Optimización y trabajamos en equipo, podamos llegar a una solución más óptima.

Saludos y gracias por tus comentarios.

@PabloNetrix, yo tengo un martillo, pero hay tantos clavos…. Salu2.

@Jose Fortes, te contesto lo mismo que a Rodrigo. Saludos y gracias por tus comentarios.

# lboisset said on Tuesday, December 30, 2008 6:12 PM

Ya lo habéis dicho todos pero quiero refrendarlo: en el equilibrio entre ambas cosas está la solución. Una empresa y un profesional deben encontrar la forma de especializarse lo suficiente como para ser atractivos/competitivos en algún aspecto que atraiga el trabajo y los clientes y a la vez ser suficientemente generalistas como para poder adaptarse a los cambios continuos, como para poder "ver" otras vías de solución u oportunidades de negocio.

Si sólo te especializas puedes tener un buen nicho de mercado, y este puede durar incluso mucho tiempo, pero siempre tendrás el riesgo de que algún cambio en el mercado te deje fuera de juego de un día para otro.

Si sólo eres generalista, en el fondo no tendrás suficiente capacidad de resolución de problemas, no aportaras algo "extra" a tu oferta y por tanto será "facilmente" reemplazable.

Lo dicho: las dos cosas en su justa medida.

Pero claro, es mucho más fácil decirlo que hacerlo ;)

# Motivaci??n, Engagement, Innovar y Disfrutar « lboisset’s Ruminations said on Wednesday, December 31, 2008 1:00 AM

PingBack desde  Motivaci??n, Engagement, Innovar y Disfrutar &laquo; lboisset&#8217;s Ruminations

# Juan Irigoyen said on Wednesday, December 31, 2008 2:53 AM

@Iboisset. Me alegra leer un post como este, es cierto, nos olvidamos de esa chispa, que sola era capaz de realizar proyectos y solucionar problemas casi por arte de magia, lo cierto es que la complejidad de las personas, los procesos, las empresas y sobre todo el  entorno tan sumamente competitivo en el que nos movemos, han hecho que muchas veces olvidemos la importancia de disfrutar de nuestro trabajo.

Te felicito por tu post. Gracias.

# Unai said on Wednesday, March 11, 2009 1:38 AM

Buen post Juan!

Unai

# Juan Irigoyen said on Wednesday, March 11, 2009 6:21 PM

Gracias Unai. Saludos.

# Raul338 said on Monday, March 16, 2009 9:37 PM

Esto es una verdadera expresion regular!!

^(Index Value:)(\d+,?\d+\.?\d+)(Trade Time:)(\w+\s\d+|\d+:\d+\w+\s\w+)(Change:)(\d+\.?\d+\s+\(\d+\.?\d+%\))(Prev Close:)(\d+,?\d+.?\d+)(Open:)(\d+,?\d+.?\d+|N/A)(Day's Range:)(\d+,?\d+.?\d+\s-\s\d+,?\d+.?\d+|N/A\s-\sN/A)(52wk Range:)(\d+,?\d+.?\d+\s\-\s\d+,?\d+.?\d+)$

xD tuve que inventarla para obtener informacion de una pagina web XHTML, para la cual el XMLDocument no me funciono porque daba error de XML no valido o_Ó y resultaron ser que los meta-tags no estaban cerrados........

jejeje, viendo el titulo y las primeras oraciones, me hicieron recordar como la pase para crear esa expresion regular, que obtenia de la informacion financiera de yahoo. Igual gracias a este post descubri que se puede usar expresiones para las busquedas (lo cual nunca me habia fijado xD)

gracias. Y Saludos!!!

# Juan Carlos González Martín said on Thursday, April 2, 2009 12:26 AM

...excelente reflexión Juan, pero me temo que te vas a llevar una decepción con VS 2010, yo me la estoy llevando...espero que para la RTM solucionen lo que ahora mismo tengo entre manos....tiempo desde luego tienen, pero hay demasiadas cosas nuevas.

Un saludo

JC's

# Fidel Bermejo Vega said on Thursday, April 2, 2009 8:23 AM

En esta larga y sentida reflexión , como dirian en lun programa de humor, has dado en el clavo , estoy totalmente de acuerdo contigo , al final microsoft apuesta por la politica de vender y vender.....no es lógico que cada vez que aparece una nueva versión casi te obligue a cambiar la máquina de trabajo , no es normal.........pero es lo que hay

# Rodrigo Corral said on Thursday, April 2, 2009 8:37 AM

Comparto lo que dices de VS, no tiene nombre en lo que Microsoft ha convertido su entorno de desarollo. Yo también me paso más horas mirando barras de progreso y relojitos de haciendo algo útil.

¿Cómo puede ser que un entorno de desarrollo empresarial no pueda con soluciones con 40 o 50 proyectos? ¿Cómo puede ser que tarde siglos en iniciar la ejecución de las pruebas unitarias?

Es increible. Desde VS 6.0 el rendimiento del entorno de desarrollo está cayendo espectacularmente.

¡Un saludo!

# Pedro Álvarez said on Thursday, April 2, 2009 10:11 AM

Tenéis toda la razón. El diseñador de WPF es una autentica ponzoña, es imposible hacer carrera de él; intentar abrir un archivo de recursos es un cara o cruz de si abrirá el fichero o no y cuando de la solución cuelgan un cierto número de proyectos, compilar se convierte en un ejercicio de paciencia.  Yo creo que voy a empezar a estudiar otra carrera entre compilación y compilación :).

Un saludo,

Pedro.

# preguntoncojonero said on Thursday, April 2, 2009 1:18 PM

Apoyo la moción, cada vez más lento y más tragarecursos...de mal en peor...

# José Ignacio Merino said on Thursday, April 2, 2009 2:44 PM

Amén

# Gonzalo Perez said on Thursday, April 2, 2009 4:22 PM

Amén,

a quien le ha sucedido que el diseñador de asp.net pierde el código declarativo? si alcansas a copiar y pegar en otro form, te salvaste.

Jajaja y SourceSafe, se han llevado sorpresas cuando descarga una versión antigua??

# Miguel Sierra said on Thursday, April 2, 2009 5:06 PM

Menuda pataleta!!!

Amén, Estoy completemente de acuerdo!!

Ponte a descargar Karma del emule, a mi me funciona...a veces!!

# Alejandro said on Friday, April 3, 2009 9:18 PM

... me pregunto.

Acaso el VS 6 permitia integrar esa enorme masa de proyectos que exponen aqui ? Teniendo en cuenta que pueden ser multiplataforma y que varian los tipos de proyectos.

Lo mismo web, que DB, que pensando utilizar MONO.

El VS ha evolucionado para poder facilitar esa integracion, la asimilacion de proyectos de VS anteriores.

Con esto aumenta el peso y tiempo de disenho y analisis y quita tiempo de desarrollo.

Y esto conlleva a un monstruo, es inevitable, a una gran plataforma de desarrollo que cada vez es mas completa y le saca diferencia a la que le siga en cuanto a completitud.

Esto lo saben muchos de Uds mas que yo por los proyectos que realizan.

Pudieran acaso hacerse los 130 proyectos de Rodrigo en el VS 6 ? Tomense tu tiempo para pensar.

Ademas que muchos proyectos actuales son posibles simplemente porque el VS ha dado la posibilidad de desarrollarlos (ojo, no es el unico pero estamos hablando de VS no de otro).

Me refiero a proyectos con plataforma virtual como bien han explicado en algunos bloggs aqui.

Y cada dia se ofrecen mas alternativas para aumentar prestaciones.

Cada dia que pasa Microsoft ofrece mejores soluciones que pueden integrarse y componer un buen esquema de informacion para el Business Inteligence.

Que es hacia donde vamos.

La Informacion hacia los es una de las banderas actuales de Microsoft y con lo que ya esta ofreciendo realmente se pueden hacer muuuuuchas cosas que antes llevaba bastante tiempo desarrollar.

Ahora muchas veces es a puro golpe de click.

Mientras mas tipos de proyectos e integracion de ellos pueda ofrecer el VS mas grande sera ... pero como ahorra tiempo.

Y pensar que eso pasara como simplemente pasaba un VS 6 por un Pentium II es dificil.

Sobre todo porque el hardware tambien ha ido evolucionando, y va mas rapido que el software.

Por lo que tiene un costo hacer la transicion, de dinero para los duenhos del proyecto como para Microsoft desarrollar un nuevo sistema.

Lo otro cae en el terreno de la magia y esa se la dejo a los espectaculos circenses.

Todo esto es con el debido respeto a personas que tienen mas experiencia con .NET que yo.

Pero ... volverian al pasado a programar en VS 6 todas las soluciones ?

# Juan Irigoyen said on Saturday, April 4, 2009 2:15 AM

@Juan Carlos, la verdad es que haber apostado por cambiar el entorno a WPF, ya es de asustar, espero que se hagan eco de los problemas de rendimiento. A veces echo de menos hasta programar en Cobol, que pena…

@Alejandro, los problemas de rendimiento, no solo se deben a la utilización de múltiples proyectos, si pruebas a tener un solo proyecto, ya sea Windows, Web, Wpf, y tienes controles y formularios se observa que el rendimiento al abrir , cerrar o realizar cualquier cambio es desastroso, lógicamente los problemas de rendimientos se aprecian mas, cuanto más grande es el proyecto, en cualquier caso y después de trabajar en diferentes entornos "en los últimos 5 dedicado exclusivamente a VS" afirmo que el rendimiento y consecuentemente la productividad con VS es pésima y que versión a versión se hace cada vez más lento, si siguen así va a llegar un punto en el que sea totalmente improductivo. La integración de diferentes proyectos no es una justificación para tener un entorno de trabajo tan lento, esto nos hace ser menos competitivos y sube el coste de desarrollo en las empresas de forma exponencial.

Saludos y gracias por tus comentarios.

# Alex said on Saturday, April 4, 2009 2:32 AM

@Juan Irigoyen:

Como explicaba en lo que escribi realmente estoy muy lejos de estar por ahora involucrado en soluciones como las que dices. Lo que si he preguntado a amigos que estan en esa posicion y no estan de acuerdo. Les gusta mucho el VS como esta ahora, con lo que ofrece y con las cosas que se estan preparando hacia un futuro.

Como te decia, a lo mejor la solucion es que emigres a una plataforma mas sencilla y quiza encuentres lo que buscas. Realmente lo dudo pero la prueba no estaria de mas.

Expongo todo esto sin animo de polemica, respeto tu opinion todo el tiempo, pero sin duda es un tema interesante y que mereceria una prueba en la practica.

Que crees ?

# Juan Irigoyen said on Saturday, April 4, 2009 3:03 AM

Alex, que Visual Studio es una plataforma de lo más completa no lo discute nadie, pero que así mismo es una plataforma lenta es algo también indiscutible para aquellos que trabajamos a diario con esta herramienta, la elección de una plataforma de desarrollo viene dada por diferentes aspectos, en los que el rendimiento es uno más de ellos, para mí una carencia que cada vez se convierte en algo mas importante y estoy seguro es algo que se puede mejorar y mucho, aunque creo que no le dan la suficiente importancia, tal y como han hecho con el sistema operativo Windows Vista y otros productos de Microsoft, de hecho hay una famosa frase de Bill Gates en la que les dice a sus desarrolladores "no os preocupeis de los requisitos de hardware, estos se adaptaran a las necesidades del software".

No puedo migrar a otra plataforma ya que la alternativa es prácticamente inexistente si mis desarrollos van enfocados hacia plataformas Windows y tengo desarrollos en WinForms, Web, Dispositivos móviles y otros, el problema es que no hay una plataforma tan completa como Visual Studio, pero no la exime de ser una plataforma con grandes deficiencias en cuanto a rendimiento se refiere. Pero como digo al final del post, entiendo que no todo el mundo este deacuerdo, es lógico, tan solo es mi opinión personal derivada de mi trabajo con Visual Studio, quizas en otros desarrollos donde los requisitos sean diferentes el rendimiento no sea tan importante, todo dependera de la complejidad y el tamaño del proyecto.

# preguntoncojonero said on Tuesday, April 7, 2009 1:51 PM

Por favor, s igan con la serie, se lo suplico y pongan ejemplos, por favor ...gracias

# Arturo said on Saturday, April 11, 2009 12:15 AM

Hola Juan, espero te sirva lo siguiente:

(Nombre collate Latin1_General_CI_AI LIKE '%" + Sanitizar(criterio) + "%')

donde "collate Latin1_General_CI_AI" le quita tildes y caracteres raros al campo guardado en la BD,  criterio es lo buscado, y Sanatizar es quitarle tildes y acentos que aveces dificultan las busquedas

   protected string Sanitizar(string cadena) // quitar tildes y caracteres extraños

   {

       cadena = Regex.Replace(cadena, @"\s+", "");

       string stFormD = cadena.Normalize(NormalizationForm.FormD);

       StringBuilder sb = new StringBuilder();

       for (int ich = 0; ich < stFormD.Length; ich++)

       {

           UnicodeCategory uc = CharUnicodeInfo.GetUnicodeCategory(stFormD[ich]);

           if (uc != UnicodeCategory.NonSpacingMark)

           {

               sb.Append(stFormD[ich]);

           }

       }

       return (sb.ToString());

   }

# Juan Irigoyen said on Saturday, April 11, 2009 2:50 PM

@Arturo, te agradezco muchos tus comentarios, si bien creo no van a hacer falta en nuestra aplicación, ya que el diccionario por defecto de la base de datos utilizados esta basada en el modelo CI_AI, no toma en cuenta los acentos ni las mayusculas y minúsculas, con lo que si realizas una busqueda de una cadena por ejemplo "%Camión%", el sistema asume que estas buscando "%camion%', en el caso de los caracteres raros, evitamos este error desde los propios controles, por ejemplo en un control de tipo moenda con un valor "1.000,00 €", el control siempre devolvera 1000 como valor, con lo que no es necesario realizar esta validación.

En el caso de no realizar esta validación seria muy util utilizar la función que espones.

Muchas gracias por tus comentarios.

Saludos.

# Julio Trujillo Leon said on Tuesday, April 14, 2009 10:17 AM

JUAN, QUE POST MAS COJONU... Desde los tiempos de Visual Studio 6.0 estaba convencido que la solución para optimizar velocidades en el mundo Microsoft y con VS pasaba por el uso de Discos RAM, y tras más de una decada y leer tu post veo que no me equivocaba. Has hecho un estudio sensacional, mi más sincera enhorabuena!!!!!

# Juan Irigoyen said on Tuesday, April 14, 2009 4:48 PM

Julio, muchas gracias por tus comentarios, la verdad es que paso mucho tiempo esperando..., y claro con tanto tiempo libre tienes que probar de todo, esperemos que en las próximas versiones mejore el rendimiento.

Saludos.

# El Bruno said on Tuesday, April 14, 2009 6:54 PM

Hey Juan, me ha gustado el post y me he tentado y ya he pedido un par de SSDs para probar. Y hablando de probar, veo que has probado cambiar el directorio temporal del Windows %TMP% para que utilice uno de tus discos Flashs o disco chulo ? y la base está por ahi, en la gestión de los temporales de Windows ?

Saludos

# Juan Irigoyen said on Tuesday, April 14, 2009 10:54 PM

@Bruno, pues si, redirigir todos los temporales, no solo los de windows, es una de las opciones y como también he hecho cambios al eliminar el uso de memoria virtual, indexado de ficheros, desfragmentación del disco, cache de archivos en firefox y explorer, no sé hasta qué punto cada opción incide cada una, lo cierto es que  tanto el Samsung de 64 Gygas como la tarjeta de memoria aumentan mucho el rendimiento, y si encima lo usas en un portátil no te acordaras de recargar la batería. Espero que me cuentes tu experiencia con los discos SSD que has comprado.

Saludos y gracias por tus comentarios.

# Rodrigo Corral said on Thursday, May 21, 2009 1:52 PM

La apuesta es clara: el código se escribe una vez y se lee cientos.

No hay duda: el código de calidad es una gran inversión.

Creo que en tu post mencionas muchos aspectos relacionados, de un modo u utro con la calidad del código. Pero en mi opinión hay dos aspectos que sobresalen sobre el resto a la hora de evaluar la calidad del código: su tamaño y su legibilidad.

A más cantidad de código, más probabilidad de indroducir errores. Esta estudiado que con independencia del lenguaje, el número de defectos es directamente proporcional a la cantidad de código.

Sobre la legibilidad, en mi opinión es el factor más importante. Lo más importante del código es que se legible por otros. Insisto, se lee más veces de las que se escribe.

¡Un saludo!

# Juan Irigoyen said on Thursday, May 21, 2009 3:34 PM

Asi es Rodrigo, estamos completamente de acuerdo, muchas gracias por tus comentarios.

Saludos.

# Carlos Segura said on Friday, May 22, 2009 12:38 AM

Ya lo dijo Fowler,

Es fácil escribir código que entiendan las máquinas y difícil escribir código que entiendan los humanos.

Efectivamente es una de las cosas más importantes, el código tiene que revelar la intención del programador.

Un libro fantástico dedicado a esto es “Code Clean” de Robert C. Martin

www.ideseg.com/HeLeidoCodeCleanDeRobertCMartin.aspx

Saludos,

Carlos.

# preguntoncojonero said on Monday, May 25, 2009 9:36 AM

Algun ejemplo de Control tree avanzado como se muestra ?

salu2

# Juan Irigoyen said on Monday, May 25, 2009 1:37 PM

El tree que aparece en la foto tiene mas de 1200 lineas de código, ya que incorpora drag & drop y otras funcionalidades que aparecen en el menú de la derecha, poner todo el código en el blog no tiene mucho sentido, ya que esta totalmente adaptado a la funcionalidad que hemos implementado, utiliza procedimientos almacenados y otras funciones que crean dependencia con el entorno de datos, si quieres avanzar en estas funciones puedes acceder a ejemplos sencillos con poco código, que te permitiran crear nuevos nodos, borrarlos, realizar drag & drop e implementar otras funciones, en http://www.codeproject.com/

Espero que te sirva. Saludos.

# Arturo said on Thursday, June 11, 2009 2:13 AM

Yo siempre trabajo así: 50% de adelanto y 50% a la entrega del trabajo. Estoy pensando replantearlo, porque muchas veces el trabajo puede alargarse por culpa de ellos. 50% a la firma del contrato y 50% en una fecha determinada.

saludos

# Miguel Sierra said on Thursday, June 11, 2009 5:41 AM

Jajajaja, me acabas de alegrar el día!! que grande eres!!

Es muy buena la frase de: "Yo me hice a mi mismo", desafía a las layes de la naturaleza ;)

Miedo me da encontrarme con ese empresario, que supongo será de una tribu de Cantabria...

Un saludo!!

# Sergio Tarrillo said on Thursday, June 11, 2009 6:29 AM

Jajaja, me quedo con esta frase: "- En mis tiempos cazaba los leones a mordiscos… "

Muy buen artículo...

Saludos,

# Alejandro said on Thursday, June 11, 2009 6:39 AM

Jajaja.

Vaya que te extremaste en originalidad.

Tienes muy buen estilo, puedes dedicarte a la literatura.

Me gusto mucho tu articulo.

Congratulations ;-) !!!

# Eduardo Obregón Gutierrez said on Thursday, June 11, 2009 7:22 AM

Yo que estuve un tiempo metido en una tribu de esta especie, te comentaré que en una reunión con el jefe de la tribu me dejó una perla buenísima:

"Dejate de organizar las ordenes de fabricación, lo que hace falta es que estos h.ps trabajen hasta las 11 que salga el camión" pensé en tatuarmela.

# Jose Antonio Gallego said on Thursday, June 11, 2009 9:25 AM

Buenisimo, me estaría partiendo si no fuese jo****mente tan real.

Muy bueno!!!

# El Bruno said on Thursday, June 11, 2009 2:43 PM

jejeje, simplemente real (triste, pero real) ;D

# Juan Irigoyen said on Thursday, June 11, 2009 3:00 PM

Gracias por vuestros comentarios, así es, el artículo es completamente real, tan solo he cambiado el nombre de Tarzán y Chita por respeto, en realidad era "Mongli acompañado de Baloo", pero a estas alturas no creo que les importe. :)  Saludos.

# Gonzalo Perez said on Thursday, June 11, 2009 3:25 PM

JAJJAJAJAJ super buenooooo, que me ha pasado que te llaman y dicen,tengo un proyecto, muy bueno que te va a servir.... y ellos solo tienen una idea y uno se lo tiene que programar todo gratis, ja! al infierno!

# José Miguel Torres said on Thursday, June 11, 2009 4:42 PM

Menudo estudio antropológico, sencillamente fantástico. Sólo te falta añadir el punto que casi siempre llevan traje y corbata, van "engominaos" y calzan zapatos de 20€ (descuidados).

Muy bueno ;-)))

# Juan Irigoyen said on Thursday, June 11, 2009 8:43 PM

@Jose, tienes toda la razón, la verdad es que han evolucionado mucho, normal, cuatro millones de años, Gran Hermano, Belen Esteban, los Banqueros de este pais y la Justicia han contribuido mucho a este hecho... :)

# Juan Carlos Febrer said on Friday, June 12, 2009 9:20 AM

Genial. Me he visto totalmente identificado, en mis 5 años de autónomo, me he topado con varios de estos especimenes ... con esta guia no me volvera a pasar. Saludos y enhorabuena por tus artículos.

# Julio Trujillo Leon said on Friday, June 12, 2009 9:52 AM

A los informáticos nunca se nos quiere pagar lo que merecemos, se nos compara a meros administratrivos (sin querer ofender). Al hilo de las primeas intervenciones os doy un consejo, al total final del importe de un proyecto agregar de un 10 a un 20% para luego volverlo a bajar en negocionciones con los clientes; es algo muy habitual en el sector de la automoción y si buscáis entre los post de "Microsoft Empresas" podreis leer que según estudios en una relación comercial el cliente tiene que tener un efecto tangible de que ha negociado y te ha sacado las higadillas, cosa que le hará sentir como un superhombre en la cima junto a los grandes negociadores del mundo mundial.

Otro consejo que os doy es que cuando detecteis un cliente "no rentable" os alejéis de el para siempre. Llevo muchos años viendo a empresarios que tratan con clientes que acaparan los recursos de su empresa brutalmente y encima ni pagan los servicios ni agradecen la atencion lo más mínimo sino al contrario, llegan a pensar "eres un mierda porque te has dejado nigunear" es lo que piensan (dicen que "lo regalao ni agradecío ni pagao") . Este tipo de clientela conviene que se marche a la competencia, allí los entretendrá y nos hara un gran favor "parasitando a sus recursos".

# Eduardo Obregón Gutierrez said on Friday, June 12, 2009 10:14 AM

Hola Julio, estoy deacuerdo con que no se quiere pagar lo que merecemos y que debemos alejarnos de clientes "no rentables" pero no estoy nada deacuerdo con cambiar precios en subida y bajada, vender debe ser asesorar la mejor solución para un problema, si la tenemos y se ajusta al precio pues bien sino es mejor asesorarle que coja una soución que se adapte mejor a su economía, la base de cualquier relación es la confianza y sobre todo habiendo dinero por medio. Debemos hacer comprender que si un producto vale un dinero es por algo(calidad,servicio, tecnología)

# Juan Irigoyen said on Sunday, June 14, 2009 11:23 PM

@Juan Carlos, gracias por tus comentarios.

@Julio, estoy deacuerdo con Eduardo, la confianza debe ser la base de toda relación comercial. en mi opinión no se trata de ganar mas o menos, se trata de ganar lo justo y realizar aquello para lo que se nos ha contratado de la mejor forma que podamos.

Saludos y gracias por tus comentarios.

# Álvaro Pardo said on Tuesday, June 16, 2009 5:30 PM

Esto tendría que haberlo leido hace tiempo... Aunque dicen que el mejor maestro sobre el fuego es una mano quemada jejeje

# Jorge Gamba said on Wednesday, June 17, 2009 6:08 AM

Así como WPF será el final de WindowsForms, Silverlight (v3...) será el final de WPF, más ahora que tiene la feature "out of browser", por eso considero mejor para quien quiere actualizarse incluso en aplicaciones de escritorio, arrancar de una vez con Silverlight.

# Julio Trujillo Leon said on Wednesday, June 17, 2009 9:18 AM

Quiero hacerte dos preguntas, la del millon y la del millon y medio. Pensamos adoptar WPF, de hecho estoy preparando el 70-502 y tenemos nuestros productos estandares en VB6, ahora estamos dando el salto a .NET en plan bestia y nos rondan dos cosas la cabeza ¿Con WPF podremos tener la misma aplicación para escritorio y para WEB? ¿Que requisitos puede tener esta am,biciosa idea?

¿Tu sabrias darnosa tu opinión al respecto?

Un saludo y enhorabuena por tu aclarativo post

# Juan Carlos González Martín said on Wednesday, June 17, 2009 9:36 AM

Muy buen post Juan...yo no sé mucho de WPF, pero me voy  a atrever con la preguna de Julio. Mi opinión respecto a si con WPF podemos tener una aplicación para escritorio y para la WEB...la respuesta es que depende. Si sólo quieres tener una única interfaz en WPF, la única opción que tienes es que WPF te permite el formato XBAP, es decir, que la aplicación se pueda ejecutar desde el navegador...el problema es que siempre necesitarás el framework en cliente....la otra alternativa es tener una versión de UI en WPF para la aplicación de escritorio y otra en Silverlight para web....o bien como dice Jorge esperar a Silverlight 3 (que está a punto de caer).

Un saludo

JC's

# Mario Munera said on Wednesday, June 17, 2009 9:46 AM

En respuesta a Julio te digo que sí, podrás tener la misma aplicación tanto en escritorio como en Web. La única pega que yo le encuentro es que a día de hoy WPF es un verdadero quebradero de cabeza el uso de los UserControl ya que está muy verde (sin hablar de la locura que es el uso del XAML a pelo). El acceso a ellos y el 'pintado' dentro de un Canvas según la aplicación es o muy sencillo o muy tedioso, dependiendo del grosor de esta. Por lo demás basta con cambiarle a la pantalla inicial desarrollada para escritorio el tipo de Window a Page. Ya que, en uso con BBDD, atacan al mismo IIS y sucedáneos. Requisitos, pues una excepcional conexión, piensa que tu ejecutable de escritorio deberá ser descargado cada vez que se acceda desde web y para una aplicación muy pequeña de 500kb es irrelevante pero si lo extrapolamos a una de 50 MB por poner un ejemplo la cosa cambia...

Espero haberte ayudado.

# jorge said on Wednesday, June 17, 2009 9:47 AM

Muy bueno el post Juan (y el blog en su conjunto).

Pregunta 1: ¿No es Silverlight la parte de WPF para web?. ¿Es otra tecnología diferente?.

Preguna 2: ¿Un buen libro en castellano de WPF, de los que no tienen un millón de páginas?. Y que se pueda comprar en España.

Si es electrónico y gratuito mejor .... :-)

# miguel said on Wednesday, June 17, 2009 9:59 AM

Yo antes trabajaba con WinForms y en cuanto vi las capacidades de WPF me cambié sin dudarlo.

Hice el 70-502 y ahora todos mis desarrollos son con WPF.

Es cierto que tal vez la curva de aprendizaje sea algo alta, pero en mi opinión merece la pena.

Hay aspectos en los que, a pesar de ser una tecnología relativamente reciente, WPF supera de largo a WinForms.

Creo que en un mundo en el que el cliente demanda cada vez más facilidad de uso, capacidades y riqueza visual, WPF es la opción.

Esta es mi opinión.

Un saludo a todos.

# Cristian Manteiga said on Wednesday, June 17, 2009 10:24 AM

Hola Juan,

La verdad es que no me sorprende la afirmación que haces sobre aplicaciones de línea de negocio. Esta es una de las primeras dudas que surgen con WPF y en el fondo con cualquier tecnología reciente que se presenta como una alternativa de adopción. Es cierto que el desconocimiento de los entresijos de una tecnología hace que dudemos de su utilidad, pero también son dudas fundadas en la resistencia al cambio a una tecnología en la que no te sientes tan seguro y sobre la que no pesan los años de experiencia en el desarrollo con ella. Debo decir que esas mismas dudas ya las tuvimos con Windows Forms en su nacimiento.

Mi comentario pretende aportar mi visión del estado de la tecnología actualmente.

WPF no está en su primera versión, si no que actualmente está en la 4ª release y próximamente dispondremos de la 5ª con .NET 4.0.

Creo que el primer mito que hay que dejar de lado es que no puedes desarrollar en WPF sin un diseñador, esto es totalmente falso, el resultado sería el mismo visualmente que con Windows Forms. Si bien el trabajo de un diseñador logrará una imagen más uniforme y consolidada de nuestra aplicación. La verdadera ventaja de WPF frente a WF es sin duda el potencial que proporciona en enlace a datos, separación entre lógica y presentación, modelo unificado para todos los aspectos de nuestras aplicaciones, ejecución en Browser y por supuesto reutilización de código y compatibilidad con Windows Forms.

Debo darte la razón en que la adopción de WPF requiere de un perido de formación y sobre todo de un cambio en la forma de pensar si vienes de WinForms.

Me gustaría contestar a tus preguntas desde mi experiencia en el desarrollo de aplicaciones con WPF:

WPF es una tecnología madura y muy eficiente.

WPF permite mejorar el diseño, la usabilidad y la interacción de una aplicación sin costes elevados y creo que es a dia de hoy un sustituto digno de WinForms.

Silverlight es una tecnología para el desarrollo de RIA y por lo tanto un subconjunto del Framework orientado a aplicaciones web, no un framework para desarrollo de aplicaciones de escritorio aunque la base de las dos tecnologías sea la misma y su evolución sea paralela.

WPF está completamente preparado para todo tipo de aplicaciones de linea empresarial, ya sea un ERP, CRM, programas de gestion, etc y mi experiencia en el desarrollo de este tipo de aplicaciones con mi empresa así lo confirma.

Por último decir que WPF permite el despliegue de las aplicaciones en escritorio (EXE) y en entornos Web mediante XBAP (solo entornos windows).

Espero que mis comentarios ayuden a ver la tecnología desde otro punto de vista.

# Pedroafa said on Wednesday, June 17, 2009 10:35 AM

Para el tema de aplicaciones cliente / web, también se podría hacer una compilación en xbap y otra en .exe normal. Para ello existe un template de proyecto para visual studio  "Flexible Application" (scorbs.com/.../vs-template-flexible-application). Básicamente es tener dos "ventanas principales" una para web (page) y otra para cliente (Windows) y según el tipo de compilación de hagas xbap o exe te instancia una u otra.

La ventaja de utilizar esto frente a WPF (cliente) + Silverligh (web) es que el desarrollo es el mismo al 95%. Sólo tienes que mantener dos "ventanas principales " el resto del desarrollo es el mismo. Evidentemente a la hora de desarrollar tienes que tener en cuenta las limitaciones de xbap.

Un saludo,

Pedro.

# Mario Munera said on Wednesday, June 17, 2009 10:51 AM

Por otro lado, y no quiero que parezca que soy un detractor de WPF (es más, soy pro-WPF) estoy muy descontento con el ensamblado que se ha hecho de Expression Blend con VS así como con SourceSafe. Por lo menos todo lo que yo he desarrollado he tenido que tener tanto Blend como VS ejecutándose a la vez sin poder editar el 'Code Behind' desde Blend, algo que por lo que he visto se ha solucionado en la Versión 3, pero con un IntelliSense muy descafeinado todavía, nada que ver con el disponible desde VS.

Qué decir ya del control de código fuente de SourceSafe desde Blend. Muy decepcionado en este aspecto.

Por lo demás. Decir que estoy muy contento por todas las posibilidades que ofrece esta plataforma al margen de 'pequeñas cosas' que lo deterioran un poco.

# Juan Irigoyen said on Wednesday, June 17, 2009 12:46 PM

Gracias a todos por vuestros comentarios.

@Julio, así es, puedes aprovechar las ventajas que te da WPF, para ejecutarse sobre plataforma Web, lo único que tienes que tener en cuenta es que de momento solo funcionara en entornos Windows.

@Jorge, como responde Cristian Manteiga  posteriormente, Silverlight está orientado a la web y aunque comparten la misma tecnología no es un framework de desarrollo de aplicaciones de escritorio, la duda es si se convertirá en esto, tal y como apunta Jorge Gamba, sobre el libro yo inicialmente aprovecharia los recursos, Microsoft dispone de un curso gratuito en http://www.desarrollaconmsdn.com/msdn/CursosOnline/Curso_WPF/index.html, tambien tienes otro en el programa desarrollador 5 estrellas, que ademas siempre y cuanto hayas cumplido con las tres estrellas anteriores, Donetmania tiene un pequeño libro Windows Presentation Foundation 7, que te puede ayudar a iniciarte de una forma sencilla. Un buen libro para empezar podria ser http://oreilly.com/catalog/9780596101138/ pero esta en ingles. Saludos.

@Cristian, muchas gracias por tu comentarios, se agradece especialmente que hables sobre experiencias propias, coincido en la mayoría de las cosas que expones. Entiendo que desde luego una tecnología moderna como WPF, tiene mucho que mejorar, sobre todo en el apartado del diseño de interfaces gráficos, la verdad trabajar con XAML es un autentico coñazo, no creo que nunca me pueda acostumbrar. En cualquier caso creo que la mayoría de los errores y problemas que presenta actualmente serán solucionados en las próximas versiones ya que la apuesta parece cada vez más clara. Te animo a que escribas un post sobre tu experiencia con WPF, con sus problemas y los beneficios que os ha aportado, sería de gran utilidad. Saludos.

# Francisco J said on Wednesday, June 17, 2009 4:03 PM

Muy buen post Juan, yo creo que sí van a tender hacia WPF los nuevos desarrollo aunque creo que para que ese paso se de falta un poco, sobre todo porque adaptar muchas aplicaciones sería algo complicado, sobre todo las que vienen de NO .NET.

Otra cosa, alguien preguntaba material en castellano de WPF.

Acaba de salir hace un mes aproximadamente el libro de WPF de O'Reilly traducido por la editorial Anaya Multimedia llamado WPF. Caro pero merece la pena.

WPF

ANAYA MULTIMEDIA/O´REILLY

Chris Sells y Ian Griffiths

960 páginas

Mayo 2009

72,70 Euros

Saludos.

Francisco J.

# El Bruno said on Thursday, June 18, 2009 8:08 PM

Hey que bueno; este es de los posts interesantes !!! y comento solo 2 cosillas:

- SL3 no va a desbancar a WPF, pensad que SL se ejecuta en un sandbox aislado que no permite acceso a recursos locales, que tiene un modelo de seguridad muy restrictivo, etc. Cuando haya que crear aplicaciones que requieran alto nivel de integración con Windows, pues SL lo lleva frito

- pues yo debo ser un poco mastuerzo, porque lo de reaprovechar codigo entre SL y WPF no me funcionó. A ver, después de un proyecto muy grande de SL (que realmente me dejó asombrado por las capacidades de presentación que tiene) en determinado momento tratamos de pasarlo a un AddIn de Office, es decir reaprovechar toda la logica y presentarlo nuevamente en WPF dentro de un AddIn. Por suerte en enfoque no era un MVP pero era parecido, y la parte de gestión de logica y presentación se pudo aprovechar, pero los XAMLs y los controles son como un huevo y una castaña ... pero repito puede ser por la ignoracia de quien suscribe.

Saludos

PD: ahh y por cierto ... yo creo que todavía tenemos WinForms para rato !!!

# Juan Irigoyen said on Friday, June 19, 2009 12:28 AM

@Francisco muchas gracias por tus comentarios.

@Bruno creo que eres el primero que cree en Winforms, menos mal que todavia queda alguien...

Comparto lo que dices sobre el XAML y los controles, veremos como lo han mejorado en VS2010.

Saludos y gracias.

# Juan Irigoyen said on Friday, June 19, 2009 12:40 AM

Alvaro, pues no se, preguntaselo a Tarzán que en uno de sus viajes a lo largo del rio, se agarro a una vieja liana, y cayo rompiendose la crisma, eso si, al caer de cabeza lo hizo sobre el pobre cocodrilo que pasaba por all y murieron los dos, en fin, cuantas desgracias.... :)  

Saludos

# Francisco J said on Friday, June 19, 2009 7:08 PM

Bueno yo creer creo pero creo que los que tienen la sartén por el mango son los que sacan el Visual Studio y el NET Framework.

Es más, a mí me sigue gustando más GDI+ que XAML aunque éste último hay que reconocer que en muchas ocasiones facilita mucho los desarrollos.

Pero en fín, como comento habrá que esperar a ver qué decide Microsoft.

También hay que tener en cuenta que tendemos en todos los aspectos a la INTEROPERABILIDAD, y XAML es más interoperable que GDI y otros elementos como Windows.Forms, etc.

Saludos.

Francisco J.

# Francisco J said on Wednesday, June 24, 2009 11:36 PM

Uf ¿qué ha pasado? ¿Me he perdido algo? Bueno espero que no sea nada, y sigue así con los post tan buenos.

Saludos.

Francisco J.

# Juan Carlos González Martín said on Wednesday, June 24, 2009 11:50 PM

Apoyo la moción!

JC's

# Alejandro said on Thursday, June 25, 2009 12:39 AM

Jajajajajajajajaja.

Beautiful !!!

I'm agree.

# Alejandro said on Thursday, June 25, 2009 12:41 AM

Lo dicho, todo esta en como se prepara la critica.

Que se observe el animo de ayudar.

Bueno, Juan, sigue con ese animo de escribir (al igual que los demas que postean aca) que siempre son bienvenidos.

# Gonzalo Perez said on Thursday, June 25, 2009 3:17 AM

Hestoi komo zienpre, mui dehakuerdo!

# Miguel LLopis said on Thursday, June 25, 2009 4:18 AM

Juan,

Totalmente de acuerdo contigo en que hay maneras y maneras de decir las cosas, especialmente cuando se trata de sacar a relucir fallos ajenos. Quien más y quien menos, comete de vez en cuando algún error y el hecho de dedicar un tiempo y un esfuerzo a escribir con el ánimo de compartir conocimiento ya merece un mínimo de respeto por parte de quien quiera "denunciar" los errores.

De igual forma, pienso que una segunda lectura a un post una vez finalizado ayuda a detectar muchos fallos, no sólo ortográficos, también gramáticales y de coherencia entre frases, párrafos, etc. Por último, usar algún corrector ortográfico sobre el texto definitivo no viene nunca mal. Son dos tipos de "filtros de calidad" que, en comparación con el tiempo invertido en el "desarrollo" del post, no requieren demasiada inversión adicional.

No seré yo quien se decante por una u otra opción, tal cual nos enseñó Platón: "La virtud se encuentra en el equilibrio entre dos extremos". Aunque si me viera obligado a elegir, tengo claro con qué me quedaría... En definitiva, mantener un blog es un buen ejercicio para perfeccionar nuestras habilidades comunicativas y de los errores se (debería) aprende(r).

Enhorabuena por tu blog. ;-)

M.

# Trubuctu said on Thursday, June 25, 2009 8:18 AM

Es vergonzoso que la gente se preocupe mas por el paquete que por el contenido de este, por bueno que este sea.

Siempre hay personas que solo saben criticar, y lo inteligente es sugerir.

Hasta los cojones de esta gente.

# Jersson said on Thursday, June 25, 2009 8:29 AM

Hola, no he terminado de leer tu post, pero completamente de acuerdo.

La verdad es que a veces uno busca aportar con lo que va conociendo en el camino, y en el apuro, pues no se da cuenta si faltan o no algunas tildes.

Es algo incomodo que uno a veces luego de esperar un "interesante, no sabia que tambien se podia hacer en el framework 4.0, he notado que si usas coderux pues lo haces mas rapido!" uno reciba un comentario tipo "amigo, no te pases de listo, te faltan 200 comas y 3 puntos suspensivos!"

Un saludo

# Luis Ruiz Pavón said on Thursday, June 25, 2009 8:50 AM

Totalmente de acuerdo contigo Juan :)

Las veces que he tenido que borrar comentarios de mi blog, despectivos y sin ningún tipo de coherencia, como tú bien dices, por tocar los cojones.

Sigue así compañero!!!

Un saludo

# Víctor González said on Thursday, June 25, 2009 9:06 AM

<ironia>

Pobrecillo, lo que habrá sufrido tu corrector ortográfico... jeje

</ironia>

En todo lo demás estoy de acuerdo, en lugar de intentar ver el esfuerzo y el contenido del post, van a dinamitar el blog con tonterías sin sentido

# DCLive said on Thursday, June 25, 2009 9:14 AM

La verdad es que muchas veces somos muy poco respetuosos con el trabajo ajeno. Maxime cuando este trabajo es altruista.

Me he dado cuenta, tiempo ha, que se le exije mas a aquel que dona su trabajo de forma gratuita a una comunidad, que a quien cobra por el. Si desarrollas una aplicación, o utilidad, o si escribes un tutorial, y no cobras por ese trabajo, te van a llover las criticas, te van a pedir entregas ("¿Cuando sacaras la ultima versión?, ¿cuando vas a corregir los errores?, ¿cuando vas a continuar las entregas del tutorial?"). Paradojicamente no exigimos de la misma manera a quien publica un libro (y tenemos que pasar por caja) y contiene errores. Al fabricante de software que libera versiones con bugs, etc.

Tengo clarisimo, que las comunidades de usuarios, a traves de internet, gozan de una tremenda fuerza que podemos denominar retroalimentación. Tu me proporcionas herramientas o conocimeintos, y yo aporto mis puntos de vista, correcciones, pruebas. Pero para que esto funcione, debemos basarnos en la educación y el respeto. Porque, lo mismo, suena diferente desde la exigencia que desde la sugerencia.

Por otro lado, tambien hay que tener cuidado en aquello que aportamos. Si escribimos un texto, seamos exigentes con nosotros mismos. Revisemoslo, comprobemos que se puede entender (por el comun de nuestros lectores), que tenga las menores faltas de redacción posibles. Y tratemos de mejorar. Porque esa superación, nos llevara a nosotros mismos a crecer.

Demos calidad a nuestras aportaciones, dentros de nuestras limitaciones, y tratemos día a día de superar nuestras propias limitaciones. Y en el otro lado, colaboremos desde la educación y el respeto por el trabajo ajeno. Sobre todo por el trabajo altruista, que se paga con el agradecimiento y el interes, que para el trabajador altruista, es mas valioso que el dinero.

Un saludo

Fidel Ortega

# Pedroafa said on Thursday, June 25, 2009 9:31 AM

Con lo bueno que es discutir sobre las cosas con educación y civilizadamente. Además, como bien dice Trubuctu, lo inteligente es sugerir.

Un saludo,

# Mario Cortés Flores said on Thursday, June 25, 2009 9:34 AM

Paciencia y ánimo

# Juan Irigoyen said on Thursday, June 25, 2009 10:43 AM

Gracias por vuestros comentarios, la verdad es que estoy en el ciclo premenstrual y claro las hormonas hacen de las suyas...

En cualquier caso, no soy de los que no acepten una críticas, es más, los que me conocen saben que me gusta especialmente "discutir" y obtener diferentes puntos de vista, esto me enriquece como persona y me anima a seguir trabajando y escribiendo.

Creo que todos los que escriben aquí y en otras comunidades, luchan día a día por mejorar, no solo en lo referente a la ortografía y gramática si no en todo lo relativo a describir adecuadamente la información que quieren transmitir y contrastar la veracidad de sus textos.

En mi caso siempre leo los posts varias veces antes de subirlos al blog, le paso un corrector ortográfico y habitualmente le pido a mi mujer que revise el texto, ya que hay ciertas palabras y errores gramaticales que este no detecta. Aún así cometo errores que espero con el tiempo y  vuestra ayuda ir subsanando.

Pero lo que no puedo soportar son los comentarios despectivos tipo a "estoy harto de le deis tantas patadas al diccionario..." y similares. Así que después de un tiempo y uno de estos comentarios me decidí a escribir este post, espero que no sea demasiado fuerte y os animo a criticar con educación cualquier aspecto que veáis mal, esto enriquece a todos los que formamos parte de esta comunidad.

Con lo fácil que es decir "acuérdate de poner el acento al final de las palabras esdrújulas...".

# Rodrigo Corral said on Thursday, June 25, 2009 11:08 AM

Jajjajajaj... muy muy divertido... de todas formas creo que debemos respetar nuestro idioma. Y eso que yo soy de los que le dan muchas patadas....

Lo que me revientan son los que utilizan la ortografía para desacreditar tus argumentos... el talibán ortográfico que sea respetuso y didactico, bienvenido sea...

¡Un saludo!

# José Miguel Torres said on Thursday, June 25, 2009 11:09 AM

Aitak, Semeak eta Espiritu Santuak, Amén.

# Ivan Martinez said on Thursday, June 25, 2009 7:55 PM

Es una lástima que alguien se dedique a criticar por faltas de ortografía cuando lo importante es lo que se expone en los post.

Ánimo Juan y sigue con tu blog, con faltas o no, siempre es interesante leerlo. Saludos!

# Juan Irigoyen said on Thursday, June 25, 2009 9:21 PM

Gracias por vuestros comentarios.

@Rodrigo, se que te has estado riendo durante un rato... mientras yo estaba golpeando la columna.... :)

@Ivan, gracias por tus comentarios. Me animan a seguir escribiendo. Saludos.

# apanitsch@gmail.com said on Friday, July 3, 2009 12:54 PM

¿"ay" no va con hache?

# David said on Wednesday, July 8, 2009 10:18 AM

Con hache no, con aché....

# PabloNetrix said on Tuesday, July 14, 2009 6:25 PM

<<se puede invitar a comer a buen restaurante al responsable de la certificación e incluso en algunos casos se puede "comprar" la certificación, he visto empresas con la ISO 9001, que ni siquiera son capaces de gestionar el stock de su almacén o encontrar un pedido en sus ficheros ,>>

Si yo te contara...

# PabloNetrix said on Tuesday, July 14, 2009 6:29 PM

'aché...'

Jesús.

# Rodrigo Corral said on Wednesday, July 15, 2009 8:27 AM

Interesante post, Juan. No puedo estar más de acuerdo con todo lo que expones. Verdades como puños que además vienen de alguien que ya está aplicando Scrum.

¡Un saludo!

# Juan Irigoyen said on Thursday, July 16, 2009 12:33 AM

Gracias por vuestros comentarios, un saludo.

# Alvaro Pardo said on Monday, September 14, 2009 8:48 AM

Un post genial. Yo reconozco que en eso de innovar (o ser original, dicho sea de paso) soy bastante malo, pero en general estoy completamente de acuerdo con lo que dices. A ver si los de arriba toman nota y dedican algo a innovacion de una vez...

# El Bruno said on Monday, September 14, 2009 9:31 AM

Excelente post !!! y un ejemplo de "innovación forzada" lo puedes tomar en los paises con pocos recursos. Por ejemplo en mi pais, hablar de productos como MOSS o Biztalk es algo ímposible por una cuestión de costes. Y este escenario hace se creen productos para solventar problemáticas específicas que son verdaderas obras de arte. Ojo, algunas son unas obras de arte y otras son como un cafe de máquina ... vamos que es innovación a la fuerza :D

Saludos

# Juan Irigoyen said on Monday, September 14, 2009 4:47 PM

@Alvaro, estoy deacuerdo, las empresas y el gobierno deben invertir en I+D, pero tambien depende de nosotros. Gracias por tus comentarios.

@Bruno, así es, la necesidad agudiza el ingenio, es una pena que sea debido a contar con menos recursos, aunque toda innovación bienvenida sea.

Un saludo.

# Juan Carlos González Martín said on Monday, September 14, 2009 5:11 PM

Muy buen post Juan!

Realmente la innovación depende de las personas, pero también se necesita inversión y el lastre de este país es que las empresas no se mojan en invertir en I+D+i, esperan que el estado lo haga cuál gallina de los huevos de oro, y claro el estado llega hasta donde puede...en mi opinión, es necesario que las emperesas inivertan + en I+D+i, y el ejemplo que das de Bosh vs IBM es bastante claro, aún siendo Bosh una empresa bastante innovadora dentro de lo que cabe.

En mi opinión, hay que incentivar la innovación ofreciendo algo atractivo a los posibles "innovadores" para que nos estrujemos la cabeza y no tengamos miedo al riesgo, que yo creo que es también un problema que tenemos en este país: por lo general, tendemos a ser cómodos y nos arriesgamos cuando lo vemos claro.

Un abrazo

JC's

# Juan Irigoyen said on Monday, September 14, 2009 8:01 PM

@Juan Carlos, estoy completamente deacuerdo, las empresas deben incentivar y dedicar parte de sus recursos a la innovación, de hecho no puedo entender como en la mayoria carecemos de un Dpto. de I+D y como tal con un presupuesto preasignado, en cambio existen todos los demas Personal, Calidad, Financiero, Contable, Comercial, RRHH, etc. Las empresas no quieren invertir en algo que marcara su futuro, es incompresible, esperemos que al menos con la crisis muchas se den cuenta de su error.

Un saludo.

# Fran said on Tuesday, September 15, 2009 8:18 PM

Hola. Tal y como ya han dicho por aquí excelente post y tema.

Aunque la necesidad obliga a la innovación, la clave está (en mi opinión) en que las empresas no solo piensen en el corto plazo, sino tambien en el medio y largo plazo, que es donde realmente se le puede sacar (a priori) más rendimiento a la innovación.

En españa pocas empresas piensan de esta menera, sin embargo fuera de España si hay mas cultara del medio, largo plazo (donde se implantan "metodologías" como ITIL o Cobit que no solo tienene en cuenta el corto plazo, sino tambien el medio y largo plazo)

Por cierto leyendo este post me he acordado del libro en.wikipedia.org/.../Who_Moved_My_Cheese.

Saludos,

Francisco R

# Juan Irigoyen said on Tuesday, September 15, 2009 9:20 PM

Hola Fran, agradezco mucho tus comentarios, te agradezco lo del libro, tratare de leerlo, comparto lo que dices, creo que otros países nos llevan años de ventaja, quizás es algo cultural, pues la innovación debe formar parte necesariamente de nuestras vidas, uno de las factores que cita el artículo de la Wikipedia es ‘Disfrutar del cambio’, creo que este es una aspecto esencial, habitualmente no disfrutamos de nuestro trabajo, venimos de una cultura dura en la que los empresarios dictaban las normas, creo que estamos empezando a dar cuenta de la importancia que tienen las personas, por ello son las empresas que apuestan por ellas, las que logran sacar mayor valor añadido, por una parte incentivando su creatividad haciendo que su trabajo sea un hobbie y enseñando que la cultura del cambio debe ser algo natural, por eso los europeos se emancipan antes y están más habituados desde que son muy jóvenes a cambiar de trabajo, viajar a diferentes países, etc, a nosotros todavía nos queda un largo camino que recorrer, aunque opino que sobre todo en los últimos tiempos se aprecian pequeños cambios, ya nadie se asusta cuando la gente se va a trabajar fuera o a estudiar otro idioma o cultura, creo que la siguiente generación estará mucho mejor preparada para aceptar la cultura del cambio.

Un saludo.

# Miguel Sierra said on Tuesday, September 15, 2009 9:50 PM

Yo creo que la velocidad en la automoción tiene un límite administrativo, pero hoy en día las infraestructuras y los vehiculos permiten viajar con seguridad a velocidades mayores de las permitidas y esto está asociado con el riesgo de las vidas humanas. En cambio en el software no existe ni esa limitación administrativa ni ese riesgo de accidente, por lo que creo que una conexión nunca será lo suficientemente rápida, y se nos ocurrirá a los desarrolladores maneras de aprovechar mejor esa velocidad... cambiar las políticas de cacheo, buffer, ajax, resolución de los datos a traer, etc... pensemos en algo sencillo como google maps, bing maps, google earth... creo que nunca va a haber conexión suficiente para dar servicio a los datos que se podrían mostrar en el cliente.

# Juan Irigoyen said on Tuesday, September 15, 2009 10:23 PM

Miguel, yo creo que la velocidad de internet dejara de tener la importancia que tiene hoy, tal y como ha pasado con la velocidad en MHz de los procesadores, sin bien los múltiples núcleos han suplido esta carencia, pero incluso hoy en día estamos lejos de sacar verdadero partido a nuestro hardware, ya hace varios años que salieron al mercado los procesadores de 64 bits y son muy pocas las aplicaciones que los aprovechan, disponemos de  equipos con 8 o más procesadores y la mayoría del software actual es incapaz de utilizarlos, creo que en muchos casos, el desarrollo comienza a ir por detrás del hardware, solo algunos programas y juegos son capaces de aprovechar los recursos de los que disponemos, existen tantos avances en la tecnología Adsl que hablan ya de velocidades que superan ampliamente los 100 mbps, ni los discos duros son capaces de aprovechar la velocidad de una tarjeta gigabyte, así que creo que en un espacio relativamente corto, la mayor parte de las necesidades que tenemos incluyendo video bajo demanda, modelado en 3D y otros, podrán realizarse sin problema y la velocidad de acceso a internet dejara de tener tanta importancia como tiene hoy.

Gracias por tus comentarios.

Un saludo.

# Eduardo Obregón Gutierrez said on Sunday, September 27, 2009 10:26 PM

Me alegro de ver tanta sinceridad cuando se habla del pasado (no es nada común y menos es estos foros), lo fácil es contar las cosas adornandolas y transfromarlas.

Me quedo con la parte en la que explicas porque se termina reusando del sueño y convirtiendo en una más.

Está muy bien contar las experiencias tanto buenas como malas.

# sentoki said on Monday, September 28, 2009 10:09 AM

Ains!!! que tiempos. Has redactado perfectamente esa parte de mi historia personal.

Lo mejor, que como decía uno de mis socios: "menos mal que somos socios y sin embargo amigos.". Lo peor, que tuve que dejar aquellos sueños.

Este relato tendría que ser leido y discutido en todas las escuelas de informática, para que se sepa por dónde se tira.

Saludos

# PabloNetrix said on Monday, September 28, 2009 10:49 AM

Espectacular.

Esto es casi una tesis doctoral. Qué digo tesis doctoral... es todo un MBA, "comprimido" en un sólo artículo de un blog.

Mis felicitaciones. Yo tambien tuve durante muchos años ese 'sueño' de tener mi propia empresa. Desde que era muy muy jovencillo (y claro, tiene uno la cabeza llena de pájaros) y de haberlo hecho, mis ideas hubiesen ido bastante por donde fueron las tuyas: "tirarme a la piscina sin saber si había agua". Huelga decir que seguramente, habría fracasado estrepitosamente.

O no... ¿Quien sabe?

Saludos

# profe de lengua said on Monday, September 28, 2009 10:59 AM

ReHusando, por favor

# Juan Irigoyen said on Monday, September 28, 2009 11:25 AM

Muchas gracias por vuestros comentarios.

@PabloNetrix, tienes razón, nunca se sabe, he visto gente mucho peor preparada que al final han triunfado y gente muy preparada que han fracasado estrepitosamente, lo que esta claro es que siempre existen razones para que cualquier caso se pueda dar.

@profe, lo siento, ya esta correguido.

Un saludo.

# Jesús Bosch said on Monday, September 28, 2009 2:38 PM

excelente artículo... creo que contiene buenos consejos a tener en cuenta

gracias

Un saludo

JB

# José Miguel Torres said on Monday, September 28, 2009 4:33 PM

Muy bueno Juan. Esto me recuerda una frase célebre de un gran pensador y poeta contemporáneo, Robe Iniesta, quién dice: "Hablo con la sabiduría que me da el fracaso", y es que sin él (el fracaso), seriamos unos hipócritas.

Saludos,

# Rodrigo Corral said on Monday, September 28, 2009 6:20 PM

@Juan, amigo, siento decirte que mientes vilmente. Todo en mundo sabe que, en este pais, cualquier puede hacerse empresario y vivir comodamente sin esfuerzo alguno, de explotar a los trabajadores, de las subvenciones y del dinero negro, que a los empresarios les crece en los bolsillos de manera espontanea. Tu historia es mas falsa que un duro de madera, todo el mundo sabe que no hace falta ni plan de negocio, ni estudios de mercado, ni nada de gestión para que una empresa funcione.

Coñas a parte, nadie podrá decir que no lo intentaste. Lo que me sorprende que una vez mordido por le gusanillo, no lo volvieses a intentar. Es muy jodido levantar una empresa, aun más jodido en este pais, pero también es muy gratificante... en todo menos en lo económico.

También me llama mucho la atención un hecho que a menudo ocurre: teniais más producto que la compentencia, y era peor producto que el de la competencia. Que cosas tiene el software: a menudo menos en más.

Gracias por compartir tu experiencia, es muy interesante.

@José Miguel: ¡Aúpa extremo!

# Juan Irigoyen said on Monday, September 28, 2009 9:36 PM

Gracias por vuestros comentarios.

@Rodrigo, jajajaja, no, no pienses que esta fue la única vez, como dice el refrán un hombre tropieza 25 veces con la misma piedra, ¿o eran 2?...

Todavía tengo alguna oportunidad de hacerlo, pero como sabes, aunque la empresa vaya bien, hay un precio muy alto que pagar, y en este momento, mis prioridades personales no me lo permiten, aunque con el tiempo, nunca se sabe, quizás me anime con la 26, eso sí, nada de software, tengo claro que banquero,  constructor o mejor, político, total en este país a partir de 300 millones no te meten en la cárcel….

Un saludo.

# Miguel Sierra said on Monday, September 28, 2009 10:43 PM

Qué bueno Juan!!

Yo creo que lo deberías de volver a intentar, todavía eres muy Joven ;) ... ideas seguro que no te faltan. Solo necesitas tener algún "primo" bien ubicado.

Cantabria es una mala zona para empezar una aventura empresarial... (y menos de software) Un dato: en el sector público en Cantabria tienen trabajo las empresas de fuera, es el axioma fundamental de este gobierno "regionalista", el cual destina 10 centimos, de cada euro invertido en software, en Cantabria... Presentate tú a un concurso en Euskadi a ver por donde te dan...

Me ha encantado el artículo!!    

# Juan Irigoyen said on Tuesday, September 29, 2009 12:16 AM

@Miguel, gracias por tus comentarios, pero de momento tengo un buen trabajo en una excelente empresa (y no es porque sea la mía), mantengo una  excelente relación con mis superiores y tengo algún compañero que de momento, me ‘aguanta’, participo activamente en la mayoría de las secciones de la empresa, dispongo de horario libre, formación continua y otras ventajas. Esto me permite disfrutar de mi familia y de mi trabajo, ¿qué más se puede pedir?

Si una cosa he aprendido es que, para liderar una empresa hay que hacer muchos sacrificios y la mayor parte de las veces, el precio es demasiado alto, aunque nunca se sabe, quizás algún día, vuelva a tropezar…

Un saludo.

# Nestor Jarquin said on Tuesday, September 29, 2009 12:49 AM

Excelente articulo, me ha gustado la manera en que has expuesto tu experiencia de manera que los que estamos "naciendo" en este ámbito nos demos cuenta que no es fácil, pero de las experiencias (propias y ajenas) se aprende y no hay nada mejor que escuchar a los que ya pasaron la prueba.

Muchas gracias por compartir tu historia y seguro que tanto tu como nosotros hemos aprendido algo de esta entrada.

Saludos...

# Juan Irigoyen said on Tuesday, September 29, 2009 1:04 AM

@Nestor, me alegra de que te haya gustado y que además seas de los que empiezan, tu generación lo tendrá más difícil que la mía, así que toda ayuda será poca, no pierdas el ánimo y aprovecha tus oportunidades, todos tenemos alguna.

Un saludo.

# Lucas said on Tuesday, September 29, 2009 3:35 AM

Excelente entrada realmente. Valen la pena las 15.000 lineas de este post, me ha encantado.

Muy bueno Juan, muy bueno.

Gracias por compartirlo.

# Juan Irigoyen said on Tuesday, September 29, 2009 7:46 AM

Gracias Lucas, me alegro que te guste.

Un saludo.

# Jose Moreno said on Tuesday, September 29, 2009 10:57 PM

Gracias por esas palabras Juan.

Me has motivado a retomar con seriedad un proyecto que tengo empolvado por ahí... pero que aun tiene oportunidad de nacer.

Creo que estoy dispuesto al fracaso con exito.... Saludos.

# Juan Irigoyen said on Wednesday, September 30, 2009 12:17 AM

@Jose, me alegra haberte motivado para ello, te deseo mucha suerte con tu proyecto.

Un saludo.

# DennisVega said on Wednesday, September 30, 2009 7:19 PM

Super-Duper site! I am loving it!! Will come back again - taking your feeds too now, Thanks.

# Juan Irigoyen said on Wednesday, September 30, 2009 10:20 PM

I'm glad you like it.  Thanks for your coments.

# Ramón Sola said on Wednesday, September 30, 2009 11:27 PM

El comentario de DennisVega es spam.

# Ramón Sola said on Thursday, October 1, 2009 7:23 PM

Y este otro de Tnelson también es spam.

# juan carlos segura castillo said on Tuesday, October 6, 2009 9:22 PM

Pues la verdad ni loko me pongo a desarrollar tan solo un proyecto por mas pequeño q sea en visual estudio.. yo como ing. de sistemas y programador de sistemas empresariales.. no lo usaria para nada hay mejores herramientas..  todo depende de la capacidad con la cuenta el programador y la formacion academica.. los q empiezas a usar VS. pues solo son programadores academicos... creo q no sabes mucho de algunos lenguiajes y plataformas q como dicen mucho esta en desuso..pero digo algo en power builder o en visual foxpro 9... lo que hacen 3 programadores en 2 meses yo lo hago en 1 mes y solo en cualquiera de estas 2 ultimas plataformas... que pena q en vez de avanzar se retroceda..

# Juan Irigoyen said on Friday, October 16, 2009 7:30 PM

@Juan Carlos, pienso que te equivocas, he desarrollado varios años en power builder y en Visual Foxpro desde la versión 2.0 (msdos) hasta la 9.2, actualmente aún mantengo desarrollos en esta plataforma y finalmente tuve que abandonarlas porque no me permitían avanzar, dime como desarrollas aplicaciones en dispositivos móviles en power builder o visual foxpro, o sistemas de comercio electrónico, o arquitecturas orientadas a servicios.

Visual foxpro y pb pueden utilizar servicios web, pero desgraciadamente estos entornos no han evolucionado lo suficiente para las necesidades actuales, aunque su velocidad de desarrollo es mucho mayor, como me acuerdo de vfp todos los días. No puedes desarrollars sistemas de calidad utilizando pruebas unitarias, workflows, entidades, etc. Muy pocas plataformas pueden hacer sombra a Visual Studio, de hecho para mi es la más completa, únicamente algunas en Java, pueden llegar a competir con este entorno.

Pero el rendimiento de vs debe necesariamente  mejorar, porque si no llegara un día en el coste del desarrollo no compense todo lo que aporta visual studio, veremos lo que nos depara el futuro.

Un saludo y gracias por tus comentarios.

# CN said on Friday, October 23, 2009 1:04 PM

Post excelente. Opino como el resto.

A las empresas en España ya se les da apoyo para innovación. Hay subvenciones a nivel autonómico, estatal y europeo para esas cosas.

Lo que sucede es que en realidad esas ayudas se emplean en productos que sean de utilidad para la empresa - quiero decir con esto que sean rentables, que se les pueda sacar partido -. No hay un innovar por mejorar sino innovar si le podemos sacar partido.

De modo que la mayoría de las veces los productos tienen algo de innovación e investigación, pero muy poco, el resto se basa en técnicas conocidas.

Esperemos que de todas estas reflexiones, se saquen resultados provechosos y seamos optimistas. Creo que aunque poco a poco, vamos hacia el buen camino.

Saludos

# Ibon Landa said on Sunday, October 25, 2009 9:06 PM

Pimpinela? Uno no es Miguel??

Con bien que nos portamos contigo y así nos lo pagas...no te preguntamos nada!!

# Juan Irigoyen said on Sunday, October 25, 2009 9:30 PM

¿Miguel?, jajajaja..., no, creo que Miguel estaba en el coro :)

# Juan Carlos González Martín said on Sunday, October 25, 2009 10:15 PM

...Ey, es como dice Ibón :P...Pimpinela van a ser Rodrigo y Miguel, con Ibón como aparición estelar (mejor no doy detalles)

Gracias chicos por participar en el evento, estuvo genial!

Un saludo

JC's

# Miguel Sierra said on Monday, October 26, 2009 12:28 AM

El evento fue un éxito!!

Juan te sugiero cambiar el video por este: www.youtube.com/watch

Rodrigo y yo vamos estamos preparando la nueva versión remasterizada.

# Juan Irigoyen said on Monday, October 26, 2009 12:41 AM

@Miguel, jajajajaja tienes toda la razón, es mucho mejor... :)

Un saludo.

# Jesus Angel said on Monday, October 26, 2009 12:54 AM

Muy interesante el artículo, un saludo.

# Juan Irigoyen said on Monday, October 26, 2009 9:47 AM

@Jesus Angel, gracias por tus comentarios, me alegro que te guste.

# ciro said on Tuesday, November 17, 2009 6:27 AM

Gracias, nuy wena la informacion

# juan carlos segura castillo said on Wednesday, November 25, 2009 5:13 PM

Hola tocayo... no nesecito hacer software con dispositivos moviles para mis ERP. para eso usamos telefonia (Sale mas Barato) Visual Foxpro. es tan poderoso este lenguaje de programacion.. que me permite hacer prestaciones con diferentes servidores (Oracle,Sql Server,Firebird,MySql..etc)

es decir si pensamos q la maravilla del mundo es VS.net pues no han visto nada... y lo mas probable que si voy con un sistema en VS.Net. crees q mis clientes van a cambiar sus Equipos ? crees q van a tenerme metido ahi todo dia solucionando los errores y Bugs q tiene esa plataforma...?... No Hijo.. me dirian q estoy loco... ya he probado VS.NET. y hasta el mismo PowerBuilder.. no hay plataforma q me ofresca tanta compatibilidad ya sea en Win98,2000,NT,2003,XP,Vista que es el sistema operativo actual que uso. TRabajo con V.Foxpro 9 y SqlServer 2005. no hay lenguaje q con tan solo unas lines me permite hacer coneccion y actualiaciones.. invito  a que revizen las bondades de este programa.. como repito ya intente meterme en VS.Net y fue una gran descepcion... como analista programador de sistemas para empresas clientes... no usaria una herramienta tan incompatible a cada version... creo q debemos pensar y ver los pro y contras.. ya los revize detenidamente.... no hay plataforma mas pesada e improductiva q vs.net. en mi opinion .... los nuevos programadores solo saben  de .net. que es lo q academicamente aprenden.. y creen tener el mundo a sus pies.. llevo mas de 15 años en este negocio se lo q es bueno y no lo q tambien

saludos desde lima peru.....

# Mercedes said on Wednesday, December 2, 2009 10:21 AM

Me ha servido de gran ayuda este post!

# marina *-* que hago aca said on Saturday, December 12, 2009 9:17 PM

que mierda me importa las cosas que hicieron monos feos me llevo biologia a diciembre y entonces tengo que estudiar a estos monos que no los conoce ni dios que truchoo la  *** madre

# Omar said on Monday, January 18, 2010 8:54 PM

Solo quisiera agregar un comentario, este ejemplo solo devuelve los "hijos" de un solo nodo, en mi caso, todos mis nodos de primer nivel tienen el padre 0, entonces, si quiero traer el árbol completo, tengo que cambiar el where por us1.Clave in (SELECT Clave FROM ... WHERE Padre = 0) y el otro us2.Clave not in (SELECT Clave FROM ... WHERE Padre = 0) y asi trae todo el arbol completo, un poco desordenado pero ordenarlo es sencillo.

Saludos!!

# Juan Pablo said on Thursday, March 25, 2010 12:28 PM

Me parece una idea muy interesante-

¿Podrias subir el codigo?, por favor.

Muchas gracias

# Juan Irigoyen said on Thursday, March 25, 2010 1:00 PM

Lo siento Juan Pablo, no puedo subir el código ya que utiliza partes de toda la aplicación basado en nuestro propio sistema de entidades, con lo que tendria que subir practicamente toda la aplicación, por eso he escrito el código de las partes mas relevantes para que facilmente puedas construir una utilidad similar

Un saludo.

# Javier Torrecilla said on Thursday, March 25, 2010 1:02 PM

Juan, la verdad es que me parece muy intereasntes el post, y realmente util.

# Juan Irigoyen said on Thursday, March 25, 2010 2:19 PM

Gracias Javier.

Un saludo.

# tester said on Friday, March 26, 2010 11:09 AM

Puede aportar algo más de código (más completo) del procesamiento de los ficheros, nada de entidades propias de su sistema ?

saludos

# Juan Irigoyen said on Friday, March 26, 2010 12:10 PM

Como explico en el post utilizo un bucle similar a este, dentro de un threat diferente utilizando backgroundWorked para no bloquear el programa mientras se cargan los ficheros. El esquema sería similar a este dentro de un bucle for voy leyendo los ficheros con los metadatos y almacenando cada uno de ellos en la base de datos.

private const string path = @"c:\temp";

foreach (string file in Directory.GetFiles(path))

{

     - Recoje los metadatos del archivo utilizando

     FileInfo fileInfo = new FileInfo(file);

     - Serializa el archivo utilizando la función espuesta arriba

     - Encripta el archivo si es necesario

     - Recojo el documento serializado y encriptado con los metadatos de fileInfo y los introducidos por el usuario, se los paso al SP

     - Llama al sp para guardar los datos en la tabla

     - Informa si el archivo se ha subido con éxito

}

La información sobre como utilizar BackgroundWorked, encriptar, y utilizar un Store Procedure la puedes encontrar facilmente en la web, por eso solo he puesto las partes mas relevantes, pero en conjunto es un programa muy sencillo.

Espero que con esta explicación quede más claro.

Un saludo.

# Pablo said on Wednesday, April 7, 2010 8:21 PM

Hola amigo, la verdad que una excelentisima idea, muy útil en mi caso.

Un par de dudas conceptuales:

- ¿Cómo sería el control de versiones? Utilizando el hash de cada file que se quiera subir y comparandolo con el que hay almacenado para ver si esta modificado? O te referis a algo como generar "Version 2" manualmente de un archivo y subirlo?

- ¿Cómo sería una aproximación a la búsqueda en el contenido del archivo? Porque no lo veo muy perfomante tener que ir uno por uno abriendo y buscando un patron en los archivos que estan en la BD.

Salu2

# Jorge said on Monday, May 3, 2010 8:48 PM

I trying to get the Maxlenght but only get null value

Model.

<?xml version="1.0" encoding="utf-8"?>

<edmx:Edmx Version="1.0" xmlns:edmx="schemas.microsoft.com/.../edmx">

 <!-- EF Runtime content -->

 <edmx:Runtime>

   <!-- SSDL content -->

   <edmx:StorageModels>

   <Schema Namespace="dbsgiModel.Store" Alias="Self" Provider="System.Data.SqlClient" ProviderManifestToken="2005" xmlns:store="schemas.microsoft.com/.../EntityStoreSchemaGenerator" xmlns="schemas.microsoft.com/.../ssdl">

       <EntityContainer Name="dbsgiModelStoreContainer">

         <EntitySet Name="cat_sgi_areas" EntityType="dbsgiModel.Store.cat_sgi_areas" store:Type="Tables" Schema="dbo" />

       </EntityContainer>

       <EntityType Name="cat_sgi_areas">

         <Key>

           <PropertyRef Name="id_version" />

           <PropertyRef Name="id_area" />

         </Key>

         <Property Name="id_version" Type="int" Nullable="false" />

         <Property Name="id_area" Type="int" Nullable="false" />

         <Property Name="id_version_superior" Type="int" />

         <Property Name="id_status" Type="int" />

         <Property Name="dc_area" Type="varchar" MaxLength="50" />

         <Property Name="dl_area" Type="varchar" MaxLength="150" />

       </EntityType>

     </Schema></edmx:StorageModels>

   <!-- CSDL content -->

   <edmx:ConceptualModels>

     <Schema Namespace="dbsgiModel" Alias="Self" xmlns="schemas.microsoft.com/.../edm">

       <EntityContainer Name="dbsgiEntities" >

         <EntitySet Name="Areas" EntityType="dbsgiModel.Area" />

         </EntityContainer>

       <EntityType Name="Area">

         <Key>

           <PropertyRef Name="IdVersion" />

           <PropertyRef Name="IdArea" /></Key>

         <Property Name="IdVersion" Type="Int32" Nullable="false" />

         <Property Name="IdArea" Type="Int32" Nullable="false" />

         <Property Name="IdStatus" Type="Int32" Nullable="true" />

         <Property Name="dc_area" Type="String" Nullable="true" />

         <Property Name="dl_area" Type="String" Nullable="true" />

         </EntityType>

       </Schema>

   </edmx:ConceptualModels>

   <!-- C-S mapping content -->

   <edmx:Mappings>

     <Mapping Space="C-S" xmlns="urn:schemas-microsoft-com:windows:storage:mapping:CS">

       <EntityContainerMapping StorageEntityContainer="dbsgiModelStoreContainer" CdmEntityContainer="dbsgiEntities" >

         <EntitySetMapping Name="Areas">

           <EntityTypeMapping TypeName="IsTypeOf(dbsgiModel.Area)">

             <MappingFragment StoreEntitySet="cat_sgi_areas">

               <ScalarProperty Name="dl_area" ColumnName="dl_area" />

               <ScalarProperty Name="dc_area" ColumnName="dc_area" />

               <ScalarProperty Name="IdStatus" ColumnName="id_status" />

               <ScalarProperty Name="IdArea" ColumnName="id_area" />

               <ScalarProperty Name="IdVersion" ColumnName="id_version" /></MappingFragment></EntityTypeMapping></EntitySetMapping>

         </EntityContainerMapping>

     </Mapping>

   </edmx:Mappings>

 </edmx:Runtime>

 <!-- EF Designer content (DO NOT EDIT MANUALLY BELOW HERE) -->

 <edmx:Designer xmlns="schemas.microsoft.com/.../edmx">

   <edmx:Connection>

     <DesignerInfoPropertySet>

       <DesignerProperty Name="MetadataArtifactProcessing" Value="EmbedInOutputAssembly" />

     </DesignerInfoPropertySet>

   </edmx:Connection>

   <edmx:Options>

     <DesignerInfoPropertySet>

       <DesignerProperty Name="ValidateOnBuild" Value="true" />

     </DesignerInfoPropertySet>

   </edmx:Options>

   <!-- Diagram content (shape and connector positions) -->

   <edmx:Diagrams>

     <Diagram Name="SgiModel" ZoomLevel="114" >

       <EntityTypeShape EntityType="dbsgiModel.Area" Width="1.5" PointX="0.75" PointY="7.375" Height="3.0714322916666674" />

       </Diagram></edmx:Diagrams>

 </edmx:Designer>

</edmx:Edmx>

Form

       private void button1_Click(object sender, EventArgs e)

       {

           Area area = new Area();

           dbsgiEntities db = new dbsgiEntities();

           int? maxlen = GetMaxlenght(db, area, "dc_area");

           textBox1.Text = maxlen.ToString();

       }

       /// <summary>

       ///

       /// </summary>

       /// <param name="context"></param>

       /// <param name="entity"></param>

       /// <param name="field"></param>

       /// <returns></returns>

       private static int GetMaxlenght(ObjectContext context, EntityObject entity, string field)

       {

           if (context != null && entity != null && !string.IsNullOrEmpty(field))

           {

               EntityContainer container;

               if (context.MetadataWorkspace.TryGetEntityContainer(context.DefaultContainerName, DataSpace.CSpace, out container))

               {

                   EntitySet entitySet;

                   if (container.TryGetEntitySetByName("Areas", false, out entitySet))

                   {

                       const string mlenght = "MaxLength";

                       if (entitySet.ElementType.Members.Contains(field) && entitySet.ElementType.Members[field].TypeUsage.Facets.Contains(mlenght))

                       {

                           object smaxlenght = entitySet.ElementType.Members[field].TypeUsage.Facets[mlenght].Value;

                           if (smaxlenght != null)

                           {

                               int maxlenght;

                               if (int.TryParse(smaxlenght.ToString(), out maxlenght))

                               {

                                   return maxlenght;

                               }

                           }

                       }

                   }

               }

           }

           return -1;

       }

# Luis said on Wednesday, June 9, 2010 2:51 PM

Hola, excelente planteamiento.

Estoy siguiendolo pero me pregunto como se podría abrir el documento sin tener que grabarlo en disco, desde memoria.

Podrías decirme algo?

Gracias y un saludo

# David said on Tuesday, September 21, 2010 6:46 PM

Yo programo en VFP 9, y he intentado en reiteradas ocasiones trabajar con .NET c#.

Es lento, aburrido, tedioso, quisquilloso y incompatible con él mismo. Se reinventa más que madona, supuestamente siempre a mejor.

En FOX puedo usar lo nuevo y lo viejo, desarrollar aplicaciones de gestión es un lujo con FOX y una tortura con NET, simplemente, NET es demasiado genérico, y FOX lo tiene todo en uno para hacer un desarrollo rapido, barato y compatible.

Espero que M$ saque por fin un .NET que realmente me enganche.

PD: Ahora a los .NET os intentan vender que useis Silverlight, que el entorno de formularios de NET no es sufiente... Buena suerte.

# Albert said on Wednesday, September 22, 2010 12:35 PM

Yo hasta ahora solamente he disfrutado de los 10 Mb que te da un ADSL pero necesito contratar fibra óptica, y llegar a los 100 Mb que prometen los operadores (que por otro lado, no estoy seguro de que sean reales). No se si en San Cugat puedo disponer ya de ese tipo de conexión ni quién lo ofrece. ¿Alguien lo sabe? Muchas gracias.

# ElleLawleit said on Thursday, September 23, 2010 5:49 AM

Deacuerdo en todo...

# Drac said on Thursday, September 23, 2010 8:21 PM

Albert, en Sant Cugat Movistar Futura te da los 100 megas que pides. Yo que tú ni me  lo pensaba. Es un servicio cojonudo. Incluye Imagenio HD, videoclub en alta definición,  DVR para grabar 160 gigas, lo último en adaptadores wifi...

Si kieres + info, aquí la encontrarás: www.movistar.es/.../index.html

# Juan Irigoyen said on Sunday, October 17, 2010 5:00 PM

@Pablo, el control de reviones lo podrias hacer como un hash y comparando, aunque una forma mucho mas facil seria crear un trigger en la tabla de manera que cada actualización del registro (INSERT, UPDATE, DELETED) genere un registro en una tabla similar de historicos y guarde la copia del registro, de esta forma con un simple trigger podrias montar el control de versiones, para las busquedas e indexación te aconsejo que leas geeks.ms/.../streaming-de-libros-parte-2-indexaci-243-n-con-full-text-search.aspx para tener una pequeña idea de como implementarlo.

Un saludo.

# Juan Irigoyen said on Sunday, October 17, 2010 5:07 PM

@Luis, quizas puedas resolverlo con algo así utilizando las librerias para web, aunque no lo he probado. Un saludo.

System.IO.MemoryStream mstream = GetData();

//Convert the memorystream to an array of bytes.

byte[] byteArray = mstream.ToArray();

//Clean up the memory stream

mstream.Flush();

mstream.Close();

// Clear all content output from the buffer stream

context.Response.Clear();

// Add a HTTP header to the output stream that specifies the default filename

// for the browser's download dialog

context.Response.AddHeader("Content-Disposition", "attachment; filename="+context.Request.Form["txtFileName"].ToString());

// Add a HTTP header to the output stream that contains the

// content length(File Size). This lets the browser know how much data is being transfered

context.Response.AddHeader("Content-Length", byteArray.Length.ToString());

// Set the HTTP MIME type of the output stream

context.Response.ContentType = "application/octet-stream";

// Write the data out to the client.

context.Response.BinaryWrite(byteArray);

# Juan Irigoyen said on Sunday, October 17, 2010 5:14 PM

@Omar, te equivocas, el ejemplo anterior devuelve los hijos de todos los nodos, es recursivo, pero todos los arboles tienen un nodo de partida este es el primer elemento en el puede colgar uno o varios hijos, pero siempre hay uno del que cuelgan los demas, si creas una pequeñas estructura como la anterior, podrás comprobarlo.

# Marcelo said on Sunday, October 24, 2010 4:16 PM

Muy bueno el post, se agradece.

# Un Experto said on Monday, November 22, 2010 8:27 PM

Soy un experto y opino que la gente no debe tener miedo a desarrollar en WPF, especialmente si se llaman Gabriel Alcocer.

# Ignacio said on Thursday, December 9, 2010 6:31 PM

Deduje, por favor.

# Juan Carlos said on Monday, February 21, 2011 4:43 AM

Excelente post, sobretodo me pare interesante la metodologia usada.

Adicionalmente me parecen muy bien definidas e intuitivas las interfaces de usuario.

Te felicito por la entrada.

# Sandra Molina said on Thursday, April 7, 2011 3:26 PM

Hola, mil felicitaciones y mil gracias por tu post. Haces un gran aporte.

Me encantó tu punto de vista! Si aprendemos de nuestros errores y no recaemos en ellos habremos fracasado con éxito... yo le agregaría el enseñar a otros a partir de nuestros fracasos.

Saludos desde Colombia

# Nestor said on Friday, May 27, 2011 5:12 PM

Excelente artículo, creo que si las empresas no están dispuestas a abrir sus "controles" para aumentar su productividad, es casi un deber nuestro proponer este tipo de prácticas.

Soy de latinoamerica y personalmente no conozco ninguna empresa que aplique este tipo de prácticas, y no sé hasta qué punto se deba a la "confianza" que tiene la empresa en sus empleados. Por que? Simple, podría pasar que los trabajadores abusen de la flexibilidad y su productividad baje... y mucho!

Que implica esto? Que no solamente la empresa debe ver esta oportunidad con mucha madurez, sino que nosotros como trabajadores debemos adoptar una posición muy madura ante esta práctica, permitiendo así que sea difunda cada vez más en nuestros países con costumbres laborales muy estrictas.

Un saludo!

# lontivero said on Friday, May 27, 2011 8:08 PM

Creo que es solo cuestión de tiempo hasta que todos en esta industria trabajemos desde casa. Los beneficios son claros; vos los describes muy bien.

# Rafael said on Saturday, May 28, 2011 6:30 PM

muy cierto lo que dices, en mi caso mi jefe tiene esa idea tambien, de poder trabajar desde casa, eso si la idea no es relajarse sino ser productivo y como lo mencionas se produce un buen ahorro y tambien sientes que confian en ti :D, saludos desde Lima, Perú

# Luis Guerrero said on Sunday, May 29, 2011 11:48 PM

Solo te diré www.ted.com/.../jason_fried_why_work_doesn_t_happen_at_work.html

# Juan Irigoyen said on Monday, May 30, 2011 9:22 AM

@Nextor, no estoy de acuerdo con lo que comentas, no comparto que tengas empleados eficientes y cuando pasas de un entorno controlado a uno que no lo es, observas que su índice de productividad baja, habría que preguntarse si realmente estos empleados son productivos, creo que si el empleado está motivado y sus jefes se encargan de situarle en un entorno adecuado siempre será más productivo, en caso contrario ‘quizás no fuese tan buen empleado como creíamos…’

Un saludo y gracias por tus comentarios.

@Lucas, desgraciadamente la mayoría de las empresas siguen prefiriendo los entornos controlados y muy pocas están cambiando, creo que todavía hace falta un cambio generacional, sobre todo a nivel de Dirección y Gerencia para que esto se pueda llevar a cabo de una forma más natural.

Un saludo.

@Rafael, si tu Jefe al menos se lo plantea, es que está intentando mejorar, es un buen principio.

Un saludo.

@Luis, solo te diré que me gustaría entender del todo, el discurso de Jason, ya que mi ingles no es muy bueno, aun así, de lo poco que he comprendido estoy de acuerdo en la mayoría de las cosas que dice, aunque su discurso está dedicado a trabajos creativos, yo creo que es fácilmente extensible a muchos otros trabajos, pienso también que no debemos aislarnos de nuestro entorno laboral, las reuniones bien planificadas, obtener diferentes puntos de vista de los compañeros, la ayuda de los jefes de proyecto que deben estar siempre informados de los problemas de sus compañeros, son muy necesarios, creo que todas deben complementarse. Incluso el entorno laboral será un factor de discusión porque habrá gente a la que trabajar fuera le suponga más distracciones que en su propio centro, pienso que cada caso es diferente y debe analizarse en detalle. Creo que debemos buscar el equilibrio intentando mezclar lo mejor de ambos entornos.

Un saludo.

# Jorge Serrano said on Monday, May 30, 2011 1:54 PM

Juan, estoy totalmente de acuerdo con tus afirmaciones aunque me gustaría puntualizar algo que no va en contra de lo que dices, simplemente lo complementa.

He trabajado en casa y en empresa (lógico).

Mi implicación cuando trabajaba en casa crecía enormemente, sin embargo, hay dos puntos que quiero resaltar.

- Hay empresas que valoran el trabajo a distancia pero "no se fían" completamente del trabajador. Es decir, asumen esa flexibilidad, la conocen y la ofrecen, es más,... la valoran como positiva, pero en realidad, como no te ven lo que estás haciendo, no terminan de fiarse del todo. Y esa desconfianza a veces se percibe y no como algo positivo. El resultado es que terminas saliendo de esa empresa porque no tienes porqué justificar toda tu implicación.

- Es necesario el calor humano. Es decir, indudablemente y pese a que se trabaje a distancia, es necesario disponer de reuniones, encuentros, etc., con el resto de compañeros que acompañen a no deshumanizar las relaciones.

Podemos llevarnos muy bien entre todos, pero si estamos metidos en un proyecto largo sin casi contacto (webcam, messenger, correo) es necesario hacer cada x días una quedada o pasarnos por la oficina central, o cualquier otra fórmula.

Estoy completamente a favor de lo que comentas, pero la implicación, confianza y responsabilidad no sólo tiene que llegar por la relación "Empleado => Empresa", sino también por la "Empresa => Empleado".

Si falla una de las dos, falla todo (implicación, confianza y responsabilidad), entra el desánimo y se echa a perder el asunto.

Sobre todo cuando se dan comparaciones del tipo "x, y, z curran más que a", etc.

Un saludo y buenas reflexiones.

Jorge

# Fernando G. Guerrero said on Monday, May 30, 2011 2:13 PM

Hola Juan,

Me ha gustado mucho tu análisis de este aspecto de la flexibilidad laboral.

De hecho, este es el modo en el que hemos trabajado en SolidQ desde que comenzamos hace 9 años.

Quizá pueda ser porque empezamos en USA, y fue más tarde cuando empezamos a operar en España. Pero la realidad es que de las casi 160 personas que formamos la empresa en todo el mundo, solo unas 10 ó 12 trabajamos regularmente en una oficina como tal, y de ellas la mitad solo pasan en esta oficina unas horas a la semana.

Basamos nuestras relaciones en la confianza mutua, y no en fichar entradas y salidas del trabajo.

Quizá sea este tipo de actitud el que nos haya permitido seguir creciendo incluso en tiempos de crisis, y que vayamos combatiendo el paro en España, incrementando nuestra plantilla mes a mes.

Enhorabuena por tu claridad de ideas.

Fernando

# Salvador Ramos said on Monday, May 30, 2011 2:33 PM

En primer lugar, te felicito por el artículo, queda muy bien expuesta la idea.

Yo trabajo en ese formato desde hace años, y ya casi no concibo otra forma de hacerlo :)

Saludos

Salvador Ramos

# @miguelEgea said on Monday, May 30, 2011 2:34 PM

Yo soy uno de los "empleados" de SolidQ,  ý me gustaría añadir que en épocas en las que está de moda la conciliación de vida laboral y familiar, este es un excelente mecanismo. Yo a veces no estoy trabajando a las 11 de la mañana, y si a las 2 de la madrugada, depende de mi, y hasta hoy, tras más de 6 años en Solid, cada dia que pasa estoy más convencido no solo de que es el futuro, sino además de que soy un tipo afortunado

# Luis Guerrero said on Monday, May 30, 2011 3:15 PM

Pues básicamente lo que dice la charla es que las empresas se aseguran de tener costosos centros de trabajo donde se supone que la gente va a trabajar, pero que normalmente si le preguntases a cualquier persona cual es el lugar de máxima productividad, muy pocas personas dirían que la oficina. También hablan de las reuniones sobre como roban el tiempo de la gente.

Saludos. Luis.

# Juan Irigoyen said on Monday, May 30, 2011 6:59 PM

@Jorge, estoy completamente de acuerdo con lo que dices, y podría añadir algo, también es necesario demostrar nuestro trabajo, no basta solo con trabajar desde casa, debemos enseñar que nuestros proyectos avanzan día a día, esto es relativamente fácil de realizar, con Scrum más aún, las reuniones del Sprint Review, permiten fácilmente realizar esta tarea, en cualquier caso coincido completamente con lo que dices, en mi caso tengo al menos una reunión cada 15 días y todos los días mantengo comunicación fluida con mi empresa a través de skype, aunque confieso que en algunos casos sería mejor no recibir ningún tipo de llamadas, al final corres el riesgo de que las interrupciones no disminuyan.

Coincido plenamente en que debe existir una relación cordial por las dos partes, es una cuestión de confianza, si una de las dos la pierde, no hay nada que hacer.

Sería fácil engañar a tu Jefe si este preguntase que has hecho hoy, en cambio desde una perspectiva mayor digamos 20 o 30 días si los avances no son claros, fácilmente se darán cuenta de que no hay avances y esto pondrá fin definitivamente a este tipo de prácticas, creo en resumen que el ‘control’ es relativamente fácil de realizar.

Un saludo.

# Juan Irigoyen said on Monday, May 30, 2011 7:04 PM

@Fernando. Muchas gracias por tus comentarios,  la última vez que hablamos erais 60 o 70 personas, es increíble vuestro crecimiento con la que está cayendo hoy en día.

Un saludo y ánimo, gestionar una empresa tan grande y que día a día vaya creciendo es un auténtico logro, mi enhorabuena.

@Salvador, Muchas gracias por tus comentarios.

@Miguel, con los posts tuyos que he leído sobre sql Server, casi te conozco como si estuvieras aquí. :)

Es triste decirlo, pero sí que somos afortunados, me gustaría en poco tiempo que muchos más pudieran trabajar de esta forma, aunque si te soy sincero creo que hace falta un cambio generacional, muchas empresas tendrán que cerrar por desaprovechar recursos como estos y muchos gerentes deberán caer y replantearse su gestión para que estos cambios se lleven a cabo.

Un saludo.

@Luis, muchas gracias por el resumen, sobre todo para aquellos que no saben ingles… :)

Un cordial saludo.

# Alberto López Grande said on Monday, May 30, 2011 11:15 PM

Dos comentarios. El primero, reiterar lo ya dicho por los compañeros, muy buen post. Y más en los tiempos que tenemos.

Cosas simples, de sentido común, pero que parece que el que las pone en práctica es un iluminado temerario e inconsciente. La pregunta clave es "¿Sabré yo trabajar a mi aire y a mi ritmo?". Por lo que conozco, la mayoría de las personas con las que yo trabajo, no pueden, de hecho lo demuestran a diario. Son esas mismas personas que creen que es productiva una reunión de 12 personas o que aprovechan cada vez que el jefe se da la vuelta para escaquearse.

Mi horario es totalmente flexible, puedo quedarme trabajando todo lo tarde quiera en la oficina, no me llega nadie a decir, "Alberto, vete ya para casa, que ya está bien por hoy". Y luego, cuando por fin llego (ya de noche, claro), puedo seguir trabajando desde casa. Incluso fines de semana, madrugadas, o cuando un niño se me pone malo y no puedo ir a la oficina. Y no sólo desde casa, desde cualquier lugar con un mínimo de conexión a internet (para eso me dieron un portátil). Todo flexible, lo mejor de los dos mundos. La cercanía y el roce de la oficina y la "libertad" del teletrabajo.

¿Sabría yo adaptarme a trabajar sin pasar por la oficina? Creo que sí, lo hago cada vez que tengo vacaciones... Luego dicen que no hay trabajo.

# Juan Irigoyen said on Tuesday, May 31, 2011 12:32 AM

@Alberto, me veo bastante reflejado con lo que dices, yo acostumbro a trabajar así muchas veces, creo que si evitas las interrupciones y distracciones, eliminas las barreras del tiempo, tu productividad aumentara, está claro que tienes sobradas aptitudes para sacarle partido.

Un saludo y gracias por tus comentarios.

# glopez said on Wednesday, June 1, 2011 12:14 PM

@Juan, el vídeo que comenta @Luis está disponible con subtitulos, vale la pena verlo: www.ted.com/.../jason_fried_why_work_doesn_t_happen_at_work.html

Por cierto, buen artículo!

Un saludo.

# Expatriado said on Wednesday, June 1, 2011 4:03 PM

La productividad es la relacion entre el PIB y las horas trabajadas. Mientras España no produzca bienes de alto valor añadido (como automóviles, trenes, computadores, maquinaria, etc) el PIB será bajo, y el indicador de productividad también; por muy "productivos" que seamos, si lo somos generando frutas y hortalizas, nunca alcanzaremos un alto valor de productividad como país, trabajemos donde trabajemos.

# Juan Irigoyen said on Wednesday, June 1, 2011 8:26 PM

@glopez, muchas gracias. Un saludo.

# Juan Irigoyen said on Wednesday, June 1, 2011 8:49 PM

@expratriado, La productividad es la relación entre la producción obtenida por un sistema productivo y los recursos utilizados para obtener dicha producción, según la definición en la Wikipedia, en nuestro caso, creo que el software puede aportar un gran valor, no hay más que ver el número de grandes empresa que forman parte de este sector, existen también otras áreas que generan gran valor y las olvidamos, ¿cuántos recursos dedicamos a I+D?, hay compañías que superan con creces el número de patentes españolas al año, no dedicamos prácticamente nada a investigación, no hay más que ver noticias tipo a esta www.europapress.es/.../noticia-polemica-barbacid-versus-garmendia-llega-science-20110511142548.html

Si es que da la risa, yo creo que el problema es de todos y los españoles desgraciadamente no sabemos trabajar, en general somos muy poco profesionales acostumbrados a vivir del cuento, no hay más que ver como Belén Esteban es capaz de ganar 2 millones de euros al año y como millones de Españoles se pasan el día viéndola por televisión, es triste y penoso y esto es lo que estamos empezando a pagar ahora.

Hay sectores sobre todo los de la construcción en los que no he conocido a un solo profesional a lo largo de toda mi vida, incluso si lo extendemos a otras profesiones: abogados, banqueros, periodistas, restauración, funcionarios, políticos, etc, joder, pero si la mayoría son todos unos chorizos que viven del cuento, me gustaría conocer cuál es el porcentaje real de profesionales, no creo que sea mayor 1/1000.

Y este es el problema real, que produzcamos coches, software, realicemos patentes o plantemos aguacates no es el problema, el problema es que no sabemos hacerlo bien.

# Rodrigo Corral said on Thursday, June 2, 2011 11:02 AM

Buen artículo Juan.

Yo creo que cada vez somos más la empresas que estamos girando a ese modelo o incluso que son el único que conocemos.

En Plain Concepts tenemos gente trabajando en Paris, Londres, Seattle, León, Madrid, Bilbao... Los horarios nos se controlan más allá de hacer posible la operativa y la coordinación, cuando alguien decide trabajar en su casa nadie pone pegas...

Esto es posible por que nuestros trabajadores son gente apasionada por lo que hacer y comprometida con su trabajo. No van a trabajar más por que yo este con un latigo dándoles, eso lo entiende cualquiera.

Salvo muy contadas excepciones todo el mundo responde y obtiene resultados. Los casos que han abusado de este sistema no son relevantes, hubiesen abusado de cualquier otro.

¡Un saludo!

# Juan Irigoyen said on Thursday, June 2, 2011 1:28 PM

@Rodrigo, estoy completamente deacuerdo, pienso que el planteamiendo de intentar basar el trabajo en el compromiso mutuo y la confianza es la única via para llegar a ser verdaderamente productivos,

asi lo demostrais aquellos que trabajais en empresas basadas en estos valores, no hay mas que observar vuestro crecimiento en tan poco tiempo, los hechos hablan por si mismos.

Los casos de abuso se detectan rapidamente, el trabajo realizado siempre refleja estas actitudes.

Un saludo.

# Lluis Franco said on Friday, August 19, 2011 4:59 PM

:-)

Hola Juan,

Complementando tu post:

Editar documentos almacenados como array de bits en SQL Server [FileStream] (3/n):

geeks.ms/.../editar-documentos-almacenados-como-array-de-bits-en-sql-server-filestream-3-n.aspx

Un saludo artista,

# Soren said on Wednesday, August 29, 2012 9:31 PM

Sin duda es la línea que se debe seguir. Realmente lo que planteas son historias de usuario.

es.wikipedia.org/.../Historias_de_usuario

Si además las plasmas en pruebas de aceptación lo bordas.

# Juan Irigoyen said on Thursday, August 30, 2012 1:57 AM

En este post yo hablo del backlog por que entiendo que en el backlog se introducen todas las tareas, no solo las procedentes de historias de usuario, que en principio podrían ser mas o menos sencillas y que podrían descomponerse en pequeñas tareas que conforman el backlog, sino de los bugs y mejoras que puedan surgir a lo largo del proceso de desarrollo que pueden ser introducidas por el cliente o por el propio equipo de desarrollo y que además permiten realizar el seguimiento de cada una de ellas, entiendo que el backlog recoge toda la información sobre todas las tareas que conforman el proyecto y por ello la idea de compartirlo con el cliente e intentar que participe en su gestión.

Un saludo y gracias por comentar.

# Eduardo Obregón Gutierrez said on Thursday, January 10, 2013 7:51 AM

Gracias a ti Juan por todo lo que me has enseñado, por encima de tecnologías, a aprender a solucionar problemas, sin duda he sido un privilegiado de estar estos años trabajando contigo.

# Rodrigo Corral said on Thursday, January 10, 2013 11:46 AM

Enhorabuena Juan!!!! Aunque no haya sido un camino de rosas los que te conocemos sabemos el empeño y buen hacer que has puesto en este proyecto.

Un saludo.

# Juan Irigoyen said on Thursday, January 10, 2013 1:06 PM

@Edu, se que en el fondo de tu corazón me odias profundamente, pero aunque sea todo mentira y te hayas visto obligado, te agradezco tu comentario. :)

# Juan Irigoyen said on Thursday, January 10, 2013 1:08 PM

@Rodrigo, te agradezco tu confianza, sobre todo viniendo de ti.

Un cordial saludo.

# Jose Luis said on Thursday, January 10, 2013 2:27 PM

Joder, impresionte!!! el trabajo que habéis realizado, una pregunta, en el modelo de entidades que utilizáis como generáis las entidades, ¿ las escribís una a una ?

# Juan Irigoyen said on Thursday, January 10, 2013 5:00 PM

Para generar las entidades creamos un generador basado en codedom, puedes mirar en otro post que escribi hace tiempo acerca de esto geeks.ms/.../maldivas-arquitectura-2-entidades-y-reflexi-243-n.aspx, en cualquier caso lo hicimos porque en su día no disponiamos de Entity FrameWork, hoy en día puedes generar entidades Poco facilmente utilizando este gestor, que te proporcionara grandes ventajas frente a un modelo de datos como el nuestro.

Un saludo y gracias por comentar.

# El Bruno said on Monday, January 14, 2013 10:46 AM

@juan, en 1er lugar felicitaciones, siempre es un placer leer a gente que escribe sobre como un equipo de trabajo mejora día a día :D

en 2do lugar, felicitaciones again !!! ^^

Salu2

# Juan Irigoyen said on Monday, January 14, 2013 6:30 PM

@Bruno, muchas gracias por tus comentarios.

Un saludo.

# Kiquenet said on Wednesday, January 16, 2013 3:36 PM

Enhorabuena,una visión muy completa del desarrollo y su evolución en el tiempo.

Técnicamente muy variado, VS 2012, utilidades como FxCop, ReSharer, CodeRush, Stylecop, Pex and Molex, Visual Studio for Database Developers, TFS,  Devexpress, Sql Server , IIS 7

CodeDom (geeks.ms/.../maldivas-arquitectura-2-entidades-y-reflexi-243-n.aspx)

programación asíncrona, paralelización, cache, Servicios Windows, Servicios web, Linq, Serialización de archivos, etc.

Se agradecerán artículos de detalles técnicos, da sin duda, una visión muy completa.

Saludos.

# Juan Irigoyen said on Thursday, January 17, 2013 3:30 PM

@Kinetic, gracias por tus comentarios, he hablado en algunos post anteriores sobre algunas partes de la Arquitectura de Maldivas, sin embargo debido a que nuestro modelo de datos es propio y fue desarrollado en una época en la que solo podías utilizar arquitecturas basadas en Ado 2.0 o herramientas de terceros como n-Hybernate, no he querido hablar en detalle de la aplicación, pues nuestra capa de negocios esta acoplada a nuestra capa de datos y no me gustaría confundir a los lectores con estos detalles. Tengo pensado realizar algún post sobre algunos módulos interesantes que hemos desarrollado como el ‘Scheduler’ que permite configurar envíos de información recurrente a diferentes destinatarios como informes de ventas, avisos, estadísticas, tarifas, etc.

Un saludo.

# Kiquenet said on Friday, January 18, 2013 1:55 PM

Creo que la orientación más útil en mi opinión tiene que ir por esta vía de Iván Freire, geeks.ms/.../default.aspx

Lástima no continuara con sus interesantes posts técnicos. Sería muy instructivo y de visión general.

# Juan Irigoyen said on Saturday, January 19, 2013 1:13 PM

@Kinetic, yo no creo en los Framework Generalistas, se deben valorar mucho dependencias, nosotros desarrollamos Maldivas para dar solución a un sistema y unas necesidades muy concretas, el atarnos a diferentes herramientas aunque sean libres y gratuitas tiene su riesgos, en este caso apostamos por utilizar el FrameWork de .NET y un desarrollo propio.

Te aconsejo la lecturas de estos dos post, donde se habla de este tema a consecuencia de un comentario de Julio Trujillo:

geeks.ms/.../maldivas-arquitectura-1-el-sentido-com-250-n.aspx

geeks.ms/.../el-requeteframework.aspx

Un saludo.

# LFLOPEZ said on Tuesday, May 28, 2013 7:24 PM

Hola buena tarde. estoy analizando el ejemplo que publicas y me parece super interesante, pero hay algo que no logro entender, qué es ManagerBI<Formas_pago> Formas_pago me imagino que es un campo (un textbox) y qué es ManagerBI o como se declara o de dónde proviene. Expreso mis agradecimientos por la colaboración prestada.

# Juan Irigoyen said on Monday, November 18, 2013 4:12 PM

Forms_pago es un entidad de nuestro modelo de datos, como puede ser clientes, articulo o cualquier otra, es un simple ejemplo y refleja el nombre de la entidad, que en este caso se corresponde a una clase. ManagerBI es un clase genérica que permite que cualquier entidad pueda añadir, borrar o buscar registros, esto se puede desarrollar con EF o cualquier modelo de datos actual.

# make money from home said on Tuesday, November 18, 2014 1:49 PM

VisualStudio.com is down - El blog de Juan Irigoyen en Geeks·ms