modulo3
elements of quality
 Produktivitäts- und Qualitätsmanagement
 
  Home -> Themen -> How To: Coole Namen für Softwareprozesse
unsere Themen

Dieser Artikel erscheint hier mit freundlicher Genehmigung des
Autoren Matt Stephens 26.11.2005 als
deutsche Übersetzung von Rosemarie Dietrich und Michael W. Dietrich

How To: Coole Namen für Softwareprozesse

Ein aufregender neuer Trend überschwemmt zur Zeit die Welt: einen eigenen Software Entwicklungsprozess zu erfinden (Pluspunkte gibt’s für „Agilität“; Minuspunkte wenn einfach nur Praktiken zu XP hinzufügt oder weggelassen werden), danach muss man ihn im Web veröffentlichen und warten, bis er beiläufig in Büchern oder halbgaren Fachartikeln erwähnt wird:

„Einige Beispiel populärer agiler Prozesse sind Crystal Clear, Scrum, <HierKommtIhrProzess>, DSDM und Spiral.“

Typischerweise versagen Bücher oder Artikel ja völlig dabei, die Charakteristiken oder Unterschiede zwischen den Prozessen herauszuarbeiten, das wird einfach mal so nebenbei weggelassen. Der Grund dafür ist, dass  bei den meisten Gelegenheiten die Details nicht im Geringsten interessieren. Das Buch/der Artikel listet die Prozesse nicht auf weil der Autor will, dass sie hingehen und diese tatsächlich ausprobieren, um Himmels willen! Am wahrscheinlichsten ist noch, dass der Autor sich gerne vage sachkundig anhören möchte.


Wenn Sie also Ihren eigenen Prozess erfinden und in Büchern und Artikeln erwähnt werden wollen, ist der bei weitem wichtigste Aspekt ihrem Geisteskind einen cool klingenden Namen zu geben.


Einen großen Fehler machen Prozesserfinder immer wieder. Die definieren zuerst den Prozess, um danach über einen Namen nachzudenken der zusammenfassend –  in ein bis zwei Worten  – darstellt, was der Große Wurf dieses Prozesses ist.  Glauben Sie mir, das funktioniert nie und nimmer: Sie brauchen es wirklich nicht einmal zu versuchen! Ein Name, der auf einem zuvor definierten Prozess basiert, wird mindestens linkisch klingen und wahrscheinlich nie   ein Volltreffer werden. Es ist ein bisschen wie der Versuch aus Versehen einen Nutelladeckel auf ein Marmeladeglas zu schrauben.

Noch schlimmer aber ist es, dass Namen, die auf dem Prozess selbst basieren dazu tendieren viel zu nüchtern und abgeklärt zu klingen. Wenn der Autor eines Prozesses versucht, sich einen Namen auszudenken, der zu seinem Prozess passt, wird er bei so was landen wie Feature-Driven-Development oder Dynamic Systems Development Method. Gääääähhhhn. Metaphern sind da doch ein weit besserer Weg.

Der bei weitem verlässlichste Ansatz aber ist, sich zuerst einen coolen Namen auszudenken, die Domain zu reservieren, bevor es jemand anderes tut und dann die Details zu erträumen, die der Prozess benötigt, um zu dem Namen zu passen. Und immer dran denken, Sie müssen etwas sehr Metaphorisches erfinden: Nichts, was man zu wörtlich nehmen kann. Scrum (auch wenn es sich ein bisschen zu sehr wie „Skrotum“ anhört) ist ein Gutes, wenn auch haariges Beispiel einer Metapher, die ganz offensichtlich ausgewählt wurde, bevor der Prozess Fleisch an die Knochen bekam.


Lassen Sie uns im Geiste ein bisschen durch ein frei erfundenes Beispiel schlendern. Was wäre ein beispielhaft guter Name für einen Entwicklungsprozess? Es muss ein Name sein, der:

(a)   in eine Liste anderer Prozesse passt

(b)   der Sache … gerecht wird

(c)   und sich von der Masse abhebt.

Wie wäre es mit „Kohle“? Nicht mal ansatzweise gut genug! Man assoziiert sofort latente Hitze, langsam brennende Glut oder einen Prozess, der Millionen Jahre dauert; und dabei hab ich noch nicht mal erwähnt, dass man zwischen tausenden Tonnen Felsgestein eingeklemmt sein könnte. Das hört sich nicht wirklich agil an.


Nein, der ideale Name muss viel dynamischer sein, besonders, wenn er Seite an Seite mit den wirklich trendigen agilen Methoden stehen will. Wie wäre es mit „Maelstrom“ (Mahlstrom). Das ist doch schon eher was. Das suggeriert Bewegung, Iterationen, Ordnung, die aus dem Chaos entsteht, solche Dinge halt.

Lassen Sie ihn uns mal in einer Reihe verwandter Softwareprozesse in einem typischen halbgaren Artikel über Agilität ausprobieren:

„Agile Entwicklung erobert die Welt der Softwareentwicklung im Sturm. Die Zahl der Projekte, die agile Methoden benutzen wird nur noch erreicht von der Zahl der agilen Prozesse,  die plötzlich aus dem Nichts auftauchen, um die Fehler zu beseitigen, die im vorletzten Prozess, der plötzlich aus dem nichts auftauchte, entdeckt wurden. Einige Beispiele dieser agilen Entwicklungsprozesse sind Scrum, Extreme Programming, ICONIX, DSDM, Maelstrom, Crystal Orange, Coal und Adaptives Software Development.“

Ich weiß nicht, was Sie denken, aber aus dieser Liste scheint mir Maelstrom der bei weitem interessanteste und dynamischste aller erwähnten Prozesse. Alleine der Namen strahlt geradezu die vitale Essenz der Agilität aus.


Ok, nachdem wir jetzt einen verdammt coolen Namen für unseren neuen Prozess haben, müssen wir noch den Prozess zusammenbasteln, der zu diesem Namen passt.

Dictionary.com definiert Maelstrom als

  1. Eine gewalttätige oder turbulente Situation: z.B. Gefangen im Mahlstrom des Krieges
  2. Ein Strudel von außerordentlicher Größe oder Kraft.

Optisch suggeriert diese Definition dass unser neuer Prozess viel gemeinsam haben wird mit Boehms Spiralmethode. Die Spiralmethode sieht etwa wie folgt aus:



Abbildung 1-1. Der spiralförmige Entwicklungsprozess


Die Prämisse hier ist, dass man in der Mitte startet und sich dann in immer weiteren Kreisen dreht, bis man die Anforderungen versteht usw. Wenn dabei schon sonst nix rauskommt, dann könnte man daraus wenigstens ein paar coole Aerobic-Elemente für die allmorgendlichen Stand-up Meetings konstruieren.

Natürlich wollen wir nicht, dass unser neuer Prozess dem Spiralmodell allzu ähnlich ist: Schließlich muss es ja außer dem bloßen Namen noch ein paar Unterscheidungsmerkmale geben. Was wir also tun könnten wäre unsere Spirale, ääähhh unseren Maelstrom, außen beginnen und ihn sich dann auf seinem Weg ins Zentrum voranarbeiten zu lassen. Einfach genial. Abgesehen davon entspricht das auch viel mehr dem Verhalten eines Maelstrom im wirklichen Leben.

Ok – so weit, so gut.



Abbildung 1-2. Der Maelstrom Entwicklungsprozess in Aktion


Welche anderen Charakteristika eines Maelstrom können wir nun in den Prozess einarbeiten? Na ja, Strudel enden ja nicht wirklich in der Mitte: wenn das Wasser die Mitte erreicht stoppt ja nicht der ganze Mechanismus. Das wäre auch überhaupt nicht wirklich agil, weil in der agilen Welt Software ja nie wirklich „fertig“ wird. Wir müssen also die Tatsache abbilden, dass jede neue Iteration wieder am äußeren Ende beginnt. Außerdem wird uns das zusätzlich vom Spiralmodell unterscheiden, in dem ein Durchgang durch die Spirale ja mehreren Iterationen entspricht.

Außerdem beschleunigt sich ein Strudel, wenn man sich dem Zentrum nähert. Schiffe sind chancenlos in seinem grausamen Griff gefangen, sobald sie ein paar Mal in um sein rotierendes Zentrum herumgeschleudert wurden. Ihr Schicksal ist besiegelt. Genau das müssen wir in unserem Prozess abbilden, indem wir festsetzen, dass, je näher eine Interation dem Release kommt, umso mehr Widerstand gegen Änderungen entstehen wird. In anderen Worten, es gibt kein Zurück. Das mag zunächst nicht sehr agil erscheinen, bis man versteht, dass es eine Menge zusätzliche Schiffe (aka Iterationen) geben wird, die schnell aufeinander folgen.

Wachsende Kompetenz ist ein anderes Feld, auf das wir uns konzentrieren sollten. Die meisten Prozesse operieren auf der Prämisse, dass mit wachsendem Projektfortschritt, das Wissen des Projektteams und sein Verständnis, sowohl des Problems wie auch der Lösung stetig wachsen. Das ist somit ein weiterer Bereich, in dem wir uns mit unserem Prozess von der Masse abheben können. In Maelstrom wird also jedes Release, wenn es sich dem Zentrum nähert unwiederbringlich durch den Abfluss gespült und verschwindet endgültig in den Händen der Benutzer. Die Programmierer bekommen ein Release nie wieder zu Gesicht, wodurch Wartungskosten gegen 0 tendieren;: einer der großen Vorteile des Maelstrom-Ansatzes


XPer mögen ruhig für sich beanspruchen, dass sie Boehms cost-of-change Kurve abgeflacht haben. Maelstrom setzt noch eins drauf: tatsächlich kehrt er doch die Kurve um!


Hier ist nun also das fertige Prozess-Abbild – vorbereitet um per Copy-and-Paste in unzählige Bücher und Artikel eingearbeitet zu werden:



Abbildung 1-3: Der Maelstrom Entwicklungsprozess


Um die zufällige Erwähnung dieses Prozesses in zukünftigen Veröffentlichungen geradezu zu garantieren, könnten wir schließlich und endlich eine komplette Serie von Maelstrom-basierten Prozessen definieren, die auf verschiedene Arten von Projekten zugeschnitten sind. Ähnlich wie bei der Crystal Serie, die hat ja auch Crystal Clear für kleine Projekte, Crystal Orange für mittlere Projekte usw.

In Maelstrom könnten wir also Maelstrom-Teetasse (aka „Sturm im Wasserglas“) für kleine Einmann-Projekte benutzen; Mit Maelstrom-Boatpeople würden wir mittlere 15-30 Personen Projekte abdecken; Pacific-Maelstrom wäre für große bis sehr große Projekte geeignet und Maelstrom-großes-ungeheuerliches-schwarzes-Loch-im-Zentrum-des-Universums, für wirklich große Behörden-Budgetversenker bei denen Etatüberschreitungen in Millionenhöhe mehr oder weniger von Beginn an eingeplant werden.

Wir hoffen natürlich, dass dieser Artikel sie anspornt endlich ihre völlig eigene Entwicklungsmethodik zu  erarbeiten. Die Prozesslandnahme schreitet täglich voran, aber es bleibt immer noch Zeit für Sie, Ihre ganz eigenen Spuren in der Softwareszene zu hinterlassen. Viel Glück mit Ihrem coolen neuen Prozess. Um Ihnen einen Schubs in die richtige Richtung zu geben sind hier schon mal ein paar potentielle coole Prozessnamen als Arbeitsvorlagen. Nehmen sie einfach ungezwungen einen davon und fangen Sie noch heute an ihren idealen Prozess aus den großen metaphorischen Möglichkeiten zu extrapolieren, die in dem gewählten Namen verborgen liegen. Aber denken Sie daran, um zu erreichen, dass Sie Ihren Prozess regelmäßig in sinnlosen Listen aufgezählt  finden, sind die Details wirklich nicht wichtig. Der Name machts und die Metaphern die er impliziert sind das was zählt:

Octopus, Tiger Bright, Archipelago, Silver Blue, Inferno, Virile, Agile Dream, Kitchen Sink, Legless, Spaghetti Monster, Vorsprung Durch Technik, Cliffhanger, Coalface, Koolaid, Lunchbox, Spirogyra, Helix, Desoxyribonukleinsäure.


In der Tat liefert gerade die Genetik ein wahrhaftes Fünfgängemenü potentiell cooler Prozessnamen: Chromosom, Mitose, Metaphase, Telophase, Interphase… hey wie wäre es mit „Anaphase, der Softwarezellteilungsprozess“?

Wir könnten auch Scrum als Hinweis nehmen und Namen aus beliebten Mannschaftssportarten wählen: Foul, Check, Referee, Linesmen  solche Sachen halt. Wenn sie einen Namen aus dem Bereich des Sports finden können, der gleichzeitig wie ein ekliger Körperteil klingt, dann laufen Sie eines Tages vielleicht gar Scrum den Rang ab (in der Geldrangliste).

Aber wenn ihnen dazu nichts einfällt reicht es als zweitbeste Lösung bestimmt auch schon, einfach nur einen wirklich ekligen Körperteil als Namen zu wählen. Viel Glück!


 

unser spezieller Dank gilt unseren Sponsoren:

Matt Stephens
Rosemarie Dietrich

Agility kompakt. Tipps für erfolgreiche Systementwicklung.
Agility kompakt. Tipps für erfolgreiche Systementwicklung.
von Peter Hruschka, Chris Rupp, Gernot Starke

Der Pragmatische Programmierer.
Der Pragmatische Programmierer.
von Andrew Hunt, David Thomas

Agile Software Development.
Agile Software Development.
von Alistair Cockburn

Software Factories
Software Factories
von Jack Greenfield, Keith Short

© 2011 modulo3 gmbh
Impressum
Datenschutzhinweis
ICRA gekennzeichnet
Diese Website benutzt den Apache Webserver (Lizenz) und TYPO3 sowie diverse andere Software unter den Bedingungen der GPL.