<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="FeedCreator 1.7.2" -->
<rss version="2.0">
	<channel>
		<title>¿Se puede planificar un trabajo que no se sabe medir?</title>
		<description>Comments for ¿Se puede planificar un trabajo que no se sabe medir? at http://www.navegapolis.net , comment 1 to 2 out of 2 comments</description>
		<link>http://www.navegapolis.net</link>
		<lastBuildDate>Fri, 29 Aug 2008 16:53:54 +0100</lastBuildDate>
		<generator>FeedCreator 1.7.2</generator>
		<item>
			<title>Como para trabajar con contratos cerrado</title>
			<link>http://www.navegapolis.net/content/view/450/99/#comment-445</link>
			<description>Completamente de acuerdo.
Además el cliente pide un presupuesto cuando acude con el concepto preliminar, cuando la estadística dice que los errores pueden ser de hasta el 300%.
Sería lógico cerrar el precio al cerrar el SRS, y lógicamente cada petición de cambio durante el desarrollo podría implicar una revisión del contrato.
En un modelo ágil, el trabajar con un contrato cerrado aún es más arriesgado (¿suicida?). En el modelo de trabajo se integra al cliente para que en cada iteración decida modificar o no los requisitos.
En el modelo ágil lo que está contratando el cliente es un servicio de desarrollo según sus indicaciones...
Pero como dices, a ver quién le explica esto a los clientes.

Juan Palacio - -</description>
			<pubDate>Mon, 25 Sep 2006 16:50:08 +0100</pubDate>
		</item>
		<item>
			<title>¿Y a esto habría que añadirle cambios en</title>
			<link>http://www.navegapolis.net/content/view/450/99/#comment-444</link>
			<description>Por ejemplo en la fase SRS dice que la desviación puede ser de entre -33/+50, que no esta mal..., pero supongo que esto será sin tener en cuenta que en el mundo del software los requisitos cambian a cada momento. Es decir esto es suponiendo el mejor escenario posible \&quot;que los requisitos no cambien\&quot;. Si nos vamos al escenario habitual en el que los requisitos cambian constantemente entonces las desviaciones es de esperar que sean aún mucho mayores.

La única conclusión a la que se puede llegar con estos datos es a la de que es casi imposble vender un proyecto software y darle una estimación y presupuesto realista al cliente. Habría que optar por otros módelos no de venta de software sino de venta de servicios de desarrollo de software, el problema es que a ver quien le explica esto a los clientes....
 - -</description>
			<pubDate>Mon, 25 Sep 2006 15:39:25 +0100</pubDate>
		</item>
	</channel>
</rss>
