Ágil arruinó mi vida.

[Rafa de Castro]

El artículo en cuestión:

http://www.whattofix.com/blog/archives/2010/09/agile-ruined-my.php


Creo que es algo que hemos leido en esta lista varias veces. Esto se va a llegar de magufos certificados, mercachifles con pines y vendehumos nivel 5. De todos modos hay una parte de la crítica que si que es admisible y es  que no hay nada concreto y eso tampoco está bien. ¿No os parece que siempre nos guardamos las espaldas y lanzamos el "depende"?

Esa es la salida fácil. Claro que decir siempre que depende es siempre acertar. Nos ha jodido. La gracia es lo contrario. La gracia es crear algo que convierta personas mediocres en excelentes a través de un proceso excelente. 

¿Ideas? ¿No teneis a veces esa misma sensación?

--
Rafa de Castro
raf...@micubiculo.com

[German DZ]

La verdad es que a mi me da igual, paso a explicarlo:

- No necesito convencer a nadie de que sea ágil (salvo en algunos casos a la gente que necesito que trabaje conmigo), porque ni me hace la vida más fácil ni gano un céntimo con eso. [motivo egoísta y económico]

- Me resulta indiferente que a un montón de gente le vaya mal con Agile, probablemente sea la misma gente que le iba a ir mal de otra manera.

- Si hay gente que se "aprovecha" de la movida Agile para hacer sus estafas, me da igual. Yo evalúo las cosas independientemente de lo que digan sus brochures y sus certificaciones.

Por otra parte el que haya muchos interesados en Agile es bueno porque:

- Se genera ruido, se provocan reacciones, alguno se lo toma en serio y surgen mucho análisis y contra análisis que investigan y sacan lo bueno y lo malo.

- Más gente prueba cosas, se depuran las técnicas, se gana experiencia.

- Si hay muchos en algo, entonces si sos mejor que el promedio y la base es más grande, te posicionás por sobre mucho más gente. Esto es algo que algunos valoran, en realidad a mi me da igual pero me beneficio indirectamente.

Pero igualmente seguiré siendo ágil porque:

- Me resulta más fácil (a diferencia de otros que les resulta más difícil)

- Me dio siempre mejores resultados

- Soy más feliz haciéndolo de esta forma

- A mucha gente le viene bien que así sea

Yo creo que el agilismo tendrá éxito si la gente que hace agilismo tiene éxito y no debe ser al revés que muchos esperan que el agilismo sea algo "probado" para entonces sumarse y beneficiarse.

Quien espera tomarse una píldora verde y convertirse en ágil se equivoca, es una cuestión de ir pensando de cierta manera y actuando consecuentemente y luego serás ágil.

GermanDZ 

{que día tengo!!! jejejje}

2010/9/9 Rafa de Castro <raf...@refugioseguro.com>

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

[José Manuel Beas]

Estoy totalmente de acuerdo con Germán, pero...

2010/9/9 Rafa de Castro <raf...@refugioseguro.com>

Esa es la salida fácil. Claro que decir siempre que depende es siempre acertar. Nos ha jodido. La gracia es lo contrario. La gracia es crear algo que convierta personas mediocres en excelentes a través de un proceso excelente. 

Estoy firmemente convencido de que los procesos (por muy excelentes que sean) no convierten a las personas mediocres en excelentes. Son las personas las que se convencen de que pueden ser excelentes y son capaces de mejorar. Asumamos de una vez por todas nuestra responsabilidad individual en las cosas y dejemos de buscar "agentes externos" (en forma de procesos o de lo que sea) para que cambien nuestro entorno. (Y no he dicho que sea fácil, pero en compañía el camino se hace más llevadero). :-)

Un saludo,
Jose Manuel Beas

http://agilismo.es

http://jmbeas.iexpertos.com

http://twitter.com/jmbeas

[Daniel Escribano]

De acuerdo con vuestros planteamientos totalmente.

Siempre se tiende a criticar el sistema cuando uno es un inepto o no
alcanza los objetivos que había planteado.

Utilizar metodologías ágiles tiene que ser algo natural, en una
empresa que tenga esos valores, desde el equipo hasta el último jefe.

Criticar es fácil, por que siempre hay aspectos que mejorar y algunos
oscuros, como las certificaciones y gurús prometiendo el paraíso a los
programadores por ser ágiles, aunque sigan siendo unos ineptos.

[German DZ]

Sin dudas.. igual "Son las personas las que se convencen de que pueden ser excelentes y son capaces de mejorar" a veces es sólo una ilusión. Hay que ser realistas, por más que quieras ser excelente hacen falta algunas cualidades. 

Sería engañar si querés convencer a gente que por hacer unos cursos, aprender unas técnicas, recitar el manifiesto ágil, leerse muchos libros empiece a crear software de calidad y útil para alguien.

Esta sería la gran diferencia entre creer que los procesos están por encima que las personas y ser ágil.

Por ejemplo a mi ahora me encantaría ser basquetbolista, pero:

- Mido apenas 1,72 (aunque haya grandes jugadores que no necesitan necesariamente ser altos)

- Nunca jugué al basket, apenas me se algunas reglas (y podría leerme ahora el reglamento 100 veces y aprenderlo de memoria)

- No tengo estado físico ya a mi edad para correr detrás de una pelota que va rapidísimo y botando por todos lados (aunque entrene, no es lo mismo hacerlo a los 12 años que a los casi 35).

Osea... por más que quiera yo nunca podré jugar al basquet profesionalmente, ni amateur, apenas alguna vez con algunos amigos (se verá...).

2010/9/9 José Manuel Beas <jose....@gmail.com>

[Alberto Peña]

¡Jose Manuel Beas for president!

Nos hace falta autocrítica, autoexigencia y profesionalidad (que parece que la culpa siempre es de otros).

El 2010/9/9 José Manuel Beas <jose....@gmail.com>

Estoy firmemente convencido de que los procesos (por muy excelentes que sean) no convierten a las personas mediocres en excelentes. Son las personas las que se convencen de que pueden ser excelentes y son capaces de mejorar. Asumamos de una vez por todas nuestra responsabilidad individual en las cosas y dejemos de buscar "agentes externos" (en forma de procesos o de lo que sea) para que cambien nuestro entorno. (Y no he dicho que sea fácil, pero en compañía el camino se hace más llevadero). :-)

German, no podrás ser jugador de basket profesional, pero sí que podrás ser entrenador... "Quicir", si de verdad te gusta, entonces tendrás un hueco (aunque no será fácil, claro).

Un saludo

--
Alberto Peña Abril

http://twitter.com/plagelao
http://plagelao.blogspot.com/

[Carlos Díez-Gil Romero]

Totalmente de acuerdo.

Simplemente añadir que agile no es para todo el mundo. Pruebalo y decide. Todos somos mayorcitos para decidir qué queremos hacer y cómo lo queremos hacer. Si me sirve para mejorar, lo acepto, si no lo descarto. A mi ahora me sirve mejor que un proyecto en cascada de toda la vida.

Por otro lado, creo que no es ni muchísimo menos perfecto. Cuando salga "algo" que me convenza mas, lo adoptaré ;-)  

Un saludo,

c.

[Christian López Espínola]

Hola Germán,

2010/9/9 German DZ <ge...@ndz.com.ar>

Sin dudas.. igual "Son las personas las que se convencen de que pueden ser excelentes y son capaces de mejorar" a veces es sólo una ilusión. Hay que ser realistas, por más que quieras ser excelente hacen falta algunas cualidades. 

Sería engañar si querés convencer a gente que por hacer unos cursos, aprender unas técnicas, recitar el manifiesto ágil, leerse muchos libros empiece a crear software de calidad y útil para alguien.

Esta sería la gran diferencia entre creer que los procesos están por encima que las personas y ser ágil.

Por ejemplo a mi ahora me encantaría ser basquetbolista, pero:

- Mido apenas 1,72 (aunque haya grandes jugadores que no necesitan necesariamente ser altos)

- Nunca jugué al basket, apenas me se algunas reglas (y podría leerme ahora el reglamento 100 veces y aprenderlo de memoria)

- No tengo estado físico ya a mi edad para correr detrás de una pelota que va rapidísimo y botando por todos lados (aunque entrene, no es lo mismo hacerlo a los 12 años que a los casi 35).

Osea... por más que quiera yo nunca podré jugar al basquet profesionalmente, ni amateur, apenas alguna vez con algunos amigos (se verá...).

A lo mejor no llegas a ser profesional del baloncesto, pero seguro que si, además de leer el reglamento, practicas bastante, podrás ser el mejor de tu barrio. O al menos ten por seguro que mejorarás.

Ágil también contempla entrenamiento, no sólo mentalidad y procesos.

 

2010/9/9 José Manuel Beas <jose....@gmail.com>

Estoy totalmente de acuerdo con Germán, pero...

2010/9/9 Rafa de Castro <raf...@refugioseguro.com>

Esa es la salida fácil. Claro que decir siempre que depende es siempre acertar. Nos ha jodido. La gracia es lo contrario. La gracia es crear algo que convierta personas mediocres en excelentes a través de un proceso excelente. 

Estoy firmemente convencido de que los procesos (por muy excelentes que sean) no convierten a las personas mediocres en excelentes. Son las personas las que se convencen de que pueden ser excelentes y son capaces de mejorar. Asumamos de una vez por todas nuestra responsabilidad individual en las cosas y dejemos de buscar "agentes externos" (en forma de procesos o de lo que sea) para que cambien nuestro entorno. (Y no he dicho que sea fácil, pero en compañía el camino se hace más llevadero). :-)

Un saludo,
Jose Manuel Beas

http://agilismo.es

http://jmbeas.iexpertos.com

http://twitter.com/jmbeas

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--
Cheers,

Christian López Espínola <penyaskito AT computer DOT org>
http://twitter.com/penyaskito | http://penyaskitodice.wordpress.com

[José Manuel Beas]

100% con Christian (qué difícil se me hace no llamarte @penyaskito) ;-)

A ver si soy capaz de resumirlo:

- autoexigencia (individual y colectiva) : búsqueda de la mejora y de la excelencia) 

- autodisciplina (también individual y colectiva) : respeto a los procesos, lo que incluye el entrenamiento, en la búsqueda de la mejora y la excelencia 

- ritmo sostenible : el factor diferencial entre un proceso de desarrollo ágil y otros (los anteriores valores son deseables en cualquier ambiente)

¿Qué os parece el resumen? Estoy muy interesado en vuestra opinión. Gracias.

[Juan Carlos Quijano Abad]

Demasiado cercano a la mística de la autoayuda... :)

--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

Blog de opinión social

Blog de World of Warcraft

Blog de Tiro con Arco

[Antón Rodríguez]

Hola,

lo han publicado en Barrapunto: http://barrapunto.com/articles/10/09/08/1315216.shtml

Tenemos troll asegurado :-)

Personalmente me parece un artículo interesante y hay bastantes cosas en las que estoy de acuerdo.

Para mí lo importante de las metodologías agiles no es lo que las rodea (gurús incluidos) si lo que uno sea capaz de sacar para llevar a sus proyectos y hacer que funcionen (y acaben) bien. Para mí esa es la clave independientemente de que se le llame scrum, kanban o el método de pepito pérez.

Un saludo,

Antón

[Rafa de Castro]

Yo lo leí de Barrapunto :P

Voy a hacer de abogado del diablo. Estamos hablando de equipos de gente competente y/o supermotivada. Así cualquiera cocina :D A mi me funciona porque tengo motivación y con eso se suple la falta de cerebro pero no todo el mundo es así y, sobre todo cuando entramos a hablar de grupos grandes de gente, a veces es incluso lo contrario. No se puede pensar solo en la gente que tiene intención de hacer las cosas bien. Hay que hacer planes que incluyan a todo el mundo.

Esta duda me surgió leyendo el Toyota Kata[1]. En un momento dicen que lograron desbancar a General Motors gracias a que lograron hacer que su proceso fuera excelente mediante mejora continua y permitían que la gente no fuese excelente en absoluto. Solo necesitaban un puñado de gente verdaderamente válida y el resto una masa no tan preparada ni motivada pero más barata.

El caso es que en términos absolutos esto tiene sentido. Si consigues que el que merezca la pena sea tu proceso de mejora de producción no dependes tanto de la gente.

Esta discusión también la tuve hablando con un amigo que en un futuro será directivo de un sitio bastante gordo. Lo que suele costarles para adoptar ágil es el personas sobre procesos por lo que os he contado. No puedes tener 1000 trabajadores motivados. De hecho creo que ni siquiera 100. Y cuanto mayor es el número más complicado es. ¿Que tal escala el agilismo? :D :D :D

P.D: Yo lógicamente prefiero defender a las personas. Incluso éticamente hablando :P. De todos modos siempre hay que cuestionarse las cosas y discutir cuando hay alguna duda.


[1] http://www.amazon.com/Toyota-Kata-Managing-Improvement-Adaptiveness/dp/0071635238

2010/9/9 Antón Rodríguez <ant...@gmail.com>

--
Rafa de Castro
raf...@micubiculo.com

[Jose R.]

Hola!

 Yo también lo lei en Barrapunto, :) hay otro enlace que comentan, que también daría para una discusión [1] 

 

 El punto que comenta Rafa me parece más que relevante. Pero creo que tiene dos visiones contrapuestas:

 -Por un lado, el proceso del que hablan en toyota Kata es del proceso de fabricación, de manufactura, y ese no es comparable con el proceso de desarrollo de software, esto creo que ya se ha comentado varias veces por aquí.

 - Por otro lado, sobre la motivación. Bajo mi punto de vista, los que tenemos alguna responsabilidad somos los que tenemos/podemos que crear procesos que motiven (?!). Y no crear procesos para que pueda trabajar gente desmotivada.  Me parece una diferencia relevante. Y nada mejor, creo yo, en software, que los principios ágiles.

 Salu2!

   Joserra

   http://najaraba.blogspot.com

[1]http://umeet.uninet.edu/umeet2002/talk/2002-12-11/linux2.txt.html

2010/9/9 Rafa de Castro <raf...@refugioseguro.com>

Yo lo leí de Barrapunto :P

[Alfredo Casado]

No puedes tener 1000 trabajadores motivados

¿No puedes?, ¿porque no puedes?. Además si están motivados quizás no hagan falta 1000.

Buscar "procesos" para que la gente mediocre/poco-motivada aporte valor a un proyecto de software es buscar la curvatura del circulo, yo no creo que se pueda.

Los proyectos de software que fracasan no lo hace por las metodologías o los procesos, lo hacen por las personas. En realidad las metodologías no son más importantes, son un empujón si vas en la buena dirección, pero es que pedís milagros y ya lo dice el refranero español "no se le pueden pedir peras al olmo".

[Scrum Master]

¿magufos certificados?
¿mercachifles con pines?
¿vendehumos nivel 5?
¿estafa?
¿personas mediocres?
¿100% de motivación en una empresa?
¿los que critican son ineptos?
¿los que programan y fallan, ineptos también?

A ver si le vamos a tener que dar la razón a Daniel Markham...un poco
de seriedad por favor, que el hombre sólo ha contado una experiencia
(o una historia...).

Y a tirarse de la moto, que Agile no es el "arma definitiva para
convertir el desarrollo de software en un paraíso", como decía alguien
por aquí en un debate: "SCRUM te garantiza el éxito" (suena a
salvación extraterrenal o anuncio de crecepelo....... ), si fuese así
la estaría utilizando todo el mundo, y es que hay proyectos XP que han
sido un auténtico fracaso, y las metodologías ágiles tienen muchos
años de antigüedad (son del siglo pasado.....). "En todos lados cuecen
habas", dice el sabio refranero español......

A relajarse, a mejorar, a contribuir con herramientas, experiencias,
nuevas prácticas y nuevas técnicas en los debates, que estas
discusiones son más propias de religión que de ciencia......y debemos
evitar que las metodologías XP parezcan religión.

Amén.

On 9 sep, 14:33, Antón Rodríguez <anto...@gmail.com> wrote:
> Hola,
>
> lo han publicado en Barrapunto:http://barrapunto.com/articles/10/09/08/1315216.shtml
>
> Tenemos troll asegurado :-)
>
> Personalmente me parece un artículo interesante y hay bastantes cosas en las
> que estoy de acuerdo.
>
> Para mí lo importante de las metodologías agiles no es lo que las rodea
> (gurús incluidos) si lo que uno sea capaz de sacar para llevar a sus
> proyectos y hacer que funcionen (y acaben) bien. Para mí esa es la clave
> independientemente de que se le llame scrum, kanban o el método de pepito
> pérez.
>
> Un saludo,
>
> Antón
>
> El 9 de septiembre de 2010 13:35, Juan Carlos Quijano Abad <

> juancarlosquij...@gmail.com> escribió:

>
>
>
> > Demasiado cercano a la mística de la autoayuda... :)
> > --
> > Un saludo
> > Juan Quijano
>

> > Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
> > Blog de opinión social <http://unmalnacido.blogspot.com/>
> > Blog de World of Warcraft <http://historiasdesdeazeroth.blogspot.com/>
> > Blog de Tiro con Arco <http://litelllon.blogspot.com/>

>
> > El 9 de septiembre de 2010 13:25, José Manuel Beas <jose.m.b...@gmail.com>escribió:
>
> > 100% con Christian (qué difícil se me hace no llamarte @penyaskito) ;-)
>
> >> A ver si soy capaz de resumirlo:

> >> - *autoexigencia *(individual y colectiva) : búsqueda de la mejora y de
> >> la excelencia)
> >> - *autodisciplina *(también individual y colectiva) : respeto a los

> >> procesos, lo que incluye el entrenamiento, en la búsqueda de la mejora y la
> >> excelencia

> >> - *ritmo sostenible* : el factor diferencial entre un proceso de

> >> desarrollo ágil y otros (los anteriores valores son deseables en cualquier
> >> ambiente)
>
> >> ¿Qué os parece el resumen? Estoy muy interesado en vuestra opinión.
> >> Gracias.
>
> >> Un saludo,
> >> Jose Manuel Beas
>
> >>http://agilismo.es
> >>http://jmbeas.iexpertos.com
> >>http://twitter.com/jmbeas
>
> >>  --
> >> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> >> Grupos de Google.
> >> Para publicar una entrada en este grupo, envía un correo electrónico a
> >> agile...@googlegroups.com.
> >> Para anular tu suscripción a este grupo, envía un correo electrónico a

> >> agile-spain...@googlegroups.com<agile-spain%2Bunsubscribe@googlegr oups.com>

> >> Para tener acceso a más opciones, visita el grupo en
> >>http://groups.google.com/group/agile-spain?hl=es.
>
> >  --
> > Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
> > Grupos de Google.
> > Para publicar una entrada en este grupo, envía un correo electrónico a
> > agile...@googlegroups.com.
> > Para anular tu suscripción a este grupo, envía un correo electrónico a

> > agile-spain...@googlegroups.com<agile-spain%2Bunsubscribe@googlegr oups.com>

[Gustavo Cebrian Garcia]

El movimiento Agile está muy criticado por ser un movimiento paralelo a PMI, Prince2...

No hay duda que son EEUU contra Unión Soviética.

Parece que es muy difícil la paz, no?

La verdad, es que la sobredocumentación de CMMI ( Unido que el movimiento ágil tienes unas prácticas muy buenas )

pues hacen que Agile le esté adelantando, en mi opinión. ( Yo soy partidario de hacer la paz )

Cierto, es mejor no decir "Depende". Es mejor decir, Si el proyecto tienes estas características, estas p´racticas y estas estrategias

son mejores. Si....    Soluciones a los problemas. El "Depende" no suena muy convincente, cierto.

Gustavo.

2010/9/9 Scrum Master <scrumaste...@gmail.com>

[Scrum Master]

Y creo que lo hemos puesto muchas veces, CMMI no es metodología y por
tanto no li puede adelantar ni retrasar, porque están en planos
distintos.

Respecto a las prácticas ágiles, son similares a las de CMMI en las
áreas de procesos cubiertas con una metodología ágil, que son un
subconjunto de las tratadas en CMMI.

Sobre el exceso de evidencias que puedan estar buscándose en las
evaluaciones CMMI cuando se aplican las prácticas en metodologías
ágiles, ese puede ser un debate interesante.

On 10 sep, 11:48, Gustavo Cebrian Garcia <g.cebrian.gar...@gmail.com>
wrote:

> El movimiento Agile está muy criticado por ser un movimiento paralelo a PMI,
> Prince2...
>
> No hay duda que son EEUU contra Unión Soviética.
>
> Parece que es muy difícil la paz, no?
>
> La verdad, es que la sobredocumentación de CMMI ( Unido que el movimiento
> ágil tienes unas prácticas muy buenas )
> pues hacen que Agile le esté adelantando, en mi opinión. ( Yo soy partidario
> de hacer la paz )
>
> Cierto, es mejor no decir "Depende". Es mejor decir, Si el proyecto tienes
> estas características, estas p´racticas y estas estrategias
> son mejores. Si....    Soluciones a los problemas. El "Depende" no suena muy
> convincente, cierto.
>
> Gustavo.
>

> 2010/9/9 Scrum Master <scrumaster.maste...@gmail.com>

[Enrique J. Amodeo Rubio]

Sobre lo que comentas de Toyota, a mi no me cuadra nada. Yo lo que había leido de ellos es que ponían especial cuidado en la selección y formación de todos sus empleados. Y alentaban a todos sus empleados proporcionar nuevas ideas y mejoras. De hecho un directivo inventó un botón que permitía a los empleados de la cadena de montaje parar toda la cadena si detectaban un fallo. También contaban sobre que el jefe debía estar con sus empleados en vez de un despacho para detectar in situ cualquier problema o margen de mejora y para formar a sus subordinados.
De esto me quedó la idea que buscaban la excelencia y la iniciativa en sus empleados, y la mejora continua de procesos. Asi un empleado al principio no sería muy experto, pero poco a poco se va convirtiendo en uno.
Claro, que todo esto era Toyota Japón, no se si las sucursales en USA o Europa siguen esta filosofía. Tal vez esta filosofía cuesta mucho de adoptar en occidente. No se, a veces se reciben mensajes contradictorios según que libro se lea.

Sobre lo de procesos sobre personas, es absurdo, y el fallo más típico en todas las empresas. El seguir un proceso a ciegas es propio de máquinas y poco eficiente. Las personas no son robots, si lo fueran, yo personalmente no las contrataría, sino que supliría su puesto con robots, y tendría procesos+robots. La gracia de las personas es que son capaces de detectar cuando el proceso falla o se queda desfasado con la realidad, y mejorarlo y adaptarlo.

Salud !
El 09/09/10 20:03, Rafa de Castro escribió:

[Luismi Cavallé]

Me temo que discrepo profundamente con la visión que planteas, Rafael. Dices que estás haciendo de abogado del diablo con lo que no queda claro si esa es realmente "tu" visión. En todo caso, te explicaré porque no estoy de acuerdo con "esa" visión.

Lo primero, como el niño del cuento "El traje nuevo del emperador", quisiera apuntar una obviedad que a veces parece que no queremos ver: producir software no es lo mismo que producir coches. No tiene nada que ver. Tampoco es lo mismo que hacer casas, ni que pintar cuadros o escribir libros. A veces llevamos las comparaciones demasiado lejos.

Para mi el movimiento ágil surge como reacción al concepto de software como factoría. Si lo comparas con cualquier otra ingeniería, el software sólo se diseña. Quien realmente "construye" el software no son personas, ni equipos, ni procesos, son compiladores (o interpretes). Además, resulta que lo hacen con un coste cercano a cero, despreciable. Y eso lo cambia todo.

Asumiendo esta premisa de que que crear software es un mero proceso de diseño, entonces debemos tener cuidado cuando tomamos como referencia procesos de *producción* y pretendemos aprender de ellos. A diferencia de los procesos de producción, en los de diseño el factor creativo es absolutamente determinante. Por eso lo fundamental aquí son las personas, no los procesos. El movimiento ágil reconoce esta realidad y por eso la incorpora como idea fundamental en su manifiesto. Los procesos, las metodologías o las herramientas han de estar al servicio de la personas, deben servir como medios para que desarrollen su creatividad.

Tu frase…

La gracia es crear algo que convierta personas mediocres en excelentes a través de un proceso excelente. 

…resume perfectamente porque no me siento identificado con buena parte de la "comunidad ágil". No sé si con "gracia" te refieres a "gracia divina" porque ciertamente sería milagroso un proceso capaz de conseguir eso que describes. No sé tú, pero yo no lo he visto nunca. En mi observación, detrás de software excelente siempre hay excelentes profesionales, que usan los procesos, las tecnologías y las herramienta que precisamente les permite desarrollar esa excelencia. 

Además creo probado que no hacen falta equipos grandes para crear software. Igual que no me imagino que sea posible que 50 personas diseñen un coche (o un mueble o una casa) sin acabar a puñetazos, tampoco lo veo en el caso del software. Diría que el 90% de los proyectos software pueden desarrollarse con equipos de no más de 6 personas. Siendo estas las personas adecuadas, claro. En cuanto al 10% restante –pensemos en Google, Amazon, Facebook…– la manera en que funcionan es subdiviendo sus mega-proyectos en mini-proyectos que son desarrollados por equipos pequeños y totalmente autónomos.

En ese sentido el hecho de que el desarrollo ágil escale o no, resultaría irrelevante. De hecho yo aseguro que no, no escala. No tiene que escalar.

-- Luismi

[Alfredo Casado]

La respuesta de Luismi es para enmarcarla, no puedo estar más de acuerdo y no creo que se pueda expresar con más claridad y contundencia.

[Carlos Díez-Gil Romero]

+1

El mediocre, JODE un proceso excelente.

Un saludo,

c.

El 10 de septiembre de 2010 13:37, Luismi Cavallé <lmca...@gmail.com> escribió:

[Gustavo Cebrian Garcia]

Sinceramente, yo creo que muchos pensamos lo mismo en cuanto procesos, ideas, metodologías etc, pero como lo ponemos en palabras, muchas veces, abstrayéndolo mucho y sin dar ejemplos, pues no nos aclaramos. Es normal, nos pasa a todos. En los procesos y desarrollos de los que hablamos, como hay similitudes, y diferencias, pues siempre hay detalles iguales y diferentes.

Por ejemplo:

Es CMMI ágil, o no?? 

Pues me incluyo, muchos ejemplos, pues no ponemos!! Para estar de acuerdo en algo, aunque se puede hablar con un nivel de abstracción alto a veces y entendernos, creo que hay que poner más ejemplos.

Es decir, a la hora del proceso, o Scrum etc. Por ejemplo, yo diría ( intentando ser más específico )

"Teniendo 20 clases con 4 métodos cada una, qué es ágil? Deberíamos hacer  TDD de al menos el 80% de los métodos?"

Cierto, esto lo tengo que hacer yo también   :-)  ( por ejemplo, no he dado un ejemplo de sobredocumentación en CMMI en este hilo ( en otro sí) )

No sé si me he explicado y me entendéis.

2010/9/10 Carlos Díez-Gil Romero <cdie...@gmail.com>

[Harald Messemer]

EXCELENTE. solamente añadiría, si lo admites, que el problema de la escalabilidad no es propio de agile, sino un escollo de cualquier metodologia. Vamos, trabajar con 1000 personas no es lo mismo que trabajar con una persona y necesitas organizarte para que sea eficiente. No por nada las grandes corporaciones tienen fama de ser ineficientes o tomar la analogia de "David" y "Goliath" de la biblia que expresa el mismo concepto.

Saludos,
Harald

2010/9/10 Luismi Cavallé <lmca...@gmail.com>

[Rafa de Castro]

Con lo abogado del diablo evidentemente digo que no es mi opinion ;) ... pero eso no me impide seguir defendiéndola :D :D :D Creo que esto va a ser largo:

> producir software no es lo mismo que producir coches. No tiene nada que ver. Tampoco es lo mismo que hacer casas, ni que pintar cuadros o escribir libros. A veces llevamos las comparaciones demasiado lejos.

Evidentemente. Nada es lo mismo que otra cosa. Eso no impide que se puedan llevar ciertos modelos de un sitio a otro con éxito.

> Quien realmente "construye" el software no son personas, ni equipos, ni procesos, son compiladores (o interpretes).

No estoy de acuerdo. Vale que replicarlo tiene coste cero pero no construirlo. El caso es que nos hemos acostumbrado mucho a diseñar y construir nosotros mismos sobre la marcha tirando de creatividad ;) Cuando hacemos proyectos y no productos estamos construyendo el equvalente a un pedido de nmil unidades.

A donde si que admito llevar el debate es que aquí con 5 tíos tienes arreglado un proyecto. Eso ya es otra cosa. Pero hay demasiadas incertidumbres. Tampoco vengais ahora con la katana y me digais que el que no se arriega no gana que eso ya lo se. Eso no impide que si es posible minimizar la incertidumbre haya que hacerlo.

> No sé si con "gracia" te refieres a "gracia divina" porque ciertamente sería milagroso un proceso capaz de conseguir eso que describes. No sé tú, pero yo no lo he visto nunca.

Evidentemente nunca lo he visto. Pero eso no quiere decir que no pueda existir. Evidentemente esto no es un debate práctico porque, para que nos vamos a engañar, esto es la lista de agile-spain y si ni aqui se cree en ágil vamos jodidos. Eso si, yo creo que tiene sentido el que, económicamente, se busque esto. En otros campos se ha dado y han sido empresas que han sido bastante exitosas en lo suyo. De aquí supongo que vienen los centenares de factorías de software basadas en mano de obra barata que, en algunos casos, son rentables. En el fondo están extrapolando un modelo que en otras industrias funciona. ¿Es rentable hacer el "mejor" software con un equipo excelente?

>De esto me quedó la idea que buscaban la excelencia y la iniciativa en sus empleados, y la mejora continua de procesos. Asi un empleado al principio no sería muy experto, pero poco a poco se va convirtiendo en uno.

Esa es la clave. No necesitar contratar gente experta sino que gracias a ti se conviertan en expertos ;) ¿Volvemos al procesos sobre personas? ¿Es el agilismo el proceso excelente?

>el problema de la escalabilidad no es propio de agile, sino un escollo de cualquier metodologia. Vamos, trabajar con 1000 personas no es lo mismo que trabajar con una persona y necesitas organizarte para que sea eficiente.

Ajá. Entonces el proceso para grupos pequeños lo tenemos. ¿Cual es el de grupos grandes?

> El mediocre, JODE un proceso excelente.

¡Sacrifiquémosles! No, en serio. A lo mejor es verdad y directamente hay gente que no tiene remedio. Que penita.

En el fondo todo se vuelve al debate del arte sobre la ciencia. De que nosotros mismos somos los que convertimos esto en un proceso cada vez más creativo y cada vez menos automático ;) Eso, si bien a nosotros nos viene genial ya que cuidamos al individuo frente al proceso, a nivel de factoría es un desastre :D A una factoría le conviene convertir el desarrollo en algo predecible. Nosotros estamos convencidos de hacerlo avanzar mediante procesos que implican la creatividad que no son medibles. ¿Somos la ingeniería menos ingeniería? ¿Por que funcionan entonces las factorías de software? Y no me vengais con que no funcionan porque ahora no voy al sentido técnico de funcionan sino al económico. Si tan maravillosas son las pequeñas empresas ágiles ¿por que aún existen las cárnicas? ¿podemos predecir que se van a morir?

ABAP4 vs Ruby :P (Venga, aquí si que me he ganado un pescozón que esto ya es demasiada provocación)

A lo que voy es que los dos mundos separados, el ágil y el charcu... el de las factorías están ahí. Me parecería raro el que alguien del "otro lado" se pasase por aquí a defenderlo y me niego a creer que sean unos ogros en sus cavernas que solo hacen lo que hacen por joder a los pobrecitos code monkeys que no pueden defenderse.

Esto me pasa por leer demasiados libros de gestión de recursos humanos. ¿Tan diferentes somos del resto de las industrias? A veces no me gusta el cariz que toman estos debates porque sinceramente muchas veces tengo la impresión que nos damos demasiada importancia. ¿Tan importante es el uno frente al grupo? Es demasiado bonito. Eso hace que no seamos hormigas y nos sentimos muy bien.

¿Sería mejor empezar a compararnos con agencias de publicidad más que con ingenieros industriales? Es un sector extraño el nuestro. Cuanto más empresas conozco veo que a las que más nos parecemos (el lado agilista) es a las pequeñas agencias de publicidad. Equipos de creativos que suelen tener mucho trabajo por delante, se matan a horas y nunca saben cuando van a terminar. Ellos también tienen sus macroempresas a las que no les gusta ir a trabajar a los que pretenden "trascender" en su profesión.

P.D: No voy a decir que no me alegre de que las cosas sean así y que no quiero volver a una factoría en lo que me queda de vida pero... :P Me siento un poco troll. Espero que nadie se ofenda porque tengo buen intención O;)

P.P.D. : También podemos decir que parte de este debate de cómo hacer que funcione una factoría se escapa de la temática de la lista y que su mundo nos importa un rábano y sanseacabó. Que se que Alfredo me va a decir esto.

2010/9/10 Harald Messemer <harr...@gmail.com>

[José Manuel Beas]

"You can't save them all, Neo!" :-)

Estoy con tu PD2 y con Alfredo. No merece la pena tratar de buscar maneras de salvar el negocio de las factorías de software. Que lo busquen ellas (si quieren, que no lo harán porque no se sienten amenazadas y probablemente no lo estén). Personalmente prefiero buscar a empresas (formadas por personas) que valoren más la calidad en las relaciones comerciales y los resultados de las mismas (los productos y servicios).

[Rafa de Castro]

Es que tengo mucha curiosidad. Sinceramente hay casos de éxito que me fascinan. Hacen un producto en muchos casos deplorable y no les va mal. Incluso a muchas les va bien. A mi me parece asombroso.

2010/9/11 José Manuel Beas <jose....@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

[Jorge Uriarte Aretxaga]

"Cuanto más empresas conozco veo que a las que más nos parecemos (el lado agilista) es a las pequeñas agencias de publicidad. Equipos de creativos que suelen tener mucho trabajo por delante, se matan a horas y nunca saben cuando van a terminar."

Mal ejemplo, mala comparación... ritmo sostenible y predictibilidad son elementos fundamentales a perseguir...

_
Jorge

>>>>> Blog de .Net y Gestión de proyectos<http://1poquitodtodo.blogspot.com/>

>>>>> Blog de opinión social <http://unmalnacido.blogspot.com/>

>>>>> Blog de World of Warcraft <http://historiasdesdeazeroth.blogspot.com/>
>>>>> Blog de Tiro con Arco <http://litelllon.blogspot.com/>

>>>>>
>>>>>
>>>>>
>>>>> El 9 de septiembre de 2010 13:25, José Manuel Beas <
>>>>> jose....@gmail.com> escribió:
>>>>>
>>>>> 100% con Christian (qué difícil se me hace no llamarte @penyaskito) ;-)
>>>>>>
>>>>>> A ver si soy capaz de resumirlo:

>>>>>> - *autoexigencia *(individual y colectiva) : búsqueda de la mejora y
>>>>>> de la excelencia)
>>>>>> - *autodisciplina *(también individual y colectiva) : respeto a los

>>>>>> procesos, lo que incluye el entrenamiento, en la búsqueda de la mejora y la
>>>>>> excelencia

>>>>>> - *ritmo sostenible* : el factor diferencial entre un proceso de

>>>>>> desarrollo ágil y otros (los anteriores valores son deseables en cualquier
>>>>>> ambiente)
>>>>>>
>>>>>> ¿Qué os parece el resumen? Estoy muy interesado en vuestra opinión.
>>>>>> Gracias.
>>>>>>
>>>>>> Un saludo,
>>>>>> Jose Manuel Beas
>>>>>>
>>>>>> http://agilismo.es
>>>>>> http://jmbeas.iexpertos.com
>>>>>> http://twitter.com/jmbeas
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Has recibido este mensaje porque estás suscrito al grupo "agile-spain"
>>>>>> de Grupos de Google.
>>>>>> Para publicar una entrada en este grupo, envía un correo electrónico a
>>>>>> agile...@googlegroups.com.
>>>>>> Para anular tu suscripción a este grupo, envía un correo electrónico a

>>>>>> agile-spain...@googlegroups.com<agile-spain%2Bunsu...@googlegroups.com>

>>>>>> Para tener acceso a más opciones, visita el grupo en
>>>>>> http://groups.google.com/group/agile-spain?hl=es.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Has recibido este mensaje porque estás suscrito al grupo "agile-spain"
>>>>> de Grupos de Google.
>>>>> Para publicar una entrada en este grupo, envía un correo electrónico a
>>>>> agile...@googlegroups.com.
>>>>> Para anular tu suscripción a este grupo, envía un correo electrónico a

>>>>> agile-spain...@googlegroups.com<agile-spain%2Bunsu...@googlegroups.com>

>>>>> Para tener acceso a más opciones, visita el grupo en
>>>>> http://groups.google.com/group/agile-spain?hl=es.
>>>>>
>>>>
>>>>
>>>> --
>>>> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
>>>> Grupos de Google.
>>>> Para publicar una entrada en este grupo, envía un correo electrónico a
>>>> agile...@googlegroups.com.
>>>> Para anular tu suscripción a este grupo, envía un correo electrónico a

>>>> agile-spain...@googlegroups.com<agile-spain%2Bunsu...@googlegroups.com>

>>>> Para tener acceso a más opciones, visita el grupo en
>>>> http://groups.google.com/group/agile-spain?hl=es.
>>>>
>>>
>>>
>>>
>>> --
>>> Rafa de Castro
>>> raf...@micubiculo.com
>>>
>>> --
>>> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
>>> Grupos de Google.
>>> Para publicar una entrada en este grupo, envía un correo electrónico a
>>> agile...@googlegroups.com.
>>> Para anular tu suscripción a este grupo, envía un correo electrónico a
>>> agile-spain...@googlegroups.com
>>> Para tener acceso a más opciones, visita el grupo en
>>> http://groups.google.com/group/agile-spain?hl=es.
>>>
>>>
>>> --
>>> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
>>> Grupos de Google.
>>> Para publicar una entrada en este grupo, envía un correo electrónico a
>>> agile...@googlegroups.com.
>>> Para anular tu suscripción a este grupo, envía un correo electrónico a

>>> agile-spain...@googlegroups.com<agile-spain%2Bunsu...@googlegroups.com>

>>> Para tener acceso a más opciones, visita el grupo en
>>> http://groups.google.com/group/agile-spain?hl=es.
>>>
>>
>> --
>> Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de
>> Grupos de Google.
>> Para publicar una entrada en este grupo, envía un correo electrónico a
>> agile...@googlegroups.com.
>> Para anular tu suscripción a este grupo, envía un correo electrónico a

>> agile-spain...@googlegroups.com<agile-spain%2Bunsu...@googlegroups.com>

[Harald Messemer]

Es una buena observacion que productos "mal hechos" pueden tener exito
en terminos de negocio.

Creo que merece la pena destacar que son cosas que no tienen una
relacion causa-efecto directa.

Es decir, si tienes una idea genial, la conviertes en producto y lo
comercializas bien puedes tener exito.

Al reves, si eres un crack en programacion y tienes una metodologia
eficaz, pero el producto que sacas no le interesa a nadie, puedes
tener un fracaso.

Incluso, si tienes una metodologia de trabajo nefasta, puedes tener un
producto tecnicamente impecable. Simplemente necesitas mas tiempo y
mas dinero.

En resumen, sin duda es importante saber de tecnologia (sea ingenieria
o artesania :-)) y de organizacion y metodo de trabajo (sea agile o
no), pero si para lo que haces no hay mercado, sera dificil vivir de
ello.

Saludos,
Harald

2010/9/11, Rafa de Castro <raf...@refugioseguro.com>:

>> agile-spain...@googlegroups.com<agile-spain%2Bunsu...@googlegroups.com>

[Luismi Cavallé]

En mi opinión, y en esto no soy experto, el hecho de que crear software de mínima calidad pueda ser rentable es consecuencia de una gran descompensación entre oferta y demanda. La demanda de software está constantemente bastante por encima de su oferta. La consecuencia natural de esta situación sería que los precios subiesen. Sin embargo existe una alternativa a esto, a la que por cierto en España somos muy aficionados, y es que el precio se mantenga bajo a costa de disminuir la calidad. El caso del desarrollo de software en la India es paradigmático en ese sentido.

Creo que está en nuestra mano como profesionales decidir por que queremos apostar: si por el de modelo que aumenta la calidad, nos permite ganar más dinero, estar más orgullosos de nuestro trabajo y produce valor a la sociedad, o por el modelo que disminuye la calidad, nos hace ganar poco, nos desmotiva y produce mierda a la sociedad. 

En la India no tienen elección. Aquí sí la tenemos.

-- Luismi

[Harald Messemer]

Hola Luisma,

Lo que queria decir era que la calidad no es suficiente si lo que
haces a nadie le interesa o no es inovador.

Vamos, hay que mejorar la productividad (=calidad) y ser inovadores.
Solamente si somos inovadores en es una ventaja estrategica saber
programar en espana.

Saludos,
Harald

Pd: De hecho, eso me lo conto (mas o menos) Xavi Albaladejo :-) y
estoy totalmente de acuerdo)

2010/9/12, Luismi Cavallé <lmca...@gmail.com>:

[José Manuel Beas]

Siento discrepar, Harald.

Si tus técnicos son mediocres y hacen un software mediocre, independientemente de que sea innovador o no, tus clientes no recibirán valor. Nuestro trabajo debería consistir en ofrecer valor a nuestros clientes. ¿Por qué una gestión de almacén puede tener defectos que hagan perder el tiempo a decenas de "auxiliares administrativos" pero la beta de un producto innovador sí requiere una alta calidad en los acabados? Mmmm.

Yo creo que debemos ser profesionales cualificados y buscar la excelencia en nuestro trabajo: es una cuestión de actitud. Luego, ya vendrá la ventaja competitiva, sea porque somos más productivos (damos más valor a menor coste) o más innovadores (somos capaces de ofrecer soluciones diferentes y mejores a problemas nuevos o conocidos).

Por lo demás, totalmente de acuerdo con Luismi. No podría estar más de acuerdo con alguien que dice:

Creo que está en nuestra mano como profesionales decidir por que queremos apostar: si por el de modelo que aumenta la calidad, nos permite ganar más dinero, estar más orgullosos de nuestro trabajo y produce valor a la sociedad, o por el modelo que disminuye la calidad, nos hace ganar poco, nos desmotiva y produce mierda a la sociedad. 

Me parece el mejor resumen de lo que quiero hacer en mi vida profesional. Y si no fuera porque aún no tengo trabajo, lo pondría en mi CV. }:-)

[Luismi Cavallé]

No contestaba directamente tu comentario, Harald. Pero matizaré que mi definición de calidad va en la linea de valor percibible por alguien. No lo llamo calidad si el usuario/cliente no lo percibe en forma de beneficio.

Así que creo que estamos de acuerdo

-- Luismi

Sent from my iPhone

[Harald Messemer]

Por supuesto hay que buscar la excelencia y la productividad. En esto
estamos de acuerdo ya hace rato.

Lo que digo es que si quieres vivir de esto, la productividad
normalmente no es suficiente porque no es un fin en si mismo, si no se
produce algo diferencial, inovador o de valor.

Talvez, si trabajas en una empresa de servicios y desarrollas
productos para otros la productividad sola ya te sirve. Pero si no hay
nadie que tiene ideas de productos diferenciales, pronto te costara
que te contraten.

Por otro lado, si solamente te concentras en productividad, y en
especial en el desarrollo software, que los indios son igual de
capaces que nosotros, tienen las mismas herramientas, pero aun mucho
mas baratos.

Saludos,
Harald

2010/9/12, José Manuel Beas <jose....@gmail.com>:

[Enrique Comba Riepenhausen]

Harald toca un tema interesante aquí. Pero creo, personalmente, que
hay un problema de aproximación o de enfoque.

Harald Messemer <harr...@gmail.com>:

> Lo que digo es que si quieres vivir de esto, la productividad
> normalmente no es suficiente porque no es un fin en si mismo, si no se
> produce algo diferencial, inovador o de valor.

La productividad viene de la calidad y experiencia del equipo. Si
tienes un equipo excelente, esta productividad se da
"automáticamente"; es decir, un equipo altamente cualificado y con
pasión produce infinitamente mejor que cualquier otro equipo. Con
equipo no me refiero únicamente a la gente que esta programando, sino
a todo el mundo involucrado en la creación de dicho proyecto.

Por otro lado estoy de acuerdo, la productividad no es un fin en si
mismo. ¿Como podría serlo? O dicho de otra manera, dado que el acto de
creación (programación) de un producto de software es en su naturaleza
creativo. La creatividad se puede entrenar (para ser capaz de ser
creativo cuando se necesita), pero no se pueden hacer procesos que te
permitan ser mas "productivo" siendo creativo. Eso si, cuanta mas
experiencia tienes, mas fácil te es ser creativo (te basas en
experiencias pasadas para encontrar soluciones, es decir tienes un
repositorio de experiencia y ideas a tu alcance).

> Tal vez, si trabajas en una empresa de servicios y desarrollas

> productos para otros la productividad sola ya te sirve. Pero si no hay
> nadie que tiene ideas de productos diferenciales, pronto te costara
> que te contraten.

Si trabajas en una empresa de servicios la productividad en si no te
sirve de nada. Puedes ser todo lo productivo que quieras y producir un
software que no le sirve al cliente ni para reirse un rato.

Si trabajas en una empresa de servicios profesional (es decir con una
ética mínima, profesionalidad y responsabilidad) le estas ofreciendo a
tu cliente algo mas que gente que sabe teclear en un lenguaje de
programación, les estas ofreciendo una experiencia de trabajo, ideas,
les ayudas a canalizar sus ideas transformandolas en el producto que
ellos necesitan, no necesariamente en lo que te pedían inicialmente.

Por otro lado, de lo que hablas tu, Harald, es de una persona (o
personas) innovadoras con ideas de producto. Si yo fuera esa persona
no me dedicaria necesariamente a desarrollar software. El software se
convertiría en un medio de traer mis ideas al mundo. Para mi el
software es un fin en si mismo, una forma de expresión.

Gente con grandes ideas de producto existen en todos los sitios del
mundo (a veces una idea aparece de la nada), no tiene nada que ver con
el desarrollo de software. Independientemente de que necesites
innovación o no tienes que hacer que tu empresa se convierta en un
entorno en el que la innovación y creatividad se respira en el aire;
que la gente que trabaja en ese entorno pueda ser creativa y puedan
mejorar cada día como profesionales.

> Por otro lado, si solamente te concentras en productividad, y en
> especial en el desarrollo software, que los indios son igual de
> capaces que nosotros, tienen las mismas herramientas, pero aun mucho
> mas baratos.

Los indios, como dices, puede que sean mas productivos y baratos. La
diferencia esta en la calidad que produces. Justamente por el hecho de
que mucha gente en la India que decide desarrollar software viene de
entornos pobres y no tienen las mismas posibilidades que tenemos
nosotros no tenemos excusas de mejorar nuestra calidad y
profesionalidad. También tenemos la ventaja cultural que nos permite
decir que no a un cliente y mostrarle que debería enfocarse en otras
cosas o ayudarle a mejorar su producto ofreciendo variantes, etc.

Si lo que quieres es simplemente programar lo que te han dicho, estoy
de acuerdo contigo, Harald, no merece la pena que te den el proyecto,
se ahorrarían mucho dinero contratando un equipo de desarrollo en la
India. Eso si, si eres un profesional que se preocupa por ofrecer el
mejor servicio a tus clientes, si te preocupas por sus problemas y les
ayudas a encontrar la solución que realmente necesitan, si buscas la
excelencia en lo que haces para poder ofrecer este servicio, entonces
no tienes nada que temer de otros equipos de desarrollo que son mas
baratos que tu...

Un Saludo,

Enrique

--
Enrique Comba Riepenhausen
twitter: @ecomba