2009/9/23 Agustin Nicolas Viñao Laseras <[email protected]>: > Un solo comentario al respecto, creo que mas que el cliente asuma los costos > del pair programming, deberia asumirlo la empresa o plantearlo esta, en > cuanto a calidad de producto, menor cantidad de bugs, etc. > > A eso sumarle que en cuanto el PP este asentado se puede llevar adelante > mejor los tiempos de desarrollo. > > No considero que el cliente deba saber como es la metodologia utilizada por > la empresa, no considero que sea el cliente quien "pague" diferente por la > cantidad de programadores, siendo que la aplicacion se estima en horas de > desarrollo, mas alla si tenemos 1, 2 o 20 programadores en dicho proyecto.
Creo que tenés razón parcialmente. Si hablos de proyectos con costo fijo, donde vos le decís al cliente "te cobro $x por hacerte tal desarrollo" entonces al cliente no le importa como vos lo hagas. Uno tiene que ver la forma de hacer el trabajo lo mejor posible, con la mayor productividad posible. Pero ciertamente, eso no es agile web development. En cambio, si uno se pone a disposición del cliente, en una forma mucho más alineada con el agile web development, donde hay mucha más conversación, posibilidad para incorporar cambios rapidamente aunque no hayan sido acordados inicialmente por contrato, etc... Entonces en esos escenarios sí tiene que ver con que el cliente vea como una ventaja el hecho de tener un equipo de dos developers haciendo pair, con respondo a dos developers por separado por ejemplo. Porque en esa modalidad, el cliente paga por hora de trabajo realizada. Para esto obviamente, hace falta una relación donde hay una mayor confianza entre proveedor y cliente. Por lo menos así lo veo yo (como decía Guillermo Nimo) :P -- http://www.ckozus.com http://www.insignia4u.com _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
