Mit Spannung haben wir verfolgt, ob die BPMN 2.0 rechtzeitig zur OMG Abstimmung im Juni vorliegen wird. Sie hat es geschafft. 
Was aber hat sich zur Vorgängerversion geändert? Dürfte ich nur zwei Änderungen gegenüber der Version 1.2 beschreiben, müsste ich vor allem das Choreographie-Diagramm und das Meta-Modell erwähnen. Das ist aber längst nicht alles.
Doch schauen wir uns zunächst das neue Choreographie-Diagramm an. In der BPMN 1.2 konnte die Choreographie – also die Art und Weise, wie zwei Teilnehmer miteinander kommunizieren – nur unzureichend abgebildet werden. An dieser Stelle ist mit einem neuen Diagrammtypen mit eigenen Symbolen und Sequenzfluss ordentlich nachgebessert worden. Zwei weitere neue Diagrammtypen sind noch hinzugekommen: Das Konversations- und das Kollaborationsdiagramm.
Kommen wir zum zweiten Highlight: Dem Metamodell. Dessen Bedeutung schlägt sich auch im Namen der BPMN nieder. Stand in der Version 1.2 BPMN noch für “Business Process Modeling Notation” heißt es ab der Version 2.0 “Business Process Model and Notation”. Das Metamodell setzt wie bei UML und anderen Standards der OMG auf MOF (Meta Object Facility) auf. Hierdurch erhält die BPMN erstmals eine formale Definition der Syntax. Und was bringt mir das als Modellierer? Die Verwendung der BPMN ist eindeutig definiert und die Modelle sind künftig zwischen Tools austauschbar (so es der Toolhersteller denn unterstützt).  
Und was gibt es sonst noch? Eine Modellierung der Daten ist auch weiterhin nicht vorgesehen. Dafür gibt es jetzt Einhakpunkte, an denen man extern definierte Datenstrukturen (z. B. XML) einbinden kann.
Die Ausführungssemantik wird umfassend behandelt und sogar das Mapping auf WS-BPEL wird genormt (was natürlich Kritik bei den Verfechtern anderen Ausführungssprachen hervorruft).
Wenn alles gut geht, wird die BPMN 2.0 beim Technical Meeting der OMG im Juni in Costa Rica als “adopted specification” verabschiedet. Danach folgt ein Feinschliff, bevor sie offiziell als “available specification” herausgegeben wird. Erfahrungsgemäß werden etwa um diese Zeit auch schon die ersten Tools herauskommen, die sie unterstützen.
Zum Thema „Bühne frei für BPMN 2“ halte ich am 07. Juli 2009 einen Abendvortrag zu welchem ich Sie gerne einladen möchte ( http://www.oose.de/abendvortraege.html). Weitere Informationen zur BPMN 2.0  erhalten Sie in Kürze auf unserer Website.
Axel Scheithauer und Andrea Grass

   

Seit letztem Jahr schreibe ich im Java Magazin eine Kolumne zum Thema Architekturen kommentieren. Anfang Mai hatte ich bei der rheinjug, der Java User Group in Düsseldorf, die schöne Gelegenheit, einige Ideen daraus vorzustellen.
Der Veranstalter hat den abendlichen Vortrag auf Video aufgezeichnet und mittlerweile inklusive der Folien online gestellt.
Schön war für mich vor allem zu erleben, wie leicht sich die Zuhörer gleich zu Beginn in die Rolle eines neuen Projektmitglieds versetzen konnten. Oder in die eines Teammitglieds, was die vielen Fragen des Neulings parieren muss. Welche Antworten kommen zu Fragen rund um Softwarearchitektur? Ein Teilnehmer hat mir nachher berichtet, dass er am Ende nicht mehr wusste, ob er bei meinen Zitaten (z.B. “Steht alles im Wiki”) lachen oder weinen sollte.

• Video “Kleines 1×1 der Architekturdokumentation”
• Architekturen dokumentieren – Die Kolumne im Java Magazin

Stefan Zörner

   

Am 27.5. halte ich im Trainingscenter von oose einen Vortrag über Variantenmodellierung mit SysML. Das ist ein sehr spannendes und herausforderndes Thema.
Der Vortrag zeigt Ihnen, wie SysML mit einem Profil bzw. einer entsprechenden DSL (Domain Specific Language) eingesetzt werden kann, um eindeutige und verständliche Anforderungsspezifikationen mit Varianten zu erstellen.

Anmeldung und weitere Details.

   

Jetzt geht die Saat auf, die ich vor zwei Jahren gesät habe. Seinerzeit war die Object Management Group (OMG) noch mit der Entwicklung des Zertifizierungsprogramms OCEB (OMG-Certified Expert in Business Process Management) beschäftigt und nicht an einer SysML-Zertifizierung interessiert. Die Entwicklung ist abgeschlossen und OCEB weltweit verfügbar. Nach einigen Diskussionen haben wir uns jetzt für die Entwicklung eines neuen Zertifizierungsprogramms entschieden, den OMG-Certified Systems Modeling Professional (OCSMP).
Es wird vier Zertifizierungsstufen geben. Die ersten beiden Stufen adressieren SysML-Wissen und die Fähigkeit, SysML-Modelle zu lesen. Die darauf aufbauenden anderen zwei Stufen fokussieren auf die Eigenschaften von SysML, die man gut kennen muss, wenn man SysML-Modelle erstellen und SysML an spezifische Projektbedürfnisse anpassen möchte.
OCSMP wird gemeinsam mit dem International Council on Systems Engineering (INCOSE) entwickelt. INCOSE hat bereits ein Systems-Engineering-Zertifizierungsprogramm (CSEP), welches aber keine Modellierungsthemen enthält. INCOSE’s Vision 2020 beschreibt, dass das Model based Systems Engineering (MBSE) eine Schlüsseltechnologie in der Zukunft sein wird. CSEP ist in Kombination mit OCSMP somit ein idealer Baustein in der Systems-Engineering-Ausbildung. Voraussichtlich wird es eine spezielle Auszeichnung für Personen geben, die beide Zertifikate besitzen.
Nach der Entwicklung an OCEB, freue ich mich darauf, auch die neue SysML-Zertifizierung mit zu entwickeln. Ich halte Zertifizierungen für ein gutes Instrument, um Wissen nachzuweisen. Was sie nicht können, ist
methodische Fähigkeiten nachzuweisen. Diesen Anspruch haben sie auch nicht. Das wird aber leider oft anders gesehen und führt zu den kontroversen Meinungen über Zertifizierungen.
Mich interessiert Ihre Meinung zu OCSMP? Finden Sie es gut und haben Sie vielleicht auch Interesse, ein Zertifikat zu erwerben? Welche Inhalte sollte die Zertifizierung haben?
Tim Weilkiens

   

Ich berichte hier in zwei Teilen von meinen Erfahrungen auf dem Scrum-Day in München, auf dem ich einige Erkenntnisse aus unserer Studie zu Erfolgsfaktoren im IT-Projektmanagement vorgestellt habe.

Zum Vortrag: “Die Einführung von Scrum bei der Allianz Deutschland AG”
Aus dem Vortrag: Scrum (und viele Techniken aus dem Extreme Programming) haben bei der Allianz einen Durchdringungsgrad von 20%, d.h. 20% der Projekte werden mit Scrum & XP abgewickelt. Typischerweise sind dies allerdings die eher kleinen Projekte.
Am bemerkenswertesten an diesem Vortrag fand ich die zwei Gegenbewegungen, die sich innerhalb der Allianz vollziehen: Gegenüber den Kunden geht man von einer “beziehungsorientierten” Betreuung, in der Kunden und Vertreter ihre Betreuer persönlich kennen hin zu einem industriellen Versicherungsbetrieb, in der “Vorfälle” nach Kapazität und Art möglichst vollautomatisiert durch die verschiedenen Schritte des Geschäftsprozesses geleitet werden.   

Und als eine Antwort auf diesen Zwang zur Industrialisierung (“Versicherungen werden zur Commodity”) wird agiles Vorgehen eingeführt, dass die Flexibilität und Kosteneffizienz ermöglichen soll, die die Allianz braucht, um gut im Geschäft zu bleiben.  

Und hier findet man dann die Gegenbewegung: Agiles Projektmanagement ist eben ein stark “beziehungsorientiertes” Projektmanagement und erwächst aus der Erkenntnis, dass Softwareentwicklung gerade nicht mit industrieller Massenproduktion vergleichbar ist.

Dies ist der Allianz sehr wohl bewusst, trotzdem frage ich mich, wie Mitarbeiter der Allianz diese Gegenbewegungen vereinen oder ob dies für Sie überhaupt ein Problem darstellt?

Die Pausengespräche
In den Pausen konnte ich mich mit vielen Scrum-Mastern unterhalten, die von ihren Projekten berichtet haben. Bei allen wurde deutlich, dass sie nicht nur eine Scrum-Master-Schulung besucht haben, sondern schon viele Softskill-Fähigkeiten mitbringen: Know-How im Bereich der lösungsorientierten Kurzzeittherapie nach de Shazer und Berg, Gewaltfreie Kommunikation nach Rosenberg, Systemische Aufstellungsarbeit und Lingua Eterna.

Dies zeigt mir nochmal, wie sinnvoll und auch notwendig unser oose-Ansatz ist, eine Scrum-Master Schulung mit den entsprechenden Soft-Skills zu verbinden. Um so mehr freut es mich, dass unsere Teilnehmer dem zustimmen.

   

Scrum verwendet ja bekanntlich eine proprietäre, d.h. sehr eigene Terminologie. Gerade auch Standardbegriffe werden durch eigene Kreationen ersetzt, beispielsweise heißt die “Iteration” in Scrum “Sprint”. Bewusst andere Begriffe zu verwenden, hilft dabei, die Andersartigkeit, das Neue also, schneller und besser zu erkennen. Ein bewusster Kontrapunkt auch in der Sprache, damit gleich von Anfang an klar wird, es geht hier nicht um kleinere Neuerungen und Änderungen gegenüber dem Altbekannten, sondern um etwas grundsätzlich Neues, eine ganz andere Haltung oder Sichtweise. Gerade weil viele Einzeltechniken agilen Vorgehens so neu nicht sind (iteratives Vorgehen ist seit den 1970er Jahren in Theorie und Praxis bekannt und erfolgreich), sondern auch in etwas anderer Weise verwendet werden, kann eine klare sprachliche Abgrenzung hilfreich sein.
Diese wesentlichen Unterschiede in der grundsätzlichen Herangehensweise und Haltung formuliert das agile Manifest. Es setzt die Prioritäten anders und führt deswegen selbst dann zu einer anderen Vorgehensweise, wenn die Einzeltechniken an sich gar nicht groß geändert würden.
Eine andere Sprache ist aber ebenso auch problematisch. Zum einen bildet sie eine Barriere für Neulinge. Selbst wenn alle Einzeltechniken bekannt sind, selbst wenn jemand schon viel Erfahrung mit anderen agilen Vorgehensweisen und eine andere Haltung entwickelt hat – er muss jetzt neue Begriffe lernen.
Solange Scrum für viele neu war und in einer Nische steckte, verlangte die proprietäre Terminologie im positiven Sinne eine intensivere Auseinandersetzung mit Scrum. Je mehr Scrum in den Mainstream gelangt und selbstverständlich wird, desto mehr steht die proprietäre Terminologie einfach nur Seite an Seite mit anderen ((älteren) Standards). Es wirkt dann immer mehr so, als wäre das Andersseinwollen ein Selbstzweck, eine eher pubertäre Reaktion.
Zum anderen tut sich Scrum schwer damit, die Begriffe in die Muttersprachen ihrer Anwender zu übersetzen, in unserem Falle also ins Deutsche. Gerade auf dem Weg zum Mainstream gibt es viele gute Gründe hierfür. Die Häufigkeit von Missverständnissen oder gar die Unverständlichkeit einzelner Begriffe oder Aussagen ist selbst bei Deutschen mit durchschnittlichen oder guten Englischkenntnissen signifikant. Und auch die Kommunikationseffizienz ist geringer. Begriffe werden nicht ad hoc gefühlt, sondern mehr intellektuell verarbeitet, was ein verzögertes aber auch anderes Verstehen zur Folge hat. Wir Deutschen beklagen uns berechtigt über die vielen Anglizismen und den daraus gebildeten leeren Phrasen. Das heißt ja aber nicht, dass die Sätze im Englischen oder Amerikanischen sinnvoller sind. Manchmal merkt man erst bei der bewussten Übersetzung welcher Unsinn bereits im englischsprachigen Original steckt.
Ein weiterer Schwachpunkt der Scrum-Terminologie ist die teilweise unpassende Bildhaftigkeit. Die Metaphern sind oftmals ganz unpassend. Hier ein paar Beispiele.
Ein “Sprint” ist ein Kurzstreckenlauf, bei dem ich alle Kraft einsetze. Nach dem Sprint bin ich erstmal erschöpft. Es ist kein ausdauernder Lauf, sondern ein einmaliger. Eine Iteration dagegen ist etwas, das sich in ähnlicher Weise stets wiederholt. Sprint drückt gar nicht das aus, was Scrum eigentlich meint, nämlich eine “kurze Iteration”.
Dann gibt es noch die Backlogs: Product-Backlog und Sprint-Backlog. Ist ein Backlog eine “Rückstandsliste”? In gewisser Weise ja, aber der passendere und einfachere Begriff wäre vielleicht “Aufgabenliste”.
Das “Burn-Down-Chart” ist ebenso kein Abbrenndiagramm, sondern ein Abarbeitungsdiagramm oder ein auf den Kopf gestelltes Fortschrittsdiagramm.
“Scrum” selbst ist im Rugby ein “Gedränge”. Ist der Scrum-Master dann ein “Gedränge-Meister”, also ein besonders guter “Drängler”? So lustig eine wörtliche Übersetzung vielleicht klingt, so treffend ist der Begriff aber möglicherweise, denn ein Wesen von Scrum ist die starke Fokussierung auf das Entwicklungsteam, das Scrum-Team. Und was ist “fokussieren” anderes als ein Zusammendrängen? Allenfalls beim Scrum-Master wäre “Scrum-Coach” oder “Team-Coach” überlegenswert. Aber “Master” klingt natürlich cooler, vor allem wenn er noch “certified” ist.
Das Daily-Scrum-Meeting ist bereits ein Pleonasmus (eine sprachliche Redundanz) denn ein “Gedränge” ist ja irgendwie schon ein “Meeting” bzw. “Treffen”.
Die Rolle des Product-Owners (“Produkteigner”?) ist sehr eigen in ihrer inhaltlichen Bedeutung und Abgrenzung, und “Produktverantwortlicher”, “Kunde”, “Kundenrepräsentant” usw. drücken vielleicht nur Teile dessen aus, was in Scrum gemeint ist. Weniger dogmatisch und etwas mehr am Mainstream orientiert wäre “Produktverantwortlicher” aber wahrscheinlich halbwegs akzeptabel.
Abbrennen, Einmallauf, Rückstand, Drängen, Eigner – ich finde dass sind eher negativ konnotierte Ausgangsbegriffe.
Sofern man die unpassenden Metaphern vermeiden möchte oder nur im Duden stehenden Begriffe verwenden möchte, lassen sich folgende Übersetzungen wählen:

• Sprint -> Iteration
• Sprint-Backlog -> Iterationplan oder Aufgabenliste (für Iteration x)
• Produkt-Backlog -> Featureliste
• Burn-Down-Chart -> Abarbeitungsdiagramm
• Daily-Scrum-Meeting -> Tägliches Team-Treffen
• Product-Owner -> Produktverantwortlicher (oder Produktmanager)

Achja: für “Mainstream” hab ich gerade kein passendes deutsches Wort gefunden. “Sorry”.

   

In der Softwareentwicklung sind agile Vorgehensweisen inzwischen etabliert. Für komplexe Systementwicklungsprojekte wird ein iteratives Vorgehen immer häufiger gefordert. Die Ergebnisse der beteiligten Disziplinen wie Hardware, Software oder Mechanik müssen dabei regelmäßig und möglichst frühzeitig miteinander integriert werden.

Am 26. Mai stelle ich auf der Software & Systems Engineering Essentials in Berlin den iterativen Ansatz für die Systementwicklung mit dem Hauptaugenmerk auf die dazu erforderlichen Planungsebenen vor.
Michael Schulze-Ruhfus

   

Im Juni findet wieder ein Treffen der OMG statt. Diesmal in Costa Rica. Und wieder trifft sich die Domain Special Interest Group Systems Engineering für einen ganzen Tag.

Folgende Themen stehen u.a. auf dem Programm:

• UPDM
• SysML 1.2
• SysML/AP233-Mapping
• SysML und Modelica
• SysML/MARTE
• SysML 2.0
• SysML Certification

Es tut sich einiges im SysML-Umfeld. Die Sprache fängt an sich zu etablieren und weckt neue Wünsche.

Haben Sie auch neue Ideen für SysML? Ich würde mich sehr dafür interessieren, da wir mit den Planungen für die SysML 2.0 beginnen. Schreiben Sie mir: tim.weilkiens(at)oose.de.

   

Unser erstes CSM-Kombi-Seminar hat stattgefunden und ist bei den Teilnehmern sehr gut angekommen. Wir haben hierfür das zweitägige Standard-CSM-Seminar (Certified Scrum Master) kombiniert mit zwei (in Zukunft: drei) Ergänzungstagen zur Vertiefung vor allem der sozialen und kommunikativen Aspekte.
Die 2 Tage CSM-Kurs reichen so gerade, um einen Überblick über Scrum zu gewinnen und alle wichtigen Themen zu behandeln – aber nicht immer in ausreichender Tiefe. Wie genau fördert man die Selbstorganisation des Teams, moderiert Scrum-Planungssitzungen, führt Retrospektiven durch und vermittelt bei Konflikten zwischen Product-Owner und Team? In dem Ergänzungsblock wurden beispielsweise Kommunikationstechniken für eine prozessorientierte Moderation vermittelt, die dem Team helfen, Verantwortung für die Arbeitsergebnisse zu übernehmen.
Zwei exemplarische Teilnehmermeinungen:

• “Sehr gut strukturiertes Seminar mit lockerer Atmosphäre und trotzdem viel gelernt”
• “Sehr guter Mix aus Theorie und Praxis”

Der nächste Termin der CSM-Kombination ist vom 15.6. – 19.6. (2 Tage CSM plus 3 Tage Soft Skills).