Freitag, 23. Mai 2014

Vom Problem seiner Rolle gerecht zu werden.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


In vielen Firmen ist es üblich Rollen zu verteilen. Über die Rolle wird eine Verantwortlichkeit für mehr oder weniger genau definierte Aufgaben bestimmt. Ein Mitarbeiter kann Inhaber einer oder mehrerer Rollen sein, genauso wie mehrere Mitarbeiter dieselbe Rolle besitzen können. "Rollen entwickeln sich. Eine Firma oder ein länger laufendes Projekt kann mit einer Definition der Rollen und wie diese zu besetzen sind, gewonnene Erkenntnisse standardisieren und so lange für höhere Produktivität sorgen, wie diese Erkenntnisse relevant sind." [S.200, DIR11]

Eine starre Rollenverteilung ist dabei nicht zielführend, genau wie eine starre Rollendefinition. Es wäre besser Rollen Richtungen zu nennen, in die man sich aufgrund seiner Fähigkeiten entwickeln kann. Innerhalb eines Teams befinden sich unterschiedliche Menschen, mit unterschiedlich ausgeprägten Fertigkeiten. In einem guten Team ergänzen sich diese Fähigkeiten und führen zu einem produktiven Austausch. Durch den Austausch, Weiterbildung und die eigene Entwicklung verändern sich die Fähigkeiten. Ein starres Rollenbild ist dieser Variabilität im Wege. Deshalb sollte man Rollen besser Richtungen nennen. Eine Richtung zeigt eine Konzentration an.

Der einzelne Mitarbeiter ist gezwungen sich auf bestimmte Themengebiete zu konzentrieren. Eine wirkliche Spezialisierung und ein tiefes Fachwissen erfordert diese Eingrenzung. Trotzdem kann man seinen aufmerksamen Blick auch nach rechts und links richten. Diese breitere Weltsicht ist auch durch die Kommunikation im Team gegeben. Ein vertiefendes Verfolgen der Fachthemen in der spezifischen Richtung eines Mitarbeiters fordert viel Zeit. Er muss Weiterbildungen besuchen, Fachliteratur studieren und erworbenes Wissen praktisch ausprobieren. Seine Ergebnisse muss er jedoch im Team kommunizieren. Bestimmte Entscheidungen, die in das Spezialgebiet fallen, hat man zu begründen. Die Suche nach dem besten Weg läuft eben über die gemeinsame verändernde Kommunikation.

Rollen in dieser Auffassung sind also Entwicklungsrichtungen. Ein Inhaber dieser Rolle verändert über die Zeit den Inhalt dieser Rolle. Er oder sie passt den Inhalt der Wirklichkeit an. "Personen sollten entsprechend ihren Stärken eingesetzt werden. Ein Rollenkorsett schränkt diese unnötig ein." [S.200, DIR11] Eine Person kann auch mehr oder weniger in einer Rolle zu Hause sein. Der Eine ist eine Fachkraft mit hoher Spezialisierung, der Andere ist eher ein Verbindungsglied zwischen den Rollen. "Gerade Brückenbauer, die in mehreren, klassischerweise getrennt betrachteten Disziplinen zu Hause sind, können einen großen Mehrwert bringen und das Team produktiver machen." [S.200, DIR11]

Verwechseln Sie Rollen nicht mit Posten. Eine Rolle ist im definierten Zusammenhang nicht auf Lebenszeit erworben. Es ist auch keine Stufe auf der Karriereleiter. Es ist im besten Fall eine Richtung, in die man sich entwickelt, um dem Team nutzen zu stiften. Es ist keine Machtposition, in der Epauletten verliehen werden, um auf Andere herabzusehen. Solche Karriereleitern sind von außen betrachtet oft Hamsterräder, deren Sinn zudem in Frage zu stellen ist. Eine Rolle ist dem Leben wesentlich verwandter. Es geht auf und ab. Die Rolle muss diese Schwankungen abfangen, sie muss sich an die Lebenswirklichkeit der Persönlichkeit anpassen, nicht die Persönlichkeit an die Rolle. Kompetenz ist eine Frage der Ausbildung, der Weiterbildung, der Erfahrung, sie ist keine Frage der Beförderung.

Bestimmte Aufgabengebiete wiederholen sich in verschiedenen Ausprägungen in fast allen Softwareprojekten. Ein Entwicklerteam, was etwas auf sich hält, führt eine Anforderungsermittlung durch. Für diese Aufgabe ist es naheliegend die Rolle eines Requirements Engineers einzuführen. In [IREB11] werden folgende Eigenschaften eines Requirements Engineers definiert: analytisches Denken, Empathie, Kommunikationsfähigkeit, Konfliktlösungsfähigkeit, Moderationsfähigkeit, Selbstbewusstsein und Überzeugungsfähigkeit. Diese Eigenschaften verlangen geradezu nach einer Persönlichkeit, die es so im richtigen Leben kaum gibt. Im anderen Falle können diese Eigenschaften jedoch über das Team verteilt sein und am Ende ergänzen sich die Mitarbeiter in ihren Aufgabenbereichen. Das Prinzip der gegenseitigen Hilfe ist deshalb in jedem Fall höher zu bewerten als ein sinnloses Gegeneinander.



Ein Requirements Engineer hat vier Hauptaufgaben: Anforderungen ermitteln, Anforderungen dokumentieren, Anforderungen prüfen und abstimmen und Anforderungen managen. Im Gegensatz dazu fordert [STARKE11] für den Softwarearchitekten, einer möglichen weiteren Rolle, folgende Hauptaufgaben: Architekturen konstruieren und entwerfen, über mögliche Alternativen entscheiden, garantieren, dass die Anforderungen erfüllt werden, die Architektur dokumentieren, die Architektur kommunizieren und einige mehr. Dazu braucht der Architekt ähnliche Eigenschaften wie der Requirements Engineer: analytisches Denken, Kommunikationsfähigkeit, Empathie und Mut. In viele Rollen muss ein Mensch erst hineinwachsen. Vertrauen in Menschen und deren Förderung kann bewirken, dass Menschen über sich hinauswachsen und unter bestimmten Bedingungen Aufgaben bewältigen, die sie sich niemals zugetraut hätten.

Es wäre ein vollkommen falsche Ansatz sensible Menschen von diesen Aufgaben zu befreien, weil ihr Selbstbewusstsein nicht groß genug ist. Sensibilität kann auf der anderen Seite große Empathie hervorrufen, mit deren Hilfe man sich in andere Menschen hineinversetzen kann. Gibt es wirkliche Teamarbeit, ist der Raubtierkäfig durch menschlich zivilisierte Verhaltensweisen ersetzt, sind die Ergebnisse dieser Menschen oft herausragend. Leistung ist auch von der Umgebung abhängig, in der sie erbracht wird.

Eine Mensch kann sich bestimmter Rollen annehmen. Um sie auszuüben sollte eine optimale Umgebung erzeugt werden, in der die Menschen ihre Fertigkeiten und Fähigkeiten leben können. Im Laufe der Zeit muss sich die Persönlichkeit weiterentwickeln. Die Rolle wird ihren Inhalt verändern, der Mitarbeiter wird neue Rollen übernehmen. Eine der wichtigsten Merkmale der Persönlichkeitsentwicklung ist die Kommunikation im Team. Es muss sich für den Einzelnen lohnen sein Wissen zu kommunizieren und lebhaft am Austausch im Team teilzuhaben.

Eine interessante Sicht hat auch [TOTH14] auf Rollen. Er lehnt ein starres Rollenverhalten ebenso ab wie [DIR11]. Auch hier ist ein pragmatisches Herangehen zu beobachten, welches den realen Projektverhältnissen gerecht werden soll. Unter bestimmten Voraussetzungen fordert [TOTH14] die Rolle des Architecture Owner (AO). "Der AO entscheidet nicht alleine und erledigt nicht alle Architekturaufgaben im Alleingang. Er hat einen verantwortungsvollen Blick auf die Gesamtarchitektur, unterstützt andere Entwickler, kennt die Probleme und ist erster Ansprechpartner für wichtige Stakeholder." [S.168, TOTH14] In gleicher Weise kann man einen Requirements Owner bestimmen. Dieser Begriff drückt für mich besser aus, wie eine Rolle in einem agilen Team besetzt sein sollte. Es wird eine Entwicklungsrichtung vorgegeben, für die man dann auch Verantwortung übernimmt, aber man zerstückelt niemals die gemeinsame Arbeit am Problem.

Diese grundsätzlichen Gedanken über den Sinn von Rollen habe ich deshalb durchgeführt, weil ich im nächsten Post ein kleines Gedankenexperiment beginnen möchte. Ich will eine kleine virtuelle Firma beschreiben, die mit Hilfe von Teamarbeit und bestimmten Rollen, besser Owner, Software erstellt und zum Einsatz bringt. Mit dieser Konstruktion hoffe ich die Prozessbeschreibung lebendiger zu machen und vielleicht auch einige Anregungen für die Organisation eines solchen Prozesses zu geben, aber auch zu bekommen.

  • [DIR11] : Jörg Dirbach, Markus Flückiger, Stefan Lentz: "Software entwickeln mit Verstand", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2011
  • [IREB11] : Klaus Pohl, Chris Rupp: "Basiswissen Requirements Engineering", 3.korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2011
  • [STARKE11] : Gernot Starke: "Effektive Software-Architekturen", 5. überarbeitete Auflage, Carl Hanser Verlag, München, 2011
  • [TOTH14] : Stefan Toth: "Vorgehensmuster für Softwarearchitektur", Carl Hanser Verlag, München, 2014


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen