<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://www.scrummanager.com/bok/index.php?action=history&amp;feed=atom&amp;title=Conway%27s_Law</id>
	<title>Conway&#039;s Law - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://www.scrummanager.com/bok/index.php?action=history&amp;feed=atom&amp;title=Conway%27s_Law"/>
	<link rel="alternate" type="text/html" href="https://www.scrummanager.com/bok/index.php?title=Conway%27s_Law&amp;action=history"/>
	<updated>2026-05-25T23:07:27Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.45.3</generator>
	<entry>
		<id>https://www.scrummanager.com/bok/index.php?title=Conway%27s_Law&amp;diff=4325&amp;oldid=prev</id>
		<title>Mberne: Created page with &quot;{{Meta-bok|min=3}} La &#039;&#039;&#039;Ley de Conway&#039;&#039;&#039; (&#039;&#039;Conway&#039;s Law&#039;&#039;) es una observación formulada por Melvin Conway en 1967 que establece que las organizaciones que diseñan sistemas están inevitablemente condicionadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones. En palabras sencillas: la arquitectura del software tiende a reflejar la estructura organizativa del equipo que lo construye.  Conway publicó la observación en el...&quot;</title>
		<link rel="alternate" type="text/html" href="https://www.scrummanager.com/bok/index.php?title=Conway%27s_Law&amp;diff=4325&amp;oldid=prev"/>
		<updated>2026-05-20T09:16:34Z</updated>

		<summary type="html">&lt;p&gt;Created page with &amp;quot;{{Meta-bok|min=3}} La &amp;#039;&amp;#039;&amp;#039;Ley de Conway&amp;#039;&amp;#039;&amp;#039; (&amp;#039;&amp;#039;Conway&amp;#039;s Law&amp;#039;&amp;#039;) es una observación formulada por Melvin Conway en 1967 que establece que las organizaciones que diseñan sistemas están inevitablemente condicionadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones. En palabras sencillas: la arquitectura del software tiende a reflejar la estructura organizativa del equipo que lo construye.  Conway publicó la observación en el...&amp;quot;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;{{Meta-bok|min=3}}&lt;br /&gt;
La &amp;#039;&amp;#039;&amp;#039;Ley de Conway&amp;#039;&amp;#039;&amp;#039; (&amp;#039;&amp;#039;Conway&amp;#039;s Law&amp;#039;&amp;#039;) es una observación formulada por Melvin Conway en 1967 que establece que las organizaciones que diseñan sistemas están inevitablemente condicionadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones. En palabras sencillas: la arquitectura del software tiende a reflejar la estructura organizativa del equipo que lo construye.&lt;br /&gt;
&lt;br /&gt;
Conway publicó la observación en el artículo &amp;quot;How Do Committees Invent?&amp;quot; (1967). Fred Brooks la popularizó citándola en &amp;#039;&amp;#039;The Mythical Man-Month&amp;#039;&amp;#039; (1975), donde la llamó &amp;quot;Ley de Conway&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Implicaciones prácticas ==&lt;br /&gt;
&lt;br /&gt;
Si una organización tiene tres equipos de backend, dos de frontend y uno de QA, el sistema resultante tenderá a tener tres módulos de backend, dos de frontend y una capa de QA, reflejando las fronteras organizativas aunque no sea la arquitectura técnicamente óptima.&lt;br /&gt;
&lt;br /&gt;
Las interfaces entre módulos del sistema tienden a corresponder a las interfaces de comunicación entre equipos: los puntos donde la comunicación es difícil o costosa son los mismos donde la integración técnica es difícil o costosa.&lt;br /&gt;
&lt;br /&gt;
== La Inverse Conway Maneuver ==&lt;br /&gt;
&lt;br /&gt;
La consecuencia práctica de la Ley de Conway en el diseño de sistemas es lo que se conoce como la &amp;#039;&amp;#039;Inverse Conway Maneuver&amp;#039;&amp;#039; (maniobra de Conway inversa): en lugar de diseñar primero el sistema y luego organizar los equipos para construirlo, diseñar primero la estructura de equipos que se quiere tener y dejar que el sistema refleje esa estructura.&lt;br /&gt;
&lt;br /&gt;
En el contexto de microservicios y arquitecturas distribuidas: si se quiere un sistema con servicios independientes y desplegables de forma autónoma, se necesitan equipos organizados de forma que puedan operar con autonomía real sobre sus servicios.&lt;br /&gt;
&lt;br /&gt;
== Relevancia en el escalado ágil ==&lt;br /&gt;
&lt;br /&gt;
La Ley de Conway es central en los marcos de escalado ágil. [[SAFe]], [[Nexus]] y [[Modelos de escalado ágil|LeSS]] proponen estructuras de equipos específicas precisamente porque entienden que la organización de los equipos determina la arquitectura del sistema resultante.&lt;br /&gt;
&lt;br /&gt;
== Error frecuente ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div class=&amp;quot;bok-aviso&amp;quot;&amp;gt;&lt;br /&gt;
&amp;#039;&amp;#039;&amp;#039;Intentar cambiar la arquitectura sin cambiar la estructura organizativa.&amp;#039;&amp;#039;&amp;#039; Los equipos pueden acordar una nueva arquitectura técnica, pero si la organización del trabajo y la comunicación no cambian, el código tenderá a regresar gradualmente a una estructura que refleje la organización real. La refactorización arquitectónica sin cambio organizativo es una batalla permanente contra la gravedad.&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Referencias ==&lt;br /&gt;
&lt;br /&gt;
* Conway, Melvin E. (1968). &amp;quot;How Do Committees Invent?&amp;quot;. &amp;#039;&amp;#039;Datamation&amp;#039;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
== Véase también ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div class=&amp;quot;bok-tags&amp;quot;&amp;gt;&lt;br /&gt;
[[Pensamiento sistémico]] [[Modelos de escalado ágil]] [[SAFe]] [[Nexus]] [[Agilidad técnica]] [[Desarrollador]]&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;div class=&amp;quot;bok-ecosistema&amp;quot;&amp;gt;&lt;br /&gt;
&amp;lt;div class=&amp;quot;texto&amp;quot;&amp;gt;&lt;br /&gt;
&amp;lt;span class=&amp;quot;titulo&amp;quot;&amp;gt;&amp;#039;&amp;#039;&amp;#039;¿Quieres avanzar en agilidad?&amp;#039;&amp;#039;&amp;#039;&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;span class=&amp;quot;sub&amp;quot;&amp;gt;Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ &amp;#039;&amp;#039;&amp;#039;Skill Arena&amp;#039;&amp;#039;&amp;#039;]: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.&amp;lt;/span&amp;gt;&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div class=&amp;quot;botones&amp;quot;&amp;gt;&lt;br /&gt;
&amp;lt;div class=&amp;quot;bok-btn-outline&amp;quot;&amp;gt;[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div class=&amp;quot;bok-btn-filled&amp;quot;&amp;gt;[https://scrummanager.com/club/ Club Agile]&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[Category:Glosario de términos]]&lt;br /&gt;
[[Category:Marcos y modelos]]&lt;br /&gt;
[[Category:Prácticas técnicas]]&lt;/div&gt;</summary>
		<author><name>Mberne</name></author>
	</entry>
</feed>