Freitag, 24. Oktober 2014

Gehören Prozesse auf den Müll?

These:Gute Software benötigt gute fachliche Anforderungen.

Mein beschriebenes Anforderungsmanagement ist als Prozess definiert, demzufolge prozesslastig. Im Folgenden möchte beschreiben, warum ich dieses Verhalten bevorzuge, obwohl es einige Vorurteile gegen Prozesse in der Softwareindustrie gibt. Eine der größten Ängste ist es, mit der Arbeit im gegebenen Zeitrahmen nicht fertig und durch einen Prozess behindert zu werden. Nur wenn der Auftraggeber einen Prozess fordert, ist man punktuell bereit einen solchen einzuhalten. Beide Verhaltensweisen empfinde ich als problematisch. Weder sind Prozesse dazu da, ein Zertifikat sklavisch zu erfüllen, noch sollten sie Zeitprobleme produzieren. Ein guter Prozess ist für mich nur ein Prozess, der unser Denken auf die eigentliche Aufgabe konzentriert und Routinearbeiten automatisiert, ohne das sie vergessen werden.

[ALT12] beschreibt das Konzept eines Prozesses wie folgt: "Zunächst ist ein Prozess nichts anderes als eine Beschreibung eines Arbeitsablaufes. Dabei wird beschrieben, wie man vorgehen muss, um ein Ziel zu erreichen. Zusätzlich wird definiert, was man als Voraussetzung braucht und welches Ziel oder Endprodukt durch Abarbeitung des Prozesses erreicht bzw. erstellt werden soll." [S.84, ALT12] Ein Prozess soll also Ordnung ins Chaos bringen. Ich will nicht abstreiten, dass ein Genie das Chaos beherrschen kann, aber die wenigsten von uns sind Genies. Für mich ist es eine Erleichterung einen Fahrplan zu besitzen. Diesen kann man natürlich nicht willenlos zur Anwendung bringen. Man muss immer wieder optimierte Pfade von einem Ort zum Anderen finden. Manchmal muss man auch neue Wege hinzufügen. Die Beschreibung der Prozesse benötigt also Entwicklungspotential und auch die Anwendung sollte nur mit der Frage, was nützt es, stattfinden.

Entwicklungsprozesse in der Softwareentwicklung sind kaum mit technischen Prozessen zu vergleichen, die genau, Schritt für Schritt beschreiben, was zu tun ist. In Softwareprojekten ist immer ein Unsicherheitsfaktor, was am Ende herauskommt. [DIR11] beschreibt: "ein Softwareprojekt hat in aller Regel ein unscharfes Gesamtziel. Dies ist bedingt durch Unwissen über den Ausgangszustand, unklare Lösungsmöglichkeiten sowie Kombinationsmöglichkeiten aus verschiedenen Alternativen." [S.16, DIR11] Auch spricht sich [DIR11] ganz offen dagegen aus, die Softwareentwicklung als Herstellungsprozess zu definieren. "Der Weg zur entwickelten Software kann nicht im Voraus detailliert beschrieben werden." [S.17, DIR11] Unterliege ich nun diesem Zwang alles schon vorher zu beschreiben? Ich bin davon überzeugt, dass das nicht der Fall ist.



Ich biete Modelle an, mit denen diese Suche erleichtert wird. Darüber hinaus versuche ich durch ein überlegtes Vorgehen zu verhindern, dass man in mehrere Fallen tappen kann, die nicht leicht zu umgehen sind. Da ist die Vermischung von funktionalen Beschreibungen und technischen Lösungen oder das Übersehen wichtiger Teilbereiche, wie die Sicherheit einer Anwendung oder das Usability Engineering. Ein Entwicklungsprozess muss demzufolge dazu geeignet sein, die Suche nach dem unscharfen Ziel in der Softwareentwicklung zu erleichtern und er muss flexibel genug sein, nicht sklavisch Schritt für Schritt abarbeiten zu müssen. Leider unterliegen Zertifikatsprozesse oft dieser sklavischen Mentalität. Sie werden durchgeführt um Vertrauen beim Kunden zu gewinnen und Zertifizierer verdienen sicherlich einiges an Geld mit dieser Unsicherheit des Kunden.

Ein anderes Problem sind verordnete Prozesse. Sie befinden sich oft nicht in den Köpfen der Mitarbeiter, die dann wenig motiviert an deren Abarbeitung gehen. Deshalb plädiere ich dafür, das jedes Team seinen eigenen durchdachten Entwicklungsprozess bestimmt. Die Entwickler müssen den Prozess akzeptieren, sie müssen mit ihm intellektuell übereinstimmen, um ihn mit Erfolg zur Anwendung zu bringen. Lieber ein kurzer Prozess, der auf einiges verzichtet, als ein Prozess, den die Mitarbeiter nur wegen der Befehlslage durchführen. Das führt zu halbherzig ausgeführten Teilschritten, die oft mehr schaden, als wenn sie gar nicht ausgeführt werden. Entwickler sind stolz auf verinnerlichte Prozesse. Sie müssen davon überzeugt sein mit diesem Prozess effektiv und effizient arbeiten zu können und außerdem sollte sie der Prozess weder vom Ziel der Produkterstellung abhalten, noch sollte er die Freizeit zu einem kümmerlichen Rest zusammenschmelzen lassen.

Entgegen der Vorbehalte gegen Prozesse führt jedoch oft ein ungesteuertes und prozessloses Dahintreiben zu Mehrarbeit, Stress und Überforderung. Wertvolle Ressourcen werden mit sinnlosen Doppeltätigkeiten belastet, weil niemand wusste, dass das schon erledigt war. Andere Aufgaben werden gar nicht erledigt, weil niemand daran denkt. Einfach mal machen liegt voll im Trend unserer Zeit. Die Vergeudung von Kraft und Energie wird jedoch nirgends registriert. Man ist stolz auf die unermüdliche Tätigkeit, statt nach einem Weg zu suchen, der die Aufgabe schnell und effizient erledigt, damit man sich ausruhen kann. Dieses einfach mal machen soll pragmatisch sein. Nicht viel fragen, dadurch wird man nur unbequem und erzeugt den Eindruck auch anderes nicht einfach hinzunehmen. Die Unwägbarkeiten dieses nicht gesteuerten Arbeitsablaufes, also eines nicht durchdachten Prozesses, werden durch das Nichtbezahlen von Überstunden abgefedert.

Einem Prozess zu folgen, heißt auch, von Anderen lernen zu wollen, von deren Wissen zu partizipieren. Man baut auf den Erfahrungen Anderer auf, bekommt Best Practices an die Hand. Dazu ist es notwendig, dass die Entwickler die Erfahrungen und die Best Practices durchdrungen und verstanden haben. Sie müssen selbst in der Lage sein zu bestimmen, was in ihrem Entwicklungsprozess wichtig ist. Der Aufbau eines Entwicklungsprozesses kann also nicht durch Verordnungen von Oben geschehen. Sie brauchen eigenständig denkende Entwickler, denen die Freiheit gegeben wird, ihren optimalen Weg zu finden. Dazu ist in jedem Fall Kommunikation nötig. Ein schweigendes Team ist kein Team, sondern eine Ansammlung von stummen Mitarbeitern. Auch sollten Sie hellhörig werden, wenn Verordnungen ohne zu murren hingenommen werden. Dann sind viele schon abgetaucht und ihre Performance ist in Gefahr.

  • [ALT12] : Oliver Alt: "Modellbasierte Systementwicklung mit SysML", Carl Hanser Verlag, München, 2012
  • [DIR11] : Jörg Dirbach, Markus Flückiger, Stefan Lentz: "Software entwickeln mit Verstand", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2011




Heute möchte ich einen zweiten, kleinen Beitrag veröffentlichen. Mit diesem Beitrag bin ich einer Bitte nachgekommen. Eigentlich sollte ich nur 7 bis 9 Tipps abgeben, aber ich möchte sie hiermit in einen Kontext setzen.

Expertentipps?

Ich wurde durch einen Mitarbeiter der MicroTool GmbH gebeten, ihm meine besten Tipps zum Requirements Engineering als Experte zu verraten. Auch andere Experten sollen ihre Tipps zu dieser Liste hinzufügen. Am Ende wird sich eine Liste von Tipps ergeben, die aus ganz unterschiedlichen Erfahrungen zusammengesetzt ist. Ich würde mich nicht als Experten bezeichnen, sondern eher als einen Entwickler, der seit 10 Jahren Erfahrungen auf dem Gebiet des Requirements Engineering gesammelt hat. In jedem Augenblick habe ich einen gewissen Stand erreicht, den ich durch neues Wissen, neue Erfahrungen weiterentwickeln möchte. Ich bin also auf fremde Hilfe angewiesen. Daraus folgt mein erster Tipp:

[1] Erarbeiten Sie Anforderungsmodelle niemals allein. Erarbeiten Sie Anforderungsmodelle im Entwicklerteam in Zusammenarbeit mit Kunden und Benutzern.

Auch mit dem Wort Tipp habe ich so meine Schwierigkeiten. In meinem Blog stelle ich mein Wissen dar, nicht als Tipp, sondern als Augenblicksstand. Diesen Stand möchte ich zur Diskussion stellen und ihn damit über sich hinaus entwickeln. Das ist eine dialektische Entwicklungsform, die den Anderen, das Gegenüber benötigt. Mein zweiter Tipp bezieht sich auf die notwendige Grundlage einer Zusammenarbeit.

[2] Achten Sie Ihre Gesprächs- und Arbeitspartner. Eine fruchtbare Diskussion kann nur in einem Klima gegenseitigen Vertrauens erzeugt werden.

Diese Form der Zusammenarbeit erfordert es, den Anderen als intelligenten Menschen wahrzunehmen und gemeinsam eine Basis der Zusammenarbeit zu entwickeln. Diktatorische Systeme neigen zu Bevormundung. Bevormundende Systeme neigen zu Demotivation. Deshalb mein dritter Tipp, den ich zur Diskussion stelle:

[3] Erarbeiten Sie den Prozess des Requirements Engineering gemeinsam im Entwicklerteam. Nehmen Sie nur solche Schritte auf, die in Bezug auf das definierte Ziel sinnvoll sind.

Innerhalb eines solchen Teams würde ich gegen den Drang bereits am Anfang Tools zu spezifizieren andiskutieren. Ein weiterer Tipp ist deshalb:

[4] Suchen Sie erst nach Tools, nachdem Sie Ihren Prozess definiert haben. Wählen Sie Tools, die Ihre Ansprüche abdecken und die so einfach wie möglich sind.

Für mich macht es keinen großen Sinn das Requirements Engineering vom Entwicklerteam abzutrennen. Das Team erarbeitet sich ein Anforderungsmodell, aus dem es ein Architekturmodell entwickelt, das dann mit Hilfe einer Programmiersprache umgesetzt wird.

[5] Fassen Sie das Entwickeln von Software als Einheit von Requirements Engineering, Softwarearchitektur und Programmierung auf. Alle Aufgaben sollten von einem Team durchgeführt werden.

In langfristigen Projekten, auch in agilen Projekten, werden viele Informationen verarbeitet. Unser Gehirn sondert ständig Informationen aus, um anderen Informationen Platz zu machen. Deshalb ist es wichtig, Dinge die wir vor einem Jahr gemacht haben, irgendwo nachzulesen. Auch wenn neue Leute ins Team kommen, ist es eine Frage der Fairness gutes Einarbeitungsmaterial zu besitzen.

[6] Dokumentieren Sie Ihre erarbeiteten Modelle und schützen Sie sie so vor dem gedanklichen Verfall. Benutzen Sie zum Dokumentieren übersichtliche Darstellungen, Grafiken und Tabellen. Verzichten Sie auf langatmige Freitexte.

Der wichtigste Prozess von allen ist jedoch der Prozess des Reflektierens und der ständigen Erneuerung. Dazu ist eine offene Fehlerkultur in Ihrem Betrieb notwendig. Aus Fehlern kann und sollte man lernen, dass geht jedoch nur, wenn man diese auch zugeben kann.

[7] Installieren Sie Fehlerkreisläufe und Retrospektiven, die es ermöglichen Ihre Prozesse ständig zu verbessern.

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

Kommentare:

  1. Ein wirklich gelungener Artikel, wo ich fast den letzten Punkt [7] der Expertentipps am wichtigsten finde. Es muss einen Mechanismus geben bei dem die Prozesse und deren Abläufe kritisch bewertet werden müssen und nicht als gegeben erachtet werden dürfen.
    Gerade die SW Entwicklung ist stätig im Wandel und da dürfen in Stein gemeißelte Prozesse nicht behindern. Was gestern mal gepasst hat kann morgen komplett falsch sein.
    Prozesse müssen auch so definiert sein, dass Sie lebbar sind und man das Team durch die nächste zusätzliche Checkliste nicht noch langsamer und unbeweglicher macht. Das Thema ist echt umfassend und im Artikel aber gut getroffen.

    AntwortenLöschen
  2. Dr. Viktor Sirotin27. Oktober 2014 um 21:17

    Man kan ein oder anderen Prozess nehmen. Es gibt mehrere Prozess- oder Vorgehensmodellen. Interessante Frage ist: wie kann man Qualität von Prozessen messen oder wenigstens vergleichen?

    AntwortenLöschen
  3. Meine Erfahrung ist, dass Menschen sich grundsätzlich nicht an Prozesse halten wollen, die ihnen auferlegt werden.
    Die Ausreden sind dabei immer die gleichen:
    1) Den Prozess nicht einzuhalten, spart wertvolle Zeit
    2) Der Prozess behindert die Qualität meiner Arbeit

    Das ist natürlich Quatsch. In der Regel behindern Mitarbeiter, die sich nicht an Prozesse halten, massiv die Abläufe in der Organisation und stehlen allen anderen Zeit. Aber das eigene, lokale Optimum wurde wenigstens verbessert.

    Wie immer hat Ralf Baumann hier sehr schön den Kern des Themas freigelegt. Akzeptanz ist der Schlüssel zu funktionierenden Prozessen.

    Methodische Ansätze wie Lean und Six Sigma sind sehr wirksam bei der Einführung von neuen Prozessen und Verbesserung bestehender Prozesse. Man kann sie auch in der Software-Entwicklung verwenden. Erst kürzlich habe ich ein Training zum Thema "Lean IT" gegeben, das entsprechende Werkzeuge vermittelt.

    AntwortenLöschen