La masa, el ladrillo, la bota, el bocadillo...

Tenía pensado empezar este post con una serie de frases míticas del titán y vecino de blog R.Corral como...

Tu abuela te debía hacer unos buenos pantalones :-)

Tiene razón es el tema de la tela, pero muchas veces es difícil hacerlo ver..y se va a "lo seguro" lo que se ha hecho siempre, pero que bien o mal, más bien mal,  ha ido para adelante...

He encontrado de casualidad una de esas joyas que están ocultas entre la maraña de descargas que Microsoft...

Todos hemos tenido diferentes particiones en el HD con varios sistemas operativos, antiguamente con el...

Que buenos links!

Sobre todo el de RUP, viene con un link de demo que incluye la creación del Team Project en Visual Studio: http://www.osellus.com/documents/presentations/rup-vsts-presentation.html.

Saludos,

Estoy de acuerdo en que la extensibilidad es un valor muy importante, sobre todo para adaptarse a las peculiaridades de cada empresa y a su manera de funcionar.

Aún así, creo hay que cogerlo con precaución esta característica. Si para implantarlo es necesario realizar muchos desarrollos a medida, no creo que sea positivo.

coincido con el comentario anterior ...
de acuerdo al tipo de proyecto y a lo q se espere del mismo, hay q tener mucho cuidado en ponerse a desarrollar "extensiones" de VSTS para ser utilizadas solo un par de veces ...


aunq la tentacion suele ser grandisima !!!!

jejeje

Saludos y felicitaciones por el Blog

Uno de los puntos en los que más fallan los desarrolladores noveles es a la hora de trabajar con excepciones....

muy bueno Rodrigo la serie que estas realizando sobre excepciones.

Felicidadesy continua asi.

Je, je. La parte .NET me suena muuuuuuuuucho.

Tendrías que poner un dia un post sobre la cantidad de código que tienes que escribir en diferentes lenguajes para hacer lo mismo...
Si alguien quiere probarlo, que trate de enviar un SMS con las API nativas de Windows Mobile y despues que lo haga en CF 2.0 con WM 5.0 de unas 20 lineas en C++ a 2 con .NET

Pues aqui (http://shootout.alioth.debian.org/gp4/index.php) puedes ver una comparativa de lineas de codigo y de perfomance en algunos lenguajes ....

aunq solo se usa el Fwk.Net de Mono :s

Saludos

No comprendi la importacia de ordenar los namespaces, y una pequeña correccion imports es de vb, using es de C#

pues si es cuestion de orden, es como de gustos ... dificil ponerse de acuerdo, pero yo m acuerdo de mis addins de VB6 q me ordenaban las funciones de una clase alfabeticamente y es mas (me habia currado no se d donde sacaba tiempo) una rutina q me tabulaba estilo tabla los Dim var as tipo ...

ahora a probar el AddIn de Nicole !!!

Saludos

Team Foundation Server Administration Tool es una herramienta que permite a los administradores de Team...

Un error en el que los programadores solemos caer es escribir manejadores de excepciones ‘genéricos’,...

Una de las primeras cosas que necesitamos saber en cuanto empezamos a programar o a utilizar un nuevo...

Pues ... la verdad q esta muy bien ... pero hasta hace 2 semanitas un poco verde ... tenia excepciones por todos lados ...
aunq lo bueno de "poder participar" es q podemos arreglar esas excepciones !!!


Saludos

Ya he hablado antes en este blog de la importancia de los patrones y las buenas practicas.
Todo el que...

No he borrado el registro pero si desctivado desde el visual studio, y el problema continua, necesariamente debo borrar el registro?....

Palabra de Dios. Totalmente de de acuerdo con tu postura pero, ¿que pasa si el proyecto que has desarrollado pasa a manos de otro equipo de desarrollo? ¿Deberian de leerse el código para entender lo que se está haciendo? Eso me suena a inviable. Quizas yo propondía la creación y almacenaje de pequeñas historias (como propone la XP) que expliquen el objetivo del programador aunque no siempre encaje con la version final. Esto ahorraría cientos de horas de mirar código. ¿No te parece?

Saludos

En mi opinión, el código es la única fuente de verdad sobre un proyecto de software a nivel de detalle....

eso que as dicho es una autentica chorrada, el código no es tan importante en proyectos grandes

(Esto empezó siendo un comentario a un post de Rodrigo)
En eso estamos…. Vamos que no me gusta el UML,...

He de reconocer que las matizaciones que haces en este segundo post me han dejado bastante satisfecho. Estoy de acuerdo que la documentación a un nivel de abstracción muy bajo sólo sirve si se puede mantener con facilidad, y que la arquitectura y las especificaciones son válidas siempre que se manejen a un nivel de abstracción que permita mantenerlos actualizados. También estoy de acuerdo en que UML sin duda está sobrevalorado, pero sin embargo, sigo pensando que tener un lenguaje común es en general, bueno... y UML, hoy por hoy, es lo mejor que tenemos. Tal vez sería aún mejor si no fuese una herramienta que unos cuantos utilizan para vender más y más libros ;-). De hecho yo daría la vuelta a tu razonamiento y te preguntaría... ¿qué le falta a UML para que Microsoft haya tenido que inventar algo adicional?

Sin embargo, hay un punto, amigo mío... que no mencionas en tus posts, y es la documentación que se genera durante el "business modelling", y que es puramente conceptual. En esta documentación, en la que básicamente expresas cuales son las clases del negocio y las relaciones que existen entre sí... hay temas de la estructura estática que se DEBEN expresar, y que además son inmutables (por ejemplo, de alguna forma debo "capturar" que en el dominio de la aplicación, un "documento T10" es un tipo de documento financiero, y que todos estos se almacenan en el "perfil" de un "contribuyente"). Cierto es que puedo escribir todo esto, pero lo puedo expresar sin ninguna ambiguedad con un diagrama de clases UML... y además es inmutable. Dices que todos tenemos una capacidad innata de dibujar, pero ya me gustaría a mi ver qué distintos clasificadores aparecen por ahí para referirse a relaciones del estilo "es un tipo de" o "contiene otros elementos" que con UML no me tengo que esforzar en pensar (una vez aprendido, me "salen" los simbilillos de generalización o agregación). El lenguaje gestual es innato, pero sin duda el lenguaje castellano es mucho menos ambiguo y más rico, aunque sea necesario un proceso de aprendizaje.

Con los casos de uso, sólo puedo decirte que un caso de uso, para mi al menos, es la descripción textual... que va acompañada de un dibujo (y no al revés). De hecho así es como los definió Jacobson. No creo que la diagramación pretenda sustituir a las descripciones textuales. Lo único que puedo achacar a UML es que no defina cómo deben ser estas descripciones. Precisamente para ver la utilidad de UML, sólo tienes que ver la cantidad de opiniones diversas que hay sobre cómo debe escribirse un caso de uso... donde hay un "vacío" de normas hay un "lleno" de discusiones bizantinas sobre cómo se debe homogeneizar la forma de realizar esa labor. Todo el mundo discuto cosas como "cómo numerar los casos de uso", "cómo elegir el escenario principal de un caso CRUD", o "si se debe especificar la condiciíon de activación como un apartado diferente al propio primer paso de un caso de uso". Personalmente pienso que la respuesta a estas preguntas es "DA IGUAL MIENTRAS SE ENTIENDA"... el problema es la cantidad de tiempo que se pierde discutiendo sobre cual es la forma idónea de hacerlo, mientras que cuando algo es estándar y universalmente aceptado, nadie lo discute. No creo que nadie pierda el tiempo discutiendo si la generalización se debe representar con un triangulito o con un cuadradito... ¿no? Pues esa, y sólo esa, es la grandeza del UML.

Por último me ha parecido entender que opinas que el UML tiende a encorsetarte. Bueno, en este caso sólo puedo decirte que sólo a quien no conoce lo que es el UML le puede llegar a encorsetar: aquel "novato" (con todo el cariño) que tiene que meter una secuencia por narices, porque ha entendido que todo proceso de la aplicación debe estar documentado con una secuencia. Evidentemente quien haga eso pierde el tiempo... porque cuando termine de escribirlo ya estará desfasado (y probablemente tarde siglos en empezar a escribir código, si es que alguna vez empieza). Sin embargo vuelvo al punto de la abstracción: seguro que hay procesos importantes cuya vista dinámica es importante especificar. Podría usarse un diagrama de flujo, o pseudocódigo o lo que sea (de hecho, me parece aceptable cualquiera de las tres opciones). Sin embargo una secuencia (o un diagrama de colaboración, según le guste a cada cual) tiene la ventaja de que se puede especificar con un montón de herramientas CASE (aunque sólo sea porque queda más limpio que el pseudocódigo escrito en una servilleta del "Bar Pepe") y que asegura al menos en gran parte la no ambiguedad de la especificación.

Por último, esta es una opinión muy personal... pero a mi el UML me parece bastante natural de comprender, y no creo que la curva de aprendizaje sea muy pronunciada. Vamos, a no ser que tengas profesores francamente malos, o te dejes llevar por la cantidad de autores que han decidido enriquecerse escribiendo pomposos libros sobre "el UML" (lo pongo entre comillas porque la verdad es que me da verdadera vergüenza ajena ver la cantidad de cenutrios que aseguran "te van a enseñar a diseñar, porque vas a aprender UML"). Qué descojono, es como si te vendiesen las clases del abecedario del jardin de infancia como un curso de poesía.

Business Modeling no es lo mismo que captura de requisitos... trata de definir sin ambiguedad patrones empresariales por medio de literatura escrita, sin que el lector necesite drogas para poder leerlo (y asimilarlo). Cuidado, que no estoy diciendo que TODOS los requisitos deban partir del business modeling... evidentemente las "personas" de Team System (todavía estoy esperando que me cuenten qué aportan sobre los casos de uso) son una herramienta estupenda para especificar. Sin embargo, el business modeling es una excelente forma de documentar las reglas de negocio sobre las que iniciar el análisis de una aplicación. Estan muchísimo antes que la especificación. Por cierto, que el UML no es un campo exclusivo de informáticos... los analistas de negocio usan UML para documentar procesos empresariales (aunque es cierto que hay lenguajes específicos al dominio... pero UML puede ser común a los analistas del negocio y a los desarrolladores de aplicaciones, de ahí su ventaja y su nombre de "universal").

En cuanto a las posibilidades de extender el UML, yo las veo bastante claras por medio de los estereotipos (por ejemplo, ver http://www.phptr.com/articles/article.asp?p=29454&rl=1 )

En cuanto a lo que dices de que "En cuanto al tiempo discutiendo la notación, no exite, quien recibe un documento es quien juzga si lo puede entender o no", es igualmente aplicable a cualquier documento "ad hoc" escrito por cualquiera, y depende, además del lenguaje, del receptor del mensaje. UML será mejor si el receptor es informático, y en ese caso evita discusiones del estilo... "el cuadradito al lado del otro cuadradito, es una clase que hereda?", "¿y qué significa ese bicho que has dibujado con forma de mosca? Coño, no,... que es una mosca". De ahí que digo que es menos ambiguo (evidentemente, nada es TOTALMENTE carente de ambiguedad... nos ha jodio). Si el receptor es "no informático", entonces me temo que muchos de los mensajes no los entenderá, independientemente del lenguaje.

Que gresca se ha montado con esto ¿no? ... yo lo veo de una forma más sencilla que todo esto, UML no sirva para documentar un proyecto, solamente sirva para expresar ciertas partes de la documentación.

Con el paraguas abierto espero las  hostias.....

Unai

yo estoy de acuerdo con Unai, que uml es una parte de la documentacion y como ya exprese en otro post (http://geeks.ms/blogs/csegura/archive/2006/06/20/526.aspx#comments) creo que solo valido para proyectos grandes con  donde podemos encontrar diferentes roles..

hay ciertos debates en los que por regla general siempre se discute sin llegar a un consenso.. por ejemplo las sql en store o en el codigo de la capa de datos o no hacemos 3 capas y hacemos 2 o todo en una .. o no hacemos nada :D

PAZ

Vaya con la tontería, de un plumazo ahorra un 25% de tráfico. Que pijada más ingeniosa.

No lo conocía, pero es muy interesante. Todos los intentos por aligerar XML están bien, sobre todo para agilizar las interfaces web. En el futuro, y ahora mismo, la tendencia es llevar la funcionalidad de una IU tradicional a la web, por lo que hacen falta iniciativas así. Y otras como WPF y WPF/E que darán que hablar para esto.

Justamente tengo un problema de este tipo en una migración de una dll a 64 bits, no se si usted me pudiera ayudar a resolverlo porque aun haciendo la recomendación que dices, no lo he resuelto.
Mi mail es: j.gutierrez.rivera@accenture.com

Muchas Gracias

Yahoo libero hace poco los suyos, mrece la pena ver:
http://developer.yahoo.com/ypatterns/index.php

últimamente, mucha gente me está preguntando como puede llevar código escrito en Visual C++ a la web....

Me parece increíble que nadie te haya respondido... ¿quién no ha entrado en una reunión de trabajo sea del tipo que sea (seguimiento, arquitectura, proyecto, cliente,...) y se ha terminado haciendo un dibujito en un papel?.
Lo bueno de la pizarra como bien apuntas y como ya sabes que coincidimos, es que permite que cada uno haga su copia, o en su defecto, se haga una fotografía que podría ser enviada vía e-mail o anexada al documento o acta que se elabore de la reunión.
Yo desde luego creo que es fundamental trabajar con una pizarra. Tanto es así, que en un SIMO ví un artilugio para escribir en la pizarra, imprimir su contenido o enviarlo por e-mail. Era un prototipo, pero no os extrañe que de aquí a poco tiempo sea un utensilio muy común. Al menos Rodrigo se ha adelantado añadiéndolo a la lista de los 4 elementos, ahora por fin, tenemos claro el quinto elemento.

¿Que es Buildix?Pues es una distribución Linux, basada en Knoppix, a la que se han eliminado un motón...

La verdad que soy un aficionado a las pizarras y hacer ciento de dibujos y diagramas en las reuniones, pero nunca me había parado a pensar lo importante que podían ser.

Estoy contigo, las pizarras son importantes, pero sin olvidar que debe existir documentación escrita...que seguro que más de uno se reune, hace sus "dibujos" y ya está, definición hecha.

Qué sería de nosotros sin una pizarra!!! Será el regalo estrella estas navidades :-)

¡Mucha suerte campeón!, y no te olvides de llevar la pizarra. :-)))

¡¡¡ENHORABUENA campeón!!!

¡¡¡Mis felicitaciones "profe"!!! :-)

Felicitaciones MCT!!

Felicidades maestro!!

Aupa Rodrigo!

Vaya pedazo de "Profe" que vamos a tener!!

Enhorabuena!!

Lo que vamos a tener que aguantar ahora!!!! .... buff si ya era dificil antes :-)

Ya era hora!!! :-)
Felicitaciones, Don Rodrigo

Pues eso, una tontería, pero como veo que compañero en campusMVP y buen amigo Rodrigo Corral también...

Mucho MVP, MCT, pero al mus... NPI. (De F1 y  pelota ni hablamos, claro).

Felicidades mojtruo!!!

hola!

felicidades Rodrigo!, pero como tocan los bowling con... la pelota. jajaja!

agur!

Rodrigo:

Desde mi punto de vista esto puede servir también para otra cosa: seleccionar qué características de un producto decidimos desarrollar antes, cosa muy importante a veces cuando hay exceso de ideas... y tan importante como el objeto original de Motion.

Por cierto, gracias por la referencia :-)

Un abrazo

Jose.

Ya tenemos Release Candidate de Iron Python, la implementación sobre .net del lenguaje de moda, Python....

"Los diagramas no son lo importante", es la frase que tengo en la mente después de leer UML: Casos de...

"Los diagramas no son lo importante", es la frase que tengo en la mente después de leer UML: Casos de...

"Los diagramas no son lo importante", es la frase que tengo en la mente después de leer UML: Casos de...

"Los diagramas no son lo importante", es la frase que tengo en la mente después de leer UML: Casos de...

Felicitaciones Rodrigo!

Auque te conozco desde hace pocos meses, sirves como ejemplo para muchos, para los que recién estan dando sus primeros pasos, y sobretodo para saber nunca es suficiente con lo sabes, y siempre tienes que saber más.

Saludos,

Unos te conocen desde hace unos meses, y otros desde hace unos días.

Felicidades!!!!

El viernes estuve en los Cursos de Verano de la Universidad Pública de Navarra, hablando sobre Team System...

PingBack from http://www.radamanto.com/blog/?p=14

Hola Rodrigo,
Excelente análisis, y estoy de acuerdo contigo en muchos aspectos, excepto en uno, que para mi es muy importante: conocimiento es universal y tiene que ser compartido con todo el mundo.
Lo que comentas de "... outsourcing no es interesante desde mi punto de vista, (por)que los que aprenden son otros..." es una idea que no comparto. Si cada persona mantuviera sus conocimientos para si mismo, nunca habríamos evolucionado como "seres humanos" como lo hemos hecho hasta ahora. La idea de sitios como el que yo mantengo (http://www.gavd.net/servers) con información sobre SharePoint, es precisamente esa: compartir la información que yo tengo o puedo adquirir con las personas que no la tienen. Por otro lado, entre mas personas tienen un determinado conocimiento de algo, a mas personas se le ocurrirán nuevas e innovativas formas de hacer cosas, y todos aprenderemos un poquito mas cada vez.
Y, finalmente, no quiero ni pensar en el momento en que tenga que tener miedo a alguien que sepa mas que yo. Como dice el poema ("Desiderata", del tiempo de viejos hippies, como yo), "...for always there will be greater and lesser persons than yourself...", y si alguien puede hacer algo mejor que yo, estaré contento de aprender de ella/el...
Un saludo cordial,
Gustavo

Tengo que decir que en la mayoría de los casos, como bien dices, es muy dificil ser un buen programador si no cumples tres requisitos que a mi entender son indispensables:

Pasión por lo que haces.
Años de experiencia creando código a tus espaldas.
Y sentido crítico a tu propio trabajo.

Todo se puede mejorar, no existe la solución perfecta y eso lo debemos tener siempre presente.

A quien no le ha pasado que al ver código escrito por el varios años atrás (o incluso meses) a pensado, ¿cómo puedo haber escrito esto?

Otra cosa muy distinta es el potencial para poder llegar a ser un buen programador, esto también es un problema de estimación de tiempo y que muchas veces se confunde con lo primero.

Veo que todo lo que comentáis está bien, pero la realidad suele ser mucho más duro.

Estamos hablando de malos análisis o de estimación erróneas, pero el principal problema es que no hay muchos programadores buenos. Es un bien bastante escado y pocas veces valorado. Cuesta mucho encontrar gente preparada y buena para los proyectos. Sí, hay mucha gente, gente que más o menos va cumpliendo, pero no cualquier programador te puede hacer una estimación correcta o un análisis/diseño.

El responsable de proyectos debe conocer a su grupo de trabajo, conocerlos bien, sabiendo sus puntos débiles y fuertes, y así podrá saber hasta dónde puede llegar cada uno.

Por cierto, no quita que esté de acuerdo con la mayoría de los puntos que se han comentando.

Uno de los puntos que ha parecido muy interesante es de "Pasión por lo que haces". Seguro que todos conocéis a más de uno para el cual una vez que suena la sirena, la informática deja de existir o que considera "hablar de trabajo" al hecho de hablar de algo relacionado con informática.

A mí no sería la primera persona que me lo dice :-)

o como dijo Libertad de Mafalda ...

"una pulga no puede detener una locomotora, pero puede llenar de ronchas al maquinista"

yo creo que siempre hay soluciones (salvo para la cuadratura del circulo), y que es mejor afrontar un problema con una solucion (que tal vez este errada) que simplemente quejarse y no hacer nada al respecto.

Interesante punto de vista :D

Saludos

Para los que no tengan Team System, VersionOne tiene una aplicación ASP.NET para gestionar proyectos scrum que es gratuita para equipos de hasta 5 miembros (http://www.versionone.net/scrum.asp).

Bueno, me parece que no haz tenido exito con UML, o que no sabes usarlo, es verdad hay en internet y existen tantos libros impresos que tratan de enseñar UML, pero al final lo que se obtiene es personas mas y cada vez mas confundidas sobre el tema.

UML es la notación estándar aqui y en la china, y si sabes utilizarlo podrás desarrollar proyectos rápidos y a tiempo.

Espero que cuando hayas entendido UML, te rectifiques, Saludos.....

Pero luego cuidado con el SP1 de Sql2005, que por defecto deja inutilizables servicios como el SSIS ...
Saludos.

Por lo menos podias mencionar quien te lo compró... :-) :-)

Anotado como un Todo para los proximos dias de soledad en Barcelona ... :D

Es bueno puntualizar esto en el blog, ya que a mi me ha tocado sufrir esto también, la verdad es que saber esto en su día me hubiese ahorrado mucho trabajo... pero por lo menos al siguiente no le pasará lo mismo.
Un saludo.

Leido y comparto lo que comentas

Debo aclarar que mi comentario se basaba en la frustración ocasionada por una descarga errónea, en su día me descargué la Beta 2 de Office System completa (en aquellos días era gratuita su descarga) e instalé parte en mi sistema (clientes mayoritariamente) pero estos días cuando me proponía a instalar uno de los servidores me encontré con un desagradable error en uno de los cds que había grabado en su día y con el archivo de la imagen corrupto por un error en la descarga.
Cuando me propuse descargarlo de nuevo me encontré con la sorpresa de no poder descargar la beta desde la página de españa y que desde los demás paises había que realizar un pago como detallo en mi post.
Mi crítica (que siempre pretende ser constructiva) está orientada al cambio repentino de política y no a la legitimidad de cobrar por ese servicio.
Por otro lado soy uno de esos pocos que podría alzar la mano, ya que además de publicar post sobre los errores que me he encontrado, reporto cada uno de ellos a los servidores de Microsoft.

Sobre el tema de si Microsoft conoce el P2P, advertir que no solo lo conocen, si no que lo implementan en el Service Pack 2 de Windows XP.
Para habilitarlo debemos ir al Panel de Control, Agregar o Quitar Componentes de Windows, Servicios de Red, Peer-to-peer y seguir el asistente que nos muestra.
Además de esto también podemos encontrar los esfuerzos de MS Research por crear un sistema peer-to-peer multipropósito. Su codename es "Avalanche" y puedes encontrar más detalles en este enlace:
http://research.microsoft.com/~pablo/avalanche.aspx

Siempre he creido que las críticas son buenas siempre que persigan mejorar lo que critican. No por ello se debe caer en la crítica fácil y sin argumentos.

Un saludo.

Ayer iba a contestar a Telemaco en su comentario... mi razonamiento era el siguiente:

Si tu vas a ver 20 casas, no tienes coche, y tienes que ir en taxi, ¿Qué le vas a decir al taxista? ¡Oye! no me cobres que al ver 20 casa me sale por una pasta.

De todas formas no habia caído en la cuenta de que lo equivalente a las casas es la versión Trial.

Muy buenos comentarios Rodrigo y Cristian ;)

Los motivos que alega Microsoft para empezar a cobrar es que el número de descargas alcanzó unos números increibles. Más de 2.000.000 creo recordar. Esos ya son muchos Beta testers. A partir de ahí han decidido recortar.

Pensad que podrían directamente haber sacado la descarga, o no sacar una Beta pública como hacen muchas otras empresas. Recordad también que para usuarios de las suscripciones MSDN y TechNet esa descarga es gratuita.

Creo que simplemente es una forma de limitar o acotar la beta y que no se desmadre. Y pensad que el coste de ancho de banda debe ser considerable.

Hola Rodrigo,

No se si será un simple labado de cara, pero MS ultimamente me estaba sorprendiendo haciendo OpenSource (o sucedaneo MS) varios de sus productos como Virtual Server. Y de repente ves estas cosas de hacer pagar por descargar por una Beta. Estoy desconcertado! Si miramos la competencia, como Google, cuando ha hecho pagar  por una beta? Puedo entender la explicación de MS basadas en costes de mantenimiento pero la encuentro bastante floja la verdad. Porque seguro que existe y pueden desarrollar otra solución para controlar y poder hacer frente a esa abalancha de descargas. Sinceramente, lo encuentro una falta de tacto hacia los usuarios que son más fieles... pero nadie es perfercto.

Felicidades por este estupendo blog!

Saludos.

pues yo creo que 2€ es una de las mejores soluciones que pudieron encontrar al problema de las descarga de la Beta.

A diferencia de otras Betas, en este caso muchisima gente queria ver el Office nuevo, y eso está bien, pero la idea de una Beta Publica y parte del EULA, "pide amablemente" que reportemos errores o sugerencias (esas 2 caritas tan simpaticas que vemos en el system tray).

Si yo cierro "parcialmente" las puertas a todo el mundo, y solo pido un aporte minimo, ya me aseguro que la persona que vera el link de descarga, pondra a bajar el ISO del DVD, y luego de un mes cuando se quede sin espacio en el disco borrará la ISO; esa persona no bajará la Beta.

Es mi punto de vista, no crei prudente responder a alguno de los comentarios ayer ya que hay ciertas personas que tienen negacion con las tecnologias Ms y cualquier tipo de accion que venga de ese lado, siempre será mala.

Pero bueno, esa es la ventaja de poder opinar entre todos !!!

Saludos

" Los diagramas no son lo importante ", es la frase que tengo en la mente después de leer UML: Casos

" Los diagramas no son lo importante ", es la frase que tengo en la mente después de leer UML: Casos

jajajajaja muy bueno ;)

jjejejje, en verdad esta muy bueno Rodrigo, pero si te fijas el chaval cometio un error debio hacer esto con el FOR

for (count;count<=500;count++)

   {

      printf("no lanzare aviones de papel en clase);

   }

Abrir y Cerrar "llave"

Pero muy ingenioso

PD: ah!!, lo de la correción lo hago a manera de amenizar, que no es plan de darmela de perfecto.

Saludos y Felicidades por tu blog

Excelente recurso Rodrigo!

Justo lo que andaba buscando :D

Saludos,

Anotado !!!

las stats de Google van muy bien, y no sabia que con Community Server se podian poner, asi q ahora mismo las agrego :D

Saludos

Estoy profundizando en Scrum. Siempre me ha llamado la atenci&oacute;n esta metodolog&iacute;a &aacute;gil,

Yo, igual;)

Muchas zenkius por la información Rodrigo. :-)

Ya he hecho lo que comentabas y ahora sólo falta ver si todo funciona ok.

Ese último detalle es importante tenerlo en cuenta, porque a mí en Google me dice "Esperando los datos..." con el típico reloj de espera, y ya me veía yo ahí 24-48h mirando el relojito dando vueltas.

Para el fin de semana veo como se ha portado Google Analystics. :-)

Hola Rodrigo,

Acabo de leer:

"Google Analytics está por fin abierto a todos los usuarios y que se han aumentado la cantidad de perfiles disponibles para los usuarios existentes..."

Dejo la liga (me encanta esta traducción de un tecnicismo, jejeje) aqui:

http://macropsia.com.ar/2006/08/google-analytics-en-abierto/

Saludos.

En esencia estoy bastante de acuerdo contigo... sin embargo, fijate que partes de la idea de que un "dictador benévolo" es el que inicialmente forma el equipo. Ciertamente, de ser así, habrá depositado su confianza en gente que se la merezca. Implantará la democracia en un equipo no viciado, de profesionales capacidados para tomar decisiones con responsabilidad (y evidentemente, de forma razonada y justificada). Esto se parece más a la aristocracia de Platón que a una democracia, tal y como es conocida en occidente (http://es.wikipedia.org/wiki/Aristocracia). Si hablamos de ese escenario, tengo que admitir que estoy de acuerdo contigo.

Sin embargo, sabes tan bien como yo que no es el escenario más habitual. El escenario habitual es aquel en el que el equipo es impuesto. En este tipo de escenario, la mediodridad puede ampararse en la democracia para vertir opiniones no justificadas ni sustentadas en nada, que cuanto menos hacen perder el tiempo al resto de integrantes del equipo. Sin llegar a caer en el diseño por comité (que sabes tan bien como yo que es muy habitual) el simple hecho de "poder hablar" suele ser el combustible para que los guiados por la ignorancia y la vanidad sean capaces de decir cualquier cosa con tal de que el resto del equipo sea consciente del moreno de solarium que ha adquirido en los últimos meses. Se lo que me responderás a esto... "lo que pueda decir ese tipo de personas se suele caer por su propio peso". Sí, es cierto, pero durante su intervención han conseguido perder su propio tiempo y lo que es más grave, el tiempo de los que se sienten obligados a escucharle.

Otro punto a discutir, relacionado con el Scrum y el reparto de poderes, sería el de hasta qué punto tienen voz los miembros que participan puntualmente en el proyecto. Quiero decir, según el Scrum, cualquier persona (o "pig" :-))que participe durante un sprint es parte del equipo y debe considerarse un miembro (entiendo que igual a los demás). Significa eso que la opinión de un consultor especializado que viene a sacar las castañas del fuego sobre un tema concreto, vale lo mismo que la de aquellos que le han llamado? ¿O tal vez "alguien" debiera tener un voto de calidad? ¿quién? ¿debería ser elegido democráticamente?

En resumen, creo que la aristocracia es una herramienta muy potente aplicada al desarrollo del software. La democracia occidental, me temo que lleva obligatoriamente al antipatrón de "diseño por comité".

En fin, ¿qué opináis?

Hola Emilio, es posible que así sea, lo digo porque tenía una invitación de Google Analystics desde hace meses que no había ejecutado aún, y al ir a dar de alta mi cuenta, no me ha pedido la invitación en ningún momento... si esto es así, no hay excusa para que nadie lo use. :-)

Yo me registre sin invitación al igual que Jorge

pues yo esperare un poco mas para ver si refresca el GAnalytics, yo las uso desde hace meses y van muy bien, pero no recuerdo q tarden tanto tiempo en empezar a refrescar :D

ademas un dato interesante, cuando veo el source code de mi blog veo 2 entradas para GAnalytics:

<script src="/Utility/global.js?Version=2.1.60809.935" type="text/javascript"></script>

<!-- Start of Google Analytics Code -->

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">

</script>

<script type="text/javascript">

_uacct = "UA-ESTENOSOYYO-1";

urchinTracker();

</script>

<!-- End of Google Analytics Code -->

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">

</script>

<script type="text/javascript">

_uacct = "UA-ESTESISOYYO-3";

urchinTracker();

</script>

donde la 2da es la mia y la 1ra ??? seguramente es de geeks.ms :D

Saludos

PD: borren el comentario si el script no puede ser publico :D

&iquest;&iquest;&iquest; Est&aacute;s interesado en probar Visual Studio Team System y ademas poder integrar

Puesto que utilizamos Google Analytics para ver el tr&aacute;fico del sitio y que seg&uacute;n me responden

Una solución que pronpongo yo es:

Un perfil de Google Analytics es multi usuario y además tiene 2 tipos de usuarios, Administrador y Visor de Informes, podrías a los bloggers añadirlos como visor de informes :D

De todas formas Rodrigo, no creo que todos vayan a usar Google Analytics, de hecho solo nos tenemos que fijar en los comentarios de tu 1º post sobre el tema, ya que solo comentamos 3 bloggers, Jorge, Bruno y yo. Si de 22 bloggers activos (he contado a los que tienen mas de 1 post) solo 4 (contandote a ti) hemos intentado ponerlo, no va a ser tanto caos administrativo.

Además, el añadir un usuario es simplemente introducir nombre, apellidos, correo electronico y seleccionar el perfil disponible.

Yo no quiero ser pesado, pero ahora me dejaste con las ganas :D

Pensado así... será la mejor opción:D

Jejejejeje habrá que verlo, yo lo uso en mi web el FreeTextBox y es bastante bueno :D, espero que está versión sea incluso mejor ;)

Creo que otro generador de estadísticas es el siguiente:

ClustrMaps

http://clustrmaps.com/index.htm

Está en fase Beta, pero algunos blogs de MSDN lo están utilizando... ¿tendrá algo que ver con Microsoft?...

Hola Rodrigo,

Seguro que ya lo sabeis pero acabo de ver un plugin para WLW la mar de interesante que precisamente colore código:

Buayacorp - Plugin: Coloreador de sintáxis para Windows Live Writer

http://www.buayacorp.com/archivos/plugin-coloreador-de-sintaxis-para-windows-live-writer/

Lo he probado y parece que me funciona estupendamente.

Saludos.

Yo utilizo otro. Es una herramienta desarrollada por un alemán de nombre Kalme en .NET Framework 2.0. No es que sea la bomba, pero mi primer artículo, tiene código preparado con esta herramienta inicialmente, y definitivamente por mis manitas. Me ahorra mucho trabajo y eso es lo que nos interesa a todos al fin y al cabo. :-)

+ Info por si os interesa:

http://www.kalme.de/index.php?option=com_content&task=view&id=35&Itemid=35

Lo probé en su día, y no me gustó mucho, la verdad... Project es una herramienta demasiado complicada para apoyar un proceso sencillo :-). Como dice Joel Spolsky, Project es para hacer submarinos, no para gestionar proyectos de software. Esta plantilla, al ya de por sñi complicado proyect, le añade infinidad de nuevas propiedades para cada tarea... en fin, que personalmente no me gustó nada.

Estoy de acuerdo, siempre le he tenido un poco de tirria a JavaScript por los mismos motivos. Hubo un tiempo que me pareció que JavaScript había quedado en segundo plano para hacer chorradillas en páginas web, pero hoy en día veo que me equivoqué de pleno. De hecho, ya he desempolvado un libro que compré hace 10 años(1996) sobre programación JavaScript.

Te propongo una aplicación más para añadir a la lista de las que utilizan JavaScript ampliamente, Microsoft Dynamics CRM 3.0. De hecho gran parte del trabajo de personalización y extensión pasa por utilizar JavaScript, como ya comenté en el blog http://geeks.ms/blogs/marco/archive/2006/06/28/606.aspx.

Bueno, que ni a mi me gustaba mucho JavaScript, es mas Java en si, pero hay que aprenderlo y dedicarle tiempo a las herramientas "Open Source" que ya me estoy empezando a dar cuenta de lo importantes que son, y de la cantidad de personas que trabajan con ella.

Me escrib&iacute;a, hace unos d&iacute;as, uno de los asistentes a la ponencia sobre Calidad del Software

Hace unos dias comentabamos esto mismo con unos compañeros de trabajo y yo les dije q me parecia q algo ha cambiado en el mercado de la informatica. Ahora podemos encontrarnos con clientes que exigen calidad en el producto final que se les entrega, pero lo mejor de esto es que entienden el coste de la calidad.

A donde voy, usualmente cuando alguien deseaba una solucion, entre las opciones que ofrecia el mercado, siempre estaban las "mas baratas" q (aunq no lo admitian) sacrificaban calidad en la entrega, al disminuir los recursos con los q trabajaban. Afortunadamente, ahora podemos encontrar casos (como en el q m encuentro ahora) donde nuestro interlocutor nos exige mucho, pero conoce el coste de esta exigencia.

Porq me gusta esto? creo que la respuesta es obvia. Aunque es una pena, que algunas personas entreguemos productos de calidad solo porq está en nuestra forma de ser, cuando poseemos todas las herramientas para lograr este resultado.

Lindo post, me ha hecho hablar un rato con algunos compañeros que trabajan en esas grandes multinacionales, que poseen cuartos llenos de certificaciones, pero q no conocen el concepto de calidad en el producto final.

Saludos

Lo que a mi modo de ver es brillante, es la estrecha relación que existe entre el coste y la calidad.

Esta frase la enmarco:

"Tercero: Quiza el factor más importante y menos evidente es que añadir calidad a nuestro software, al contrario de lo que puede parecer a primera vista, reduce los costes de desarrollo y acorta los plazos."

¡Cuantas veces he discutido yo de esto mismo en algunas de las empresas en las que he trabajado!

Pero... claro... cuando uno no lo quiere ver ni entender...

Me escrib&iacute;a, hace unos d&iacute;as, uno de los asistentes a la ponencia sobre Calidad del Software

¡Sensacional una vez más Rodrigo! :-)

Creo que al hilo, voy a escribir un comentario en mi blog sobre la Calidad [Arquitectura], algo que también me encanta. :-)

Excelente post rodrigo, mas de uno lo deberia leer aunk lo de descartar clientes es dificil de llevar a la practica por consultoras que no sean muy grandes y puedan optar a clientes como los que comentas, pero esta situacion de pez que se muerde la cola que comentas NO exime de la responsabilidad de la empresa de informatica a demandar la participacion del cliente para la generacion de un buen proyecto. Lamentablemente al final (en caso de problemas) importa más lo que esta escrito en la oferta que lo que realmente necesita el cliente, sobretodo si se necesitan más horas y estas no pueden ser facturables desde el punto de vista del cliente claro....

un buen resumen de una problematica actual y ojala todas las empresas sigan este camino.

Salu2

100% Agree ... !

hace un tiempo un compañero de Australia me contaba una historia sobre un boomerang que no vuelve; esto que parece una herramienta poco útil, es un reflejo de la previsión para el manejo de algunos proyectos.

Como tu bien dices, por lo gral uno invierte tiempo, dinero, formación, etc. en un proyecto, con la certeza que el mismo en un determinado momento empezará a generar beneficios. Sin embargo, el boomerang nunca vuelve, se convierte en un ladrillo; los proyectos se convierten en cargas eternas, la gente abandona las empresas, el cliente no queda nunca conforme, etc. Y esto es lo que quiere el cliente, la respuesta es fácil: NO.

Lo que uds comentan, relacionado al momento de sentar las bases del proyecto, tambien tiene que estar embebido dentro de la mentalidad de las personas que trabajan en el mismo. Personalmente, me he encontrado en casos donde una persona se reunia con el cliente para resolver un problema y volvía con ese problema resuelto, pero con una carga de 10 nuevas tareas para realizar!!! Al no estar bien definido el alcance del proyecto, era un círculo vicioso de nunca acabar. Y lamentablemente, el resultado no era feliz para ninguna de las partes :(

Esto que tu comentas en pocas lineas, es el reflejo de muchas experiencias distribuidas de proyectos. Es bueno saber que hay lugares/personas qtienen en cuenta este tipo de inquietudes.

Saludos

Sin duda JavaScript es el leguaje del presente y del futuro. Piensa en las aplicaciones que han tenido

Habeis pensado en esto como posible factor?

Para ejercer como médico o arquitecto hay que estar colegiado y titulado para poder firmar la obra del proyecto o recetar.

y para ejercer de informático??? Conozco gente que dice "yo soy informático" , ha hecho un curso de windows XP  y hace unas chapuzas que dan miedo... (y luego nos toca arreglar a otros) o que carecen de formacion adecuada . Recuerdo una empresa que reclutaba licenciados en derecho , les daba un cursillo y los ponia a programar...

No estoy diciendo que un Ingeniero Químico no pueda ejercer de jefe de proyectos o de programador pues estoy seguro que puede con la formación y motivación adecuadas pero creo que esta profesion que tenemos es una de las que más INTRUSISMO profesional padece lo cual se refleja a mi parecer en una MENOR valoracion profesional del informático y peores sueldos. ¿Conoceis algun arquitecto que gane menos que un ing. informatico?

Yo creo que lo que hace falta son profesionales verdaderamente cualificados.

Sergio

Rodrigo, estoy completamente de acuerdo y de hecho, como bien sabes, en mi empresa (www.krasis.com) hace tiempo que segimos esa filosofía.

Lo que ocurre es que mientras una empresa no está consolidada es muy difícil decir que no a los clientes. Es más que difícil. Al principio le pegas tiros a todo lo que se mueve y haces hasta páginas Web o lo que se tercie. Yo ahora, cuando ya tengo unos años de experiencia empresarial a cuestas veo perfectamente lo que tú dices, pero entiendo que no es tan fácil, sobre todo en algunas zonas de España (por ejemplo Galicia).

Ahora bien, muchos de los proyectos que haces de los que no estás convencido, es un hecho constatable y objetivo que son pan para hoy y hambre para mañana pues incluso acabas perdiendo dinero. Por eso es mejor dejarlos aunque duela.

Saludos

JM.

El hecho de poder elegir al cliente lo veo muy complicado hoy en día. Creo que pocas empresas pueden permitirse ese lujo.

De todas maneras, creo que muchas veces el problema no está en el cliente, sino en la propia empresa informática, que se mete a realizar proyectos donde no está capacitada. La cosa es conseguir el proyecto, independientemente de si tienen gente cualificada para hacerlo.Como el trabajo de programador lo puede hacer cualquiera...Yo lo vendo y luego ya contrataremos a cuatro becarios para hacer el desarrollo.

Hombre, al hilo de lo que dice ILM de "Como el trabajo de programador lo puede hacer cualquiera..." (ya sé que está dicho en tono irónico) yo tengo un simil que creo que describe bien lo que muchos piensan del trabajo de programador:

Programar es muy parecido a jugar al ajedrez. Hay muuuucha gente que se sabe mover las reglas de mover las piezas (sintaxis de un lenguaje y fundamentos) pero que no sabe jugar, pensar y resolver partidas (es decir, programar de verdad), pero que aún así se llama ajedrecista (programador).

Para mi un programdaor es algo más que alguien que se defiende con la sintaxis y los fundamentos de un lenguaje/plataforma, al igual que un ajedrecista es alguien que sabe bastante más que las reglas que permiten mover las piezas en el tablero.

Uf!, que filosófico me he puesto :-)

Coincido en todo.

Pero es dificil como decis, que una Consultora evolucione hacia otro tipo de empresa.

Si la Gerencia no entiende la necesidad de cambio, nunca le dirá al área Comercial que antes de vender algo debe estar validado por un arquitecto, analista, desarrollador (depende el tipo de proyecto ingrese aquí el tipo de recurso necesario). Los Comerciales no piensan en este tipo de cosas, por ende seguirán vendiendo "el oro y el moro".

El común denominador aquí es que estas personas no son Ingenieros. No piensan en dejar conforme al cliente, sino en el % de dinero que les toca si se firma el acuerdo con el cliente.

Si bien el cambio es dificil, es muy importante que uno lo vea como indispensable porque de seguro intentará influenciar a los demás. Pero influenciar para arriba? (comerciales, gerentes, directivos..). Es mucho más difícil. Y si no entienden esto menos van a entender lo de "elegir al cliente", jeje.

Saludos

Ya que a Rodrigo le ha gustado el ejemplo de Jose (que conste que amí también), y según leía ese comentario de Jose, me acordaba de otro que puse justamente esta semana cuando con unos conocidos hablaba de la informática actual, el intrusismo laboral de la profesión y me acordaba además de una conversación que tuve hace ya algunos años con el mismo Jose sobre estos temas en los que alguien le dijo algo así como... "...no te preocupes, esto creo que lo puede hacer mi hijo que sabe informática..." (omito más detalles pero creo que ahora se acordará mejor de aquella conversación ;-) ).

Sobre mi ejemplo, diré que para mí, una persona que sabe conducir un coche no le convierte ni en mecánico ni en excelente conductor. Es posible que sepa arreglar una rueda, echar gasolina, mirar el aceite, conducir y poco más, pero no sabe de todo sobre un coche para resolver cualquier situación.

Exactamente ocurre con la profesión informática.

Sobre el planteamiento que hace Rodrigo, reconozco como ya se ha dicho aquí, que es muy complicado decir que no a un cliente cuando la empresa empieza, pero tarde o temprano hay que tomar esa decisión si se quiere ir por ese camino, el camino de la distinción dentro de las empresas informáticas actuales, porque sino, no encontrarás diferenciación real entre el resto de empresas del sector y una vez que te atrapas en esa espiral, es muy difícil salir de ella. Lógicamente, mi postura es la misma que la de Rodrigo, pero no es simple capricho, mi experiencia laboral me hace pensar y decir, que la calidad tiene una estrecha relación con la satisfacción del cliente.

Me meto en la mente de Rodrigo por lo tanto (con la posibilidad de errar), para afirmar que lo que él quiere decir también, es que el objetivo que se persigue con este planteamiento, es el de ofrecer la máxima calidad y satisfacción del cliente, porque como profesionales, nuestra obligación es actuar así y saber que las necesidades de nuestros clientes han quedado colmadas. Es decir, que paga y obtiene a cambio una compensación que cumple sus espectativas. Pero para ello lógicamente, se deben implicar las dos partes, el cliente, y la empresa informática que desempeña las demandas solicitadas.

Por cierto Rodrigo, me alegro de lo que dices de los sistemas gremiales ya que de otra forma yo no me dedicaría a la informática pues como muchos sabéis mi profesión y estudios "formales" son en ingeniería mecánica (al igual que los de Rodrigo) ;-)

Yo creo que eso va con la persona y sus intereses. Prefiero a un filólogo que sepa programar porque lo ha aprendido él por interés y "frikismo" y lleva años en su casa haciendo cosas con elordenador porque le gusta, que a un licenciado en informática que se cree que por haber hecho una carrera ya lo sabe todo. Y sé bien lo que digo por que lo veo continuamente en procesos de selección. os sorprendería la cantidad de recién titulados en informática que te llegan diciendo que lo que más les gusta es programar y lo único que han programado en su vida es algún algoritmo suelto en Pascal que le han mandado en la facultad. ¿Cómo puedes decir que te gusta programar y no programar jamás nada fuera de lo que te mandan enla facultad obligatoriamente? Es como decir que lo que más te gusta es la literatura y sólo haber leído los libros obligatorios que te mandan en bachillerato (¿Siguen obligando a leer "Tiempo se soledad"? hoy en día ;-))

Yo entiendo que un médico al que le guste la neuro-cirugía me diga que no tiene experiencia práctica (no va a practicar consigo mismo), pero un programador no tiene disculpa hoy en día para no programar si le gusta.

En todos los lados cuecen habas y a veces el intrusismo viene de dentro aunque parezca una paradoja (conozco unos cuantos ingenieros que es para matarlos al igual que unos cuantos licenciados en informática que lo mimo). Así que el gregarismo no tiene porque ser bueno para nada. OJO: también conozco muchos que aprenden a manejar por encima el Dreamweaver y ya se llaman programadores y montan una empresa de "informática". Igual podían haber montado una mercería y serían igual de malos. Esto tampoco debería consentirse.

¡Aupa Rodrigo, titán!

A mi no me importa que un excelente ing industrial programe y seguro que lo hace

bien si se forma , aprende y esta motivado. Estoy seguro de que lo hace mejor que un ing sup informatico que carece de formacion o no le gusta programar o va de prepotente.

Lo que queria decir es que lo ideal sería como Arquitecto, aparejador , albañil

tener estos tres niveles o similares que podrían ser equivalentes en informatica a :

Jefe de proyecto, analista y programador (respectivamente ing. superior, ing. tenico y tecnico de fp por ejemplo)

Otra cosa es lo que enseñan en la carrera que puede estar mas o menos alejado del mundo laboral como descubrí cuando salí de la uni pero adquirí una capacidad de aprendizaje innegable pues tuve que hacer practicas en 15 lenguajes de programacion algunos de los cuales os sonaran a chino a algunos (lease pascal, ADA, modula2,Lisp, Eiffel, Smallltalk, etc....), por lo que coger un nuevo lenguaje como ASP o ASP.net o certificarme en ellos pues me pareció algo mas sencillo que no haber programado nunca.  A mi por ejemplo en la carrera no me enseñaron a administrar IIS ni a programar en ASP.net ni a hacer la mitad de las cosas que hago ahora.

YO creo que un ing. superior estudió esa carrera para dirigir proyectos (igual que un tecnico de fp para programar) pero debe empezar obviamente desde abajo y seguir una carrera profesional similar a esta: programador- analista- consultor- jefe proyectos durante unos años e ir cogiendo experiencia. E incluso puede darse el caso de que un excelente programador luego sea un desastre como jefe de proyectos cuando asciende pues no sabe dirigir y motivar quipos de trabajo o planificar proyectos o al reves, un jefe de proyecto que no tiene npi de programación ni tiene que tenerla porque se dedica a planificar y admisnitrar recursos como personal y sistemas.

Insisto, no por ello pienso que un ing quimico o industrial no pueda hacerlo con la adecuada formacion y motivacion. No olvidemos que por ejemplo Fernando Guerrero es ing Civil, José es ing. industrial, yo soy ing informatico , mi profesor del doctorado es ingeniero químico y creo que somos buenos profesionales cuando queremos.

Lo que no podemos consentir es que el "amigo de mi primo " hace paginas webs mu chulas y baratas y no sabe lo que es la tercera forma normal o una clave ajena para  la base de datos del portal o intranet  que quiere una empresa que va a desarrollar no os parece?

Saludos

Sergio

jeje

conocía la historia pero no conocía el detalle de la misma

empezaré a tener mas respeto a estos simpáticos animalitos :D

Saludos

Siempre he sostenido que la calidad del software empieza por la calidad del c&oacute;digo fuente. Basta

Siempre he sostenido que la calidad del software empieza por la calidad del c&oacute;digo fuente. Basta

Estoy completamente de acuerdo contigo, la calidad del código afecta directamente a la calidad del producto. Sobre todo porque un código de mala calidad es muy dificil de mantener. Por otra parte, si quisiesemos hacer un símil, ¿qué pasaría si los componentes de un coche son de mala calidad?, pues es muy probable que el coche tenga muchas averías.

jejeje, Muy buena promoción Rodrigo.

Leo en el numero 29 de la excelente revista dotNetMania , un art&iacute;culo de opini&oacute;n Antonio

Todavía no he podido leer el artículo de Antonio, pero sí estoy de acuerdo en muchos de los comentarios que haces, aunque en algunos discrepo un poco.

En cuanto a la captura de requisitos, es cierto que a medida que se desarrolla el proyecto surgirán nuevos requisitos y otros cambiarán, pero aún así, es nuestra responsabilidad intentar poner el empeño máximo en que la captura inicial sea lo más completa posible, para que estos cambios o nuevos requisitos sean realmente cambios o nuevos, y que no sean requisitos que estaban ahí desde el principio pero que no hemos sido capaces de encontrarlos.

El cliente irá descubriendo sus necesidades según avance el proyecto. Eso es muy cierto, pero tb podemos ayudar nosotros a que éstos salgan en fases inciales, por ejemplo, presentando maquetas o prototipos que puedan servir para validarlos. En muchas ocasiones, en cuanto se ve un pequeño prototipo empiezan a surgir nuevas ideas para el cliente. Y si en lugar de hacer esto....y si hacéis tb...

Una máxima que debemos tener siempre presente es que todo proyecto debe estar preparado para el cambio y si no lo está fracasará. No siempre se tiene claro esto y así salen las cosas.

Por otro lado, al tema de las estimaciones y del cumplimiento de plazos yo sí le daría más importancia. Para el cliente es muy importante contratar un software que le sea entregado en tiempos, con calidad, y que cubra sus necesidades. Hay veces que de la llegada de ese software dependen muchos intereses. Nada más empezar no podemos decirle que el proyecto podrá durará unos 3 meses, pero que sepa que esto es una estimación y que puede tardar 6 meses.

Cierto es, que lo que sí tiene que tener muy claro el cliente, y hay que transmitírselo así, es que cosas como los cambios y los nuevos requisitos afectarán al proyecto y a los tiempos de entrega del mismo. Muchas veces se pide, se pide y no se da cuenta que en lugar de 3 meses se va a tardar 6. Me recuerda al albañil que empieza a hacer una obra y da un presupuesto. A medida que hace la obra su cliente le pide X cambios pidiendo mejoras, y luego se lleva las manos a la cabeza cuando la obra se dispara de precio.

Las preguntas que comentas me hacen tener esta reflexión. Cómo está el mundo del software y cuántas compañias mediocres hay por ahí que hacen verdaderas chapuzas!! Ya sé que esto es algo ideal, pero casi todo lo que comentas debería ser algo que el cliente diese por supuesto, ya que nosotros debemos ser los profesionales y actuar en beneficio del cliente, llevando los proyectos a buen término.

Leo en el numero 29 de la excelente revista dotNetMania , un art&iacute;culo de opini&oacute;n Antonio

Leo en el numero 29 de la excelente revista dotNetMania , un art&iacute;culo de opini&oacute;n Antonio

Rodrigo ... q bueno q tu también hables de EntLib !!!

Yo desde hace varios años (desde q eran Application Blocks) que trato de enseñar las ventajas que trae utilizar los productos de la gente de Patterns and Practices, en especial EntLib. Te cuento q ademas los HOL hay muchos webcasts donde podemos ver aplicadas y explicadas, cosas tan simples como el uso del Data Access AppBlock, o el desarrollo de una aplicacion que los utilice a todos !!!

los puedes ver aqui (http://www.ronjacobs.com/pnplive/Default.htm), y obviamente es nombre del site es Patterns and Practices Live !!!

Saludos

Como ya sabes, desde mi modesta opinión y experiencia, comparto tu forma de entender esta "industria" (que poco me gusta este nombre). El caso, es que al hilo de lo que comentas sobre los sistemas de gestión/aseguramiento de la calidad, me gustaría contar algunas cosas.

Para mi, hoy en día, contratar una empresa informática certificada ISO no es garantía de nada, es más, en cierta forma me provocaría desconfianza. Me he encontrado, no una ni dos, muchas empresas que presumen de certificacion de calidad ISO, pero que ni siquiera son capaces de definir su ciclo de vida, su metodología, pruebas, calidad del código... En la mayoría de los casos la certificación de calidad no tiene más objetivo que conseguir el sello, da igual si mejoramos o no... "total antes de que venga el auditor apañamos un poco los registros y listo" (esto es real). Por eso me provocaría desconfiaza una empresa de nuestra "industria", que como uno de los principales motivos para confiarle un proyecto se escudase en su certificación de calidad, en vez de en cosas como las que comenta Rodrigo.

Creo que el concepto de certificación de calidad esta irremediablemente devaluado por querer hacer negocio de la calidad. La calidad no debería ser un argumento comercial, para mí, la calidad debería ser una necesidad interna... Una forma de descubrir nuestros fallos, de ayudarnos a mejorar, y en definitiva de ser unos excelentes profesionales. Prefiero mil veces utilizar como argumento comercial a clientes satisfechos, proyectos en plazo superior al estimado pero que realmente han supuesto una innovación y han demostrado ser un beneficio para el cliente, etc... que una triste certificación de calidad.

Un Saludo

El "nada más empezar" no era lo más adecuado. Yo no digo que desde el minuto 0 le vas a poder decir el tiempo del proyecto pero algún momento le tendrás que decir algo, porque el tiempo que lleve tb influirá en el coste y esto sí que es una cosa que valora mucho el cliente. Al principio de proyecto es una solución muy válida el tema de estimar en rangos, pero a medida que avanza el proyecto, cuando se tienen más claros los requisitos, se debería poder ajustar más.

Cierto es que en la mayoría de las situaciones se suele ser optimista. Cuando un tarea está al 80% es que todavía le falta otro 80%. ( no es algo así..) Pero como esto ya lo sabemos, vamos a intentar poner medidas :-)

En cuanto a los prototipos, yo si suelo ser partidarios de ellos, siempre que se entienda que son el producto final y que son simplemente eso, prototipos; usar y tirar. Lo veo una buena manera de validar requisitos y obtener nuevos, ya que se ve "algo funcionando". El principal problema que veo, que se puede pensar que es casi el producto final y que el fin de proyect está cerca. Tb depende del proyecto, porque no para todo tipo de proyectos viene bien.

Cuando comentas que lo mejor es recoger una serie de requisitos mínimos para poder entregar algo a corto plazo. ¿ no sería como hacer un prototipo ? Si haces algo para seguir capturando más requisitos y que el cliente vea algo...En esta situación es más que posible que surgan nuevos requisitos que te harán tirar la aplicación.

Por matizar, cuando comentaba que la captura de requisitos debería ser completa, no estoy diciendo que hay que construir montañas de documentación. Todo en su justa medida. Podría valer con un simple listado, en una hoja excel, para ir teniéndolos localizados.

Hola a todos,

Me prece interesantisima la conversación que esta dando lugar este post. Para comenzar expongo de antemano que mi punto de vista es el de un desarrollador que se dedica a realizar su trabajo lo mejor que puede y le dejan, no la de un proyect manager. La sensaciones que te llebas al cabo de los años es que los clientes saben de sus necesidades pero desconocen como cubrirlas. En este punto se tendría que hacerse valer la figura del consultor pero en la mayoría de los casos el cliente no esta dispuesto a amoldarse a los cambios necesarios en su forma de trabajo para poder implantar una nueva solución tecnológica.

Si algo he visto con mis propios ojos es que las empresas cereen que un sistema informático hara que ese empleado completamente inútil, que no ha visto un ordenador en su vida, sea el elemento más productivo de la historia. Total que aunque le hagas el mejor programa que puedas al final siempre hay un técnico, externo o interno (cuando no uno mismo), haciendo el trabajo de este elemento. Todo esto acaba siempre con un cliente pidiendo y pidiendo mas requerimientos y un consultor aceptando y aceptando más cambios dentro del proyeto.

Mientras tanto al final de la cadena hay un desarrollador encerrado en un proyecto que nunca acaba y que siente que su labor nunca satisface realmente las necesidades del cliente por mucho esfuerzo y pasión que le heche. Eso si el dueño de la empresa informática se hace más y más rico gracias a las horas que se le han facturado de más al cliente haciendole creer que están justificadisimas por la extremada complejidad de sus necesidades.

Por otro lado, pienso como Rodrigo que entregar reducidas funcionalidades completamente finalizadas, que hacen poquito pero lo hacen bien, al cliente es mucho mejor que presentarle prototipos que al fin y alcabo no son realmente productivos para una empresa que, al fin y al cabo, es para lo que nos paga.

Saludos.

Rodrigo, que lindo tema que has tocado. No he leido el articulo, pero me hago una idea de la linea

Rodrigo, gracias por tocar estos temas más que interesantes.

Yo tampoco he leído el artículo de Antonio, pero me hago una idea de la línea que sigue. Como la parte trillada ya las has enfocado muy bien vos y la han completado con los comentarios; sólo agregaría que para darnos cuenta de la mejor forma de gestionar/administrar/coordinar un proyecto, simplemente veamos como han evolucionado las metodologias para esta tareas. No por nada, las metodologias ágiles (las de moda) restan importancia a la "burocratización" de los proyectos. El problema suele estar, en que las grandes consultoras (las muy grandes) siguen defendiendo sus logros con certificaciones ISO, CMMI nivel 5, etc. Pero (y esto lo vivo cada tanto) luego en sus proyectos no cumplen/aplican nada de lo que prometen, porque la dinámica de los mismos se los impide. ¿Esto está mal? en parte sí (que es lo que hablamos hasta ahora) pero por otro lado, se ven obligados a adaptarse; es grato ver que de a poco tienen q ser mas ágiles, mas moldeables, pero que tienen un dinosaurio interno que no les deja evolucionar.

Algunos pensarán, el tiempo dirá quien tiene razón; yo prefiero pensar que los clientes ya están eligiendo calidad antes que espejitos y cuentas de colores :D

Saludos.

Como bien dices, se trata de un tutorial para pequeñas y medianes aplicaciones (Que yo prefiero utilizar las EnterpriseLibrary para el acceso a datos) y no siempre es necesario irse a montar una fachada de Web Services, puesto que en muchos clientes solo quieren montar su intranet únicamente con aplicativos Web y descartan la posiblidad de desarrollar un smart client o una aplicación Windows Forms, y como sabemos el desarrollar esa fachada de servicios implica un costo de tiempo y dado que en muchos proyectos ese tiempo es oro, no es posible desarrollar, aunque comparto tu opinión en que es la mejor manera de hacer una buena aplicación empresarial.

Salu2.

Gracias por este articulo (y gracias tambien a RFOG), esto nos ayuda mucho a los que estamos aprendiendo.

Esta muy bien el enfoque de 4 capas pero solo para aplicaciones muyyy grandes y

Si mi cliente solo quiere una aplicacion web y no va a querer jamás una winforms ni smartclient me parece suficiente con 3 capas sin servicios web.

Opino como Nat e incluso a veces cuando el proyecto es pequeño (unportal con noticias y enlaces unicamente por ejemplo) solo haría un proyecto con VS con una unica dll usando por ejemplo los data access app blocks como capa de acceso datos y los webforms .aspx como capa de cliente (que usan los objetos de negocio) ademas de unas clases que implementan mi lógica de negocio que usan la capa de datos exclusivamente. Es decir preservamos el mismo enfoque de arquitectura de 3 capas pero con un solo proyecto.

Lo estuve hablando asi con Scott Mitchel de 4guysfromrolla autor del link que menciona Rodrigo. Si duda el link es muy educativo y lo uso en los cursos que imparto de asp.net

Saludos

Sergio

Aupa Rodrigo!

Yo escribí una pequeña utilidad denominada CassiniAquí hace unos meses y la publiqué en mi Blog y creo que es bastante interesante:

http://www.jasoft.org/blog/PermaLink,guid,e7a8f8d7-bdbb-43dc-8325-01710dc8cd7b.aspx

Salu2

Jose.

muy buena data  ...

y la verdad q bastante útil !!!

Saludos

Y como sería muy presuntuoso ponerte a ti mismo como uno de esos 'especialistas generalizadores' te refiero como uno de ellos, un gran conocedor de todo lo que se refiera a C++, a las APIS de Windows como bueno en ASP.NET, SharePoint, gestión de proyectos y muchas más cosas....

P.D: Eso si, de cenar no sabes hacer!!!

Saludos

Unai Zorrilla Castro

Como siempre un excelente aporte

Estos últimos días he estado investigando sobre el funcionamiento de System.Transactions y su relación

Enhorabuena Rodrigo :-)

Pienso comprarmelo asi que avísanos cuando esté publicado en castellano por favor!!

Yo creo que hasta podrías escribir un artículo en alguna revista sobre el tema que le interesaría a más de un jefe de proyectos y/o Analista como yo.

Gracias

Saludos

Sergio

Muy importantes tus comentarios, las empresas si no se concientizan de lo importante que es el aplicar una correcta gestión de proyectos y de procesos creo que no van a poder explotar al máximo las capacidades que TFS, si bien es cierto no se logrará un cambio de la noche a la mañana, es un proceso que ya debe empezarse ahora, actualmente existen muchas empresas que ni siquiera conocen a fondo sus procesos y menos la forma de trabajo que hay en cada uno de sus proyectos dentro de la misma, te comento que acá en perú muchas empresas han emprendido el camino hacia la certificación CMMI y eso se aplaude ya que sigifica que se está tomando conciencia de lo importante que es el implantar sus áreas de proceso correctamente y del valor agregado que le da a la empresa el uso de métricas y herramientas que ayuden a conocerse a si mismas :).

Un saludo desde perú.

Ivan Mostacero.

Buenas Rodrigooo! Totalmente de acuerdo contigo, llevo un año formando en TS con TFS y me llevo la misma impresion siempre. Las herramientas de TS Suite estan bien, pero no sirven de nada si no aceptas los principios que han derivado en esto... y eso solo lo puedes conseguir si alguien te evangeliza lo suficiente como para hacerte verlo.

Ahora, no estoy de acuerdo con que las herramientas de Team System son mas potentes que las open source... llevo casi 4 años currando con agile, unit testing, refactoring, etc... y te puedo asegurar y aseguro que unit testing de team system no llega aun a la version 2.0 de lo que es NUnit; refactoring de Team System es una full comparado con Resharper; Team Build es un mero compilador al lado de Cruise Control; y por ultimo, MSBuild no puede competir con NAnt a estas alturas y tal y como se entrega con Team System, a menos que te bajes las Task Libraries.

Eso si, es de Microsoft y tiene lo que siempre aporta (tarde) Microsoft: Integración con tus herramientas. Y si ahroa todo el mundo esta descubriendo esto es porque esta en Team System, y como tu decias: las herramientas son muy viejas, si no las has descubierto hasta ahroa es que no te interesaba ni sabias que aportaban.

Sin rencor ;)

Me ha gustado todo el artículo pero en especial me gustaría saber de donde has sacado la metodología ASM (A Salto de Mataby Miguel Egea). Porque esa esa debe de ser la metodología más extendida del mundo. Debrían dar certificaciones oficiales con cuadros que lo expecifiquen para colgarlas en las entradas de las empresas para que los clientes sepan donde se meten.

Saludos.

&iquest;&iquest;&iquest; Est&aacute;s interesado en probar Visual Studio Team System y ademas poder integrar

"...toda empresa aspira a hacer menos con más"

Yo diria que más que aspirar, es REALMENTE lo que hacen. :P

(Ponga un "Oracle" en su vida: La palabra "Oracle" da mucho prestigio. Da igual que usted tenga sólo dos delegaciones en toda España y su base de datos tenga apenas 20 o 30 transacciones DIARIAS. Toda empresa que aspire a ser considerada "seria", debe hacer que la palabra "Oracle" forme parte de ella. Y no se olvide además de presumir de Enterprise Edition, aunque deba rehipotecar su vivienda para pagar la licencia. Recuerde: su empresa lo vale).

buen tip

cambiado y actualizando en la start page :D

Saludos

wolas,

Repasando entradas he visto esta y me he acordado de una cosa relacionada. GetProcesses en .NET 1.1 necesita que esten instalados los contadores de rendimiento para poder enseñar los procesos en curso, si no recibiremos un precioso InvalidOperationException, porque esta fallando al acceder a las claves de registro. En .net 2.0 no es necesario porque se obtienen de manera diferente :)

ciao!

Muy Buena Rodrigo!!!, está estupendo el programita.

Me uno a tu razonamiento Rodrigo, me parece correctísima tu opinión

Está claro que la administración no está siendo neutral en este tema, si no que está actuando de forma intervencionista con un discriminación positiva hacia el software libre.

Hace poco días me he enterado de que la Xunta de Galicia va a subvencionar una nueva distribución de Linux. Otra distribución de Linux más. ¿Aporta eso algo? ¿Es eso innovar? Esperemos que esa distribución no se limite a una mera traducción y a un cambio de colores y fondos de pantalla, junto con una selección de software como ha ocurrido con otras muchas distribuciones de Linux políticas.

Pero que razón tenéis!!! Por fin alguien que comparte mi opinión...

Salu2.

Como yo le pase el link de este hilo a ciertos personajes que conozco... xDDD

Porque con según quién no se puede hablar. Si no opinas que el Software libre es la solución a todos los males del mundo mundial, eres poco menos que un "vendido" a Microsoft y discípulo del Diablo. Eres un capitalista de mierda porque apoyas "al monopolio" en lugar de a los "paladines de la justicia". Y no se dan cuenta de que lo que ellos quieren es en realidad imponer otro monopolio. Yo no sé si se creen todas las zarandajas que escriben ... pero, por lo menos yo, opino que NO le es rentable ni útil al 90% de las empresas tener el código fuente de un programa (igual se creen que todo el mundo es programador). Yo he llegado a leer en foros, que Firefox es mejor que Opera SOLO porque es libre... y es un argumento que no se aguanta por ningún sitio porque ya no les queda ni el recurso de decir que Opera es de pago, porque ya no lo es.

En fin, yo tengo una opinión respecto a esto, y es que un gran porcentaje de "partidarios" del software libre realmente son unos jetas que lo de libre les importa un pepino, lo que les interesa de verdad es que sea gratuito. Rompiendo así con el principal paradigma que ya dijo Stallman: "Free as in freedom, not as in free beer".

Saludos

Bueno... aquí hay opiniones de todo tipo, para empezar no están predicando con el ejemplo ya que la Xunta para sus aplicaciones Web usa .NET con Windows, ¿qué pasa? ¿va a migrar sus servidores a Linux con Mono?¿Va a suponer el gasto que ello conlleva?, no lo creo, me sorprendería mucho.

Por otra parte, "eres un vendido de Microsoft", estoy totalmente de acuerdo con Pablo de que es un comentario generalizado que une a Microsoft con el software de pago, uniendo por otra parte el software libre con el Anti-Windows, lo que más me hace gracia de esta situciación es que la mayoria de la gente que te dice que el software libre es mejor usa Windows.

Ya le gustaría a las distribuciones Linux tener un sistema de ejecutables/instaladores como el de Windows (lo digo por experiencia... instalar un programa en Linux no es para nada fácil). Que conste que yo no estoy encontra ni de Linux ni del Software libre, pero lo que es cierto es que la confianza/seguridad que te da el software libre no te la da el software de pago, y no lo digo por calidad, la cual no cuestiono, sino por el soporte del mismo.

Bueno esta es mi opinión, y que conste que yo diariamente uso tanto software libre, de pago y gratuito depende de las necesidades y cual las cubra mejor.

Bajo las premisas que comentas, tienes razón. Pero te has dejado un dato muy importante: la Administración Pública de un país debe ASEGURAR el acceso a sus servicios de TODOS los ciudadanos.

El problema es que si utilizar un software no libre de una empresa en concreto estas OBLIGANDO a que tus ciudadanos, TODOS tus ciudadanos utilicen dicho software, y ahí está el problema ¿Qué pasa con la gente que no pueda utilizar o acceder a dicho software? Sobre todo si:

1. La empresa del software no cumple los estándares.

2. La empresa del software no permite el acceso a discapacitados.

3. La empresa del software no da seguridad 100% sobre sus sistemas y los datos.

La opción del software libre es porque asegura que TODO el mundo puede acceder al mismo. Si Microsoft hubiera cumplido estas premisas ahora Word sería el estandar en la UE y no OpenDocument, y así les va ultimamente.

Yo me lo pensaría dos veces antes de hablar sobre este tema porque tu blog está montado alrededor de algunas tecnologías que son ABIERTAS (como el C#). Si no fuera así no tendría el éxito que tiene.

Estoy totalmente de acuerdo contigo Rodrigo.

Hay algo que detesto, me molesta, me arde la sangre y es que cuando se comenta sobre algun producto que tenga que ver con Microsoft ya lo ponen como que es malo, tiene poca funcionalidad y si la tiene la comparan con algun software libre que corra bajo Linux. Pero como decia Eugenio en su comentario estas personas que critican a Microsoft trabajan con sus tecnologias y lo peor de todo la PC que tienen en su casa, tiene Windows instalado.

Creo que es hora de ir creando conciencia y apreciar lo que tiene valor (ya sea libre o de pago).

Ah!! por cierto Rodrigo eso de que no hay un suite ofimatica que se le pare al lado a Office es muy cierto, jejje.

The Pragmatic Programmer !! que buenos recuerdos ..  lo lei hace un tiempo (que ya es más de un año porq estaba en Argentina), pero recuerdo que por sobre todo era una lectura divertida y a conciencia. Y tocando un poco el tema del post, yo creo que muchos desarrolladores desarrollan principios sólidos para gestionar su día a día; pero sus principios suelen "chocar" contra los que poseen los jefes de proyecto. Si bien, la lista podria ser aplicable a ambos perfiles, por lo gral no se aplica. De aquí nacen los principales problemas de gestión de proyectos que usualmente veo en mi día a día.

Saludos

El Bruno

Siempre que imparto un curso sobre gesti&oacute;n de proyectos de software, con independencia de la empresa

Interesante razonamiento ... aca va el mio

http://necudeco.blogsome.com/2006/10/12/opiniones-y-opiniones/

¿Volviendo a C++? pues si ... me parece que comenzaré a pasar mas seguido por estos excelentes ejemplos de código ya que es muy probable que tenga q volver durante un tiempo a C++. Ademas este ejemplo me viene "justo" para un pequeño servidor de streaming que tengo que implementar y donde los callbacks para el progreso del streaming de archivos son bastantes utiles para la monitorización.

Saludos.

Scrum es una metodolog&iacute;a que me gusta mucho, los motivos principales son los siguientes:Es simple:

Scrum es una metodolog&iacute;a que me gusta mucho, los motivos principales son los siguientes:Es simple:

Personalmente, me encanta Scrum como metodologia y es con la que hasta el momento me he sentido mas comodo trabajando (especialmente porque, como mencionas, bien aplicada elimina un monton de peso sobre el equipo de proyecto) Ademas, como ya sabes, tengo informacion de primare mano de que dos famosas y malvadas megacorporaciones (};P) la usan en muchos de sus equipos, lo cual siempre es interesante...

El problema que tiene Scrum (pero que es practicamente extensible a cualquier otra metodologia agil) es que el esfuerzo de implantacion no esta en "la puesta en marcha"... esta en convencer a un monton de gente de que en realidad FUNCIONA. La "perdida de control" relativa que supone el dejar la estimacion a largo plazo y tener feedbacks solo por sprints tiende a "acongojar" un poco a los managers (especialmente a los mas "estilo Dilbert) aunque suele funcionar una vez se prueba que compensa con creces en cuanto se usen la demos de final de sprint un par de veces ("tenemos algo funcionando cada dos semanas? de verdad?")

Pero como pluses: lo facil que es de manejar, las buenas practicas en comunicacion, integracion continua, el ser "time oriented" en vez de "goal oriented",... en fin, que si alguien quiere pasarse a "la agilidad", yo definitivamente lo recomendaria!

y yo que sabia porque habia leido que la version enterprise y developer del sql server 2005 se diferenciaba tan sólo por el tipo de licencias... ahora veo que es por algunas funcionalidades... :S...

particularmente sólo ando jugando con la versión Enterprise, y pos ya vean de lo que me estoy perdiendo... o no ?.

Saludos..

Percy Reyes.

muy interesante,...

saludos..

Percy Reyes.

Ya he hablado anteriormente en este blog sobre el desarrollo web con C++ sobre IIS. Pues bien seg&uacute;n

Hola Rodrigo.

Al parecer C++ es el lenguaje rey porque montar una infraestructura como esta bajo este lenguaje, es algo de apreciar. Cada dia que pasa me doy cuenta de algo, a veces nos esforzamos demasiado tratando de aprender nuevas tecnologias que al final no podemos completar ninguna.

Ademas no nos vallamos mas lejos, muchas de las aplicaciones que trae Windows (cualquier version) vienen programadas en este lenguaje (C++).

Disculpa si este comentario no corresponde directamente con el post, pero me vino esto a la mente y pues... lo dije!! ;)

Holas Rodrigo!

Grandes posts, como siempre!. En cuanto a C++ sería bueno, si no es mucho pedirte, elabores un post donde orientes como empezar a programar en C++ y q cosas aprender, recursos, guias, y todo eso.

Y eso se diviría en dos tipos, para los que recién empiezan y para los que ya tienen conocimiento avanzados en algún otro lenguaje y desarrollo de Aplicaciones.

P.D.: Sólo es un sugerencia :D.

Saludos,

Apoyo la sugerencia de Sergio.

Sin duda alguna que son puntos muy importantes a tener en cuenta, y justo es un tema que ahora se viene discutiendo, si vemos el conjunto de vectores que se mencionan la mayoria estan relacionos a servicios Web. Justamente Dino Espósito nos da algunas características que deben tener estos y para que usarlo, cuando y donde. aca está la URL http://weblogs.asp.net/despos/archive/2006/10/17/Careful-with-Web-Services-in-ASP.NET-AJAX.aspx.

Debemos tener mucho cuidado con la información que se envíe al cliente y en si, buscar opciones mas seguras para diferentes situaciones, por ejemplo centrandonos en ASP.NET Ajax, (Ajax es uno de los pilares de la Web 2.0) debemos hacer llamadas a servicios Web para el caso de listados que no comprometan información crítica de la empresa, ahora si es necesario trabajar con datos mas críticos se podría usar características como el UpdatePanel para lo mismo.

Es una necesidad el comprender de que además de la facilidad con que se pueden trabajar ciertas características en el cliente, tambien es una responsabilidad mayor el protegernos de ataques dañidos como los que muestras rodrigo, y esa responsabilidad recae en nosotros que somos los que implementaremos estas características, si bien estos temas no son nuevos (existe bastante documentación al respecto desde hace buen tiempo atrás), es necesario tomar las precauciones del caso.

Saludos :)

Ivan Mostacero.

Me la apunto, muy buena pisha :)

Aunque nada como un volcado de kernel para volcar los handles xDD

Muy bueno maestro , yo agregaría tcpview como utilidad adicional para ver el estado de los puertos de nuestro pc y las conexiones que se abren y cierran en tiempo real

además de saber desde que ip se generan y matar algunas "moscas" donde "huele a mierda" ... ;-)

Saludos

Sergio

Cualquiera que en conozca algo sobre metodolog&iacute;as &aacute;giles de desarrollo conoce el manifiesto

Holas...!

Empezando a investigar un poco más de "stakeholders", encontré algunos links interesantes de la definición de los que aún no saben:

Acá hay un gráfico que da un overview de ellos: http://www.aulafacil.com/estrategia/Lecc-9.htm.

Y este es un PDF interante, que trata sobre la importancia de los stakeholders y porque es necesario conocer a los grupos de interes: http://www.telefonica.es/responsabilidadcorporativa/pdfs/manualpracticarelaciones.pdf.

Rodrigo, ¿?, a quienes consideras como stakeholders dentro de un proyecto?

Saludos,

Sergio,

Existen diferentes terminos que se manejan en los proyectos, uno de ellos es saber distinguir claramente entre lo que son Usuarios, Clientes y Stakeholders.

Definiendolo de manera sencilla diriamos que un "Cliente" es la persona que va a pagar por el sistema pero que no necesariamente lo va a usar, "Usuario" es la persona encargada de usar el sistema y es con quien vas a obtener la mayor cantidad de requerimientos porque es el que conoce el sistema en si.

Si tuvieramos que dar una definicion breve de "Stakeholders" diriamos que son quienes tienen un interes en el proyecto, interes que puede ser positivo o negativo y que ademas podrian ser parte de la empresa o externa a ella.

Por ejemplo si tuvieses que desarrollar un workFlow de tarjetas de credito dentro de una empresa financiera, tu cliente en si seria la empresa que esta contratando tus servicios, tus usuarios podrian ser el personal de tarjetas de credito que va a usar el sistema para una preaprobacion de las mismas (es un caso hipotetico claro) y los stakeholders serian las personas involucradas, usuarios, clientes que tienen una tarjeta de credito, talvez un grupo de la gente del area de sistemas no les conviene que el proyecto salga debido a ciertos arreglos que tienen, o otras empresas bancarias que no quieren que mejores el tema de entrega de tarjetas de credito. Como podemos ver hay mucha gente involucrada verdad :) y es necesario tomar en cuenta a todos ellos para poder tener un mejor control del proyecto ya que todos ellos podrian influir de manera positiva o negativa en el mismo.

Un saludo desde Peru,

Ivan Mostacero

Hola una pregunta lo que pasa es que mi version de tfserver esta por vencer, pero ya tengo la version licenciada existe algun procedimiento para realizar la actualizacion de la version ya que la version trial ya esta en produccion.??

Gracias.

A menudo recibo la pregunta: &iquest;Qu&eacute; puedo hacer para mejorar la calidad del software que

Solo un comentario, aunque es obvio (pero como bien mencionas en realidad no lo es tanto) que el implementar un proceso formal de pruebas ejecutado como tal por un profesionista es un requisito imprescindible para obtener calidad en un producto, esto es solo un lado de la historia, ya que aunque efectivamente la funcionalidad es un aspecto escencial para decir que un software tiene la calidad adecuada (es decir, si un software no hace lo que tiene que hacer, pues estamos en el hoyo), esto cumple dependiendo de la complejidad del software, un porcentaje de la calidad. El resto de la calidad proviene de atributos que no están asociados al funcionamiento del software. Es decir, aspectos como usabilidad, desempeño, portabilidad etc. Aspectos que algunos autores identifican como Factores de Calidad, Requerimientos Operacionales, Requerimientos No Funcionales, etc.

Y en ese escenario, aunque el Tester también tiene un papel (es quien se encarga de verificar que los atributos se satisfagan), quien defina la calidad del mismo es precisamente el Rol del Arquitecto de Sotware.

Para quien este interesado, chequen el blog del buen Sergio: http://community.crosshorizons.us/blogs/softwarearquitecto/default.aspx

Rodrigo, estoy totalmente de acuerdo contigo en todos los puntos comentados acerca de la necesidad de un tester y las razones a esgrimir ante la dirección de la empresa. Creo que es fundamental para la supervivencia de cualquier empresa de software.

No obstante, antes de contratar un tester en una empesa, yo haría la siguiente pregunta ¿ Está la empresa preparada para que un tester desarrolle su trabajo eficientemente ?

Y la respuesta podría depender de otras cuestiones como: ¿ Está el software suficientemente documentado para que una persona ajena al desarrollo sepa lo que tiene que probar ? ¿ Existen base de datos de pruebas perfectamente establecidas para que las pruebas sean efectivas ? ¿ Se tienen herramientas para controlar y documenatar cada una de las incidencias encontradas y reportarlas a programación ? ....

Con ello quiero decir que no resulta tan sencillo tomar la decisión de contratar a un tester y que

se ponga a trabajar. Antes de eso es necesario un trabajo de análisis de la situación actual de la empresa, ya sea interno o externo, y seguramente a partir de ahí trabajo duro hasta tener los cimientos necesarios para contratar un tester.

Rodrigo, estoy de acuerdo contigo en que tener un tester en el grupo de desarrollo ayuda mucho, pero tb creo importante tener en cuenta que los propios desarrolladores tienen que intentar dar la mayor calidad posible, haciendo las pruebas para verificar que sus desarrollos cumplen con lo que se les ha pedido. Si el programador entrega "software basura" al tester apaga y vamonos!! No puede ser que por tener un tester en el equipo yo me olvide de la calidad porque ya me lo va a probar otro.

Lo que intento decir es que un tester sí que ayuda mucho a mejorar la calidad, siempre que el tester realmente sea eso y no una persona que se dedica a dar doble-click sobre la aplicación, pero que antes hay que cumplir con otros pasos anteriores; Una buena documentación, revisiones de código, pruebas por parte del desarrollador..y no caer en que con tener un tester ya me vale.

Hola Rodrigo.

Bueno yo anteriormente cuando utilizaba el Visual Studio 6.0 para programar con mi querido Visual Basic no tomaba el "Source Safe" para nada en serio, es mas ni siquiera me preocupe por utilizarlo. Ahora en .NET tendre que ver esta utilidad, al menos la que trae integrada Visual Studio .NET

Jejeje lo tendré en cuenta, es algo que estoy pensando ahora que he formateado mi PC... :)

Encuentro que uno de los principales obstáculos para plantearse tener un equipo de testers, (suficiente con que cumpla la formula  m+1 testers donde m<>0, según Rodrigo) es la motivación o la ausencia de experiencia positiva en este campo.

Ya no digo iniciar los pasos, simplemente que por nuestra cabeza pase la idea, de que se tiempo esta bien invertido.

Ian Sommerville, decia algo asi como:

"Las pruebas sirven para determinar que un sistema tiene fallos, pero no pueden demostrar la ausencia de estos"

Así... ¿Quién quiere probar un sistema? ¿Cómo podemos asegurarnos fehacientemente de que un sistema es bueno? Quizás ahí encontraremos la motivación que buscamos.

Gracias por vuestro tiempo.

a ver a ver  ...

¿¿¿ como es eso que hay gente q no utiliza un gestor de codigo fuente ???

q ganas de aprender por las malas, jejeje; lamentablemente mucha gente comienza a darse cuenta del valor de un VSS (x ej) despues de no tenerlo y necesitar volver atras a base de Zips, copy paste de folders, etc; por las malas como digo yo :D

Saludos

Hablaba hace un tiempo en este mismo blog sobre la importancia de las pizarras para facilitar la comunicaci&oacute;n

Ya sabes titán cuál es mi punto de vista sobre este aspecto... es FUNDAMENTAL.

En muchas ocasiones además, somos capaces de rellenar una pizarra completa, borrarla y volverla a rellenar... y esto n veces... total, que sino sacamos una foto por cada fase o pizarra rellena, podemos volvernos locos discutiendo aspectos de arquitectura y otros varios.

Adicionalmente, una fotografía es muy fácil de enviar por correo electrónico y de adjuntarlo al documento final, por lo que es bajo mi punto de vista, de una documentación ESENCIAL.

la utilización de pizarras, o algo que las emule, es fundamental. Se nota mucho cuando no las tienes y tienes que sacar de la documentación esa visión global de la que te dota la pizarra con un sólo vistazo. Por cierto, el video del MIT una pasada, no he podido resistirme a publicitarlo en mi blog, jiji. Nos vemos en la codecamp!

El post buenisimo como siempre, pero encontrar una joya en los comentarios como

Ian Sommerville, decia algo asi como:

"Las pruebas sirven para determinar que un sistema tiene fallos, pero no pueden demostrar la ausencia de estos"

me pone :D :D :D

Thanks to everyone

Saludos

gogoz ha tomado la solución que tu has dicho: enviar curriculums, porque está hasta los webs de ver analisis que no son analisis sino mercadotecnia para los clientes. Así como de analistas que son agronomos, periodistas, matematicos,... de todo menos analistas, pues, como bien dices, un mal analista JAMAS reconoce sus errores, pues equivaldría a decir "soy comercial, no analista, no valgo para esto", y, aunque es verdad que hay empresas donde los analisis existen, son las menos, pues lo que prima en la mayoría de las pequeñas pymes es dinero dinero dinero y no la calidad, además, ya nos tienen a los programadores que salimos de FP que les hacemos el trabajo sucio. Lo dicho, ¡hasta los webs!

Si, imprescindibles las pizarras (o pizarrones, como le decimos en Arg :).

Con respecto al video, el software del MIT se puede descargar, buscando en google se encuentra.

Saludos

Hola Rodrigo,

El principal problema que tiene un equipo de dasarrollo con VSS en VB6 es cuando, por ejemplo, dos personas crean nuevas fuentes dentro de un proyecto. La segunda tiene que obtener a mano, es decir, con el gestor de VSS el proyecto porque sino las nuevas fuentes que haya introducido la primera persona son omitidas por el nuevo proyecto de la segunda.

Saludos!!!

Encantado de habernos conocido en persona Rodrigo, me lo pasé muy bien con todos vosotros!!!!

La verdad es que yo también me lo pasé estupendamente. Ya he colgado las fotos del viernes, que con el cansancio que llevaba no pude hacer más. Hoy intentaré poner las del sabado (y sabado a la nuit, jiji).

OK Gracias ya pude resolver el problema pero me surge otra duda lo que pasa es que estoy intentando realizar una restauracion de los datos de team foundation server en otra maquina para probar si estan funcionando losbackup que se estan sacando pero hasta ahora he seguido los pasos de las paginas de microsoft para realizar este procedimiento pero no funciona ya e intentado de varias formas aveces uqeda apuntando a las base sde datos del servidor original.

Vuelvo a leer aAntonio Quiros explicando su visi&oacute;n sobre la gesti&oacute;n de proyectos, en el

¡Que grande eres Rodrigo! (en todos los sentidos). :-)

Ojalá hubiese más jefes de proyecto con las ideas tan claras como tú, y la preocupación constante por el bienestar del equipo. Seguramente a esta industria le irían las cosas mucho mejor.

A colación de lo que dices Marco, durante esta semana me ha estado bombardeando una parte muy pequeña de una interesantísima conversación con Rodrigo en el Code Camp pasado, dónde discutíamos acerca de como denominar al personal informático... "recursos" vs "personas"... y es que comúnmente se habla de recursos, pero deberían salirnos a todos sarpullidos cuando se habla de recursos, ya que los recursos son un PC, un Software, un teclado,... pero... ¿una persona es un recurso?.

Estaba por poner en mi blog algo sobre este tema, pero ya que has hecho tu comentario, como venía muy bien... he decidido poner esta pequeña línea aquí. :-)

Por suerte, en la mayoría de las empresas se evitan este tipo de discusiones acerca de las métricas más adecuadas... sencillamente, ¡porque no se mide nada! :-) Me temo que el "medir bien" es la segunda derivada. De todas formas, en este caso, menos mal que es mejor no medir, que medir mal. La pura incompetencia y desidia acabará salvando al mundo de los cortos de miras. ¿A que es genial?

Por fin !! Desde que leí el artículo estaba esperándolo.

Estoy de acuerdo con Gorka en que lo habitual es no tener ningún tipo de métrica, al menos formal.

Tb un comentario sobre "El motivo es sencillo, las personas son mucho más inteligentes que las métricas". Bueno, en esta industria tenemos de todo :-)

Completamente de acuerdo, hace tiempo que vengo siguiendo los articulos de "opinión" de Quiros, y la verdad es que no se como cogerlos... en la mayoria de los proyectos que he trabajado ha habido un jefe de proyecto con ideas "reveladoras" que media todo y te juzgaba por ello, y el resultado era el que dice Rodrigo. Sin embargo, en los ultimos años ha existido un Jefe de Proyecto que utilizaba las metricas para determinar las acciones y decisiones del proyecto, sin evaluar, simplemente para mejorar el tiempo de respuesta. Y es el unico en toda mi vida como desarrollador que he visto entregar un proyecto a tiempo, con la funcionalidad especificada, sin echar ni una hora de mas y donde los desarrolladores estaban 120% contentos (tb dependia mucho de las metodologías agile y de que ejecutaba sus tareas de jefe de proyecto: aislar al desarrollador del cliente)

Y por cierto, lo de que el equipo se destruye a medio plazo no creo que sea del todo cierto... pienso que se destruye mas bien a corto, cortisimo plazo...

Creo que el problema viene cuando a un cliente le tienes que dar una estimación del tiempo que vas a invertir en la realización de un proyecto.

Te puedes basar en la experiencia, o en proyectos pasados, pero creo que no viene mal alguna ayuda digamos "científica" que permita orientarte, como la estimación según puntos de función (o cualquier otra herramienta). Y está claro que el resultado, es eso, simplemente una estimación.

Pero es que nosotros, al igual que ocurre en todas las profesiones, debemos ser capaces de dar un presupuesto estimativo a un cliente.

La verdad es q es mas que interesante ... personalmente yo no me quiero perder la oportunidad de conocer al equipo de Pattern and Practices y ver su vision para fututo de productos como EntLib ... seguramente nos veremos !!!

Saludos

Espero que nos lo puedas contar a los que no podemos asistir ;)

Saludos

Ole!

Estaré desde el lunes, a si que nos vemos por allí, de todos modos me toca estar algunos turnos en los stands de .NET 3.0 (28&29 si no recuerdo mal) a si que nos veremos fijo :)

Personalmente tengo puestas muchas ilusiones en el teched de este año (WCF, AJAX y CardSpace sobre todo), a ver que tal se porta...sobre la charla de depuración, si es la que yo creo (windbg, sos...) posiblemente la hagamos en el siguiente MVP day, de modo que aprovecha para ver otra cosa!!!  :D

nos vemos BurgoVasco ;)

Pásalo estupendamente Rodrigo. :-)

Y tú David, disfruta como siempre. ;-)

Hola Rodrigo,

Espero que no te importe que haga promoción de la Conferencia de Mono de Miguel de Icaza en Barcelona. El miercoles 8 de noviembre a las 19:30 en la Aula Magna de la Universitat de Barcelona con la dirección de Gran Via de les Corts Catalanes, 585. El acceso a la conferencia es totalmente gratuito.

http://www.softcatala.org/~jmas/bloc/pivot/entry.php?id=219

No todo el mundo tiene la suerte de poder asistir al TechEd.

Saludos.

te tomo la promesa Rodrigo :).

Saludos,

Yo tb estare por alli... a la preconference asistire a la de Software Engineering the Scott Hanselman... y despues mas o menos como tu, quiero tragarme todo lo de Nikhil Kothari (o commo se escriba) mucho de depuración con Ingo Rammer, a Rafal pensaba verle la de MSF 4.0 tb (porque ya le he visto antes con security) y tb a Roy Osherove con Team System (tecnicas avanzadas de testing o el "tipicos miedos a agile"), algunas de identidades (cardspace, identity metasystem y active directoy federation services), Live y WCM, algo de MOSS, algo de Anders Heljsberg, Biztalk 2006 + WF ... y por supuesto, como dije al principio, mucho Atlas, Usabilidad Web y nuevos entornos Web 2.0...

Supongo Rodrigo que ya tienes mi telefono... sino es asi asi, dimelo por mail y te lo paso para quedar por alli :)

Yo currare en el ATE de Team System, he marcado mis imperdibles como (sobre todo por los ponentes):

Tuesday

09:30 - 11:00  KEY001 - LAUNCH: Windows Vista, the 2007 Office system, and AJAX Remove

Eric Rudder

14:15 - 15:30  ARC207 - Introduction to Agile Methodologies and Concepts Remove

Roy Osherove

17:45 - 19:00  DEV309 - The Identity Metasystem, Active Directory Federation Services (ADFS), and Windows CardSpace (formerly 'InfoCard') Remove

Keith Brown

Wednesday

09:00 - 10:15  DEVWD15 - Hardcore .NET Production Debugging Remove

Ingo Rammer

Thursday

09:00 - 10:15  DEV345 - Asynchronous ASP.NET Programming Remove

Jeff Prosise

13:30 - 14:45  DEVWD27 - "Scripting ASP.NET AJAX": Deep Dive into ASP.NET AJAX, Scripting & Debugging Remove

Nikhil Kothari

Friday

13:30 - 14:45  DEV411 - AJAX Patterns with the Microsoft AJAX Library Remove

Nikhil Kothari

Estoy de acuerdo que las personas somos mas que recursos, sobre todo en este negocio.

Una de las primeras métricas que escuche - y que aun existe - es la cantidad de lineas que escribe un desarrollador, yo prefiero que no tenga que escribir tantas lineas de acceso a datos y utilice un componente ya probado, y por el contrario centre ese esfuerzo a la lógica del negocio, que es de ese negocio y que no se repite para otro.

Coincido con que muchas veces no existen métricas, ni conciencia empresarial de las personas que venden los proyectos. Un preventa que habia en la empresa siempre decia "Esto... dos meses". Ni estimación ni brujería, caradurismo en estado puro. Vender una falsa ilusión.

En casi ningun proyecto que trabaje existe una reunion post morten, se deshace el equipo, cada uno a clientes diferentes a repetir la misma historia. Parece que esta prohibido evaluar el proceso "Hemos cobrado ¿que mas quieres?" y se acabo el análisis del proyecto.

Por ultimo, hay muchos MCAD y otros emule CAD. Gente que no ha abierto el Visual Studio, sino el emule y se bajo los exámenes. No digo que sea algo propio de las personas, sino aveces forzado por la empresa "Te pagamos la certificación para poder ser proveedor de tal cliente". Pero bueno, después de todo, las certificaciones son otra forma de medir a las empresas.

Lo que soys es unos borrachos!!

PD: Las letras del human detector que me han tocado son IBM, tokate los webs.

Pues no me funciono con mis bases me marca error en las vistas del sistema

Creo que no te salen los links... :-P

Yo lo estuve probando y no funcionaba bien, no activaba el intellisense. Lo habéis probado con SQL Server 2005 SP1 en castellano ?

Gracias Rodrigo.

Desde que me quite unas cuantas cosillas de encima empezare con el Blog en Geeks ;)

Saludos

A ver si nos pones más cosas sobre C++/CLI. :-)

Empezaba mi segundo d&iacute;a de Tech Ed con el af&aacute;n de acudir a una sesi&oacute;n de discusi&oacute;n

Pues en mi caso me paso lo mismo, pero mucho antes, solo me vasto leer un par de entrevistas hechas a él o ver una presentación que hizo sobre Mono en una Universidad de España (no recuerdo cual), en que ninguna demo le compilo, fue todo un papelón y viendo que no podía hacer mucho y tiempo le sobraba, empezó a despotricas contra todos, los usuarios de KDE por que supuestamente tiene mal gusto, los desarrolladores de Visual Basic que para él son maricas y así siguió un buen rato.

Para culminar están sus declaraciones acerca de WPF, que se notan son de un ignorante o un resentido, o quizás las dos cosas,  siempre he tenido la sensación que en el mundo del “software libre” la gente en vez de trabajar pensando en mejorar o innovar, lo hace trabajando en contra de algo o alguien.

Muy buena pagina. me gustaría q hablaras mas sobre las bondades del FrameWork 3.0

Hola!

Yo conozco a gente dentro del mundo del SL que se lo curra una barbaridad :) pero supongo que en todas partes tiene que cocerse habas y que nuestras percepciones variarán en base a nuestras experiencias.

En cuanto a lo de Miguel, prefiero no opinar porque solo he hablado con el un día un rato y paso de entrar en cyber prensa rosa =D  Aquel dia hubo ciertas anécdotas y los que estuvimos alli comentamos la jugada en un corrillo de sillas que nos quedó cañí cañí (overcañí) :) Estuvo genial poder conocer a una persona de la que se leen vida y obras y ver que son de carne y hueso

Fue divertido ver a Rodrigo consternado por la sesión de RUP xDD y el rato de risas sobre la longitud de sus posts no tuvo precio xDDD

chao!

:DD

por eso, nosotros comentamos la jugada en el corrillo :) lo de overengineered me llegó al alma, pero que nadie lo saque de contexto!!! Es que hubo algunas afirmaciones curiosas y su estilo de expresarse es único O:)  ¿quién no ha dicho nunca el "páralo, páralo" de Boris ? :DD

de todos modos Miguel fue un gran contribudor al Kernel de GNU/Linux y ha hecho muchas cosas y el que tuvo retuvo, ahora esta en otro rol, por cierto...nos dio unos cd´s con vmwares con mono y esta bastante interesante ;)

Chaou!

Dios, que panza de reir... ya me ha enviado los links de las multicolumnas con javascript, por cierto. Y son lo mismo que el anterior, un modelo de capas... ese dias fue muy muy bueno, entre Icaza y el PanWei de Ivar Jacobson no podia dar credito a todo lo que estaba pasando :)

Que tal cuates!!

La verdad que Miguel es una parsona muy muy peculiar. Quizas necesite ser asi para llamar la atención sobre un proyecto que no dispone de las capañas de marketing como las de Microsft. Quizas sea pq su sangre latina le hace expresarse de esa manera tan vehemente. Palabras textutuales suyas: "Cualquiera que visite mi blog se dará cuenta que no tengo la más pija idea de cualquier chiguada de html o php".

Sinceramente yo no soy una persoan objetiva hablando sobre el tema. Miguel de Icaza es un verdadero idolo para mi, que a pesar de su caracter extrovertido, es un profesional que pasará a la historia no por su Mono sino tb gracias a proyectos anteriores como Evolution. Tras verlo en la citada conferencia, en contra de Rodrigo, sigo manteniendo el mito porque el director de un proyecto que lo primero que hace para presentar su tecnologia muestra las caras al publico asistente de los desarrolladores responsables de cada parte del proyecto, necesariamente debe de ser un tio genial!

Desarrolla como un MONO

http://test.vbprincipiantes.com/Blogs/tabid/290/EntryID/326/Default.aspx

la clave de esto es:

involucrar al cliente en el proceso del desarrollo de software...

XP es la voz ??...

saludos

PERCY REYES,

Allí está el número 29:

http://www.dotnetmania.com/Articulos/029/index.html

http://www.dotnetmania.com/Articulos/029/editorial.html

saludos

PERCY REYES,

Gracias Rodrígo por los recursos!!!!

(como puedes ver leo tu blog:P)

Saludos

mas gente para el lado oscuro !!!

jejeje (sin ofender :D)

Viva C++, pronto empiezo en Geeks :D)

Ya he comentado en este blog que Scrum es una metodología ágil que me gusta especialmente ( http://geeks.ms/blogs/rcorral/archive/2006/10/15/Por-qu_E900_-me-gusta-Scrum.aspx

Ya he comentado en este blog que Scrum es una metodología ágil que me gusta especialmente ( http://geeks.ms/blogs/rcorral/archive/2006/10/15/Por-qu_E900_-me-gusta-Scrum.aspx

Escribía hace unos días sobre las estimaciones y como se tienden a tratar como compromisos. Pero es evidente

Recientemente inicie un curso de Desarrollo de Aplicaciones, en la Célula de mi Universidad. A comparación...

Recientemente inicie un curso de Desarrollo de Aplicaciones, en la Célula de mi Universidad. A comparación...

Recientemente inicie un curso de Desarrollo de Aplicaciones, en la Célula de mi Universidad. A comparación

Recientemente inicie un curso de Desarrollo de Aplicaciones, en la Célula de mi Universidad. A comparación

Recuerdo que en una charla un instructor de ventas de software decia que tampoco se negocia el precio del producto, lo que es lo mismo cuando trabajas frelance, el cliente o el usuario les parece exagerado el tiempo en hacer el proyecto y por lo tanto el costo, sin embargo la leccion es se cobran y se trabajan minutos de 60 segundos no minutos de 30 o 40 segundos

excelente blogs

saludos

Ya he comentado en este blog que Scrum es una metodología ágil que me gusta especialmente , y que uno

Ya he comentado en este blog que Scrum es una metodología ágil que me gusta especialmente , y que uno

Genial propuesta... aquí van mis dos centavos... partiendo de tu base Rodrigo. :-)

Log on your PC,

with a trust connection...

Create a database as a programmer,

and normalize it...

Write your applications, code the scripts,

refactor them and fix the errors...

Use Internet, blog all as a bloguer,

as a Geek...

Be a Geek, my friend

Bruce Geek

Eso está bien, yo se de uno que le van mucho los diseños y no quiero señalar(http://geeks.ms/blogs/FJCarbajosa)

Bruce Lee: Be Water, My Friend

   Empty your mind. Be formless, shapeless. Like water. You put water into a bottle and it becomes the bottle. You put in a teapot, it becomes the teapot. Water can flow, or it can crash. Be water, my friend!

http://www.microsiervos.com/archivo/peliculas-tv/be-water-my-friend.html

   Test your program. Be workflow or assert. Like Code. Comment and refractor your class. Blog about this and read Geeks. Code can run, or it can throw exception. Be Code my friend!

Saludos!

Empty your code.

Be formless, shapeless. Like a geek.

You put a geek to write a Class, he becomes the Class; you put to write an Application, he becomes the Application.

The Application can run, or it can crash.

Be a GEEK, my friend...

¿Y que sería la vida sin este aderezo tipo salsa?... ¡¡¡yo quiero más opciones!!! :-))))

Hola Rodrigo,

Hay van algunos pegas/problemas que le veo al uso de Scrum. Esto no quita que le veo cosas interesantes, pero voy a comentar algunas pegas que le veo.

> Scrum supone un cambio bastante importante es la forma de trabajar; cambiar es muy difícil. Superar las reticencias al cambio son bastante complicadas y más cuando es un cambio importante. Ya sé que has escrito sobre este tema en post anteriores, pero

aún así lo veo complicado.

> Los proyectos más o menos terminan saliendo con más o menos dolor, pero ahí están. Por esto, pienso que la tendencia es más hacia cómo puedo "matizar" mi proceso actual, quitando lo que me sobra o añadiendo alguna buena práctica, para que la próxima vez lo haga bien, más que cambiar la metología e implantar otra diferente.

Lo que se plantea es: ¿ Para que voy a cambiar si haciendo pequeños retoques puedo mejorar ?. Aprendo de cómo me han ido mis proyectos, saco lo bueno y mano de cada uno, y voy mejorando poco a poco.

> Implicación del equipo. Para poder llevarlo a cabo debe haber un equipo comprometido, que adquiera unos compromisos y los cumpla. No sé hasta que punto esto siempre se puede conseguir. Del tema del compromiso no siempre se puede fiar uno. Hay gente para todo.

Ibon.

Aquí va alguna más:

Empty your mind. Be efficient, util. Like a geek.ms. You put a code into a comunity and it becomes the comunity. You put in a Application, it becomes the Application. Code can flow, or it can crash.... Be a Geek.ms, my Friend !

:D

Be whisky, my friend!!

a binary can flow or it can crash

a binary in a number is a number

a binary in a ascii is a ascii

be binary my friend

Pues yo consideraria esta:

DotNET addicted

C++ is Necesary for you applications :D)

Be whisky, my geek!!

A mí el whisky no me sienta bien, pero vamos...

No se si será porque es Lunes, pero al personal lo noto espeso...

¡¡¡Yo quiero más animación!!!... no me puedo creer que la gente no sea más creativa que Rodrigo o que yo mismo... ¡venga ya!

Be whisky, my geek!!

a geek is emotionless...

painless...

you put a geek into the code, and he becomes the code

you put a geek into the flow, and he gives you a workflow

a geek can unit test

or he can debug the best

Be a geek, my friend...

Bruce Geek.

Came on!! Other to the Collection:

Choose your version

Import Web.UI or Windows.Forms

Became a Form or a Page

Like a .NET Application

You chose VB and you have MY

You chose C# and you write ;

Or you can implement the your

Code can run, but it can crash

As a geek...

Be a geek, my friend

Byes!!!

A mi me gusta la de Gorka....

Yo no te digo que las empresas no se hacen las preguntas que tu comentas, sino que se las hacen pero la respuesta no es cambiar la forma de trabajar y usar la metodología X, sino que de forma natural intentan modificar su forma de trabajar actual con retoques de la misma.

¿ Qué igual la respuesta debería ser otra ? De acuerdo, pero hoy por hoy creo que es lo que más habitualmente sucederá.

Comentas que hay jefes de proyecto que lo empiezan a saber, pero en organizaciones medianas-grandes aún así, lo veo difícil, salvo que encuestres un sponsor bien arribita que entienda que la manera actual de trabajar y que parchearla no es una solución. Cosa tb difícil.

yo me apunto a hacer el diseño grafico si hace falta :)

El otro dia estuve leyendo un post de Rodrigo Corral sobre el tercer dia del Tech Ed y pues ya en la

Totalmente de acuerdo, Rodrigo. Si quieres tu pegata de "office 2007" en tu programa de conta, te lo curras. ¡Lo que vamos a tardar en ver programas "O07"! A menos que sea fácil "circunvenir" el test. Me parece una idea excelente por parte MS. Así sí que se crea "parroquia".

Me parece una buena idea la de Microsoft, pero no va a quedar nadie con licencia si sigue haciendo lo que comentas :-)

Que gracia les va a hacer esto a los vendedores de componenetes de interface, por ejemplo a Divelements y su SandRibbon, les han dado de lleno.

Muy interesantes la serie de articulos de Scrum!.

Saludos desde Argentina.

Empty your memory,

with a free()...

like a pointer

If you cast a pointer to a integer,

it becomes the integer,

if you cast a pointer to a struct,

it becomes the struct...

The pointer can crash and can Overflow...

Be a pointer my geek

¡Qué huevos tienes Rodrigo! Desde luego el asunto te ha quedado un poco "fascistoide", pero en el espíritu estoy de acuerdo contigo.

JM.

Por cierto, no se licencia código alguno, es decir sólo se licencia el "estilo" y usabilidad pero no te dan componentes para crear esta interfaz. Así que los que hacen componentes pueden estar tranquilos :-)

Con una agenda tecnológica tan interesante, tanto por los temas como por los ponentes, qué menos que comida y bebida al mismo nivel.

Que envidia (sana claro) :)

Cabrones, a ver cuando invitáis a vuestros partners como nosotros, que encima estamos en Galicia ;-)

Que por cierto aún estamos esperando que pongáis nuestro logo en vuestra página.

¡Envidia me dais!

Un abrazo.

JM.

Joeee... si os cuento como he amanecido hoy con el estómago... ayer por la noche hizo crack,... pero hoy ya ando mejor.

No tengo palabras para describir como fue todo. :-)))))))

Por fin entiendo de una manera clara las iteraciónes en las metodologías. Mi duda sobre TFS es como podriamos superponer las estimaciones y la duración real de las tareas de manera gráfica, a parte de los KPIs que tan de moda están!!! Pero bueno eso quizas sea apartarse un poco del tema introducido ya se...

Saludos.

La próxima vez podrías organizar un "Open Plain", que este tipo de fin de semana se apunta cualquiera :-)

Las jamadas como comenta Rodrigo estuvieron a la altura de las charlas. Creo que he engardado aún más si cabe... madre mía...

Por cierto, alguien se acuerda del nombre del vino? Estaba muy bueno :-)

¿Cuál de los dos?,... ¿el tinto o el blanco?... (me relamo mientras escribo)... srulp...

Que grande eres!!! y en todos los sentidos!!! jajaja

Muchas gracias.

hola Rodrigo!

Estoy leyendo un poco más sobre metodologías ágiles, y tenía pregunta para ti, y era:

¿cuando usas una metología ágil, que usas para el modelado del sistema?. Por lo que he revisado, a vista rápida en tus post, no has hablado mucho del modelado en metologías ágiles.

Estuve revisando por ahí, y llegue a: http://www.agilemodeling.com/. Tu lo estas aplicando?, o se entiende que si aplicas una metodología ágil como XP o Scrum, se entiende implícitamente que estas usando Agile Modeling?

Saludos,

He creado un addin que automatiza el proceso

http://www.codeplex.com/TfsAddInCheckOut

Hola a todos:

Me mola esto de Bruce Lee, lo que pasa que yo ahora mismo no se me ocurre el texto, pero si os puedo echar un mano en el diseño, para las camisas, etc. Para lo que sea aquí tamos! os dejo mi correo (carbasoft@hotmail.com) sin necesitaís algo. Venga amigos! seguro que sale algo chulo!

Bueno yo tengo que decir que en el 90% de los casos con realizar un simple backup y restaurarlo en la instancia de destino he tenido suficiente. Y es que la facilidad es algo cada dia más fascinante!!! Pero mentiria si alguna vez no he encontrado algun problema: la interelación en algunos casos no son compatibles entre sql 2000 y sql 2005. Avisados estais! jejeje

me parece que el modelo en capas incluyendo web services es una inteligente opción siempre pensando en el futuro y la escalabilidad, nosotros en un proyecto de facultad realizamos toda nuestra lógica de negocios con web services (en visual studio 2005) y nuestro cliente web en MoNo con ASPNet 2.0 al intentar realizar reportes en el cliente web con Mono fue imposible, entonces decidimos realizar un web service que devuelva los reportes en forma de un stream de bytes y que el cliente web los consuma. Esa fue una de las facilidades que obtuvimos de modelar con capas además de muchas otras.

Muy buen blog siempre encuentro algo interesante

Saludos

Hola Rodrigo, he encontrado una falta de ortografía en:

...pero una vez la hecheís un vistazo...

creo que echar un ojo o echar de menos es sin hache.

Saludos campeón.

jejeje rodrigo y sus faltas de ortografía, ya te acostumbrarass :)

Por cierto, Rodri, espero queme des permiso para usar parte de tus posts en un PDF sobre scrum que estoy preparando, luego lo postearé... es como una guía rápida de uso de scrum. Si tienes cualquier incoveniente dimelo :P

A mí me encanta las listas de comprobación. Me parecen un método excelente y ràpido de detectar puntos

Mmm... la protección contra impresión de los PDF de Adobe tiene una peguilla de seguridad:

Si se abre la plantilla con GSView + Ghostscript, se puede imprimir.

De todas formas, seguro que el documento impreso que se puede comprar en la web, es de mejor calidad,

Buen acto en el que vimos buenas herramientas,  algunos tostones , pero en general fue bastante bueno.

El Sr. Bolton un 10,

PD.- decir que RCorral .... no tuvo mucha suerte con la hora de la ponencia, aun así

ahí estábamos ... unos cuantos.

Rodrigo, felicidades y ha esperar un Prime Time la próxima.

Pepmarti

Pero que pasa cuando no tienes clara la arquitectura a utilizar ?, recientemento he empezado a trabajar con pruebas unitarias y uno de los problemas con los que me encuentro es el de tener que reacerlas constatemente, cuando no tienes claro el diseño de una aplicación normalmente vas aproximandote hacia esta, en varios pasos, y esto te obliga a tener que rehacer de forma constante tu código y de la misma forma las pruebas unitarias, y el tiempo que se pierde, buff..., no se si al final compensara..., estoy convencido de que de es gran ayuda tener una bateria de pruebas unitarias, pero cuando los desarrollos van ha sufrir muchos cambios a lo largo del proceso, quizas la solución este en escribirlas al final. Aunque recuerdo alguien que me dijo "en ese caso, seguro que no realizaras las pruebas, una vez hayas terminado la aplicación". Creo que todavian deben mejorar los sistemas para soportar pruebas unitarias, es mas estoy convencido que en poco tiempo muchas de las pruebas que realizamos podran generarse de forma automática por el sistema, pero tambien creo que debemos avanzar en este sentido para mejorar la calidad del software aunque todavia tengo muchas dudas, quien debe desarrollar las pruebas ?? los programadores, expertos en testing... además, la parte de los mock objects, todavía deja mucho que desear es muy costosa y muchas veces te obliga cambiar el desarrollo para poder testearlo.

Aunque entiendo a Juan perfectamente, creo el problema de no entender la necesidad de las pruebas unitarias es debido principalmente a un “erróneo” enfoque de lo que son las iteraciones. Debemos empezar a pensar que iteración es algo así como requisitos+código+test+loquieranustedes.  

Entiendo que en cada iteración debería entrar la codificación de requerimientos, la creación de las pruebas unitarias (si es antes o después de codificar los requerimientos no me meto), y un chequeo del cliente/responsable/lo que sea. Una vez concluido el  plazo se entra en la siguiente iteración donde:

-Podemos cambiarlo todo porque no es lo que se pedía: Es una evolución donde tendremos que reescribir algunos métodos y por supuesto sus test.

-Añadimos nueva funcionalidad: tendremos que escribir nuevas “cosas” y adaptar los anteriores clases para que encajen lo nuevo. Una vez más hay que adaptar las pruebas unitarias.

Al final de cada iteración podemos lanzar los test unitarios y ver que el código generado/adaptado en esa iteración y en todas las otras iteraciones posteriores es correcto. Es la única forma de asegurarse que estamos haciendo las cosas con pruebas demostrables. Dejarlos todos para el final es una autentica locura porque ¿a quién se le ocurriría, por ejemplo, escribir más de 1000 test de una tirada? Es un trabajo tan tedioso que yo no conozco a nadie  que tenga tanta paciencia para hacerlo con calidad (sin dejarse nada de lado). Y ya que hablamos de calidad, lo test unitarios son una prueba (necesaria) de que hemos hecho un software de calidad, ¿no? Aunque evidentemente para hacer un software de calidad tenemos que tener en cuenta muchas más cosas…

Saludos

Hola a Todos,

Uno de los motivos de que me encante el blog es el trato que se le da a Scrum o XP y el Agile en general. Para los que les interesa tanto el tema como a mi me gustaría recomendar esta comunidad que vulve a la carga con fuerzas renovadas:

http://www.agile-spain.com/agilev2/

Saludos.

Bueno, el crear los test unitarios antes que las funcionalidades  obliga a los programadores a que piensen antes de programar, pero que piensen en resultados (que es lo que se pide) y en las formas.

Muchos desarrolladores (incluidos los míos) se ponen a programar con la idea de lo que tienen que hacer. Muchas veces esta idea es a nivel de Interfaz de usuario o de resultados concretos, sin haber pensado antes qué patrones de diseño deben aplicar, qué clases, qué interfaces, etc.. Al obligar a realizarse antes los test unitarios obligamos a que piensen en la implementación que tienen que hacer: Resultados + Forma de lograrlo.

Además sirve para autoestimarse en tiempo. Un desarrollador debe tener el buen hábito de, a primera hora de la jornada, ponerse una meta de un x por ciento de los test para el fin de la jornada. Usar esta métrica le ayudará a demostrar y justificar su trabajo.

Evidentemente hay programadores que necesiten que se le inculquen este tipo de reglas y otros que son lo suficientemente disciplinados para no necesitarlos porque piensan como deben de pensar y saben cuánto tiempo les lleva cada cosa.  Pero todos fallamos alguna vez (y muchas) y para eso están los métodos, aunque siempre hay que buscar el equilibrio entre la opresión del método y la libertad artística del programador.

Lei los 4 puntos de scrum y estoy muy interesado en esta metodología. Pero me resulta importante 2 puntos que no quedan muy claros en estas 4 traducciones.

El primero aparece al final de esta diapositiva, y dice que "las retrospectivas que no resultan en cambios son esteriles y frustrantes". ¿Eso significa que si no surgen cambios o esos cambios no se pueden implementar antes del próximo sprint, no se debe continuar con esta etapa del proceso?

La segunda, no escribiste nada acerca de las reuniones diarias. ¿Hay algún consejo al respecto, sobre todo en cuanto a qué acciones hay que tomar cuando ocurren problemas en estas reuniones que no son fácilmente o rápidamente solucionables?

Saludos y gracias

Pero aún, ¿Dejarimos que alguien que no sabe nada de los aspectos técnicos dirijiese nuestro transpante de hígado?.

Lo que está claro, que al final en todo proyecto es muy importante que haya una persona técnica, preparada, que sirva de guía a los demás miembros del equipo y que pueda tomar una serie de decisiones técnicas sobre por dónde debe de ir en el equipo; un lider, alguien a la que gente siga.

Esta persona creo que lo más conveniente es que sea el jefe de proyecto, salvo igual en proyectos grandes donde hay una labor muy alta de gestión y pueda ser muy útil que convivan los dos roles, el gestor y el técnico, pero cada uno es su "parcela".

Aún así, en mi opinión, todo persona con un puesto de responsabilidad en un proyecto, ya sea en la parcela de gestión, en la técnica o en ambas...debería haber pasado alguna vez por las "galeras" y saber lo que es desarrollar y cómo van tb las cosas por ese mundo... No sé si me estoy explicando, pero lo que quiero decir es que no veo que pueda haber gente que sea jefe de proyecto y no entienda nada de cómo se está haciendo y que simplemente sea un gestor, un gestor de algo que no entiende?? Espero haberme explicado..

Sobre la encuesta que comentas, tb tendría en cuenta que el término jefe de proyecto se aplica de muchas maneras y muchos no se ciñen a la definión que tu comentas, la de llevar el día a día del proyectos.

Otro tema es la cultura empresarial que veo. Los desarrolladores valoran mucho el tema técnica, más bien sólo valoran eso, pero en cambio desde otros esferas se valora el tema gestión, no dándole importancia al tema técnica, incluso considerándono poco importante ( Te podría contar alguna experiencia personal.. ). Al final volvemos a temas recurrentes, que es que hay que tiene que cambiar mucho de la cultura empresarial.

Y por último, tb tendría quiero mencionar que cualquier técnica no vale para jefe de proyecto. Un jefe de proyecto le veo que tiene que ser un buen técnico, pero un buen técnico no tiene por qué ser un buen jefe de proyecto.

Ibon.

A menudo imparto formación sobre gestión de proyectos. Los perfiles que me encuentro en estos cursos

MMmm pero un jefe de proyecto 100% técnico no creo que sea lo ideal. Porque, quien gestiona? el mismo, pero quizas no lo haga del todo bien.

Es cierto que es necesario un Lider Técnico, entonces creo que pueden convivir el Lider Técnico con el Gestor. El Gestor nunca tomaría decisiones técnicas y el Lider Técnico no debería estresarse con aspectos que estén más allá del proyecto.

Siempre voy a recordar una charla mía (Lider Técnico [LT]) con el jefe de proyecto (100% gestor )

LT: ".. y es por esto que aqui lleno un DataSet.."

G: "Noooo un DataSet noooo!!!"

LT: "Porque no? pero.. eh.. sabes que es un DataSet?"

G: "mmm algo.. a ver explicamelo porque lei por ahi que no era nada bueno.."

Resumen: prefiero un Jefe de Proyecto Técnico.

Bueno, un jefe de proyecto técnico es lo ideal...si el proyecto no es para una empresa puramente comercial, bancaria, etc. Quiero decir que en las empresas cuyo negocio no tiene nada que ver con la tecnología, los grandes proyectos tienen una componente política muy fuerte, y en este caso el negocio sólo va a confiar en uno de los suyos. Lo ideal es un buen Jefe Técnico con un buen gestor,  que confie en el Jefe Técnico y le apoye ante la empresa, y viceversa, que el gestor se vea respaldado ante el equipo técnico. Parece difícil, pero ocurre muchas vece, cuando hay buena sintonía entre jefe Técnico y gestor. Cuando es así, todo va suave. Si no, el proyecto es un infierno

¡Que guay que saques aquí este temita que tú y yo hemos hablado por encima en alguna ocasión!.

Voy a recordar a un jefe que tuve (que no se si leerá este blog, pero le molaría por las cosas que se cuentan) y que no había estudiado una carrera de informática. Esta persona para mí, ha sido uno de los mejores jefes de proyecto que he visto y que he tenido, porque no siendo puramente informático, se ha inquietado siempre por los aspectos técnicos.

¿Que dos aspectos resumo de esta persona?. Su valor de gestión era incomiable, y a su lado aprendí muchísimo, pero luego, técnicamente era una persona buenísima e inquieta, siempre quería aprender... así que digamos que era gestor por el puesto que ocupaba pero muy técnico, de manera tal que los problemas que surgían en el proyecto, eran entendidos perfectamente y se solucionaban más rápidamente.

Sin embargo, estoy completamente de acuerdo con el comentario de Ibon, de hecho siempre lo digo yo también aunque de otra forma... un poco más soez, y es que como digo yo, para saber a que sabe o huele la mierda, primero hemos tenido que comérnosla o trabajar cerca de ella. Es un poco duro dicho así, pero es la forma de decir lo mismo que Ibon, es decir, que primero creo que se debe pasar por el esalafón más bajo (galeras) para ir poco a poco progresando, y de esa manera, el gestor (el que ha llegado ahí), ha pasado por la parte técnica, pero aún y así, creo que el gestor, además de ser técnico, debe reunir las cualidades suficientes de la inquietud por la parte técnica, porque la evolución de la parte técnica es constante, y esa evolución debe ser un compromiso del gestor/técnico, por lo que yo veo esta tercer pata en el comentario de Rodrigo, que es la inquietud por la tecnología. :-)

Así que resumiendo lo dicho hasta ahora y lo que comento, yo veo que el gestor debe ser técnico, debe haber llegado ahí pasando por todos los eslafones posibles (desde las galeras), y debe tener pasión e inquietud por las tecnologías.

Creo sinceramente que un jefe de proyecto debiera ser ante todo tecnico, por que sabe que terreno pisa, y mas importante, sabe que terreno pisan sus desarrolladores.

Pero sobretodo, lo mas importante es la labor psicológica que debe realizar esa persona, es la parte posiblemente mas importante de todo el proyecto. Hacer un grupo de trabajo estable, un entorno no hostil, donde la gente sea colaborativa. El es la imagen de apoyo, la supuesta persona que sabe por donde debe salir cuando el proyecto esta trabado (aunque no este seguro de lo que dice, pero que de esa imagen de que si sabe lo que acaba de decir jeje)

A fin de cuentas, un jefe de proyecto debe ser compañero, gran repositorio de soluciones, el gestor de los tiempos de trabajo, y el psicologo tecnico del entorno de trabajo.

Un saludo. Carlos.

Creo que un jefe de proyecto como ya se ha comentado debe haberse formado en las galeras. Yo realmente no concibo un jefe de proyecto en tecnologías de la información que no tenga un perfil técnico. Es la mejor forma de conocer la problemática real de los desarrolladores.

Pero dicho ésto, comentar que un jefe de proyecto con sólo pérfil técnico no es suficiente. Como has mencionado Rodrigo, la verdadera labor del jefe de proyecto es: "el trabajo el jefe de proyecto no es hacer que la gente trabaje, sino construir el entorno que haga posible que la gente trabaje". Y para ello hacen falta algunas dotes de liderazgo para dirigir eficazmente al grupo. Y cuando "dirigir", no digo "mandar", sino tomar en algún momento las decisiones oportunas, y sobre todo saber hacer motivar en cada momento al grupo. Lo bueno es que con formación, una persona originalmente técnica puede llegar a aprender cuestiones puramente de gestión.

En resumen, me inclino hacia un jefe de proyecto eminentemente técnico, pero con formación en dotes de gestión de grupos.

Yo tras haber pasado por manos de varios de los dos estilos (técnicos y no técnicos) cláramente me decanto por un jefe técnico. Quizás con la frase que más estoy de acuerdo con Rodrigo es con que la motivación necesaria para la productividad del desarrollador debe ser producida gracias a un planteamiento tecnológico claro, y este tiene que ser desarrollado por el jefe de proyecto (o en su defecto, por el lider técnico). Lo que está claro es que el respeto que un desarrollador tiene hacia un gestor viene bastante relacionado con el nivel técnico del mismo, sin duda alguna, porque si no fuera así, ¿cual sería el referente del desarrollador?

Obviamente nadie pide un 'jefe de látigo', pero si no hay categorías y responsabilidades claras en el aspecto técnico, nunca podrá haberlas en la gestión, puesto que esta se convertiría en caótica, y cuando una nave es ingobernable, nunca llegará a buen puerto ;).

Empezaré por una obviedad: no hay reglas que valgan para todo. Es decir, las características de cada proyecto: tamaño, plazo, complejidad, ambiente político, multiculturalidad, etc. deben condicionar las características que deberá tener el jefe de proyecto a elegir. Obvio que en un proyecto de 2 meses y 3 programadores el jefe de proyecto tenga un alto conocimiento y experiencia técnica. ¿Y en un proyecto de 1 año, 20 programadores de 4 nacionalidades distintas y diversidad tecnológica? Un proyecto puede ser muchas cosas y por lo tanto puede requerir competencias y habilidades distintas. Lo importante es ser consciente de esto y hacer un buen "casting" de todo el equipo.

Yo creo que es condición necesaria, pero no suficiente el tener conocimientos técnicos (altos). Además debe de tener otra serie de características y conocimientos, que le permitar gestionar bien sus recursos. Comparto la opinión de Rodrigo.

Hace años estuve durante un tiempo de jefe de proyectos, en aquella época (bueno más bien antes de llegar a este cargo), estuve muy implicado en formarme en conocimientos de negocio, de gestion de proyectos, de recursos humanos, etc... con la intención hacer mi trabajo lo mejor posible. Y la verdad me sentía bastante cómodo, sobre todo porque cuando había ciertos problemas técnicos, me ponía con los programadores a resolverlos y ayudarles (y eso que realmente no me lo permitían), lo que hacía que mejorasen las relaciones y la unidad del equipo. Eran equipos pequeños, y mis conocimientos e implicación me ayudaron bastante, entre otras cosas, a evitar los tan poco deseados retrasos.

Ahora, a mi hay una frase que me han soltado alguna vez sobre este tema, gente con opinión contrara, y que siempre he intentado defender y argumentar: ¿ Necesita un arquitecto saber poner ladrillos para hacer bien su trabajo ?

Yo creo que es diferente el caso, cosa difícil de hacer ver a alguien que defiende la postura contraria.

Y bueno ya que me pongo estos articulos de otro excelente blog de Jorge Fernández González paisano de BCN.

La metodología como caballo de troya

http://sistemasdecisionales.blogspot.com/2006/12/la-metodologa-como-caballo-de-troya.html

¿Cuando puedo aplicar una metodología ágil?

http://sistemasdecisionales.blogspot.com/2006/10/cuando-puedo-aplicar-una-metodologa.html

7 Paradigmas a romper para ser ágiles

http://sistemasdecisionales.blogspot.com/2006/08/7-paradigmas-romper-para-ser-giles.html

A ver si se invita a algo por la publicidad... jejeje

Hola Rodrigo,

El link que has puesto va a la página de descargas de los ejemplos y libros en pantalla de SQL Server... ¿seguro que este mapa se encuentra allí?

Estoy deacuerdo con todos vosotros, pero pienso en el tiempo invertido, en mi caso mi equipo de desarrollo es muy pequeño y tengo que variar mucho el diseño, pues hay que hacer todo el trabajo, incluido el analisis, el problema radica en que muchas veces el cliente no tiene clara las necesidades, y vas implementado nueva funcionalidad a medida que ven funcionando la aplicación, pues es en ese momento y solo entonces cuando se dan cuenta de que falta esto o lo otro, se que este es un error muy común a la hora de diseñar aplicaciones, pero seamos serios, es mi realidad y la de muchos desarrolladores, enfrentarse a proyectos con poca gente, muy largos en los que las especificaciones cambian acompañadas al desarrollo, esto me obliga a perder mucho tiempo con las pruebas unitarias, por ejemplo cuando incluyo un campo nuevo en un procedimiento almacenado o simplemente cuando inserto un campo nuevo en una tabla.

Entiendo que al final lograremos un código de mas calidad, pero a veces hay que balancear para conseguir un buen rendimiento. Ademas si realizo las pruebas unitarias una vez he trazado la linea básica del proyecto, pierdo una de las premisas de Agile, que te aconseja realizar la pruebas unitarias antes del código.

Otro de los problemas con los que me he encontrado es que algunas veces las pruebas unitarias tienden a alterar mi codigo, por ejemplo en el caso de los mock, no puedo utilizar pruebas unitarias con clases estaticas ya que tengo que implementar un interface, asi que las pruebas estan condicionando mi código.

Pero sigo creyendo que son un primer paso para mejorar la calidad del código, aunque pienso todavia tienen que evolucionar bastante y son dificiles de adaptar en entornos de desarrollo similares al mio.

Excelente recurso!

Saludos,

Rodrigo,

decime la verdad vos tenes algun tipo de acuerdo con Amazon? porque en mi caso, sos la referencia tecnica de los libros que voy adquiriendo (santa claus y amazon estan contentos con vos). Te cuento que lo tenia en mira desde hace un tiempo, pero me has dado la excusa para comprarlo.

Ahora me toca alternar la lectura destructiva con la tecnica para poder compartir las experiencias de desarrollo con VSTS.

Muchas gracias !!!!

Creo que lo dejastes clarísimo :)!

Por cierto no puedo ver este link: http://www.microsoft.com/about/legal/useterms/default.aspx. :S. Y lo mismo me paso cuando Unai lo referencio, y ahora tu lo referencias dos veces :S, pero no lo veo :S.

P.D.: Como sabes que no leen tus post hasta el final *-)

Saludos,

Chapó

Holas,

Pues yo los tengo mas largos... jejejeje

Entrad y lo vereis! lo siento no puede resistirme...

Por cierto, alguien puede explicarme las licencias por volumen que se entregan con las subscripiones? La verad es que a mi me da respeto instalar Vista y todos los que conozco se lo instalan en particiones diferentes a las de trabajo. Puedo entender que temamos a lo que desconocemos pero quizas Microsoft no nos ayuda mucho con unas explicaciones un poquito mas claras de los requerimientos y licencias de instalación. Todo esto sin hablar de la pesadilla que puedes tener con los controladores sobre todo para 64 bits.

Saludos.

que resquemor!!!

ya tuve una discusion similar a esta y tuve que buscar esa información tb con un objetivo similar al tuyo: desenmarañar una mente enmarañada ... pero, me quedo una duda: cuantas licencias tenemos nosotros con la subscripción MSDN? Tecnicamente se supone que tenemos 1 serial con 5 activaciones, y segun la lista de keys que puedo generar, puedo generar un serial para cada edición de Windows Vista que hay... vamos asi a lo sencillo 5 x 5 = 25 activaciones ... lo de las 5 activaciones viene dado por las activaciones que permite cada serial, que segun nos comentaron en el programa Beta de Windows Vista eran ese numero, cinco... pero no se si se quedo solo para la Beta o tb para la RTM.

Total, que esto lo digo porque yo tengo Windows Vista instalado en dos maquinas distintas... dos veces la Ultimate, y me ha dejado activar las dos y funciona todo perfectamente en las dos maquinas. Sin embargo, se que si intentas activar una key que se ha pasado de activaciones no te deja hacerlo. Por eso pienso que las activaciones son  5, ¿pruebo?

PD: estoy en bilbo esta semanica!

El tema de las licencias para productos de esta magnitud es un poco como la declaración de la renta.

Creo recordar que fue en uno de los libros de la serie de La Fundación de Asimov donde comentaba algo así como que un gobierno debía hacer que la recaudación de impuestos fuera todo lo compleja posible como para recaudar el máximo de cada ciudadano, pareciendo a la vez lo más justa posible para cada uno de ellos y lo suficientemente sencilla de realizar como para que la pudiese hacer cada uno en un tiempo razonable y sin errores importantes, ahí es nada...

La cantidad de escenarios que se quieren cubrir con una licencia de este tipo es enorme y, si habéis seguido un poco el tema desde las betas, han reculado en un par de aspectos que querían incluir ya que afectaban a un grupo importante de gente que no querían 'enfadar' demasiado, como son los usuarios que se montan sus propios PCs y les cambian componentes (como yo!!!, por ejemplo: http://www.dvorak.org/blog/?p=7512).

Cosas como esta generaron la correción del modelo de licencias que mencionas en el link del blog de windowsvistablog.com.

Alejandro

Hay un tema que no habéis mencionado, y es la tremenda diferencia de precio entre las licencias OEM y las Retail.Eso me lleva a pensar que comercialmente, se quieren potenciar las OEM. Hasta aquí lo veo lógico... es más efectivo "presionar" al integrador para que incluya la licencia cargando un coste muy bajo en el propio precio del aparato, que "presionar" a cada uno de los compradores para que se gaste un pastón adicional al propio pastón que le ha costado el equipo (el comprador es más proclive a gastar una suma mayor de dinero de una sola vez, que gastar dos sumas grandes de dinero).

Lo que no me gusta, y no me gusta del mundo en que vivo en general, es que estos términos practicamente te obligan a renovar de equipo por completo cada ve que te toca renovar de sistema operativo. A mi me gustaría que quedase muuuucho más clarito, qué significa EXACTAMENTE un equipo nuevo. ¿Es nuevo un hardware al que le cambio el porcesador? ¿la placa madre? ¿la memoria? ¿el monitor es parte del equipo? ¿y los altavoces? ¿y la alfombrilla del ratón? (esto último parece absurdo, pero habría que aclararlo).

Si queremos vivir en un mundo "limpio" y que "recicla", hay que empezar por reducir la chatarra informática que generamos. A mi me gustaría poder ampliar mi ordenador cambiando únicamente el hardware necesario cada "x" años, pero la consecuencia del modelo de licencias de Windows es que ya he dejado de hacerlo, y cada "x" años compro un ordenador nuevo con su licencia OEM. Hago números y es más barato que una licencia retail... ¿pero no es un poco absurdo? ¿no es más caro en términos medioambientales?

Si es que a veces, los locos son los galos, los romanos, y hasta la madre que parió a Peneque. Que mundo más raro.