<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="FeedCreator 1.7.2" -->
<rss version="2.0">
	<channel>
		<title>Factor de escala y agilidad</title>
		<description>Comments for Factor de escala y agilidad at http://www.navegapolis.net , comment 1 to 2 out of 2 comments</description>
		<link>http://www.navegapolis.net</link>
		<lastBuildDate>Sat, 20 Mar 2010 05:54:19 +0100</lastBuildDate>
		<generator>FeedCreator 1.7.2</generator>
		<item>
			<title>...</title>
			<link>http://www.navegapolis.net/content/view/670/98/#comment-942</link>
			<description>Completamente de acuerdo Luis.
No solamente si el desarrollo es lento.
Si el cliente no quiere innovación, sino que sabe perfectamente qué es lo que quiere y cómo lo quiere. Si el grado de inestabilidad de requisitos previsto no es alto durante el desarrollo, tiene razón Humphrey: lo más eficiente es hacerlo bien a la primera. El cliente quiere previsibilidad, saber coste y fechas y poder garantizalas. No quiere un sistema en desarrollo incremental con innovación continua, etc.

Cuando se desarrolla el mismo sistema de gestión del club deportivo, solo que ahora ya no en MS-DOS, y que controle los tornos de acceso (por ejemplo), si no se hace una buena obtención de requisitos al principio, es porque no se quiere, y si no se hace una gestión de proyectos predictiva, lo mismo. 

 - Juan</description>
			<pubDate>Thu, 06 Sep 2007 07:34:45 +0100</pubDate>
		</item>
		<item>
			<title>Descomponiendo la cuestion</title>
			<link>http://www.navegapolis.net/content/view/670/98/#comment-939</link>
			<description>Estoy relativamente de acuerdo. Hoy en día casi todos convendremos que los desarrollos monolíticos, cerrados y largos (¿Por qué siempre se asocia eso?) no estan de moda, no son efectivos, no son... ¿Pero y si son cortos?

Es cierto no recuerdo apenas ninguna experiencia de un proyecto en que los requisitos no fueran evolucionando con cada entregable (y a veces sin él) pero cada pequeña iteración puede ser perfectamente un proceso &quot;cerrado&quot;. 

Estoy siendo flexible en los conceptos, no me saquéis ahora la metodología tal o cual. Lo que quiero decir es que estoy de acuerdo en la idea final pero no veo la relación con el aumento de usuarios, es más, si estás haciendo algo para un sólo cliente, aunque él lo ponga para millones de usuarios, es 1 cliente y 1 feedback. Pero si los millones son tus usuarios ese [i]feddback[/i] será interminable. Desde luego que será necerio, no hay sistema que se precie de tener un buen volumen de usuarios que no tenga que estar mejorando día a día, pero esa mejora tiene un coste grande, muy grande a veces. La propia escala de usuarios tiene un coste para la casa de software, incluso aunque esta no sea online/servicio. Hoy por hoy no hay programas sin servicios de soporte, actualizaciones, etc. Y crecer, escalar... es muy difícil. Ver sino lo prágmático que puede llegara ser un sistema en la entrevista a un arquitecto jefe de eBay http://www.infoq.com/interviews/dan-pritchett-ebay-architecture;jsessionid=90D547A68CFD02646FC4882027DB7D7B

Quizá me he desvidado un poco pero última frase de requisitos simpre abiertos me recuerda demasiado a muchos proyectos [i]interminables[/i]. Al final hay que tener un conjunto de requisitos generales mínimos a cumplir para cerrar un proyectos.


 - lboisset</description>
			<pubDate>Thu, 06 Sep 2007 00:02:21 +0100</pubDate>
		</item>
	</channel>
</rss>
