¿Planificación Ágil? Sí, es lo que tiene el término “ágil”, ahora todo lo que tenga que ver con el desarrollo de software tiene que ser ágil: metodologías ágiles, testing ágil, agilidad ágil… Así que, ¡Qué demonios! Planificación ágil, o como no morir en el intento de planificar un proyecto.
Te puedo asegurar que escribo muchas líneas de código al día (soy el autor del post), de hecho, escribo líneas de código tanto en el trabajo como por placer. Creo que te equivocas totalmente en encasillarme en el "jefe de proyecto que no tiene ni xxxx idea de desarrollar".
Desde luego no voy a discutir contigo lo de "el que menos curra" ni lo de "el menos ágil", piensa lo que quieras. Eso si, te digo que si desarrollo, sino mira el resto de la temática del blog!!
Tu post está muy bien, pero como le escuché decir a un profesor de la Politécnica de Minas "Compren el office si quieren utilizar M$ Project, además trendrán otros programas muy útiles que les sacarán de más de un apuro"...
#4 si dices que eres programador y jefe de proyecto y defiendes la "supuesta" metodología agil, es porque ni eres programador ni eres jefe de proyecto. Eres como mucho un enteradillo que se cree que todo lo sabe y se cree que todo lo hace.
Y te lo digo desde el punto de vista que me dan mis 12 años de experiencia, primoero como porgramador y luego con el tiempo como jefe de proyecto, no por meterme contigo.
Me quedo con lo de "Pon una BD para cada desarrollador".... Chico, te encuentras algunas animaladas en algunas ocasiones que no sabes que pensar.
Por cierto, gestión de recursos como vacaciones, ausencias, cambio de prioridades, gestión del riesgo o de cambios..... Por no hablar de los informes al cliente enseñándoles un Excel, TRIUNFAL!!!!
Sería más acertado decir que este "Excel" te pueda ayudar, pero no a olvidarte del Project, a no ser que gestiones a 1-2 personas claro, como parecer ser el caso.
Titular
¿Planificación Ágil? Sí, es lo que tiene el término “ágil”, ahora todo lo que tenga que ver con el desarrollo de software tiene que ser ágil: metodologías ágiles, testing ágil, agilidad ágil… Así que, ¡Qué demonios! Planificación ágil, o como no morir en el intento de planificar un proyecto.
En resumen, ¿de donde has sacado que todo lo que tenga que ver con el desarrollo de software tiene que ser ágil?
Esto es lo que memosqueó en primer lugar, estás basando todos tus argumentos para defender una metodología vaporware (como bien han dicho antes) en una afirmación que te sacas de la manga, que no es cierta ni de lejos, y que pretendes hacer válida a toda costa sin ningún tipo de justificación.
Por otro lado yo no te he descalificado solo he dicho que si realmente confias en una metodología que no tiene más interés que el poder decir que haces los proyectos en la mitad de tiempo, pero arreglar los errores lleva el doble, no deberías presumir de blog ni de experiencia, por muy interesantes que puedan ser alguunos artículos (que seguro los hay), y por muy dilatada que sea tu carrera.
Y es por esto último que hablé de la mia, porque despues de 12 años se que al final, lo único que le importa al cliente es el resultado final (casi más que sea bonito, que que sea funcional), a tus jefes los beneficios (la metodología es solo para sacar la ISO) y a la gente de tu equipo hacer las mínimas horas extras y trabajar los menos fines de samana posible. ¿Puede la metodología Ágil contentar a todos? ni de coña, así que lo mejor es adaptarse:
Que en tu caso planificas mejor con el Excel, cojonudo, de hecho el sistema no es tan descabellado, pero no funcionaría en la mitad de los proyectos que he trabajado, así como en la otra mitad habrías resultado muy util. Se de mucha gente que con el project hace maravillas, en mi caso lo uso lo mínimo posible ya por suerte para mi, ahora hago otro tipo de trabajo que no me requiere su uso.
Por último decir que a mi el karma me la suda, supongo que para ti es algo importante, ya que lo has mencionado, si quieres te doy mis 7 puntos, que se ve que te hacen falta para algo.
#7 Hoy en día puedes tener un BD para cada developer perfectamente (CADA UNO EN SU MÁQUINA). Mysql? seguro, Oracle? ponle 2 GB de ram a tus desarrolladores, que está tirada de precio.
De todas formas, ya que "te quedas con lo de", quedate con ello entero "Pon una BD para cada desarrollador, si no puedes permitírtelo crea protocolos que eviten o minimicen estos problemas".
Sobre lo de olvidarse del proyect, si ves la entrada anterior pongo, literalmente:
Entonces, ¿No vale para nada el MS Project? ¿Hay que huir de ellos como el demonio? Yo no llegaría a tanto, simplemente hay que tener en cuenta sus limitaciones y las implicaciones que tiene. En ciertos proyectos grandes, con muchas dependencias, puede estar justificado su uso. Pero para proyectos pequeños y medianos existen mejores herramientas.
#10 Hombre, era un comiento irónico, coño, que pongo "Agilidad ágil", pero bueno te lo traduzco a modo no irónico:
"Como parece que ahora todo tiene que ser ágil (observa las comillas del original) pues nada te presento una forma de planificar con Excel y la llamamo ágil"
Segundo, no pretendo hacer válido a toda cosa la utilización del Excel, explico lo que me ha valido a mi y a varias personas.
No presumo de blog ni de experiencia, no se de donde has sacado esa conclusión (me gustaría que me indicaras el parrafo exacto), de echo de nosotros dos creo ser el único que no ha comentado cuantos años de experiencia tiene ni deja de tener.
Así que en resumen, yo no puedo presumir de experiencia (que no lo hago en ningún momento) pero tu no puedes parar de presumir de tu experiencia (si, nos has dicho ya 2 veces que tienes 12 años de experiencia)
para karni0:
"estás basando todos tus argumentos para defender una metodología vaporware"
¿Vaporware? Mira, yo no sé si alguna vez has intentado poner en práctica alguna de las prácticas (valga la redundancia) que por ejemplo la Extreme Programming o Scrum proponen, pero es que macho, son de sentido común. No todas, ojo, pero si me niegas la utilidad del frequent releasement, user stories o TDD (por nombrar algunas), no sabría qué pensar. Otras propuestas como el cliente in-house o iteraciones cada 2 semanas exactas, pues es muy discutible y yo creo que no es que no funcionarían, sino que provienen desde el punto de vista anglosajón y en empresas extranjeras es más fácil su introducción. Para no extenderme, a mí me harías un favor enorme si nos explicaras el por qué consideras vaporware a dicha forma de llevar los proyectos (y pon en cc a Microsoft, que lleva años usando Scrum).
__ "Por otro lado yo no te he descalificado solo he dicho que si realmente confias en una metodología que no tiene más interés que el poder decir que haces los proyectos en la mitad de tiempo, pero arreglar los errores lleva el doble..."
Bueno, bueno, a ver por dónde empiezo. ¿Proyectos en la mitad de tiempo? ¿De dónde te has sacado que proclame tal tontería? ¿En la mitad de tiempo que qué? Y ahora lo mejor, y es que no entiendo eso de "arreglar los errores lleva el doble" ... No sé dónde pone eso tampoco, pero en todo caso sería todo lo contrario. Créeme, al contrario que las tecnologías más tradicionales (que no peores) como cascada, RUP o ERUP, las metodologías ágiles se basan en algo tan lógico como lo siguiente: cuanto más se tarda en arreglar un bug a lo largo del proyecto, más aumenta el coste de solucionarlo. Sentido común, vamos. En fin, que a un profesional como tú con tantos años de experiencia, no le he descubierto nada nuevo. Sólo por refrescar.
"...lo único que le importa al cliente es el resultado final (casi más que sea bonito, que que sea funcional), a tus jefes los beneficios (la metodología es solo para sacar la ISO) y a la gente de tu equipo hacer las mínimas horas extras y trabajar los menos fines de samana posible"
Bueno, no puedo estar de acuerdo. De primeras, al cliente le importa más o menos un aspecto de la aplicación dependiendo de quién es el cliente. Si alguna vez te topas con cliente no dotado de conocimientos técnicos y que confía ciegamente en ti en ese aspecto, te puedo asegurar que en las reuniones de seguimiento de lo único que se va a preocupar es de los aspectos estéticos. Te lo aseguro. Puedes ir con tu flamante estrategia de persistencia implementada, pero como no hayas cuidado tu look and feel, incluso dejando claro que no es final, el curso de las reuniones van a ser en un 90% comentarios del "pues podíais poner esta caja de texto ahí, y esta zona en verde, que en blanco es muy feo". Evidentemente, esto no es cierto al 100%, lo que quiero hacer ver es que hay que encontrar un equilibrio al dedicar esfuerzos a los aspectos que no le importan un pito al cliente, y lo que es de vital importancia para él.
Vamos con los beneficios y los jefes. La verdad que no sé qué pensar. ¿Qué clases de jefes has tenido? o mejor, ¿eres jefe? Evidentemente los beneficios es lo que importa, pero hay jefes que ven más allá del "ganar a toda costa" e intentan aplicar responsablemente aquello que pueda ayudar a los objetivos del proyecto (metodologías, tecnologías, etc etc). Eso de que la metodología es para sacarse la ISO es, sin ánimo de ofensa, una de las mayores gilipolleces que he oído nunca. Y si tu crees en ello y te sirve, chapó.
Otra pregunta a la cola, ¿das por hecho que un equipo tiene que meter horas extras y fines de semana? Si es así, me parece lógico que el objetivo sea minimizar dicho tiempo. Gran filosofía del trabajo (incluyo lo de la ISO también) aplicada por los managares y directivos de las grandes consultoras aquí en España. Quizás tengas razón, pensando que hay que meter horas y fines de semana de por sí, una empresa ve tu brazo cuando le estás mostrando ¡el brazo! O quizás visto al revés, como te dicen que meter horas y fines de semana es "cultura empresarial", pues lo ves como lo normal. Y vuelta a empezar.
"Se de mucha gente que con el project hace maravillas"
Jaja, perdona las risas (pero es que he soltado un carcajada). ¡Explícame en qué consisten dichas maravillas! Yo sí que he visto hacer virguerías con un lenguaje de programación, con un script, con un programa de retoque fotográfico, con una llave inglesa ... pero ¡con el MS Project! No digo que no se pueda, sólo que me des algunos ejemplos por favor.
"...ahora hago otro tipo de trabajo que no me requiere su uso."
Vaya, entonces para gestionarte/planificarte, o para gestionar el trabajo de un equipo, ¿qué utilizas ahora?
Por último, algo en lo que creo profundamente, X años de experiencia no dice nada de la calidad profesinal que te ha dado esa experiencia. Vaporware
#6 Sí, realmente no soy un programador ni un JP, soy un elfo y vivo en el bosque.
¡Qué argumentación!, 12 años de experiencia te dan para poder argumentar tan poco las cosas como para decir "No eres programador ni nada, solo un enterado, te lo digo yo que tengo 12 años de experiencia" (me he tomado la liberad de resumir lo dicho)
Desde luego no voy a discutir contigo mi profesionalidad o falta de profesionalidad, como tampoco voy a discutir la tuya. Si no estas de acuerdo con el post explicanos por qué, y sino sigue acumulando años de "experiencia", me han dicho que da karma en Meneame.
Así que, ¿Qué puntos no te gustan de las metodologías ágiles? Para mi no son perfectas pero tienen muchos puntos positivos
y por último ¿En qué discrepas del post? (se concreto por favor, y sin descalificaciones personales por favor)
vaporware agil!
chapuza agil!
coge el dinero y corre!
Madre mia, y tener que aguantar esto programando por 1000€ al mes... Encima se pensara que ha inventado la polvora cuando el que menos curra y el menos "agil" del equipo es el "planificador". Luego cuando el cliente se queja y viene la tormenta de mierda el marron se lo comen los programadores, no el "agil" planificador que igual no ha escrito ni 2 lineas de codigo en su vida. Eso si, es un "tesnico esperto" en el "escel".
Informaticos del mundo, meteos a albañiles o fontaneros que se gana mas y no por lo menos no tendreis que aguantar "monchitos".
HOYGAME, dudo mucho que "planificador" o jefe de proyecto sea el que menos curra en un equipo de desarrollo. Simplemente con tener que aguantar a los clientes, tenemos el suledo ganado. Además hay que llevar una gestion tanto de recursos económicos, como de las personas que integran el equipo y te puedo asegurar que tratar de tener contentos a 30 personas, para que realicen bien su trabajo no es nada facil. Los programadores puros, solamente se tienen que preocupar de programar, siempre basandose en un DT previamente hecho por un AP por lo menos, con lo que no tienen que preocuparse de cosas tan triviales como los nombres de las clases, de los métodos, etc, solo tienen que programar. Es duro, lo se, la mayoria de los JP hemos pasado por ahi previamente y para mi el mejor JP es aquel que previemente fue el mejor PJ.
Comentarios
#2 pero tu te has leido el post??!!
Te puedo asegurar que escribo muchas líneas de código al día (soy el autor del post), de hecho, escribo líneas de código tanto en el trabajo como por placer. Creo que te equivocas totalmente en encasillarme en el "jefe de proyecto que no tiene ni xxxx idea de desarrollar".
Desde luego no voy a discutir contigo lo de "el que menos curra" ni lo de "el menos ágil", piensa lo que quieras. Eso si, te digo que si desarrollo, sino mira el resto de la temática del blog!!
Lo de la metodología "agil" lleban años intentando meternoslo en la cabeza, pero es algo que deja de funcionar fuera de las cabezas de los managers.
Tu post está muy bien, pero como le escuché decir a un profesor de la Politécnica de Minas "Compren el office si quieren utilizar M$ Project, además trendrán otros programas muy útiles que les sacarán de más de un apuro"...
Triste, mu triste
#4 si dices que eres programador y jefe de proyecto y defiendes la "supuesta" metodología agil, es porque ni eres programador ni eres jefe de proyecto. Eres como mucho un enteradillo que se cree que todo lo sabe y se cree que todo lo hace.
Y te lo digo desde el punto de vista que me dan mis 12 años de experiencia, primoero como porgramador y luego con el tiempo como jefe de proyecto, no por meterme contigo.
Me quedo con lo de "Pon una BD para cada desarrollador".... Chico, te encuentras algunas animaladas en algunas ocasiones que no sabes que pensar.
Por cierto, gestión de recursos como vacaciones, ausencias, cambio de prioridades, gestión del riesgo o de cambios..... Por no hablar de los informes al cliente enseñándoles un Excel, TRIUNFAL!!!!
Sería más acertado decir que este "Excel" te pueda ayudar, pero no a olvidarte del Project, a no ser que gestiones a 1-2 personas claro, como parecer ser el caso.
Titular
¿Planificación Ágil? Sí, es lo que tiene el término “ágil”, ahora todo lo que tenga que ver con el desarrollo de software tiene que ser ágil: metodologías ágiles, testing ágil, agilidad ágil… Así que, ¡Qué demonios! Planificación ágil, o como no morir en el intento de planificar un proyecto.
En resumen, ¿de donde has sacado que todo lo que tenga que ver con el desarrollo de software tiene que ser ágil?
Esto es lo que memosqueó en primer lugar, estás basando todos tus argumentos para defender una metodología vaporware (como bien han dicho antes) en una afirmación que te sacas de la manga, que no es cierta ni de lejos, y que pretendes hacer válida a toda costa sin ningún tipo de justificación.
Por otro lado yo no te he descalificado solo he dicho que si realmente confias en una metodología que no tiene más interés que el poder decir que haces los proyectos en la mitad de tiempo, pero arreglar los errores lleva el doble, no deberías presumir de blog ni de experiencia, por muy interesantes que puedan ser alguunos artículos (que seguro los hay), y por muy dilatada que sea tu carrera.
Y es por esto último que hablé de la mia, porque despues de 12 años se que al final, lo único que le importa al cliente es el resultado final (casi más que sea bonito, que que sea funcional), a tus jefes los beneficios (la metodología es solo para sacar la ISO) y a la gente de tu equipo hacer las mínimas horas extras y trabajar los menos fines de samana posible. ¿Puede la metodología Ágil contentar a todos? ni de coña, así que lo mejor es adaptarse:
Que en tu caso planificas mejor con el Excel, cojonudo, de hecho el sistema no es tan descabellado, pero no funcionaría en la mitad de los proyectos que he trabajado, así como en la otra mitad habrías resultado muy util. Se de mucha gente que con el project hace maravillas, en mi caso lo uso lo mínimo posible ya por suerte para mi, ahora hago otro tipo de trabajo que no me requiere su uso.
Por último decir que a mi el karma me la suda, supongo que para ti es algo importante, ya que lo has mencionado, si quieres te doy mis 7 puntos, que se ve que te hacen falta para algo.
#7 Hoy en día puedes tener un BD para cada developer perfectamente (CADA UNO EN SU MÁQUINA). Mysql? seguro, Oracle? ponle 2 GB de ram a tus desarrolladores, que está tirada de precio.
De todas formas, ya que "te quedas con lo de", quedate con ello entero "Pon una BD para cada desarrollador, si no puedes permitírtelo crea protocolos que eviten o minimicen estos problemas".
Sobre lo de olvidarse del proyect, si ves la entrada anterior pongo, literalmente:
Entonces, ¿No vale para nada el MS Project? ¿Hay que huir de ellos como el demonio? Yo no llegaría a tanto, simplemente hay que tener en cuenta sus limitaciones y las implicaciones que tiene. En ciertos proyectos grandes, con muchas dependencias, puede estar justificado su uso. Pero para proyectos pequeños y medianos existen mejores herramientas.
No se si queda claro...
#10 Hombre, era un comiento irónico, coño, que pongo "Agilidad ágil", pero bueno te lo traduzco a modo no irónico:
"Como parece que ahora todo tiene que ser ágil (observa las comillas del original) pues nada te presento una forma de planificar con Excel y la llamamo ágil"
Segundo, no pretendo hacer válido a toda cosa la utilización del Excel, explico lo que me ha valido a mi y a varias personas.
No presumo de blog ni de experiencia, no se de donde has sacado esa conclusión (me gustaría que me indicaras el parrafo exacto), de echo de nosotros dos creo ser el único que no ha comentado cuantos años de experiencia tiene ni deja de tener.
Así que en resumen, yo no puedo presumir de experiencia (que no lo hago en ningún momento) pero tu no puedes parar de presumir de tu experiencia (si, nos has dicho ya 2 veces que tienes 12 años de experiencia)
Hola,
para karni0:
"estás basando todos tus argumentos para defender una metodología vaporware"
¿Vaporware? Mira, yo no sé si alguna vez has intentado poner en práctica alguna de las prácticas (valga la redundancia) que por ejemplo la Extreme Programming o Scrum proponen, pero es que macho, son de sentido común. No todas, ojo, pero si me niegas la utilidad del frequent releasement, user stories o TDD (por nombrar algunas), no sabría qué pensar. Otras propuestas como el cliente in-house o iteraciones cada 2 semanas exactas, pues es muy discutible y yo creo que no es que no funcionarían, sino que provienen desde el punto de vista anglosajón y en empresas extranjeras es más fácil su introducción. Para no extenderme, a mí me harías un favor enorme si nos explicaras el por qué consideras vaporware a dicha forma de llevar los proyectos (y pon en cc a Microsoft, que lleva años usando Scrum).
__ "Por otro lado yo no te he descalificado solo he dicho que si realmente confias en una metodología que no tiene más interés que el poder decir que haces los proyectos en la mitad de tiempo, pero arreglar los errores lleva el doble..."
Bueno, bueno, a ver por dónde empiezo. ¿Proyectos en la mitad de tiempo? ¿De dónde te has sacado que proclame tal tontería? ¿En la mitad de tiempo que qué? Y ahora lo mejor, y es que no entiendo eso de "arreglar los errores lleva el doble" ... No sé dónde pone eso tampoco, pero en todo caso sería todo lo contrario. Créeme, al contrario que las tecnologías más tradicionales (que no peores) como cascada, RUP o ERUP, las metodologías ágiles se basan en algo tan lógico como lo siguiente: cuanto más se tarda en arreglar un bug a lo largo del proyecto, más aumenta el coste de solucionarlo. Sentido común, vamos. En fin, que a un profesional como tú con tantos años de experiencia, no le he descubierto nada nuevo. Sólo por refrescar.
"...lo único que le importa al cliente es el resultado final (casi más que sea bonito, que que sea funcional), a tus jefes los beneficios (la metodología es solo para sacar la ISO) y a la gente de tu equipo hacer las mínimas horas extras y trabajar los menos fines de samana posible"
Bueno, no puedo estar de acuerdo. De primeras, al cliente le importa más o menos un aspecto de la aplicación dependiendo de quién es el cliente. Si alguna vez te topas con cliente no dotado de conocimientos técnicos y que confía ciegamente en ti en ese aspecto, te puedo asegurar que en las reuniones de seguimiento de lo único que se va a preocupar es de los aspectos estéticos. Te lo aseguro. Puedes ir con tu flamante estrategia de persistencia implementada, pero como no hayas cuidado tu look and feel, incluso dejando claro que no es final, el curso de las reuniones van a ser en un 90% comentarios del "pues podíais poner esta caja de texto ahí, y esta zona en verde, que en blanco es muy feo". Evidentemente, esto no es cierto al 100%, lo que quiero hacer ver es que hay que encontrar un equilibrio al dedicar esfuerzos a los aspectos que no le importan un pito al cliente, y lo que es de vital importancia para él.
Vamos con los beneficios y los jefes. La verdad que no sé qué pensar. ¿Qué clases de jefes has tenido? o mejor, ¿eres jefe? Evidentemente los beneficios es lo que importa, pero hay jefes que ven más allá del "ganar a toda costa" e intentan aplicar responsablemente aquello que pueda ayudar a los objetivos del proyecto (metodologías, tecnologías, etc etc). Eso de que la metodología es para sacarse la ISO es, sin ánimo de ofensa, una de las mayores gilipolleces que he oído nunca. Y si tu crees en ello y te sirve, chapó.
Otra pregunta a la cola, ¿das por hecho que un equipo tiene que meter horas extras y fines de semana? Si es así, me parece lógico que el objetivo sea minimizar dicho tiempo. Gran filosofía del trabajo (incluyo lo de la ISO también) aplicada por los managares y directivos de las grandes consultoras aquí en España. Quizás tengas razón, pensando que hay que meter horas y fines de semana de por sí, una empresa ve tu brazo cuando le estás mostrando ¡el brazo! O quizás visto al revés, como te dicen que meter horas y fines de semana es "cultura empresarial", pues lo ves como lo normal. Y vuelta a empezar.
"Se de mucha gente que con el project hace maravillas"
Jaja, perdona las risas (pero es que he soltado un carcajada). ¡Explícame en qué consisten dichas maravillas! Yo sí que he visto hacer virguerías con un lenguaje de programación, con un script, con un programa de retoque fotográfico, con una llave inglesa ... pero ¡con el MS Project! No digo que no se pueda, sólo que me des algunos ejemplos por favor.
"...ahora hago otro tipo de trabajo que no me requiere su uso."
Vaya, entonces para gestionarte/planificarte, o para gestionar el trabajo de un equipo, ¿qué utilizas ahora?
Por último, algo en lo que creo profundamente, X años de experiencia no dice nada de la calidad profesinal que te ha dado esa experiencia. Vaporware
#6 Sí, realmente no soy un programador ni un JP, soy un elfo y vivo en el bosque.
¡Qué argumentación!, 12 años de experiencia te dan para poder argumentar tan poco las cosas como para decir "No eres programador ni nada, solo un enterado, te lo digo yo que tengo 12 años de experiencia" (me he tomado la liberad de resumir lo dicho)
Desde luego no voy a discutir contigo mi profesionalidad o falta de profesionalidad, como tampoco voy a discutir la tuya. Si no estas de acuerdo con el post explicanos por qué, y sino sigue acumulando años de "experiencia", me han dicho que da karma en Meneame.
Así que, ¿Qué puntos no te gustan de las metodologías ágiles? Para mi no son perfectas pero tienen muchos puntos positivos
y por último ¿En qué discrepas del post? (se concreto por favor, y sin descalificaciones personales por favor)
vaporware agil!
chapuza agil!
coge el dinero y corre!
Madre mia, y tener que aguantar esto programando por 1000€ al mes... Encima se pensara que ha inventado la polvora cuando el que menos curra y el menos "agil" del equipo es el "planificador". Luego cuando el cliente se queja y viene la tormenta de mierda el marron se lo comen los programadores, no el "agil" planificador que igual no ha escrito ni 2 lineas de codigo en su vida. Eso si, es un "tesnico esperto" en el "escel".
Informaticos del mundo, meteos a albañiles o fontaneros que se gana mas y no por lo menos no tendreis que aguantar "monchitos".
HOYGAME, dudo mucho que "planificador" o jefe de proyecto sea el que menos curra en un equipo de desarrollo. Simplemente con tener que aguantar a los clientes, tenemos el suledo ganado. Además hay que llevar una gestion tanto de recursos económicos, como de las personas que integran el equipo y te puedo asegurar que tratar de tener contentos a 30 personas, para que realicen bien su trabajo no es nada facil. Los programadores puros, solamente se tienen que preocupar de programar, siempre basandose en un DT previamente hecho por un AP por lo menos, con lo que no tienen que preocuparse de cosas tan triviales como los nombres de las clases, de los métodos, etc, solo tienen que programar. Es duro, lo se, la mayoria de los JP hemos pasado por ahi previamente y para mi el mejor JP es aquel que previemente fue el mejor PJ.