Freitag, 11. Juli 2014

Managementaufgaben zwischen Fremd- und Selbstverwaltung.

Managementaufgaben

Artikelübersicht
1. Teil Managementaufgaben zwischen Fremd- und Selbstverwaltung.
2. Teil Was soll ich zuerst tun? Die Qual der Wahl.
3. Teil Prioritäten verteilen ist eine Kunst.
4. Teil Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.
5. Teil Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.
6. Teil Im Dschungel der Nachvollziehbarkeit.
7. Teil Gib Deiner Version einen nachvollziehbaren Namen.
8. Teil Das Erstellen reproduzierbarer Software Releases.


Bisher haben wir uns mit dem Dokumentieren von Anforderungen beschäftigt. Dabei sind auf der Grundlage des Objekt-Aufgaben-Modells eine Fülle verschiedener Artefakte erzeugt worden. Das geschah durch beauftragte Tätigkeiten. Diese Artefakte (Objekte) und Tätigkeiten (Aufgaben) müssen geplant und verwaltet werden. Neben der reinen Dokumentation muss es demzufolge ein Management geben, welches die notwendige Planung, Steuerung und Kontrolle im Auge behält. Das Management muss die Aktivitätsausführung kontrollieren und steuern. [POH08] spricht im Requirements Engineering allgemein von den Phasen Gewinnung, Dokumentation, Übereinstimmung und Validierung. In meiner Prozessreihe setzte ich mich mit der Abfolge notwendiger Arbeitsschritte innerhalb der Softwareentwicklung auseinander. Deshalb werde ich in dieser Managementreihe zugunsten dieser Reihe auf prozessuale Beschreibungen verzichten.

Eine weitere wichtige Managementaufgabe innerhalb des Requirements Engineering ist die Beobachtung des Systemkontextes. "Der Systemkontext verändert sich über den gesamten Lebenszyklus eines Systems. Das Management im Requirements Engineering beobachtet diese Veränderung, um geeignete Maßnahmen zur Integration dieser Veränderung zu ergreifen." [S.495, POHL08] Für die Systemkontextanalyse habe ich eine eigene Reihe begonnen. In dieser diskutiere ich die Dokumentation der einzelnen Kontextobjekte. In der näheren Zukunft werde ich dort auch das Problem einer sinnvollen Beobachtung des Systemkontextes diskutieren.



In dieser Reihe möchte ich mich jedoch mit allen anderen Managementaufgaben auseinandersetzen, die mir ins Auge fallen und die ich als notwendig erachte. Zuerst werde ich mich mit dem versionierten Ablegen der Artefakte beschäftigen. Wie können wir eine konsistente Menge an Artefakten gewährleisten, die zu einem bestimmten Zeitpunkt eine geschlossene Informationmenge für einen Zustand der zu entwickelnden Software darstellt? Konsistente Mengen an Artefakten erzeugt man gewöhnlicherweise über das Setzen einer Baseline. Wie und wann setzen wir eine solche Baseline? Manchmal entwickeln sich Softwareprodukte auseinander, zumindest zeitweise. So etwas wird in Versionierungstools durch Branches abgebildet. Das Abzweigen zu vieler Informationen vom Hauptweg birgt jedoch die Gefahr, dass der Überblick verloren geht. Deshalb führt man Branches durch Mergen wieder zusammen. Leider habe ich auch schon Systeme gesehen, in denen der Überblick vollständig verloren gegangen und ein Zusammenführen der Branches ein Alptraum war.

Zuerst werde ich mich auf die Konzepte der zentralen Versionsverwaltung konzentrieren, später aber auch die Konzepte dezentraler Versionsverwaltungen diskutieren, wie sie beispielsweise durch GIT gegeben sind. Diese Konzepte erscheinen mir sehr flexibel und modern für die Arbeit in kleinen agilen Teams zu sein.

Eng mit diesem Thema hängt die Traceability zusammen. „Die Nachvollziehbarkeit einer Anforderung ist die Fähigkeit, den Lebenszyklus der Anforderungen über die verschiedenen Verfeinerungs- und Spezifikationsschritte bis hin zur Berücksichtigung der Anforderungen in nachgelagerten Entwicklungsartefakten verfolgen zu können.“ [S.505, POHL08] Die Artefakte haben also nicht nur die Dimension der Version, sie unterliegen auch Verfeinerungen, Herkunftsbeziehungen, Objektabhängigkeiten und vielen anderen zu diskutierenden Abhängigkeiten. Beim Thema Traceability kommt es vor allem auf ein sinnvolles Gleichgewicht zwischen zu setzenden Abhängigkeitsbeziehungen und der Einschränkung der Nachvollziehbarkeitsbeziehungen an. Ein wichtiger Grundsatz des Management sollte sein, dass der Verwaltungsaufwand in einem sinnvollen Rahmen bleibt, der der Aufgabe nützt.

Eine sehr wichtige und immer wieder durchzuführende Managementaufgabe ist das Priorisieren. Im Laufe der Zeit werden Objekte oder auch Aufgaben priorisiert. Priorisierungen ermöglichen es uns, sich auf das Wesentliche zu konzentrieren. Das ist aber nur der Fall, wenn wir vernünftige Priorisierungsmethoden und sinnvolle Priorisierungskriterien anwenden. In den Posts zu diesen Themen werden wir also genau das diskutieren. Warum sollte man was priorisieren und welche Schlussfolgerungen haben wir daraus zu ziehen?

Ein sehr wichtiges Thema ist natürlich das Änderungsmanagement. Ist ein Änderungsmanagement bei der agilen Vorgehensweise überhaupt notwendig? Sind Sprints kurz genug, um darauf zu verzichten. Benötigen wir einen komplizierten Prozess, um Änderungen in unser System einzupassen. Dieses Thema hängt eng mit der Versionierung von Anforderungen zusammen und eine Lösung für agiles Vorgehen muss demzufolge auch im Zusammenhang mit diesem Thema gesucht werden. Im Zusammenhang mit diesem Thema werden wir eine der Hauptbeschäftigungen von Entwicklern diskutieren, das Bugfixing. Wer sollte das wann tun, und welche Auswirkungen auf einen Sprint hat das?

Natürlich werden wir auch weitere Managementaufgaben diskutieren, insofern sie sich aus dem Kontext ergeben. Ich möchte auch kein eigenes Thema Requirements Management. Zur Zeit ist in der Requirements-Engineering-Reihe ersichtlich, dass es mehrere Stellen gibt, an denen die Requirements-Objekte Grundlage für die Weiterverarbeitung in der Systemarchitektur bilden und etwas später werde ich auch auf den direkten Übergang zu Useability Engineering eingehen. Auch nachfolgende Objekte werden in einem geschlossenen, einheitlich zu verwaltenden Prozess entstehen. Deshalb beziehen sich Managementaufgaben, wie das Planen von Aufgaben, die Versionierung von Objekten, das Setzen von Nachvollziehbarkeitsbeziehungen etc. nicht nur auf das Requirements Engineering. Sie beziehen sich auf alle zu planenden Aktivitäten und zu verwaltenden Artefakte.

Managementaufgaben beziehen sich also auf den gesamten Entwicklungsprozess. Jeder einzelne Schritt, ob Requirements Engineering, Softwarearchitektur, Useability Enginering, Codieren und Testen muss gesteuert werden. Je nach Firmenkultur ist der Projektmanager oder das Team für diese Aufgabe verantwortlich. In meinem Artikel Vom Problem seiner Rolle gerecht zu werden plädiere ich für Owner bestimmter Verantwortlichkeiten. Somit muss es auch Owner für die Aufgaben des Management geben. Für eine verantwortliche Wahrnehmung ist eine sinnvolle Aufgabenteilung zu empfehlen. Das Problem der Aufgaben- und Verantwortlichkeitskonzentration ist zum einen eine Überforderung, die lange andauern kann, da sie nicht zugegeben wird und zum anderen das Vernachlässigen bestimmter Aufgaben in Stresssituationen. Innerhalb einer guten Aufgabenteilung verteidigen die Verantwortlichen Ihre Aufgabengebiete. Die Owner sollten dabei nicht außerhalb oder über dem Entwicklerteam stehen. Die Durchsetzung per Macht ist zwar einfach, die Durchsetzung per Argument ist dem aber immer vorzuziehen.



Da ich ein agiles Vorgehen, spezifisch nach Scrum, bevorzuge, würde ich die Managementaufgaben auf den Product Owner und auf das Team verteilen. Die Rolle eines Projektleiters ist in Scrum überflüssig. Auf keinen Fall darf der Scrummaster in diese Aufgaben involviert werden. Er hat ausschließlich beratende Funktion und soll sich mit der Zeit überflüssig machen. Die einzelnen Aufgaben sind in folgenden Posts genau zu diskutieren.

Eine Abtrennung des Management von den eigentlichen Produktionsaufgaben halte ich persönlich nicht für sinnvoll. Oft fehlt dann im Management das fachliche Verständnis für die eigentliche Arbeit und es wird ausschließlich nach Zahlen entschieden. Am Ende erfolgt nur noch ein Controlling, welches kontrolliert statt steuert. Im agilen Vorgehen sollte so viel Vertrauen in die Teams vorhanden sein, dass diese sich selbst steuern können. In Ideologien, die das Gegeneinander bevorzugen, haben diese Kontrollmechanismen sicherlich einen eingebildeten Sinn. In der Realität beobachte ich durch diese Verantwortungsenteignung jedoch großflächige Motivationszerstörung und das häufige Arbeiten nach Vorschrift oder der Gang in der inneren Emigration.

  • [POHL08] Klaus Pohl: "Requirements Engineering", 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008


folgender Post dieses Themas


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

Keine Kommentare:

Kommentar veröffentlichen