<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-1048881-6";
urchinTracker();
</script><?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rss [<!ENTITY % HTMLlat1 PUBLIC "-//W3C//ENTITIES Latin 1 for XHTML//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent">]>
<rss version="2.0" xml:base="http://www.agile-spain.com/agilev2">
<channel>
 <title>agile-spain.com - Comunicación</title>
 <link>http://www.agile-spain.com/agilev2/taxonomy/term/42/all</link>
 <description>Noticias sobre todas aquellas prácticas que tengan que ver con aumentar o gestionar la comunicación dentro de un equipo: Programación por parejas, Comunicación a través de internet, Problemas de comunicación en la subcontratación, Reunión diaria, Cuando y qué documentar, etc.</description>
 <language>es</language>
<item>
 <title>El porqué de las tres preguntas de la reunión diaria</title>
 <link>http://www.agile-spain.com/agilev2/el_porque_de_las_tres_preguntas_de_la_reunion_diaria</link>
 <description>&lt;p&gt;En numerosos textos y libros se habla de la reunión diaria (de pie) como una de las buenas prácticas común a muchos métodos ágiles. En esta reunión cada miembro del equipo da respuesta a tres preguntas:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;¿Qué hiciste ayer?
&lt;li&gt;¿Qué prevees hacer hoy?
&lt;li&gt;¿Qué impedimentos te has encontrado?
&lt;/ul&gt;
&lt;p&gt;Pero, si bien es habitual encontrar listadas esas tres preguntas, es más complicado dar con la explicación de las mismas. Jeff Sutherland, uno de los principales promotores de SCRUM (quizá el primero de los métodos que empleó esta práctica) nos ofrece su visión en el artículo &lt;a href=&quot;http://jeffsutherland.com/scrum/2006/06/why-three-questions-in-daily-scrum.html&quot;&gt; Why the Three Questions in the Daily Scrum Meeting?&lt;/a&gt;&lt;/p&gt;
</description>
 <category domain="http://www.agile-spain.com/agilev2/tema/comunicacion">Comunicación</category>
 <pubDate>Sun, 04 Jun 2006 20:32:20 +0000</pubDate>
</item>
<item>
 <title>Lanzada la web AgileDraw</title>
 <link>http://www.agile-spain.com/agilev2/agiledraw_0</link>
 <description>&lt;p&gt;miguelcalix nos cuenta:&lt;br /&gt;
&lt;i&gt;&lt;A HREF=&quot;http://agiledraw.org/&quot;&gt;Agile Draw&lt;/A&gt; fué lanzado el mes pasado como una iniciativa para hacer del modelaje una tarea simple, libre y efectiva. En resumen es un set de principios y estilos para crear modelos simples y efectivos. El objetivo es usar un minimo de elementos de dibujo (circulos, cajas, lineas de conexion y texto) que combinados comuniquen de una manera consistente. Estos principios pueden ser usados con cualquier tecnica y herramienta de dibujo (sea un pizarrón o MS visio).&lt;/i&gt;&lt;/p&gt;
</description>
 <category domain="http://www.agile-spain.com/agilev2/tema/comunicacion">Comunicación</category>
 <pubDate>Sun, 23 Apr 2006 18:50:20 +0000</pubDate>
</item>
<item>
 <title>Experimento con programación por parejas</title>
 <link>http://www.agile-spain.com/agilev2/experimento_con_programacion_por_parejas</link>
 <description>&lt;p&gt;He encontrado un interesante artículo del Doctor Randall W Jensen publicado en la revista de ingeniería de software para defensa, The Journal of Defense Software Engineering, sobre sus conclusiones de un experimento de aplicación de programación por parejas. &lt;/p&gt;
&lt;p&gt;En el artículo, titulado &lt;a href=&quot;http://www.stsc.hill.af.mil/crosstalk/2003/03/jensen.html&quot;&gt;A Pair Programming Experience&lt;/a&gt;, Jensen explica como esta práctica supuso un importante incremento en productividad y un menor número de defectos.&lt;/p&gt;
</description>
 <category domain="http://www.agile-spain.com/agilev2/tema/comunicacion">Comunicación</category>
 <pubDate>Mon, 06 Mar 2006 16:13:44 +0000</pubDate>
</item>
<item>
 <title>Usando XP en un equipo de teletrabajadores</title>
 <link>http://www.agile-spain.com/agilev2/usando_xp_en_un_equipo_de_teletrabajadores</link>
 <description>&lt;p&gt;Más de una vez me he preguntado cómo podrían seguirse ciertas prácticas de extreme programming si varios o todos los miembros de un equipo teletrabajan. Ciertamente esto parece ir en contrar de un proceso de desarrollo que tiene como columna vertebral el potenciar la comunicación directa. &lt;/p&gt;&lt;p&gt;Pues bien, Rachel Davis nos cuenta en el artículo &lt;a href=&quot;http://www.twelve71.org/blogs/rachel/archives/000840.html&quot;&gt;Remote Pair Programming&lt;/a&gt; cómo han aplicado con algunas variaciones y bastante &amp;eacute;xito prácticas como la programación por parejas o la reunión diaria. Para ello han usado tecnologías como Skype o compartición del escritorio con Netmeeting. Rachel comenta sobre los problemas encontrados y cómo estas prácticas han producido efectos beneficiosos aunque el proceso se &lt;em&gt;sienta&lt;/em&gt; bastante diferente al de XP tradicional.&lt;/p&gt;</description>
 <category domain="http://www.agile-spain.com/agilev2/tema/comunicacion">Comunicación</category>
 <pubDate>Wed, 11 Jan 2006 08:14:22 +0000</pubDate>
</item>
<item>
 <title>Eliminando el misticismo de la programación por parejas</title>
 <link>http://www.agile-spain.com/agilev2/eliminando_el_misticismo_de_la_programacion_por_parejas</link>
 <description>&lt;p&gt;La programación por parejas parece llevarse el galardón a la práctica más controvertida y menos entenida de los m&amp;eacute;todos ágiles. En su artículo &lt;a href=&quot;http://www-128.ibm.com/developerworks/library/j-xp03113.html&quot;&gt;Winning with a pair&lt;/a&gt; Roy Miller trata de explicar en qu&amp;eacute; consiste realmente esta práctica y el porqu&amp;eacute; del rechazo que surge en ocasiones tanto de programadores como de managers. &lt;/p&gt;
&lt;p&gt;En el foro asociado a la serie de artículos Demistifying Extreme Programming (de la que este es parte) hay un hilo especialmente interesante sobre el tema. Comienza con una pregunta sobre &lt;a href=&quot;http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?forum=179&amp;#038;thread=5873&amp;#038;cat=10&quot;&gt;porque la programacion por parejas es la práctica más abandonada de XP&lt;/a&gt; y trata temas como los sistemas de evaluación de desempe&amp;ntilde;o personales y por equipo, la sensación de que dos personas están haciendo el trabajo de uno, los problemas de parejas que permanecen juntas demasiado tiempo (días), etc.&lt;/p&gt;
</description>
 <category domain="http://www.agile-spain.com/agilev2/tema/comunicacion">Comunicación</category>
 <pubDate>Sat, 31 Dec 2005 12:35:09 +0000</pubDate>
</item>
<item>
 <title>Como transmitir la sensación de avance del equipo</title>
 <link>http://www.agile-spain.com/agilev2/como_transmitir_la_sensacion_de_avance_del_equipo</link>
 <description>&lt;p&gt;Era la primera vez que visitaba el blog de James Shore y me he encontrado con una entrada que me ha llamado mucho la atención.  &lt;/p&gt;&lt;p&gt;Los antecedentes son esos: todos los m&amp;eacute;todos ágiles coinciden combatir las jornadas de trabajo excesivamente largas, reuniones interminables y el exceso de presión en el trabajo. El resultado es que cuando se compara un equipo de trabajo que emplea XP o SCRUM con otros equipos que sufran los efectos anteriores puede parecer que hay una menor implicación de los integrantes del primero. Como consecuencia de esto comentaba Ron Jeffries en la lista de correo de XP que algunos clientes le pedían percibir una mayor &lt;em&gt;sensación de urgencia&lt;/em&gt; en los equipos de desarrollo. Al leer esto he recordado diversas charlas con esc&amp;eacute;pticos de los m&amp;eacute;todos ágiles que hablando sobre sus resultados me hacían comentarios como &lt;em&gt;la gente está demasiado relajada&lt;/em&gt; o &lt;em&gt;a las ocho ya no queda nadie en la oficina&lt;/em&gt;. &lt;/p&gt;&lt;p&gt;A pesar de mi absoluto convencimiento sobre lo negativo de la presión externa y las ventajas de la motivación y la auto-organización siempre me ha quedado una espina clavada: ciertos clientes que no están lo suficientemente cerca del equipo para conocer su avance de primera mano siguen quedándose en ocasiones con una impresión peor que si la gente trabajara muchas horas extra. Algo parecido puede ocurrir con ciertos directivos o gerentes de alto nivel. Y claro está, aunque tu sepas que se está avanzando muy rápido puede ser un problema que la percepción externa sea distinta &amp;iquest;puede evitarse esto? &lt;/p&gt;
</description>
 <category domain="http://www.agile-spain.com/agilev2/tema/comunicacion">Comunicación</category>
 <pubDate>Wed, 14 Dec 2005 18:51:17 +0000</pubDate>
</item>
</channel>
</rss>
