Freitag, 7. November 2014

Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.

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.


In unserem Leben lassen wir uns, bei grundlegenden Entscheidungsfragen, oft genug nicht ausreichend Zeit. Obwohl wir immer wieder erfahren, dass wir mit den Folgen dieser Entscheidungen lange Zeit leben müssen. Die schnelle Entscheidung ein Tool zu benutzen, führt dazu, die Restriktionen des Werkzeugs ertragen zu müssen. Noch schlimmer, aber kaum beachtet, ist die Akzeptanz der Mehrfunktionalität, die man niemals nutzt. Man braucht einen Kutter und kauft einen Trawler. Wie verhindert man diese Fehlanschaffungen? Bei einer Entscheidung wählen wir zwischen verschiedenen Alternativen. Wir benötigen Kenntnisse zu den Alternativen und wir brauchen Kennwerte, die sie vergleichbar machen. Oft genug ist es nur der technikverliebte Blick, der uns verführt, statt ein intensives Nachdenken über Sinn oder Unsinn.

Dieser Blog behandelt in einer umfangreichen Reihe das Requirements Engineering. Deshalb möchte ich den Prozess der Toolauswahl an diesem Beispiel darstellen. [POHL08] fordert uns auf, bei der Auswahl eines geeigneten Requirements Engineering Tools, sich einige Fragen zu stellen:"
  • Welcher Requirements-Engineering-Prozess liegt zugrunde?
  • Welche Dokumentationsformen von Anforderungen (z.B. natürlichsprachige oder modellbasierte) müssen verwaltet werden?
  • Welche Stakeholder sind am Requirements-Engineering-Prozess beteiligt?
  • Welche Erfahrungen existieren im Bereich des Requirements Management?
" [S.687, POHL08] Auch [RUPP07] fordert uns auf: "Erst der Mensch, dann die Methode und zum Schluss das Tool." [S.402, RUPP07]

Die Fragen machen uns deutlich, dass wir über einige Dinge nachdenken sollten, bevor wir handeln. Zuallererst sollten wir uns jedoch klar machen, was ein Tool ist. Ein Tool sollte die Fähigkeiten unseres Körpers bzw. unseres Geistes erweitern, um ein ganz bestimmtes Ziel zu erfüllen. Unser Körper bzw. unser Geist vollzieht also ganz bestimmte Handlungen, um zu diesem Ziel zu kommen. Wir würden unter Umständen auch ganz ohne Tool auskommen. Im Requirements Engineering würde uns das gelingen, wenn wir uns alles merken könnten. Bevor wir jedoch an ein Tool denken, sollte uns klar sein, um welches Ziel es sich handelt, welche Handlungen wir durchführen müssen und was wir uns merken sollten. [POHL08] nennt die Folge der Handlungen, die ein Ziel verfolgen, in seiner Fragestellung den Requirements-Engineering-Prozess.



Spielen Sie diesen Prozess doch mal ganz ohne Tool durch. Ich mache eine kleine Ausnahme, Sie dürfen Marker und Whiteboards benutzen. Außerdem stelle ich Ihnen genug Whiteboardfläche zur Verfügung. Dann dürfte ein Requirements Engineering ganz ohne weitere Tools gelingen. Mit der Zeit und mit der Größe eines Projekts werden Sie jedoch erhebliche Komplexitätsprobleme bekommen. Sie entdecken Arbeitsschritte und Zusammenhänge, die mithilfe eines Tools wesentlich leichter zu entdecken, zu verwalten bzw. zu überblicken wären. Statt die ganze Wand abzusuchen, muss ein Tool Ihnen benötigte eingeschränkte Sichten liefern. Dazu müssen Sie wissen, welche Sichten Sie benötigen. Es wird auch nicht all zu lange dauern, bis jemand von Ihnen verlangt, dass Sie eine Anforderung ändern sollen. Dann löschen Sie die Anforderung ab und schreiben Sie erneut ans Whiteboard. Eine andere Person möchte die Anforderung jedoch gerne auf die alte Weise umgesetzt haben und bedauerlicherweise hat diese Person einen viel größeren Einfluss. Hätten wir die Anforderung nur nicht abgewischt. Das nächste mal schreiben wir die Anforderungen mit einer Änderungshistorie. Sicherlich sind solche Änderungen in einem Tool wesentlich besser zu verwalten. Umfangreiche Modelle können Sie natürlich an ein Whiteboard malen, die Konsistenz dieser Modelle zu prüfen ist etwas ganz anderes. Bestimmte Personen dürfen nur ganz bestimmte Dinge sehen. Dazu könnten Sie bestimmte Tafeln verdecken. Leichter ist das alles jedoch mit einem Tool.

Ein Tool soll Ihnen also die Arbeit erleichtern. Aber Sie müssen wissen, was Ihre Arbeit ist. Ein einziges Wort reicht hierbei nicht aus. Requirements Engineering ist nicht Requirements Engineering. Definieren Sie Ihren Requirements-Engineering-Prozess im Team. Wie ich im letzten Post bemerkte, wird nur ein akzeptierter Prozess wirklich sinnvoll ausgeführt. Leben Sie eine Zeit lang diesen Prozess und suchen Sie sich nach und nach kleinere Tools, die Ihren Prozess unterstützen. Viele kleine Werkzeuge sind meiner Meinung sinnvoller, als Funktionalitätsungetüme. Diese kleinen Tools sollten einen sehr begrenzten und genau definierten Funktionsumfang besitzen. Sie könnten als Services bereitgestellt werden und uns so erlauben unseren eigenen Requirements-Engineering-Toolkit zusammenzustellen, statt die Katze im Sack zu kaufen. Diese Services sollten genau nur die Zeit bezahlt werden, die sie auch genutzt werden. Dieses Verhalten würde einer anderen Notwendigkeit guter Prozesse sehr entgegenkommen. Ein Prozess ist nicht in Stein gemeißelt. Er unterliegt Änderungen. Ein gutes Team beobachtet seine Prozesse und führt Retrospektiven durch. Dabei werden sinnvolle Ergänzungen getätigt, genauso wie Sinnloses fallen gelassen wird. Ein solcher Fehlerkreislauf gewährleistet eine ständige Trennung von Spreu und Weizen. Services, die nur bei Nutzung gebraucht und bezahlt werden, unterstützen diese Herangehensweise. Ich kann Services wegfallen lassen und neue Services hinzufügen. Es entsteht ein lebendiges Gebilde, dass sich auf den benötigten Funktionsumfang beschränkt.



Tools, die einen Großteil unserer geistigen Energie absorbieren, sind schlechte Tools. Ein Werkzeug soll uns nicht von der Arbeit abhalten, es soll uns in der Arbeit unterstützen und sie einfacher machen. Die beschriebenen Services sollten deshalb über eine gute Dokumentation verfügen. Ein Tutorial kann uns schnell in die Arbeitsweise einführen. Installation und Deinstallation müssen immer auf dieselbe einfache Weise erfolgen. Das Zusammensetzen eines solchen Toolkits erfordert bei jedem Schritt ein genaueres Nachdenken. Brauche ich diesen Service? Hilft er mir, mein Ziel schneller zu erreichen? Unterstützt er mich in meinen Prozess? Wir würden keinen dieser kleinteiligen Helfer einsetzen und in unsere Toolkette einfügen, wenn wir ihn nicht benötigen. Kaufen Sie also keine Monstertools mit riesigen Funktionalitätsversprechungen. Wir fallen dabei auf Dinge herein, die wir nie genutzt haben und nie nutzen werden.

Ich plädiere also dafür zuerst einen Prozess zu entwickeln, ihn zu leben, ihn zu ändern und nach und nach kleine Services bzw. Programme zu nutzen die Prozesserleichterungen ermöglichen. Diesen beschriebenen Prozess sollte das Team in seiner Gesamtheit vollziehen. Aber das Team ist im Requirements Engineering nicht ausreichend. Beziehen Sie den Kunden bzw. den Fachbereich in diesen Definitionsprozess mit ein. Der Kunde spielt eine große Rolle bei der Definition von Anforderungen. Gründen Sie also kein Gremium. Erstellen Sie auch keinen Zeitplan für den Bewertungs- und Auswahlprozess. Lassen Sie die Evolution zu. Am Ende entsteht genau das Toolkit, welches Sie benötigen.

Wenn Ihnen solche Services über den Weg laufen, die genau in dieser Kleinteiligkeit zu nutzen sind, schreiben Sie mir bitte. Ich und vielleicht auch andere Leser wären Ihnen sehr dankbar über Hinweise jeder Art.

  • [POHL08] Klaus Pohl: "Requirements Engineering", 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008
  • [RUPP07] Chris Rupp & SOPHISTen: "Requirements Engineering und – Management", 4. aktualisierte und erweiterte Auflage, Carl Hanser Verlag, München, Wien, 2007


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