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.
Saludos
___________________
Agustin Viñao
agustinvinao (Skype)
2009/9/23 Carlos Kozuszko <[email protected]>
> 2009/9/23 Juan Maria Martinez Arce <[email protected]>:
> >
> > Actualmente tenemos un pair trabajando en un proyecto y estamos todos
> > chochos con los resultados. Y se vienen un par de proyectos nuevos para
> los
> > que acordamos hacer pairing.
> >
>
> Aportando sobre lo que dijo Juan y ampliando lo que le decía a Nelson
> recién,
> me parece que uno de los problemas importantes, más allá de lo técnico y lo
> humano, es el conseguir clientes que vean el valor agregado en el pair
> programming y que paguen por ello.
>
> Aparte no todos tenemos el speech de ventas que tiene Obie :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
>
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
