Software Engineering Blog

Durch Artikel im Projektmanagement-Blog und im Blog von Jens Coldewey bin ich über Youtube (nein hier gibt es keinen Link) auf Prof. Peter Kruse aufmerksam geworden.

In diesem Video erklärt Prof. Kruse sehr gut, warum Veränderungsprozesse auch immer durch die oberste Ebene einer Organisation mitgetragen werden müssen und eine Änderung von unten nie erfolgreich ist. Und falls doch, dann nur, weil die Führung durch eine Reihe von Krisen so geschwächt ist, daß sie dem Änderungsdruck von unten nichts entgegen setzen können.

Für uns und unsere Projekte bedeutet dies, daß Veränderungen nur erfolgreich sind, wenn wir die Unterstützung der wichtigsten Stakeholder haben oder einfach der richtige Zeitpunkt dafür gekommen ist.

Gernot Starke hat in seinem Blog einen Hinweis auf seinen auf der WJAX
gehaltenen Vortrag zum Thema Architekturkommunikation hingewiesen, der als Video online zur Verfügung steht.

Starke widmet sich in seinem Vortrag dem Zusammenhang von Architektur und Kommunikation und weiß das überzeugend zu vermitteln.

Nach seiner Ansicht ist eine der wesentlichen Aufgaben eines Architekten die Kommunikation mit allen am Projekt beteiligten Stakeholdern. Richtig dachte ich nur während des ganzen Videos. Gute Architekturen zu entwerfenist das eine, sie zum Leben zu erwecken und zu halten etwas anderes. Dafür
müssen alle miteingebunden werden, die davon betroffen seien könnten. Und leider muß es muß auch immer wieder wiederholt werden.

Hier ein paar nebenbei notierte Aussagen von Starke:

• Architektur beschäftigt sich mit Strukturen und Konzepten.
• Implizite Annahmen treten immer da auf, wo etwas nicht
  dokumentiert ist, wo es notwendig gewesen war. (Alt bekannt!)
• Implizite Annahmen schaffen Mißverständnispotential. (Ich nenne
  das einfach mal heterogene Projektentwicklung. Klingt doch
  netter.)
• Architektur ist nicht das Kodieren von selbigen, da Code
  allein ab einer gewissen Größe keine Basis für Verständnis
  ist.
• Verständnis (von Architekturen) muß erst geschaffen werden und
  kann erst danach gefördert werden.
• Dokumentation muß minimalistisch sein, womit gemeint ist, daß
  nur die relevanten oder stabilen Punkte dokumentiert werden sollten,
  die für das Verständnis der Anwendung notwendig sind.
• Dokumentation muß wartbar sein.

Starke schafft es diese Punkte überzeugend zu vermitteln.

Fazit: Anschauen!

Oft herrscht werden die Begriffe Vorgehensmodell und Prozessmodell synonym verwendet und dabei lustig durcheinander geworfen. Beide sind aber nicht gleich, wenn auch eng verwandt.

Hier meine (Kurz-)Definitionen:

Vorgehensmodell Beschreibung von durchzuführenden Tätigkeiten, deren Abhängigkeiten und zeitliche Aufeinanderfolge.

Ein Vorgehensmodell sagt uns also, was wir zu tun habe: Anforderungsanalyse, Design, Codierung, Test, Einführung. Es sagt uns aber nicht, wie wir es zu tun haben. Hier kommt das Prozessmodell in das Spiel:

Prozessmodell Konkrete Beschreibung wie die durch ein Vorgehensmodell auszuführenden Tätigkeiten durchzuführen sind.

Ein Prozesmodell ist also die praktische Umsetzung eines Vorgehensmodell und trifft die konkreten Aussagen, die wir für unser Handeln in Projekten benötigen.

Das Verhältnis von Vorgehens- und Prozessmodell ähnelt sehr starkt dem Metamodell der UML. Das Prozessmodell ist die konkrete Ausprägung eines Vorgehensmodells. Sozusagen eine Instanz dessen. Das Vorgehensmodell beschreibt das Prozessmodell.

Dieser Unterschied ist wohl auch der Grund warum viele Menschen nach dem Lesen von Büchern zum Thema Software Engineering oder einer seiner Teildisziplinen erst einmal nicht wissen, wie sie das (hoffentlich) gelernte in die Praxis bringen. Das Buch sagt uns zum Beispiel das wir einen Projektplan erstellen sollen oder das Design dokumentieren sollen und wann wir das zu tun haben. Trifft aber keine Aussagen über das zu verwendende Werkzeug oder wie wir dokumentieren sollen. Dafür ist das Prozessmodell zuständig und diese sind immer so individuell wie sie, ihre Firma und ihr Projekt.

Als Projektleiter ist es unsere Aufgabe den Fortschritt unserer Projekte ständig mit den gesetzten Ist-Zielen abzugleich und die Voraussetzungen zu schaffen, daß es zu keinen gefährlichen Abweichungen kommt. Die meisten von uns beherrschen die hierfür notwendigen technischen Fähigkeiten. Oft kommt dabei aber die Mitarbeiterführung zu kurz. Im schlimmsten Fall erhalten die Mitarbeiter erst im jährlichen Personalgespräch eine Rückmeldung und diese kann von der Selbsteinschätzung erheblich abweichen. Für den Projektfortschritt würde kein Leiter ein solches Vorgehen akzeptieren, bei unseren Mitarbeitern akzeptieren wir dies aber zu oft.

Wie kann das sein? Der Grund ist einfach. Niemand fühlt sich wohl beim Kritisieren von den Menschen mit denen wir täglich zusammenarbeiten und es wird versucht den dabei möglicherweise entstehenden Spannungen aus dem Weg zu gehen. Dummerweise können dadurch Fehlentwicklungen entstehen, die sonst leicht zu korrigieren wären. Letztendlich sammeln sich alle Punkte an und ergießen sich kummuliert über den Mitarbeiter, der in dieser Situation oft nicht weiß wie ihm geschieht.

Viele Punkte können leicht in einem informellen Rahmen geklärt werden, ehe sie sich zu richtigen Problemen entwickeln. Nichts eignet sich dazu so gut wie ein kurzes Gespräch an der Kaffeemaschine oder bei Mittagessen.

Hier meine Tipps für eine kontinuierliche Mitarbeiterführung:

• Schaffen Sie eine Atmosphäre, die es Ihnen erlaubt früh Ihre Mitarbeiter auf Fehler oder andere Sichtweisen anzusprechen, ohne daß diese in eine Verteidigunghaltung gehen.
  Schaffen Sie die Möglichkeit zum gegenseitigen Feedback, auch im informellen Rahmen.
• Laß Sie ihre Mitarbeiter reden und seine Sicht oder die Gründe seiner Handlungsweise erklären. Denken Sie dabei an das Sprichwort „Reden ist Silber, Schweigen ist Gold.“
• Ziehen Sie für sich auch immer in Erwägung sich zu irren.
• Lassen Sie Ihre Mitarbeiter wissen, wenn Sie unzufrieden sind.
• Lassen Sie Ihre Mitarbeiter wissen, wann Sie mit ihnen zufrieden sind.

Denken Sie daran: Vorsorge ist immer besser als Problemlösung und aufgeschoben ist nicht aufgehoben.

Die aktuelle Sonderausgabe des Havard Businessmanagers Erfahrung enthält einen lesenswerten Artikel zu Fehlentwicklungen in Projekten und warum auch erfahrene Projektmanager grundsätzliche Fehler immer wiederholen.
(weiterlesen...)

Zu DDR-Zeiten gab es folgenden Witz: Zwei Schüler sind auf dem Schulhof. Der eine öffnet seine Tasche, nimmt seine Stullen raus und wirft sie weg. Worauf der andere fragt: „Warum wirfst du sie weg, du weißt ja noch gar nicht, was drauf ist.“ Der erste Schüler antwortet: „Leberwurst. Ich habe sie ja selber gemacht.“

Dieser Witz ist mir bei der Lektüre von „Adrenalin Junkies und Formular Zombies“ von Tom DeMarco und Co eingefallen, als ich mich gefragt habe, welche Verhaltensmuster ich selber kenne, die aufgeschrieben werden sollten.

Leberwurststullen gibt es dann, wenn die Entwickler in einer Firma niemals mit dem eigenen Produkt arbeiten würden und sich wundern, daß andere es tun. Ein Beispiel hierfür war mein rumänischer Kollege Florian, der sich immer geweigert hatte Online-Banking-Systeme zu benutzen. Auf unsere Nachfrage wieso meinte er nur, daß er in einem Team zur Entwicklung von Online-Banking-Systemen gewesen wäre und wüßte wie diese geschrieben würden. So etwas macht einen dann immer sprachlos. Nach Leberwurst riecht es auch, wenn ein Team mit einer selbstentwickelten Software arbeitet, die es selber für schlecht und unausgereift hält, es aber für Kundenprojekte einsetzt.

Diese beiden Varianten haben den gleichen Ursprung, wenn auch unterschiedliche Auswirkungen. In beiden Fällen haben alle Beteiligten das bewußte oder unbewußte Gefühl, daß etwas mit der Software die entwickelt wird oder dem Softwareentwicklungsprozess nicht stimmt. Daher können sie kein inneres Vertrauen zu ihrem Produkt entwickeln, nutzen es selber nicht und es bildet sich teilweise eine leicht zynische Haltung gegenüber dem Produkt. Das ist vergleichbar mit Bankern, die bei vollem Bewußtsein Kredite an nicht zahlungsfähige Häuslebauer vergeben und uns so die aktuelle Finanzkrise beschert haben.

In unserem Falle sind aber nicht die Entwickler daran schuld. Vielmehr fehlen in solchen Firmen zwei Dinge: Zum einen eine offene Kultur der konstruktiven Kritik und zum anderen ein Bewußtsein für Qualität. Eigentlich schade, den Qualität ist eigentlich gar nicht so teuer, denn auch wenn immer mit Aufwänden argumentiert wird, entsteht Qualität in aller erster Linie durch den Willen dazu.