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.

ninguno

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.

Bueno, creo que también hay un factor que influye en el tipo de jefe de proyecto más recomendable para un equipo: el tamaño tanto del equipo a gestionar, como de la organización en la que se encuentra.

En una gran organización hay mucha más política contra la que lidiar para "proteger" a tu equipo y que peuda realizar corectamente su trabajo (más gestión pro tanto) y en un equipo grande también será dificil etar al tanto de todas las decisiones técnicas, y se necesita más labor de gestión y coordinación (con lo que vuelve a necesitar un perfil más de gestión).

De todas maneras creo que un jefe de proyecto puramente de tipo gestor puede funcionar en cualquier equipo si este confía en las decisiones técnicas de su gente (ya saldrá algún lider natural en el plano técnico), pero un jefe de proyecto puramente técnico no funciona nada bien para ningún proyecto.

Eso sí, como ya dicen antes, para mi también es muy importante que haya estado "en galeras" también. No vale un tipo que ha hecho un MBA y nada más terminar se pone a dirigir equipos, si nunca antes ha sido dirigido y puede discernir lo  que "se siente" bueno o malo. Se necesita alguien en <a href="http://najaraba.blogspot.com/2006/11/la-confianza-y-las-metodologas-giles.html">quien confiar</a>, en cualquier tipo de metodología de proyectos realmente.

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.

No estoy de acuerdo con esto:

Sobre el malestar de Rafael por no poder leer la licencia ante de comprar, está totalmente injustificado, puedes encontrar cualquier licencia de Microsoft aquí: Retail Software License Terms. Además, si no aceptas los terminos de la licencia puedes devolver tu copia de Windows Vista.

En ninguno de los comercios de informatica que conozco te devuelven el dinero de la compra si el software ya está abierto. Sólo te lo cambian por uno igual por "defecto de origen". Asi que si, supongo que Rafael tiene razón. Lo que no se es si esto en españa es ilegal o no.

Saludos!

Hola Pirri, hasta donde yo sé (y si no me equivoco, claro) la legislación española establece que tienes un plazo de 7 días para hacer devoluciones. Que te pongan más o menos pegas, eso ya es otro tema (en El Corte Ingles por ejemplo, casi nunca hacen preguntas), y por ejemplo el conocido letrerito de "no se aceptan cambios ni devoluciones" es totalmente denunciable. Otro ejemplo que todos hemos visto por la tele, todos los años nos recuerdan que en época de rebajas DEBEN aceptar que pagues con tarjeta, y el género que te venden NO PUEDE tener defectos o taras. Y si nos lo recuerdan es porque pasa. Los comerciantes muchas veces no cumplen la legislación.

Saludos

Pablo,

La legislación española no dicta que los productos se puedan re-embolsar por el dinero. Únicamente dicta que en caso de no funcionamiento de acuerdo con las características indicadas, se puede o bien re-emplezar por otro igual o en su caso devolver el dinero si el primero no fuera posible. Obviamente, las tiendas son libres de tomar decisiones y cuando se trata de software, al igual que música y videos, nadie es tonto y no te van a devolver el dinero una vez abierto. Si te lo cambian. Yo jamás en mi vida he podido devolver software ni música en Corte Inglés ni en ninguna otra tienda. Por internet y en empresas extranjeras no hay problemas. Incluso hay algunos que publicamente te dan xx dias de prueba.

Bueno, Gorka, el problema de las actualizaciones de hard suele ser otro: que, sencillamente, en un año y medio/dos los componentes dejan de ser compatibles y entonces te ves igualmente abocado al cambio, sino de todo, al menos de buena parte del equipo. Y si ya trabajas con portátiles, que resultan más complicados de actualizar por el usuario, pues...

Lo de las 5 activaciones por serial es correcto pero, no sé por qué, a partir de la primera siempre tengo que llamar por teléfono para realizarla, porque online no hay forma...

Ya se que no es relevante a este asunto, pero ya que muchos de los que están aqui trabajan en Plain Concepts, alguien me podría decir porque su web no funciona en FireFox?

Hola Paco.

Tendremos marcada esta "queja" que nos haces llegar sobre FireFox.

Se agradecen mucho tus comentarios, y ten por seguro que tendré en cuenta esto que comentas.

Como bien dice Rodrigo andamos a tope, y la Web de Plain Concepts es un canal de comunicación muy importante que debe estar abierto a todas las personas con independencia del navegador Web que posean.

Muchas gracias por tu comentario.

Un saludo cordial.

Si sirve de algo... en Opera 9.02 funciona perfectamente :)

Saludos

Muchas gracias por ese detalle también Pablo.

Claro que sirve. :-)

Esta vez has dado en la diana con el asunto en cuestión.

En lo que es mi experiencia como desarrollador me he encontrado que

el motivo de que muchos proyectos fracasan es precisamente

lo que dices de que una persona no técnica acabe tomando decisiones técnicas.

Otra situación que me he encontrado es Jefes de Proyecto preguntándome cuestiones técnicas,

lo cual respondo encantado,

pero evidentemente supondría para mí una motivación mucho mayor

el estar a cargo de una persona de la que puedo aprender.

Una vez un directivo de una empresa me dijo: es mucho más fácil encontrar un perfil

analista-consultor-jefe (formación en económicas-empresariales-master) de proyecto que un

perfil de buen técnico (formación técnica).

En mi experiencia una de las principales funciones que hace un gestor de proyectos es planificar y estimar la duración del proyecto, con alguna desviación.

Sin embargo muchas veces se da menos importancia o simplemente se ignora un análisis de riesgos: que probabilidad hay

de que nuestras estimaciones fallen por completo y que hacer en este caso.

Para mi es obvio que cualquier pelele es capaz de hacer una estimación más o menos fiable de cuánto va a durar un

proyecto. No hace falta ser licenciado para eso. Sólo tener en cuenta ciertos criterios que la experiencia y

algún que otro master nos descubren.

Pero tener que evaluar riesgos es otra cosa muy distinta. Hay es donde o se tiene un perfil técnico, o estas andando por tierras movedizas.

Holas Rodrigo,

PORFAVOR CUANDO ESCRIBES UN LIBRO SOBRE TEAM FOUNDATION Y TEAM SERVER!!!

Te prometo que me tienes el primero cuando salga y comprarlo. Y si es posible que le eches un garabato jejeje

Gracias porque tus explicaciones son genialmente claras.

Saludos.

Hola Rodrigo.

Hace un tiempo escribi un post relacionado a MONO y pues deje la descarga de un video sobre una conferencia que hizo el padre de esa tecnologia (Miguel de Icaza) miralo y me dices.

aqui esta el link: http://geeks.ms/blogs/jberrocal/archive/2006/11/22/monologo-de-icaza.aspx

Saludos

Yo no voy a comentar nada sobre el video (ya ví en su día tu post Juan Fco.).

Sobre la productividad en herramientas de desarrollo, hay que ser justos y admitir que llegar a la altura de Microsoft respecto a sus avances sobre la productividad en el desarrollo de aplicaciones .NET es difícil... pero siendo Mono un proyecto que surgió de una idea de código libre, debo admitir que han hecho cosas formidables, aunque aún quede mucho por hacer como es lógico.

Estos CDs/DVDs tipo live vendrán muy bien sin dudas. :-)

Cita: "Es un pena que estos chicos siempre vayan muy por detrás de la implentación de Microsoft y que no tengan nada que se acerque ni de lejos en productividad a Visual Studio, pero sin duda están haciendo grandes avances."

Hombre Rodrigo, me perdonarás pero la gente que está, de una manera u otra, vinculada con Mono, llevan bastante tiempo quejándose siempre de lo mismo: Que no llegan más lejos porque MICROSOFT NO LES DEJA. Sin ir más lejos, toda la implementación de Windows Forms, precisamente de lo que más ha cojeado Mono desde siempre, es el mejor ejemplo de ésto. Microsoft es "demasiado opaca" y no permite que la gente de Mono acceda a según qué cosas que quizás sean clave.

Eso si, estamos de acuerdo en que para batir o incluso a Visual Studio como herramienta, va a haber que sudar mucha tinta... Lo único que parece haber funcionado es Netbeans/Eclipse y en general lo relacionado con Java. Porque Kylix (el Delphi de Borland para Linux) nunca jamás se comió un "torrao"... y lo abandonaron.

Y he aquí un problema: La gente vinculada a Linux y el OpenSource no soporta ni concibe la idea de pagar por el software. Te miran como si fueses subnormal cuando les dices que has pagado por el antivirus (por ejemplo). Y yo vengo diciendo desde hace mucho tiempo que nos estamos (en general, la gran masa de los usuarios)acostumbrando a la idea de que "software=gratis".

Pero eso seria otro tema... ;)

Saludos

"Las retrospectivas que no resultan en cambios son esteriles y frustrantes".

Rodrigo seguro que lo puede explicar mejor pero como yo lo veo es que si en la reunión salen una serie de punto de mejorar para evitar problemas que hayan surgido durante el sprint o que pueden ayudar a hacer que sea más productivo el sprint habría que intentar aplicarlos, porque sino no se verá nada útil la reunión. Se podría pensar...Para que vamos a hacer una reunión retrospectiva si no sirve para nada.....

Pues desde mi punto de vista veo que están muy lejos de poder ofrecer lo que actualmente ofrece Microsoft, sobre todo en cuanto a la productividad se refiere y si tengo que elegir, no tengo ninguna duda de lo que elegiré...Prefiero el "original".

Esto no quita que el trabajo y lo que están consiguiendo esté muy bien, pero es la vida real y cada uno tiene que mirar por sus intereses :-)

Buenas, señor!

Genial noticia!

No es necesario esperar hasta el lunes, ya esta disponible.

http://paulosay.spaces.live.com/blog/cns!7CC9F2B7406F44D0!690.entry

He leido en blogs que tarda más en instalarse que el Windows Vista, especialmente si usas Resharper.

Así que parece una buena decisión instalarlo por la noche. Por aquello de no gastar media jornada laboral sin poder utilizar Visual Studio.

Microsoft Visual Studio 2005 SP1, no sólo trae parches, cabe recordarlo siempre para mentes desviadas

estoy total acuerdo, en la empresa donde prestada asesoría para desarrollar un software, me dieron el tiempo para planear todo, todo iba bien, una buena arquitectura, patrones de diseño claro y definido; cuando todo se empieza a caminar y comienzo a desarrollar el aplicativo, me cuenta al mes que tienen la obligación de terminar el software el 1 enero de este año. QUE BARBARIDAD!!!!!!, un software en dos meses???, ese el problema de un jefe que no sabe de software...y lo más triste es que le presto asesoría MEDIO-TIEMPO.

La crisis de software se dá en dos puntos:

-el programador conformista(nunca se pregunta como optimizar o mejorar lo que hace, solo si funciona, dejemoslo así).

-el jefe que sabe más chatear que de arquitectura de software.

Saludos de COLOMBIA.

p.d: este es el blog que más frecuento, excelente.

p.d2: lo del problema mencionado arriba, tocó(obligatorio) quitarle las buenas arquitecturas, aunque se aplicaba el desarrollo más rápido, en dos meses no era lo mejor, si hubiese más tiempo, la paradoja que menciona es aplicable, siempre que sean más de 4 meses, ya que uno gasta los primeros meses en la arquitectura.

Casualidades tiene la vida... justo depués de escribir sobre las iteraciones y las áreas en Team Foundation

Casualidades tiene la vida... justo depués de escribir sobre las iteraciones y las áreas en Team Foundation

Microsoft Visual Studio 2005 SP1, no sólo trae parches, cabe recordarlo siempre para mentes desviadas

He estado echando un vistazo al PDF, y he de decir que para los neófitos como yo, está muy, muy bien. Muy bien explicado, y da ejemplos reales sobre una aplicación de una metodología, con lo que no solo es teoría.

Muy recomendable.

Gracias por compartirlo, Rodrigo!

Gracias Rodrigo.

Pero espero que ese no sea tu regalo de navida

Saludos

Vía el blog de Rodrigo Corral, la liga a un artículo publicado sobre las experiencias de usar XP y Scrum ...

Al igual que "venero" el libro de Petzold sobre Windows en C (Programming Windows), el que escribió sobre C# hace tiempo me dejó muy insatisfecho. Es un autor muy irregular. Echaré un vistazo a este que comentas a ver qué tal...

Un abrazo, y felices fiestas :)

no encuentro el directorio ke dice AeDebug llego solo hasta HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion

porke despues no esta ese directorio xD! y trate de buscarlo en la pagina de Microsoft y decia ke debia entrar a este directorio ke tampoco en contre y llegue donde mismo HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices

tampoco encontre el ke dice RunServices porfa ayudenme xD!

Las personas, independientemente de la esfera en la que se encuentren, tienden a confiar más en aquello que conocen o con lo que se pueden comunicar sin problemas. Los desarrolladores confían más en la persona que tiene conocimientos afines a los suyos, y los altos directivos provenientes de carreras alejadas de los aspectos técnicos del proyectos tienden a confiar en el cumplimiento de los plazos e indicadores marcados en las planificaciones u objetivos comerciales o de mercado.

Si el foro en el que se tiene que defender, explicar o plantear un proyecto esta conformado por comerciales, marketinianos, financieros y demás personas alejadas en la mayoría de los casos de los aspectos técnicos, evidentemente se necesita una interfaz de comunicación "gestora", con indicadores y números que en la mayoría de las situaciones ofenden a los técnicos.

Si el foro es el de un conjunto de desarrolladores que deben de cumplir un plazo y que sienten que nadie les entiende o apoya, el perfil técnico es necesario ya que debe apoyar, dar soporte e incluso aportar soluciones a problemas que un técnico no solventa en un momento determinado (motivado por que lleva 10 horas seguidas trabajando, por ejemplo).

Lo que está claro para mí es que el jefe de proyecto (o los jefes de proyecto) deben ser aquellas personas que defiendan el proyecto en los distintos frentes de la mejor manera posible para que el proyecto cumpla su objetivo. Un proyecto puede ser un fracaso tanto si los desarrolladores no son liderados adecuadamente, como si el proyecto elaborado (por muy bueno que sea a nivel técnico) no transmite confianza y fiabilidad a quien sólo quiere escuchar que se ha conseguido el objetivo.

No podemos pedir a un técnico que entienda por qué sólo le miden por indicadores como puntos funcionales, plazos comerciales o incluso número de líneas de código, en lugar de por la calidad, estabilidad y fiabilidad del software que desarrolla. Tampoco podemos exigir a una persona con un perfil puramente gestor o político que entienda o decida sobre la arquitectura, técnicas, patrones y metodologías a utlizar en la parte técnica.

La jefatura de un proyecto debe estar formado por aquellas personas (o persona) que sepan defender el proyecto en todas las situaciones de riesgo para el mismo. Como siempre, en el equilibrio está la solución buena (recordando que lo perfecto es lo enemigo de lo bueno).

Muy interesante el documento. Describe muy claramente un ejemplo real de uso de Scrum, pero como el libro dice, es la forma en que lo han hecho ellos, que no significa que sea la forma en que otra empresa lo tenga que adoptar.

Muy recomendable leer el documento.

Ibon.

En mi empresa estamos empezando a adoptar SCRUM, y nos estamos basando precisamente en ese libro.

No lo seguimos al 100%, pero la verdad es que es una buena base para empezar. Otra cosa es que sustituyas los post-it por hojas excel (en mi empresa complementamos ambas), pero es una muy buena guia, sobre todo para novatos.

Oye, una duda que me asalta... Hay lenguajes en los que no importa si escribes con mayúsculas o minúsculas, porque no se distinguen. Ahora bien ¿para el compilador de .Net la 'b' y la 'v' son lo mismo?  jijiji...

La cuestión es que si eres jefe de proyecto (como es mi caso) no de un proyecto sino de unos 12-15 proyectos llega un momento en que dejas de ser técnico, dejas de formarte en temas de programación y acabas siendo un gestor que sabía programar pero que se ha quedado obsoleto. Tu misión consiste en proporcionar a cada equipo de desarrollo todo lo que necesita y realizar una tarea de seguimiento del proyecto para dar la cara ante el cliente. Total que estas en medio, entre el cliente y el equipo de desarrollo y esto, en ocasiones te obliga a tragar carros y carretas (con unos y con otros) para que al final cada proyecto termine dignamente.

La cosa no es fácil y ser técnico y gestor a la vez es un sueño, a no ser que trabajes en una empresa balneario, con tiempo para estudiar y probar nuevas tecnologías.

Saludos

Hola Rodrigo!

Te leo desde hace tiempo, y aunque solo he puesto dos comentarios, soy muy fiel a tu blog, ya que gracias a él hemos empezado a usar SCRUM en mi empresa.

Muchas gracias por la info ... es una pena que no uséis J2EE, que si no... eso si, ya he informado a un par de personas interesadas en la oferta.

hola Rodrigo,

Ahora mismo no me acuerdo de memoria el código fuente en Java, pero tras pegarme con ¡hasta 8 hilos a la vez! y unos acababan antes que otros (imposible de depurar, pero lo conseguí), conseguí que no se quedasen abiertos. Después, realizas una join de ellos y después, les interrumpes(Interrupt). Por supuesto, esto debe ser controlado.

Desconozco si tal funcionamiento es igual de bueno para .NET porque no me he pegado mucho con ellos en esta plataforma; pero ya sabes que te pegas con lo que la universidad exige.

agur!

PD: A punto de obtener el punto 3 del reto del "chico maravilla" ;). A ver si lo acabo antes de que déis la solución, pero como tengo que estudiar y hacer trabajos, no tengo demasiado tiempo.

Vale, consegui desactivar el debugger del VS2005, ahora en lugar de saltarme un aviso del debugger de VS2005 me salta un simple error (el tipico de la crucecita blanca en circulo rojo...) que solo me da la opción de aceptar. es posible desactivar este error tambien... Hasta que no pulso sobre aceptar la pàgina web no me devuelve ningún error.

alguna idea? gracias.

tienes documentacion mas extensa de su uso.

Cuando imparto formación sobre gestión de proyectos suelo preguntar a los asistentes cuantos proyectos

Hola Rodrigo,

Lo que hablas de la gestión de proyectos se puede extrapolar a aspectos de las ITs. Por ejemplo, esos empleados con una larga experiencia en la empresa llevan en sus espaldas todos los mantenimientos de los desarrollos y sistemas que ha realizado. Nadie sabe, o no se da cuenta de lo difícil que es acarrear con la responsabilidad de realizar en un mismo mes, tareas de desarrollo y sistemas para una misma persona para todos esos diferentes proyectos. El tema de la pirámide de desempeño es totalmente cierta, porque las personas tienen 2 manos pero nuestro único cerebro por mucho que lo desarrollemos solo puede emplearse en una tarea en un mismo instante.

Saludos.

Hola Rodrigo.

Gran Post. Desde hace algún tiempo llevo encontrandome con gestores de proyecto que más bien parecen superhombres atados a una silla dado que deben mantener el ritmo de 6, 7, 8 e incluso 9 proyectos de una vez.

No es lógico, dada la tabla de tiempo perdido en cambios de contexto que se les pueda exigir un mínimo éxito en ninguno de ellos, pero es así, no solo se les pide la gestión de estos proyectos, si no que también se les exige el éxito en cada uno de ellos.

Pero mi pregunta es: ¿ en que momento debe un gestor de proyecto parar esa ruleta y  decir que no, decir que no puede realizar esa gestión y asegurar el éxito del proyecto ?

Te aseguro que en ciertos entornos, por desgracia, si un jefe de proyecto dice esto con solo 2 proyectos en sus espaldas ... poco tiempo le queda en la empresa, o le asignan a la fuerza ese proyecto y se convierte en un proyecto desatendido.

Desde mi punto de vista, no es tan importante la calidad de cada uno de los developers involucrados en un desarrollo como la calidad de la persona que los dirije.

Un Saludo

Estoy completamente de acuerdo con esa tabla ... tanto con otros gestores de proyecto que he conocido, como yo mismo.

Por poner un ejemplo concreto, en estos momentos vamos a comenzar con 3 proyectos simultáneos, que se supone que debo gestionar yo. Menos mal que, gracias a Dios, estoy en una empresa donde mis jefes tienen algo de cabeza (lo que por desgracia no es habitual) y es mas que probable que me permitan delegar la gestión de uno de ellos, para centrarme en los otros dos.

Como bien dices, aqui no hay termino medio: o ayudas o entorpeces.

Saludos!

o ¿cuántos proyectos realmente no lo son? o ¿realmente eres el jefe de proyecto?. ¿No convendría que en esas empresas se aclarasen ambos términos? o:

- El problema es que llamamos a cosas distintas de la misma manera

- El problema es que aún no se valora suficientemente la labor del jefe de proyecto

- Seguimos pensando que las cosas sales por "cojones"

- Nos importa un carajo cuántas horas se tengan que trabajar al día...

¿Cuántas obras puede un arquitecto gestionar a la vez? ¿Dependen del tamaño de la obra? ¿Cuándos desarrollos puede gestionar un IT project manager? ¿de qué depende?

Mil disculpas por tantas preguntas. ¡FELIZ AÑO NUEVO! Enhorabuena por tu blog y por hacernos pensar.

Mi experiencia me dice también lo mismo. Cuando los proyectos se acumulan en una sola persona, éstos suelen perder el control de todo, con lo que o se delega o simplemente se cruzan los dedos esperando que todo vaya bien.

Siempre me ha parecido que aquí, si eres un jefe de proyecto, debes de ser todopoderoso y llevar a cabo un ingente número de tareas. Y parece que eso es lo mínimo que se te puede pedir...

Hola,

Otro problema es el término "jefe de proyecto". En muchas ocasiones se aplica este término a personas que no desempeñan esas labores.

Por ejemplo, tengo el caso de una persona que me comentó que él era jefe de proyecto y que llevaba 15-20 proyectos, cosa que me extrañó enormemente....indagando un poco más, era la persona que solía tener la relaciones con los clientes, prácticamente un comercial técnico o algo por el estilo, pero nada de hacer sgto de los proyectos. Luego había otra sería de gente que era el que llevaba el día a día. Pero él se auto-denominaba jefe de proyectos.

Más de 2 proyectos me parece excesivo, incluso hasta más de 1 puede ser ya mucho. SI alguien lleva más, o no se hace gestión o la hace otro de manera implícita. Por la experiencia que he tenido normalmente no se realiza la gestión...De ahí la calidad de lo que se entrega.

y qué pasa si tus jefes no lo entienden?cedes y callas? Yo creo que NUNCA hay que callarse y siempre hay que exponer lo que se piensa, dando argumentos y si estos argumentos los puedes llevar a dinero mejor que mejor.

Eso sí, mano izquierda!!! Que la primera reacción suele ser de rechazo y los cambios poco a poco. Si aún así no se entiende, te exigen, te exprimen, te....igual es el momento de buscar otras cosas.

Ibon.

Hola de nuevo.

La verdad es que estoy de acuerdo con Angel y con Ibon en que el nombre 'Jefe de Proyecto' o 'Project Manager' se ha malutilizado o puede incluso que mi definición no sea tan correcta como he pensado siempre.

La idea de que las cosas salen 'si o si', 'por cojones', está muy generalizada, y la verdad es que eso normalmente solo genera mal estar en los proyectos, la gente se quema y es normal.

En mi ejemplo que comentaba en la anterior opinión hablaba de un caso que conozco que ha estado 'gestionando' nueve ( señores!! 9 proyectos!!! ) al mismo tiempo. Por supuesto el caso del que nos habla Ibon ... se aleja mucho de mi ejemplo. pero ... ?

Estár en esa cantidad de proyectos significa claramente que no se está alcanzando ni un mínimo de atención a ninguno de ellos...

¿ es eso gestionar un proyecto ? ...

Desde mi punto de vista ... NO.

Un Saludo

Ya eran horas MACHOTE....

Joer que buena pinta tiene el cacharro.

Felices fiestas con tu nuevo juguete Rodrigo.

Curiosa visión tanto de los señores de Oriente como de los originales.

Muy bueno.

Felicidades!!! Te lo has ganado, que sean por lo menos otros cuatro más los que te nombren.

Saludos

Como ya dije a Miguel Jiménez y a Carlos Segura, me alegro un montón por vosotros. Espero que sigáis este año en la misma línea que en el pasado.

Un Saludo

Que bien hemos empezado el año ehhh ...

Felicidades.

Well, today the first day of 2007,I Want to thank all the people who read this blog for this stats. Also

Pues, como ya le he comentado a Miguel Jiménez, MUCHAS FELICIDADES Rodrigo! Lo vuestro sí que es dedicación y sacrificar vuestras pocas horas libres. Ya me gustaría a mí poder ayudar tanto en la comunidad (creo que con la décima parte me conformaba), pero se me plantea un conflicto de intereses... O mejor dicho, de "compatibilidad".

Digamos que "vida en pareja v1.0" daría un petardazo a nivel de kernel con "pásate 4 horas diarias delante del PC en los grupos de noticias, v2.1" :P

FELIZ 2007!!

Móvil nuevo y renovación de MVP estas que te sales.

Felicidades.

Muchas Felicidades ... Eso es empezar bien el año!!

Un Saludo

Well, today the first day of 2007,I Want to thank all the people who read this blog for this stats. Also...

Enhorabuena Titán de Titanes !!! :)

Enhorabuena y Feliz año nuevo! ;-)

No me extraña tio eres un Crack (Aqunque todavía tus post me quedan grandes, me acordaré de tí y de tus artículos cuando llegue a Jefe de Proyecto) y que menos que eso!!!

Salu2.

ZORIONAK txapeldun y a seguir así, manteniendo el pabellón bien alto!

Feliz año 2007 a tod@s!

SaludoX.

Felicitaciones, y bien merecido titán!

Saludos,

Felicidades titán!!!

Felicidades titán!!!

¡¡¡Campeón!!!

No tenía duda, pero mejor así con una confirmación debajo del brazo.

¡¡¡Muchas Felicidades!!!

¡Que crack!, ¡que titán!. :-)

Que mejor regalo que recibir un correo electrónico de Msft el 1o de Enero con el título [MVP] ¡Felicidades!...

Cielos, otro año de TTTs con Rodrigo de asistente... Enhorabuena!!

Zorionak Rodrigo!!! Esto de Bilbo que bien viene para mi euskera jajaja aunque se va a merecer tanta nominación una pasadilla por Txakoli Simon la semana del 29 de Enero, no??

Enhorabuena titan!! Y feliz año :)

Por si a alguien le interesa también está Araxis Merge, no sé si ponerla por encima de Beyond Compare, aunque también es de pago.

¿Que desarrollador no necesita compara ficheros y directorios? En multiples ocasiones necesito comparar archivos o directorios. Cuando trabajo desconectado del gestor de fuentes en varios equipos, cuando edito un script y de repente comienza a fallar,

Yo estoy 100% de acuerdo con Rodrigo... Beyond Compare seria mi opcion 1 (si no te importa pagar), pero en el PC de casa uso WinMerge }:)

Y es que a falta de las bonitas herramientas de comparacion que tiene Linux pues... };P

jajaja, cuando tenga cuarenta años me haré la cirugía y venderé muchos discos con esta carita mía .. Pues yo también la canto en la ducha ...

Ahora el mejor pelotari de TODOS los tiempos es sin lugar a dusdas Retegui II :-)

carlos.

Ni lo dudes, yo te invito a comer.

Carlos.

Para seguir formándose en este tema, me ha parecido interesante este artículo de Eric Gunnerson sobre cómo debemos escribir nuestras propias clases de excepciones:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp08162001.asp

La definición la encontramos en wikipedia, el porqué de la necesidad de usar AJAX, podemos...

La definición la encontramos en wikipedia, el porqué de la necesidad de usar AJAX, podemos...

La definición la encontramos en wikipedia, el porqué de la necesidad de usar AJAX, podemos sacarlo de

La definición la encontramos en wikipedia, el porqué de la necesidad de usar AJAX, podemos sacarlo de

Titán, no se que decirte ya... lo bordas. :-)

Un patrón que, a lo largo de mi experiencia como desarrollador se repite, es que alguien ajeno al equipo

Un patrón que, a lo largo de mi experiencia como desarrollador se repite, es que alguien ajeno al equipo

Que quieres que te diga... me ha encantado todo todo todo lo que dices en este post. :-))

Si.. es más fácil aplicar presión/tensión que hacer una correcta gestión del equipo.

Muy buen post, saludos.

Excelente post, Rodrigo!

Un abrazo - Octavio

Qué familiar me suena lo que comentas...

Muy buen post. La verdad vale la pena leer cosas como estas.

Salu2

Enhorabuena Rodrigo, quizás ya ni te acuerdes de este humilde tocayo (o sí! quién sabe?). Soy Rodrigo, compañero de trabajo de Iván, de Burgos, ahora sí ¿no?. Mi más sincera enhorabuena, hacía tiempo que entré en tu blog pero nunca había dejado un mensaje. Aquí seguimos peleándonos con el Sharepoint y esas cosas que tanto nos gustan. Por cierto, contactaremos para ver si ponemos en marcha lo del TS.

Un saludo y feliz año.

Rodrigo.

Sobresaliente. :-)

Pues no lo había hecho nunca y me lo apunto para mi pequeño intelecto.

Por cierto, me encanta que hayas nombrado a VB 6.0 como "venerable lenguaje". ¡¡¡Así me gusta!!!... ¡¡¡Pero que bien me caes Rodrigo!!!. :-))))

Sobre la cantidad de equipos de desarrollo que trabajan en VB 6.0 aún, es efectivamente bestial. Y los motivos son muy variados, tantos que no sería conveniente enumerarlos aquí (no quiero hacer una contestación más larga que tu post).

Abrazotes.

Hola,

Es indiscutible que la capacidad de integración de tecnologías que ofrece las herramientas de desarrollo de MS es una de las mejores bazas que tenemos. Quizás si los equipos de desarrollo abrazaran estas nuevas metodologías que como en este caso ofrece una mínima inversión a cambio de un máximo rendimiento, muchos de los integrantes de estos equipos no tendrían la sensación de estar desaprovechando su potencial cada vez que tiran una linea de código en VB6. ¿Porque no querer a todos los desarrolladores por igual independientemente del lenguaje que utilicen?

Saludos.

Estoy totalmente de acuerdo con evelardiez, pero porque no queremos mas a los de C/C++ y C#

A mi experiencia para implementar VSTS una de las primeras interrogantes que el cliente tiene es precisamente como se integra el valor de TFS a inversiones o esfuerzos existentes en terminos de desarrollo. Caso de Power Builder, .NET 2003 y claro Visual Basic 6 son muy comunes. En ocasiones empresas de desarrollo de software profesionales no toman la decision de adoptar VSTS por varios motivos, el mas importante el precio jejeje sin embargo tambien por cuestiones de compatibilidad o reutilizacion de lo que ya se tiene construido.

Tu post es para futura referencia. Thanks.

+1 to Scrum :D

Despues de trabajar en un proyecto con SCRUM (y haciendo mea culpa de muchos errores e inconvenientes que tuvimos por ir descubriendo de a poco esta metodología) creo que hoy es una excelente opción para muchos proyectos; aunque despues de mi experiencia aconsejaría lo que bien decis al principio "una vez elegida una metodologia, hay que ceñirse a las reglas que dicta la misma"; porque el resultado de una mala implementacion es igual de desastrozo en CMMI, SCRUM, XP, o hasta en la preparacion de una pizza.

Saludos.

Hola Rodrigo!

Que libro recomendarías para (empezar con/asimilar correctamente) scrum: http://www.amazon.com/s/ref=nb_ss_b/103-5327471-7448658?url=search-alias%3Dstripbooks&field-keywords=SCRUM&Go.x=3&Go.y=18.

Según esa búsqueda hay: 4919 resultados :S.

Saludos,

Y este: http://www.amazon.com/Agile-Software-Development-SCRUM-Schwaber/dp/0130676349/ref=pd_bxgy_b_text_b/002-0946114-5874416, que comentarios te sugiere?

Saludos,

Hola,

Coincido con Rodrigo, es más, debemos estudiar los tiempos de parada que va a tener nuestro sistema, y además siempre debemos tener un plan de "vuelta atrás" por si hubiese cualquier problema. Tened en cuenta que estáis "jugando" con información muy valiosa.

Lo de "siguiente" - "siguiente" va muy bien, salvo cuando hay un problema y no tenemos un botón "anterior", además de hacer ciertas cosas sin tener ni idea de lo que realmente hacen.

Supongamos que necesitamos añadir soporte para Workflow Foundation a un proyecto que no hemos creado

Pero porsupuesto!

Saludos,

Últimamente he recibido esta pregunta en dos ocasiones, en un corto espacio de tiempo, por correo. Además

Últimamente he recibido esta pregunta en dos ocasiones, en un corto espacio de tiempo, por correo. Además

Últimamente he recibido esta pregunta en dos ocasiones, en un corto espacio de tiempo, por correo. Además

Últimamente he recibido esta pregunta en dos ocasiones, en un corto espacio de tiempo, por correo. Además

BIEN, AHI LES VA UNA FORMA FACIL DE DESACTIVAR EL JUST IN TIME DEBUGGER:

METANSE A: HERRAMIENTAS-OPCIONES DE INTERNET-OPCIONES AVANZADAS Y UNA VEZ AHI BUSQUEN EN "EXAMINAR"  

-DESHABILITAR DEPURACION DE SECUENCIA DE COMANDOS-       SELECCIONEN ESA OPCION Y LISTO....

Aupa Rodrigo, ya las felicitaciones te quedan cortas.

A mí me paso, que cuando cría que sabía todo sobre lo que hacía, vino la fase final, "deployment", y en esa fase creo que aprendi más que en los tiempos de desarrollo. Y es obvio que los días de deployment considerado en el project se hicieron semanas...xD

Saludos,

resulta que he borrado la clave de windows que dice mas arriba, luego he probado con las opciones de internet marcando deshabilitar la depuracion, me sigue saliendo el just in time.

Acabo de terminar de leer este libro de Sam Guckenheimer, otro compañero de geeks.ms, Rodrigo Corral

Acabo de terminar de leer este libro de Sam Guckenheimer, otro compañero de geeks.ms, Rodrigo Corral

E La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo

E La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo

E La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo

Hola Rodrigo

Muy buena exposición pero me surgen ciertas dudas.

Imaginemos que un cliente nos solicita que le hagamos una valoración del desarrollo de una solución que en principio se preveé que tenga  una duración de más de 10 meses. Dicha valoración debería de contener tanto la parte económica como el tiempo que tardaría en desarrollarse. El cliente no nos conoce y quería contar con dicha valoración antes de comenzar a trabajar con nosotros.

Según tu experiencia ¿que le entregaríamos, si no es un planning con perfiles y tiempos?.

Recordemos que el cliente no nos conoce no puede arriesgarse a que realicemos una primera entrega que posteriormente no le satisfaga o no cumpla la perspectivas esperadas (si, podríamos decir, “realizaríamos un seguimiento exhaustivo”) pero el cliente quiere ver un global ¿cuanto me costara esta solución con vosotros?. Asemejándolo con una reforma por poner un símil, ¿podríamos plantear la reforma de una cocina al cliente?, le pondremos el fregadero y si queda satisfecho continuamos. El cliente espera un plan completo no puede arriesgarse.

Lo dicho el tema es mas que interesante espero que podamos seguir comentándolo.

Un Saludo.

Holas!

Mi opinión va en dos contextos:

1. Sobre escoger los clientes: Muchas veces es difícil escoger un cliente, pero lo que puedes hacer es recibir un cliente, y abrirle los ojos, como dijo Rodrigo, hacerle ver que es importante para el proyecto tanto como tus servicios; ahora que si el cliente que recibes no se puede transformar, ya de inicio el proyecto tendría pretención a fracasar... y viene la balanza.. tomo el cliente y acumulo un proyecto más a la lista: "porque fallan los proyectos" o simplemente escojo al cliente.

2. Sobre la profesíon y colegiado, que creo que se salio del tema pero se sento una posición: En todo caso se tendría uqe escoger el personal preguntandoles a quienes les gusta programar?, creo que lo mejor sería indepediente del título, es la experiencia y los conocimientos extras, lo que decía rodrigo en un post, sobre "el especialista generalizador". Es que imaginemos si quieres operarte de los ojos: a quién vas? a un oftalmologo, imagíno que vas al oculista, pero además puedes optar por un oculista de experiencia y eso independientemente si es colegiado o no, eso no garantiza que tenga experiencia, pero de hecho que si no esta colegiado te siembra duda. Ahora que pasa si quieres un Lider Técnio en C#?, y he aquí viene la duda, un ing. Informático titulado recién salido de la U te garantiza eso?, nop, un recién colegiado te serviría?, lo que buscarás es experiencia comprobada en proyectos, y la habilidad que pueda tener. La colegiatura te serviría en todo caso para saber que el no miente al decir que es ing. informático... pero de eso a reconocer que es un "especialista" es difícil. Ojo no desprecio la colegiatura... pero dada la situación actual, donde todas las universidad [por lo menos eso pasa en mi pais] ofrecen la carrera de ing. Sistemas, o ing. informática (y todas sus otras versiones), que alguién por ser titulado firme proyectos, creo que el mundo entraría en caos, y se podría colegiar además por experiencia...y que pasa con la gente que no es ing. informática de profesión, pero que si tiene experiencia deberían también ser colegiados... pero entonces quien decide quien se se colegia o no?...se politizaría y se crearian elites como dice Rodrigo, pero bueno .. creo que unas decadas nuestra profesión [no los ing. informáticos, ni los ing. de Sistemas, simplemente hablo de los informáticos] tendrá que evolucionar...

Saludos,

E La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo

Lo cierto es que es la mar de interesante todo esto. Espero que compartan sus impresiones todos los que puedan porque es un tema que como muy bien dicen José Luis y Rodrigo, es interesantísimo.

Leo atentamente los comentarios de José Luis y Rodrigo y a la vez medito y en voz alta (escrito aquí) lo siguiente:

Muchos clientes, quieren "entregables" para ir viendo como va el proyecto (por falta de confianza, por que no nos conocen, porque tienen esa forma de trabajar, porque quieren saber como se están haciendo las cosas y controlar todo, etc).

En la oferta económica, muchas empresas detallan el coste y el porqué de esos costes, proponiendo los entregables en un plan general en el que se detalla además la fecha final de entrega de acuerdo a unas métricas (odio personalmente las métricas estrictas que en muchas ocasiones generan tensiones inadecuadas en un proyecto, adios a la creatividad).

Luego, se pide el detalle del planning del proyecto (Project por ejemplo), con las tareas, el entregable de cada una de las tareas indicadas, su fecha, personas o recursos como dicen los "mal hablados", y eso se asocia con el coste. Es decir, se comprime todo.

De esos entregables, diré a modo de ejemplo que imaginemos que mantenemos varias reuniones con el cliente para la toma de requisitos. Si la planificación del proyecto es completa desde antes de la primera reunión (el comercial de turno puede meter la pata y haber vendido "la moto"), nadie nos asegura que trás la primera reunión, no haya surgido una nueva reunión que hace que el planning se desplace, y que por lo tanto, los tiempos predispuestos no se cumplan ya desde el principio.

YA se que para que te den a veces un proyecto, la oferta debe ajustarse porque estamos en un mundo de competencia voraz, el planning se comprime y los tiempos se hacen irrealizables, aunque no haya más remedio. Y lo peor es que lo sabemos y en muchas empresas se da aún y así con el látigo.

Vamos, que la planificación que se hace en muchos proyectos, nace en mi opinión viciada en la irrealidad más absoluta desde el comienzo. No ocurre en todos los proyectos, pero sí generalmente en los que están basados en tiempos y no en calidad... y el que diga que se puede dar calidad ajustándola al tiempo, creo en mi modesta opinión que no está en la realidad y sí en Matrix.

Lo que sí he visto en otras ocasiones, es que si las fechas se van del planning (que ocurre en el 99,9% de los proyectos claro), es que el cliente mirando la planificación inicial que tenemos muy bien detallada, los entregables y sus fechas, etc, comienza a ponerse nervioso pensando en que los costes derivados de la demora de tiempos caerán a su patio, además no se cumplen las espectativas iniciales vendidas en forma de planning rígido y el proyecto entra en una espiral de tensión que genera siempre unas consecuencias en forma de problemas.

La gestión de proyectos informáticos, es sin lugar a dudas complicadísima. Nadie dijo que fuera fácil lo se. La búsqueda de la idoneidad en abordar un proyecto también es dificilísima, pero creo que hay planificaciones que son contraproducentes y otras que no tanto, y las que tratan de ajustar todo al milímetro creo que lo son, porque siempre hay factores incontrolables (alguien que se pone enfermo por ejemplo o alguien que se va de la empresa cliente o de la que da el servicio), que provocan que un proyecto planificado no se cumpla en tiempos.

La planificación no muestra una imagen fiel de cómo irán sucediendo las cosas, algo que comenta Antonio Quirós (ex-jefe mío por cierto), muestra una imagen de como quieres que sucedan las cosas que es muy diferente.

Yo siempre digo algo cuando se aborda este tema o similar, hay que ser proactivo en lugar de reactivo, y tanto en la proactividad como en la reactividad, es necesaria la misma cosa, un cambio. Y ese cambio debe ser ágil y consecuente... no basta con meter un hito en una planificación y correr la planificación de fecha. Lo siento pero no. La planificación estricta tampoco ayuda. Meter cosas con calzador para no pasarnos de tiempos es un error. Si un proyecto se va de tiempo por la razón "x", el hablarlo con el cliente, exponerlo y ver sus soluciones es más acertado en mi opinión que el meter con cuña esa funcionalidad en el planning... es un conjunto de opiniones nada más. :-)

En mi opinión la historia es el mejor argumento. Es decir. Un cliente típico ya ha "sufrido" potencialmente varios proyectos. Cosas que tenían en común:

- La consultora de marras le muestra la estimación, le dice lo buenos que son mostrándole otros casos de éxito, o su certificación CMMI.

- El cliente asume que estas estimaciones son garantías de algo.

- El proyecto arranca y se van realizando toneladas de documentación, planificaciones en project, etc...

- El equipo de desarrollo va descubriendo lagunas mayores o menores en los requisitos. En algunos casos, asumen cosas. En otros, buscan feedback. En algunos casos, este feedback muestra que los requisitos son incompletos / desviados de la realidad. Aquí la técnica utilizada puede variar. Me he encontrado con consultoras que se acogen a la quinta enmienda (lo que el cliente firmó es lo que va a misa). Y complentan en tiempo algo que le es inútil al cliente, generando insatisfacción en el cliente. Otras consultoras prefieren que el tiempo se vaya al cuerno pero al menos entregar algo que sea una fracción de lo que prometieron, generando también insatisfacción en el cliente. Y en otros casos (que también he visto), las consultoras pretenden que el equipo de desarrollo termine en el tiempo especificado lo que el cliente realmente necesita a golpe de horas extras (aquí sería muy útil una slide de esclavos en galeras), generando insatisfacción en el cliente y en el equipo.

Moraleja: Lo mires como lo mires, acabas teniendo insatisfacción por parte del cliente. Y en algunos casos, también en el equipo de desarrollo.

Si el cliente se siente identificado con esta historia, se le puede explicar que, en efecto, con las metodologías ágiles no se pretende el poder predecir todas las variables (scope, tiempo, calidad). Pero en realidad, si miramos más arriba, si tenemos memoria, descubriremos que las otras consultoras que han venido nos han engañado como a chinos, y tampoco nos han dado lo que queríamos, ni en el tiempo que prometían ni con los costes que esperábamos.

Es decir: Una vez que nos damos cuenta de que con la aproximación tradicional aquello falla 4 veces de cada 5, igual el cliente empieza a ser más propenso a explorar otras vías.

Eso espero.

> ¿ Cúántas veces le han prometido el oro y el moro a un cliente?

> ¿ cuántas veces le han tomado el pelo?

> ¿ cuántas empresas hay que desarrollan buen software?

> ¿ cuántas empresas han fracasado o entregado verdaderas chapuzas?

> ¿ cuántas malas experiencias es capaz de soportar un cliente ?

Es normal que con tantas experiencias malas se quiera "más control" ...sobre todo si empiezas a trabajar con una empresa nueva. ¿ Cómo se asegura el cliente que esta vez va a ser todo diferente?

Ya sé que la mentalidad tiene que cambiar y que el cliente tiene que entender, tiene que hacer...tiene....pero el cliente también desconfía con razón, porque constantemente se le ha engañado. Por eso veo muy complicado el cambiar la mentalidad. Eso sí, otra cosa es que te conozca, que sepa que trabajas bien y que se pueda fiar de lo que le dices.

Por lo demás, el cliente necesita más una estimación que una planificación detallada. Es importante tener una estimación para poder valorar los costes que podrá tener el desarrollo de la aplicación y el tiempo que llevará.

Un saludo,

De CMMI sólo diré una cosa: Coritel (empresa conocida por su desarrollo de calidad) tiene CMMI 5: http://www.coritel.es/publica/main.aspx?processID=dispatch&pageID=149

Eso dice bastante sobre el valor de la susodicha certificación.

También hay muchas empresas con certificaciones varias, ISO 9001, etc. Y claro, este tipo de certificaciones es para muchos básico o fundamental (en fin...), pero en muchas otras ocasiones, muestra esa aparente calidad que les da a los clientes esa tranquilidad y seguridad que no tenían antes (marketing vamos),... y luego llegan los disgustos porque no deja de ser un papel y la realidad queda disfrazada. Con un papel sólo no haces un entregable en condiciones y según las condiciones pactadas inicialmente.

La relación de confianza y colaboración es el camino del éxito como bien dice Rodrigo,... en otras palabras, hacer equipo. :-)

Coritel y CMMI..Aquí cuál es el error? Echamos la culpa a la metodoloía o a la empresa? En la mayoría de los casos dónde está el problema? Para mí generalmente en la empresa, no en la metodología. Otra cosa es que haya mejores o peores metologías.

Rodrigo dice.."La cuestión es establecer una relación de confianza y colaboración que permita abordar los proyectos de una manera diferente."

Con esto totalmente de acuerdo...Sólo digo que cuando a uno le han engañado tantas veces es difícil hacerle ver que tiene que seguir confiando, sobre todo, si no te conoce.

No estoy seguro de cómo se obtiene el CMMI, pero sospecho que es bastante similar a las certificaciones de calidad que conozco. Voy a establecer un símil:

Cuando una persona se pretende presentar a unos exámenes de certificación de Microsoft (o exámenes de universidad, o de casi cualquier cosa. Simplemente que los de Microsoft me los conozco bien), tiene varias opciones. Una de ellas coincide con el propósito del propio examen: Evaluar la pericia de una persona en una determinada materia (luego podríamos hablar sobre si un examen mide o no esta pericia). Es decir, te lo curras, aprendes de que va el tema, y eventualmente apruebas el examen. Simplemente, porque sabes del tema. Pero es que luego alguien se inventó los TestKing (y similares). Y entonces dices: ¿Para qué cojones me tengo que empollar todo el temario? Me miro examenes con preguntas reales hasta que me he visto todas las posibles preguntas. Y apruebas. Ambas personas (el que se lo sabe, y el del Testking) tienen el examen aprobado. Sin embargo, el propósito del examen (demostrar quién vale y quién no) ha sido burlado. Y el sentido ha quedado pervertido.

Del mismo modo, cuando una empresa se plantea enfrentarse a un proceso de certificación, puede hacerlo con una intención de normalizar y mejorar sus procesos. O puede hacerlo sólamente para ponerse una medallita y para ir a sus clientes diciendo: Tengo el CMMI 5. En definitiva, una prueba a la que se someten periódicamente y que no dice nada de la forma habitual de trabajo.

Yo he llegado a estas conclusiones porque lo veo desde dentro. Pero un cliente al que le están vendiendo la moto Coriteles (y similares) continuamente, y le cuentan lo buenos que son, y las maravillosas certificaciones que tienen, y luego lo compara con los resultados que obtienen, tendría que sacar sus conclusiones acerca de la validez de estas certificaciones.

Con eso estoy de acuerdo, tener la certificación no significa nada. Lo que quería decir es que el problema no es CMMI en sí. Yo puedo usar metodologías ágiles ( más bien decir que usas ) y seguir entregando verdaderas chapuzas, y por eso no vamos a decir que las metodologías ágiles no valen. Realmente siempre hay que saber si las metodologías se llevan a la práctica, sea cual sea la elegida.

Q buen post ... pero QUE BUENOS COMENTARIOS !!!

Me gustó el comentario de Jorge cuando nos dice "la oferta debe ajustarse porque estamos en un mundo de competencia voraz, el planning se comprime y los tiempos se hacen irrealizables, aunque no haya más remedio. Y lo peor es que lo sabemos y en muchas empresas se da aún y así con el látigo." Esto es una triste realidad que a aquellas personas que tratamos de generar un vínculo de confianza con nuestros clientes nos cuesta muchísimo. Un ejemplo, puede ser uno de los padres de la empresa donde trabajo (Tio_Luiso sabe de que hablo)

En esta empresa, la máxima general es la planificación super-detallada, hasta llegar al extremo de tener proyectos de 30 personas, donde 20 de las mismas están encargadas de la gestión del proyecto. Esta gestión se estima en una etapa inicial utilizando herramientas y métricas incorrectas; y usualmente sin conocer todas las variables externas que afectarán al proyecto. Aquí se consume muchísimo tiempo del proyecto y también del cliente; ya que es el primer contacto real que tiene con su proveedor (nosotros) y a partir de allí; se crea una falsa expectativa en relación con la dinámica que llevará el proyecto.

¿Cuál suele ser el siguiente paso?, el Miedo. Cuando un cliente tiene una planificación muy detallada (por ejemplo con tareas de 2 horas), y ve que algunas de las mismas no se cumplen (un desarrollador tuvo la osadía de enfermarse!), comienza a temer retrasos y obviamente más gastos para su proyecto. Y lamentablemente en ese momento, solemos aparecer personas que tenemos otro enfoque.

Aquí debemos demostrar a nuestro cliente que existen otras alternativas a una planificación tan estricta, que brinda resultados similares y que se basa en un trabajo más realista teniendo un objetivo claro (a donde queremos llegar). Pero este tipo de trabajo, no supone una planificación y no nos vemos mas hasta la entrega, sino que supone sumar al cliente como un integrante más de nuestro equipo de trabajo para que comprenda el día a día de un equipo de desarrollo (agile, msf, cmmi, pin pun pan o el que sea) para que conozca la dinámica de trabajo y que aporte sus necesidades dentro de ésta dinámica :D

… (viaje en metro) …

Retomo el post, después de un rato y cuando releo mi respuesta veo la cantidad de veces que escribí “dinámica” ¿será porque esa es la clave de nuestro trabajo actual?

Saludos

“Una precondición imprescindible para poder usar una aproximación ágil es centrarse en construir una relación de confianza entre las partes, no en negociar ferreos contratos con el afán de protegernos unos de otros.”

“Aquí debemos demostrar a nuestro cliente que existen otras alternativas a una planificación tan estricta, que brinda resultados similares y que se basa en un trabajo más realista teniendo un objetivo claro ….…supone sumar al cliente como un integrante más de nuestro equipo de trabajo para que comprenda el día a día de un equipo de desarrollo”

          ----------------

Esta muy claro que la teoría la tenemos bien aprendida, pero no en todos los casos podemos presentarnos frente a un cliente y decirle. Tranquilo nosotros somos distintos nuestra metodología es Agile, vamos nuestro propio nombre nos vende tranquilo intégrese en nuestro equipo y vera como si no podemos sacar el proyecto adelante no será por que no lo hemos intentado. Señores seamos serios que estamos jugando con el pan del cliente [Uff que tajante he sido].

Lo dicho el tema da para mucho, espero y deseo que este tema se siga sacando a debate, ya que seguro que de el podremos sacar muchas cosas. aH  y yo también intento seguir la tan querida metodología Agile pero no pensemos que es la panacea.

Un Saludo ;-)

Hola Jose Luis,

creo o creía que había quedado claro que las metologías ábiles no son la panacea, hasta el mismo Rodrigo creo que lo ha mencionado más arriba.

Todas las metodologías tienen sus pros y sus contras, pero una metodología ágil tiene menos tendencia al fracaso a priori.

Tú acabas de decir que no se le puede decir en todos los casos al cliente que se esté tranquilo y que se integre en el equipo, que así irá mejor, y que si no, que no es porque no se ha intentado... pero es que ahí está el quiz creo yo.

¿Cuántos proyectos conocéis en los que el cliente se implique y salga mal frente a los que el cliente no se implica y salen mal?. En mi opinión, y espero que en la de la mayoría también, no basta con una metología. También es necesario otras premisas como la implicación, formar equipo, sumar como dice la segunda frase que muy bien seleccionas de otras que ha comentado Rodrigo, etc.

Lo que pasa es que nuestro trabajo no sólo consiste en aplicar esas metologías, sino en transmitir esa confianza. Tampoco es camino fácil, ya lo sabemos todos, pero es un camino obligado, más largo al principio, pero más productivo en la curva de madurez.

Bueno... ando algo dormido ya... creo que es hora de descansar.

Abrazotes, esto es muy muy interesante. :-)

Buenos post, me gustaria rescatar algunos a partir de mi experiencia,

1.- No es lo mismo estimación que planificación.

Las estimaciones no siempre son verdaderas, independientemente de la metodología son expresiones de deseo. La Planificación viene despues de cerrar los acuerdos comerciales y ahí vienen los problemas.

2.- Las metodologías no son universales... yo agregaría tampoco son "puras"... siempre se combinan.

3.- Un proyecto es en definitiva una relación entre cliente y proveedor, una negociación... y esa la pierde el mas debil.

4.- La metodología exitosa es la que se cumple... y por ambas partes...

5.- Desde el proveedor... el problema es el cliente... Desde el cliente el problema es el proveedor... hay que buscar nuevas relaciones....

6.- La calidad del software requiere de tiempo.... y no existe el software terminado... se acaban los presupuestos, las paciencias, y los conflictos pueden llegar a no resolverse...

7.- Los proyectos son permanentes, son un proceso...

El desarrollo de sistemas, además de tener aspectos cientificos, es un arte.... hay que desarrollar para lo que viene despues del proyecto... lo importante es el resultado... hay que buscar un exito, un modulo que funcione... y construir sobre el exito.... hay que detectar al "dueño" y concentrase en él... no se puede satisfacer a todos ... hay que satisfacer al o los que estan involucrados en el liderazgo... sin liderazgo no hay proyecto... y el liderazgo en la empresa no puede ser parte del outsourcing.

A mi, Agile (o más bien XP) me parece que tiene 2 cosas:

1.- Se definen los problemas de las metodologías pesadas, y se definen 4 valores que se supone que son el espíritu de todo desarrollo agil. Estos 4 valores son: Comunicación, Simplicidad, Feedback y Coraje. Esto no es trivial. Es un resumen de los problemas que tienen las metodologías pesadas. Falta de comunicación en el equipo (o comunicación ineficiente, superburocratizada), falta de feedback del cliente, falta de coraje a la hora de acometer cambios (o más bien, negarse a aceptar cambios y agarrarse a las especificaciones firmadas como un clavo ardiendo) y falta de simplicidad a todos los niveles. Esta es la filosofía de XP.

2.- Un conjunto de principios y prácticas que en principio se derivan de los valores. Vienen un conjunto, pero en principio, mientras seas fiel a los valores, puedes usar o no las que quieras, o los que te resulten útiles. O puedes inventarte tus propias prácticas. ¿Por qué no?.

Es decir: Hay cosas innegables (las metodologías pesadas fallan y los motivos por los que fallan) y cosas discutibles (soluciones para estos problemas).

Solo 3 peros:

1.- En efecto, Agile no es una bala de plata. Nada lo es. ¿A alguien le suena la expresión "Golden Hammer"?

2.- Cada cosa tiene su medida. El que ahora haya nuevas teorías no invalida todo lo antiguo. Me he encontrado gente que ahora reniega de UML, o cualquier cosa que huela a metodología pesada. Me parece un error. UML me parece una buena forma de comunicación.

3.- A raiz del éxito de Agile ahora todo el mundo es Agile. Y lo mismo que dije antes de CMMI se puede aplicar a Agile. No por decir que eres Agile lo eres. En realidad, ni siquiera hace falta seguir ninguna metodología concreta (Scrum, XP, MSF Agile) para ser Agile. Basta con llevar los valores dentro.

Por último, recomiendo encarecidamente la lectura del ensayo "The New Methodology" de Martin Fowler: http://www.martinfowler.com/articles/newMethodology.html

   Genial el POST señores. Gracias a todos exponer sus opiniones. Da gusto encontrarse gente como ustedes para seguir aprendiendo.

   - Objetividad con humildad ( no soy PM ) -

         Estoy de acuerdo en muchos de los puntos de vista aquí expuestos.

         Una de las metodologías que concuerda con "algunos" de los aspectos aquí mencionados es Extreme Programming. En algunas cosas se puede tomar el concepto como ejemplo. Programar probando primero. Esto responde a la comparativa entre: Predicción vs Anticipación. La efectividad está basada en la agilidad pero también en la anticipación.

         A mi me gustaría pensar en poder proponer una "metodología" que sea un mix bien realizado entre todas.

         Las más rígidas no son adaptables y las más ágiles carecen de "planificación". A mi me gusta pensar que un proyecto puede ser medianamente planificado con rango de demora previamente conocido pero no establecido de forma concreta. Podemos dejar al cliente medianamente tranquilo con estimaciones pero negociarle la confianza suficiente para que conozca y acepte la demora a la que un proyecto de ingeniería del software está asociado. Por otro lado el cliente debe conocer el valor añadido que le supondrá el desarrollo y la implantación de un buen proyecto informático. Debe poder verlo y contrastarlo, bien sea con ejemplos o bien sea forzándole a que realice el trabajo de recordar sus experiencias provocando así su implicación directa en el proyecto. Al final de esto debemos poder decirle “No somos baratos, pero nosotros no vendemos promesas, vendemos valor añadido nuestros clientes”. Con este planteamiento el cliente obtiene “números”, a medias, pero al final “números” en los que se puede sostener, pero, a la vez, también conoce el concepto de demora. No tan solo sabe que existe, sino que sabe que es real y que va a ocurrir si o si.

          Por qué no podemos pensar en proyecto basado en alguna de las metodologías (MSF, RUP), que proporcionen iteratividad sobre los aspectos funcionales, centradas en un mismo núcleo, que pueda ser prototipado como fase inicial de un proyecto, el cual el cliente pueda “tocar”, en el que se pueda implicar. En base a eso, podemos girar entorno al núcleo haciendo reingeniería sobre él, y construir el resto generando nuevas iteraciones que nos permitan adaptarnos a las situaciones cambiantes.

          Eso si, veo la necesidad de que esto esté guiado por un lenguaje común que todo el mundo entienda, un lenguaje que permita ver con claridad el sistema, los requisitos y las funcionalidades. Creo que UML es bastante imprescindible en todo ello. Obviamente sin ser purista al 100%, los extremos nunca son buenos, hay que centrarse en extraer los puntos clave de cada cosa y llegar al término medio.

          E aquí un pequeño resumen, de lo que, a mi modo de ver, y des de mi punto de vista de analista programador existe en cualquier proyecto informático. (P.D. ODIO la palabra programador. ¿somos o no somos ingenieros del software? ¿Nos interesamos o no en Best Patterns & practices, MSF, RUP, UML, herramientas CASE…? ¿Entonces, por qué se nos valora a todos así? )

Consultora:

- “Facturar, facturar, facturar…” Somos “pollos” que hay que recolocar cuando no son productivos. (Cosa que en algún caso, puede que llegue a ser cierto)

- Sino hay, apuestas por nuevas tecnologías y una buena gestión de proyectos = Desmotivación total + “Horas, horas y más horas”.

- No se puede contratar en base a certificaciones, ni a empresas ni a empleados. ¿Qué diferencia existe entre ser un MCSD o MCPD de Microsoft y tener una etiqueta de anís del mono? En la primera te has leído las preguntas del testking y en la segunda te has bebido la botella. Menuda diferencia. Siempre hay las personas como yo que se leen el temario, lo estudian, lo entienden e intentan aprobar los exámenes sin las respuestas antes de estudiárselos para el examen final. Pero no se pueden valorar a las personas por ello.

- ¡¡¡Confección de un buen equipo!!!  Esa si que es tarea de los Project managers, siento cargaros el muerto… jejejejejeje, pero es muy importante. Gente que esté capacitada y que pueda conjuntar bien. No colocar Ferraris para ir a 20 por la autopista (desmotivación) ni tampoco a seats panda para subir a los pirineos (horas, horas y mas horas = mas desmotivación y encima estrés.)

- COMUNICACIÓN, entre todos los elementos del equipo. Es importantísimo. Si queremos se ágiles es muy importante que cualquier percepción de desviación, cambios etc… se comunique con rapidez y se organice el trabajo en base a ello.

- ¿"Saber vender"? ¡No! Ser sincero y realista.

¿Quién está vendiendo qué?

¿El comercial?   ¿Presales?   ¿El ingeniero?

  CUÁNTO    QUÉ      CÓMO

Esa tarea tiene que ser supervisada por todos a la vez. ¿Cuántos proyectos se venden sin saber? ¿Cuántas veces “el que vende” no tiene ni idea y cuela todo lo que puede para ganar el proyecto?

Cliente:

- El cliente: ¿Tiranosaurus rex? ¿O Homo sapiens? Hay que mostrarse seguro de sí mismo. ¿Quién es el experto aquí? ¿Quién decide entonces? No es quién paga, sino quien realiza. Es decir, la misma confianza que se ha generado para la planificación del proyecto es básica para proponer y elaborar un diseño, en base a nuevas plataformas con visión de futuro. ¡¡¡Se acabó el Cobol, VB6.0 etc…!!! Como mucho estudiemos herramientas de migración, o a las malas, integración. El cliente tiene que ser consciente de ello, por más ignorancia que tenga de la actualidad tecnológica. Ese también es nuestro trabajo.

- El cliente dispone de dinero, solo quiere gestionar para obtener. Hay que recordar que para el cliente, la informática aun es un gasto, no una inversión.

¿Sabe el cliente realmente diferenciarlo? ¿Sabe qué valor añadido va a aportar nuestro sistema? Hay que explicárselo. Hay que saber contárselo y saber demostrárselo.

Creo, desde mi punto de vista, que hay que centrar esfuerzos en generar la confianza del cliente. No nos conoce, necesita saber números. Démosle “números” si se puede, pero siempre concienciándolo de la demora y de la calidad con la que trabajamos. No vamos a permitirnos el lujo de  entregar algo mal desarrollado. Además somos lo suficientemente ágiles como para captar los elementos conflictivos, cambios y demás con la suficiente rapidez para que sean solucionados en el mismo momento o clasificarlos para incluirlos en la demora posterior previamente conocida pero no estimada de forma concreta.

  Y en cuanto al proyecto, deberíamos ser capaces de extraer lo mejor de las metodologías y aplicarlas, pero siempre acompañadas por un lenguaje común, una documentación increíblemente accesible y especializada para cada cargo dentro del equipo de trabajo, un conjunto de tests unitarios e integrales, todo ello gestionar por herramientas también ágiles desde el punto de vista de seguimiento, organización y comunicación.

  Nada, un granito de arena más.

  ¡¡Gracias a todos!!!

  ¡¡Saludos!!

La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo

La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo

La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo

La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo

Hola,

He leido todos los posts y estoy de acuerdo en todos, pero a la vez no. Me explico. Rodrido, siempre dices que lko que hay que hacer es "establecer una relación de confianza y colaboración que permita abordar los proyectos de una manera diferente", palabras textuales. Y eso esta muy bien.

¿Pero cuando ya tienes todo eso y cada dos por tres el clientes te está cambiando la programación que habías expuesto desde un principio?

Por mucha confianza con el cliente que tengas, lo que el cliente quiere ver siempre, son resultrados, chicha, carne, vamos que no le valen las cosas de palabra, que para eso nos pagan.

Otra cosa que veo en los proyectos, tampoco soy PM, es el tiempo que se "pierde" en hacer las propuestas. Actualmente estopy en un proyecto por el cual se están analizando 7 escenarios diferentes para el mismo proyecto. Tienen a 7 personas diferentes, cada una con un escenario, haciendo una prueba piloto. ¿Esto es funcional? Desde el punto de vista de  un simple desarrollador, no.

Un saludo a todos,

Hola a todos.

Quizas este no sea el marco adecuado para hacer una pregunta, ya que se utiliza mas bien para hacer aportaciones, pero suelo leer este blog muy a menudo y quizas me podais guiar un poco sobre donde puedo encontrar informacion al respecto.

Me dispongo a crear una aplicacion Web utilizando ASP.NET 2.0. Pensaba utilizar para ello el enfoque de 3 capas. Durante el estudio final del proyecto, decidimos utilizar tambien AJAX.NET.

Mi pregunta es: Hay algun enfoque, "patterns & practise" o similar para unir digamos los dos conceptos?.

Agradezco vuestros comentarios por adelantdo.

Un saludo,

Alberto

Chess... Ya no es gratuito :(.

Saludos,

¿Existen otras herramientas existen para la captacion de requisitos, y que se puedan integrar con TFS?, ya que analizando CaliberRM (muy extenso) y Mindjet Requirements Management (no lo entiendo)

Estoy buscando una herramienta de captacion de requisitos.

Saludos y felicitaciones por el Blog

Como últimamente me han realizado esta pregunta en varias ocasiones la voy a contestar en este post,

Este es un post especial para la gente que tiene blog en Geeks.ms, aunque a modo de curiosidad os invito

Este es un post especial para la gente que tiene blog en Geeks.ms, aunque a modo de curiosidad os invito

gSoap qué requisitos de despliegue tiene? sproxy te obliga a distribuir el MSXML, gSOAP tiene alguna dependencia de este estilo? Distribuir algún parser XML? ( libxml2, tinyXML....)

Ibon.

Pero a ver, yo creo que el problema real no esta en el titulo. Ni en el intrusismo, diria que esta tambien en las propias universidades, que de una universidad a otra hay bastante diferencia de exigencias. Se comenta sobre sobre titulados que no saben programar, y lo llevo leyendo bastante. Pues por la zona que vivo, los de la publica miramos un poco de lado a los de una privada de por aqui. Basicamente porque se comenta, de gente de no aprobar ni a ostias, cambiarse a la privada y milagrosamente aprueban.

El problema con los propios ing. informaticos, es que hay universidades regalando titulos.

Un error habitual en gestión de proyectos es creer que la mejor manera de estimar el coste o la duración de un proyecto es realizar una división del trabajo en tareas. Veía este error hace pocos días entre los comentarios al post titulado Tengo un plan:

ummmm esperaré a tu próximo post porque no lo veo claro.

A hacer una planificación detallada no le veo sentido, pero dividir un problema en N problemas puede ayudar, sin llegar al detalle que comentas. Todo tiene término medio..

porque ejemplo, en el caso que comentas es probable que no haya ido nunca de Bilbao a Amsterdan, pero sí que haya hecho algunos tramos en otros viajes; igual he ido alguna vez a Burdeos o a Bayona o he hecho Amberes-Amsterdam o lo me lo le léido en algún lado.

No comento nada más y espero a tu próximo post-

Un saludo!!

Aupa Ibón!!!

Creo que lo que Rodrigo quiere hacer patente es que conocer en detalle la duración de las subtareas no va a mejorar la estimación. Todos sabemos que ne desarrollo de software, incluso la pequeñas tareas sufren grandes cambios, por ello estimar pequeñas tareas no mejora la estimación.

Además ya dice Rodrigo que hay que tener en cuenta el coste de realizar esa subdivisión, que claro esta no es pequeño.

Yo entiendo el post de Rodrigo en el sentido de que hay que buscar información sobre el software a estimar, pero no demasiada porque llega un punto que el coste no compensa. Y hacer la división de todo un proyecto en tareas es algo que puede ser excesivamente costoso sin que mejore demasiado la estimación.

Me ha encantado el ejemplo, ojalá lo hubiera tenido con algún jefe de proyecto con el que he trabajado!!!

Además, te puede pasar lo siguiente. Al dividir tu proyecto en fases y/o tareas, es posible que a mitad del proyecto tengas que modificar totalmente la planificación de una de las tareas por lo que toda la estimación se va al cuerno.

En el ejemplo de Bilbao a Amsterdam. Imaginate que cuando estás camino de Burdeos te das cuenta de que pasar por París no es viable (huelga de transportes?)

Oscar A.G. dijo: "Además, te puede pasar lo siguiente. Al dividir tu proyecto en fases y/o tareas, es posible que a mitad del proyecto tengas que modificar totalmente la planificación de una de las tareas por lo que toda la estimación se va al cuerno.

En el ejemplo de Bilbao a Amsterdam. Imaginate que cuando estás camino de Burdeos te das cuenta de que pasar por París no es viable (huelga de transportes?)"

Precisamente ahí creo que está el meollo. El tratamiento de la incertidumbre frente a los requisitos cambiantes, y cómo afecta a las estimaciones y las planificaciones. Me explico. En un ejemplo como el que ha puesto Rodrigo, a menos que haya alguna catástrofe, sí que podemos realizar cierta estimación. No necesariamente en el tiempo (quién sabe qué atascos habrá), pero sí en los Km.

El coste de analizar, diseñar y estimar es alto. El de intentar hacerlo de forma apriorística con toda la solución es grande. Con la gran desventaja de que si luego te cambian la especificación, se te hunde el chiringuito.

Por este motivo con las metodologías ágiles se estima iteración a iteración. Porque a muy corto plazo es posible analizar, diseñar y estimar de forma razonable sin que te cambien los requisitos.

Excelente ejemplo !!!

Sin embargo, TU planificacion detallada (Bilbao – Bayona – Burdeos – Orleans – Paris – Amberes – Amsterdam) a vos te parece que no te ayudará a estimar correctamente; pero a MI sí. No me ayudará a estimar, pero si me ayuda porque sirve de la lista de lugares q tengo pendientes de conocer: {Bilbao, Bayona, Burdeos, Orleans, Amberes}.

Por eso puedo suponer lo siguiente: si existe información que piensas que no es útil, tal vez a alguien le sirva ;)

Esto es para q no empecemos a desestimar planificaciones existentes y comencemos a hacer todo de nuevo, creo que lo mas importante es saber el nivel de detalle con el que necesitamos trabajar.

Saludos

Y... ese siguiente post saldrá...?

Porque ya no me quedan uñas por morderme mientras lo espero... ;)

Como forofo de geek, y admirador de Rodrigo, me lanzo ha dar mi opinión.

La descomposición en tareas menores se realiza para llegar a una unidad de trabajo conocida y estimable, la cual nos permita tener una primera cifra y saber de lo que estamos hablando. Evidentemente después de utilizar esta metodología y hay aplicarle unos factores correctivos que dependen de muchas variables (semejantes a los que se utilizan en la estimación por casos de uso: tecnicos, ambientales, etc). Y al final establecer una estimación basada en métricas y experiencia al 50%.

En cambio en el ejemplo (que aunque es muy bueno no es aplicable) descomponemos la tarea en unidades que seguimos desconociendo por lo que nunca tenemos una referencia real y estimable.

Bueno esta es mi opinion. Muchas gracias por GEEKS a todos lo que lo componéis.

Como forofo de geek, y admirador de Rodrigo, me lanzo ha dar mi opinión.

La descomposición en tareas menores se realiza para llegar a una unidad de trabajo conocida y estimable, la cual nos permita tener una primera cifra y saber de lo que estamos hablando. Evidentemente después de utilizar esta metodología y hay aplicarle unos factores correctivos que dependen de muchas variables (semejantes a los que se utilizan en la estimación por casos de uso: tecnicos, ambientales, etc). Y al final establecer una estimación basada en métricas y experiencia al 50%.

En cambio en el ejemplo (que aunque es muy bueno no es aplicable) descomponemos la tarea en unidades que seguimos desconociendo por lo que nunca tenemos una referencia real y estimable.

Bueno esta es mi opinion. Muchas gracias por GEEKS a todos lo que lo componéis.

Javier,

de eso trata este ejemplo creo yo.

El desmenuzar el proyecto en tareas y estas en subtareas hasta encontrar unidades "conocidas" y "estimables" es donde te puedes llegar a perder.

A medida que vas profundizando en las subtareas estás aumentando el número de variables estimadas.

En el ejemplo propuesto por Rodrigo se ve muy claro: Sólo tengo que estimar la distancia entre 2 puntos.

Al principio puede parecer dificil porque no tengo suficiente información. Así que lo divido en subtareas más "asequibles". En el ejemplo son pasar por varias ciudades que están a una distancia menor. Ahora tengo que estimar la distancia de Bilbao a Bayona, de Bayona a Burdeos y así sucesivamente. De esta manera creo que el número de variables a estimar crece. Paso de estimar una distancia a estimar 6 distancias. Es posible que los fallos de estimación en cada uno de los tramos sean menores, pero... ¿qué me dices de la suma de todos los fallos de estimación de cada una de las etapas?

Sinceramente, es posible incluso que sean hasta peores.

Aproximacion vasta:

Minimo (bilbao-bayona) 100 km (distancia de la capital a la frontera)

Maximo frontera-frontera 2000km (minimo para un pais en condiciones)

5 pasos a 100 km = 500 Km

La distancia es 2000km + 500 km (me pillo los dedos ? )

Gracias por el dato :)!

Saludos,

Lo conocía y lo recomiendo. =:-)

Quisier tener una informacion mas completa puesto que no tengo demasiada experiencia con C# y tengo que hacer un proyecto de programacion en este lenguaje usando un pueto paralelo con visual C#

Acabo de terminar de leer este libro y la verdad que es muy bueno, engancha. Hace tiempo que no leía un libro en inglés tan rápido como este.

recontra útil! sobretodo para nuevos productos. Es más, siempre cuando se busca algo de cualquier tema, el cerebro ya se va acostumbrando a buscar en ingles primero :D.

Pero en Geeks.ms, cambiamos eso para que sea el punto de partida de búsqueda en español :).

Saludos,

Hola Rodrigo.

Quizas esto que voy a preguntar no venga al caso, y disculpame.

¿Que hay con C++ y el .NET 3.0?

Un Saludo.

    Estoy totalmente deacuerdo contigo, no hace mucho discutia con Miguel Jimenez la utilización de datareaders, datatables e incluso dataset como objetos de datos, despues de diseñar toda la capa utilizando codedom para generar las estructuras de clases, conjuntamente con funciones de reflexión todo ello mezclado con generics y otras funcionalidades, sigo pensando que muchas veces la utilización de un datatable o un datareader, sin ser tan eficaz como lo anterior, puede ahorrarnos muchas lineas de código y dolores de cabeza, creo que a veces nos olvidamos el fin de las aplicaciones intentando desarrollar la mejor solución, y la complicamos mas, sin pararnos a pensar que muchos de estos objetos, nos aportan todo lo necesario para trabajar con datos.

Solo os queda esperar un poco al Entity Data Model de Microsoft que aportara soluciones y mejorara el rendimiento en este tipo de procesos.

Perdonand que haga un post que no viene a cuento, pero me podría decir que tiene que hacer uno para tener un blog aquí? He escrito en dos ocasiones a usted (Rodrigo) y no ha recibido ninguna contestación. Si es que no se puede por no ser "conocido", con que me lo digan es suficiente y buscaré otro sitio. Pero agradecería una respuesta.

Gracias.

 Exacto! Entity Data Model...

 ¿Que os parecería si os propusiera LINQ y el EDM, tal y como Juan comenta? ¿Porque no trabajar con objetos XLINQ y DLINQ en determinadas circunstancias en las que el peso de los datos nos importa? Es más, si que es verdad que con los DataSets tienes una cantidad de funcionalidades, estado de los datos, consultas, representación Modelo-Entidad bien plasmada, constraints, hasta incluso ahora con 2.0 el mismo DataSet goza de capa de acceso a datos integrada (De la cual no estoy muy de acuerdo en utilizar. A mi modo de ver tiene que existir siempre una arquitectura bien desacoplada i diferenciada en capas…), pero todos sabemos de que cojean los DataSets y es el peso que conllevan para ser transportados.

   Además, tenemos que tener en cuenta que LINQ es una tecnología que va a más, aparte de iniciarse como un conjunto de funcionalidades y integración del lenguaje de consulta para cualquier conjunto de colecciones de objetos (Languaje Integrated Query...), Linq nos introduce, y realiza la primera aproximación real al mundo de los ORM (Object Relational Mapping) o EDM (Entity Data Model) con vNext, de una forma bien estructurada y orientada a objetos en plataforma .NET.

   Además todos conocemos que el paso de un objeto Linq a dataset o dataset tipado es increíblemente sencillo, dicese de IQueryable.

  Además de que existe la posibilidad de mapear la estructura relacional de la base de datos de forma rápida i sencilla: Northwind nor = new Northwind().  También es posible arrastrar del explorador de servidores las tablas de la misma manera que los datasets en un diagrama de clases y crear relaciones entre los objetos.

   Creo que es un candidato muy serio a tener en cuenta para poder trabajar en entornos SOA en los cuales se necesite mejorar el rendimiento de comunicación entre servicios. Que mejor manera de hacerlo que utilizando colecciones de objetos con tipos simples que pesan bastante menos y después en cada capa de negocio de cada servicio trabajar indistintamente con DataSets tipados o objetos Linq según se precie.

  Saludos!!!

Como siempre Rodrigo muy buen artículo!!!

Yo he empezado hace poco a desarrollar con ASP.NET 2.0 y la verdad es que me gusta la manera de trabajar con DataSet, DataTables y TableAdapters por la facilidad con la que se desarrollan aplicaciones y lo comodo que me resulta su mantenimiento.

Salu2

Hola Rodrigo,

Veo que no era el único que defendia el uso del DataSet o la familia ADO para encapsular los datos entre capas. Pero cuando te hablan de SOA entonces la batalla esta perdida! Yo se que trabajar con DataSets es algo comodisimo, donde vas a encontrar objetos serializables preparados para contener cualquier tipo de datos independientemente de cual sea su fuente... pero claro, si le pasas un DataSet a una aplicación JAVA creo que te dirá que te estas equivocando de destino. Espero que puedas dar algún consejillo para poder establecer un criterio a la hora de legir mis herramientas tanjibles de trabajo diario ante los desafios como SOA y SaaS. Yo no soy arquitecto, pero espero algún día llegar a alcanzar esa menta y en mi cabeza algo no para de decirme: ¿Porque lo llaman SOA si quieren decir Web Servcies (WS que es más 'Cool'? ¿Y que de elementos físicos esta compuesto un 'Bus de Datos' algo de lo que siempre se habla en esto del SOA? ¿Realmente con WCF ya no tengo que preocuparme del método de comunicación (WS o Remoting) entre capas de arquitectura?¿Es posible el envio de datos binarios no serializados en una aproximación a SOA? Muchas pregunta y poco tiempo para contestarlas...

PD: Benja que a ver si te animas y nos haces un Mod .NET 2.0 de LINQ!

Saludos.

En mi opinión, no creo que usar DataSets sea una solución más cómoda que usar Entidades. De hecho, el uso de DataSet en aplicaciones que superan las 20 o 30 clases se convierte en un autentico infierno, prácticamente imposible de mantenar (podría ser que yo no hubiera usado las herramientas adecuadas). Yo, normalmente, desarrollo usando como herramientas motores de persistencia y generadores de código (en mi caso Gentle.NET y MyGeneration). Y al menos desde mi experiencia el desarrollo se agiliza.

Desde luego, serializar colecciones de 20000 objetos también es bastante costoso. Pero ahora estamos realizando comparativas entre herramientas y no entre "metodologías".

Hola Rodrigo!

Yo soy defensor de usar objetos de transferencia de datos (DTOs o VOs). Ya que estás usando .NET 2.0, puedes hacer el binding directamente a los objetos, y si quieres añadir campos, al estar pasando un objeto los interfaces se mantienen iguales.

Además, siendo realistas, si metes campos nuevos, usando datasets no sólo tocas la query. Si ese campo influye en la lógica de negocio, la tendrás que modificar (al igual que con un objeto). Si influye en la capa de presentación, la tendrás que modificar (igual que con un objeto). A parte de la query, que la tendrás que modificar también.

En serio, no veo tanta ventaja al uso de los DataSets, además de que son "pesados" para las transmisiones... (será que no los uso bien, que también puede ser ;) )

Augusto me gustaría responderte una cosita:

"Ya que estás usando .NET 2.0, puedes hacer el binding directamente a los objetos"

Desde que estoy usando ASP.NET 2.0  en casa porque en el curro parece ser que no se animan todavía, yo construyo el DAL con DataSet Tipado (Facil y sencillo como dice el de bricomanía) ,luego me creo la BBL para crear el negocio (Si un campo debe ser mayor que 0, si esto lo otro lo que sea...) utilizando los TableAdapters del DAL para devolver los datos y ademas extiendo el DAL de una manera simple (si necesito controlar algún campo del datarow, o si necesito devolver mas datos) y luego hago el binding de la capa de presentación directamente a los objetos de la BBL. Como ves utilizo las 2 cosas y va fenomenal, pero efectivamente como dice Rodrigo esto es cuestión de gustos o costumbres.

Salu2

Yo creo que hay que tener en cuenta cuatro puntos:

 1. Que los recursos que van a integrarse en el equipo tengan nombres, apellidos, y curriculums con experiencia previa, que sean buenos profesionales, con experiencia contrastada.

 2. Cerrar con el cliente que es lo que va a querer y dejar claro que se está abierto a cambios pero eso si pudiendo impactar a fechas de entregas y costes (parece mentira, pero si trasladaramos un proyecto de IT a la compra de un coche, tendrías a un cliente pidiendo extras ... aire acondicionado etc... por el mismo precio que pago por un modelo base).

 3. Que el cliente sea parte del equipo, esto es planificar entregas semanales a modo de "Sprints" con el que client pueda ver en todo momento el avance del proyecto y evitar el efecto "tunel", dejarle claro que si no colabora se tomara su silencio como aprobación del desarrollo realizado.

 4.  Establecer algunos métodos formales, sin llegar a matar de burocracia el desarrollo: realizar actas de las reuniones es vital para evitar malosentendidos y olvidos, realizar informes de progreso es muy importante, poniendo especial hincapie en riesgos y problemas que aparecen (en este aspecto hay que pensar en positivo, mejor decir los problemas cuanto antes para darles solucíon a tiempo, que no callarnos y esperar que cuando sea demasiado tarde nos reviente esto en la cara).

 Como resumen, algunos puntos de lo que comenta el artículo de Antonio no están mal, pero es cierto de que el capital humano no se valora con tests o formulas matemáticas, son personas que deberían de ser evaluadas por empresas externas para ver si cumplen con la calidad esperada o no.

  Yo siempre he estado a favor de un punto medio. Es precisamente lo que estaba intentando plantear.

  ¿Por qué solamente DataSets tipados y por qué solamente LINQ?

  Vamos a ver, ¿por qué razón voy a usar un DataSet para devolver 100.000 registros que solamente van a servir para ser mostrados en una lista y no van a ser tratados con ningún tipo de lógica? Siempre se ha hablado de DataReaders como objetos muchíssimo más eficientes "PARA ESTOS ESCENARIOS EN CONCRETO", en cambio cuando necesitas tratar los datos con algo más de lógica de negocio, o, es más, cuando tu aplicación tiene muchíssima concurrencia y necesitas augmentar la escalabilidad prefieres usar DataSets en lugar de DataReaders.

  Pues exactamente planteo lo mismo. ¿Quieres ser ágil? DataReader o Objetos LINQ. ¿Queremos además poder hacer consultas entre colecciones de objetos? También puedes hacerlo con LINQ. ¿Queremos además bindar objetos a las Views y Controls? Tambíen podemos usar colecciones de objetos.

  Pero no hay que negar que la potencia de los DataSets es brutal. La facilidad de uso también y las capacidades que nos aportan para manejar el estado de los datos y su consistencia es muy buena.

  Por ese motivo exiten las funcionalidades "LINQ to DataSets" y "DataSets to LINQ", porque precisamente voy a querer no solamente escojer la manera en cómo tratamos los datos, sino también, cual es la mejor manera de integrarlos en arquitecturas Saas y SOA mejorando notoriamente el rendimiento.

  Es tan sencillo como dotar a la capa DAL de una factoría que te permita escojer el tipo de datos sobre el que vas a trabajar ( generics estaría muy bien también para potenciar esto y crear constraints de tipos a aceptar ) y a partir de ahí gestionar estos objetos en base a sus capacidades, ya sea para comunicación entre servicios, ya sea para tratamientos de datos con estado, ya sea para operaciones CRUD sencillas.

  Saludos!!

Todo la razón Rodrigo en decir que el 80% del rendimiento de una aplicación al final se encuentran en optimización de consultas, así como administración del gestor de db. Pero seguramente, el porcentaje de consultas a optimizar suele ser muy pequeño (al menos en los escenarios que conozco). Un ORM, en ningún caso no impide o no debería impedir que determinada funcionalidad se ejecutase de la manera más optima posible.

También decir, que es cierto que comprender el funcionamiento puede ser costoso. Pero la mayoría de los casos evaluando benchmark podríamos elegir uno u otro. Al igual que elegimos un entorno de desarrollo u otro.

Simplemente mi experiencia de desarrollo con DataSet (es cierto que no he llegado a usar los tipados) fue un auténtico horror.

(offtopic) Por último, viendo que sois conocedores de las próximas tecnologías de microsoft; me gustaría preguntaros si sabeis si en la próxima versión del framework incluiran algún ORM; o tal vez quede todo como la promesa de ObjectSpace en .Net 2.0.

Un saludo,

PS. Por cierto, en el post anterior me olvidé de felicitarte por el blog :P

fravelgue AT gmail DOT com

Que tal Rodrigo, muy interesante lo que leo en tu post, yo no tenog inguna experiecia en SCRUM y MSF, me he centrado más en RUP y Extreme Programming, y en lso proyectos donde los empleé si hubo el control necesario, además que RUP pudo ser flexible al momento de emplear los artefactos a utilizar. RUP además puede ser utilizaod en conjunto a las técnicas de XP explotando lo mejor de ambas metodologías en proyectos de corta duración y planificación de iteraciones. Investigaré más al respecto de SCRUM.