<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Kommentare für Loseblattsammlung</title>
	<atom:link href="http://jenshimmelreich.de/blog/?feed=comments-rss2" rel="self" type="application/rss+xml" />
	<link>http://jenshimmelreich.de/blog</link>
	<description>Jens&#039; Blog</description>
	<lastBuildDate>Sun, 06 Feb 2011 18:17:22 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>Kommentar zu Selbstorganisation von Ralf Westphal</title>
		<link>http://jenshimmelreich.de/blog/?p=116&#038;cpage=1#comment-326</link>
		<dc:creator>Ralf Westphal</dc:creator>
		<pubDate>Sun, 06 Feb 2011 18:17:22 +0000</pubDate>
		<guid isPermaLink="false">http://jenshimmelreich.de/blog/?p=116#comment-326</guid>
		<description>Wie wäre es, den Begriff &quot;Zweck&quot; in die Diskussion einzuführen?

Hr. Simon hat, würde ich sagen, vor allem soziale Systeme gemeint, die &quot;sich einfach finden&quot;. Sie entstehen &quot;von innen heraus&quot;. Beispiele wären da für mich Familie oder Dorfgemeinschaft. Solche sozialen Systeme müssen ihren Zweck erst entwickeln; der wird gemeinschaftlich festgestellt.

Und dann gibt es soziale Systeme, die sich nicht &quot;einfach finden&quot;, sondern die &quot;gemacht werden&quot;. Beispiel: ein Softwareteam. Solche sozialen Systeme müssen ihren Zweck nicht entwickeln; der ist ihnen &quot;vom Erzeuger&quot; vorgegeben.

Die ersteren sozialen Systeme sind autopoietisch. Sie erhalten sich selbst. Dafür organisieren sie sich ständig selbst.

Letztere hingegen sind nicht autopoietisch im strengen Sinn, würde ich sagen. Sie werden von außen erhalten. Deshalb haben sie auch keinen inhärente Notwendigkeit zur Selbstorganisation bzw. die hat immer eine Grenze, die durch den Erzeuger vorgegeben ist.

Ich denke, die Frage muss deshalb lauten: Ist es zielführend (Welches Ziel? Wessen Ziel? ;-), Teams zu echt selbstorganisierenden Systemen zu machen? Oder inwiefern geht das überhaupt, da sie ja in etwas Größerem aufgehängt sind?</description>
		<content:encoded><![CDATA[<p>Wie wäre es, den Begriff &#8220;Zweck&#8221; in die Diskussion einzuführen?</p>
<p>Hr. Simon hat, würde ich sagen, vor allem soziale Systeme gemeint, die &#8220;sich einfach finden&#8221;. Sie entstehen &#8220;von innen heraus&#8221;. Beispiele wären da für mich Familie oder Dorfgemeinschaft. Solche sozialen Systeme müssen ihren Zweck erst entwickeln; der wird gemeinschaftlich festgestellt.</p>
<p>Und dann gibt es soziale Systeme, die sich nicht &#8220;einfach finden&#8221;, sondern die &#8220;gemacht werden&#8221;. Beispiel: ein Softwareteam. Solche sozialen Systeme müssen ihren Zweck nicht entwickeln; der ist ihnen &#8220;vom Erzeuger&#8221; vorgegeben.</p>
<p>Die ersteren sozialen Systeme sind autopoietisch. Sie erhalten sich selbst. Dafür organisieren sie sich ständig selbst.</p>
<p>Letztere hingegen sind nicht autopoietisch im strengen Sinn, würde ich sagen. Sie werden von außen erhalten. Deshalb haben sie auch keinen inhärente Notwendigkeit zur Selbstorganisation bzw. die hat immer eine Grenze, die durch den Erzeuger vorgegeben ist.</p>
<p>Ich denke, die Frage muss deshalb lauten: Ist es zielführend (Welches Ziel? Wessen Ziel? <img src='http://jenshimmelreich.de/blog/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> , Teams zu echt selbstorganisierenden Systemen zu machen? Oder inwiefern geht das überhaupt, da sie ja in etwas Größerem aufgehängt sind?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Kommentar zu Selbstorganisation von Jan Gentsch</title>
		<link>http://jenshimmelreich.de/blog/?p=116&#038;cpage=1#comment-325</link>
		<dc:creator>Jan Gentsch</dc:creator>
		<pubDate>Sun, 06 Feb 2011 16:50:13 +0000</pubDate>
		<guid isPermaLink="false">http://jenshimmelreich.de/blog/?p=116#comment-325</guid>
		<description>... und beim lesen kommt mir die folgenden Gedanken: Eine Aussage im Vortrag war, wenn ein selbstorganisiertes System sich nicht mehr verändert ist es tot, da es sich alleine schon um zu bleiben wie es, sich ständig entwickeln muss. In starren Organisationen treiben wir großen Aufwand um mit Regeln, Rollen und Vorschriften dafür zu sorgen, dass sich die Strukturen statisch und berechenbar, also möglichst tot bleiben. Das was zum Beispiel in Rahmen von Scrum von uns angestrebt wird, ist ein System (Team) welches sich durch ein gemeinsames Ziel definiert, aber lebendig ist. Das heißt, wenn es krank ist (seine Beziehungsregeln oder seine Strukturen nicht funktionieren) wird es sich von selbst regenerieren und gesunden.</description>
		<content:encoded><![CDATA[<p>&#8230; und beim lesen kommt mir die folgenden Gedanken: Eine Aussage im Vortrag war, wenn ein selbstorganisiertes System sich nicht mehr verändert ist es tot, da es sich alleine schon um zu bleiben wie es, sich ständig entwickeln muss. In starren Organisationen treiben wir großen Aufwand um mit Regeln, Rollen und Vorschriften dafür zu sorgen, dass sich die Strukturen statisch und berechenbar, also möglichst tot bleiben. Das was zum Beispiel in Rahmen von Scrum von uns angestrebt wird, ist ein System (Team) welches sich durch ein gemeinsames Ziel definiert, aber lebendig ist. Das heißt, wenn es krank ist (seine Beziehungsregeln oder seine Strukturen nicht funktionieren) wird es sich von selbst regenerieren und gesunden.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Kommentar zu Der Tod des Navigators von Artur Tomas</title>
		<link>http://jenshimmelreich.de/blog/?p=64&#038;cpage=1#comment-27</link>
		<dc:creator>Artur Tomas</dc:creator>
		<pubDate>Mon, 07 Dec 2009 10:51:10 +0000</pubDate>
		<guid isPermaLink="false">http://jenshimmelreich.de/blog/?p=64#comment-27</guid>
		<description>Gab es ihn je, den Navigator? Offenbar. In allen Lehrbüchern. Oft auch als &quot;Beifahrer&quot;-Metapher bezeichnet. Wenn ich genauer darüber nachdenke, habe ich mich zwar immer an diese Bilder gehalten, und sie sogar oft an Andere weitergegeben (z. B. bei Vorträgen über TDD, PP... XP), aber gespürt habe ich das noch nie. Es hat mir weder geholfen noch hat es mich gestört. Ich freue mich deshalb über den Beitrag von Jens und die Studien, die er nennt.</description>
		<content:encoded><![CDATA[<p>Gab es ihn je, den Navigator? Offenbar. In allen Lehrbüchern. Oft auch als &#8220;Beifahrer&#8221;-Metapher bezeichnet. Wenn ich genauer darüber nachdenke, habe ich mich zwar immer an diese Bilder gehalten, und sie sogar oft an Andere weitergegeben (z. B. bei Vorträgen über TDD, PP&#8230; XP), aber gespürt habe ich das noch nie. Es hat mir weder geholfen noch hat es mich gestört. Ich freue mich deshalb über den Beitrag von Jens und die Studien, die er nennt.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Kommentar zu Platzen oder Lean &amp; Zen von Dennis</title>
		<link>http://jenshimmelreich.de/blog/?p=32&#038;cpage=1#comment-3</link>
		<dc:creator>Dennis</dc:creator>
		<pubDate>Thu, 08 Oct 2009 04:30:12 +0000</pubDate>
		<guid isPermaLink="false">http://jenshimmelreich.de/blog/?p=32#comment-3</guid>
		<description>Hallo Jens,

mit solchen Gedanken bist du nicht allein, siehe 
http://www.markhneedham.com/blog/2009/08/12/zen-mind-beginners-mind-book-review/

Dort geht es nicht um Lean, vielmehr um den Anfängergeist generell und um die Wichtigkeit ihn - grade in sehr professionalisierten Branchen wie der Softwareentwicklung - zu bewahren. 

Schönen Gruß,
Dennis</description>
		<content:encoded><![CDATA[<p>Hallo Jens,</p>
<p>mit solchen Gedanken bist du nicht allein, siehe<br />
<a href="http://www.markhneedham.com/blog/2009/08/12/zen-mind-beginners-mind-book-review/" rel="nofollow">http://www.markhneedham.com/blog/2009/08/12/zen-mind-beginners-mind-book-review/</a></p>
<p>Dort geht es nicht um Lean, vielmehr um den Anfängergeist generell und um die Wichtigkeit ihn &#8211; grade in sehr professionalisierten Branchen wie der Softwareentwicklung &#8211; zu bewahren. </p>
<p>Schönen Gruß,<br />
Dennis</p>
]]></content:encoded>
	</item>
	<item>
		<title>Kommentar zu Klassisches Testen von Software versus TDD von Alexander Knöller</title>
		<link>http://jenshimmelreich.de/blog/?p=3&#038;cpage=1#comment-2</link>
		<dc:creator>Alexander Knöller</dc:creator>
		<pubDate>Wed, 19 Aug 2009 11:57:35 +0000</pubDate>
		<guid isPermaLink="false">http://jenshimmelreich.de/blog/?p=3#comment-2</guid>
		<description>Ich hatte das Glück diesen Vortrag bei der GI zu hören. Ich empfand es als sehr produktiv diese Trennung einmal so klar herauszuarbeiten wie es in dem Vortrag geschah. Es hat mir geholfen in Diskussionen um TDD und Testing bzw. dem Verständnis von Softwarequalität klarer Positionen beziehen zu können.

Beide Dimensionen waren zuvor in Diskussionen immer zu spüren, aber man hat häufiger unbemerkt mal zwischen Ihnen gewechselt und dadurch aneinander vorbeigeredet. Das kann ich seit dem sehr effektiv vermeiden, in dem ich frühzeitig die beiden Dimensionen anspreche.

Was ich mir noch wünschen würde wäre eine einschlägigere Terminologie, die das Verwechslungsproblem entweder expliziter macht oder sogar vermeidet: BDD wird sich gegenüber TDD vermutlich nicht mehr durchsetzen können. Aber es ist ganz klar die treffendere Bezeichnung und verhindert die Verwechslung mit klassischem Testen.</description>
		<content:encoded><![CDATA[<p>Ich hatte das Glück diesen Vortrag bei der GI zu hören. Ich empfand es als sehr produktiv diese Trennung einmal so klar herauszuarbeiten wie es in dem Vortrag geschah. Es hat mir geholfen in Diskussionen um TDD und Testing bzw. dem Verständnis von Softwarequalität klarer Positionen beziehen zu können.</p>
<p>Beide Dimensionen waren zuvor in Diskussionen immer zu spüren, aber man hat häufiger unbemerkt mal zwischen Ihnen gewechselt und dadurch aneinander vorbeigeredet. Das kann ich seit dem sehr effektiv vermeiden, in dem ich frühzeitig die beiden Dimensionen anspreche.</p>
<p>Was ich mir noch wünschen würde wäre eine einschlägigere Terminologie, die das Verwechslungsproblem entweder expliziter macht oder sogar vermeidet: BDD wird sich gegenüber TDD vermutlich nicht mehr durchsetzen können. Aber es ist ganz klar die treffendere Bezeichnung und verhindert die Verwechslung mit klassischem Testen.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

