<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="FeedCreator 1.7.2" -->
<rss version="2.0">
	<channel>
		<title>¿Requisitos cerrados, o evolutivos?</title>
		<description>Comments for ¿Requisitos cerrados, o evolutivos? at http://www.navegapolis.net , comment 1 to 2 out of 2 comments</description>
		<link>http://www.navegapolis.net</link>
		<lastBuildDate>Fri, 05 Sep 2008 21:16:41 +0100</lastBuildDate>
		<generator>FeedCreator 1.7.2</generator>
		<item>
			<title>re: en desacuerdo con...</title>
			<link>http://www.navegapolis.net/content/view/429/58/#comment-470</link>
			<description>Hola... (porfa, firmarme los comentarios que si no no puedo casi ni contestar :-)
Si que es cierto que PMI y SEI reconocen la compatibilidad de la agilidad con sus modelos, pero creo (es mi opinión) que es más una evolución normal por la aparición de su antítesis: la agilidad.
Pero lo cierto es que el principio y la identidad de SEI es el principio básico de la calidad de Jurán, afirmado por Humphrey: la calidad del producto depende de la calidad de los procesos, y el principio de la gestión de proyectos de PMI es un principio predictivo sobre un plan previo que sin requisitos detallados no puede construirse.
Estos principios son su identidad, y son buenos. No deberían renunciar a ellos porque haya surgido la agilidad, de hecho esa antítesis ha surgido gracias a tesis que ellos han construido.
En muchos proyectos la agilidad y la adaptabilidad no es tan apropiada como la predictibillidad (vaya palabros :-).
Quizá esté confundido, pero PMI SEI han hecho grandes aportaciones y es necesario conocer sus modelos.
La agilidad también ha abierto los ojos a aspectos que PMI y SEI olvidaban, pero la verdad absoluta no la tendrá nunca ningún modelo.
Gracias a la tesis de los primeros que se remangaron para crear el conocimiento de nuestra profesión (PMI) y a la antítesis de los ágiles, vamos aprendiendo lo bueno y malo de cada uno, que todos aciertan, y todos nos equivocamos... 
Creo que ya tenemos perfilada la línea de síntesis hacia la que vamos.
Lo que ocurre también es que también es humano el decir no... si a eso me refería...
De ahí que los ágiles, tras las \&quot;broncas\&quot; iniciales que armaron descalificando a los procesos, vayan rectificando hacia posturas de \&quot;equilibrio\&quot; y que PMI y SEI en sus ultimas versiones abandonen también la postura de enrocamiento y admitan que no, que sus modelos son compatibles con la agilidad.

Por eso creo que no estamos tan en desacuerdo, es que el conocimiento no es estable, y claro que CMMI y PMI están abriendo espacio a la agilidad... están evolucionando. Quizá por lo que nos despistamos es porque no reconocen el cambio.

Juan Palacio - -</description>
			<pubDate>Fri, 20 Oct 2006 16:45:10 +0100</pubDate>
		</item>
		<item>
			<title>en desacuerdo con algunos puntos...</title>
			<link>http://www.navegapolis.net/content/view/429/58/#comment-500</link>
			<description>Estimado Juan,
creo que la frase de Pressman que comentas no es excluyente con la visión ágil; comprender perfectamente los requisitos determinará el éxito del proyecto ya sea que los entiendas al principio como que los entiendas gradualmente.
Los modelos para mejora de procesos como CMMI no impiden trabajar en forma ágil. CMMI da lineamientos, no especifica procesos, por lo que puedo implementar un framework de procesos ágil cumpliendo los lineamientos de CMMI.
Por la parte de gestión de proyecto, el PMI a través de su PMBoK (al menos en su última edición) insiste en la naturaleza progresiva e iterativa de los proyectos y la necesidad de ejecutar procesos y revisitarlos a medida que avanzamos. Es más, da como ejemplo en proyectos de software el caso de ejecución paralela de actividades de diferentes \&quot;fases\&quot; para reforzar su postura... Tampoco es excluyente con la visión ágil.

No pretendo contradecir tus comentarios, solo escribo estas lineas para darte mi opinión sobre estos temas puntuales. Creo que la agilidad o no agilidad de los proyectos de desarrollo tienen más que ver con en enfoque de quien implementa los procesos, más que con los estándares de proceso que estos últimos han ido evolucionando y se presentan bastante poco rígidos... (excepto por SOX, pero de esto mejor ni hablar) - -</description>
			<pubDate>Fri, 20 Oct 2006 15:00:22 +0100</pubDate>
		</item>
	</channel>
</rss>
